<div dir="ltr"><div><div><div><div><div>Hi Nicolas.<br><br></div>I have tested the flvmux code with your new code and to make it short, it does not work correctly with YouTube Live. In fact, if released implemented like that, GStreamer can no longer be used to feed a stream to YouTube live. However something is changed to the better and will be described in details below.<br>
<br></div>Now first for the test conditions:<br><br></div>GStreamer-1.4.0 is used to produce a H.264/AAC stream terminating in a matroska-muxed tcpserversink like this:<br><br><div style="margin-left:40px">/usr/local/bin/gst-launch-1.0 -v fdsrc fd=0 do-timestamp=true ! queue ! audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2 ! queue ! audioconvert ! audiorate ! faac bitrate=128000 ! audio/mpeg,mpegversion=4, stream-format=raw ! aacparse ! queue ! muxer. shmsrc socket-path=/tmp/mixer1 do-timestamp=true is-live=true ! video/x-raw, format=(string)BGRA, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, width=(int)1280, height=(int)720, framerate=(fraction)24/1 ! queue leaky=2 ! videoconvert ! x264enc bitrate=3500 tune=zerolatency speed-preset=5 key-int-max=48 bframes=0 ! video/x-h264, alignment=au, stream-format=byte-stream, profile=(string)main ! h264parse ! queue ! matroskamux name=muxer streamable=true ! queue ! tcpserversink host=0.0.0.0 port=5010 sync-method=2 recover-policy=keyframe<br>
</div><br></div>The the following pipeline is used to send the stream to YouTube Lives server:<br><div><br><div style="margin-left:40px">/usr/local/bin/gst-launch-1.0 -v -e --gst-debug=rtmpsink:4,flvmux:4 tcpclientsrc host=localhost port=5010 do-timestamp=true ! queue ! matroskademux name=demuxer ! queue ! aacparse ! muxer. demuxer. ! queue ! h264parse ! flvmux name=muxer streamable=true ! queue ! rtmpsink location=$location<br>
</div><br></div><div>What goes into the $location parameter is described here <a href="https://sourceforge.net/p/snowmix/wiki/Snowmix%20and%20CDNs/">https://sourceforge.net/p/snowmix/wiki/Snowmix%20and%20CDNs/</a><br><br>
</div><div>The above described works with GStreamer-1.4.0<br><br></div><div>Now if the bframes parameter is changed to lets say bframes=2, the pipeline sending the stream to YouTube will fail and produce the following output<br>
<br><div style="margin-left:40px">Setting pipeline to PLAYING ...<br>New clock: GstSystemClock<br>0:00:01.057591202 31022       0x8a2f70 WARN                rtmpsink gstrtmpsink.c:258:gst_rtmp_sink_render:<rtmpsink0> error: Failed to write data<br>
ERROR: from element /GstPipeline:pipeline0/GstRTMPSink:rtmpsink0: Could not write to resource.<br>Additional debug info:<br>gstrtmpsink.c(258): gst_rtmp_sink_render (): /GstPipeline:pipeline0/GstRTMPSink:rtmpsink0:<br>Failed to write data<br>
EOS on shutdown enabled -- waiting for EOS after Error<br>...<br></div><br></div><div>This is because YouTubes server sees an error in the stream and shuts down the connection.<br><br></div><div>Now one can say that bframes=2 should not work when tune=zerolatency is set, but apparently it does.<br>
<br></div><div>One important thing to bear in mind is that if you change the settings of your stream you send to YouTube, you may have to create a new event. If you send a stream with one set of parameters to YouTube and then later change the parameters, YouTube's system may not like it. So always create a new Live Event, when you change stream parameters.<br>
<br></div><div>Now when I used the new code made available by Nicolas, then when streaming  bframes=0 to YouTube Live, the pipeline works nicely and YouTubes system/interface says that the 'Stream is Good', but their system can't enter 'Preview State' where the stream can be seen by the Operator and as such, it can never go into Live Stream mode. So the code changes now prevents one from using GStreamer to stream to YouTube Live.<br>
<br></div><div>That said, when using the new code, creating a new event and setting bframes=2, the rtmpsink pipeline no longer fails as YouTube now longer close the connections as faulty. However, even with bframes and the new flvmux code, I still can't get to the Preview State so something in YouTube still think that's something is not quite right with the stream (with or without bframes). I could guess that somehow something with the timing PTS/DTS of the frames are still not quite right, but I can't figure out what. Still the system works with Adobes FLME as a reference system with and without B-frames.<br>
</div><div><br></div><div>Hope all this helps.<br><br></div>Best regards<br></div>Peter Maersk-Moller<br><div><div><div><div><br><br><div><div><br><br></div></div></div></div></div></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sun, Aug 3, 2014 at 5:15 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas.dufresne@collabora.com" target="_blank">nicolas.dufresne@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Peter,<br>
<br>
I've came across a report recently that revealed that in presence of<br>
B-Frames flvmux would create invalid FLV stream that get rejected by the<br>
different streaming servers base on RTMP. Patches are at:<br>
<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=731352" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=731352</a><br>
<br>
If you have time, I would really like your input on these. Just in case,<br>
B-Frames are enabled with default x264enc settings (defaults are pretty<br>
much CD quality level iirc).<br>
<br>
cheers,<br>
Nicolas<br>
<br>
<br>
<br>
</blockquote></div><br></div>