<div dir="ltr"><div>Nicolas:</div><div><br></div><div>Can you please please pretty please answer me the following questions:</div><div><br></div><div>1) Would you expect the number of I420 frames to be equal to the H.264 ones?</div><div><br></div><div>i.e. nvcamerasrc ! identity name=count420 ! blah ! omxh264dec ! h264parse ! identity name=count264 ! mux out...</div><div><br></div><div>Again: Would you expect the number of "handoff" calls to be equal between the two identity plugins above?<br></div><div><br></div><div>2) In the above pipeline would you expect the number of frames counted by "count264" equal the number of frames muxed to a multifilesink? i.e. a 1-to-1 match between frames IN the file and frames caught by identity "count264"?<br></div><div><br></div><div>The problem I am seeing is that on stopping the pipeline, it looks like a few frames hit my handoff callback that don't make it out to the muxer and subsequently in the file stream. Is this because stopping is asynchronous, i.e. some frames hit handoff but never made it out to the muxer because the element is shutting down? Is there an idiom where I can guarantee a 1-to-1 match between number of frames that hit "handoff" vs number of frames that make it into the stream?</div><div><br></div><div>3) Is there any way to coordinate a multifilesink rollover (max-file-duration) event with a handoff function? I suspect the answer is no because there seems to be an inherit race condition between when my callback sees the event and when a handoff callback gets called for the "next frame" (or a frame that is past the file rollover)?</div><div><br></div><div>Thanks!<br></div><div><br></div><div>-aps<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 8:12 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>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 ?<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 1 août 2019 14 h 25, pisymbol . <<a href="mailto:pisymbol@gmail.com" target="_blank">pisymbol@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 12:18 PM pisymbol . <<a href="mailto:pisymbol@gmail.com" rel="noreferrer" target="_blank">pisymbol@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 11:12 AM pisymbol . <<a href="mailto:pisymbol@gmail.com" rel="noreferrer" target="_blank">pisymbol@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Here is a short log of a pipeline starting and stopping:</div><div><br>Available Sensor modes :<br>4104 x 3046 FR=30.000000 CF=0x1009208a10 SensorModeType=4 CSIPixelBitDepth=12 DynPixelBitDepth=12<br><br>NvCameraSrc: Trying To Set Default Camera Resolution. Selected sensorModeIndex = 0 WxH = 4104x3046 FrameRate = 30.000000 ...<br><br><br>Available Sensor modes :<br>4104 x 3046 FR=30.000000 CF=0x1009208a10 SensorModeType=4 CSIPixelBitDepth=12 DynPixelBitDepth=12<br><br>NvCameraSrc: Trying To Set Default Camera Resolution. Selected sensorModeIndex = 0 WxH = 4104x3046 FrameRate = 30.000000 ...<br><br>Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4<br>===== MSENC =====<br>NvMMLiteBlockCreate : Block : BlockType = 4<br>NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation<br>NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation<br>Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4<br>===== MSENC =====<br>NvMMLiteBlockCreate : Block : BlockType = 4<br>NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation<br>NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation<br>===== MSENC blits (mode: 1) into tiled surfaces =====<br>===== MSENC blits (mode: 1) into tiled surfaces =====<br>2019-08-01 11:01:40,635 INFO: Stop recording...<br>2019-08-01 11:01:40,672 DEBUG: Stopping recorder pipeline...<br>[21, 17]</div><div><br></div><div>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?</div><div><br></div><div>But it's not...</div><div><br></div><div>$ ffprobe -v fatal -count_frames -select_streams v:0 -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1  capture.mkv</div><div>18</div><div>$ ffprobe -v fatal -count_frames -select_streams v:1 -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 capture.mkv</div><div>14</div><div><br></div><div>What am I missing?</div><div><br></div><div>The pertinent pipeline bits are:</div><div><br></div><div>nvcamearsrc ! identity name=tapX ...</div><div><br></div>Why are the number of frames LESS than the number of times "handoff" was called?<br><div><br></div></div></blockquote><div><br></div><div>Is there a way to tell if a GstBuffer is actually frame data? (assuming an element is sending buffers that are NOT frame data???)<br></div></div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>How can I be sure I'm pulling the exact number of frames that land in my MKV container (i.e. the stream)?<br></div><div><br></div><div>-aps<br></div></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" rel="noreferrer" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>