[FFmpeg-devel] IMF demuxer ping

[Pierre-Anthony Lemieux]

On Mon, Dec 6, 2021 at 8:02 AM Lynne <dev at lynne.ee> wrote:
>
> 6 Dec 2021, 16:58 by pal at sandflow.com:
>
> > On Mon, Dec 6, 2021 at 2:16 AM Anton Khirnov <anton at khirnov.net> wrote:
> >
> >>
> >> Quoting Lynne (2021-12-05 11:13:17)
> >> > 5 Dec 2021, 02:33 by pal at sandflow.com:
> >> >
> >> > > Hi all,
> >> > >
> >> > > Quick ping re: libavformat/imf demuxer patch set.
> >> > >
> >> > > All outstanding feedback (thanks!) has been addressed as far as I know.
> >> > >
> >> > >  What are the next steps?
> >> > >
> >> > > It would be good to make progress while it is fresh in peoples' minds.
> >> > >
> >> > > Latest patchset at [1] and tracking PR at [2] (including memory leak checking):
> >> > >
> >> > > [1] http://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/288173.html
> >> > > [2] https://github.com/sandflow/ffmpeg-imf/pull/74
> >> > >
> >> > > Looking forward to (finally) adding support for IMF demuxing to ffmpeg.
> >> > >
> >> >
> >> > There are still many issues.
> >> > Put your custom header beneath the standard ffmpeg header. Or
> >> > remove it altogether if you're allowed to.
> >> > You're not following our code style at all:
> >> > All internal functions (except intra-file functions) must have
> >> > an ff_<name> prefix. If it's a struct, the prefix is FF<name>.
> >>
> >> actually we do not require any prefixing for internal structs, since
> >> they are not visible in the ABI.
> >>
> >
> > Ok. Let me know if I should revert the struct names in imf.h from
> > "FFIMF*" to "IMF*", e.g. "FFIMFBaseResource" to "FFIMFBaseResource".
> >
>
> Keep the prefix. We don't require it, but it looks better, it's a convention,
> and I think we ought to require it.
>
> > Do you mean `-ignore_editlist`?
> > An IMF Composition consists of a standalone playlist (the CompositionPlaylist) that
> > references MXF files (the Track Files). It is notpossible to process the Track Files without the
> > Composition Playlist,i.e. the edit list.What scenario(s) do you have in mind?
>
> In that case, it's fine, as long as the demuxer actually supports all
> of this and all demuxers are expected to perform this.

Yes. Thanks.

>
> _______________________________________________
> 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".