[FFmpeg-devel] Next developer meeting

[Anton Khirnov]

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.borgmann at 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