Bad results in WebRTC -> RTC -> RTMP -> HLS using kurento, ffmpeg and nginx

1,133 views
Skip to first unread message

alb...@axiomzen.co

unread,
Jul 14, 2016, 6:47:30 PM7/14/16
to kurento
Hello everyone,

I'm trying to create a conversion from WebRTC to HLS.
I'm using Kurento to do WebRTC to RTP. Then ffmpeg to do RTP to RTMP, then nginx to do RTMP to HLS.

I've started from the one2many example but just using the presenter piece. Right after the webRtc processes the offer from the websocket, I create a RtpEndpoint and process the following SDP:

v=0
o=- 3641290734 3641290734 IN IP4 127.0.0.1
s=ffmpeg
c=IN IP4 127.0.0.1
t=0 0
m=audio 5005 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
m=video 5007 RTP/AVP 101
a=rtpmap:101 H264/90000
a=recvonly

and then I connect the webRtcEndpoint to the rtpEndpoint.

Then I run ffmpeg with the following command:
ffmpeg -protocol_whitelist file,udp,rtp -re -i offer.sdp -y -vcodec libx264 -vprofile baseline -acodec libmp3lame -ar 44100 -ac 1 -f flv rtmp://127.0.0.1:1935/hls/test
where the offer.sdp contains the exact same content I processed in the RtpEndpoint.

Once I have ffmpeg running, I go to the browser and click Present. I see my own stream and ffmpeg triggers, it receives some data, but it shows lots of errors like:

[sdp @ 0x266ac40] max delay reached. need to consume packet

[sdp @ 0x266ac40] RTP: missed 156 packets

[sdp @ 0x266ac40] max delay reached. need to consume packet

[sdp @ 0x266ac40] RTP: missed 156 packets

[h264 @ 0x272abe0] Invalid level prefix

[h264 @ 0x272abe0] error while decoding MB 8 14

[h264 @ 0x272abe0] concealing 681 DC, 681 AC, 681 MV errors in I frame

[h264 @ 0x2950f80] corrupted macroblock 22 25 (total_coeff=-1)

[h264 @ 0x2950f80] error while decoding MB 22 25



and on the hls side (nginx) I get some parts but the video is really bad, I think the index or something is really wrong... probably because some frames are missed?
Does anyone have any idea why this happens? I'm not sure what piece of the chain is acting weird, sorry if I'm asking in the wrong place.

Cheers, 

Ivan Gracia

unread,
Jul 15, 2016, 3:35:58 AM7/15/16
to Kurento Public
We achieved that with Wowza and didn't find any errors. I know it doesn't help much, but just for you to know that it can work.

Ivan Gracia



--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Hassman

unread,
Jul 15, 2016, 6:45:39 AM7/15/16
to kur...@googlegroups.com
I can't help with the video quality issues, but why not simplify your process flow? i.e. removing rtmp
  webrtc -> kurento -> rtp -> ffmpeg -> hls -> nginx
 
Sample ffmpeg parameters:
ffmpeg -protocol_whitelist file,udp,rtp -loglevel 99 -analyzeduration 2048M -probesize 2048M -y -nostdin -i /tmp/offer.sdp -threads 3 -s 480x270 -c:v libx264 -tune zerolatency -flags +global_header -movflags +faststart -pix_fmt yuv420p -profile:v main -level 3.1 -preset medium -b:v 400K -maxrate 500K -bufsize 2M -r 10 -g 20 -keyint_min 20 -sc_threshold 0 -x264opts keyint=5:min-keyint=1:level=41 -c:a libfdk_aac -profile:a aac_low -ac 1 -strict -2 -f tee -map 0:v -map 0:a [f=hls:hls_time=2:hls_list_size=10:hls_wrap=30:start_number=1]/tmp/480x270.m3u8
 
Misc additional performance improvements:
 - Write the hls files to a ram drive for i/o efficiency.
 - Re-order the webrtc sdp to prioritize h.264 and pcmu. This way, there's only one transcode (ffmpeg).
 
Hope this helps..
 


From: kur...@googlegroups.com [mailto:kur...@googlegroups.com] On Behalf Of alb...@axiomzen.co
Sent: Thursday, July 14, 2016 6:48 PM
To: kurento
Subject: [kurento-public] Bad results in WebRTC -> RTC -> RTMP -> HLS using kurento, ffmpeg and nginx

Mark Hassman

unread,
Jul 15, 2016, 7:12:52 AM7/15/16
to kur...@googlegroups.com
Whoops.. just noticed i was using an older dev server.. this is better - resolves key frame inconsistencies.
 
 
-protocol_whitelist file,udp,rtp -analyzeduration 2048M -probesize 2048M -y -nostdin -i /tmp/offer.sdp -threads 3 -s 480x270 -c:v libx264 -tune zerolatency -flags +global_header +cgop -movflags +faststart -pix_fmt yuv420p -profile:v main -level 3.1 -preset medium -b:v 400K -maxrate 500K -bufsize 2M -r 10 -g 20 -keyint_min 20 -sc_threshold 0 -x264opts keyint=20:level=41 -c:a libfdk_aac -profile:a aac_low -ac 1 -strict -2 -f tee -map 0:v -map 0:a [f=hls:hls_time=2:hls_list_size=10:hls_wrap=30:start_number=1]/tmp/480x270.m3u8
 


