example-webrtc-applications icon indicating copy to clipboard operation
example-webrtc-applications copied to clipboard

Twitch "Conversion failed!" with panic: write |1: broken pipe

Open ldenoue opened this issue 3 years ago • 12 comments

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.

ldenoue avatar Sep 18 '20 08:09 ldenoue

:( 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!

Sean-Der avatar Sep 18 '20 22:09 Sean-Der

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?

ldenoue avatar Sep 19 '20 11:09 ldenoue

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 :)

Sean-Der avatar Sep 20 '20 05:09 Sean-Der

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

ldenoue avatar Sep 21 '20 17:09 ldenoue

-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

j1elo avatar Sep 21 '20 20:09 j1elo

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!

ldenoue avatar Sep 21 '20 20:09 ldenoue

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?

mqgmaster avatar Oct 11 '20 23:10 mqgmaster

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.

mqgmaster avatar Oct 12 '20 21:10 mqgmaster

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

Sean-Der avatar Oct 14 '20 04:10 Sean-Der

Regarding RTP Forwarders, is it possible to forward rtp to some other ip address instead of localhost??

xoraingroup avatar Oct 29 '20 16:10 xoraingroup

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!

Sean-Der avatar Nov 06 '20 06:11 Sean-Der

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.

mohit810 avatar Nov 09 '20 14:11 mohit810