flvdemux working .. sometimes

[Peter Maersk-Moller]

Hi Sebastian

On Tue, May 31, 2016 at 8:17 AM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> > QUEUE="queue max-size-time=0 max-size-bytes=0 max-size-buffers=0"
> > LOCATION=rtmp://192.168.3.100/live/mykey3
> >
> > gst-launch-1.0 -v                        \
> >         rtmpsrc location=$LOCATION      !\
> >         $QUEUE                          !\
> >         flvdemux name=demux             !\
> >         $QUEUE                          !\
> >         aacparse                        !\
> >         avdec_aac                       !\
> >         autoaudiosink sync=0 demux.     !\
> >         $QUEUE                          !\
> >         h264parse                       !\
> >         avdec_h264                      !\
> >         $QUEUE                          !\
> >         videoconvert                    !\
> >         autovideosink sync=0
> > [...]
>
> This means that one of the queues you have there is not linked until
> no-more-pads happens on the demuxer. Give proper names to the queues to
> know which one it is.
>

I named the pipes uniquely and found the queue starving is the queue
between the flvmux and h264parse.

0:00:06.310136630 10614       0xb6f990 WARN                 default
grammar.y:506:gst_parse_no_more_pads:<demux> warning: Delayed linking
failed.
0:00:06.310215513 10614       0xb6f990 WARN                 default
grammar.y:506:gst_parse_no_more_pads:<demux> warning: failed delayed
linking some pad of GstFlvDemux named demux to some pad of GstQueue named
qh264
WARNING: from element /GstPipeline:pipeline0/GstFlvDemux:demux: Delayed
linking failed.
Additional debug info:
./grammar.y(506): gst_parse_no_more_pads ():
/GstPipeline:pipeline0/GstFlvDemux:demux:
failed delayed linking some pad of GstFlvDemux named demux to some pad of
GstQueue named qh264
0:00:28.189631062 10614       0xb6f990 WARN                flvdemux
gstflvdemux.c:1413:gst_flv_demux_parse_tag_video:<demux> Signaled
no-more-pads already but had no video pad -- ignoring


> Most likely the problem here is that the audio or video stream are not
> found in the container early enough, and then the demuxer decides that
> there is no audio or video. This would be related to
>   https://bugzilla.gnome.org/show_bug.cgi?id=764260


Reading through it, it sounds like that. That bug however is marked as an
enhancement and it appear not to be moving very fast :-( Note that the
problematic rtmp/flv stream is muxed and produced by GStreamer and not an
external tool. I tried to change the block-size in the flvmux, but that
does not seem to have any effect on this problem.

Interesting thing for delay in sync. If I start op the pipeline producing
the stream and then start the playing pipeline without sync for audio and
video sink, the video displayed is only a few hundred ms after what the
camera records. The audio is around 5 seconds late. But if I start the
player first, several seconds before I start producing the stream, the
audio is less than 1000 ms late. Maybe the demuxer introduces a delay it
doesn't have to introduce?

Are there any plans to add a rtmpserversrc module to GStreamer, a module
that could act as an rtmp server receiving a RTMP stream from a rtmpsink
module or another third party encoded rtmp (some cameras does rtmp although
the current issue with audio/video sync and no-pads doesn't make it very
attractive) ?

Thanks for the help

Peter

>
>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
> _______________________________________________
> 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/20160601/4d3cb186/attachment.html>