Timestamp H.264 frame ramp up?

[Nicolas Dufresne]

Le sam. 6 juill. 2019 08 h 10, pisymbol . <pisymbol at gmail.com> a écrit :

>
>
> On Fri, Jul 5, 2019 at 7:36 PM pisymbol . <pisymbol at gmail.com> wrote:
>
>>
>>
>> On Thu, Jul 4, 2019 at 11:44 PM Vinod Kesti <vinodkesti at yahoo.com> wrote:
>>
>>> pisymbol
>>>
>>> It may be source giving wrong delta.
>>>
>>> What is a source in your pipeline
>>> Do similar analysis immediately after the source. That would give you
>>> some
>>> Idea.
>>>
>>
>> Vinod that is a great question. I am going to exactly that. Will report
>> back.
>>
>>
> [
>     {
>         "delta": 0,
>         "frame": 0,
>         "timestamp": 710794680
>     },
>     {
>         "delta": 31127306,
>         "frame": 1,
>         "timestamp": 741921986
>     },
>     {
>         "delta": 8828365,
>         "frame": 2,
>         "timestamp": 750750351
>     },
>     {
>         "delta": 21636578,
>         "frame": 3,
>         "timestamp": 772386929
>     },
>     {
>         "delta": 32609730,
>         "frame": 4,
>         "timestamp": 804996659
>     },
>     {
>         "delta": 33260030,
>         "frame": 5,
>         "timestamp": 838256689
>     },
>     {
>         "delta": 32897792,
>         "frame": 6,
>         "timestamp": 871154481
>     },
> ...
>
> So it's slightly better. But notice frame 2 and 3 have some kinda weird
> buf.pts timestamps before it starts to level out to about 30fps. The source
> is nvcamerasrc (i.e. nvcamerasrc (bunch of options) ! identity ..).
>
> Is this just some kind of pipeline jitter?
>

This looks like frame drops. GStreamer uses a push back model. So what I
imagine here is that nvcamsrc produced a buffer, push which simply get
queued. Then it produces a second buffer, but this time it's block for a
certain amount of time (about 2-3 frames, probably initialization time,
NVidia stuff is know for having long alloc/init time). In parallel to that,
the capture HW ends up reusing that current buffer, because it might not
have any other to capture in, so buffers are effectively being dropped.

This is one a the wide variety of possibilities. Without traces from
nvcamsrc and it's code, we are limited to guessing.

Nicolas


> -aps
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190706/d14a2930/attachment.html>