Illegal AudioSpecificConfig header

lostbacon

New Member
Obs 20.0.1 for Windows is currently producing the following HEX 13 10 56 E5 98 for 48kHz Audio and HEX 13 90 56 E5 A0 for 44.1Khz Audio.

Basically, the FrequencyIndex is being set to 6 for 48Khz and 7 for 44.1Khz. Index 6 is 24Khz and 7 is 22.050Khz.

The audio frames also seem to be twice as large as usual. They're 46ms (rounded) in duration instead of the expected 23.22ms for 44.1Khz audio. Its okay to produce multiple audio frames per packet; just need to get the FrequencyIndex correct.

On a side note: RTMP is only using a single chunk-channel to transfer stream data which is making your timestamp math much more difficult and error prone. By using more than one channel, you get to use pure deltas for the timestamps.
 
Last edited:

pkv

Developer
which aac encoder are you using ? (should be in the logs) it can be ffmpeg aac , coreaudio, libfdk_aac or mf_aac with OBS.
It would be at that level that the ASC is encoded; I'm not seeing anything in obs-studio source code toward writing the ASC header (unless I'm mistaken)
 

lostbacon

New Member
I'm not sure that it is the encoder's problem because I think OBS is sending double-sized audio frames to the encoder configured for half the frequency rate. Like the frequency is being divided by half when the encoder is configured.
 

pkv

Developer
what you say is not consistent with the index changes, which are done in the ASC, hence my asking about the encoder from your logs; or I misunderstand something ?
 

lostbacon

New Member
I think there is a correlation to the ASC specifying half the actual frequency and pushing two audio frames at once. Looks like on Win 10 it is using CoreAudio AAC.
 
Top