<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 21 juin 2019 19 h 10, Chen Fisher <<a href="mailto:chen.fisher@gmail.com" rel="noreferrer noreferrer" target="_blank">chen.fisher@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 6:51 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" rel="noreferrer noreferrer noreferrer" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le vendredi 21 juin 2019 à 18:35 +0300, Chen Fisher a écrit :<br>
> Hello all,<br>
> <br>
> I'm trying to play a live RTMP stream (from an nginx-rtmp source) and fail on flvdemux.<br>
> 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.<br>
> <br>
> 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<br>
> <br>
> 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<br>
> <br>
> 0:00:08.778626100 42065 0x5633904b0ed0 LOG flvdemux gstflvdemux.c:1469:gst_flv_demux_parse_tag_video:<d> parsing a video tag<br>
> 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<br>
> <br>
> 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....<br>
<br>
This normally means there was audio for 6 second without any video<br>
packet. In this case, flvdemux assume that the presence of the video<br>
was a lie. There is not support for renegotiation. Best is to record a<br>
small portion of the RTMP stream so we can analyze it offline.<br>
<br>
> <br>
> My gst pipeline:<br>
> gst-launch-1.0 rtmpsrc location=rtmp://<source of rtmp stream> ! flvdemux ! flvmux ! filesink location=f1<br>
> <br>
> I also tried several options with queues, but the flvdemux fails to delay link the video pad for the above reasons.<br>
> <br>
> Any help would be appreciated!<br>
> Thanks!<br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" rel="noreferrer noreferrer noreferrer" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" rel="noreferrer noreferrer noreferrer" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><div>I have extended the "no more pads" signal from 6 to 60 seconds to see what happens.</div><div>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.</div><div><br></div><div>This is a snippet log, grepped for codec type:</div>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)<br>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)<br>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)</div><div class="gmail_quote"><br></div><div class="gmail_quote">It goes on... the codec tag is always 7</div><div class="gmail_quote"><br></div><div class="gmail_quote">Any idea?<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">flvdemux does not need to sync on key frame, it does not need to provide any metadata in fact, since h264parse will take care.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><br></div></div></blockquote></div></div></div></blockquote><div><br></div><div><br></div><div>Yes, 7 (H264) is probably ok, but look at this line, avc_packet_type is always 1:<br><a href="https://github.com/GStreamer/gst-plugins-good/blob/master/gst/flv/gstflvdemux.c#L1534">https://github.com/GStreamer/gst-plugins-good/blob/master/gst/flv/gstflvdemux.c#L1534</a></div><div><br></div><div>It's always case 1 (H.264 NALU packet) so the demuxer never gets the codec data. </div><div>But this seems very odd.</div><div><br></div><div>ffmpeg plays this stream well and without any problems.</div><div><br></div><div>Unfortunately, I cannot share a stream as this is private. </div><div><br></div><div>Any other data I can provide that would help?</div><div> </div></div></div>