Playing a live RTMP (flv, h264) stream

Sun Jun 30 06:04:49 UTC 2019

On Sat, Jun 22, 2019 at 8:36 PM Shishir Pokharel <akaccr at gmail.com> wrote:

> Set “wait_video on” parameter in your ngnix rtmp block. That should take
> care of your issue.
>
> /Shishir
>
> On Jun 22, 2019, at 07:50, Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>
>
>
> Le sam. 22 juin 2019 02 h 40, Chen Fisher <chen.fisher at gmail.com> a
> écrit :
>
>>
>>
>> On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <nicolas at ndufresne.ca>
>> wrote:
>>
>>>
>>>
>>> Le ven. 21 juin 2019 19 h 10, Chen Fisher <chen.fisher at gmail.com> a
>>> écrit :
>>>
>>>>
>>>>
>>>> On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <nicolas at ndufresne.ca>
>>>> wrote:
>>>>
>>>>> Le vendredi 21 juin 2019 à 18:35 +0300, Chen Fisher a écrit :
>>>>> > Hello all,
>>>>> >
>>>>> > I'm trying to play a live RTMP stream (from an nginx-rtmp source)
>>>>> and fail on flvdemux.
>>>>> > flvdemux is saying no video found after 6 seconds of audio, although
>>>>> it recognizes there's a video stream and there are video packets coming in
>>>>> even after it has decided there's no video.
>>>>> >
>>>>> > 0:00:08.776685700 42065 0x5633904b0ed0 ERROR               flvdemux
>>>>> gstflvdemux.c:1558:gst_flv_demux_parse_tag_video:<d> got H.264 video packet
>>>>> before codec data
>>>>> >
>>>>> > 0:00:08.778178000 42065 0x5633904b0ed0 DEBUG               flvdemux
>>>>> gstflvdemux.c:1295:gst_flv_demux_parse_tag_audio:<d> Signalling
>>>>> no-more-pads because no video stream was found after 6 seconds of audio
>>>>> >
>>>>> > 0:00:08.778626100 42065 0x5633904b0ed0 LOG                 flvdemux
>>>>> gstflvdemux.c:1469:gst_flv_demux_parse_tag_video:<d> parsing a video tag
>>>>> > 0:00:08.778649200 42065 0x5633904b0ed0 WARN                flvdemux
>>>>> gstflvdemux.c:1477:gst_flv_demux_parse_tag_video:<d> Signaled no-more-pads
>>>>> already but had no video pad -- ignoring
>>>>> >
>>>>> > I believe flvdemux is waiting for a keyframe (hence the first error)
>>>>> and it receives it after it has decided to abandon the video pad (6 seconds
>>>>> of audio data). Although keyframes are sent every 1 second in the source
>>>>> stream....
>>>>>
>>>>> This normally means there was audio for 6 second without any video
>>>>> packet. In this case, flvdemux assume that the presence of the video
>>>>> was a lie. There is not support for renegotiation. Best is to record a
>>>>> small portion of the RTMP stream so we can analyze it offline.
>>>>>
>>>>> >
>>>>> > My gst pipeline:
>>>>> > gst-launch-1.0 rtmpsrc location=rtmp://<source of rtmp stream> !
>>>>> flvdemux ! flvmux ! filesink location=f1
>>>>> >
>>>>> > I also tried several options with queues, but the flvdemux fails to
>>>>> delay link the video pad for the above reasons.
>>>>> >
>>>>> > Any help would be appreciated!
>>>>> > Thanks!
>>>>> > _______________________________________________
>>>>> > gstreamer-devel mailing list
>>>>> > gstreamer-devel at lists.freedesktop.org
>>>>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I have extended the "no more pads" signal from 6 to 60 seconds to see
>>>> what happens.
>>>> There *are* video packets. There *are* keyframes coming in but from the
>>>> gstflvdemux.c code I see the codec type is always 7 and this does not allow
>>>> the flvdemux to finalize the video info.
>>>>
>>>> This is a snippet log, grepped for codec type:
>>>> 0:00:30.859649100 42107 0x5640c68a22d0 LOG                 flvdemux
>>>> gstflvdemux.c:1529:gst_flv_demux_parse_tag_video:<d> video tag with codec
>>>> tag 7, keyframe (0) (flags 27)
>>>> 0:00:30.860473000 42107 0x5640c68a22d0 LOG                 flvdemux
>>>> gstflvdemux.c:1529:gst_flv_demux_parse_tag_video:<d> video tag with codec
>>>> tag 7, keyframe (1) (flags 17)
>>>> 0:00:30.861011000 42107 0x5640c68a22d0 LOG                 flvdemux
>>>> gstflvdemux.c:1529:gst_flv_demux_parse_tag_video:<d> video tag with codec
>>>> tag 7, keyframe (0) (flags 27)
>>>>
>>>> It goes on... the codec tag is always 7
>>>>
>>>> Any idea?
>>>>
>>>
>>> 7 means AVC another name for H264, so that's all right. Can you share a
>>> sample of this rtmp flv stream, this way we could reproduce and maybe come
>>> with a proper context to file a bug report.
>>>
>>> flvdemux does not need to sync on key frame, it does not need to provide
>>> any metadata in fact, since h264parse will take care.
>>>
>>>>
>>>>
>>
>> Yes, 7 (H264) is probably ok, but look at this line, avc_packet_type is
>> always 1:
>>
>> https://github.com/GStreamer/gst-plugins-good/blob/master/gst/flv/gstflvdemux.c#L1534
>>
>> It's always case 1 (H.264 NALU packet) so the demuxer never gets the
>> codec data.
>> But this seems very odd.
>>
>> ffmpeg plays this stream well and without any problems.
>>
>> Unfortunately, I cannot share a stream as this is private.
>>
>> Any other data I can provide that would help?
>>
>
> Normally a very small sample, like 2 frames should suffice and should work
> around license violation. At this stage, I cannot help further without
> doing a binary analyses.
>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Well, I found the problem. The issue seems to be with the source encoding
(and nothing to do with nginx-rtmp)

flvdemux expects avc_packet_type to be 0 to get the codec data, but as I
wrote before, the packet is never received by flvdemuxer.
rtmpsrc, which connects to the source stream, drops this packet and never
passes to flvdemux.

rtmpsrc is based on librtmp which filters out this packet since the data is
<= 5 bytes. See here:
https://github.com/mstorsjo/rtmpdump/blob/master/librtmp/rtmp.c#L4528

See attached image for the video data. It's missing the actual data.
ffmpeg works well. and I'm not sure why librtmp requires the video packet
to have actual data.

Patching librtmp solves this particular problem, but causes issues down the
stream with h264parse expecting the data as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190630/8c8bbfa7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2019-06-26 at 9.24.25.png
Type: image/png
Size: 78813 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190630/8c8bbfa7/attachment-0001.png>