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

[Michael Niedermayer]

On Wed, Apr 11, 2012 at 01:29:02AM -0400, Don Moir wrote:
> >>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.

ill remove that line, we will see if that 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.

see f63412fc741e9936b71141e7f15ab8aa39ad72f9

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120411/ef9b0588/attachment.asc>