Playing a live RTMP (flv, h264) stream

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Playing a live RTMP (flv, h264) stream

Chen Fisher
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....

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Nicolas Dufresne-5
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Chen Fisher


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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?
 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Nicolas Dufresne-5


Le ven. 21 juin 2019 19 h 10, Chen Fisher <[hidden email]> a écrit :


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Chen Fisher


On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <[hidden email]> wrote:


Le ven. 21 juin 2019 19 h 10, Chen Fisher <[hidden email]> a écrit :


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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?
 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Nicolas Dufresne-5


Le sam. 22 juin 2019 02 h 40, Chen Fisher <[hidden email]> a écrit :


On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <[hidden email]> wrote:


Le ven. 21 juin 2019 19 h 10, Chen Fisher <[hidden email]> a écrit :


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:



Le sam. 22 juin 2019 02 h 40, Chen Fisher <[hidden email]> a écrit :


On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <[hidden email]> wrote:


Le ven. 21 juin 2019 19 h 10, Chen Fisher <[hidden email]> a écrit :


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Playing a live RTMP (flv, h264) stream

Chen Fisher

On Sat, Jun 22, 2019 at 8:36 PM Shishir Pokharel <[hidden email]> wrote:
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 <[hidden email]> wrote:



Le sam. 22 juin 2019 02 h 40, Chen Fisher <[hidden email]> a écrit :


On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <[hidden email]> wrote:


Le ven. 21 juin 2019 19 h 10, Chen Fisher <[hidden email]> a écrit :


On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



Well, I found the problem. The issue seems to be with the source encoding (and nothing to do with nginx-rtmp)

flvdemux expects avc_packet_type to be 0 to get the codec data, but as I wrote before, the packet is never received by flvdemuxer.
rtmpsrc, which connects to the source stream, drops this packet and never passes to flvdemux.

rtmpsrc is based on librtmp which filters out this packet since the data is <= 5 bytes. See here:

See attached image for the video data. It's missing the actual data.
ffmpeg works well. and I'm not sure why librtmp requires the video packet to have actual data. 

Patching librtmp solves this particular problem, but causes issues down the stream with h264parse expecting the data as well.


 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Screen Shot 2019-06-26 at 9.24.25.png (105K) Download Attachment