[FFmpeg-devel] [patch 3/3] Make timing calculations less dependant on start_time being defined.

[Michael Niedermayer]

Hi

On Thu, Aug 23, 2007 at 10:17:20AM +1000, Neil Brown wrote:
> On Wednesday August 22, andreas at olebyn.nu wrote:
> > 
> > Since Neil does not seem to come back with a cleaned up patch
> > I've done that. (Getting invalid durations bugs me a bit :)
> 
> Hi,
>  thanks for doing that.
> 
> I was planning to come back with an update (sorry about the tabs in
> the first version) but was distracted by several things.
> 
> One being that I still don't get all the results I expect with my .wmv
> file.
> 
> With this patch in place, it reports the correct duration (00:05:00.8)
> which is an improvement, however I have problems syncing video and
> audio.
> 
> For example, if I
>    ffmpeg -i myfile.wmv  -b 1M myfile.mpeg
> 
> The resulting mpeg is nearly 2 seconds longer (00:05:02.2), reports a start
> time of 0.500000, and the audio is about 1.5 seconds ahead of the
> video.
> 
> Interestingly, the "preroll" number which used to be used to initialise
> start_time is 1579 (milliseconds), which is 1 second and 14 frames.
> If I offset the audio from the video by exactly that, it is perfectly
> in sync.  This puts the audio starting at the exact moment that the
> first non-black pixel appears in the video stream.
> 
> If I set st->start_time to asf->hdr.preroll in asf.c, then transcode
> to mpeg, the resulting mpeg is perfectly in sync.
> So there is still something wrong here.
> 
> Interestingly playing the original .wmv with 'ffplay' plays the audio
> in sync with the video.  It is just using ffmpeg to transcode that
> gets it wrong (plus kdenlive not only plays it out-of-sync, but also
> the audio is a bit choppy).
> 
> So I'm perfectly willing to believe that st->start_time shouldn't be
> set to hdr.preroll, but it seems that something else needs to be done
> with that number and I have no idea what.....
> 
> However I found
>       http://msdn2.microsoft.com/en-us/library/bb643323.aspx
> 
> which says:
> 
>   Preroll
> 
>   Specifies the amount of time to buffer data before starting to play
>   the file, in millisecond units. If this value is nonzero, the Play
>   Duration field and all of the payload Presentation Time fields have
>   been offset by this amount. Therefore, player software must subtract
>   the value in the preroll field from the play duration and
>   presentation times to calculate their actual values. 
> 
>   It follows that all payload Presentation Time fields need to be at
>   least this value. 
> 
> So if the video packets have a timestamp, which starts from 1.5
> seconds, and the audio packets don't have a timestamp, and just rely
> on starting at 'start_time', then I would get exactly the behaviour I
> see.  It can be fixed either by subtracting hdr.preroll from the
> timestamp in all the video packets, or by setting start_time to
> hdr.preroll.
> 
> I presume the former is preferred.  This patch seems to fix it.
> 
> Index: libavformat/asf.c
> ===================================================================
> --- libavformat/asf.c	(revision 10189)
> +++ libavformat/asf.c	(working copy)
> @@ -793,7 +793,7 @@
>              /* new packet */
>              av_new_packet(&asf_st->pkt, asf->packet_obj_size);
>              asf_st->seq = asf->packet_seq;
> -            asf_st->pkt.pts = asf->packet_frag_timestamp;
> +            asf_st->pkt.pts = asf->packet_frag_timestamp - asf->hdr.preroll;
>              asf_st->pkt.stream_index = asf->stream_index;

1.
asf.c does
asf->packet_frag_timestamp= AV_NOPTS_VALUE;
at some point, so your code might fail fatally as 
AV_NOPTS_VALUE - asf->hdr.preroll is not valid

2.
the av_find_stream_info() and related code will buffer packets which
have no timestamp until the first timestamp and then correct the
previous packets before passing them to te user app
so ffmpeg.c should not see audio packets without timestmamps as you
described (see code related to first_dts for the stuff which fixes up
the initial timestamps)

also ffmpeg.c should be a little more tolerant and not mess up if theres
a single missing or wrong timestamp, i guess finetuneing some command line
arguments would workaround that too ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070823/f90fac12/attachment.pgp>