Can muxers/multifilesink drop frames?

pisymbol . pisymbol at gmail.com
Wed Sep 25 16:06:36 UTC 2019


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

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


More information about the gstreamer-devel mailing list