Playing a live RTMP (flv, h264) stream

[Chen Fisher]

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