[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.
>

With git-e01f478 (last known working) the values for first_dts for the ogg 
files I tested were all zero and reflected properly in the packet time 
stamps.

With git-41a097a and before the line was commented out, the first_dts was 
RELATIVE_TS_BASE plus/minus some unknown (unknown sometimes is zero) and 
this is not refected in the packet time stamps. The first packet pts and dts 
for the audio stream were zero.

With git-41a097a and after the line was commented out, there was a variation 
of negative values depending on file for the first_dts and this value was 
properly reflected in the packet time stamps.

So vorbis_packet in oggparsevorbis.c needs to be looked at as there could be 
other things. As far as I know right now, commenting that line out seems to 
fix it but don't know for sure if it breaks anything.

Its just a little strange that with git-e01f478 the first_dts was zero and 
with git-41a097a (with commented out line), there is a variation of negative 
values but thats fine since that is properly reflected in the packets.