The identity plugin not being called per frame?

[pisymbol .]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190801/c497d341/attachment.html>