Playing a live RTMP (flv, h264) stream

[Chen Fisher]

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