Playing a live RTMP (flv, h264) stream

[Shishir Pokharel]

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