[MPlayer-dev-eng] Regarding x264 decoding optimizations

[Reimar Döffinger]

Hello,
On Fri, Jan 25, 2008 at 09:00:19AM +0100, Mathieu Monnier wrote:
> FFmpeg's devs know to efficienctly thread ffh264 (decoding several 
> frames in parallel). They just lack the time.
> > Another trick I thought of is that decoding non-ref
> > frames can be skipped automatically if facing frame
> > dropping. The skipped decode should save enough time
> > to catch up. This should provide gradual degradation
> > to playback framerate rather than long jerks. I looked
> > to me like this is not being done at the moment,
> > pardon me if I am wrong.
> >   
> It's sound on paper, but it won't work. The most complicated part (to 
> decode) in a video are the highest bitrate part, and in those, there 
> usually aren't any bframe (since their inherent complexity makes it 
> unefficient to add bframes).

The same applies to splitting out deblocking, it is called in-loop
filter for a reason, you may need its results to decode the next frame.
I'm not sure for H.264 but in general you might even need its results to
decode the later part of the same frame.

Greetings,
Reimar Döffinger