From: Mark Hassman [mailto:ma...@hassman.org]
Sent: Friday, July 15, 2016 6:46 AM
To: 'kur...@googlegroups.com'
Subject: RE: [kurento-public] Bad results in WebRTC -> RTC -> RTMP -> HLS using kurento, ffmpeg and nginx

I can't help with the video quality issues, but why not simplify your process flow? i.e. removing rtmp
  webrtc -> kurento -> rtp -> ffmpeg -> hls -> nginx
 
Sample ffmpeg parameters:
ffmpeg -protocol_whitelist file,udp,rtp -loglevel 99 -analyzeduration 2048M -probesize 2048M -y -nostdin -i /tmp/offer.sdp -threads 3 -s 480x270 -c:v libx264 -tune zerolatency -flags +global_header -movflags +faststart -pix_fmt yuv420p -profile:v main -level 3.1 -preset medium -b:v 400K -maxrate 500K -bufsize 2M -r 10 -g 20 -keyint_min 20 -sc_threshold 0 -x264opts keyint=5:min-keyint=1:level=41 -c:a libfdk_aac -profile:a aac_low -ac 1 -strict -2 -f tee -map 0:v -map 0:a [f=hls:hls_time=2:hls_list_size=10:hls_wrap=30:start_number=1]/tmp/480x270.m3u8
 
Misc additional performance improvements:
 - Write the hls files to a ram drive for i/o efficiency.
 - Re-order the webrtc sdp to prioritize h.264 and pcmu. This way, there's only one transcode (ffmpeg).
 
Hope this helps..
 


From: kur...@googlegroups.com [mailto:kur...@googlegroups.com] On Behalf Of alb...@axiomzen.co
Sent: Thursday, July 14, 2016 6:48 PM
To: kurento
Subject: [kurento-public] Bad results in WebRTC -> RTC -> RTMP -> HLS using kurento, ffmpeg and nginx

Albert Callarisa Roca

unread,
Jul 15, 2016, 9:02:10 AM7/15/16
to kur...@googlegroups.com
I think I know what's wrong.
I was running all those services inside a docker container and
probably reaching some cpu limit. I tried running the ffmpeg piece on
my machine instead of docker and it was quite smooth.
Anyway, thanks for the ffmpeg command, that's always useful :)

On 7/15/16, Mark Hassman <ma...@hassman.org> wrote:
> Whoops.. just noticed i was using an older dev server.. this is better -
> resolves key frame inconsistencies.
>
>
> -protocol_whitelist file,udp,rtp -analyzeduration 2048M -probesize 2048M -y
> -nostdin -i /tmp/offer.sdp -threads 3 -s 480x270 -c:v libx264 -tune
> zerolatency -flags +global_header +cgop -movflags +faststart -pix_fmt
> yuv420p -profile:v main -level 3.1 -preset medium -b:v 400K -maxrate 500K
> -bufsize 2M -r 10 -g 20 -keyint_min 20 -sc_threshold 0 -x264opts
> keyint=20:level=41 -c:a libfdk_aac -profile:a aac_low -ac 1 -strict -2 -f
> tee -map 0:v -map 0:a
> [f=hls:hls_time=2:hls_list_size=10:hls_wrap=30:start_number=1]/tmp/480x270.m
> 3u8
>
>
>
> _____
>
> From: Mark Hassman [mailto:ma...@hassman.org]
> Sent: Friday, July 15, 2016 6:46 AM
> To: 'kur...@googlegroups.com'
> Subject: RE: [kurento-public] Bad results in WebRTC -> RTC -> RTMP -> HLS
> using kurento, ffmpeg and nginx
>
>
> I can't help with the video quality issues, but why not simplify your
> process flow? i.e. removing rtmp
> webrtc -> kurento -> rtp -> ffmpeg -> hls -> nginx
>
> Sample ffmpeg parameters:
> ffmpeg -protocol_whitelist file,udp,rtp -loglevel 99 -analyzeduration 2048M
> -probesize 2048M -y -nostdin -i /tmp/offer.sdp -threads 3 -s 480x270 -c:v
> libx264 -tune zerolatency -flags +global_header -movflags +faststart
> -pix_fmt yuv420p -profile:v main -level 3.1 -preset medium -b:v 400K
> -maxrate 500K -bufsize 2M -r 10 -g 20 -keyint_min 20 -sc_threshold 0
> -x264opts keyint=5:min-keyint=1:level=41 -c:a libfdk_aac -profile:a aac_low
> -ac 1 -strict -2 -f tee -map 0:v -map 0:a
> [f=hls:hls_time=2:hls_list_size=10:hls_wrap=30:start_number=1]/tmp/480x270.m
> 3u8
>
> Misc additional performance improvements:
> - Write the hls files to a ram drive for i/o efficiency.
> - Re-order the webrtc sdp to prioritize h.264 and pcmu. This way, there's
> only one transcode (ffmpeg).
>
> Hope this helps..
>
>
>
> _____
>
> You received this message because you are subscribed to a topic in the
> Google Groups "kurento" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kurento/Y4jenK-CtaE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
--
Albert Callarisa Roca
Reply all
Reply to author
Forward
0 new messages