On Sun, 25 Mar 2018 17:46:50 +0200
Michael Niedermayer wrote:
> On Sun, Mar 25, 2018 at 04:35:12PM +0100, Josh de Kock wrote:
> > On 2018/03/25 16:21, Michael Niedermayer wrote:
> > >On Fri, Mar 23, 2018 at 11:05:22AM +0100, Nicolas George wrote:
> > >>Josh de Kock (2018-03-22):
> [...]
> >
On Sun, Mar 25, 2018 at 04:35:12PM +0100, Josh de Kock wrote:
> On 2018/03/25 16:21, Michael Niedermayer wrote:
> >On Fri, Mar 23, 2018 at 11:05:22AM +0100, Nicolas George wrote:
> >>Josh de Kock (2018-03-22):
[...]
>
> >People would just start to switch to the current API only to have it
> >depre
On 2018/03/25 16:21, Michael Niedermayer wrote:
On Fri, Mar 23, 2018 at 11:05:22AM +0100, Nicolas George wrote:
Josh de Kock (2018-03-22):
move lavd avinputformats and avoutputformats into lavf
delete lavd
Possibly ok in principle for me, but see below.
write new lavd aimed at actual devic
On Fri, Mar 23, 2018 at 11:05:22AM +0100, Nicolas George wrote:
> Josh de Kock (2018-03-22):
> > move lavd avinputformats and avoutputformats into lavf
> >
> > delete lavd
>
> Possibly ok in principle for me, but see below.
>
> > write new lavd aimed at actual devices
>
> There are already such
On Sun, 25 Mar 2018 16:41:12 +0200
Michael Niedermayer wrote:
> On Sun, Mar 25, 2018 at 03:32:33PM +0200, Nicolas George wrote:
> > Josh de Kock (2018-03-23):
> [...]
>
> > You can observe just that by the fact that you needed to add an avpriv
> > function to let lavd communicate with lavf. Ea
On Sun, Mar 25, 2018 at 03:32:33PM +0200, Nicolas George wrote:
> Josh de Kock (2018-03-23):
[...]
> You can observe just that by the fact that you needed to add an avpriv
> function to let lavd communicate with lavf. Each time an avpriv function
> appears, it shows there is something flawed in th
Josh de Kock (2018-03-23):
> I personally think this will fix a lot of the weird interactions between the
> two libraries, and should be considered a serious option independent of the
> new API.
Maybe. But that is for another discussion.
> Sure, I guess but I still think it's more involved than j
On 2018/03/23 10:05, Nicolas George wrote:
Josh de Kock (2018-03-22):
move lavd avinputformats and avoutputformats into lavf
delete lavd
Possibly ok in principle for me, but see below.
I personally think this will fix a lot of the weird interactions between
the two libraries, and should b
Josh de Kock (2018-03-22):
> move lavd avinputformats and avoutputformats into lavf
>
> delete lavd
Possibly ok in principle for me, but see below.
> write new lavd aimed at actual devices
There are already such libraries, we do not need another. The basic
devices with a (de)muxer API are quite
On 2018/03/22 22:38, Michael Niedermayer wrote:
> On Thu, Mar 22, 2018 at 02:01:27AM +, Josh de Kock wrote:
> [...]
>> +#ifdef CONFIG_AVDEVICE
>> +opaque = 0;
>> +if (muxdemuxers != SHOW_DEMUXERS) {
>> +while ((ofmt = av_outdev_iterate(&opaque))) {
>> +
On Thu, Mar 22, 2018 at 02:01:27AM +, Josh de Kock wrote:
[...]
> +#ifdef CONFIG_AVDEVICE
> +opaque = 0;
> +if (muxdemuxers != SHOW_DEMUXERS) {
> +while ((ofmt = av_outdev_iterate(&opaque))) {
> +if ((!name || strcmp(ofmt-> name, name) < 0) &&
> strc
On Thu, Mar 22, 2018 at 01:07:18PM +0100, Nicolas George wrote:
> Josh de Kock (2018-03-22):
> > Merging lavd into lavf may be the best option here, as it allows us to
> > change the return type of av_iterate_indev() etc to an AVDevice or another
> > type which may represent an actual device as opp
On 2018/03/22 12:07, Nicolas George wrote:
Josh de Kock (2018-03-22):
Merging lavd into lavf may be the best option here, as it allows us to
change the return type of av_iterate_indev() etc to an AVDevice or another
type which may represent an actual device as opposed to a purely
input/output de
Josh de Kock (2018-03-22):
> Merging lavd into lavf may be the best option here, as it allows us to
> change the return type of av_iterate_indev() etc to an AVDevice or another
> type which may represent an actual device as opposed to a purely
> input/output device (which is just implemented as an
On 2018/03/22 11:37, wm4 wrote:
On Thu, 22 Mar 2018 12:32:29 +0100
Nicolas George wrote:
Josh de Kock (2018-03-22):
There is always the option to just merge lavf and lavd. The state of them
being sort-of merged, but not really, isn't very good and adds a lot of
complexity especially in inter-
On Thu, 22 Mar 2018 12:32:29 +0100
Nicolas George wrote:
> Josh de Kock (2018-03-22):
> > There is always the option to just merge lavf and lavd. The state of them
> > being sort-of merged, but not really, isn't very good and adds a lot of
> > complexity especially in inter-library dependencies (
On 3/22/18, Nicolas George wrote:
> Josh de Kock (2018-03-22):
>> There is always the option to just merge lavf and lavd. The state of them
>> being sort-of merged, but not really, isn't very good and adds a lot of
>> complexity especially in inter-library dependencies (which are unneeded
>> if
>>
Josh de Kock (2018-03-22):
> There is always the option to just merge lavf and lavd. The state of them
> being sort-of merged, but not really, isn't very good and adds a lot of
> complexity especially in inter-library dependencies (which are unneeded if
> lavf and lavd are either merged or actually
On 2018/03/22 11:19, Nicolas George wrote:
Josh de Kock (2018-03-22):
I strongly oppose using the same loop. Separating devices' iteration is one
of the first steps to separating lavf from lavd.
And I oppose separating lavf from lavd, was it not clear enough? I have
given technical arguments i
Josh de Kock (2018-03-22):
> I strongly oppose using the same loop. Separating devices' iteration is one
> of the first steps to separating lavf from lavd.
And I oppose separating lavf from lavd, was it not clear enough? I have
given technical arguments in my first mail.
Regards,
--
Nicolas G
On 2018/03/22 10:29, Nicolas George wrote:
Josh de Kock (2018-03-22):
I have -ffunroll'd the macros for you Nicolas.
That is not what I asked. The macros were just a way of making the poor
API a little less poor, but the problem still remains:
+#ifdef CONFIG_AVDEVICE
+opaque = 0;
+
Josh de Kock (2018-03-22):
> I have -ffunroll'd the macros for you Nicolas.
That is not what I asked. The macros were just a way of making the poor
API a little less poor, but the problem still remains:
> +#ifdef CONFIG_AVDEVICE
> +opaque = 0;
> +if (muxdemuxers != SHOW_DEMUXERS)
---
I have -ffunroll'd the macros for you Nicolas.
fftools/cmdutils.c | 248 -
1 file changed, 129 insertions(+), 119 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 708a849f51..956eb7b974 100644
--- a/fftools/cmdutils
23 matches
Mail list logo
