GNOME Bugzilla – Bug 642879
qtmux: add a 'variant' with the bare video/quicktime media type
Last modified: 2011-08-02 10:16:53 UTC
This will allow encodebin to select it when using a profile with video set to video/quicktime, as can happen if this profile is generated from a typefind result, which may or may not have set a variant.
Created attachment 181466 [details] [review] qtmux: add a 'variant' with the bare video/quicktime media type
Are you planning to add support to the QT-specific metadata? I don't see the advantage of using a particular FTYP if, at the end, metadata is still the good old ISO/mp4
I am not. The intent of the patch is to allow a muxer to be selected when encodebin is instructed to use video/quicktime without specifying a particular type.
This patch doesn't look like the optimal solution to me. It should be okay to just add a second caps structure to the normal qtmux caps in the template, we shouldn't have to register another element just to make this work. Will have a look.
Fixed this differently (I hope): commit 025417f12436170fe77d469d614933304b0b046f Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Wed Apr 13 15:18:11 2011 +0100 qtmux: add variant-less video/quicktime to source pad template caps This is needed for automatic transcoding using encodebin. Our typefinder does not always add a variant to the found caps, and encodebin needs an *exact* match to the caps on the source pad template, so we need to add the variant-less video/quicktime caps to the template as well for encodebin to be able to find it. Add unit test for this as well. https://bugzilla.gnome.org/show_bug.cgi?id=642879
Just adding here a related bug that was caused by this change. https://bugzilla.gnome.org/show_bug.cgi?id=651496
Shouldn't the fix for this issue be to update the typefinders to always generate a variant?
> 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.
But is the current fix truly useful? I mean if you rely on a typefind to set your container format I assume that means you want the same container format used for your output. But with the current fix I assume your 3gpp or mp4 files gets defaulted to quicktime, which might not want to play on your device or system at all. So the only case where this fix actually gives you the expected result is if your input happens to be quicktime anyway. Anyway I will cut and paste your fix suggestion over to the other, still open bug for completeness.