[FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
Marton Balint
cus at passwd.hu
Wed Nov 4 23:44:56 EET 2020
On Wed, 4 Nov 2020, Michael Niedermayer wrote:
> we have "millisecond" based formats, rounded timestamps
> we have "exact" cases, maybe the timebase being 1 packet/frame per tick
> we have "high precission" where the timebase is so precisse it doesnt matter
>
> This here though is a bit an oddball, the size if 1 PCM frame is 1 sample
> The timebase is not a millisecond based one, its not 1 frame either nor is
> it exact nor high precission.
> Its 1 video frame, and whatever amount of audio there is in the container
>
> which IIUC can differ from 1 video frame even rounded.
> maybe this just doesnt occur and each frame has a count of samples always
> rounded to the closes integer count for the video frame.
The difference between the audio timestamp and the video timestamp for
packets from the same DV frame is at most 0.3929636797*frame_duration as
the specification says, as Dave quoted, so I don't see how the error can
be bigger than this.
It looks to me you are mixing timestamps coming from a demuxer, and
timestamps you calculate by counting the number of demuxed/decoded audio
samples or video frames. Synchronization is done using the former.
>
> But if for example some hardware was using internally a 16 sample buffer
> and only put multiplies of 16 samples in frames this would introduce a
> considerable amount of jitter in the timestamps in relation to the actual
> duration. And using async to fix this without introducing more problems
> might require some care.
I still don't see why timestamp or duration jitter is a problem as long as
the error is below frame_duration/2. You can safely use async with
min_hard_comp set to frame_duration/2.
In general, don't you find it problematic that the dv demuxer can return
different timestamps if you read packets sequentially and if you seek to
the end of a file? It looks like a huge bug which is not fixable if you
insist on sample counting...
Regards,
Marton
More information about the ffmpeg-devel
mailing list