RTMP/Flv streaming with B-Frames

[Peter Maersk-Moller]

Hi Nicolas.

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.

Now first for the test conditions:

GStreamer-1.4.0 is used to produce a H.264/AAC stream terminating in a
matroska-muxed tcpserversink like this:

/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

The the following pipeline is used to send the stream to YouTube Lives
server:

/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

What goes into the $location parameter is described here
https://sourceforge.net/p/snowmix/wiki/Snowmix%20and%20CDNs/

The above described works with GStreamer-1.4.0

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

Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:01.057591202 31022       0x8a2f70 WARN                rtmpsink
gstrtmpsink.c:258:gst_rtmp_sink_render:<rtmpsink0> error: Failed to write
data
ERROR: from element /GstPipeline:pipeline0/GstRTMPSink:rtmpsink0: Could not
write to resource.
Additional debug info:
gstrtmpsink.c(258): gst_rtmp_sink_render ():
/GstPipeline:pipeline0/GstRTMPSink:rtmpsink0:
Failed to write data
EOS on shutdown enabled -- waiting for EOS after Error
...

This is because YouTubes server sees an error in the stream and shuts down
the connection.

Now one can say that bframes=2 should not work when tune=zerolatency is
set, but apparently it does.

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.

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.

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.

Hope all this helps.

Best regards
Peter Maersk-Moller






On Sun, Aug 3, 2014 at 5:15 PM, Nicolas Dufresne <
nicolas.dufresne at collabora.com> wrote:

> Hi Peter,
>
> I've came across a report recently that revealed that in presence of
> B-Frames flvmux would create invalid FLV stream that get rejected by the
> different streaming servers base on RTMP. Patches are at:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=731352
>
> If you have time, I would really like your input on these. Just in case,
> B-Frames are enabled with default x264enc settings (defaults are pretty
> much CD quality level iirc).
>
> cheers,
> Nicolas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140811/ce33dc31/attachment.html>