Opened 13 years ago
Closed 10 years ago
#964 closed defect (fixed)
No h263 Mode B support?
Reported by: | Greg | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | h263 |
Cc: | silvo@gmx.net | Blocked By: | |
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
It appears that Mode B support for h263 is not supported?
I have a h263 over RTP stream dump from a commercial videophone that includes both Mode A and Mode B.
From this thread on ffmpeg-devel, I'm taking it that only Mode A was ever supported?
https://lists.libav.org/pipermail/ffmpeg-devel/2009-April/067074.html
I have tested the attached stream on four different commercial videophones. They all reproduce the video flawlessly. ffmpeg renders the Mode A packets, but simply prints out errors for the Mode B packets.
I am attaching three files:
demo.h263: The raw stream that is sent both to and from a videophone. H263 + RTP.
ffmpeg.out: The output from ffmpeg -i demo.h263 demo.mp4
demo.mp4: The ffmpeg-generated mp4 from the h263 stream. It seems that only the Mode A packets are interpreted by ffmpeg, so the video looks quite corrupted.
Sample error output from the attached+complete ffmpeg.out dump:
[h263 @ 0x7f86b083fc00] Bad picture start code
[h263 @ 0x7f86b083fc00] header damaged
[h263 @ 0x7f86b083fc00] I cbpy damaged at 20 0
[h263 @ 0x7f86b083fc00] Error at MB: 20
[h263 @ 0x7f86b083fc00] illegal ac vlc code at 0x14
[h263 @ 0x7f86b083fc00] Error at MB: 322
[h263 @ 0x7f86b083fc00] I cbpy damaged at 2 15
[h263 @ 0x7f86b083fc00] Error at MB: 347
[h263 @ 0x7f86b083fc00] I cbpy damaged at 1 5
[h263 @ 0x7f86b083fc00] Error at MB: 116
[h263 @ 0x7f86b083fc00] run overflow at 1x16 i:1
[h263 @ 0x7f86b083fc00] Error at MB: 369
[h263 @ 0x7f86b083fc00] illegal dc 128 at 0 5
[h263 @ 0x7f86b083fc00] run overflow at 1x5 i:1
[h263 @ 0x7f86b083fc00] Error at MB: 116
[h263 @ 0x7f86b083fc00] concealing 396 DC, 396 AC, 396 MV errors
Attachments (3)
Change History (9)
by , 13 years ago
by , 13 years ago
Attachment: | ffmpeg.out added |
---|
ffmpeg output while generating demo.mp4 from demo.h263
comment:1 by , 13 years ago
Keywords: | mode removed |
---|---|
Status: | new → open |
Version: | unspecified → git-master |
comment:2 by , 13 years ago
I would agree that Mode B support for h263 decoding is not supported. Does any one know the complexity of modifying ituh263dec.c to support this mode ?
comment:3 by , 12 years ago
Component: | undetermined → avcodec |
---|
comment:4 by , 10 years ago
Analyzed by developer: | set |
---|---|
Cc: | added |
Component: | avcodec → avformat |
Reproduced by developer: | set |
Confirmed: modes B + C are missing in the current parser code
comment:5 by , 10 years ago
Analyzed by developer: | unset |
---|
comment:6 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
The cmd line "ffmpeg -i demo.h263 demo.mp4" instructs ffmpeg to assume plain H.263 as input format (not H.263+RTP). Hence, the output of this conversion will always look corrupted.
The current RTP packetizer for H.263 also supports the desired additional modes. So, the ticket can be closed as "fixed".
demo.h263 - Raw H263 RTP stream containing both mode a and b.