GNOME Bugzilla – Bug 330681
[real] RV20 video garbled
Last modified: 2010-02-04 12:29:41 UTC
Trying to play various Real Video files in Totem I don't get any errors reported, while the files never starts playing. This is using rmdemux and ffmpeg.
Any file in particular? I get 'You don't have the necessary decoders installed' errors for each and every .rm file I try. Also, just to make sure: are you using an up-to-date rmdemux from after this commit: 2006-02-04 Tim-Philipp Müller <tim at centricular dot net> * gst/realmedia/rmdemux.c: (gst_rmdemux_add_stream): One source pad not being linked is not an error condition when we're still parsing the header. In this case (e.g. where we don't have a suitable decoder installed) just pretend everything is fine, so that the demuxer will actually go on to signal no-more-pads when done parsing the header, otherwise decodebin/playbin will never post the appropriate error message if decoders are not available. ?
Try downloading these two files: http://www.linuxrising.org/files/journal1215180405.rm http://www.linuxrising.org/files/journal0630200405.rm
With both, I get a trizillion ERROR (0x81de0c8 - 0:00:01.477583000) ffmpeg( 6512) (0):: HEADER ERROR errors and at some point, usually after a few seconds, a segfault.
These files play now that cook audio de-scrambling has been added, at least sort-of: audio is fine, but video is completely screwed up (same in mplayer though). xine manages to play the video just fine, however. Oh well, at least it doesn't crash any longer. Maybe there's something we're not extracting properly somewhere (possibly related to bug #343519?)
Does someone still have files to reproduce this? The above URLs are invalid now...
Yes, I still have the files, and it still fails in the same way (using ffmpeg decoders). Still crashes at times, actually. In valgrind I get a few of these: /playbin0/decodebin0/ffdec_rv200.sink: caps = video/x-pn-realvideo, rmversion=(int)2, format=(int)538980354, subformat=(int)17078328, width=(int)720, height=(int)576, framerate=(fraction)25/1, codec_data=(buffer)01049838202030025a905a4840343024 /playbin0/decodebin0/ffdec_rv200.src: caps = video/x-raw-yuv, width=(int)720, height=(int)576, framerate=(fraction)25/1, format=(fourcc)I420 ==9027== ==9027== Thread 4: ==9027== Invalid read of size 1 ==9027== at 0x4C23814: memcpy (mc_replace_strmem.c:406) ==9027== by 0x8CD6E50: ff_img_copy_plane (imgconvert.c:838) ==9027== by 0x8CD6F10: av_picture_copy (imgconvert.c:904) ==9027== by 0x8CDF85C: sws_scale (imgresample.c:682) ==9027== by 0x8C55AED: gst_ffmpeg_img_convert (gstffmpegcodecmap.c:3311) ==9027== by 0x8C61B90: gst_ffmpegdec_frame (gstffmpegdec.c:1348) ==9027== by 0x8C6381C: gst_ffmpegdec_chain (gstffmpegdec.c:2240) ==9027== by 0x4E7C058: gst_pad_chain_unchecked (gstpad.c:3552) ==9027== by 0x4E7C666: gst_pad_push (gstpad.c:3720) ==9027== by 0x74A1D9C: gst_queue_loop (gstqueue.c:1028) ==9027== by 0x4E965EC: gst_task_func (gsttask.c:192) ==9027== by 0x598B448: (within /usr/lib/libglib-2.0.so.0.1400.1) ==9027== Address 0x1051DB1F is 1 bytes before a block of size 32,016 alloc'd ==9027== at 0x4C20E3D: memalign (vg_replace_malloc.c:332) ==9027== by 0x8CDE1A6: avcodec_default_get_buffer (utils.c:313) ==9027== by 0x8C65788: gst_ffmpegdec_get_buffer (gstffmpegdec.c:856) ==9027== by 0x8DF57AB: alloc_picture (mpegvideo.c:180) ==9027== by 0x8DF5C3D: MPV_frame_start (mpegvideo.c:881) ==9027== by 0x8ED08FB: rv10_decode_frame (rv10.c:634) ==9027== by 0x8CDD102: avcodec_decode_video (utils.c:945) ==9027== by 0x8C616D3: gst_ffmpegdec_frame (gstffmpegdec.c:1458) ==9027== by 0x8C6381C: gst_ffmpegdec_chain (gstffmpegdec.c:2240) ==9027== by 0x4E7C058: gst_pad_chain_unchecked (gstpad.c:3552) ==9027== by 0x4E7C666: gst_pad_push (gstpad.c:3720) ==9027== by 0x74A1D9C: gst_queue_loop (gstqueue.c:1028) ==9027== (and then valgrind aborts with SIGILL because it doesn't handle some op in ff_imdct_calc_3dn2). The files are ca. 45MB, I can make them available if needed.
Question from comment #5 has been answered, thus reopening.
Tim, if you still have those files, could you try them again ? There's been a truckload of improvements in the ffmpeg decoders.
Ping....?
Still broken. Here's one of the files: http://people.freedesktop.org/~tpm/journal0630200405.rm mplayer plays it (with many ffmpeg warnings, but still), so it's probably something in rmdemux or gst-ffmpeg.
care to put a file online again?
http://people.freedesktop.org/~tpm/samples/rm/journal0630200405.rm
After this patch, this clip plays perfectly with git everything. commit 14e8ce8816c037d99d10f8a45e3400522b21b44c Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Feb 4 13:26:16 2010 +0100 ffmpegdec: only clip to a smaller region When we have an input width/height that should be used for clipping, only perform the clipping if the rectangle is smaller than the actual picture size. Fixes #330681