Can muxers/multifilesink drop frames?

[pisymbol .]

On Wed, Sep 25, 2019 at 1:16 PM pisymbol . <pisymbol at gmail.com> wrote:

>
>
> On Wed, Sep 25, 2019 at 12:06 PM pisymbol . <pisymbol at gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 25, 2019 at 11:31 AM pisymbol . <pisymbol at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 25, 2019 at 10:29 AM Tim Müller <tim at centricular.com> wrote:
>>>
>>>> On Wed, 2019-09-25 at 15:28 +0100, Tim Müller wrote:
>>>>
>>>> > Mmh, not really/necessarily, you can't just concatenate Matroska
>>>> > files. It might work with splitmuxsrc however.
>>>>
>>>> Make that splitfilesrc.
>>>>
>>>
>>> So here is a concrete example of a 29+ minute recording:
>>>
>>> $ for f in /mnt/storage/capture_*.mkv; do ffprobe -v fatal -count_frames
>>> -select_streams v:0 -show_entries stream=nb_read_frames -of
>>> default=nokey=1:noprint_wrappers=1 $f; done >> counts
>>> $ cat counts | paste -sd+ - | bc
>>> 52375
>>>
>>> That should be the total number of frames in all of the mkv captures of
>>> stream 0. The problem is if I count the number of times my handoff function
>>> is called for frames in stream 0, I get:
>>>
>>> "total_frames_0": 52782
>>>
>>> So I'm trying to figure out where did the extra 407 frames come from/go?
>>> Or am I counting the frames incorrectly above?
>>>
>>>
>> Question, is it possible that not all frames are being flushed out at the
>> end by the muxer? Since I seem to always have more entries than frames in
>> meta files, I am guessing my handoff function is being called but perhaps
>> the frames aren't making it out to the filesystem via the muxer???
>>
>
>
Another question: Is there a way to check the buffer's type? i.e. can I
verify that each buffer passed to handoff is indeed an H.264 frame?

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