[x264-devel] Re: Still struggling with VFR video

[bond]

just for general information: the cts/dts currently produced by svn
x264/gpac is 100% correct


----- Original Message ----- 
From: "Tomas Carnecky" <tom at dbservice.com>
To: <x264-devel at videolan.org>
Sent: Saturday, June 17, 2006 3:43 PM
Subject: [x264-devel] Still struggling with VFR video


> After having a little discussion over at mplayer-dev-eng about how DTS
> and CTS work, based on that I changed some code in the x264 mp4 muxer
> and now it sets DTS to p_picture->i_pts and CTS_Offset to 0. This works
> fine for streams without B-Frames. So I'm glad I can produce VFR mp4
> videos (even though they are without B-Frames).
> But I can't get x264 to produce correct mp4 files with B Frames. Also,
> when hacking on the demuxer, I've stubled across some problems with your
> code: 'offset' (in set_eop_mp4) can be negative, but that isn't allowed
> by the spec (and CTS_Offset is u32). And this indeed happens with my VFR
> source video.
>
> Michael Niedermayer explained me how DTS/CTS work in mpeg containers:
> for the case of mpeg1, mpeg2 and mpeg4 video there is a very
> simle rule how PTS/CTS must be set (no frame reordering CTS=DTS, frame
> reordering CTS=DTS for B frames, CTS of non B frames = DTS of next non B
> frame)
> However, I don't see how this could be properly implemented in x264. In
> case of non B frames, the mp4 muxer would need to wait for the next non
> B frame to set the CTS offset accordingly. But there is no such caching
> in the muxer.
>
> tom
>
> -- 
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12.06.2006
>
>

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html