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

[Nico Sabbi]

D Richard Felker III wrote:

>ok, at some point someone should make a guide for how to encode
>(compliant) vcd/svcd/dvd with mencoder's new mpeg muxer. a few
>questions i have right away:
>  
>

... keeping in mind that the muxer generates totally variable muxrate
and as a consequence warps the SCR, this is the reason why I called the
formats xvcd and xsvcd (and as you can guess there's no cbr padding
whatsoever in the stream)

>- 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?

>- lavc encodes keyframes (or perhaps the first p frame after a key
>  frame?) at very high quantizer trying to maintain cbr, resulting in
>  an ugly low-frequency flicker once every gop. is there a workaround?
>  
>

not yet, and the other muxer I tried (dvb-mplex) didn't cope with
it any better, so I don't have code to steal yet :)

>- 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).
The problems that can appear are two:
1) pts underrun is by far the most dangerous one because it prevents (in 
a strictly
compliant device) to play the associated audio/video frame
1) pts overflow (pts > scr + 1.0 seconds)
2) excessive buffering in the decoders

The muxer tries to mux the streams with an interleaving pattern that should
prevent both, usually 2) happens without problems, but currently there's no
check to verify over/underflow; 1) and 1b) sometimes happens, but in 
that case the
muxer compensates for them in the next gops

Dvd are the easiest streams to handle because they have higher permitted 
top bitrates
and specify vbr from the start, in addition they don't require pts in 
every frame;
I never experienced problems muxing dvds;
on the contrary vcd and svcds need pts in every frame, so I have to 
change slightly
the SCR algorithm, to ensure at every single frame that pts don't 
over/underflow.
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).

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

>- 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.
You can even disable reordering: -mpegopts noreorder
(on this behalf: wrong ordering is a thing of the far past, but I guess
there are still plenty of broken videos around).

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

>anyway, great job! it's amazing that this is finally (mostly) working.
>
>rich
>
>  
>
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.

    Nico