GNOME Bugzilla – Bug 705024
aacparse: does not propagate downstream sample rate restriction upstream
Last modified: 2013-12-09 14:05:11 UTC
Created attachment 250301 [details] dotfile graph I am having trouble transcoding a file in Transmageddon, as you can see if the attached dotfile graph the issue is that I try to set a rate value with a capsfilter, but the element that should provide that new rate doesn't seem aware of it.
Created attachment 250303 [details] Another similar looking issue, but this time the capsfilter seems to be compatible
This is with up-to-date git master? I suspect some element doesn't proxy the caps query properly, most likely streamcombiner. Moving tentatively to encodebin for now. And it should be audioresample before the encoder that does the rate conversion. Could you provide a GST_DEBUG=*:6 log for when it doesn't work?
Yes, git master of everything except gst-libav. GST_DEBUG log can be found here: http://uraeus.fedorapeople.org/output.txt.bz2
This looks like a bug in aacparse: gst-launch-1.0 audiotestsrc ! audioconvert ! audio/x-raw,rate=48000,channels=2 ! audioresample ! faac ! aacparse ! audio/mpeg,rate=44100 ! fakesink Remove the aacparse, and it works. Replace faac ! aacparse with lamemp3enc ! mpegaudioparse, and it works.
I was told that this was introduced by this commit: commit ca4b5d795bf52ea434470475e2dac6a149282c10 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue Jun 5 09:18:12 2012 +0200 audioparsers: Fix GstBaseParse::get_sink_caps() implementations They should take the filter caps into account and always return the template caps appended to the actual caps. Otherwise the parsers stop to accept unparsed streams where upstream does not know about channels, rate, etc. Fixes bug #677401. The problem here is that if downstream has rate=44100 as a constraint we would need to pass that upstream. However we can't pass that constraint upstream because unparsed AAC streams might not have the rate on the caps.
> > > The problem here is that if downstream has rate=44100 as a constraint we would > need to pass that upstream. However we can't pass that constraint upstream > because unparsed AAC streams might not have the rate on the caps. In this case, the template caps add the exact property that is also being constrained (rate=(int){ 8000, 11025, 12000, 16000, 22050, 24000, ...). If this is the case, the contraint should be applied to those added properties. Not sure how to express that...
Well, no. The template caps don't contain the rate field, otherwise we could just fix this problem by putting the constraints into the caps we append. However that will require all elements to put the sample rate in AAC caps, which is a value that aacparse extracts and not everything knows.
(In reply to comment #5) > I was told that this was introduced by this commit: > > commit ca4b5d795bf52ea434470475e2dac6a149282c10 > Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> > Date: Tue Jun 5 09:18:12 2012 +0200 > > audioparsers: Fix GstBaseParse::get_sink_caps() implementations > > They should take the filter caps into account and always return > the template caps appended to the actual caps. Otherwise the > parsers stop to accept unparsed streams where upstream does not > know about channels, rate, etc. > > Fixes bug #677401. > > > > The problem here is that if downstream has rate=44100 as a constraint we would > need to pass that upstream. However we can't pass that constraint upstream > because unparsed AAC streams might not have the rate on the caps. I think the trick is to proxy the constraints but implement a custom getcaps function that only intersects so that it can also allow missing fields.
commit e0a5c07e8d404e72654e016fa0a6c88d573f51f1 Author: Wim Taymans <wtaymans@redhat.com> Date: Tue Dec 3 21:41:28 2013 +0100 audioparsers: use ACCEPT_INTERSECT flag The parser can accept input that is not completely specified. Use the ACCEPT_INTERSECT flag on the sinkpad to tweak the acceptcaps function to check for intersection only. This allows us to proxy downstream constraints while still allowing non-subset caps as input. We can then also remove the appended template caps workaround. Make a unit-test to check the new feature. This reverts commit 26040ee38cb9e7c42f3d9a0282b3e5cace7ca42d Fixes https://bugzilla.gnome.org/show_bug.cgi?id=705024
Wim, this probably needs an update in part-caps and/or part-negotiation now. There it says that caps are considered compatible if they're a subset. Otherwise this should work, but somehow feels not ideal :) I don't have a better solution though
(In reply to comment #10) > Wim, this probably needs an update in part-caps and/or part-negotiation now. > There it says that caps are considered compatible if they're a subset. > > Otherwise this should work, but somehow feels not ideal :) I don't have a > better solution though I think the ideal solution would be to mark some properties as mandatory and others optional. I also think that this would complicate things even more.
Yes, let's not go that road :)