Problem with videorate

[Frédéric Sallé]

Hi Tim,

Thanks for your quick feedback.

With fakesink I see that the buffer timestamp are correct but the when 
sent over UDP there is still an issue.

It means that videorate do _NOT proactivaly_ inserts duplicated frame at 
the specified rate, it inserts duplicated frames with _timestamp IN THE 
PAST_ when it receive a new frame.

Very likely it 'works as coded' but it's counter intuitive ... :-)

On top of that this create a _major issue _when you try to mix that that 
stream with a _real time_ one as the pipeline create lag 'by design' ...

Is there a way to workaround that behaviour and to have a plugin that 
actually insert new duplicated frames at the specified rate ?

Thanks,
Frédéric



On 03/12/2013 10:25, Tim Müller wrote:
> On Tue, 2013-12-03 at 09:26 +0100, Frédéric Sallé wrote:
>
> Hi Frédéric,
>
>> On average it's ok, I have 20 images per seconds ...
>> HOWEVER, you can see  there is a burst of 10 images in ~50ms after
>> each input then nothing for~450ms
>>
>> It was clearly not the expected behavior for videorate...
>> Is there a way to make it smooth or it is a bug ??
>>
>> (I do not mention that the command above freeze my computer (it
>> happens 3 times already) after a while as I didn't try to reproduce
>> that issue for now).
> Just guessing here of course, but what might happen is that the video
> encoder blocks for too long, which means that packets are not read from
> the udp buffer, so some new packets will get dropped. You can fix that
> by inserting a
>
>    queue max-size-time=0 max-size-bytes=0 max-size-buffers=0
>
> after udpsrc (for example).
>
> Also, if you want to debug timestamps generated after videorate or the
> encoder, just use  fakesink silent=false and pass -v to gst-launch-1.0.
>
> Cheers
>   -Tim
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131203/eceeb4f7/attachment-0001.html>