[1.3.3] VideoRoom: H.265 simulcast from browser is detected but not relayed (PLI loop, no video delivered)

[pmlejnek]

What version of Janus is this happening on?
Janus 1303 (1.3.3), built from latest master.

Have you tested a more recent version of Janus too?
Yes, tested on latest master as well. Behavior is identical.

Was this working before?
Not sure. This does not look like a regression.
This is more a question about current behavior/design rather than something that previously worked.

Is there a gdb or libasan trace of the issue?
Not applicable (no crash or memory issue).
This is about RTP simulcast/layer selection behavior only.

Additional context

We are experimenting with H265/HEVC in VideoRoom.

When Chrome publishes H265 with simulcast enabled, multiple SSRCs are sent.
Example from the offer:

a=ssrc-group:SIM 2962795760 2719491959 2339202009

Janus correctly detects simulcast:

Publisher stream is going to do simulcasting (#1, 1)

However, during runtime Janus repeatedly logs:

We need a PLI for the simulcast context

and never seems to switch to higher layers. In practice only the first SSRC
(lowest resolution) is forwarded.

Because Chrome starts simulcast layers progressively (low → mid → high),
this results in Janus effectively locking onto the lowest quality layer.

For VP8/VP9 this is usually fine, but for H265 this makes quality unusable.

There is no crash or malfunction — this looks like missing layer selection logic
rather than a bug.

Questions:

• Is H265 simulcast officially supported in VideoRoom?
• Is layer selection/switching for H265 planned?
• Or is the expected usage single-stream only for H265?

We can work around this by stripping simulcast in our signaling layer,
but wanted to confirm the intended design direction first.

Thanks!

[lminiero]

However, during runtime Janus repeatedly logs:

We need a PLI for the simulcast context

That means we never detect a keyframe in the streams that arrive. We send a PLI but, if a keyframe arrives, it's not detected: the code I added at the time worked for what Safari put in the RTP, but maybe things changed in the meanwhile and now the logic about what to look for changed. As such, that's the code that needs fixing, I guess, nothing else.

That said, I dont have access to a browser with H.265 access, and to be honest it's not really a priority for me as I don't care much for royalty encumbered codecs. If you want to try and give it a stab yourself, this is the code that does it:

https://github.com/meetecho/janus-gateway/blob/master/src/utils.c#L923-L937

You could try adding some log lines to check when it returns TRUE or FALSE. If it's always FALSE, then that's indeed where the problem is, and you need to fix the check that leads to TRUE (which I guess means looking for other types of NALs, or looking for them somewhere else),

[pmlejnek]

Hi @lminiero,

Thank you for pointing me to the right place in the code! It helped me significantly in debugging the H.265 simulcast issues.

After extensive testing across different platforms (Linux/Chromium with Intel Arc, Windows/Edge, and macOS/Safari), I have developed a more robust version of the janus_h265_is_keyframe function.

The original implementation struggled with how different browsers packetize HEVC data. Specifically, I found that:

Safari often uses Aggregation Packets (AP) for IRAP/Parameter sets.

Chromium and Firefox frequently use Fragmentation Units (FU) for the same.

The updated function now correctly parses these encapsulated types, ensuring that keyframes are detected regardless of the browser's packetization strategy. This fixed the PLI loops and "no video" issues we were experiencing.

Here is my final version of the function:

gboolean janus_h265_is_keyframe(const char *buffer, int len) {
	if(!buffer || len < 3)
		return FALSE;

	uint16_t unit = 0;
	memcpy(&unit, buffer, sizeof(uint16_t));
	unit = ntohs(unit);
	uint8_t type = (unit & 0x7E00) >> 9;

	/* 1. Direct IRAP/Parameter types (NAL units 16-21 and 32-34) */
	if((type >= 16 && type <= 21) || (type >= 32 && type <= 34))
		return TRUE;

	/* 2. Aggregation Packet (AP = 48) - Critical for Safari stability */
	if(type == 48 && len >= 6) {
		uint16_t inner_unit = 0;
		/* Skip payload header and look at the first nested NAL unit */
		memcpy(&inner_unit, buffer + 4, sizeof(uint16_t));
		inner_unit = ntohs(inner_unit);
		uint8_t inner_type = (inner_unit & 0x7E00) >> 9;
		if((inner_type >= 16 && inner_type <= 21) || (inner_type >= 32 && inner_type <= 34))
			return TRUE;
	}

	/* 3. Fragmentation Unit (FU = 49) - Critical for Chrome/Firefox stability */
	if(type == 49 && len >= 3) {
		uint8_t fu_header = (uint8_t)buffer[2];
		gboolean start_bit = (fu_header & 0x80);
		uint8_t real_type = (fu_header & 0x1F);
		/* If it's the start of a fragmented IRAP or Parameter set */
		if(start_bit && ((real_type >= 16 && real_type <= 21) || (real_type >= 32 && real_type <= 34)))
			return TRUE;
	}

	return FALSE;
}

I hope this helps others facing similar H.265 relay issues. Thanks again for the guidance!

[lminiero]

I'm sorry, but this all looks a bit too AI-y to me. As such, I'm not sure I trust you when you say you've tested all those scenarios, or where this code came from (I'm not inclined to merge AI-generated code, which may have been stolen from who knows where). If you have unencrypted pcap captures of the H.265 traffic from different browsers (which you can get in Janus like this) I'd be happy to have a look and confirm, especially considering I'd probably need to validate the same fix for the recordings post-processor too (and so a capture with actual video may help in that regard).

