[MPlayer-dev-eng] B frame handling

[D Richard Felker III]

On Mon, Apr 12, 2004 at 07:56:09PM +0200, Moritz Bunkus wrote:
> Heya,
> 
> > The packing like in AVI is absolutely forbidden. Each NUT packet must
> > containe EXACTLY ONE coded frame, whether audio or video. Putting
> > multiple frames in a single container packet is not allowed.
> 
> Good. Now how to let mplayer handle it... Here's my current problem. For
> Matroska mplayer takes the difference between two consecutive packet's
> timecodes as the packet's duration. This will be screwed if the
> Maktroska demuxer hands over the pts over as they are stored in the
> Matroska file (e.g. for a coded order sequence of IPBB and 25fps the
> timecodes would be 0ms, 120ms, 40ms, 80ms).

Basically the problem is that G1's architecture totally sucks...

> Solution one is to re-order the timestamps but not the video packets in
> the demuxer. This does work - badly. The playback is choppy, and A/V
> sync is often off by one frame. Likely because the codec cannot output a
> frame after the P frame...

This is very ugly, I agree.

> Solution two is two re-create the packed bitstream in the demuxer. Yuck.

Also ugly but at least it would work.

> Solution three is to... well... modify other parts of mplayer to handle
> this correctly. But how? Do you have any suggestions or other solutions?

Replace it with G2? ;)

> > P.S. I HATE B FRAMES
> 
> Me too, me too...

Just to elaborate...they add latency (bad), overcomplicate muxing,
demuxing, decoding, and presentation terribly, make temporal filtering
super-inefficient, and most importantly, they don't significantly
improve quality/bitrate and often even worsen it! But idiots still
insist on using them...

Rich