After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 594393 - multipartdemux: Add GStreamer extension to include the caps in the multipart output
multipartdemux: Add GStreamer extension to include the caps in the multipart ...
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-07 16:57 UTC by Marc-Andre Lureau
Modified: 2016-04-11 10:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
multipartdemux: set default rate/channel for x-mulaw (828 bytes, patch)
2009-09-07 16:57 UTC, Marc-Andre Lureau
rejected Details | Review

Description Marc-Andre Lureau 2009-09-07 16:57:25 UTC
Created attachment 142632 [details] [review]
multipartdemux: set default rate/channel for x-mulaw

the following patch fixes the non-negotiated error due to missing rate/channel
on src pad.

gst-launch audiotestsrc ! mulawenc ! multipartmux ! multipartdemux ! mulawdec !
fakesink

I am not sure if this is the proper fix, though.
Comment 1 Sebastian Dröge (slomo) 2009-09-08 13:47:34 UTC
And what if mulawdec uses a different samplerate? :)

I guess a better fix would be to somehow include the rate/channel information in the multipartmux output and read it again from multipartdemux instead of adding random rate/channel values.
Comment 2 Marc-Andre Lureau 2009-09-08 14:04:49 UTC
(In reply to comment #1)
> I guess a better fix would be to somehow include the rate/channel information
> in the multipartmux output and read it again from multipartdemux instead of
> adding random rate/channel values.

Yes. I wonder what are the limitations of multipart to not put the whole caps in there. Who would know about that?
Comment 3 Sebastian Dröge (slomo) 2009-09-08 14:18:24 UTC
I guess Wim knows details :)
Comment 4 Wim Taymans 2009-09-08 14:33:53 UTC
RFC 2046 defines audio/basic as mulaw 8000Hz, mono. Anything else is undefined AFAIK.

The multipart muxer/demuxer will correctly convert mulaw 8KHz mono to and from audio/basic.

In the above pipeline, 44100Hz mulaw is muxed as multipart. Since there is no way to encode this inside multipart, the demuxer cannot reconstruct the 44100Hz samplerate nor the number of channels.
Comment 5 Marc-Andre Lureau 2009-09-08 14:42:11 UTC
(In reply to comment #4)
> RFC 2046 defines audio/basic as mulaw 8000Hz, mono. Anything else is undefined
> AFAIK.
> 
> The multipart muxer/demuxer will correctly convert mulaw 8KHz mono to and from
> audio/basic.
> 
> In the above pipeline, 44100Hz mulaw is muxed as multipart. Since there is no
> way to encode this inside multipart, the demuxer cannot reconstruct the 44100Hz
> samplerate nor the number of channels.

so we are left with that. Should we close that bug as invalid?

Do you think there is any chance we could put gst caps in multipart headers? (as X- extension) so that gstreamer would be able to handle it correctly?
Comment 6 Wim Taymans 2009-09-08 14:48:42 UTC
I think we could indeed make an extension, something like:

  application/x-gstreamer; caps=<base64 of caps>

or something. When there is not proper mapping from the caps to a MIME type we could use this as a fallback.
Comment 7 Sebastian Dröge (slomo) 2009-09-08 14:52:48 UTC
Ok, then let's reopen this bug for that gstreamer extension.
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2011-03-02 18:24:12 UTC
Comment on attachment 142632 [details] [review]
multipartdemux: set default rate/channel for x-mulaw

Marc-Anfre, wanna go for the new approach?
Comment 9 Tim-Philipp Müller 2016-04-11 10:40:21 UTC
Seems not. Let's close this then.