[MPlayer-users] XviD sync-bug and its fix

[armin.gerritsen at philips.com]

D Richard Felker III wrote:

> -hardframedrop is intended to cause image corruption. This
> flush-until-the-next-I-frame business is nonsense.

That's why I said "If you don't want to accept this (as I didn't), one
should add also".
If you'll accept corruption, it is indeed obsolete (not nonsence).

>> A better, but more intrusive fix would be to decode the frame, but
>> don't return it so it will not be dithered and displayed, but this
>> may not buy you much cycles (it didn't on our embedded CPU).

> No, that's what -framedrop does!!

.. and where it fails to do so in some cases as explained.

>> This covers pretty most all situations where the actual decoding
>> drops a frame, but in the extreme case that an I-frame needs to be
>> dropped (which the decoder even with my fix doesn't do), it will
>> fail. I admit this is

> LOL, drop an I frame?!? You might as well not decode the video at all.

I know, but I just mentioned it for completeness. (As I feel was very clear
in my post.)

One can however image on a multi-task system that a background process
suddenly does something causing the need to drop all frames (including
I-frames) for short periode of time and after that play normally.

> Seriously, if you're working on video decoding in an embedded system,
> the system needs to be fast enough to play the video!! Dropping frames
> at all is a total joke...

Well, better you first ask more before you judge. In our case we will have a
seperate DSP for the audio. But that isn't ready yet (except in VHDL :-) ).
So untill then we cannot play audio and video without dropping frames.
However in the mean time we want to be able to play everything (for demo,
testing, etc.) in sync (!!!) even if this means dropping frames. However,
because of the explained bug, it will not drop frames at all in the
explained situation.

With all due respect even if YOU don't need the bugfix or fail to see a
need, respect other people in their efforts trying to fix bugs. That's the
foundation of open source ...

Regards,

Armin