example-webrtc-applications
example-webrtc-applications copied to clipboard
Twitch "Conversion failed!" with panic: write |1: broken pipe
Your environment.
- Version: v3
- Browser: Chrome or Firefox
- Other Information
Connection State has changed connected
Track has started, of type 111: opus
Track has started, of type 96: VP8
WebM saver has started with video width=640, height=480
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-opencl --enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, matroska,webm, from 'pipe:0':
Metadata:
encoder : ebml-go.webm.BlockWriter
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
Metadata:
title : Audio
Stream #0:1(eng): Video: vp8, yuv420p(progressive), 640x480, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
Metadata:
title : Video
Stream mapping:
Stream #0:1 -> #0:0 (vp8 (native) -> h264 (libx264))
Stream #0:0 -> #0:1 (opus (native) -> aac (native))
[libx264 @ 0x7fe6bb80f800] using SAR=1/1
[libx264 @ 0x7fe6bb80f800] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0x7fe6bb80f800] profile High, level 3.0
[libx264 @ 0x7fe6bb80f800] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=50 keyint_min=5 scenecut=40 intra_refresh=0 rc_lookahead=10 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=3000 vbv_bufsize=6000 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00
Output #0, flv, to 'rtmp://REDACTED_FOR_PRIVACY':
Metadata:
encoder : Lavf58.20.100
Stream #0:0(eng): Video: h264 (libx264) ([7][0][0][0] / 0x0007), yuv420p, 640x480 [SAR 1:1 DAR 4:3], q=-1--1, 30 fps, 1k tbn, 30 tbc (default)
Metadata:
title : Video
encoder : Lavc58.35.100 libx264
Side data:
cpb: bitrate max/min/avg: 3000000/0/0 buffer size: 6000000 vbv_delay: -1
Stream #0:1(eng): Audio: aac (LC) ([10][0][0][0] / 0x000A), 44100 Hz, stereo, fltp, 160 kb/s (default)
Metadata:
title : Audio
encoder : Lavc58.35.100 aac
**av_interleaved_write_frame(): End of fileB** time=00:00:46.39 bitrate= 473.6kbits/s speed=0.999x
Last message repeated 1 times
[flv @ 0x7fe6bb80e600] Failed to update header with correct duration.
[flv @ 0x7fe6bb80e600] Failed to update header with correct filesize.
**Error writing trailer of rtmp://REDACTED_FOR_PRIVACY: End of file**
frame= 575 fps= 12 q=27.0 Lsize= 2682kB time=00:00:46.71 bitrate= 470.3kbits/s speed=0.998x
video:1935kB audio:920kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[libx264 @ 0x7fe6bb80f800] frame I:17 Avg QP:19.12 size: 16985
[libx264 @ 0x7fe6bb80f800] frame P:294 Avg QP:21.21 size: 4813
[libx264 @ 0x7fe6bb80f800] frame B:264 Avg QP:22.01 size: 1345
[libx264 @ 0x7fe6bb80f800] consecutive B-frames: 30.3% 20.9% 14.1% 34.8%
[libx264 @ 0x7fe6bb80f800] mb I I16..4: 28.2% 30.7% 41.0%
[libx264 @ 0x7fe6bb80f800] mb P I16..4: 13.3% 8.0% 2.8% P16..4: 25.6% 6.8% 3.0% 0.0% 0.0% skip:40.6%
[libx264 @ 0x7fe6bb80f800] mb B I16..4: 3.9% 1.7% 0.2% B16..8: 11.7% 3.4% 0.4% direct: 6.0% skip:72.8% L0:51.3% L1:42.3% BI: 6.4%
[libx264 @ 0x7fe6bb80f800] 8x8 transform intra:32.2% inter:38.0%
[libx264 @ 0x7fe6bb80f800] coded y,uvDC,uvAC intra: 45.2% 53.5% 21.3% inter: 9.0% 17.2% 0.9%
[libx264 @ 0x7fe6bb80f800] i16 v,h,dc,p: 27% 29% 40% 4%
[libx264 @ 0x7fe6bb80f800] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 31% 23% 1% 3% 5% 3% 2% 3%
[libx264 @ 0x7fe6bb80f800] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 38% 11% 3% 3% 5% 4% 4% 3%
[libx264 @ 0x7fe6bb80f800] i8c dc,h,v,p: 54% 26% 16% 3%
[libx264 @ 0x7fe6bb80f800] Weighted P-Frames: Y:3.7% UV:2.0%
[libx264 @ 0x7fe6bb80f800] kb/s:430.43
[aac @ 0x7fe6bc81aa00] Qavg: 9015.414
**Conversion failed!
panic: write |1: broken pipe
panic: write |1: broken pipe**
goroutine 65 [running]:
github.com/at-wat/ebml-go/mkvcore.NewSimpleBlockWriter.func1(0x1639600, 0xc0004bc1e0)
/Users/denoue/go/pkg/mod/github.com/at-wat/[email protected]/mkvcore/blockwriter.go:76 +0x3e
github.com/at-wat/ebml-go/mkvcore.NewSimpleBlockWriter.func4.1(0xc00010bea8, 0xc00010beb8, 0xc000110840, 0xc0001ec0e0, 0xc000465620)
/Users/denoue/go/pkg/mod/github.com/at-wat/[email protected]/mkvcore/blockwriter.go:178 +0x149
panic(0x1505440, 0xc0004bc180)
/usr/local/go/src/runtime/panic.go:969 +0x166
github.com/at-wat/ebml-go/mkvcore.NewSimpleBlockWriter.func1(0x1639600, 0xc0004bc180)
/Users/denoue/go/pkg/mod/github.com/at-wat/[email protected]/mkvcore/blockwriter.go:76 +0x3e
github.com/at-wat/ebml-go/mkvcore.NewSimpleBlockWriter.func4(0xc000110840, 0xc0001ec0e0, 0xc000465620, 0xc0004657a0, 0xc0004655c0, 0x7fff)
/Users/denoue/go/pkg/mod/github.com/at-wat/[email protected]/mkvcore/blockwriter.go:238 +0x475
created by github.com/at-wat/ebml-go/mkvcore.NewSimpleBlockWriter
/Users/denoue/go/pkg/mod/github.com/at-wat/[email protected]/mkvcore/blockwriter.go:156 +0x70a
exit status 2
What did you do?
I ran the twitch sample by sending my SDP using EXPORT SDP=... and then echo $SDP | go run main.go
What did you expect?
I expect ffmpeg to keep converting the incoming RTP audio and video packets and pushing the converted audio/video to my RTMP endpoint.
What happened?
Everything works for a few seconds (and I can see my stream for a little while, even though it's highly pixelated), but then it fails with the stack trace shown above.
:( that's no good!
Honestly I think https://github.com/pion/webrtc/tree/master/examples/rtp-forwarder is better. Having to put stuff inside an MKV -> rtmp is really wasteful.
If you do the example ^ you will waste a lot less CPU cycles!
Thanks Sean for pointing me in the right direction. I wouldn’t have realized that this forwarder example was all I needed.
As you said, it would simply forward the RTP packets to whatever app is able to receive them, in my case ffmpeg.
So we don’t have to decode in Pion and then feed to ffmpeg: we can just forward and have ffmpeg do its thing, potentially encoding Opus to AAC and sending the result to my existing RTMP listening endpoint, right?
I’ll give it a try. It’s probably a very frequent use case for Pion users: if I end up writing a good sample I’ll post it.
By the way: in your experience should I prefer gstreamer to ffmpeg for this use case?
Yea exactly! Right now we waste CPU cycles because our webm
stuff only supports VP8. But with the rtp-forwarding style you can pass the same H264 packets all the way through!
The more examples the better, that would be amazing :D I love just have a grab bag of examples to inspire people. My biggest motivation for Pion is to kickstart people to go do interesting things. I like that these examples don't just help people solve problems, but maybe show them what else could be done.
If you are interested in blogging/writing I would love to link to that as well! Really w/e you feel most inspired to do. I am also up for massive refactors/changes if you think that is best :)
To follow up on this, the rtp-forwarder example worked well coupled with this FFMPEG command line to send to an existing RTMP:
ffmpeg -protocol_whitelist file,udp,rtp -i rtp-forwarder.sdp -c:v libx264 -codec:a aac -f flv -strict -2 rtmp://YOUR_RTMP_URL
-c:v libx264 -c:a aac
literally means to re-encode anything in the input to those two codecs, so you'll be using a lot of CPU. If you wanted to only convert audio, while keeping the input video as-is, use this: -c:v copy -c:a aac
Yes and so I would need to change the accepted video codec in https://github.com/pion/webrtc/blob/master/examples/rtp-forwarder/main.go to specify H264 instead of the current VP8.
Thanks!
Hey @Sean-Der and @ldenoue, thanks for the great comments. I am currently working on something like this, but I need get the H264 video, for my case other codecs are impractical.
The question is, after changing and registering the H264 codec like this:
m.RegisterCodec(webrtc.NewRTPH264Codec(webrtc.DefaultPayloadTypeH264, 90000))
The ffmpeg is now reporting strange informations about the video and VLC is not working at all with the default SDP file of the example.
[sdp @ 0x55e655982180] Could not find codec parameters for stream 1 (Video: h264, 1 reference frame, none(left)): unspecified size
Searching about the SDP format, I get this pattern:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=Pion WebRTC
c=IN IP4 127.0.0.1
t=0 0
m=audio 2406 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
m=video 2535 RTP/AVP 102
a=rtpmap:102 H264/90000
But.... again the same error. Any ideas?
Oh, my mistake, after another research about SDP (and fixing the UDP ports) the video is now working perfectly.
The correct SDP file for my case is:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=Pion WebRTC
c=IN IP4 127.0.0.1
t=0 0
m=audio 4000 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
m=video 4002 RTP/AVP 102
a=rtpmap:102 H264/90000
Thank you guys.
That's awesome, glad it worked @mqgmaster. Always excited to see people use Pion :)
Sorry I have been slow on responses, my backlog grows faster then I can close stuff
Regarding RTP Forwarders, is it possible to forward rtp to some other ip address instead of localhost??
Hey @xoraingroup
Yes that is easily possible! pion/webrtc
itself doesn't have a rtp forwarder
itself, but it gives you access to the RTP packets.
You can change this line to be w/e address you want!
Hey @Sean-Der , In continuation to this issue. One of the possible solution is at hexcord-mediaserver or v2.0 of my project which i have tested. Both implement webrtc v 3.0.