Issue wit hstreaming plugins: tons of video NACK

[Ju Ju]

Hi Lorenzo,

I'm playing with streaming plugin but I can't get something viewable.

I have reencode a 1080p H264 trailer to VP8/opus.

from ffmpeg perspective the trailer is playing at 1x without issue.

The issue is on my browser (both FF and chrome): the sound is perfect but video is stuttering like hell, most of the time the screen is black.

-> All KPI (admin API, webrtc-internal and janus.log) tells there is tons of video nack (> 1000 regulary).

At this point it would be easy to point out my network but in the same setup and using others plugin (videoroom, echotest) it works perfectly with no video nack.

Do you have an idea why I have this behaviour ? maybe browsers disable their buffer or something like that ?

From many tries it seems to be a link between the video codec I used and the video nack (I have less video nack when using h264 coed for the same video trailer)


JJ-

[Lorenzo Miniero]

I don't know how to debug the logic browsers implement, sorry. What you can do is check if those NACKed packet are actually lost or not, that is if the browser is not receiving them for some reason. If not, the browser is NACKing them for some different reason, and you'll have to dig in the Chrome/Firefox logs yourself to figure out why.

L.

[emmanu...@dazzl.tv]

my 2 cents; I have had the same kind of issue, in my case it was due to fragmentation. Packets were not received in right order by the browser. Video packets were fragmented because of the extra bytes added by the SRTP layer.
If you can control the packets size of the source, that might solve your pb.

Cheers,

Emmanuel.

[Ju Ju]

Hi Emmanuel

Many thanks to remind me that ! I have completely forgotten by in the past it solves my issue so I’m sure you ‘re right.

I m gonna try it at once, many thanks !

JJ-

--
You received this message because you are subscribed to a topic in the Google Groups "meetecho-janus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meetecho-janus/J2dij_nSyHU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emmanuel Riou]

You're welcome ;-) Spent quite some time to figure that out, so I hope it will save you some time ;-)

Cheers,

Emmanuel.

To unsubscribe from this group and all its topics, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Ju Ju]

Ok so verdict:

much more better. Still few NACK but it  comes from my wifi access. With wire access it is perfect.
It seems NACK mechanism is not good enough for this use case.

JJ-

Cheers,

Emmanuel.

To unsubscribe from this group and all its topics, send an email to meetecho-janu...@googlegroups.com.

[Lorenzo Miniero]

Il giorno venerdì 12 gennaio 2018 17:38:25 UTC+1, Ju Ju ha scritto:

Ok so verdict:

much more better. Still few NACK but it  comes from my wifi access. With wire access it is perfect.
It seems NACK mechanism is not good enough for this use case.

Well, if it's MTU related (size exceeds MTU) then it's clear that NACKs can't help: they'd try to retransmit the same packet, which would exceed the MTU exactly as the original one did, and would be dropped as well. NACKs are for losses caused by different reasons than going beyond the MTUs.

L.

[Ju Ju]

Hi Lorenzo,

I was talking about « now » , I mean with size of RTP packets << MTU, so not MTU relative issue.

The use case of streaming a HD  trailer with sound, every little losses is visible, NACK seems to be not enough.

Kr,

JJ--

[Lorenzo Miniero]

Ah got it, sorry for misunderstanding... Have you checked if retransmissions are taking place? The max NACK queue might be too small, and so Janus may not have the packet anymore when you ask for it.

L.

JJ--

To unsubscribe from this group and all its topics, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Ju Ju]

Hi Lorenzo ,

Le 12 janv. 2018 à 18:48, Lorenzo Miniero <lmin...@gmail.com> a écrit :

Ah got it, sorry for misunderstanding... Have you checked if retransmissions are taking place?

It seems so as I have this kind of message in log file

[Thu Jan 11 17:15:07 2018] [5537225940997570] Retransmitted 7 packets due to NACK (video stream #0)

The max NACK queue might be too small, and so Janus may not have the packet anymore when you ask for it.

By « small » you mean : the « max » delay authorized by the back queue or you mean you have a limited space for this queue ?

We agree I can only set the max « aged » of NACK which will be processed ?