Variable framerate/fps input video encoding questions

[Nicolas Dufresne]

Le jeudi 18 juillet 2019 à 08:19 -0500, jles a écrit :
> Hi Nicolas,
> 
> Thanks for your reply.
> 
> 
> Nicolas Dufresne-5 wrote
> > What is not possible which this, is for GStreamer to evaluate the
> > latency requires if you would like to do live streaming out of it. Best
> > is to pretend you are doing 10fps, and the latency calculation will be
> > made from that, then having early frames should not be a problem.
> 
> Do you mean that for a live source like this case it would be convenient to
> set the appsrc caps framerate to the lowest expected fps?

If you are writing to filesrc, it does not matter, but if you re-
transmit let's say over RTP, then yes, picking the lowest fps will
setup the worst possible latency on your pipeline and ensure packets
aren't late even at the lowest.

> 
> If I'm doing this the resulting encoded and container file after mpegtsmux
> will have that let's say 10fps low framerate timestamps....so what would
> happen if the framerate is increased during that time let's say to 400fps
> would all frames be discarded? 

What about setting the appsrc caps property to lowest fps, and then use
videorate drop-only=1 with a caps filter afert that match the maximum
you'd like to record ?

> 
>  
> 
> Nicolas Dufresne-5 wrote
> > Note that videorate will likely drop or add frames to you stream, is
> > this really what you are looking for ?
> 
> You are right it might be no ideal here, I used it initially because I tried
> to set a variable framerate in the appsrc caps and it was the only way to
> don't get a "no enough resources available" error from the encoder. But now
> I'm setting a appsrc caps constant framerate  I'll  delete it from the
> pipeline...
> 
> 
> 
> Nicolas Dufresne-5 wrote
> > That can only be a miss-calculation of timestamp on your end. Using
> > appsrc requires good care on crafting correct timestamps.
> 
> Agree this could it be the key of everything but I'm confuse with this, what
> I've done is:
> I do the calculation getting the appsrc clock (gst_element_get_clock) and
> base time (gst_element_get_base_time) after I get the time of the computed
> clock (gst_clock_get_time)  and then I calculate the difference:
> 
> 		clock = gst_element_get_clock (GST_ELEMENT_CAST (appsrc));
> 		if (clock) {
> 		 base_time =
> 		 gst_element_get_base_time (GST_ELEMENT_CAST (appsrc));
> 		 now = gst_clock_get_time (clock);
> 		 if (now > base_time)
> 			 now -= base_time;
> 		 else
> 			 now = 0;
> 
> 		 gst_object_unref (clock);
> 		 GST_BUFFER_PTS (buffer) = now;
> 		 GST_BUFFER_DTS (buffer) = now;
> 		}
> I compared with the actual camera framerate (fps given by the camera) and
> matches so I assume that the calculation is correct...
> I'm a bit lost here, I looked around and I couldn't find any good
> tutorial/examples on how to calculate properly timestamps with appsrc, 
> what would it be the best way/idea to compute properly timestamps?
> 
> On the other hand I tried  to change the encoder target bit rate and this
> also affects to the resulting playback speed...so could it be instead a
> timestamp issue a bandwidth one?
> 
> Thanks.
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190718/6ff99a5c/attachment-0001.sig>