Quoting James Almer (2020-11-11 14:13:07) > On 11/11/2020 10:05 AM, Thilo Borgmann wrote: > > Am 11.11.20 um 14:04 schrieb Thilo Borgmann: > >> Am 11.11.20 um 13:01 schrieb Steven Liu: > >>> Thilo Borgmann <thilo.borgm...@mail.de> 于2020年11月11日周三 下午7:20写道: > >>>> > >>>> Hi, > >>>> > >>>> we haven't had a meeting for quite some time and are beyond schedule > >>>> anyway. So I'd propose having another developer meeting before end of > >>>> year. > >>>> > >>>> Please give your preferences for a date here: > >>>> https://framadate.org/g1FPmOpfEz9mSLg9 > >>>> > >>>> Current agenda proposals, feel free to add to it: > >>>> > >>>> - Tech / Comm committees how-to in practice > >>>> - GSoC adaptations for upcoming years > >> > >>>> - splitting libraries (lavf->lavio) > >>> Need more introduce for this line, libavformat and libavio ? > >> > >> AFAICT i/o operations shall not be separated from lavformat. If I > >> understood it correctly. > > > > ... shall BE sepearated... > > What i know we were discussing was to merge lavd into lavf, since their > current dependency state is pretty hacky and makes development and > extension of certain lavf public structs a pain. > It's why i didn't apply my iterate api set just yet.
When this topic last came up, it seemed that nobody disagrees about merging lavd into lavf, so I am currently working on it. Patches soon. > > I don't recall anything about splitting IO, but what does it achieve > beyond making lavf lighter? Are there users out there that could care > about linking to an hypothetical lavio while not caring about other lavf > functionality? Yes, I recall several people expressing interest in a separate libavio. Also, I believe it would be good for us internally, since it would - allow other libraries to do IO cleanly without depending on lavf - force us to clean up avio public API, which is not in a great shape -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".