Problem with videorate

Frédéric Sallé salle.frederic at gmail.com
Mon Dec 9 06:21:45 PST 2013


Done as bug #720104
<https://bugzilla.gnome.org/show_bug.cgi?id=720104>
Best Regards,
Frédéric

<https://bugzilla.gnome.org/show_bug.cgi?id=720104>
On 05/12/2013 09:09, Sebastian Dröge wrote:
> On Di, 2013-12-03 at 14:12 +0100, Frédéric Sallé wrote:
>> 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 ?
> Unfortunately there's no workaround for that right now, and your
> analysis is correct :) What you want is a videorate element that is
> suitable for live scenarios, and inserts new frames based on a timeout
> instead of timestamps of the buffers.
>
> Could you file a feature request at http://bugzilla.gnome.org against
> GStreamer?
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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


More information about the gstreamer-devel mailing list