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

[Dale Curtis]

We're seeing this in Chrome as well. Essentially first_dts ==
RELATIVE_TS_BASE until the first av_read_frame(). This is
trivially reproducible with any ogg file and printing first_dts
after avformat_find_stream_info():

av_register_all();
avformat_open_input(&ctx, argv[1], NULL, NULL);
avformat_find_stream_info(ctx, NULL);
printf("first_dts: %ld\n", ctx->streams[0]->first_dts);
...


>>first_dts: 9223090561878065023


Is the proper response here to consider first_dts to be (ts -
RELATIVE_TS_BASE) when is_relative(ts) is true?

- dale

On Wed, Apr 11, 2012 at 5:56 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>