[FFmpeg-devel] [RFC] libavdevice

[FFmpeg-devel] [RFC] libavdevice

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1090 bytes --]

Hi all

libavdevice uses teh same ABI as libavformat so extending that ABI
without major bump leads to problems

input devices and input formats use the same struct
FFInputFormat

now you cant add a new field to that because the old libavdevice
would not have it and the newer libavformat would so things would
blow up.

The 2 solutions suggested where
1. merge libavdevice and libavformat
2. make libavdevice actually great again, aka a seperate API designed for devices
(3. maybe a bunch of flags checks version whatever can be used to make it work as is)

comments ?

Is anyone against "1. merge libavdevice and libavformat" ?
Is anyone volunteering for "2. make libavdevice actually great again, aka a seperate API designed for devices"

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] libavdevice

[Nicolas George via ffmpeg-devel]

Michael Niedermayer via ffmpeg-devel (HE12025-10-29):
> 1. merge libavdevice and libavformat

Of course we should do that. The split into multiple libraries serves no
purpose, it only makes our work more complicated; the benefits people
think they get from it either are nonexistent or could be obtained more
efficiently with less intrusive solutions.

IIRC, in the case of libavdevice, it was done under the pressure of
people who hated it and wanted to get rid of it, just like they managed
to put pressure on you to get rid of libpostproc.

> 2. make libavdevice actually great again, aka a seperate API designed for devices

That would not make libavdevice great, that would kill it.

The fact that devices can pass as muxers / demuxers is the key to the
usefulness of libavdevice: people write code for plain files, and thanks
to the magic of having the same API, this code can be used as is with
ALSA playback or desktop capture.

If libavdevice gets its own API, then the only code that works with it
is code that was specifically written for it, and who would write code
specifically for a mishmash of devices whose sole common point is that
they used to have the same API.

> (3. maybe a bunch of flags checks version whatever can be used to make it work as is)

We could also consider making libavdevice API evolve towards the one of
libavfilter.

That would require the driving code to work with non-buffersink sinks,
though, and we are not there yet.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org