GNOME Bugzilla – Bug 343519
[rmdemux] Expose full MDPR buffer in stream caps
Last modified: 2008-11-03 12:08:42 UTC
Please describe the problem: It seems that the packet data in gst_rmdemux_parse_packet() was stripped before passing to the pad. In Mplayer, libmpcodecs/vd_realvid.c, decode() shows that the header is also needed to prepor decode realvideo codec: // copypaste from demux_real.c - it should match to get it working! typedef struct dp_hdr_s { uint32_t chunks; // number of chunks uint32_t timestamp; // timestamp from packet header uint32_t len; // length of actual data uint32_t chunktab; // offset to chunk offset array } dp_hdr_t; // decode a frame static mp_image_t* decode(sh_video_t *sh,void* data,int len,int flags){ mp_image_t* mpi; unsigned long result; dp_hdr_t* dp_hdr=(dp_hdr_t*)data; unsigned char* dp_data=((unsigned char*)data)+sizeof(dp_hdr_t); uint32_t* extra=(uint32_t*)(((char*)data)+dp_hdr->chunktab); unsigned char* buffer; unsigned int transform_out[5]; transform_in_t transform_in={ dp_hdr->len, // length of the packet (sub-packets appended) 0, // unknown, seems to be unused dp_hdr->chunks, // number of sub-packets - 1 extra, // table of sub-packet offsets 0, // unknown, seems to be unused dp_hdr->timestamp,// timestamp (the integer value from the stream) }; .... result=(*rvyuv_transform)(dp_data, buffer, &transform_in, transform_out, sh->context); Steps to reproduce: 1. 2. 3. Actual results: Expected results: Maybe the packet header should be passed along in some cap field. Since other demux also handle realmedia codec (like matroska demuxer), what's the proper way to unify all the demuxers? matroska demuxer has other problems like don't pass along 'format' and 'subformat' and codec_data to _setcap. Does this happen every time? Other information:
This is how xine does the decode in realdec_decode_data(): http://xine.cvs.sourceforge.net/xine/xine-lib/src/libreal/xine_decoder.c?revision=1.80&view=markup
Could you point us to a file/stream where this seems to be a problem? Or make a patch that fixes it?
Bug flys: Can you please answer Tim-Philipp's questions? Thanks in advance.
It's more of a question than a pointers. I tried to wrote a pitdll like plugin for realvideo. And then when I tried to feed the buffer to the realvideo's decoder (dload from .so), I got a coredump. And I stopped digging deeper by then. The data buffer was coming from the rmdemux at: http://cvsweb.freedesktop.org/gstreamer/gst-plugins-ugly/gst/realmedia/rmdemux.c?revision=1.76&view=markup&sortby=rev I saw in function gst_rmdemux_parse_packet() some comment on "/* skip other stuff */", and that's why I asked. Because both mplayer and libxine did some preliminary process on the data header before passing rest of the data to the decoder. To really solve the problem, we need to compare the data buffer passed out from both libxine and gst rmdemux. See if there are some different. I saw someone else is currently working on a realvideo decoder in another gst bug report. Hopefully, he's effort will success.
The realvideo/realaudio plugins (gst-plugins-bad/gst/real/ in cvs) work fine with the codec_data that rmdemux exposes on the pads. And those wrap the official Real .so codecs. So somehow... I doubt you need anything else to be exposed for decoding. ON THE OTHER HAND, I was doing some transcoding tests a few days back from .rm to .mkv (without changing the codecs), and we indeed need to pass a good chunck of the 'MDPR' stream header in the caps so the matroska muxer can create files that can be read by any other implementation.
If this is about the slice offsets, we pass those in the buffer data as the first N bytes. see realvideodec.c for how this is passed to the decoder. Maybe matroska also needs to parse this better. Please reopen if this is not enough.