[FFmpeg-devel] [SCISYS Possible Spam] Re: [PATCH v5] avformat/mov: Memory optimization with QuickTime/MP4

Jörg Beckmann Joerg.Beckmann at scisys.com
Mon Dec 16 13:13:17 EET 2019

> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> Im Auftrag von Carl
> Eugen Hoyos
> Gesendet: Montag, 16. Dezember 2019 11:50
> An: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Betreff: [SCISYS Possible Spam] Re: [FFmpeg-devel] [PATCH v5] avformat/mov:
> Memory optimization with QuickTime/MP4
> Am Mo., 9. Dez. 2019 um 16:05 Uhr schrieb Jörg Beckmann
> <Joerg.Beckmann at scisys.com>:
> >
> > Invents a new option "discard_fragments" for the MP4/Quicktime/MOV decoder.
> >
> > If the option is not set, nothing changes at all. If it is set, old
> > fragments are discarded as far as possible on each call to switch_root.
> > For pure audio streams, the memory usage is now constant.
> Is it possible to detect this case?
> If possible, the new option could have an "auto" setting.

I'm not sure whether it really works with all possible stream types. It works with all types I tried. Therefore I think the default behavior should be the old one and no "auto" mode. The main use case is 24x7 recording. In most other cases the memory usage is not important on modern computers. I'm even not sure whether there are many Quicktime/MP4 life streams at all. I did not find any but my audio streams. If you know additional ones, I would like to try them with the option. Maybe there are additional tables that could be freed also.

> Carl Eugen


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> To unsubscribe, visit link above, or email ffmpeg-devel-request at ffmpeg.org with
> subject "unsubscribe".

More information about the ffmpeg-devel mailing list