[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