[FFmpeg-devel] [RFC] mpegts: Provide a monotonic timestamp to the outside world

Michael Niedermayer michaelni at gmx.at
Fri Nov 2 04:16:28 CET 2012


On Thu, Nov 01, 2012 at 05:53:42PM +0100, Harald Axmann wrote:
> Am 01.11.2012 01:50, schrieb Michael Niedermayer:
> >On Thu, Nov 01, 2012 at 01:39:34AM +0100, Harald Axmann wrote:
> >>Am 31.10.2012 04:11, schrieb Michael Niedermayer:
> >>>On Wed, Oct 31, 2012 at 01:15:26AM +0100, Harald Axmann wrote:
> >>>>[...]
> >>>>Everything is okay, it was a compiling issue there.
> >>>>
> >>>>What do you think about it? Should I change something or is it suitable now?
> >>>it appears to break "make fate"
> >>I executed "make fate", please see attached log file. Could you
> >>please point me to the problem? Do I need to specify some samples,
> >>as said in the first line?
> >yes, and you can fill the samples with make fate-rsync
> >
> >[...]
> 
> Am 01.11.2012 01:59, schrieb Carl Eugen Hoyos:
> >[...]
> >Use the following to download the samples:
> >$ make SAMPLES=fate-suite fate-rsync
> >
> >And the following to run all tests:
> >$ make SAMPLES=fate-suite fate
> >
> >As long as you are working on the failing test,
> >the following is sufficient:
> >$ make SAMPLES=fate-suite fate-zmbv-8bit
> >
> >[...]
> 
> Thank you very much. I found the mistake, it was a missing cast, as
> I did not expect such high values for "time_base.den".
> 
> I also deactivated the wrapping detection now, if the number of time
> stamp bits is equal to 64.
> 
> Now "make fate" worked out for me. Could you please check the
> updated version of the patch? Thanks!

>  utils.c |   37 +++++++++++++++++++++++++++++++------
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 42c70b4fc8886550c60a717fe941e5c98d625bcb  utils-pcr-wrap-fix2.diff
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 3171b21..53a1a9a 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -78,6 +78,22 @@ static int is_relative(int64_t ts) {
>      return ts > (RELATIVE_TS_BASE - (1LL<<48));
>  }
>  
> +/**
> + * Wrap a given time stamp, if there is an indication for an overflow
> + *
> + * @param st stream
> + * @param timestamp the time stamp to wrap
> + * @return resulting time stamp
> + */
> +static int64_t wrap_timestamp(AVStream *st, int64_t timestamp)
> +{
> +    if (st->pts_wrap_bits != 64 &&
> +        st->first_dts != AV_NOPTS_VALUE && timestamp != AV_NOPTS_VALUE &&

> +        timestamp < st->first_dts - 60*(int64_t)st->time_base.den)

this ignores st->time_base.num

also consider that a file starts with dts -1/30 sec, that is one frame
in the past so that the first PTS is 0, this is not uncommon.
this would result in the first stored timestamp to be around the
maximum value and a wrap happening immedeatly, the above code would
then move the whole 1<<33 in the future. While this is just ugly
the bigger problem is that audio might start at 0 and it wont wrap
total AV desync would result.

I had not realized this corner case when suggesting to use streams
instead of programs for storing the first dts.

maybe you can add a new field to AVStream and use that instead of
first_dts and then synchronize this at a convenient place so that
streams in the same program have the exact same wrap point.
But i did not deeply think about this ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20121102/8c5e7e0e/attachment.asc>


More information about the ffmpeg-devel mailing list