GNOME Bugzilla – Bug 665394
mpegtsdemux: regression - Taiwan_HiHD_slogan.ts doesn't preroll
Last modified: 2012-02-02 13:00:08 UTC
This clip pre-rolls fine with the last releases, but not with git of things (using the old mpegtsdemux in both cases; it works with tsdemux): http://file.kidwm.net/Taiwan_HiHD_slogan.ts Note that the lack of audio is expected, that's another issue, bug #596772 (and not a regression).
Introduced by: commit 83b5b296390838a2e151097e4665b9334cfff1fc Author: Rafael Diniz <rafael@riseup.net> Date: Fri May 20 09:58:50 2011 +0200 mpeg[pt]sdemux: Add support for AAC LATM/LOAS streams Fixes bug #615681. However, the rea issue is that aacparse gets plugged by playbin2, as it advertises it can handle audio/mpeg, mpegversion: { 2, 4 }, and will output something which does not include loas as a stream format. The input here has loas as a stream format (which matches aacparse's generic template), but there's no way to express in caps "I do anything except that". If I was to specify "I do A, B, and C", it would stop working for inputs which do not specify any stream format. So, not sure what to do here. We have other decoders which have template caps coser to what's being passed, so that would make more sense to plug them, but that would not solve the main issue, just sidestep it...
The only solution I currently see is implementing of LATM/LOAS support in aacparse
Created attachment 202986 [details] [review] aacparse: parse LOAS variant The LOAS variant seems to have three different variants itself, only one of them is implemented as my two samples use that one. The sample rate reported is a bit odd (24000 Hz in both samples), but I'm told that AAC sometimes reports half the sample rate, so this seems to match. I don't know when to recognize these cases, though, so I leave the sample rate as is. This should be fixed if someone knows how to tell between half and normal rates.
That's it done, turned out to be a large change. It works on my two LOAS samples, but I'm not too confident it's 100% right. However, that does not "fix" the issue entirely. It turns out that faad does not decode LOAS variant, so playbin2 will fail to play with an error from faad. However, a manual pipeline using ffdec_aac_latm will play (correctly ? I don't know, the sound seems not to be noise, but only partial, and the sample is small). However, faad's rank is primary, and ffdec_aac_latm is 64, so faad will always be chosen for the same reason again: one can't tell in caps that we support everything except loas.
Created attachment 203694 [details] [review] aacparse: parse LOAS variant The LOAS variant seems to have three different variants itself, only one of them is implemented as my two samples use that one. The sample rate reported is a bit odd (24000 Hz in both samples), but I'm told that AAC sometimes reports half the sample rate, so this seems to match. I don't know when to recognize these cases, though, so I leave the sample rate as is. This should be fixed if someone knows how to tell between half and normal rates.
Some more parsing to read a second sample rate which can override the previous one. This makes one of my samples output the correct sample rate. The other sample would seem to require parsing of a preposterous amount of (for us, but hopefully not only for us) useless stuff, so I'll leave that out for now, since ffdec_latm does not rely on the sample rate in caps anyway.
Created attachment 203855 [details] [review] aacparse: parse LOAS variant The LOAS variant seems to have three different variants itself, only one of them is implemented as my two samples use that one. The sample rate reported is a bit odd (24000 Hz in both samples), but I'm told that AAC sometimes reports half the sample rate, so this seems to match. I don't know when to recognize these cases, though, so I leave the sample rate as is. This should be fixed if someone knows how to tell between half and normal rates.
Some cleanup and factoring, I'll be pushing this soonish.
Pushed. Does not fix the original bug though, preroll still fails with playbin2, though it fails later in the pipeline, in faad. commit 16a4c596eb39bfc845e2675385d95ff808920edc Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Dec 7 13:24:55 2011 +0000 aacparse: parse LOAS variant The LOAS variant seems to have three different subvariants itself, only one of them is implemented as my two samples happen to be using that one. The sample rate is not always reported correctly, as the "main" sample rate is apparently sometimes half what it should be (both of my samples report 24000 Hz there), and there are two other parts of the subvariant with different sampling rates. One of them is parsed, but not the other, as it's located after some other large amount of variable data that needs parsing first, and there seems to be a LOT of it, which is useless for our needs here. This ends up being rather inconsequential, as ffdec_aac_latm, which is the only decoder that can decode such streams, does not need the sample rate on the caps anyway. https://bugzilla.gnome.org/show_bug.cgi?id=665394
I looked through the different elements for "audio/mpeg, mpegversion=4" which is used for AAC. Some caps use mpegversion=[2, 4] and the like, but it should be possible to split those caps, and always set a stream format for version 4, which should in turn ensure that anything outputting LOAS will not go to faad, while making sure every demuxer adds a stream format to these caps. I'd need to go into the code of every demuxer that outputs mpegversion=4 to check if we can know the stream format there to set it, though. Parenthetically, might it be a good idea, in case linking fails in a case such as this, to try other elements that may be autoplugged ? In this case, if faad does not understand the LOAS format, and fails to link, decodebin2 could try autoplugging ffdec_aac_latm, which is the next autopluggable element on rank. This would make things more robust, but arguably faad ought not have been selected in the first place due to caps.
Yes, please do that (always requiring a stream-format).
Created attachment 206624 [details] [review] flvdemux: specify we only output raw AAC in template caps
Created attachment 206625 [details] [review] flvmux: specify we only accept raw AAC in template caps No header seems to be added, and the codec ID is the same as used for raw by flvdemux, so raw seems the only supported case.
Created attachment 206626 [details] [review] mpegdemux: include specific AAC stream-format types in template caps
Created attachment 206627 [details] [review] mpegtsmux: specify in template caps we only take raw/adts AAC format This appears to be what this element supports.
Created attachment 206628 [details] [review] faad: include specific support AAC stream formats in template caps
Created attachment 206629 [details] [review] tsdemux: add explicit supported AAC stream-format in template caps
Created attachment 206630 [details] [review] mpegpsmux: include specific AAC stream-format in template caps This elements seems to support raw and adts AAC.
There's one case left where template caps do not specify stream-format, and this is in libgstriff. There are a few different identifiers for AAC, and based on googling they seem to be not LOAS nor ADTS. However, I can't tell betewen raw and ADIF, so this one is left to do still. The Taiwan_HiHD_slogan.ts file now plays A/V with playbin2, autoplugging ffdec_aac_latm. I'm not certain this isn't breaking anything else though. The caps changes are based on looking at the code in each element that handled audio/mpeg, mpegversion=4, and guessing from what I found. Only a couple cases had an explicit stream-format set.