[FFmpeg-devel] first_dts set to RELATIVE_TS_BASE in vorbis audio
michaelni at gmx.at
Wed Apr 11 02:31:47 CEST 2012
On Tue, Apr 10, 2012 at 05:18:06PM -0400, Don Moir wrote:
> >>On Mon, Apr 09, 2012 at 07:57:17AM -0400, Don Moir wrote:
> >>>>In recent builds I now see that the AVStream.first_dts is
> >>>>set to RELATIVE_TS_BASE which is 0x7ffeffffffffffff.
> >>>>RELATIVE_TS_BASE is defined in libavformat\utils.c
> >>>>Not sure what all this effects, but I am seeing it in ogg
> >>>>files with vorbis audio for the audio stream.
> >>>>Previously, the first_dts value was always reliable in that
> >>>>it was set correctly or it contained AV_NOPTS_VALUE.
> >>>>Is this a bug or what does it mean ?
> >>>do you have a testcase ?
> >>>i mean a file + command line that shows a wrong output or something ?
> >>>its easyier to look into this when we look at the same case
> >>>instead of picking a random file and random options that certainly
> >>>would be different from what you used
> >>I was hoping someone could answer why this was changed.
> >>It looks like all my ogg files have this problem in the audio
> >>stream only, but it may be effecting other formats. Mostly it
> >>looks ok with other formats but not sure.
> >>The value in first_dts may be exactly RELATIVE_TS_BASE as in the
> >>following sample or RELATIVE_TS_BASE minus some unknown.
> >The last known good to me is git-e01f478 but there may be a more
> >recent version that was good.
> >The failing version that i first discovered it is git-41a097a but
> >it may fail in earlier version. git-6bfb304 is still a problem.
> By the way, I can't point you to actual failing senario. I use the
> first_dts value to determine the offset time for a stream. If this
> is not used as an offset then the timing can be off. I have noticed
> parcular behavior before with ffplay etc related to this but I don't
> remember the exact files used to produce that offhand.
> All you need to do is open the above sample and check the first_dts
> value for the audio stream. It will be RELATIVE_TS_BASE. This never
> occured with previous builds and so now first_dts is not reliable
> and I figure this is a bug but no one has been forthcoming with any
can you try to outcomment the code that messes with cur_dts in
and if it fixes this issue, maybe you could test with a few files
if it breaks anything.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel