That probably happens because qtmux and gppmux both have a rank of primary and qtmux can output video/quicktime without any variant at all (which would satisfy the variant=3gpp constraint)

> That probably happens because qtmux and gppmux both have a rank of primary and
> qtmux can output video/quicktime without any variant at all (which would
> satisfy the variant=3gpp constraint)

Then encodebin behaviour has changed, it uses to look for an exact match, not a subset/intersection.

(PS: not saying that that's what it should be doing, also see bug #647821)

for completness sake I just tested with isomp4 format and same happens there, it defaults to quicktime

Anyone got an ideas what needs to be the solution for this bug?

> Anyone got an ideas what needs to be the solution for this bug?

A small test case might help move this along..

Created attachment 192198 [details]
Simple testcase, doesn't EOS properly, but generates a proper file showing the issue

Testcase added, it is supposed to create a mp4 iso file, but instead ends up creating a Apple quicktime file.

(In reply to comment #1)
> That probably happens because qtmux and gppmux both have a rank of primary and
> qtmux can output video/quicktime without any variant at all (which would
> satisfy the variant=3gpp constraint)

Yes, this is the issue. gst_caps_is_subset / gst_caps_can_intersect are the options to list the elements from a certain caps. _is_subset is currently used and qtmux will always match.

The related bug on why this variant-less entry was added: https://bugzilla.gnome.org/show_bug.cgi?id=642879

Copying Tims response over from 642879 as it contains a suggestion for how to fix this bug (without reverting the fix from that bug)

> Shouldn't the fix for this issue be to update the typefinders to always
> generate a variant?

Not sure that's possible.

Another fix would be to give qtmux lower priority, so that encodebin tries the
non-generic muxers first.

However, I think maybe encodebin should first try to find an exact match and
only then settle for a subset match.

Created attachment 193217 [details] [review]
encodebin: Select muxer further

Sort muxers based on their caps and ranking before iterating to
find one that fits the profile.

Sorting is done by putting the elements that have a pad template
that can produce the exact caps that is on the profile. For example:
when asking for "video/quicktime, variant=iso", muxers that
have this exact caps on their pad templates will be put first on
the list than ones that have only "video/quicktime".

This patch applies on top of the patches of https://bugzilla.gnome.org/show_bug.cgi?id=650652

I'm not entirely happy with the algorith that orders tha muxers, but it is enough
for the 'variant' problem. Maybe someone has a better and more generic caps comparison
algorith.

Created attachment 193640 [details] [review]
encodebin: Select muxer further

Updated patch to not depend on the patches from
the encodebin not plugging parsers bug.

This works and Tim has a patch adding a unit test for it.

Currently, the muxers are sorted based on gst_caps_is_equal, if
it results true, the muxer goes to the beginning of the list, otherwise
it goes to the back.

The question is: is gst_caps_is_equal a good way of comparing caps here?
Or should we write another function?

Maybe iterating over the format caps structures and looking for a fully
compatible one on the muxers pad, if this results in true, the muxer
goes to the beginning of the list.

Any comments, or another ideas?

Edward or Tim, is this patch ready to be merged?

Created attachment 194439 [details] [review]
encodebin: Select muxer further

Updated patch that doesn't rely on gst_caps_is_equal

fixed by commit 2768ed75e099dac907528e13f4f7ef5a035b651a