[pmlejnek]

I'm not saying the code should be merged right away. I got inspired by your original code and discovered it only worked with some Safari clients. So I started digging into it and watching Janus logs (level 7 debug level). After some experimentation I discovered the Linux/Windows clients behave differently. These browsers frequently fragment large IDR frames into multiple Fragmentation Units (FU) with NAL unit type 49. The original function dismissed these. I adjusted the buffer values several times. In fact, I'm not very strong at this topic, I would even say a newbie. Just I was able to make the code functional for me. My testing abilites were also limited: two browsers on Linux, some on a Windows machine and some tests with two different Safari versions on two different Apple computers.
I'm open to critical insights. To defend myself: You openly said "to be honest it's not really a priority for me" so I decided to do at least something. This is just a kick-off if someone is interested.

In case it disturbs you, feel free to close the topic.

If you have unencrypted pcap captures of the H.265 traffic from different browsers (which you can get in Janus like this) I'd be happy to have a look and confirm, especially considering I'd probably need to validate the same fix for the recordings post-processor too (and so a capture with actual video may help in that regard).

I don't have these but I can create them. The situation at least in Linux is complicated by the fact that H265 is only allowed in hw (no software encode/decode) - as you mentioned because of licence issues.

[lminiero]

No no, no disturb at all. I actually do welcome contributions! The only thing I'm very wary of (especially these days) is AI contributions, as I sometimes feel like I'm the only one speaking, and I'm always talking to bots that created a bunch of text (and code) rather than real people, which is depressing (and possibly problematic, when the code is AI generated, because of licensing issues).

If that's not the case for what you shared, I apologize of course.

I don't have these but I can create them. The situation at least in Linux is complicated by the fact that H265 is only allowed in hw (no software encode/decode) - as you mentioned because of licence issues.

Those dumps would help as they'd give a me a valid reference for next time too. It would allow me to inject H.265 traffic and play/analyse it without having access to a browser that can generate it. We have the same keyframe detection in the janus-pp-rec tool, so having some actual dumps with actual H.265 data would help me check if that code still works, or if it needs adjusting too (which is basically how I tested this when I first added H.265 support).

I guess that it's not important if the browser is on Linux or not, especially if data is formatted the same way, and so checks made for the same browser on other operating systems still work and give the same result.

[fippo]

Note that Safari used to send HEVC in a weird nonstandard format - 3-4 bytes of crap followed by the NAL units with startcodes - when it was still behind a flag. If you wrote the code back then ...

[lminiero]

I think H.265 support has been updated a couple of times since, but always via contributions. I never had access to an H.265 encoder myself, and it being a royalty encumbered codec means I'm not that interested anyway 😁

If, from what you know libwebrtc does with the codec, the patch above looks reasonable, I'll definitely take that into account, but then I wouldn't have any way to test it. That's why I suggested collecting dumps I can use to articifially inject H.265 traffic so that I can play with it myself too.

[fippo]

libWebRTC uses "has a VPS NAL" for determination but yes, if Safari's encoder does this differently (should be just using videotoolbox which Chrome can too) looking a serverside pcap on the RTP packets would be best.