Opened 13 years ago

Closed 13 years ago

#302 closed defect (fixed)

no padding bugs detection conflicts with mpeg4 stream which contains resync_markers

Reported by: Anatoly Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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.

Attachments (2)

01.mp4 (2.3 MB ) - added by Anatoly 13 years ago.
Sample stream
02.mp4 (38.2 KB ) - added by Anatoly 13 years ago.
Truncated version with 2 frames: I and P.

Change History (8)

by Anatoly, 13 years ago

Attachment: 01.mp4 added

Sample stream

by Anatoly, 13 years ago

Attachment: 02.mp4 added

Truncated version with 2 frames: I and P.

comment:1 by Anatoly, 13 years ago

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.

comment:2 by Carl Eugen Hoyos, 13 years ago

Reproduced by developer: set
Status: newopen
Version: unspecifiedgit-master

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

in reply to:  2 ; comment:3 by Anatoly, 13 years ago

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?

in reply to:  3 ; comment:4 by Carl Eugen Hoyos, 13 years ago

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?

in reply to:  4 comment:5 by Anatoly, 13 years ago

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.

comment:6 by Michael Niedermayer, 13 years ago

Resolution: fixed
Status: openclosed

Fixed locally

Note: See TracTickets for help on using tickets.