Opened 14 years ago
Closed 14 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)
Change History (8)
by , 14 years ago
comment:1 by , 14 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.
follow-up: 3 comment:2 by , 14 years ago
Reproduced by developer: | set |
---|---|
Status: | new → open |
Version: | unspecified → git-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
follow-up: 4 comment:3 by , 14 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?
follow-up: 5 comment:4 by , 14 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?
comment:5 by , 14 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.
Sample stream