GNOME Bugzilla – Bug 647821
encodebin: problem with asf/asfmux caps
Last modified: 2018-11-03 11:18:45 UTC
Noticed today that in order to enable transcoding to windows media/asf with Transmageddon I need to not only create containerprofile for encodebin that is set to video/x-ms-asf, but to "video/x-ms-asf, parsed=true". (This is with parsers enabled in encodebin.c). I assume it should be able to figure this out without me added parsed=true to the caps?
asfmux has parsed=true on the srcpad. I don't think that makes sense but encodebin could also try to do something better here... "video/x-ms-asf" and "video/x-ms-asf, parsed=true" can be intersected and that should be all the is important to encodebin.
Encodebin always looks for an exact match at the moment. For qtmux we've added video/quicktime and video/quicktime, variant=xyz to the template caps (to support what's described below). However, I think the solution is to make encodebin a bit smarter here, for the following reason: to support transmuxing/transcoding into the same container, an application might want to / need to set the container caps to encode to from the typefind/discoverer caps. These are either video/x-ms-asf (currently) or video/x-ms-asf,parsed=false (more correct if we start with parsed fields on asf caps). Now, video/x-ms-asf,parsed=false is not something asfmux will ever output, so encodebin needs to be smarter about these things.
Is this something that would be simpler to fix in 0.11?
Is this fixable on 1.0 or should I just close this bug?
I think it can be fixed, just needs someone to sit down and do the work
-- 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-plugins-base/issues/47.