[MPlayer-users] Bugreport and proposed fix: XviD sync-bug

[D Richard Felker III]

On Fri, May 23, 2003 at 10:18:40AM +0200, armin.gerritsen at philips.com wrote:
> So here I go in my final attempt. I hope I'll be clearer now.

I doubt it's the final... :)

> [1]  This first bug is the simple fact that -hardframedrop doesn't add
> anything.
> 
> At line 615 of h263dec.c one sees the hurry_up value must be 5 in order to
> start dropping any non-B frames. However using -hardframedrop only makes
> hurry_up equal to 2. So in every case where the normal -framedrop option is
> not enough, -hardframedrop will never help.

Yes this is a bug. Report it to ffmpeg-devel since it's a lavc issue,
not MPlayer. Better yet, send a patch (cvs diff -u).

> [2]  But there is more. A bug exists that causes that on platforms with lack
> of CPU horsepower playing certain XviD (or DivX or anything else played with
> h263dec.c !) content without B-frames, you'll loose A/V-synchronisation.
> With XviD/DivX/MPEG/etc content it is 100% legal to have no B-frames. And
> this may be less rare than you may think.
> 
> Since -framedrop will only drop B-frames, this will never drop anything for
> such content.

That's the intention. -framedrop drops frames that can be dropped
without causing prediction errors (i.e. only B frames) AND causes
MPlayer to skip filter chain/display. If this is not enough for you,
use -hardframedrop and prepare for corruption.

> So, if we don't fix the first bug, we'll always get out of sync with such
> content if our CPU isn't fast enough, even with -hardframedrop. Even if our
> system is only too slow for bit or only for very short period of time!
> 
> But if we do fix the first bug, we'll stay in sync but get serious image
> corruption.
> 
> So this leaves these people with two options: out of sync or serious
> corruption. Not very nice I would say.
> 
> There is a third option: stay in sync, have no corruption, but at the
> expense of dropping more frames.
> Instead of fixing line 615, simply replace it with:
> 
> 
> if ( (1 < s->hurry_up) && (s->pict_type != I_TYPE) )
> {
>  // If we drop a P-frame, we must drop all other B/P's too,
>  // in order to prevent serious image-corruption ... ;-(
>  //if ( s->pict_type == P_TYPE ) // We know it is P.
>   must_flush_non_I_frames = 1 ;
>  return get_consumed_bytes( s, buf_size ) ;
> }

No, this is idiotic and will not accomplish anything useful. Dropping
15 seconds of video is nonsense!!! (Typical distance between
keyframes.) I see no reason such a horrible hack should be made to
lavc just to accomodate your very strange case. Instead, patch the
code on your end.

BTW, one other option, if you can do it, would be to drop just 1 or 2
P frames before the next I frame, but that would require reading the
stream into the future which is probably not an option.

> [3]  The third bug is a very tiny one. I only mention it to be complete and
> because I found it by accident. It is in vd_ffmpeg.c. Dropping frames can be
> done in three ways: drop decoding, drop dithering or drop output. Not all
> make sense of course (like dithering, when not outputting).
> 
> Point is that vd_ffmpeg doesn't provide all options. It never drops
> dithering. This may be useful when there is the need to drop an I-frame or
> P-frame, which is decoded (because other frames depend on it) but cannot
> be displayed because we need to drop frames in order to remain A/V sync.

Dithering? WTF are you talking about??

I agree there may be a bug here, but you're talking nonsense...


Rich