GNOME Bugzilla – Bug 594393
multipartdemux: Add GStreamer extension to include the caps in the multipart output
Last modified: 2016-04-11 10:40:21 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.
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.
(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?
I guess Wim knows details :)
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.
(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?
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.
Ok, then let's reopen this bug for that gstreamer extension.
Comment on attachment 142632 [details] [review] multipartdemux: set default rate/channel for x-mulaw Marc-Anfre, wanna go for the new approach?
Seems not. Let's close this then.