[MPlayer-users] "Too many video packets in the buffer" playing a merged file

D Richard Felker III dalias at aerifal.cx
Sat Oct 2 23:53:44 CEST 2004


On Sat, Oct 02, 2004 at 12:29:46PM -0700, Loren Merritt wrote:
> On Sat, 2 Oct 2004, D Richard Felker III wrote:
> >On Sat, Oct 02, 2004 at 08:10:01PM +0300, Ville Saari wrote:
> >>
> >>The text in credits eats a horrible amount of bits, but a good encoder 
> >>only
> >>needs to encode the new lines appearing form the bottom and everything
> >>else is just motion vectors. I just tested a bunch of movies by splitting
> >>the credits to separate file and checking the bitrate and every single one
> >>had less bitrate in the credits than in the rest of the movie! And I
> >>certainly hadn't done anything special to the credits while encoding them.
> >
> >in general this is true. the only exception i can think of is when you
> >have really fancy backgrounds and stuff behind the credits eating lots
> >of bits, but the background still sucks enough that you don't want to
> >waste bits on it. :)
> 
> That case happens more often than I'd like. And it doesn't take a very 
> complex background to eat lots of bits from scrolling text. Especially if 
> it's interlaced text on a telecined background, like too many anime dvds.

nasty region1 anime dvds, yes. get the original japanese discs or
south asian ones instead if you want proper video...

> Even after deinterlacing, I've seen credits use 8x the bitrate of the 
> movie (at constant qp).

best solution is to use vrc_override, but i seem to recall hearing
it's broken at the moment...

> BTW, I've seen large improvements from using qpel in credits, while qpel 
> hurts compression in the main movie.

interesting..

> Concatenating (avimerge) the two 
> encodes works when decoded by libavcodec, but is it really legal mpeg4?

i don't see why not...

rich




More information about the MPlayer-users mailing list