Bug Report AAC format OBS uses is not accepted by Justin.tv!

LeonhartGR

New Member
I woke up to find that my stream was disconnected with a pretty message in my inbox...:
Code:
Hello leonhartgr_justin,

This is an automated message. Here at Justin.tv, we’ve experienced a massive surge in demand for viewing on non-computer devices; such as tablets and mobile phones. We want your viewers to be able to watch in all these places, so we’re making changes to our infrastructure to service this growth!

Your broadcast settings will be INCOMPATIBLE on this new system, which will take place in November 2013. This is why:


    Audio codec must be set to MP3 or AAC (it is currently "SoundFormat_Aac") Follow this link to fix audio codec: https://help.justin.tv/entries/25128411-Broadcast-Requirements#audio_codec


For all of the broadcast requirements, you can find them here: https://help.justin.tv/entries/25128411-Broadcast-Requirements

Should you have any questions, please contact us through http://help.justin.tv.

Thanks!

Regards,
The Justin.tv Team

Even if I don't get it since I already use AAC... can you please support AAC instead of "SoundFormat_Aac"? Thanks!
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
If I were to guess, it's a bug in their detection code. OBS isn't using a "different" AAC format. It looks like they're comparing text strings. Not sure where they're getting that string from though. They'll probably have someone talk to me if there's actually something going wrong on my end, but if there's anything wrong on my end it would most likely just be metadata or something, nothing more.
 

LeonhartGR

New Member
"...which WILL take place in November 2013."??? That's certainly a bug... I just wouldn't wish to be banned due to a bug... I have some really bad experiences with the YouTube latest copyright terror as well :) I switched to 128kbps mp3 atm for any unfortunate cases...

And thanks for replying! Appreciated a lot!
 

szatmary

New Member
Hello, I develop the transcoding tools here at Justin/Twitch. This is a poor interaction between two bugs. One on each end. It did detect the codec correctly (AAC) but doesn't know how to handle it. This is caused when an AAC sequence header is not the first audio tag in the stream. I will modify the code on my end to throw away tags until a sequence header is found. But from the broadcasting side raw AAC packets should not be sent before a sequence header.
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
Ah, thank you for the information. Although it should be the first audio packet in the stream. We actually haven't changed any of that specific area of code in like half a year, so I'm curious as to what's going on. I'll check it out and make sure it's working properly.

(Guess I jinxed myself, wasn't metadata after all)
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
I just checked the code, are you sure the header wasn't the first audio packet? We have it specifically programmed so that the first packets that get sent out are the video and audio headers when publishing starts, right after metadata.

It sends out the metadata, audio codec header, and then video codec header.

(Also thank you for taking the time to point it out to us)
 

szatmary

New Member
Sorry, Jim I have never used OBS personally, But does it support rebroadcasting of FLVs? If so, it could have been the FLV that had an out of order tag.
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
OBS doesn't rebroadcast FLVs, it builds the stream itself. This shouldn't be happening because it doesn't send off data before the metadata and audio/video codec headers are already sent. I'm trying to figure out if this is a bug or something, but I can't really find any indication that it's doing so as of yet.
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
The only possible thing I can think of is if the function to send the metadata/headers isn't properly being called. Do you know if they were sent at all? Because they definitely *shouldn't be sent out of order otherwise.
 

szatmary

New Member
On this particular stream, I don't know for sure if they were or were not sent. Do we know if the problem is reproducible? Either way. I do have a fix from our end. So I wouldn't worry about it too much.
 

Lain

Forum Admin
Lain
Forum Moderator
Developer
I can't seem to reproduce myself, so I'm totally confused as to what happened there with his particular stream. I do have it programmed specifically so that it sends out the metadata, audio header, and then video header first before any other packets start streaming though. No packets should be able to get added to the queue until that initial data is sent.

I'm not sure why it only happened to this one guy though. If there were a bug or something, you'd think it would happen to everybody. I'm really confused.

Either way, if you wrote some code to handle it then I suppose it's fine for now, but if there's ever a problem never hesitate to email me any time. I'm really sorry for the trouble.
 

Boildown

Active Member
LeonhartGR, what version of OBS were/are you using?

A wireshark capture should show what order everything is going in, in case its ever reproducible.
 

LeonhartGR

New Member
Got it again... Sent me offline...

Code:
"Hello leonhartgr_justin,

This is an automated message. Here at Justin.tv, we’ve experienced a massive surge in demand for viewing on non-computer devices; such as tablets and mobile phones. We want your viewers to be able to watch in all these places, so we’re making changes to our infrastructure to service this growth!

Your broadcast settings will be INCOMPATIBLE on this new system, which will take place in November 2013. This is why:


    Audio codec must be set to MP3 or AAC (it is currently "SoundFormat_Aac") Follow this link to fix audio codec: https://help.justin.tv/entries/25128411-Broadcast-Requirements#audio_codec


For all of the broadcast requirements, you can find them here: https://help.justin.tv/entries/25128411-Broadcast-Requirements

Should you have any questions, please contact us through http://help.justin.tv.

Thanks!

Regards,
The Justin.tv Team"
 

Boildown

Active Member
I don't know what that is, but its not the entire log file, or something is really messed up. Use Select All and copy the entire log file.

Or open the folder containing the log files, and zip all of them into an archive and post the zip file on a file-sharing site.
 

Boildown

Active Member
02:20:52: Capture window 0x00050386 invalid or changing, terminating capture
02:20:56: SharedTexCapture hooked
02:45:31: Capture window 0x0006035E invalid or changing, terminating capture
02:45:35: SharedTexCapture hooked
02:45:46: Capture window 0x00070358 invalid or changing, terminating capture
02:45:51: SharedTexCapture hooked
03:10:25: Capture window 0x00080386 invalid or changing, terminating capture
03:10:29: SharedTexCapture hooked

02:20:36: wglDeleteContext Called
02:20:36: ---------------------- Cleared OpenGL Capture ----------------------
02:20:36: SwapBuffers(503385653) Called
02:20:36: setting up gl data
02:20:36: share device: 99692116
02:20:36: share texture: 92506296
02:20:36: share device handle: 3593646454
02:20:36: share texture handle: 3595643242
02:20:36: DoGLGPUHook: success
02:20:36: wglSwapBuffers(503385653) Called

He's got pages of these two messages. Anyone know what they mean?

The rest looks fine to me, although 1500 bitrate is a bit light for 720p60.

 
Top