Timestamp H.264 frame ramp up?

[pisymbol .]

On Sat, Jul 6, 2019 at 9:12 AM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

>
>
> 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.
>

Let me ask NVidia directly since you maybe right: This may have more to do
with the hardware and their plugin than gstreamer itself.

One thing I also noticed using nvcamerasrc is that when I use
max-file-duration of 10s I don't get 300 frames per capture file (I seem to
be off anywhere from 30-50 frames during each rollover despite my pipeline
fixed at 30fps).

Not sure yet what this is all about either.

-aps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190706/a42605d3/attachment-0001.html>