GNOME Bugzilla – Bug 651543
[encodebin] doesn't work with mpegts
Last modified: 2011-06-01 14:27:36 UTC
Created attachment 188930 [details] simple python app showing issue Attached testcase shows that encodebin seems to refuse to run when mpegts is set as the container format. The same code works fine if I replace the container and codecs with asf or ogg for instance.
Could someone knowledgeable in encodebin triage this bug to find out what is broken in mpegtsmux? (I make assumptions, but...)
Did a GST_Debug log and found this: encodebin gstencodebin.c:1606:create_elements_and_pads:<encodebin0>^[[00m error: No available muxer for format video/mpegts, systemstream=(boolean)true 0:00:08.549977559 ^[[334m 1917^[[00m 0x89d8800 ^[[36mDEBUG ^[[00m ^[[00;01;37;41m GST_MESSAGE gstelement.c:1900:gst_element_message_full:<encodebin0>^[[00m start Checking gst-inspect on mpegtsmux I don't see why it gets that response: SRC template: 'src' Availability: Always Capabilities: video/mpegts systemstream: true packetsize: { 188, 192 }
> No available muxer for format video/mpegts, systemstream=(boolean)true > > Checking gst-inspect on mpegtsmux I don't see why it gets that response: > Capabilities: video/mpegts, systemstream=true, packetsize={ 188, 192 } Does it work if you add a packetsize field?
Just tested, adding a packetsize field makes it work, but I assume that is not the 'correct' fix?
I think that is the correct fix. You need to specify complete caps. If the packetsize field is in the template caps, it's required.
Ok, I agree that the severity of the bug is less, but this to me is not just about work/not work, but the API of encodebin. To me it seems natural that the minimum API of encodebin is the minimum needed to identify the muxer needed and everything else is optional data in case you are not happy to use the default. The packetsize value is of course not part of the minimum required to identify the mpegts container format, ideally I should have been able to create a encodebin by just using "video/mpegts" as the caps, as that already provides us with the minimum needed to know which muxer to plug, at least until we get around to adding variants to the caps.