[FFmpeg-devel] [PATCH] "Fix" rm muxer
Mon Nov 19 00:40:29 CET 2007
I'm looking int a minimal fix for the rm muxer, so that we can revert
r10892 that breaks normal real files with frames bigger than 0x3fff
The woraround in r10892 is no longer needed to prevent crashing the
demuxer (that was fixed in r11040); but without fixing the muxer I
can't revert it, else the regression tests are broken.
In the current configuration, the video files created by the rm muxer (i
tried the files from the regression tests, a-rv10.rm a-rv20.rm
b-libav.rm; there is also a-ac3.rm that is audio-only) are unplayable
by rp8, by a recent rp from the helix project and by MPlayer. ffplay
plays them as long as the real demuxer is broken.
The audio-only file sounds bad in rp 8, but it's ok in MPlayer and
It's not possible to test audio in helix realplayer since Real decided
that dnet is obsolete and no longer supported (same for 14_4 and 28_8
The attached patch (by kostya) fix most of the problems, and
create files that are correct based on what we know about rmf format.
The patch is for test only, I'll clean it up and split when committing.
Results are (about demuxer, see below for other problems):
- rp from helix plays a-rv10 and a-rv20 ok
- rp8 plays a-rv10 and a-rv20 ok with a freeze at the beginning, b-libav
has audio artifacts
- mplayer and ffplay (with r10892 reverted) play all the files correctly
Reverting r10892 will obviously break the playback of the files created
by the unfixed muxer, but since they can't be played even by the
official player and nobody ever complained I guess that it's ok to drop
them. The only other solution is to add some code to detect rm files
created by ffmpeg before the muxer fix, and enable a workaround to
play them; it's not possible to support good and broken syntax at the
There are other problems that I discovered while checking this issue:
- audio only rm files are broken in realplayer. I have no idea when
this happened, the files works ok in MPlayer and ffmpeg. I don't
remember any change in the audio part of the muxer, did anything
changed in the way ac3 is encoded? packet fragmentation maybe?
- rv20 encoded files have artifacts on realplayer, and the same can be
reproduced with MPlayer using the binary codec. The artifacts are green
areas and seem related to motion compensation at the edges of the
frame, and are clearly visible in the rotozoom files created by the
All this broken things with no single complaint makes me think that
nobody is using the real muxer, and we can just fix it without
So if nobody complain I will commit the fix to the muxer, revert r10892
and update the regression test checksum in a few days.
Better is the enemy of good enough.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7409 bytes
Desc: not available
More information about the ffmpeg-devel