pbutils: Allow getting descriptions for unfixed caps

Submitted by Vincent Penquerc'h @vincent

Link to original bug (#703378)

Description

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.

Vincent Penquerc'h @vincent said:

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).

Vincent Penquerc'h @vincent submitted a patch:

This proposed patch avoids the false positives discussed on IRC.

Patch 248132, "Better way to tell":
0001-pbutils-better-way-to-tell-if-two-caps-represent-the.patch

Sebastian Dröge @slomo said:

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?

Tim Müller @tpm said:

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.

Vincent Penquerc'h @vincent said:

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.

Vincent Penquerc'h @vincent said:

One of the container restrictions I get is:

application/x-3gp; video/quicktime, variant=(string)iso

Vincent Penquerc'h @vincent said:

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).

Sebastian Dröge @slomo said:

(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?

Sebastian Dröge @slomo said:

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.

Tim Müller @tpm said:

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.

Sebastian Dröge @slomo said:

ok, reverted for now then. Let's find a good solution now without the "blocker"-pressure :)

commit 1c4af723
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

Sebastian Dröge @slomo said:

So, what exactly is the problem that we want to solve here?

Tim Müller @tpm closed a related bug:

*** Bug 758308 has been marked as a duplicate of this bug. ***

Uraeus@linuxrising.org said:

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.

Edward Hervey @bilboed said:

Still valid, would be good to have a small "test" for this (like something which shows the description of all caps of all elements ?)

mentioned in issue #552

mentioned in merge request !160 (merged)

added Base Plugins labels