[FFmpeg-devel] [PATCH/RFC] Update libx264.c to use new libx264 features (b_keyframe, DTS support)

[Michael Niedermayer]

uOn Fri, Jan 15, 2010 at 11:39:50AM -0500, Jason Garrett-Glaser wrote:
> On Thu, Jan 14, 2010 at 9:55 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Jan 14, 2010 at 06:14:19PM -0500, Jason Garrett-Glaser wrote:
> >> This patch updates libx264.c to support a few new features:
> >>
> >> 1) Keyframes are now signalled by x264_picture_t->b_keyframe. ?This
> >> allows x264 to have non-IDR keyframes, such as in the new Periodic
> >> Intra Refresh feature (see http://x264dev.multimedia.cx/?p=249).
> >>
> >> 2) DTS are now set correctly using x264's native VFR handling system.
> >>
> >> 3) Timebase is now set using x264's native VFR handling system.
> >>
> >
> >> Potential issues:
> >>
> >> 1) FPS is the same as timebase. ?Is this necessarily correct?
> >
> > probably not
> >
> >
> >> Ideally, for ratecontrol purposes (x264 doesn't have VFR ratecontrol
> >> yet, but it's getting it soon), the FPS should be the average input
> >> fps, but that's probably not always possible. ?Is there any value we
> >> should use instead of timebase?
> >
> > hmm, we have AVStream.avg_frame_rate but a encoder has no access to
> > that currently
> >
> >
> >>
> >> 2) x264's DTS values start at a negative value in the case of
> >> B-frames; x264 leaves it up to the muxer whether to pass through the
> >> negative values, fix them with an initial delay, fix them with DTS
> >> compression, or use an EDTS element or similar. ?Will this work in
> >> ffmpeg, or will libx264.c have to munge the dts values somehow?
> >
> > negative dts should work
> 
> Wait a minute here: AVFrames don't even have a place to store dts.
> Where am I supposed to put it, or does the encoder just not do that?

It could be set in the AVPacket that avcodec_encode_video() will one day
output
like avcodec_decode_video2() alraedy now does on the input side.
currently encoders dont output dts, but where dts exists, negative
values should be no problem.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100115/3ab5e88e/attachment.pgp>