<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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 <div class="moz-cite-prefix">On 03/12/2013 10:25, Tim Müller wrote: </div> <blockquote cite="mid:1386062709.6949.7.camel@zingle" type="cite"> <pre wrap="">On Tue, 2013-12-03 at 09:26 +0100, Frédéric Sallé wrote: Hi Frédéric, </pre> <blockquote type="cite"> <pre wrap="">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). </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> </body> </html>