Playing a live RTMP (flv, h264) stream

[Nicolas Dufresne]

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.


> _______________________________________________
> 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/20190621/1545d4d6/attachment.html>