no padding bugs detection conflicts with mpeg4 stream which contains resync_markers

[anatoly]

Attached sample contains mpeg4 bitstream with resync_markers. This stream successfully decoded with Elecard Stream Eye and IPP decoders. FFmpeg reports following errors:
Input #0, m4v, from '/home/alien/tmp/02.mp4':

Duration: N/A, bitrate: N/A

Stream #0.0: Video: mpeg4, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 30k tbr, 1200k tbn, 30k tbc

[mpeg4 @ 0x21b4ce0] cbpc damaged at 3 30KB vq= 18KB sq= 0B f=0/0
[mpeg4 @ 0x21b4ce0] Error at MB: 2433
[mpeg4 @ 0x21b4ce0] concealing 2400 DC, 2400 AC, 2400 MV errors

0.84 A-V: 0.000 s:0.0 aq= 0KB vq= 0KB sq= 0B f=0/0 0/0

It looks like no padding bug detection conflicts with this stream.

[anatoly]

Sample stream

[anatoly]

Truncated version with 2 frames: I and P.

[anatoly]

I've made a patch with which sample file can be played fine.
Here it is:

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index f079557..5986f7c 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -225,7 +225,7 @@ static int decode_slice(MpegEncContext *s){
 //printf("%d %d %d %06X\n", s->mb_x, s->mb_y, s->gb.size*8 - get_bits_count(&s->gb), show_bits(&s->gb, 24));
                     ff_er_add_slice(s, s->resync_mb_x, s->resync_mb_y, s->mb_x, s->mb_y, (AC_END|DC_END|MV_END)&part_mask);
 
-                    s->padding_bug_score--;
+                    if (!s->resync_marker) s->padding_bug_score--;
 
                     if(++s->mb_x >= s->mb_width){
                         s->mb_x=0;
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 6b7b4bf..7cc30c2 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -113,7 +113,7 @@ static inline int mpeg4_is_resync(MpegEncContext *s){
     int bits_count= get_bits_count(&s->gb);
     int v= show_bits(&s->gb, 16);
 
-    if(s->workaround_bugs&FF_BUG_NO_PADDING){
+    if(s->workaround_bugs&FF_BUG_NO_PADDING && !s->resync_marker){
         return 0;
     }

This is just example patch not for review. Just to show the main problem.

[cehoyos]

Decoded stream looks very broken, works fine with mplayer -vc ffodivxvdpau

$ ffmpeg -i 01.mp4
ffmpeg version N-30996-gf925b24, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jun 24 2011 22:26:42 with gcc 2.95.3 20010315 (release)
  configuration: --cc=/usr/local/gcc-2.95.3/bin/gcc --disable-sse
  libavutil    51. 10. 0 / 51. 10. 0
  libavcodec   53.  7. 0 / 53.  7. 0
  libavformat  53.  4. 0 / 53.  4. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 23. 0 /  2. 23. 0
  libswscale    2.  0. 0 /  2.  0. 0
[m4v @ 0x8c82390] Estimating duration from bitrate, this may be inaccurate
Input #0, m4v, from '01.mp4':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: mpeg4, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 30k tbr, 1200k tbn, 30k tbc
At least one output file must be specified

[anatoly]

Replying to cehoyos:

Decoded stream looks very broken, works fine with mplayer -vc ffodivxvdpau

It's not very broken. Deep analysis of stream has shown that there is just a garbage between previous frame's end and next frame's start_code. Thus last slice of frame doesn't finished by start_code or resync_marker.
I think that this situation is just a kind of padding bug which is not covered by current implementation.
Besides, I can't understand why we can't just skip garbage bytes at the end of frame?

[cehoyos]

Replying to anatoly:

Replying to cehoyos:

Decoded stream looks very broken, works fine with mplayer -vc ffodivxvdpau

It's not very broken.

What I was trying to say was:
If attached stream is decoded with current libavcodec, the result looks very broken (as you said, that is why I set "Reproduced"), mplayer -vc ffodivxvdpau (and mplayer -vc xvid) play the sample fine.

Can you provide a tested patch?

[anatoly]

Replying to cehoyos:

Replying to anatoly:

Replying to cehoyos:

Decoded stream looks very broken, works fine with mplayer -vc ffodivxvdpau

It's not very broken.

What I was trying to say was:
If attached stream is decoded with current libavcodec, the result looks very broken (as you said, that is why I set "Reproduced"), mplayer -vc ffodivxvdpau (and mplayer -vc xvid) play the sample fine.

Can you provide a tested patch?

Yes, I can. I will post it on mailing list.

[michael]

Fixed locally