[FFmpeg-devel] [PATCH] lavf: accept time base from untrusted codecs if it matches timings

Michael Niedermayer michaelni
Mon Feb 14 13:24:31 CET 2011


On Sun, Feb 13, 2011 at 12:52:35PM +0200, Anssi Hannula wrote:
> On 06.02.2011 08:32, Anssi Hannula wrote:
> > If the first 4 frames contain timestamps that closely match the codec
> > time base, accept the codec time base in tb_unreliable() even if the
> > codec is blacklisted (currently MPEG-2 and H.264).
> > 
> > ---
> > 
> > Anssi Hannula wrote:
> >> Here's a new patch that checks the timestamps of the first 4 frames
> >> (using the same method which is used in the guess-framerate code) and
> >> uses codec time base for r_frame_rate if the timestamps fit to it.
> >>
> >> I tested also with several other files, including H.264 PAFF, MVE
> >> (ipmovie.c), and spotted no regressions.
> >>
> >> What do you think?
> > 
> > Ping. Also, I noticed an extra added newline in the patch, now removed.
> 
> This patch is indeed not enough. The h264 decoder may not discover the
> time base immediately from the first few frames, so st->codec->time_base
> may still be stream time base. So the code will notice from the first 4
> frames that the stream time base can accurately represent timestamps
> (which is always true), and sets codec_tb_matches_dts = 1.
> Since the mpegts timebase is 1/90000 (i.e. too fine to be fps),
> tb_unreliable() says (correctly) false despite codec_tb_matches_dts==1,
> so the detection code continues to inspect frames.
> 
> When the h264 decoder finally sets the codec timebase (e.g. 1/25), it is
> assumed correct due to codec_tb_matches_dts==1, even if it is not able
> accurately represent timestamps at all (e.g. 1/50 intervals).
> 
> At least this sample shows the above issue:
> http://samples.ffmpeg.org/V-codecs/h264/hdtv-interlaced/sky_720p_test_why-cant-i-overwrite.ts
> 
> So some checks need to be added to the patch to guard against above. Or
> use some entirely different/better approach :)
> 
> I'd really appreciate someone more experienced looking at this issue,
> but I'll take a further look at this myself later as well.

Could you explain elaborately what issue you are trying to fix?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110214/6e42df45/attachment.pgp>



More information about the ffmpeg-devel mailing list