Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
aac decoder: pcmmode.eEndian should be set to OMX_EndianLittle instead of OMX_EndianBig . #409
gstomxaacdec works on both tizonia-test-media/aac/riff_rock.aac and tizonia-test-media/aac/strum12str.aac but it requires to change plugins/aac_decoder/src/aacdec.c::pcmmode.eEndian to OMX_EndianLittle; instead of OMX_EndianBig;
Not sure if the spec says anything about it or if libfaad has an api to configure it.
Please have a look, thx a lot!
The reason is that the Tizonia player app has logic to probe the local stream file during the graph creation, and it configures the right parameters in the various components before moving the graph into Executing state. So I think I decided to do this to:
so it was a way to make my life simpler, so the components would only need to react to stream changes that occur "after" Executing.. which in the case of local files playback is ... never.
But the downside is that this leads to the situation that you are pointing out, where some components might not be doing a great job with things like endianess. So that needs fixing... I'm almost done with the embedding of dbus-cplusplus (
Note, that I've setup a "youtube-live-streaming" branch to get a mp4_demuxer ready to work in complex aac decoding use cases, so I might get the aac decoder improvements in that branch first.
I've updated most of the decoders (including the aac dec) to display OMX_EndianLittle on their PCM output port, because that is what they currently output today. They can't do conversions to Big Endian at the moment, but that will be an issue to resolve once we have platforms that requires it.
The only decoder that still outputs samples in BigEnding order is the mad-based MP3 decoder.
So I'm closing this issue for now. I believe this will work for you.