GNOME Bugzilla – Bug 703378
pbutils: Allow getting descriptions for unfixed caps
Last modified: 2018-11-03 11:25:50 UTC
I pushed this patch: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=065f1603b0f1d2adc8477bf1f3ebe2b154885d89 The intent is to allow describing non fixed caps if they represent the same format, but as others pointed out, a single media type may represent different formats (eg, audio/mpeg). So this patch is too loose. Filing so the patch may be reverted if no good solution can be found. For context, my test case is getting caps from gupnp-dlna restrictions. These are not fixed, and I pass them as profiles to encodebin. If encodebin can not find elements to satisfy the profile, those caps will be passed through the description/missing-plugin code.
One possible way out would be to provisionally accept multi-structure caps, describe each structure separately, and then error out if the descriptions differ (ie, for the audio/mpeg type cases).
Created attachment 248132 [details] [review] Better way to tell This proposed patch avoids the false positives discussed on IRC.
I'm not sure if that makes more sense. "application/3gpp" and "application/quicktime" can both have a different description but are arguably the same. I guess it still depends on what exactly you're trying to do and how you expect stuff to work :) Can you explain a bit more what the problem is you're trying to solve and how it should work?
Do you get "application/3gpp; application/quicktime" to describe one particular dlna profile? That's surprising (to me). The difference is that 3gpp has restrictions what can be inside that container in multiple ways (codecs, etc.), so I would've thought the dlna profiles are specific enough to know which one it is.
I am getting DLNA profiles from libgupnp-dlna. These come with restrictions for audio, video, and muxer. I want to create encodebin profiles for those, so I can transcode an input source to something that matches the DLNA profile. However, the restrictions I get from libgupnp-dlna aren't always "simple". Some have more than one structure, usually with the same format but different resolutions, etc. Those caps are usually not fixed: they contain some amount of leeway in things like bitrate, etc. It depends on the particular profile. When encodebin can find elements to build a pipeline that can transcode to those caps, all is fine. However, when it cannot, it will try to describe the caps to post a message. This is when the code I patched really wants a fixed caps, and asserts when it gets a non fixed one. However, since it is possible to provide such a description of the caps in some cases where we get non fixed caps (eg, when all structures in the caps describe the same format), these patches do this. Maybe they will miss some cases, but surely it's better than just asserting. If any case is missed, the assert will be here as before.
One of the container restrictions I get is: application/x-3gp; video/quicktime, variant=(string)iso
Oh, and this is for the container: the DLNA profile also includes restrictions for audio and video. All the cases with application/x-3gp; video/quicktime, variant=(string)iso for container have audio/AMR for audio (and nothing for video).
(In reply to comment #5) > However, the restrictions I get from libgupnp-dlna aren't always "simple". Some > have more than one structure, usually with the same format but different > resolutions, etc. Those caps are usually not fixed: they contain some amount of > leeway in things like bitrate, etc. It depends on the particular profile. Things like resolution restrictions should be placed into constraints of the encoding profile though, most probably making these caps fixed again. > When encodebin can find elements to build a pipeline that can transcode to > those caps, all is fine. What is encodebin doing then? Taking the first, highest ranked element that somehow matches the caps? > However, since it is possible to provide such a description of the caps in some > cases where we get non fixed caps (eg, when all structures in the caps describe > the same format), these patches do this. Maybe they will miss some cases, but > surely it's better than just asserting. If any case is missed, the assert will > be here as before. Maybe encodebin should expand the caps to simple caps and then pass them to the missing-plugin code instead? That way there would be multiple missing plugin messages though. Alternatively, maybe allowing non-fixed caps for the missing plugin messages makes sense?
So what's going to happen here? This must be fixed before 1.2.0, if nothing else is decided we must revert the original patch.
I don't know. I think I'd like to revert this for now. We may also want to return different descriptions for things like 3GP and MP4 in future.
ok, reverted for now then. Let's find a good solution now without the "blocker"-pressure :) commit 1c4af723a32fdfacaab884bff0d0c46b70072d2c Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Aug 19 10:39:19 2013 +0200 Revert "pbutils: allow describing unfixed caps if they share the same media This reverts commit 065f1603b0f1d2adc8477bf1f3ebe2b154885d89. This is not considered the correct solution, see: https://bugzilla.gnome.org/show_bug.cgi?id=703378
So, what exactly is the problem that we want to solve here?
*** Bug 758308 has been marked as a duplicate of this bug. ***
In my case here (testcase attached 758308) there was no encodebin involved. It was just me iterating on a return of all installed plugins and wanting a plaintext description of it. I think its the libva VP8 plugin in this case causing problems.
Still valid, would be good to have a small "test" for this (like something which shows the description of all caps of all elements ?)
-- 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/88.