input-selector pixelation when changing active-pad

[jaime]

Hi,

I have two h264 encoded rtsp sources from IP cameras, and I want to switch
between cameras every 20 seconds, and save the output into a file.  The
problem I face is when switching, I'm expecting a fast switch but it does a
slow pixelated transition between the previous active pad frames and the new
one.

The pipeline looks like:

rtspsrc -> queue -> depay -> input selector -> h264parse -> flvmux ->
filesink

I tried all the input-selector property combinations; cache-buffers
(TRUE|FALSE), sync-streams (TRUE | FALSE), sync-mode (0|1) with no different
results

I also tried:

rtspsrc -> queue -> depay -> h264parse -> input selector -> flvmux ->
filesink

With no different results either.

The libraries Gstreamer 1.8.3 on Ubuntu 16.04 LTS

Could you please shed some light here?


With regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Gst-Geek]

Hi Jaime,

You cannot switch between 2 video elementary stream. Unlike audio NALs, video NALs are not independently decoded. Video is generally ecncode in the form 

I B B P B B P B B P B B P B B P I B B P B B

P and B video frames can't be decoded without I and its dependent reference frame. When stream switches, it breaks dependency and produce pixelated video stream. 

To avoid this consider decoding stream and switch the raw frames.   

 

On Friday, 6 July, 2018, 3:57:00 PM IST, jaime <[hidden email]> wrote:

Hi,

I have two h264 encoded rtsp sources from IP cameras, and I want to switch

between cameras every 20 seconds, and save the output into a file.  The

problem I face is when switching, I'm expecting a fast switch but it does a

slow pixelated transition between the previous active pad frames and the new

one.

The pipeline looks like:

rtspsrc -> queue -> depay -> input selector -> h264parse -> flvmux ->

filesink

I tried all the input-selector property combinations; cache-buffers

(TRUE|FALSE), sync-streams (TRUE | FALSE), sync-mode (0|1) with no different

results

I also tried:

rtspsrc -> queue -> depay -> h264parse -> input selector -> flvmux ->

filesink

With no different results either.

The libraries Gstreamer 1.8.3 on Ubuntu 16.04 LTS

Could you please shed some light here?

With regards

--

Sent from: http://gstreamer-devel.966125.n4.nabble.com/

_______________________________________________

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

[jaime]

Thank you for your response.

I will give it a try and let you know.

My only worry is our device (quite small to contain price), could not handle
the encoding load.

Regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Arjen Veenhuizen]

You could also switch on I-frame boundaries only. This will require a bit of
programming though, checking each passing buffer on your first feed for the
Gst::BUFFER_FLAG_DELTA_UNIT flag. If I-frames are not aligned between
streams, you will have to wait for a passing i-frame on the second stream as
well.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Gst-Geek]

@Arjen Veenhuizen good thought. In that case Use pad probe can be used to
determine the incoming frame type.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jaime]

Thank you very much for your responses. Decoding and encoding was good enough

The pipe looks like:

rtspsrc -> queue -> depay -> parse -> vaapidecode -> input selector ->
vaapipostproc -> vaapih264enc -> flvmux -> queue-> rtmpsink


Now I am facing a new problem:

At certain point the encoder output show a duplicated or decreasing DTS.
Which usually matches the camera change in the input selector.
It does not happen everytime, it couid happen after 2 minutes or 20 minutes


vaapih264enc is using baseline profile.

Is it there anyway to force the stream activated on the input selector to be
always forward?
or
can we relabel the timestamps on the output?

Thank you again!



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel