[FFmpeg-devel] first_dts set to RELATIVE_TS_BASE in vorbis audio

[Don Moir]

> 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.
>> >>
>> >>http://sms.pangolin.com/temp/bad_first_dts_in_audio_stream.ogv
>> >>
>> >
>> >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
>>> answer.
>
>> can you try to outcomment the code that messes with cur_dts in
>> oggparsevorbis.c ?
>
> I commented out this line in vorbis_packet in oggparsevorbis.c:
>
> s->streams[idx]->cur_dts = AV_NOPTS_VALUE;
>
> This was the only reference to cur_dts in oggparsevorbis.c.
>
> With that change the first_dts in the audio stream is 0xfffffffffffffc00, 
> so no fix then.
>
> vorbis_packet has been added since it last worked correctly as well as the 
> relative time stamp code in utils.c

Actually that might have fixed it and 0xfffffffffffffc00 is valid. I will 
run some more test.