[FFmpeg-devel] [PATCH 14/18] lavf: move AVStream.{need_parsing, parser} to AVStreamInternal

[Michael Niedermayer]

On Sun, Oct 11, 2020 at 08:50:50PM +0200, Nicolas George wrote:
> Michael Niedermayer (12020-10-11):
> > The situation with a single API+ABI shared by 2 libs with their own soname
> > is bad.
> > lavd either needs an independant API thats designed for devices (which is
> > probably more a medium to long term effort)
> 
> This would be a terrible idea. Being functionally a part of lavf, with
> the same API is an essential feature of lavd: it is what allows users to
> use devices with applications that are designed for files. Otherwise,
> lavd would only be usable with applications meant for it, i.e. none.

I dont think that what i suggested leads to what you describe here.

For example
Lets consider a hypothetical lavd with a API/ABI thats designed more towards
devices than (de)muxers.
lavf can depend on lavd and provide each device from lavd as a (de)muxer in
lavf too. That can even be in a 1 to 1 match or a single lavf (de)muxer with
an option to choose which device to map to.

These would maintain the device availability for existing applications.
While it would avoid requireing access to devices through the (de)muxer
interface.
Some people and maybe most people dislike that interface for devices.

I think you too want lavd to be something an author of a simple media
player considers. 
While ATM i think people consider variuous things but skip lavd as it
doesnt feel as an equal to the other choices.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201012/7c5e6832/attachment.sig>