GNOME Bugzilla – Bug 749433
pad-monitor test error about audio rate change
Last modified: 2018-11-03 11:07:00 UTC
DISPLAY=:0 GST_GL_XINITTHREADS=1 GST_VALIDATE_SCENARIO=seek_forward gst-validate-1.0 playbin uri=http://dash.edgesuite.net/dash264/TestCases/1a/netflix/ElephantsDream_AAC48K_064.mp4.dash The above test fails with the following error. Critical error Field rate from setcaps caps 'audio/x-raw, format=(string)F32LE, layout=(string)interleaved, rate=(int)48000, channels=(int)2, channel-mask=(bitmask)0x0000000000000003' is different from expected value in caps 'pending-fields, rate=(int)24000, channels=(int)2;' I confirmed that avdec_aac element's sink and src pad have different caps as following in the test pipeline. <sink> audio/mpeg rate : 24000 channels : 2 <src> audio/x-raw layout : interleaved rate : 48000 channels : 2 pad-monitor seems to assume that audio rate caps information shouldn't be changed b/w a decoder's sink and src pad. But I'm not sure this assumption is right for this case. It seems that rate of sink and src pad can be considered the same because decoded data have interleaved layout.
Thibault, could you give me a guide for this?
In that case the decoder should also be marked as Converter in it klass I think.
No, the decoder is not a converter. I think what's happening here is that this is a HE-AAC stream with SBR, so the sample rate is half of what a decoder with HE-AAC/SBR support would output. Unclear what should happen here, perhaps the demuxer should recognise it and double the rate (but then it would be wrong for the fallback LC decoder case..).
(In reply to Tim-Philipp Müller from comment #3) > No, the decoder is not a converter. OK, I guess I missunderstood the case then. > I think what's happening here is that this is a HE-AAC stream with SBR, so > the sample rate is half of what a decoder with HE-AAC/SBR support would > output. Unclear what should happen here, perhaps the demuxer should > recognise it and double the rate (but then it would be wrong for the > fallback LC decoder case..). I guess the parser at least should set it correctly no? What is the LC decoder case?
LC is the most basic AAC low complexity profile. HE-AAC v1 basically encodes a base stream with half the sample rate and then some extra info to restore the full sample rate. Decoders that can't handle HE-AAC v1 can still decode the LC part of the stream and output a lower quality version, this way some degree of backwards compatibility is maintained. So there is no 'correct' sample rate really, depending on the decoder it will output with a rate of 24000 or 48000. Depending what the signalled caps are exactly, I think the demuxer and/or parser should detect this and set a rate of 48kHz in the caps here (if signalled explicitly), BUT if a LC decoder gets plugged the fact that it outputs something with a different rate than it got as input is not a bug.
That for the explanation @tim. I think we should keep that bug open and make it about making sure parsers/demuxer properly set the rate to what a HE-AAC v1 complient decoder should decode. Meanwhile @Young, you can just add an override to ignore that issue. (sorry there is no documentation about that, you can just have a look at the tests http://cgit.freedesktop.org/gstreamer/gst-devtools/tree/validate/tests/check/validate/overrides.c and GST_VALIDATE_OVERRIDES in the env variable documentation: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/envvariables.html)
Thanks @Thibault. I found this problem while trying to add mpeg-dash test cases to gst-devtools. It would be great if gst-devtools have sample tests of the following. http://dashif.org/reference/players/javascript/1.3.0/samples/dash-if-reference-player/index.html Thanks, @Tim. I'm still digging this rate issue. It seems that the following media file have similar problem. http://download.wavetlan.com/SVV/Media/HTTP/AAC/MediaCoder/MediaCoder_test4_AAC-LC_v4_Stereo_ABR_32kbps_48000Hz.m4a GstAacParse changes sample rate from 48000 to 24000 based on codec-data, and then avdec_aac changes again sample rate from 24000 to 48000. I'll attach a dot-graph for this soon. p.s. I got this media file from the following. http://download.wavetlan.com/SVV/Media/HTTP/http-aac.htm
Created attachment 303577 [details] dot graph of AAC-LC
Note that the second file (MediaCoder_test4_AAC-LC_v4_Stereo_ABR_32kbps_48000Hz.m4a) is AAC-LC by its name and the page from which the file comes.
> I found this problem while trying to add mpeg-dash test cases to gst-devtools. > It would be great if gst-devtools have sample tests of the following. > http://dashif.org/reference/players/javascript/1.3.0/samples/dash-if-reference-player/index.html Patches very welcome :) What takes time is always to make sure the tests we add are not racy.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-devtools/issues/15.