Playing a live RTMP (flv, h264) stream

[Nicolas Dufresne]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190622/606b763b/attachment.html>