GNOME Bugzilla – Bug 670255
media-factory-uri: payload mpeg-ts streams directly
Last modified: 2018-11-03 15:37:47 UTC
Created attachment 207823 [details] [review] Fixes the issue, making it possible to send muxed streams in payloads Currently instead of using the mpeg-ts payloader (rtpmp2tpay) to send the streams payloaded inside an mpeg-ts container, we demux it and send the various streams payloaded separately. We could just payload them as is inside the mpeg-ts container. This is also true for other container types that could be used directly as payloads. I am not really sure what the advantages of this behavior are in comparison with the current one but the described behavior makes more sense to me. Also we might want to let the user control this behavior?
The RTP RFC recommends sending audio and video streams on different ports so demuxing is preferable. I do agree that an option to enable sending muxed content would be good.
Sending a whole mpeg-ts program is *very* common (there's that standard board called DVB, which states it must be done like that, and all ISP/operators will do it that way). Note: I do agree the common way to do RTP is to split per elementary streams, but mpeg-ts is the exception :( Maybe the patch would be acceptable if it was special-casing mpeg-ts (instead of being generic to any containers).
Comment on attachment 207823 [details] [review] Fixes the issue, making it possible to send muxed streams in payloads Don't know what to do about this. I do think sending elementary streams is the right default behaviour. This might be one of those few cases where I'd advocate a new property ;) If we special-case formats, it should probably be MPEG-TS and ASF.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/1.