Can muxers/multifilesink drop frames?

[pisymbol .]

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

I can never get them to be exact and that is what has me concerned.

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