From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-05-31 16:09:48
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D343519 GStreamer | gst-plugins-ugly | Ver: 0.10.3 Summary: [rmdemux] Stripped valuable data for decoding? Product: GStreamer Version: 0.10.3 Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: gst-plugins-ugly AssignedTo: gst...@li... ReportedBy: moz...@ya... QAContact: gst...@li... GNOME version: Unspecified GNOME milestone: Unspecified Please describe the problem: It seems that the packet data in gst_rmdemux_parse_packet() was stripped = before passing to the pad.=20 In Mplayer, libmpcodecs/vd_realvid.c, decode() shows that the header is a= lso 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=3D(dp_hdr_t*)data; unsigned char* dp_data=3D((unsigned char*)data)+sizeof(dp_hdr_t); uint32_t* extra=3D(uint32_t*)(((char*)data)+dp_hdr->chunktab); unsigned char* buffer; unsigned int transform_out[5]; transform_in_t transform_in=3D{ dp_hdr->len, // length of the packet (sub-packets appe= nded) 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 th= e stream) }; .... result=3D(*rvyuv_transform)(dp_data, buffer, &transform_i= n, transform_out, sh->context); Steps to reproduce: 1.=20 2.=20 3.=20 Actual results: Expected results: Maybe the packet header should be passed along in some cap field. Since o= ther demux also handle realmedia codec (like matroska demuxer), what's the pro= per 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: --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-05-31 16:29:09
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D343519 GStreamer | gst-plugins-ugly | Ver: 0.10.3 ------- Comment #1 from Bug flys 2006-05-31 16:29 UTC ------- 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=3D1.80&view=3Dmarkup --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-07-28 18:38:18
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D343519 GStreamer | gst-plugins-ugly | Ver: 0.10.3 Tim-Philipp M=C3=BCller changed: What |Removed |Added -------------------------------------------------------------------------= --- Status|UNCONFIRMED |NEEDINFO ------- Comment #2 from Tim-Philipp M=C3=BCller 2006-07-28 18:38 UTC ---= ---- Could you point us to a file/stream where this seems to be a problem? Or make a patch that fixes it? --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-10-06 08:59:21
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D343519 GStreamer | gst-plugins-ugly | Ver: 0.10.3 Andre Klapper changed: What |Removed |Added -------------------------------------------------------------------------= --- CC| |a90...@gm... ------- Comment #3 from Andre Klapper 2006-10-06 08:59 UTC ------- Bug flys: Can you please answer Tim-Philipp's questions? Thanks in advanc= e. --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-10-07 01:09:10
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D343519 GStreamer | gst-plugins-ugly | Ver: 0.10.3 Bug flys changed: What |Removed |Added -------------------------------------------------------------------------= --- Status|NEEDINFO |UNCONFIRMED ------- Comment #4 from Bug flys 2006-10-07 01:09 UTC ------- It's more of a question than a pointers. I tried to wrote a pitdll like p= lugin 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/rm= demux.c?revision=3D1.76&view=3Dmarkup&sortby=3Drev I saw in function gst_rmdemux_parse_packet() some comment on "/* skip oth= er stuff */", and that's why I asked. Because both mplayer and libxine did s= ome 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 ou= t from both libxine and gst rmdemux. See if there are some different. I saw some= one else is currently working on a realvideo decoder in another gst bug repor= t. Hopefully, he's effort will success.=20 --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2007-12-04 16:51:53
|
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=343519 GStreamer | gst-plugins-ugly | Ver: HEAD CVS Edward Hervey changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bi...@bi... Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Summary|[rmdemux] Stripped valuable |[rmdemux] Expose full MDPR |data for decoding? |buffer in stream caps Version|0.10.3 |HEAD CVS ------- Comment #5 from Edward Hervey 2007-12-04 16:51 UTC ------- 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. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=343519. |
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2008-11-03 12:08:54
|
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=343519 GStreamer | gst-plugins-ugly | Ver: HEAD CVS Wim Taymans changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wim...@gm... Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #6 from Wim Taymans 2008-11-03 12:08 UTC ------- 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. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=343519. |