The identity plugin not being called per frame?

[Nicolas Dufresne]

I'm looking at this thread and couldn't make my mind what pipeline we are
referring to, it makes it's hard to help. Could meany things, could be QoS
doing as this is live encoding. A shot in the dark, but you could try
QoS=false on your sink maybe ?

Le jeu. 1 août 2019 14 h 25, pisymbol . <pisymbol at gmail.com> a écrit :

>
>
> On Thu, Aug 1, 2019 at 12:18 PM pisymbol . <pisymbol at gmail.com> wrote:
>
>>
>>
>> On Thu, Aug 1, 2019 at 11:12 AM pisymbol . <pisymbol at gmail.com> wrote:
>>
>>> Here is a short log of a pipeline starting and stopping:
>>>
>>> Available Sensor modes :
>>> 4104 x 3046 FR=30.000000 CF=0x1009208a10 SensorModeType=4
>>> CSIPixelBitDepth=12 DynPixelBitDepth=12
>>>
>>> NvCameraSrc: Trying To Set Default Camera Resolution. Selected
>>> sensorModeIndex = 0 WxH = 4104x3046 FrameRate = 30.000000 ...
>>>
>>>
>>> Available Sensor modes :
>>> 4104 x 3046 FR=30.000000 CF=0x1009208a10 SensorModeType=4
>>> CSIPixelBitDepth=12 DynPixelBitDepth=12
>>>
>>> NvCameraSrc: Trying To Set Default Camera Resolution. Selected
>>> sensorModeIndex = 0 WxH = 4104x3046 FrameRate = 30.000000 ...
>>>
>>> Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block
>>> : BlockType = 4
>>> ===== MSENC =====
>>> NvMMLiteBlockCreate : Block : BlockType = 4
>>> NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
>>> NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
>>> Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block
>>> : BlockType = 4
>>> ===== MSENC =====
>>> NvMMLiteBlockCreate : Block : BlockType = 4
>>> NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
>>> NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
>>> ===== MSENC blits (mode: 1) into tiled surfaces =====
>>> ===== MSENC blits (mode: 1) into tiled surfaces =====
>>> 2019-08-01 11:01:40,635 INFO: Stop recording...
>>> 2019-08-01 11:01:40,672 DEBUG: Stopping recorder pipeline...
>>> [21, 17]
>>>
>>> The above is the number of numbers the "handoff" callback was called for
>>> the recording. It should be the total number of frames in the stream that
>>> landed on the filesystem, right?
>>>
>>> But it's not...
>>>
>>> $ ffprobe -v fatal -count_frames -select_streams v:0 -show_entries
>>> stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1  capture.mkv
>>> 18
>>> $ ffprobe -v fatal -count_frames -select_streams v:1 -show_entries
>>> stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 capture.mkv
>>> 14
>>>
>>> What am I missing?
>>>
>>> The pertinent pipeline bits are:
>>>
>>> nvcamearsrc ! identity name=tapX ...
>>>
>>> Why are the number of frames LESS than the number of times "handoff" was
>>> called?
>>>
>>>
>> Is there a way to tell if a GstBuffer is actually frame data? (assuming
>> an element is sending buffers that are NOT frame data???)
>>
>
> If I move my callback deeper in my pipeline, I still see "drift" for lack
> of a better term. The number of callbacks seem to always be higher than the
> number of frames in the stream. I originally thought this was due to the
> fact that my stream is not fixed at 30fps but ffprobe does indeed count the
> frames one by one (I also used ffmpeg to count frames and the number
> matches the output of ffprobe).
>
> How can I be sure I'm pulling the exact number of frames that land in my
> MKV container (i.e. the stream)?
>
> -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/20190801/a452be8d/attachment-0001.html>