search

RidgeRun / gst-interpipe

GStreamer plug-in for interpipeline communication
Other
140 stars 63 forks source link

Freeze frames when using interpipe with an RTMP source #113

Open aidanbarrett opened 2 years ago

aidanbarrett commented 2 years ago

Using decodebin or uridecodebin with an rtmp source and interpipe results in a frozen frame on output.

This works fine:

 GST_DEBUG=2,*interpipe*:5 gst-launch-1.0  -v uridecodebin uri="https://mp4location.mp4" name=d ! queue ! interpipesink name=rtmp interpipesrc listen-to=rtmp format=time ! queue ! videoconvert !  autovideosink sync=false

But using a live rtmp source like in this example:

 GST_DEBUG=2,*interpipe*:5 gst-launch-1.0  -v uridecodebin uri="rtmp://xxxx/yyyy" name=d ! queue ! interpipesink name=rtmp interpipesrc listen-to=rtmp format=time ! queue ! videoconvert !  autovideosink sync=false

results in the first frame being launched and and then lots of the following warnings:

0:00:08.132744800 16386 0x7f5fec016760 WARN            videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<avdec_h264-0> Dropping frame due to QoS. start:6:29:07.304000000 deadline:0:00:05.160000000 earliest_time:6:29:02.144000000
0:00:08.189508800 16386 0x7f5fec016760 WARN            videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<avdec_h264-0> Dropping frame due to QoS. start:6:29:07.344000000 deadline:0:00:05.200000000 earliest_time:6:29:02.144000000
0:00:08.233281100 16386 0x7f5fec016760 WARN            videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<avdec_h264-0> Dropping frame due to QoS. start:6:29:07.384000000 deadline:0:00:05.240000000 earliest_time:6:29:02.144000000
0:00:08.251921200 16386 0x7f5fec016760 WARN            videodecoder gstvideodecoder.c:3298:gst_video_decoder_clip_and_push_buf:<avdec_h264-0> Dropping frame due to QoS. start:6:29:07.424000000 deadline:0:00:05.280000000 earliest_time:6:29:02.144000000

I've experimented with different options mentioned in this issue(https://github.com/RidgeRun/gst-interpipe/issues/109) like setting is-live=true as well as using stream-sync in interpipesrc.

Setting restart-ts seems to almost work but then uridecodebin and decodebin allow 1 frame through, freeze for 1s, buffer, repeat...

I've roughly recreated the uridecodebin pipeline and this seems to work fine:

GST_DEBUG=2,*interpipe*:5 gst-launch-1.0  -v rtmp2src location="rtmp://xxxx/yyyy" ! queue ! flvdemux name=demux ! queue ! h264parse ! avdec_h264 ! queue ! interpipesink sync=true name=rtmp interpipesrc listen-to=rtmp format=time ! videoconvert ! queue ! autovideosink sync=false
WeibinDai commented 2 years ago

I have met similar problem, maybe you also need set "interpipesink async=false" for the live source. You can have a try.

hatsch commented 7 months ago

i also ran into this problem today. one strange thing i've noticed. when i run the pipeline immediatly after the stream started publishing ( via nginx-rtmp) it works also through interpipes but if i wait for a couple of seconds i just get a frozen image.

hatsch commented 7 months ago

fyi: when setting qos=false on the final sink rtmp is working through interpipes i still need to find out if there are other implications in my application if turning off quality of service.

GST_DEBUG=1,*interpipe*:5 gst-launch-1.0 -v rtmp2src location=$RTMP_SRC ! flvdemux name=demux ! h264parse ! avdec_h264 ! queue ! identity name=id ! interpipesink sync=true name=rtmp drop=false interpipesrc listen-to=rtmp format=time stream-sync=restart-ts is-live=true ! videoconvert ! queue ! xvimagesink qos=false

i saw that centricular did it that way in their rtmp-slate-fallback example https://github.com/centricular/rtmp-slate-fallback