<div dir="ltr"><div dir="ltr"><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 8:36 PM Shishir Pokharel <<a href="mailto:akaccr@gmail.com" target="_blank">akaccr@gmail.com</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">Set <span style="background-color:rgba(255,255,255,0)">“wait_video on” parameter in your ngnix rtmp block. That should take care of your issue. </span><div><br><div id="gmail-m_6338306729184601123gmail-m_-117957644229436615AppleMailSignature" dir="ltr">/Shishir</div><div dir="ltr"><br>On Jun 22, 2019, at 07:50, Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 22 juin 2019 02 h 40, Chen Fisher <<a href="mailto:chen.fisher@gmail.com" 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 Sat, Jun 22, 2019 at 3:26 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" rel="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"><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 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 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 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 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 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 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" rel="noreferrer" target="_blank">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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</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"><div> </div></div></div> _______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.freedesktop.org" rel="noreferrer" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div> </div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>gstreamer-devel mailing list</span><br><span><a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a></span><br><span><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></span></div></blockquote></div></div>_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote><div><br></div><div><br></div><div><br></div>Well, I found the problem. The issue seems to be with the source encoding (and nothing to do with nginx-rtmp)<div><br></div><div>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.</div><div>rtmpsrc, which connects to the source stream, drops this packet and never passes to flvdemux.</div><div><br></div><div>rtmpsrc is based on librtmp which filters out this packet since the data is <= 5 bytes. See here:</div><div><a href="https://github.com/mstorsjo/rtmpdump/blob/master/librtmp/rtmp.c#L4528" target="_blank">https://github.com/mstorsjo/rtmpdump/blob/master/librtmp/rtmp.c#L4528</a><br></div><div><br></div><div>See attached image for the video data. It's missing the actual data.</div><div>ffmpeg works well. and I'm not sure why librtmp requires the video packet to have actual data. </div><div><br></div><div>Patching librtmp solves this particular problem, but causes issues down the stream with h264parse expecting the data as well.</div><div><br></div><div><br></div><div> </div></div> </div>