[MPlayer-dev-eng] [PATCH] new mpeg muxer

D Richard Felker III dalias at aerifal.cx
Thu Feb 24 01:56:37 CET 2005


On Thu, Feb 24, 2005 at 01:02:22AM +0100, Nico Sabbi wrote:
> >- is there any way to make the muxer handle soft telecine for you
> > (tff/rff flags)? i know vcd allows 24fps, but dvd and maybe svcd
> > require fake 30fps with stupid flags.
> 
> at the moment the muxer detects for every video frame the
> tff/repeat_first_field and changes the related frame duration
> accordingly, so respect to the nominal fps in the seq_header
> a frame can last x1, x1.5, x2, x3.
> Afaik (but I may be wrong) other software such as pulldown.exe
> permit to set these fields in a progressive video, so as to emulate
> a telecined pattern. Is this what you mean/need?

i'm not talking about remuxing but encoding. presumably you have a
24fps source, and want to make a valid svcd or dvd out of it. you can
just increase the framerate to 30fps, inserting duplicate frames, but
that will give horrible choppy 4:2:2:2 pulldown rather than 3:2:3:2.

the "correct" way, as far as i'm concerned, is to encode at 24fps, but
then modify the output stream to indicate 30fps and to add tff/repeat
flags to alternating frames so as to emulate 24fps inside a 30fps
stream, aka "soft telecine". i'm not sure whether this nasty hackery
belongs in the encoder or in the muxer, though...

> >- what encoder options do you use to make compliant mpeg1/2 video for
> > vcd/svcd/dvd? so far i've had luck, but the players i've tested
> > might just be forgiving..
> 
> using short gops is the most effective solution: keyint=small N
> (I usually use 25, but many times I sucessfully muxed videos with N=125
> without pts underruns, dts can be zeroed in that case).

obviously you want the compliant gop sizes... ;)
i meant other stuff, like presence/absence of b frames, what the
correct gop sizes are, correct bitrates and vbv buffer sizes, etc...

> Vcd requires cbr, but this doesn't happen because
> a) lavc has the problems we all know (cbr is not an option)
> b) the muxer doesn't even try to pad frames/gops to reach a cbr stream 
> because it's silly
> (I even wonder what does the standard mean with cbr: inter-gop? 
> inter-second? bah).

cbr means within the window of the vbv buffer size...

> In any case we should consider that a reader must be tolerant in order 
> to deal with lavc...

are you sure? i've had good luck getting lavc to output cbr for vcd,
as long as you specify the correct rate for min/max rate and the
correct vbv buffer size.

> >- i seem to occasionally get weird out-of-order glitched frames during
> > really high motion scenes. is this due to buggy reordering of some
> > sort in the muxer, failure to enforce closed gops, or something
> > else? i think i can extract small samples that exhibit the problem
> > if you want to see one.
> > 
> >
> 
> yes please, post the filenames.

imo it's not worthwhile. the bug can trivially be reproduced by
encoding any video with enough motion to make lavc's scene-change
detection kick in, in which case the reordering misorders a frame.

> Closed gops don't work with lavc, but maybe you are remuxing something else?

nope. i have no interest in using other programs; it's too much work
dealing with all the temp files/pipes, and too slow...

> I'd glad you like it :)
> Next steps are:
> a) finally find an algorithm that can't mux streams so as to lead to pts 
> underrun
> b) verify buffering
> 
> I have some very vague idea for a), never thought of b).
> Suggestions and patches are very welcome.

my biggest suggestion would be padding for compliance. i know it's
stupid, but being able to generate 100% or even 90% compiant
vcd/svcd/dvd with no tools other than mencoder would be a huge step
forward over the mess of scripts and awkward tools everyone has to use
now. personally i don't care about vcd enough to use it if i have to
go though the pain of all that stuff, but if i can make a vcd with
just mencoder, i might actually use them now and then for preparing
videos for use on hardware players.

rich





More information about the MPlayer-dev-eng mailing list