[FFmpeg-devel] [PATCH] "Fix" rm muxer
Sun Dec 2 18:47:14 CET 2007
On Mon, 19 Nov 2007 00:40:29 +0100
Roberto Togni <rxt at rtogni.it> wrote:
> Hi all
> 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
> same time.
> 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
> regression tests.
> 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
> back-compatibility hacks.
> 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.
More information about the ffmpeg-devel