View Issue Details

IDProjectCategoryView StatusLast Update
0001771DCP-o-matic[All Projects] Bugspublic2020-07-05 22:35
Reportercarl Assigned To 
PriorityimmediateSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version 
Target Version2.16.0Fixed in Version 
Summary0001771: Audio artefacts at ends of audio files
Description

WAVs come from a post house split into reels, but prepared for 23.976. Then DCP-o-matic resamples them and there are discontinuities when one resampler is flushed and the next started.

  • concatenate the files before FFmpeg processes them? looks hard
  • re-use resamplers

When AudioDecoder makes a resampler we could re-use one from the same channel/samplerate/correct timing. If we had content

A1 A2

A1 would need to not flush its resamplers, then A2 would re-use them. A1 needs to know it has something following it.

Maybe some ResamplerManager that is set up in Player::setup_pieces. It knows which AudioDecoder is using what Resamplers and provides them on request to the AudioDecoder. The decoder can also tell the manager that it might want to flush the resamplers.

This was going fine in 1771-resample-glitches until ResamplerManager::maybe_flush; here it seems that we'll run into problems because Player may throw away samples that don't appear to come from the right place.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredUndecided

Activities

carl

2020-06-23 20:03

administrator   ~0003848

Last edited: 2020-07-05 22:35

View 4 revisions

Another idea might be

Extend Piece so that it has

vector<Content>
vector<Decoder>

where there are one or more of each, 1 decoder per 1 content.

Then extend the Piece API so that it does everything currently done by calls into the content from Player.

Content would be:

  • all the same type
  • only with start trim on 1st content and end trim on last
  • some settings the same

Tricky bits with this are:

  • _stream_states and audio streams in general
  • re-use of old decoders (optimisation)

_stream_states are piece, last_push_end (DCPTime) for every stream in every piece of content Initialised to content->position() in setup_pieces_unlocked

last_push_end updated when audio is pushed into the merger; here the piece and stream are known. Checked when deciding the time before which we have all audio

_stream_states could be a vector in Piece, then it is managed by Piece; call it when audio is pushed, it finds the correct stream from its internal list of content, then updates. Then you could ask it what the earliest stream is.

Going reasonably OK in 1771-resamples-glitches-take3

Issue History

Date Modified Username Field Change
2020-06-20 20:40 carl New Issue
2020-06-20 20:44 carl Description Updated View Revisions
2020-06-20 20:44 carl Estimated work required => Undecided
2020-06-21 19:09 carl Description Updated View Revisions
2020-06-23 20:03 carl Note Added: 0003848
2020-06-23 20:03 carl Note Edited: 0003848 View Revisions
2020-06-23 22:27 carl Note Edited: 0003848 View Revisions
2020-07-05 22:34 carl Status new => confirmed
2020-07-05 22:35 carl Note Edited: 0003848 View Revisions