Re: [FFmpeg-devel] GSOC 2018 qualification task.

[ANURAG SINGH IIT BHU]

Thank you sir, I'll implement the suggested reviews as soon as possible.




‌

On Fri, Apr 13, 2018 at 4:04 AM, Michael Niedermayer  wrote:

> On Fri, Apr 13, 2018 at 02:13:53AM +0530, ANURAG SINGH IIT BHU wrote:
> > Hello,
> > I have implemented the reviews mentioned on previous patch, now there is
> no
> > need to provide any subtitle file to the filter, I am attaching the
> > complete patch of the hellosubs filter.
> >
> > Command to run the filter
> > ffmpeg -i  -vf hellosubs= helloout.mp4
> >
> >
> > Thanks and regards,
> > Anurag Singh.
> >
> >
> > ‌
> >
> > On Tue, Apr 10, 2018 at 4:55 AM, Rostislav Pehlivanov <
> atomnu...@gmail.com>
> > wrote:
> >
> > > On 9 April 2018 at 19:10, Paul B Mahol  wrote:
> > >
> > > > On 4/9/18, Rostislav Pehlivanov  wrote:
> > > > > On 9 April 2018 at 03:59, ANURAG SINGH IIT BHU <
> > > > > anurag.singh.ph...@iitbhu.ac.in> wrote:
> > > > >
> > > > >> This mail is regarding the qualification task assigned to me for
> the
> > > > >> GSOC project
> > > > >> in FFmpeg for automatic real-time subtitle generation using
> speech to
> > > > text
> > > > >> translation ML model.
> > > > >>
> > > > >
> > > > > i really don't think lavfi is the correct place for such code, nor
> that
> > > > the
> > > > > project's repo should contain such code at all.
> > > > > This would need to be in another repo and a separate library.
> > > >
> > > > Why? Are you against ocr filter too?
> > > >
> > >
> > > The OCR filter uses libtessract so I'm fine with it. Like I said, as
> long
> > > as the actual code to do it is in an external library I don't mind.
> > > Mozilla recently released Deep Speech (https://github.com/mozilla/
> > > DeepSpeech)
> > > which does pretty much exactly speech to text and is considered to
> have the
> > > most accurate one out there. Someone just needs to convert the
> tensorflow
> > > code to something more usable.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
>
> >  Makefile   |1
> >  allfilters.c   |1
> >  vf_hellosubs.c |  513 ++
> +++
> >  3 files changed, 515 insertions(+)
> > 2432f100fddb7ec84e771be8282d4b66e3d1f50a  0001-avfilter-add-hellosubs-
> filter.patch
> > From ac0e09d431ea68aebfaef6e2ed0b450e76d473d9 Mon Sep 17 00:00:00 2001
> > From: ddosvulnerability 
> > Date: Thu, 12 Apr 2018 22:06:43 +0530
> > Subject: [PATCH] avfilter: add hellosubs filter.
> >
> > ---
> >  libavfilter/Makefile   |   1 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/vf_hellosubs.c | 513 ++
> +++
> >  3 files changed, 515 insertions(+)
> >  create mode 100644 libavfilter/vf_hellosubs.c
> >
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index a90ca30..770b1b5 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -331,6 +331,7 @@ OBJS-$(CONFIG_SSIM_FILTER)   +=
> vf_ssim.o framesync.o
> >  OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
> >  OBJS-$(CONFIG_STREAMSELECT_FILTER)   += f_streamselect.o
> framesync.o
> >  OBJS-$(CONFIG_SUBTITLES_FILTER)  += vf_subtitles.o
> > +OBJS-$(CONFIG_HELLOSUBS_FILTER)  += vf_hellosubs.o
> >  OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
> >  OBJS-$(CONFIG_SWAPRECT_FILTER)   += vf_swaprect.o
> >  OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> > index 6eac828..a008908 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -322,6 +322,7 @@ extern AVFilter ff_vf_ssim;
> >  extern AVFilter ff_vf_stereo3d;
> >  extern AVFilter ff_vf_streamselect;
> >  extern AVFilter ff_vf_subtitles;
> > +extern AVFilter ff_vf_hellosubs;
> >  extern AVFilter ff_vf_super2xsai;
> >  extern AVFilter ff_vf_swaprect;
> >  extern AVFilter ff_vf_swapuv;
> > diff --git a/libavfilter/vf_hellosubs.c b/libavfilter/vf_hellosubs.c
> > new file mode 100644
> > index 000..b994050
> > --- /dev/null
> > +++ b/libavfilter/vf_hellosubs.c
> > @@ -0,0 +1,513 @@
> > +/*
> > + * Copyright (c) 2011 Baptiste Coudurier
> > + * Copyright (c) 2011 Stefano Sabatini
> > + * Copyright (c) 2012 Clément Bœsch
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A 

Re: [FFmpeg-devel] [PATCH] tests/checkasm/checkasm: Provide verbose failure information on float_near_abs_eps() failures

[James Almer]

On 4/12/2018 9:34 PM, Michael Niedermayer wrote:
> This will make understanding failures and adjusting EPS easier
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/checkasm/checkasm.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 20ce56932f..8a3e24f100 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -294,8 +294,12 @@ int float_near_ulp_array(const float *a, const float *b, 
> unsigned max_ulp,
>  int float_near_abs_eps(float a, float b, float eps)
>  {
>  float abs_diff = fabsf(a - b);
> +if (abs_diff < eps)
> +return 1;
>  
> -return abs_diff < eps;
> +fprintf(stderr, "test failed comparing %f with %f (abs diff=%f with 
> EPS=%f)\n", a, b, abs_diff, eps);

Maybe %g instead? I may be better to print small values, but I'm not
sure. LGTM in any case.

A few tests also output a custom log message like this one, so it may be
a good idea to remove them now that it's done in general.

> +
> +return 0;
>  }
>  
>  int float_near_abs_eps_array(const float *a, const float *b, float eps,
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/12/2018 10:17 PM, James Almer wrote:
> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
>> On Thu, Apr 12, 2018 at 07:59:25PM -0300, James Almer wrote:
>>> On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
 On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
> Hi
>
> Its 4 months since 3.4 was branched so its time for a new major release
>
> Is 4.0 or 3.5 preferred ?
> Any name suggestions ?
>
> If there are no objections i will likely make that release in the next 
> weeks

 more time has passed than intended ...

 what issues do remain that need to be fixed before the release ?
 I see fate.ffmpeg.org is not looking that well (compared to most
 releases in the past) i remember this being pretty much green longer ago
 do people want these to be fixed before the release ?

 Thanks
>>>
>>> I fixed two targets the other day, and another has the patch pending in
>>> the ml (OpenBSD). 
>>
>>> Then there are your FreeBSD clients that you need to
>>> switch to yasm, 
>>
>> I can do that, it doesnt feel right though. configure should not pick
>> a nasm that then fails later.
> 
> Do you have a suggestion of what kind of configure check could trigger
> this failure? As is, all the current checks are succeeding. It's only
> failing once it tries to compile the first asm file in the tree.
> 
>>
>>
>>> and apply the fix to the c11 check in configure.
>>
>> you want me to apply it ?
>> or i misunderstand ?
> 
> You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
> whichever you prefer, yes.
> 
>>
>>
>>>
>>> The kfreebsd failures are for the tests filter-metadata-silencedetect
>>> and checkasm-aacpsdsp. After a recent patch silencedetect prints float
>>> values with more precision. Paul said to remove the test and forget
>>> about it, but no idea if there's a better solution.
>>
>> of course removing the test is the easy solution.
>> there is only 1 test for silencedetect, so that would remove not just
>> one silencedetect test but all silencedetect tests
>>
>> The test currently uses a amrwb test file which is decoded with a
>> non bitexact float decoder.
>> has someone tried to replace this by bitexact input ?
> 
> Do we have a relatively quiet sample using a bitexact codec like this
> amrwb one? Or we could convert it to flac and upload it instead.
> 
>>
>> Thanks

In any case, save for the c11 configure check fix, none of these issues
should IMO block the release seeing it was already delayed enough. They
are either strict float comparisons in fate (Where the fix is using a
laxer comparison value), or external issues like broken assemblers and
binutils tools.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
> On Thu, Apr 12, 2018 at 07:59:25PM -0300, James Almer wrote:
>> On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
>>> On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
 Hi

 Its 4 months since 3.4 was branched so its time for a new major release

 Is 4.0 or 3.5 preferred ?
 Any name suggestions ?

 If there are no objections i will likely make that release in the next 
 weeks
>>>
>>> more time has passed than intended ...
>>>
>>> what issues do remain that need to be fixed before the release ?
>>> I see fate.ffmpeg.org is not looking that well (compared to most
>>> releases in the past) i remember this being pretty much green longer ago
>>> do people want these to be fixed before the release ?
>>>
>>> Thanks
>>
>> I fixed two targets the other day, and another has the patch pending in
>> the ml (OpenBSD). 
> 
>> Then there are your FreeBSD clients that you need to
>> switch to yasm, 
> 
> I can do that, it doesnt feel right though. configure should not pick
> a nasm that then fails later.

Do you have a suggestion of what kind of configure check could trigger
this failure? As is, all the current checks are succeeding. It's only
failing once it tries to compile the first asm file in the tree.

> 
> 
>> and apply the fix to the c11 check in configure.
> 
> you want me to apply it ?
> or i misunderstand ?

You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
whichever you prefer, yes.

> 
> 
>>
>> The kfreebsd failures are for the tests filter-metadata-silencedetect
>> and checkasm-aacpsdsp. After a recent patch silencedetect prints float
>> values with more precision. Paul said to remove the test and forget
>> about it, but no idea if there's a better solution.
> 
> of course removing the test is the easy solution.
> there is only 1 test for silencedetect, so that would remove not just
> one silencedetect test but all silencedetect tests
> 
> The test currently uses a amrwb test file which is decoded with a
> non bitexact float decoder.
> has someone tried to replace this by bitexact input ?

Do we have a relatively quiet sample using a bitexact codec like this
amrwb one? Or we could convert it to flac and upload it instead.

> 
> Thanks
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavc/hevc: Don't parse NAL unit for a dummy buffer

[Xiang, Haihao]

Thank Steven for reviewing the patch, could anyone help to push the patch?

Best Regards
Haihao

> > On 8 Apr 2018, at 12:53, Xiang, Haihao  wrote:
> > 
> > 
> > 
> > Hi Steven,
> > 
> > Are there more comments on this patch? 
> > 
> > Thanks
> > Haihao
> > 
> > 
> > > hevc parser mistakenly reports the following message if a dummy buffer
> > > is padded for EOF
> > > 
> > >   [hevc @ 0x559b63848610] missing picture in access unit
> > > 
> > > v2: use the preferred code style and rebase the patch
> > > 
> > > Signed-off-by: Haihao Xiang 
> > > ---
> > > libavcodec/hevc_parser.c | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > > index a468682ed3..01418b276d 100644
> > > --- a/libavcodec/hevc_parser.c
> > > +++ b/libavcodec/hevc_parser.c
> > > @@ -294,6 +294,8 @@ static int hevc_parse(AVCodecParserContext *s,
> > > AVCodecContext *avctx,
> > > int next;
> > > HEVCParserContext *ctx = s->priv_data;
> > > ParseContext *pc = >pc;
> > > +int is_dummy_buf = !buf_size;
> > > +const uint8_t *dummy_buf = buf;
> > > 
> > > if (avctx->extradata && !ctx->parsed_extradata) {
> > > ff_hevc_decode_extradata(avctx->extradata, avctx->extradata_size,
> > > >ps, >sei,
> > > @@ -313,7 +315,10 @@ static int hevc_parse(AVCodecParserContext *s,
> > > AVCodecContext *avctx,
> > > }
> > > }
> > > 
> > > -parse_nal_units(s, buf, buf_size, avctx);
> > > +is_dummy_buf = (is_dummy_buf && (dummy_buf == buf));
> > > +
> > > +if (!is_dummy_buf)
> > > +parse_nal_units(s, buf, buf_size, avctx);
> > > 
> > > *poutbuf  = buf;
> > > *poutbuf_size = buf_size;
> 
> LGTM
> 
> Thanks
> Steven
> 
> 
> 
> 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] tests/checkasm/checkasm: Provide verbose failure information on float_near_abs_eps() failures

[Michael Niedermayer]

This will make understanding failures and adjusting EPS easier

Signed-off-by: Michael Niedermayer 
---
 tests/checkasm/checkasm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 20ce56932f..8a3e24f100 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -294,8 +294,12 @@ int float_near_ulp_array(const float *a, const float *b, 
unsigned max_ulp,
 int float_near_abs_eps(float a, float b, float eps)
 {
 float abs_diff = fabsf(a - b);
+if (abs_diff < eps)
+return 1;
 
-return abs_diff < eps;
+fprintf(stderr, "test failed comparing %f with %f (abs diff=%f with 
EPS=%f)\n", a, b, abs_diff, eps);
+
+return 0;
 }
 
 int float_near_abs_eps_array(const float *a, const float *b, float eps,
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 07:59:25PM -0300, James Almer wrote:
> On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
> > On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
> >> Hi
> >>
> >> Its 4 months since 3.4 was branched so its time for a new major release
> >>
> >> Is 4.0 or 3.5 preferred ?
> >> Any name suggestions ?
> >>
> >> If there are no objections i will likely make that release in the next 
> >> weeks
> > 
> > more time has passed than intended ...
> > 
> > what issues do remain that need to be fixed before the release ?
> > I see fate.ffmpeg.org is not looking that well (compared to most
> > releases in the past) i remember this being pretty much green longer ago
> > do people want these to be fixed before the release ?
> > 
> > Thanks
> 
> I fixed two targets the other day, and another has the patch pending in
> the ml (OpenBSD). 

> Then there are your FreeBSD clients that you need to
> switch to yasm, 

I can do that, it doesnt feel right though. configure should not pick
a nasm that then fails later.


> and apply the fix to the c11 check in configure.

you want me to apply it ?
or i misunderstand ?


> 
> The kfreebsd failures are for the tests filter-metadata-silencedetect
> and checkasm-aacpsdsp. After a recent patch silencedetect prints float
> values with more precision. Paul said to remove the test and forget
> about it, but no idea if there's a better solution.

of course removing the test is the easy solution.
there is only 1 test for silencedetect, so that would remove not just
one silencedetect test but all silencedetect tests

The test currently uses a amrwb test file which is decoded with a
non bitexact float decoder.
has someone tried to replace this by bitexact input ?

Thanks

[...]

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Friday, April 13, 2018 1:24 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support 
> implementation by AMF encoder
> 
> 
> The code gets more readable / less ugly.
> 

Hi Carl,
Is this the common practice? Any recommendations somewhere?

IMHO it does not help reading code, but may confuse and make code researcher to 
spend time trying to figure out why the macro is in condition
Also it makes condition longer

Thanks,
Alexander



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
> On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
>> Hi
>>
>> Its 4 months since 3.4 was branched so its time for a new major release
>>
>> Is 4.0 or 3.5 preferred ?
>> Any name suggestions ?
>>
>> If there are no objections i will likely make that release in the next weeks
> 
> more time has passed than intended ...
> 
> what issues do remain that need to be fixed before the release ?
> I see fate.ffmpeg.org is not looking that well (compared to most
> releases in the past) i remember this being pretty much green longer ago
> do people want these to be fixed before the release ?
> 
> Thanks

I fixed two targets the other day, and another has the patch pending in
the ml (OpenBSD). Then there are your FreeBSD clients that you need to
switch to yasm, and apply the fix to the c11 check in configure.

The kfreebsd failures are for the tests filter-metadata-silencedetect
and checkasm-aacpsdsp. After a recent patch silencedetect prints float
values with more precision. Paul said to remove the test and forget
about it, but no idea if there's a better solution.
The checkasm failure can be solved by changing the value passed as
epsilon to float_near_abs_eps_array(), but i don't know which one would
be best without making it too lax and end up having it succeed even when
it's getting bad results.

The rest of the failures are old, like random_seed on some obscure
systems and a bunch of msvc miscompilation failures that Microsoft will
not fix.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
> Hi
> 
> Its 4 months since 3.4 was branched so its time for a new major release
> 
> Is 4.0 or 3.5 preferred ?
> Any name suggestions ?
> 
> If there are no objections i will likely make that release in the next weeks

more time has passed than intended ...

what issues do remain that need to be fixed before the release ?
I see fate.ffmpeg.org is not looking that well (compared to most
releases in the past) i remember this being pretty much green longer ago
do people want these to be fixed before the release ?

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Friday, April 13, 2018 1:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type 
> AV_HWDEVICE_TYPE_DXVA2 support
> 
> 
> Tested on Windows 7, works well.  Unlike with D3D11 the OpenCL interop works 
> properly as well, so e.g. -vf
> 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1 
> 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16'
> as encoder input works too.
> 
> Thanks,
> 
> - Mark


Hi Mark, 
sorry if I confused you
I have moved the thread to
 [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by 
AMF encoder
With the same code patch, but with different subject and with sample of usage.

I will fix code according your feedback and send the new patch there if you 
don’t mind

Thanks,
Alexander

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSOC 2018 qualification task.

[Michael Niedermayer]

On Fri, Apr 13, 2018 at 02:13:53AM +0530, ANURAG SINGH IIT BHU wrote:
> Hello,
> I have implemented the reviews mentioned on previous patch, now there is no
> need to provide any subtitle file to the filter, I am attaching the
> complete patch of the hellosubs filter.
> 
> Command to run the filter
> ffmpeg -i  -vf hellosubs= helloout.mp4
> 
> 
> Thanks and regards,
> Anurag Singh.
> 
> 
> ‌
> 
> On Tue, Apr 10, 2018 at 4:55 AM, Rostislav Pehlivanov 
> wrote:
> 
> > On 9 April 2018 at 19:10, Paul B Mahol  wrote:
> >
> > > On 4/9/18, Rostislav Pehlivanov  wrote:
> > > > On 9 April 2018 at 03:59, ANURAG SINGH IIT BHU <
> > > > anurag.singh.ph...@iitbhu.ac.in> wrote:
> > > >
> > > >> This mail is regarding the qualification task assigned to me for the
> > > >> GSOC project
> > > >> in FFmpeg for automatic real-time subtitle generation using speech to
> > > text
> > > >> translation ML model.
> > > >>
> > > >
> > > > i really don't think lavfi is the correct place for such code, nor that
> > > the
> > > > project's repo should contain such code at all.
> > > > This would need to be in another repo and a separate library.
> > >
> > > Why? Are you against ocr filter too?
> > >
> >
> > The OCR filter uses libtessract so I'm fine with it. Like I said, as long
> > as the actual code to do it is in an external library I don't mind.
> > Mozilla recently released Deep Speech (https://github.com/mozilla/
> > DeepSpeech)
> > which does pretty much exactly speech to text and is considered to have the
> > most accurate one out there. Someone just needs to convert the tensorflow
> > code to something more usable.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  Makefile   |1 
>  allfilters.c   |1 
>  vf_hellosubs.c |  513 
> +
>  3 files changed, 515 insertions(+)
> 2432f100fddb7ec84e771be8282d4b66e3d1f50a  
> 0001-avfilter-add-hellosubs-filter.patch
> From ac0e09d431ea68aebfaef6e2ed0b450e76d473d9 Mon Sep 17 00:00:00 2001
> From: ddosvulnerability 
> Date: Thu, 12 Apr 2018 22:06:43 +0530
> Subject: [PATCH] avfilter: add hellosubs filter.
> 
> ---
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_hellosubs.c | 513 
> +
>  3 files changed, 515 insertions(+)
>  create mode 100644 libavfilter/vf_hellosubs.c
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..770b1b5 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -331,6 +331,7 @@ OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o 
> framesync.o
>  OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
>  OBJS-$(CONFIG_STREAMSELECT_FILTER)   += f_streamselect.o framesync.o
>  OBJS-$(CONFIG_SUBTITLES_FILTER)  += vf_subtitles.o
> +OBJS-$(CONFIG_HELLOSUBS_FILTER)  += vf_hellosubs.o
>  OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
>  OBJS-$(CONFIG_SWAPRECT_FILTER)   += vf_swaprect.o
>  OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 6eac828..a008908 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -322,6 +322,7 @@ extern AVFilter ff_vf_ssim;
>  extern AVFilter ff_vf_stereo3d;
>  extern AVFilter ff_vf_streamselect;
>  extern AVFilter ff_vf_subtitles;
> +extern AVFilter ff_vf_hellosubs;
>  extern AVFilter ff_vf_super2xsai;
>  extern AVFilter ff_vf_swaprect;
>  extern AVFilter ff_vf_swapuv;
> diff --git a/libavfilter/vf_hellosubs.c b/libavfilter/vf_hellosubs.c
> new file mode 100644
> index 000..b994050
> --- /dev/null
> +++ b/libavfilter/vf_hellosubs.c
> @@ -0,0 +1,513 @@
> +/*
> + * Copyright (c) 2011 Baptiste Coudurier
> + * Copyright (c) 2011 Stefano Sabatini
> + * Copyright (c) 2012 Clément Bœsch
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * Libass hellosubs burning filter.
> + *
> + 
> + */

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

[Mark Thompson]

On 11/04/18 23:56, Alexander Kravchenko wrote:
> I am sorry, sending patch one more time. Outlook was wrapping text.
> Sending patch in message body and in attachment
> 
> ---
>  libavcodec/amfenc.c | 123 
> +++-
>  1 file changed, 102 insertions(+), 21 deletions(-)
> 
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index b9418b6791..c1f65f909d 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -24,6 +24,9 @@
>  #if CONFIG_D3D11VA
>  #include "libavutil/hwcontext_d3d11va.h"
>  #endif
> +#if CONFIG_DXVA2
> +#include "libavutil/hwcontext_dxva2.h"
> +#endif
>  #include "libavutil/mem.h"
>  #include "libavutil/pixdesc.h"
>  #include "libavutil/time.h"
> @@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
>  AV_PIX_FMT_YUV420P,
>  #if CONFIG_D3D11VA
>  AV_PIX_FMT_D3D11,
> +#endif
> +#if CONFIG_DXVA2
> +AV_PIX_FMT_DXVA2_VLD,
>  #endif
>  AV_PIX_FMT_NONE
>  };
> @@ -69,6 +75,7 @@ static const FormatMap format_map[] =
>  { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
>  { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
>  { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> +{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },

As with D3D11, this isn't necessarily true.  This was ignored before, but do 
you have any plan for how P010 (and others?) will be handled here?

>  };
>  
>  
> @@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
>  return 0;
>  }
>  
> +static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
> IDirect3DDevice9 **device, void *avcl)
> +{
> +HRESULT hr;
> +HANDLE device_handle;
> +
> +if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr, _handle))) 
> {
> +if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle, 
> device, FALSE))) {
> +devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
> +} else {
> +av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for 
> Direct3D9 device: %lx.\n", (unsigned long)hr);
> +}
> +devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
> +} else {
> +av_log(avcl, AV_LOG_INFO, "Failed to open device handle for 
> Direct3D9 device: %lx.\n", (unsigned long)hr);
> +}
> +}

Might be cleaner using an error return rather than the null device?

Everything using D3D9 types needs to be inside CONFIG_DXVA2.

> +
>  static int amf_init_context(AVCodecContext *avctx)
>  {
>  AmfContext *ctx = avctx->priv_data;
> @@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
>  res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
>  AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
> "CreateContext() failed with error %d\n", res);
>  // try to reuse existing DX device
> -#if CONFIG_D3D11VA
>  if (avctx->hw_frames_ctx) {
> -AVHWFramesContext *device_ctx = 
> (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> -if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
> -if (amf_av_to_amf_format(device_ctx->sw_format) != 
> AMF_SURFACE_UNKNOWN) {
> -if (device_ctx->device_ctx->hwctx) {
> -AVD3D11VADeviceContext *device_d3d11 = 
> (AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
> +AVHWFramesContext *frames_ctx = 
> (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> +if (amf_av_to_amf_format(frames_ctx->sw_format) != 
> AMF_SURFACE_UNKNOWN) {
> +if (frames_ctx->device_ctx->hwctx) {
> +#if CONFIG_D3D11VA
> +if (frames_ctx->device_ctx->type == 
> AV_HWDEVICE_TYPE_D3D11VA) {
> +AVD3D11VADeviceContext *device_d3d11 = 
> (AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
>  res = ctx->context->pVtbl->InitDX11(ctx->context, 
> device_d3d11->device, AMF_DX11_1);
>  if (res == AMF_OK) {
>  ctx->hw_frames_ctx = 
> av_buffer_ref(avctx->hw_frames_ctx);
>  if (!ctx->hw_frames_ctx) {
>  return AVERROR(ENOMEM);
>  }
> -if (device_ctx->initial_pool_size > 0)
> -ctx->hwsurfaces_in_queue_max = 
> device_ctx->initial_pool_size - 1;
> +if (frames_ctx->initial_pool_size > 0)
> +ctx->hwsurfaces_in_queue_max = 
> frames_ctx->initial_pool_size - 1;
>  } else {
> -if(res == AMF_NOT_SUPPORTED)
> +if (res == AMF_NOT_SUPPORTED)
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has D3D11 device which doesn't have D3D11VA interface, switching to 
> default\n");
>  else
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has non-AMD device, switching to 

Re: [FFmpeg-devel] [PATCH v6] avfilter: add OpenCL scale filter

[Gabriel Machado]

On 4/8/18 11:37 PM Song, Ruiling wrote:
> > +float2 src_coord = (convert_float2(dst_pos) + 0.5) / dst_size;
> For the floating point constant, it is better to add suffix 'f' to the number 
> to tell the compiler that this is a single floating point value (like 0.5f).
> The reason is if no suffix provided, floating point constants will be treated 
> as double precision float number.
> OpenCL C language derive this feature from C language. And most GPUs are 
> performance sensitive to single floating point/ double floating point 
> operations.
> If you intentionally need double precision, it is ok to leave it as it is.
> There are also some other places like this in the OpenCL file.

Changed to floating point constants, thanks.

- Gabriel

From b5cbdef9abc3727e1456915e50bbf1d9c87751d7 Mon Sep 17 00:00:00 2001
From: Gabriel Machado 
Date: Sat, 31 Mar 2018 23:03:18 -0300
Subject: [PATCH] avfilter: add OpenCL scale filter

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   |  67 ++
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 544 ++
 6 files changed, 615 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 1e192f8..7d0858c 100755
--- a/configure
+++ b/configure
@@ -2879,6 +2879,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 6eac828..3073881 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -293,6 +293,7 @@ extern AVFilter ff_vf_sab;
 extern AVFilter ff_vf_scale;
 extern AVFilter ff_vf_scale_cuda;
 extern AVFilter ff_vf_scale_npp;
+extern AVFilter ff_vf_scale_opencl;
 extern AVFilter ff_vf_scale_qsv;
 extern AVFilter ff_vf_scale_vaapi;
 extern AVFilter ff_vf_scale2ref;
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..6583bb5
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+__kernel void neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 dst_pos = {get_global_id(0), get_global_id(1)};
+float2 dst_size = {get_global_size(0), get_global_size(1)};
+
+float2 src_coord = (convert_float2(dst_pos) + 0.5f) / dst_size;
+
+float4 c = read_imagef(src, sampler, src_coord);
+write_imagef(dst, dst_pos, c);
+}
+
+__kernel void scale(__write_only image2d_t dst,
+__read_only  image2d_t src,
+__constant   float*cx,
+__constant   float*cy,
+ int2  flt_size)
+{
+const sampler_t s_img = (CLK_NORMALIZED_COORDS_FALSE |
+ CLK_ADDRESS_CLAMP_TO_EDGE |
+ CLK_FILTER_NEAREST);
+
+int2 dst_pos = {get_global_id(0), get_global_id(1)};
+
+

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[Hendrik Leppkes]

On Thu, Apr 12, 2018 at 11:52 PM, wm4  wrote:
>
> Could we use that PARSE_HEADERS probably never changes packet contents?

Not without reviewing all parsers, its not enforced, just a usage hint really.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Carl Eugen Hoyos]

2018-04-13 0:11 GMT+02:00, Alexander Kravchenko :
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Friday, April 13, 2018 12:48 AM
>> To: FFmpeg development discussions and patches 
>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
>> implementation by AMF encoder
>>
>> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko
>> :
>> >
>> > This patch contains DXVA2 textures support implementation by AMF
>> > encoder (in addition of D3D11 textures)
>>
>> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA

(There is a linebreak in your original and my mail afaict.)

>> > +if (frames_ctx->device_ctx->type ==
>> > AV_HWDEVICE_TYPE_D3D11VA) {
>>
>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
>>
>> same below.
>>
>
> Hi Carl, thanks for your feedback
>
> Could you explain the reason replacing
> if (frames_ctx->device_ctx->type ==
> to
> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==

The code gets more readable / less ugly.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[James Almer]

On 4/12/2018 6:52 PM, wm4 wrote:
> On Thu, 12 Apr 2018 16:22:01 -0300
> James Almer  wrote:
> 
>> On 4/12/2018 3:59 PM, wm4 wrote:
>>> On Thu, 12 Apr 2018 15:34:29 -0300
>>> James Almer  wrote:
>>>   
 If the parser returns full frames, then the output pointer retured by
 av_parser_parse2() is guaranteed to point to data contained in the
 input packet's buffer.

 Create a new reference to said buffer in that case, to avoid
 unnecessary data copy when queueing the packet later in the function.

 Signed-off-by: James Almer 
 ---
  libavformat/utils.c | 23 ---
  1 file changed, 20 insertions(+), 3 deletions(-)

 diff --git a/libavformat/utils.c b/libavformat/utils.c
 index 3e482a3bbc..8ad2ef4d70 100644
 --- a/libavformat/utils.c
 +++ b/libavformat/utils.c
 @@ -1471,6 +1471,22 @@ static int parse_packet(AVFormatContext *s, 
 AVPacket *pkt, int stream_index)
  if (!out_pkt.size)
  continue;
  
 +if (pkt->buf && out_pkt.data == pkt->data) {
 +/* reference pkt->buf only when out_pkt.data is guaranteed to 
 point
 + * to data in it and not in the parser's internal buffer. */
 +/* XXX: Ensure this is the case with all parsers when the 
 muxer sets
 + * PARSER_FLAG_COMPLETE_FRAMES and check for that instead? */
 +out_pkt.buf = av_buffer_ref(pkt->buf);
 +if (!out_pkt.buf) {
 +ret = AVERROR(ENOMEM);
 +goto fail;
 +}
 +} else {
 +ret = av_packet_make_refcounted(_pkt);
 +if (ret < 0)
 +goto fail;
 +}
 +
  if (pkt->side_data) {
  out_pkt.side_data   = pkt->side_data;
  out_pkt.side_data_elems = pkt->side_data_elems;
 @@ -1511,10 +1527,11 @@ static int parse_packet(AVFormatContext *s, 
 AVPacket *pkt, int stream_index)
  
  ret = ff_packet_list_put(>internal->parse_queue,
   >internal->parse_queue_end,
 - _pkt, FF_PACKETLIST_FLAG_REF_PACKET);
 -av_packet_unref(_pkt);
 -if (ret < 0)
 + _pkt, 0);
 +if (ret < 0) {
 +av_packet_unref(_pkt);
  goto fail;
 +}
  }
  
  /* end of the stream => close and free the parser */  
>>>
>>> For which cases is this?  
>>
>> Pretty much every single packet from a demuxer that sets
>> AVSTREAM_PARSE_HEADERS, meaning every non-raw demuxer with a couple
>> exceptions.
>>
>>> Maybe we should just make a new parser API (or
>>> reuse the BSF one), and make it cover the cases we care about.  
>>
>> I remember a new parser API that works on packets rather than raw data,
>> much like the new bsf API, was the plan at some point.
>> There's no lack of ideas in any case, just manpower in general.
> 
> To be honest I wish we just did away with this probing stuff and
> restrict libavformat to actually demuxing stuff.
> 
> Could we use that PARSE_HEADERS probably never changes packet contents?

AVSTREAM_PARSE_HEADERS is a constant AVStream->needs_parsing gets set to
by demuxers, which lavf/utils.c then uses to set
AVStream->AVParser->flags to PARSER_FLAG_COMPLETE_FRAMES, the actual
AVParser API flag (Which should probably get an AV prefix, btw).
Even then, not all parsers actually care about that flag being set, as
is the case with for example png, bmp, mlp until not too long ago, etc.
So at least right now no, we can't assume all packets will be parsed for
codec specific params then passed along untouched even if that flag is
set. I mentioned as much in the commented out chunk in this patch and
the reason I'm comparing the in and out data pointers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

[Alexander Kravchenko]

Thread was moved to
[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by 
AMF encoder


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Friday, April 13, 2018 12:48 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support 
> implementation by AMF encoder
> 
> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko :
> >
> > This patch contains DXVA2 textures support implementation by AMF
> > encoder (in addition of D3D11 textures)
> 
> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA
> > +if (frames_ctx->device_ctx->type ==
> > AV_HWDEVICE_TYPE_D3D11VA) {
> 
> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
> 
> same below.
> 

Hi Carl, thanks for your feedback

Could you explain the reason replacing
if (frames_ctx->device_ctx->type ==
to
if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==
in code like:

#if CONFIG_DXVA2
#include "libavutil/hwcontext_dxva2.h"
#endif
//...
#if CONFIG_D3D11VA
if (frames_ctx->device_ctx->type ==...
//code required include libavutil/hwcontext_dxva2.h"
#endif


Thanks,
Alexander

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 10:23:07AM +0200, Bodecs Bela wrote:
> 
> 
> 2018.04.12. 0:26 keltezéssel, Michael Niedermayer írta:
> >On Wed, Apr 11, 2018 at 10:37:41PM +0200, Bodecs Bela wrote:
> >>fate test enclosed
> >>
> >>
> >>2018.04.04. 10:39 keltezéssel, Bodecs Bela írta:
> >>>
> >>>2018.04.04. 2:37 keltezéssel, Michael Niedermayer írta:
> On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:
> >Dear All,
> >
> >currently when specifying the program id you can only decide to select
> >all stream of the specified program (e.g. p:103 will select all streams
> >of program 103) or narrow the selection to a specific stream sub index
> >(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
> >specify like all audio streams of program 145 or 3rd video stream of
> >program 311.
> >In some case, mainly working with multiprogram mpeg-ts containers as
> >input, this feature would be handy.
> >This patch makes it possible to narrow the stream selection among
> >streams of the specified program by stream type and optionally its
> >index. Handled types: a, v, s, d.
> >Examples: p:601:a  will select all audio streams of program 601,
> >p:603:a:1 will select 2nd audio streams of program 603,
> >p:604:v:0 will select first video stream of program 604.
> >This syntax enhancement does not interfere in any way with
> >current/exiting syntax or working command lines
> I think this is a good idea.
> Can you also add fate test(s) for this ? (can be in a seperate patch
> later of course)
> 
> >>>ok, I will try.
> >>>
> >>>bb
> >>>
> thx
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>___
> >>>ffmpeg-devel mailing list
> >>>ffmpeg-devel@ffmpeg.org
> >>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>  mpegts.mak |6 ++
> >>  1 file changed, 6 insertions(+)
> >>da6c059eab100872d0f61d14e40e46012f031bfe  
> >>0002-fate-to-test-program-sub-stream-selection-by-its-typ.patch
> >> From 093bdb47d1c5093cbd9427fbd2383a1c802464bb Mon Sep 17 00:00:00 2001
> >>From: Bela Bodecs 
> >>Date: Wed, 11 Apr 2018 22:33:02 +0200
> >>Subject: [PATCH] fate: to test program sub stream selection by its type in
> >>  mpegts
> >>
> >>Signed-off-by: Bela Bodecs 
> >>---
> >>  tests/fate/mpegts.mak | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >>diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
> >>index bb0d9d9..2b12849 100644
> >>--- a/tests/fate/mpegts.mak
> >>+++ b/tests/fate/mpegts.mak
> >>@@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) 
> >>+= fate-mpegts-probe-la
> >>  fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
> >>  fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
> >>+
> >>+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
> >>fate-mpegts-probe-program
> >>+fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
> >>+fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
> >>-select_streams p:769:v:0 -i "$(SRC)"
> >>+
> >>+
> >>  FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
> >missing reference file
> >
> >reference file './tests/ref/fate/mpegts-probe-program' not found
> >./tests/fate-run.sh: 419: ./tests/fate-run.sh: cannot open 
> >tests/data/fate/mpegts-probe-program.diff: No such file
> >Test mpegts-probe-program failed. Look at 
> >tests/data/fate/mpegts-probe-program.err for details.
> >make: *** [fate-mpegts-probe-program] Error 1
> >make: *** Waiting for unfinished jobs
> >
> >[...]
> >
> >
> sorry, ref file was not included. Corrected patch enclosed.

will apply with the related patch

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[wm4]

On Thu, 12 Apr 2018 16:22:01 -0300
James Almer  wrote:

> On 4/12/2018 3:59 PM, wm4 wrote:
> > On Thu, 12 Apr 2018 15:34:29 -0300
> > James Almer  wrote:
> >   
> >> If the parser returns full frames, then the output pointer retured by
> >> av_parser_parse2() is guaranteed to point to data contained in the
> >> input packet's buffer.
> >>
> >> Create a new reference to said buffer in that case, to avoid
> >> unnecessary data copy when queueing the packet later in the function.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavformat/utils.c | 23 ---
> >>  1 file changed, 20 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index 3e482a3bbc..8ad2ef4d70 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -1471,6 +1471,22 @@ static int parse_packet(AVFormatContext *s, 
> >> AVPacket *pkt, int stream_index)
> >>  if (!out_pkt.size)
> >>  continue;
> >>  
> >> +if (pkt->buf && out_pkt.data == pkt->data) {
> >> +/* reference pkt->buf only when out_pkt.data is guaranteed to 
> >> point
> >> + * to data in it and not in the parser's internal buffer. */
> >> +/* XXX: Ensure this is the case with all parsers when the 
> >> muxer sets
> >> + * PARSER_FLAG_COMPLETE_FRAMES and check for that instead? */
> >> +out_pkt.buf = av_buffer_ref(pkt->buf);
> >> +if (!out_pkt.buf) {
> >> +ret = AVERROR(ENOMEM);
> >> +goto fail;
> >> +}
> >> +} else {
> >> +ret = av_packet_make_refcounted(_pkt);
> >> +if (ret < 0)
> >> +goto fail;
> >> +}
> >> +
> >>  if (pkt->side_data) {
> >>  out_pkt.side_data   = pkt->side_data;
> >>  out_pkt.side_data_elems = pkt->side_data_elems;
> >> @@ -1511,10 +1527,11 @@ static int parse_packet(AVFormatContext *s, 
> >> AVPacket *pkt, int stream_index)
> >>  
> >>  ret = ff_packet_list_put(>internal->parse_queue,
> >>   >internal->parse_queue_end,
> >> - _pkt, FF_PACKETLIST_FLAG_REF_PACKET);
> >> -av_packet_unref(_pkt);
> >> -if (ret < 0)
> >> + _pkt, 0);
> >> +if (ret < 0) {
> >> +av_packet_unref(_pkt);
> >>  goto fail;
> >> +}
> >>  }
> >>  
> >>  /* end of the stream => close and free the parser */  
> > 
> > For which cases is this?  
> 
> Pretty much every single packet from a demuxer that sets
> AVSTREAM_PARSE_HEADERS, meaning every non-raw demuxer with a couple
> exceptions.
> 
> > Maybe we should just make a new parser API (or
> > reuse the BSF one), and make it cover the cases we care about.  
> 
> I remember a new parser API that works on packets rather than raw data,
> much like the new bsf API, was the plan at some point.
> There's no lack of ideas in any case, just manpower in general.

To be honest I wish we just did away with this probing stuff and
restrict libavformat to actually demuxing stuff.

Could we use that PARSE_HEADERS probably never changes packet contents?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aac: Rework extradata parsing code

[Vittorio Giovara]

- enable the parsing code
- use the new buffer instead of replacing the context one
- do not push/pop configuration, just discard the exiting one
- propagate errors correctly
---
 libavcodec/aacdec_template.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index cf97181092..0c899285dd 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3324,20 +3324,14 @@ static int aac_decode_frame(AVCodecContext *avctx, void 
*data,
AV_PKT_DATA_JP_DUALMONO,
_dualmono_size);
 
-if (new_extradata && 0) {
-av_free(avctx->extradata);
-avctx->extradata = av_mallocz(new_extradata_size +
-  AV_INPUT_BUFFER_PADDING_SIZE);
-if (!avctx->extradata)
-return AVERROR(ENOMEM);
-avctx->extradata_size = new_extradata_size;
-memcpy(avctx->extradata, new_extradata, new_extradata_size);
-push_output_configuration(ac);
-if (decode_audio_specific_config(ac, ac->avctx, >oc[1].m4ac,
- avctx->extradata,
- avctx->extradata_size*8LL, 1) < 0) {
-pop_output_configuration(ac);
-return AVERROR_INVALIDDATA;
+if (new_extradata) {
+/* discard previous configuration */
+ac->oc[1].status = OC_NONE;
+err = decode_audio_specific_config(ac, ac->avctx, >oc[1].m4ac,
+   new_extradata,
+   new_extradata_size * 8LL, 1);
+if (err < 0) {
+return err;
 }
 }
 
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Carl Eugen Hoyos]

2018-04-12 23:42 GMT+02:00, Alexander Kravchenko :
>
> This patch contains DXVA2 textures support implementation
> by AMF encoder (in addition of D3D11 textures)

> +if (frames_ctx->device_ctx->hwctx) {
> +#if CONFIG_D3D11VA
> +if (frames_ctx->device_ctx->type ==
> AV_HWDEVICE_TYPE_D3D11VA) {

if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...

same below.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Wednesday, April 11, 2018 2:13 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D 
> frames used as input during the encoding process
> 

> 
> Two minor points below, not enough to merit another cycle so I fixed them and 
> pushed.
> 

Hi Mark,
Thanks for your help reviewing, fixing, and pushing patch

I have send one more patch with subject: [PATCH] lavc/amfenc: DXVA2 textures 
support implementation by AMF encoder
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228186.html

Could you please review it?

FYI, my next steps are:
* hwcontext_amf + apply using one in amfenc.
* vf_scale_amf
* code cleanup

Thanks,
Alexander

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Alexander Kravchenko]

This patch contains DXVA2 textures support implementation by AMF encoder (in 
addition of D3D11 textures)

Samples of usage:
DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i 
input.mp4 -an -c:v h264_amf out.mkv

D3D11va decoder -> d3d11 texture -> AMF Encoder:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i 
input.mp4 -an -c:v h264_amf out.mkv


---
 libavcodec/amfenc.c | 123 +++-
 1 file changed, 102 insertions(+), 21 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..c1f65f909d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 #if CONFIG_D3D11VA
 AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_NONE
 };
@@ -69,6 +75,7 @@ static const FormatMap format_map[] =
 { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
 { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
 { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
 };
 
 
@@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
 return 0;
 }
 
+static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr, _handle))) {
+if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle, 
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for 
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9 
device: %lx.\n", (unsigned long)hr);
+}
+}
+
 static int amf_init_context(AVCodecContext *avctx)
 {
 AmfContext *ctx = avctx->priv_data;
@@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
 res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext() 
failed with error %d\n", res);
 // try to reuse existing DX device
-#if CONFIG_D3D11VA
 if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
-if (amf_av_to_amf_format(device_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
-if (device_ctx->device_ctx->hwctx) {
-AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
+AVHWFramesContext *frames_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+if (amf_av_to_amf_format(frames_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
+if (frames_ctx->device_ctx->hwctx) {
+#if CONFIG_D3D11VA
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
+AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
 res = ctx->context->pVtbl->InitDX11(ctx->context, 
device_d3d11->device, AMF_DX11_1);
 if (res == AMF_OK) {
 ctx->hw_frames_ctx = 
av_buffer_ref(avctx->hw_frames_ctx);
 if (!ctx->hw_frames_ctx) {
 return AVERROR(ENOMEM);
 }
-if (device_ctx->initial_pool_size > 0)
-ctx->hwsurfaces_in_queue_max = 
device_ctx->initial_pool_size - 1;
+if (frames_ctx->initial_pool_size > 0)
+ctx->hwsurfaces_in_queue_max = 
frames_ctx->initial_pool_size - 1;
 } else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has D3D11 device which doesn't have D3D11VA interface, switching to default\n");
 else
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has non-AMD device, switching to default\n");
 }
 }
-} else {
-av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx has format 
not uspported by AMF, switching to default\n");
+#endif
+#if CONFIG_DXVA2
+  

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: Fix extradata memleak

[Michael Niedermayer]

On Tue, Apr 10, 2018 at 02:28:19AM +0200, Michael Niedermayer wrote:
> Fixes: crbug 822705
> 
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 6 ++
>  1 file changed, 6 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Fix integer overflow with last_poc

[Michael Niedermayer]

On Tue, Apr 10, 2018 at 02:28:20AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2147483646 - -2816 cannot be represented in 
> type 'int'
> Fixes: crbug 823145
> 
> Reported-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_slice.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Check input buffer size.

[Michael Niedermayer]

On Tue, Apr 10, 2018 at 11:25:39PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 6381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5665032743419904
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mjpegdec.c | 4 
>  libavcodec/mjpegdec.h | 1 +
>  2 files changed, 5 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSOC 2018 qualification task.

[ANURAG SINGH IIT BHU]

Hello,
I have implemented the reviews mentioned on previous patch, now there is no
need to provide any subtitle file to the filter, I am attaching the
complete patch of the hellosubs filter.

Command to run the filter
ffmpeg -i  -vf hellosubs= helloout.mp4


Thanks and regards,
Anurag Singh.


‌

On Tue, Apr 10, 2018 at 4:55 AM, Rostislav Pehlivanov 
wrote:

> On 9 April 2018 at 19:10, Paul B Mahol  wrote:
>
> > On 4/9/18, Rostislav Pehlivanov  wrote:
> > > On 9 April 2018 at 03:59, ANURAG SINGH IIT BHU <
> > > anurag.singh.ph...@iitbhu.ac.in> wrote:
> > >
> > >> This mail is regarding the qualification task assigned to me for the
> > >> GSOC project
> > >> in FFmpeg for automatic real-time subtitle generation using speech to
> > text
> > >> translation ML model.
> > >>
> > >
> > > i really don't think lavfi is the correct place for such code, nor that
> > the
> > > project's repo should contain such code at all.
> > > This would need to be in another repo and a separate library.
> >
> > Why? Are you against ocr filter too?
> >
>
> The OCR filter uses libtessract so I'm fine with it. Like I said, as long
> as the actual code to do it is in an external library I don't mind.
> Mozilla recently released Deep Speech (https://github.com/mozilla/
> DeepSpeech)
> which does pretty much exactly speech to text and is considered to have the
> most accurate one out there. Someone just needs to convert the tensorflow
> code to something more usable.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From ac0e09d431ea68aebfaef6e2ed0b450e76d473d9 Mon Sep 17 00:00:00 2001
From: ddosvulnerability 
Date: Thu, 12 Apr 2018 22:06:43 +0530
Subject: [PATCH] avfilter: add hellosubs filter.

---
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_hellosubs.c | 513 +
 3 files changed, 515 insertions(+)
 create mode 100644 libavfilter/vf_hellosubs.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..770b1b5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -331,6 +331,7 @@ OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o framesync.o
 OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
 OBJS-$(CONFIG_STREAMSELECT_FILTER)   += f_streamselect.o framesync.o
 OBJS-$(CONFIG_SUBTITLES_FILTER)  += vf_subtitles.o
+OBJS-$(CONFIG_HELLOSUBS_FILTER)  += vf_hellosubs.o
 OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
 OBJS-$(CONFIG_SWAPRECT_FILTER)   += vf_swaprect.o
 OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 6eac828..a008908 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -322,6 +322,7 @@ extern AVFilter ff_vf_ssim;
 extern AVFilter ff_vf_stereo3d;
 extern AVFilter ff_vf_streamselect;
 extern AVFilter ff_vf_subtitles;
+extern AVFilter ff_vf_hellosubs;
 extern AVFilter ff_vf_super2xsai;
 extern AVFilter ff_vf_swaprect;
 extern AVFilter ff_vf_swapuv;
diff --git a/libavfilter/vf_hellosubs.c b/libavfilter/vf_hellosubs.c
new file mode 100644
index 000..b994050
--- /dev/null
+++ b/libavfilter/vf_hellosubs.c
@@ -0,0 +1,513 @@
+/*
+ * Copyright (c) 2011 Baptiste Coudurier
+ * Copyright (c) 2011 Stefano Sabatini
+ * Copyright (c) 2012 Clément Bœsch
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Libass hellosubs burning filter.
+ *
+ 
+ */
+
+#include 
+
+#include "config.h"
+#if CONFIG_SUBTITLES_FILTER
+# include "libavcodec/avcodec.h"
+# include "libavformat/avformat.h"
+#endif
+#include "libavutil/avstring.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "drawutils.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "formats.h"
+#include "video.h"
+#include 
+#include 
+#include 
+
+typedef struct AssContext {
+const AVClass *class;
+ASS_Library  *library;
+ASS_Renderer *renderer;
+ASS_Track*track;
+char *filename;
+

Re: [FFmpeg-devel] [PATCH] avformat/mux: ignore invalid timestamps on formats without timestamps

[Hendrik Leppkes]

On Thu, Apr 12, 2018 at 9:59 PM, Michael Niedermayer
 wrote:
> On Thu, Apr 12, 2018 at 10:20:38AM +0200, Hendrik Leppkes wrote:
>> ---
>>  libavformat/mux.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> can you provide an example/testcase of when this is needed ?
>

Just take any file with that particular timestamp problem and try
muxing its audio into a raw audio formt, like .ac3. It already ignores
that error on non-strict timestamps, so it should even moreso ignore
it when not handling timestamps at all.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] make swresample optional for ffmpeg

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 configure| 2 +-
 fftools/ffmpeg_opt.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 1e192f8780..a0c05c043d 100755
--- a/configure
+++ b/configure
@@ -3458,7 +3458,7 @@ avfilter_extralibs="pthreads_extralibs"
 avutil_extralibs="d3d11va_extralibs nanosleep_extralibs pthreads_extralibs 
vaapi_drm_extralibs vaapi_x11_extralibs vdpau_x11_extralibs"
 
 # programs
-ffmpeg_deps="avcodec avfilter avformat swresample"
+ffmpeg_deps="avcodec avfilter avformat"
 ffmpeg_select="aformat_filter anull_filter atrim_filter format_filter
null_filter
trim_filter"
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index d7a7eb0662..8ae68aec0e 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -3157,7 +3157,9 @@ void show_help_default(const char *opt, const char *arg)
 #if CONFIG_SWSCALE
 show_help_children(sws_get_class(), flags);
 #endif
+#if CONFIG_SWRESAMPLE
 show_help_children(swr_get_class(), AV_OPT_FLAG_AUDIO_PARAM);
+#endif
 show_help_children(avfilter_get_class(), AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_FILTERING_PARAM);
 show_help_children(av_bsf_get_class(), AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_BSF_PARAM);
 }
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mux: ignore invalid timestamps on formats without timestamps

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 10:20:38AM +0200, Hendrik Leppkes wrote:
> ---
>  libavformat/mux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

can you provide an example/testcase of when this is needed ?

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[James Almer]

On 4/12/2018 3:59 PM, wm4 wrote:
> On Thu, 12 Apr 2018 15:34:29 -0300
> James Almer  wrote:
> 
>> If the parser returns full frames, then the output pointer retured by
>> av_parser_parse2() is guaranteed to point to data contained in the
>> input packet's buffer.
>>
>> Create a new reference to said buffer in that case, to avoid
>> unnecessary data copy when queueing the packet later in the function.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/utils.c | 23 ---
>>  1 file changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 3e482a3bbc..8ad2ef4d70 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -1471,6 +1471,22 @@ static int parse_packet(AVFormatContext *s, AVPacket 
>> *pkt, int stream_index)
>>  if (!out_pkt.size)
>>  continue;
>>  
>> +if (pkt->buf && out_pkt.data == pkt->data) {
>> +/* reference pkt->buf only when out_pkt.data is guaranteed to 
>> point
>> + * to data in it and not in the parser's internal buffer. */
>> +/* XXX: Ensure this is the case with all parsers when the muxer 
>> sets
>> + * PARSER_FLAG_COMPLETE_FRAMES and check for that instead? */
>> +out_pkt.buf = av_buffer_ref(pkt->buf);
>> +if (!out_pkt.buf) {
>> +ret = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>> +} else {
>> +ret = av_packet_make_refcounted(_pkt);
>> +if (ret < 0)
>> +goto fail;
>> +}
>> +
>>  if (pkt->side_data) {
>>  out_pkt.side_data   = pkt->side_data;
>>  out_pkt.side_data_elems = pkt->side_data_elems;
>> @@ -1511,10 +1527,11 @@ static int parse_packet(AVFormatContext *s, AVPacket 
>> *pkt, int stream_index)
>>  
>>  ret = ff_packet_list_put(>internal->parse_queue,
>>   >internal->parse_queue_end,
>> - _pkt, FF_PACKETLIST_FLAG_REF_PACKET);
>> -av_packet_unref(_pkt);
>> -if (ret < 0)
>> + _pkt, 0);
>> +if (ret < 0) {
>> +av_packet_unref(_pkt);
>>  goto fail;
>> +}
>>  }
>>  
>>  /* end of the stream => close and free the parser */
> 
> For which cases is this?

Pretty much every single packet from a demuxer that sets
AVSTREAM_PARSE_HEADERS, meaning every non-raw demuxer with a couple
exceptions.

> Maybe we should just make a new parser API (or
> reuse the BSF one), and make it cover the cases we care about.

I remember a new parser API that works on packets rather than raw data,
much like the new bsf API, was the plan at some point.
There's no lack of ideas in any case, just manpower in general.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[wm4]

On Thu, 12 Apr 2018 15:34:29 -0300
James Almer  wrote:

> If the parser returns full frames, then the output pointer retured by
> av_parser_parse2() is guaranteed to point to data contained in the
> input packet's buffer.
> 
> Create a new reference to said buffer in that case, to avoid
> unnecessary data copy when queueing the packet later in the function.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 3e482a3bbc..8ad2ef4d70 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1471,6 +1471,22 @@ static int parse_packet(AVFormatContext *s, AVPacket 
> *pkt, int stream_index)
>  if (!out_pkt.size)
>  continue;
>  
> +if (pkt->buf && out_pkt.data == pkt->data) {
> +/* reference pkt->buf only when out_pkt.data is guaranteed to 
> point
> + * to data in it and not in the parser's internal buffer. */
> +/* XXX: Ensure this is the case with all parsers when the muxer 
> sets
> + * PARSER_FLAG_COMPLETE_FRAMES and check for that instead? */
> +out_pkt.buf = av_buffer_ref(pkt->buf);
> +if (!out_pkt.buf) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +} else {
> +ret = av_packet_make_refcounted(_pkt);
> +if (ret < 0)
> +goto fail;
> +}
> +
>  if (pkt->side_data) {
>  out_pkt.side_data   = pkt->side_data;
>  out_pkt.side_data_elems = pkt->side_data_elems;
> @@ -1511,10 +1527,11 @@ static int parse_packet(AVFormatContext *s, AVPacket 
> *pkt, int stream_index)
>  
>  ret = ff_packet_list_put(>internal->parse_queue,
>   >internal->parse_queue_end,
> - _pkt, FF_PACKETLIST_FLAG_REF_PACKET);
> -av_packet_unref(_pkt);
> -if (ret < 0)
> + _pkt, 0);
> +if (ret < 0) {
> +av_packet_unref(_pkt);
>  goto fail;
> +}
>  }
>  
>  /* end of the stream => close and free the parser */

For which cases is this? Maybe we should just make a new parser API (or
reuse the BSF one), and make it cover the cases we care about.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[James Almer]

If the parser returns full frames, then the output pointer retured by
av_parser_parse2() is guaranteed to point to data contained in the
input packet's buffer.

Create a new reference to said buffer in that case, to avoid
unnecessary data copy when queueing the packet later in the function.

Signed-off-by: James Almer 
---
 libavformat/utils.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3e482a3bbc..8ad2ef4d70 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1471,6 +1471,22 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 if (!out_pkt.size)
 continue;
 
+if (pkt->buf && out_pkt.data == pkt->data) {
+/* reference pkt->buf only when out_pkt.data is guaranteed to point
+ * to data in it and not in the parser's internal buffer. */
+/* XXX: Ensure this is the case with all parsers when the muxer 
sets
+ * PARSER_FLAG_COMPLETE_FRAMES and check for that instead? */
+out_pkt.buf = av_buffer_ref(pkt->buf);
+if (!out_pkt.buf) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+} else {
+ret = av_packet_make_refcounted(_pkt);
+if (ret < 0)
+goto fail;
+}
+
 if (pkt->side_data) {
 out_pkt.side_data   = pkt->side_data;
 out_pkt.side_data_elems = pkt->side_data_elems;
@@ -1511,10 +1527,11 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 
 ret = ff_packet_list_put(>internal->parse_queue,
  >internal->parse_queue_end,
- _pkt, FF_PACKETLIST_FLAG_REF_PACKET);
-av_packet_unref(_pkt);
-if (ret < 0)
+ _pkt, 0);
+if (ret < 0) {
+av_packet_unref(_pkt);
 goto fail;
+}
 }
 
 /* end of the stream => close and free the parser */
-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Qualification task, simple ffserver implementation.

[wm4]

On Thu, 12 Apr 2018 19:12:36 +0200
Stephan Holljes  wrote:

> On Thu, Apr 12, 2018 at 6:59 PM, wm4  wrote:
> > On Thu, 12 Apr 2018 15:35:45 +0200
> > Stephan Holljes  wrote:
> >  
> >> This patchset is a new simple implementation of ffserver for a new
> >> repository. It is basically a port of 
> >> https://github.com/klaxa/mkvserver_mk2
> >> The self-implemented fifo buffers have been replaced by AVFifoBuffer.
> >> Documentation on the architecture is present in a separate file.
> >> Currently only matroska video and no configuration is supported.
> >> These features are part of the future work to be done during GSoC.  
> >
> > Doesn't look bad - definitely better than what we'd had if we had kept
> > the old ffserver.
> >
> > I don't quite like that it appears to use the libavformat HTTP server
> > (a thing which I question whether it really should exist), but whatever.  
> 
> As far as I understand it was kind of intended for this specific use.
> What would you suppose instead? Use another library? Run as a
> webserver cgi thing? (Could that even work?)
> Reimplementing the HTTP protocol clearly can't be the answer. I'm open
> to suggestions.

Probably use another library, but I guess I understand if people want
it to use the libavformat server.

> >
> > Documentation is a bit lacking.  
> 
> Ok I will add more. What parts do you feel are missing that are most
> important? (I found that usage is missing completely for example.
> Whoops.)

The doc patch seemed like a stub, so I just made a general statement.
It's missing a description of what it does (for the user), options,
examples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

> From: "Paul B Mahol" 
> To: "FFmpeg development discussions and patches" 
> Cc: "Damien Riegel" , "Patrick Keroulas" 
> 
> Sent: Wednesday, April 11, 2018 2:47:40 AM
> Subject: Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace 
> support

> On 4/10/18, Patrick Keroulas  wrote:
> > From: Damien Riegel 

> > This codec is already capable of depacking some combinations of pixel
> > formats and depth as defined in the RFC4175. The only difference between
> > progressive and interlace is that either a packet will contain the whole
> > frame, or only a field of the frame.

> > As FFmpeg is not capable of handling fields only and recompose an
> > interlaced frame from that, it has to be done by the codec. To achieve
> > that, it must use two AVPacket: one for each field (top and bottom).

> This is lie, FFmpeg handle fields only just fine.

We should have specified "There is no mechanism for interlaced frames 
reconstruction at the rtp demux level, so it has to be handled by the codec".

Or do you mean that there is no point recomposing frames from fields? 

Any other comment/hint on the implementation?

> > Signed-off-by: Damien Riegel 
> > Signed-off-by: Patrick Keroulas 
> > ---
> > libavcodec/avcodec.h | 4 +++
> > libavcodec/bitpacked.c | 76
> > ++
> > 2 files changed, 68 insertions(+), 12 deletions(-)

> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index fb0c6fa..350e8d9 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1480,6 +1480,10 @@ typedef struct AVPacket {
> > */
> > #define AV_PKT_FLAG_DISPOSABLE 0x0010

> > +/**
> > + * The packet contains a top field.
> > + */
> > +#define AV_PKT_FLAG_TOP_FIELD 0x0010

This flag will be fixed.

> > enum AVSideDataParamChangeFlags {
> > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> > diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> > index 85d4bdd..d81703d 100644
> > --- a/libavcodec/bitpacked.c
> > +++ b/libavcodec/bitpacked.c
> > @@ -33,15 +33,19 @@

> > struct BitpackedContext {
> > int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> > - AVPacket *pkt);
> > + AVPacket *pkt, int top_field);
> > + AVPacket *first_field_pkt;
> > };

> > /* For this format, it's a simple passthrough */
> > static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
> > - AVPacket *avpkt)
> > + AVPacket *avpkt, int top_field)
> > {
> > int ret;

> > + if (frame->interlaced_frame)
> > + return AVERROR_PATCHWELCOME;
> > +
> > /* there is no need to copy as the data already match
> > * a known pixel format */
> > frame->buf[0] = av_buffer_ref(avpkt->buf);
> > @@ -56,17 +60,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext
> > *avctx, AVFrame *frame,
> > }

> > static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame
> > *frame,
> > - AVPacket *avpkt)
> > + AVPacket *avpkt, int top_field)
> > {
> > uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height
> > * 20;
> > uint64_t packet_size = (uint64_t)avpkt->size * 8;
> > + int interlaced = frame->interlaced_frame;
> > GetBitContext bc;
> > uint16_t *y, *u, *v;
> > int ret, i, j;

> > -
> > - if (frame_size > packet_size)
> > + /* check packet size depending on the interlaced/progressive format */
> > + if (interlaced) {
> > + if ((frame_size >> 1) > packet_size)
> > + return AVERROR_INVALIDDATA;
> > + } else if (frame_size > packet_size) {
> > return AVERROR_INVALIDDATA;
> > + }

> > if (avctx->width % 2)
> > return AVERROR_PATCHWELCOME;
> > @@ -75,7 +84,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> > *avctx, AVFrame *frame,
> > if (ret)
> > return ret;

> > - for (i = 0; i < avctx->height; i++) {
> > + /*
> > + * if the frame is interlaced, the avpkt we are getting is either the
> > top
> > + * or the bottom field. If it's the bottom field, it contains all the
> > odd
> > + * lines of the recomposed frame, so we start at offset 1.
> > + */
> > + i = (interlaced && !top_field) ? 1 : 0;
> > +
> > + /*
> > + * Packets from interlaced frames contain either even lines, or odd
> > + * lines, so increment by two in that case.
> > + */
> > + for (; i < avctx->height; interlaced ? i += 2 : i++) {
> > y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
> > u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
> > v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> > @@ -100,13 +120,20 @@ static av_cold int
> > bitpacked_init_decoder(AVCodecContext *avctx)

> > if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
> > if (avctx->bits_per_coded_sample == 16 &&
> > - avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> > + avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> > +
> > + if 

Re: [FFmpeg-devel] [GSoC] Qualification task, simple ffserver implementation.

[Stephan Holljes]

On Thu, Apr 12, 2018 at 6:59 PM, wm4  wrote:
> On Thu, 12 Apr 2018 15:35:45 +0200
> Stephan Holljes  wrote:
>
>> This patchset is a new simple implementation of ffserver for a new
>> repository. It is basically a port of https://github.com/klaxa/mkvserver_mk2
>> The self-implemented fifo buffers have been replaced by AVFifoBuffer.
>> Documentation on the architecture is present in a separate file.
>> Currently only matroska video and no configuration is supported.
>> These features are part of the future work to be done during GSoC.
>
> Doesn't look bad - definitely better than what we'd had if we had kept
> the old ffserver.
>
> I don't quite like that it appears to use the libavformat HTTP server
> (a thing which I question whether it really should exist), but whatever.

As far as I understand it was kind of intended for this specific use.
What would you suppose instead? Use another library? Run as a
webserver cgi thing? (Could that even work?)
Reimplementing the HTTP protocol clearly can't be the answer. I'm open
to suggestions.

>
> Documentation is a bit lacking.

Ok I will add more. What parts do you feel are missing that are most
important? (I found that usage is missing completely for example.
Whoops.)

>
> Does the code assume av_fifo is thread safe? Because last time I
> looked, it claimed to be, but wasn't.

I think it does. Will add mutexes for locking them.

Thanks for the feedback!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Qualification task, simple ffserver implementation.

[wm4]

On Thu, 12 Apr 2018 15:35:45 +0200
Stephan Holljes  wrote:

> This patchset is a new simple implementation of ffserver for a new
> repository. It is basically a port of https://github.com/klaxa/mkvserver_mk2
> The self-implemented fifo buffers have been replaced by AVFifoBuffer.
> Documentation on the architecture is present in a separate file.
> Currently only matroska video and no configuration is supported.
> These features are part of the future work to be done during GSoC.

Doesn't look bad - definitely better than what we'd had if we had kept
the old ffserver.

I don't quite like that it appears to use the libavformat HTTP server
(a thing which I question whether it really should exist), but whatever.

Documentation is a bit lacking.

Does the code assume av_fifo is thread safe? Because last time I
looked, it claimed to be, but wasn't.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-04-10 22:34 GMT+02:00 Vasile Toncu :

> Hello,
>
> This is the first part of the first patch. I added interlace options to
> tinterlace. On the next patch I will delete vf_interlace.
>
>
> Thank you,
>
> Vasile Toncu
>
>
> From b2be4e949e071f9017d8a9d6fbd1fbb56505ac50 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu 
> Date: Tue, 10 Apr 2018 23:28:32 +0300
> Subject: [PATCH] Added interlace options to tinterlace
>
> ---
>  libavfilter/Makefile| 2 +-
>  libavfilter/vf_tinterlace.c | 9 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..586d9c7 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -231,7 +231,7 @@ OBJS-$(CONFIG_HYSTERESIS_FILTER) += vf_hysteresis.o
> framesync.o
>  OBJS-$(CONFIG_IDET_FILTER)   += vf_idet.o
>  OBJS-$(CONFIG_IL_FILTER) += vf_il.o
>  OBJS-$(CONFIG_INFLATE_FILTER)+= vf_neighbor.o
> -OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_interlace.o
> +OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_tinterlace.o
>  OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
>  OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
>  OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
> diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
> index f13791d..5bf384d 100644
> --- a/libavfilter/vf_tinterlace.c
> +++ b/libavfilter/vf_tinterlace.c
> @@ -53,6 +53,15 @@ static const AVOption tinterlace_options[] = {
>  {"complex_filter","enable complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>  {"cvlpf", "enable complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>  {"exact_tb",  "force a timebase which can represent
> timestamps exactly", 0, AV_OPT_TYPE_CONST, {.i64 =
> TINTERLACE_FLAG_EXACT_TB}, INT_MIN, INT_MAX, FLAGS, "flags" },
> +
> +{"scan",  "scanning mode",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +{"tff",   "top field first",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +{"bff",   "bottom field first",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +
> +{"lowpass",   "set vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX,
> FLAGS, "flags"},
> +{"off",   "disable low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = 0},INT_MIN, INT_MAX,
> FLAGS, "flags" },
> +{"linear","linear vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX,
> FLAGS, "flags" },
> +{"complex",   "complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>
>  {NULL}
>  };
> --
>
>
You need to write separate AVOption interlace_options and AVFilter
avfilter_vf_interlace in vf_tinterlace.c
Have a look at this patch:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e2054d911b38662f681bdc267e08312d313a

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Shared Thread Pool

[Malcolm Bechard]

On Thu, Apr 12, 2018 at 12:23 PM, wm4  wrote:

> On Thu, 12 Apr 2018 12:08:50 -0400
> Malcolm Bechard  wrote:
>
> > Hey,
> >
> > I'd like to restart the conversation about a Shared Thread Pool in
> FFmpeg.
> > I found a past conversation about it here:
> >
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186770.html.
> >
> > As far as I can tell there isn't a thread pool in FFmpeg so far, but I
> > apologize if this has been solved already and I missed the solution.
> >
> >
> > One of the contentious issues in that last conversation seems to be that
> > there was few real-world examples where FFmpegs current behavior of
> > spawning new threads for each decoder would cause issues. I'll provide
> > another example:
> >
> >
> > Live music shows often have a VJ (video jockey) that is performing live
> > along with the performer/band. This is particularly true for electronic
> > music, but is becoming more and more common for other music styles as
> well.
> >
> > The application the VJ uses allows them to choose from banks of
> > pre-rendered video, and blend/mix the layers of video in real time. What
> > video is going to be played is selected in real-time by the VJ depending
> on
> > what they currently want to show the audience, based on what the
> performer
> > is doing.
> >
> > To make this possible, the app will need to have a large bank of videos
> > already open and ready to play. 50+. These videos can not be opened when
> > the VJ decides to play them, the 100ms+ of time it takes to open a video
> > and allocate resources is far too slow for a real-time performance. So
> > although they aren't playing 50+ videos at the same time, all of the
> > resources those videos need to be played at an instants notice needs to
> be
> > allocated already. So, using a thread pool will greatly reduce the number
> > of threads that need to be allocated here.
> >
> >
> > The 50 videos they have in one bank is only one bank of many they have.
> > They may want to switch banks and load up another set of 50 videos. Not
> > having to spawn/kill new threads for every video that is opened will
> > improve the performance of opening and closing of videos when switching
> > banks.
> >
> >
> > Most importantly though, decode performance. Since H264/H265 is not a
> > constant-time decoder, it's impossible to know for sure how many threads
> > you need for your video to be able to play it back in real time. Some may
> > require 8, some may require 1, depending on the video content. To be safe
> > the app should assign enough threads for a worst-case decode at that
> > particular resolution. The VJ can mix all kinds of different videos at
> the
> > same time, multiple 4K videos, a mix of 1080p and 4K videos, some even
> > smaller ones. It could be 2-4 heavy files or 12 light ones, or anything
> in
> > between. Without a thread pool this causes heavy oversubscription to the
> > CPU cores, reducing performance. Avoiding oversubscription is exactly why
> > most modern parallel applications utilize thread pools.
> >
> >
> > To be clear, this usage case is already happening, and has been happening
> > for a long time. Adding thread pool support will push the limits of what
> > this use case can do even further. Yes, the need is there for that.
> >
> >
> > Is there any interest in adding thread pool capabilities to FFmpeg? If I
> > was to take on this work, would it be accepted into the code base?
> Ideally
> > the API would be such that the host application could provide it's own
> > thread pool to be used (using callbacks), to avoid having two thread
> pools
> > allocated (and contending with each other for the cores).
> >
> > I'm perfectly fine with this being entirely optional, and programming it
> in
> > such a way that the existing threading workflow stays functional, if
> there
> > is a desire for that.
>
> I think the most contentious issue (apart from the pointless flame that
> was not about how to implement it) was that there should be no global
> thread pool. If a shared thread pool is e.g. explicitly set on an
> AVCodecContext which should use it, that would be fine by me.
>
> Whether or not such a shared pool helps with anything is a different
> question.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Sure, making it something that is assigned per-context seems perfectly
reasonable.

Malcolm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Shared Thread Pool

[wm4]

On Thu, 12 Apr 2018 12:08:50 -0400
Malcolm Bechard  wrote:

> Hey,
> 
> I'd like to restart the conversation about a Shared Thread Pool in FFmpeg.
> I found a past conversation about it here:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186770.html.
> 
> As far as I can tell there isn't a thread pool in FFmpeg so far, but I
> apologize if this has been solved already and I missed the solution.
> 
> 
> One of the contentious issues in that last conversation seems to be that
> there was few real-world examples where FFmpegs current behavior of
> spawning new threads for each decoder would cause issues. I'll provide
> another example:
> 
> 
> Live music shows often have a VJ (video jockey) that is performing live
> along with the performer/band. This is particularly true for electronic
> music, but is becoming more and more common for other music styles as well.
> 
> The application the VJ uses allows them to choose from banks of
> pre-rendered video, and blend/mix the layers of video in real time. What
> video is going to be played is selected in real-time by the VJ depending on
> what they currently want to show the audience, based on what the performer
> is doing.
> 
> To make this possible, the app will need to have a large bank of videos
> already open and ready to play. 50+. These videos can not be opened when
> the VJ decides to play them, the 100ms+ of time it takes to open a video
> and allocate resources is far too slow for a real-time performance. So
> although they aren't playing 50+ videos at the same time, all of the
> resources those videos need to be played at an instants notice needs to be
> allocated already. So, using a thread pool will greatly reduce the number
> of threads that need to be allocated here.
> 
> 
> The 50 videos they have in one bank is only one bank of many they have.
> They may want to switch banks and load up another set of 50 videos. Not
> having to spawn/kill new threads for every video that is opened will
> improve the performance of opening and closing of videos when switching
> banks.
> 
> 
> Most importantly though, decode performance. Since H264/H265 is not a
> constant-time decoder, it's impossible to know for sure how many threads
> you need for your video to be able to play it back in real time. Some may
> require 8, some may require 1, depending on the video content. To be safe
> the app should assign enough threads for a worst-case decode at that
> particular resolution. The VJ can mix all kinds of different videos at the
> same time, multiple 4K videos, a mix of 1080p and 4K videos, some even
> smaller ones. It could be 2-4 heavy files or 12 light ones, or anything in
> between. Without a thread pool this causes heavy oversubscription to the
> CPU cores, reducing performance. Avoiding oversubscription is exactly why
> most modern parallel applications utilize thread pools.
> 
> 
> To be clear, this usage case is already happening, and has been happening
> for a long time. Adding thread pool support will push the limits of what
> this use case can do even further. Yes, the need is there for that.
> 
> 
> Is there any interest in adding thread pool capabilities to FFmpeg? If I
> was to take on this work, would it be accepted into the code base? Ideally
> the API would be such that the host application could provide it's own
> thread pool to be used (using callbacks), to avoid having two thread pools
> allocated (and contending with each other for the cores).
> 
> I'm perfectly fine with this being entirely optional, and programming it in
> such a way that the existing threading workflow stays functional, if there
> is a desire for that.

I think the most contentious issue (apart from the pointless flame that
was not about how to implement it) was that there should be no global
thread pool. If a shared thread pool is e.g. explicitly set on an
AVCodecContext which should use it, that would be fine by me.

Whether or not such a shared pool helps with anything is a different
question.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Shared Thread Pool

[Malcolm Bechard]

Hey,

I'd like to restart the conversation about a Shared Thread Pool in FFmpeg.
I found a past conversation about it here:

https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186770.html.

As far as I can tell there isn't a thread pool in FFmpeg so far, but I
apologize if this has been solved already and I missed the solution.


One of the contentious issues in that last conversation seems to be that
there was few real-world examples where FFmpegs current behavior of
spawning new threads for each decoder would cause issues. I'll provide
another example:


Live music shows often have a VJ (video jockey) that is performing live
along with the performer/band. This is particularly true for electronic
music, but is becoming more and more common for other music styles as well.

The application the VJ uses allows them to choose from banks of
pre-rendered video, and blend/mix the layers of video in real time. What
video is going to be played is selected in real-time by the VJ depending on
what they currently want to show the audience, based on what the performer
is doing.

To make this possible, the app will need to have a large bank of videos
already open and ready to play. 50+. These videos can not be opened when
the VJ decides to play them, the 100ms+ of time it takes to open a video
and allocate resources is far too slow for a real-time performance. So
although they aren't playing 50+ videos at the same time, all of the
resources those videos need to be played at an instants notice needs to be
allocated already. So, using a thread pool will greatly reduce the number
of threads that need to be allocated here.


The 50 videos they have in one bank is only one bank of many they have.
They may want to switch banks and load up another set of 50 videos. Not
having to spawn/kill new threads for every video that is opened will
improve the performance of opening and closing of videos when switching
banks.


Most importantly though, decode performance. Since H264/H265 is not a
constant-time decoder, it's impossible to know for sure how many threads
you need for your video to be able to play it back in real time. Some may
require 8, some may require 1, depending on the video content. To be safe
the app should assign enough threads for a worst-case decode at that
particular resolution. The VJ can mix all kinds of different videos at the
same time, multiple 4K videos, a mix of 1080p and 4K videos, some even
smaller ones. It could be 2-4 heavy files or 12 light ones, or anything in
between. Without a thread pool this causes heavy oversubscription to the
CPU cores, reducing performance. Avoiding oversubscription is exactly why
most modern parallel applications utilize thread pools.


To be clear, this usage case is already happening, and has been happening
for a long time. Adding thread pool support will push the limits of what
this use case can do even further. Yes, the need is there for that.


Is there any interest in adding thread pool capabilities to FFmpeg? If I
was to take on this work, would it be accepted into the code base? Ideally
the API would be such that the host application could provide it's own
thread pool to be used (using callbacks), to avoid having two thread pools
allocated (and contending with each other for the cores).

I'm perfectly fine with this being entirely optional, and programming it in
such a way that the existing threading workflow stays functional, if there
is a desire for that.


Thanks!


Malcolm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dxv.c | 1038 --
 1 file changed, 1003 insertions(+), 35 deletions(-)

diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 529e211258..af8038d377 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -1,6 +1,7 @@
 /*
  * Resolume DXV decoder
  * Copyright (C) 2015 Vittorio Giovara 
+ * Copyright (C) 2018 Paul B Mahol
  *
  * This file is part of FFmpeg.
  *
@@ -23,6 +24,7 @@
 
 #include "libavutil/imgutils.h"
 
+#include "mathops.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "internal.h"
@@ -34,50 +36,230 @@ typedef struct DXVContext {
 TextureDSPContext texdsp;
 GetByteContext gbc;
 
-uint8_t *tex_data;  // Compressed texture
-int tex_rat;// Compression ratio
-int tex_step;   // Distance between blocks
-int64_t tex_size;   // Texture size
+uint8_t *tex_data;   // Compressed texture
+uint8_t *ctex_data;  // Compressed texture
+int tex_rat; // Compression ratio
+int tex_step;// Distance between blocks
+int ctex_step;   // Distance between blocks
+int64_t tex_size;// Texture size
+int64_t ctex_size;   // Texture size
 
 /* Optimal number of slices for parallel decoding */
 int slice_count;
 
+uint8_t *op_data[4]; // Opcodes
+int64_t op_size[4];  // Opcodes size
+
+int texture_block_w;
+int texture_block_h;
+
+int ctexture_block_w;
+int ctexture_block_h;
+
 /* Pointer to the selected decompression function */
 int (*tex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t *block);
+int (*tex_funct_planar[2])(uint8_t *plane0, ptrdiff_t stride0,
+   uint8_t *plane1, ptrdiff_t stride1,
+   const uint8_t *block);
 } DXVContext;
 
+static void decompress_indices(uint8_t *dst, const uint8_t *src)
+{
+int block, i;
+
+for (block = 0; block < 2; block++) {
+int tmp = AV_RL24(src);
+
+/* Unpack 8x3 bit from last 3 byte block */
+for (i = 0; i < 8; i++)
+dst[i] = (tmp >> (i * 3)) & 0x7;
+
+src += 3;
+dst += 8;
+}
+}
+
+static int extract_component(int yo0, int yo1, int code)
+{
+int yo;
+
+if (yo0 == yo1) {
+yo = yo0;
+} else if (code == 0) {
+yo = yo0;
+} else if (code == 1) {
+yo = yo1;
+} else {
+if (yo0 > yo1) {
+yo = (uint8_t) (((8 - code) * yo0 +
+ (code - 1) * yo1) / 7);
+} else {
+if (code == 6) {
+yo = 0;
+} else if (code == 7) {
+yo = 255;
+} else {
+yo = (uint8_t) (((6 - code) * yo0 +
+ (code - 1) * yo1) / 5);
+}
+}
+}
+
+return yo;
+}
+
+static int cocg_block(uint8_t *plane0, ptrdiff_t stride0,
+  uint8_t *plane1, ptrdiff_t stride1,
+  const uint8_t *block)
+{
+uint8_t co_indices[16];
+uint8_t cg_indices[16];
+uint8_t co0 = *(block);
+uint8_t co1 = *(block + 1);
+uint8_t cg0 = *(block + 8);
+uint8_t cg1 = *(block + 9);
+int x, y;
+
+decompress_indices(co_indices, block + 2);
+decompress_indices(cg_indices, block + 10);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int co_code = co_indices[x + y * 4];
+int cg_code = cg_indices[x + y * 4];
+
+plane0[x] = extract_component(cg0, cg1, cg_code);
+plane1[x] = extract_component(co0, co1, co_code);
+}
+plane0 += stride0;
+plane1 += stride1;
+}
+
+return 16;
+}
+
+static void yo_subblock(uint8_t *dst, uint8_t *yo_indices,
+ptrdiff_t stride, const uint8_t *block)
+{
+uint8_t yo0 = *(block);
+uint8_t yo1 = *(block + 1);
+int x, y;
+
+decompress_indices(yo_indices, block + 2);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int yo_code = yo_indices[x + y * 4];
+
+dst[x] = extract_component(yo0, yo1, yo_code);
+}
+dst += stride;
+}
+}
+
+static int yo_block(uint8_t *dst, ptrdiff_t stride,
+uint8_t *unused0, ptrdiff_t unused1,
+const uint8_t *block)
+{
+uint8_t yo_indices[16];
+
+yo_subblock(dst,  yo_indices, stride, block);
+yo_subblock(dst + 4,  yo_indices, stride, block + 8);
+yo_subblock(dst + 8,  yo_indices, stride, block + 16);
+yo_subblock(dst + 12, yo_indices, stride, block + 24);
+
+return 32;
+}
+
+static void a_subblock(uint8_t *dst, uint8_t *a_indices,
+   ptrdiff_t stride, const uint8_t *block)
+{
+uint8_t a0 = *(block);
+uint8_t a1 = *(block + 1);
+int x, y;
+
+decompress_indices(a_indices, block + 2);
+
+for (y = 0; y < 4; y++) 

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Tomas Härdin]

tor 2018-04-12 klockan 16:47 +0200 skrev wm4:
> On Thu, 12 Apr 2018 16:43:48 +0200
> Tomas Härdin  wrote:
> 
> > sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> > > On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> > > > 
> > > > Good suggestion
> > > > 
> > > > /Tomas
> > > 
> > > Patch LGTM with the suggestion from James. Although I'm not on
> > > IRC
> > > very often lately you can add mine too if you feel like it:
> > > llogan.
> > 
> > Alright, how about this?
> 
> Btw. not everyone is going to have a GPG fingerprint.

That's true. I'd suggest they make themselves known :)

We could of course just omit fingerprint for those folks

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[wm4]

On Thu, 12 Apr 2018 16:43:48 +0200
Tomas Härdin  wrote:

> sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> > On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> > > 
> > > Good suggestion
> > > 
> > > /Tomas
> > 
> > Patch LGTM with the suggestion from James. Although I'm not on IRC
> > very often lately you can add mine too if you feel like it: llogan.
> 
> Alright, how about this?

Btw. not everyone is going to have a GPG fingerprint.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Tomas Härdin]

sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> > 
> > Good suggestion
> > 
> > /Tomas
> 
> Patch LGTM with the suggestion from James. Although I'm not on IRC
> very often lately you can add mine too if you feel like it: llogan.

Alright, how about this?

/TomasFrom 9cb24834d2f96773ca995ca8f4f408fa62a599b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Sat, 7 Apr 2018 12:18:00 +0200
Subject: [PATCH] Add IRC nicknames

---
 MAINTAINERS | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c54ad6781..d2f46d105d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -574,8 +574,11 @@ Releases
 If you want to maintain an older release, please contact us
 
 
-GnuPG Fingerprints of maintainers and contributors
-==
+GnuPG Fingerprints and IRC nicknames of maintainers and contributors
+
+
+IRC nicknames are in parentheses. These apply
+to the IRC channels listed on the website.
 
 Alexander Strasser1C96 78B7 83CB 8AA7 9AF5 D1EB A7D8 A57B A876 E58F
 Anssi Hannula 1A92 FF42 2DD9 8D2E 8AF7 65A9 4278 C520 513D F3CB
@@ -593,7 +596,7 @@ Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368
 James Almer   7751 2E8C FD94 A169 57E6 9A7A 1463 01AD 7376 59E0
 Jean Delvare  7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A
 Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F 56DE
-Lou Logan 7D68 DC73 CBEF EABB 671A B6CF 621C 2E28 82F8 DC3A
+Lou Logan (llogan)7D68 DC73 CBEF EABB 671A B6CF 621C 2E28 82F8 DC3A
 Michael Niedermayer   9FF2 128B 147E F673 0BAD F133 611E C787 040B 0FAB
 Nicolas George24CE 01CE 9ACC 5CEB 74D8 8D9D B063 D997 36E5 4C93
 Nikolay Aleksandrov   8978 1D8C FB71 588E 4B27 EAA8 C4F0 B5FC E011 13B1
@@ -610,5 +613,5 @@ Steinar H. Gunderson  C2E9 004F F028 C18E 4EAD DB83 7F61 7561 7797 8F76
 Stephan Hilb  4F38 0B3A 5F39 B99B F505 E562 8D5C 5554 4E17 8863
 Tiancheng "Timothy" Gu9456 AFC0 814A 8139 E994 8351 7FE6 B095 B582 B0D4
 Tim Nicholson 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-Tomas Härdin  A79D 4E3D F38F 763F 91F5 8B33 A01E 8AE0 41BB 2551
+Tomas Härdin (thardin)A79D 4E3D F38F 763F 91F5 8B33 A01E 8AE0 41BB 2551
 Wei Gao   4269 7741 857A 0E60 9EC5 08D2 4744 4EFA 62C1 87B9
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[wm4]

On Wed, 11 Apr 2018 14:01:08 +0100
Rostislav Pehlivanov  wrote:

> On 28 March 2018 at 22:59, Drew Allen 
> wrote:
> 
> > Hello all,
> >
> > My name is Andrew Allen and I'm a contributor to Opus, supporting new
> > channel mappings 2 and 3 for ambisonics compression. I've attached a patch
> > to support the new OpusProjectionEncoder and OpusProjectionDecoder APIs for
> > handling the new channel mapping 3 in OPUS.
> >
> > Please let me know of any changes I should make or if there are any
> > questions I can help answer.
> >
> > Cheers,
> > Drew
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >  
> You don't set the channel layout to anything. We have support for some
> ambisonics formats. Use them. How else would users know what is what? Check
> the number of channels?
> Also what about mapping families 240(?) -> 254?
> I thought they were reserved for ambisonics (very recently too, though they
> don't define any specific layouts :/).
> 
> IMO this might need a new channel layout API with support for ambisonics
> because things are messy there as-is.

Libav has a patchset, but it's stalled.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[wm4]

On Thu, 12 Apr 2018 15:49:30 +0200
Michael Niedermayer  wrote:

> On Thu, Apr 12, 2018 at 01:57:34PM +0100, Rostislav Pehlivanov wrote:
> > On 12 April 2018 at 11:31, Paul B Mahol  wrote:
> >   
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavcodec/dxv.c | 1006 ++
> > > ++--
> > >  1 file changed, 978 insertions(+), 28 deletions(-)
> > >
> > >
> > > +
> > > +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> > > a)
> > > +{
> > > +int r, g, b;
> > > +
> > > +co = co - 127;
> > > +cg = cg - 127;
> > > +
> > > +r = av_clip_uint8(yo + co - cg);
> > > +g = av_clip_uint8(yo + cg);
> > > +b = av_clip_uint8(yo - co - cg);
> > > +
> > > +return (a << 24) | (b << 16) | (g << 8) | (r);
> > > +}  
> > 
> > 
> > Cinepak all over again? We're not doing and are never going to do  
> 
> no, its different.
> The cinepak case was a volunteer who wanted to maintain the cinepak code, had
> a patch that made the decoder several fold faster (in his practical use) and 
> possibly closer in output to the binary reference. That by doing colorspace
> convertion to the vector quantizer data tables IIRC
> 
> He was attacked
> cinepak in ffmpeg is unmaintained since then and there has been no further
> contribution from him since then either.
> 
> This case here is very different, noone depends on this IIUC.
> So i have no strong oppinion on this.
> 
> The mention of cinepak as a "good" example is what makes me a bit upset.
> I do not think we should be proud of how that cinepak case was handled.

No, he posted a patch that was unacceptable for several reasons. These
were pointed out. He then made a drama out of it, implying something
about how FFmpeg will fade into irrelevance because Cinepak support is
not the "best". And now you drag out this drama, for whatever reason.

He also failed to provide explanations why this was supposed to be
necessary. Keep in mind that he wanted to decode directly to obscure
packed RGB formats and such.

Also Cinepak is an obscure garbage codec, so it's not a big loss that
it's a bit slower. Nobody complained about Cinepak support ever, except
that one guy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dxva2: add VP9 10-bit Profile2 mode mappings

[James Almer]

On 4/12/2018 11:29 AM, wm4 wrote:
> On Wed, 11 Apr 2018 14:06:57 +0200
> Hendrik Leppkes  wrote:
> 
>> ---
>>  libavcodec/dxva2.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
>> index 6d831599af..32416112bf 100644
>> --- a/libavcodec/dxva2.c
>> +++ b/libavcodec/dxva2.c
>> @@ -44,6 +44,7 @@ DEFINE_GUID(ff_DXVA2_ModeVC1_D2010,  0x1b81beA4, 
>> 0xa0c7,0x11d3,0xb9,0x84,0x0
>>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main,  0x5b11d51b, 
>> 0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
>>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main10,0x107af0e0, 
>> 0xef1a,0x4d19,0xab,0xa8,0x67,0xa1,0x63,0x07,0x3d,0x13);
>>  
>> DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_Profile0,0x463707f8,0xa1d0,0x4585,0x87,0x6d,0x83,0xaa,0x6d,0x60,0xb8,0x9e);
>> +DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_10bit_Profile2,0xa4c749ef,0x6ecf,0x48aa,0x84,0x48,0x50,0xa7,0xa1,0x16,0x5f,0xf7);
>>  DEFINE_GUID(ff_DXVA2_NoEncrypt,  0x1b81beD0, 
>> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
>>  DEFINE_GUID(ff_GUID_NULL,0x, 
>> 0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
>>  DEFINE_GUID(ff_IID_IDirectXVideoDecoderService, 
>> 0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
>> @@ -67,6 +68,10 @@ static const int prof_hevc_main[]= 
>> {FF_PROFILE_HEVC_MAIN,
>>  FF_PROFILE_UNKNOWN};
>>  static const int prof_hevc_main10[]  = {FF_PROFILE_HEVC_MAIN_10,
>>  FF_PROFILE_UNKNOWN};
>> +static const int prof_vp9_profile0[] = {FF_PROFILE_VP9_0,
>> +FF_PROFILE_UNKNOWN};
>> +static const int prof_vp9_profile2[] = {FF_PROFILE_VP9_2,
>> +FF_PROFILE_UNKNOWN};
>>  
>>  static const dxva_mode dxva_modes[] = {
>>  /* MPEG-2 */
>> @@ -90,7 +95,8 @@ static const dxva_mode dxva_modes[] = {
>>  { _DXVA2_ModeHEVC_VLD_Main,   AV_CODEC_ID_HEVC, prof_hevc_main },
>>  
>>  /* VP8/9 */
>> -{ _DXVA2_ModeVP9_VLD_Profile0,AV_CODEC_ID_VP9 },
>> +{ _DXVA2_ModeVP9_VLD_Profile0,   AV_CODEC_ID_VP9, 
>> prof_vp9_profile0 },
>> +{ _DXVA2_ModeVP9_VLD_10bit_Profile2, AV_CODEC_ID_VP9, 
>> prof_vp9_profile2 },
>>  
>>  { NULL,  0 },
>>  };
> 
> Both patches LGTM.
> 
> (Whatever happened to Profile1?)

Profile 1 is yuv422p, yuv440p and yuv444p. No hardware ever will handle
that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dxva2: add VP9 10-bit Profile2 mode mappings

[wm4]

On Wed, 11 Apr 2018 14:06:57 +0200
Hendrik Leppkes  wrote:

> ---
>  libavcodec/dxva2.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index 6d831599af..32416112bf 100644
> --- a/libavcodec/dxva2.c
> +++ b/libavcodec/dxva2.c
> @@ -44,6 +44,7 @@ DEFINE_GUID(ff_DXVA2_ModeVC1_D2010,  0x1b81beA4, 
> 0xa0c7,0x11d3,0xb9,0x84,0x0
>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main,  0x5b11d51b, 
> 0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main10,0x107af0e0, 
> 0xef1a,0x4d19,0xab,0xa8,0x67,0xa1,0x63,0x07,0x3d,0x13);
>  
> DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_Profile0,0x463707f8,0xa1d0,0x4585,0x87,0x6d,0x83,0xaa,0x6d,0x60,0xb8,0x9e);
> +DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_10bit_Profile2,0xa4c749ef,0x6ecf,0x48aa,0x84,0x48,0x50,0xa7,0xa1,0x16,0x5f,0xf7);
>  DEFINE_GUID(ff_DXVA2_NoEncrypt,  0x1b81beD0, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
>  DEFINE_GUID(ff_GUID_NULL,0x, 
> 0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
>  DEFINE_GUID(ff_IID_IDirectXVideoDecoderService, 
> 0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
> @@ -67,6 +68,10 @@ static const int prof_hevc_main[]= 
> {FF_PROFILE_HEVC_MAIN,
>  FF_PROFILE_UNKNOWN};
>  static const int prof_hevc_main10[]  = {FF_PROFILE_HEVC_MAIN_10,
>  FF_PROFILE_UNKNOWN};
> +static const int prof_vp9_profile0[] = {FF_PROFILE_VP9_0,
> +FF_PROFILE_UNKNOWN};
> +static const int prof_vp9_profile2[] = {FF_PROFILE_VP9_2,
> +FF_PROFILE_UNKNOWN};
>  
>  static const dxva_mode dxva_modes[] = {
>  /* MPEG-2 */
> @@ -90,7 +95,8 @@ static const dxva_mode dxva_modes[] = {
>  { _DXVA2_ModeHEVC_VLD_Main,   AV_CODEC_ID_HEVC, prof_hevc_main },
>  
>  /* VP8/9 */
> -{ _DXVA2_ModeVP9_VLD_Profile0,AV_CODEC_ID_VP9 },
> +{ _DXVA2_ModeVP9_VLD_Profile0,   AV_CODEC_ID_VP9, 
> prof_vp9_profile0 },
> +{ _DXVA2_ModeVP9_VLD_10bit_Profile2, AV_CODEC_ID_VP9, 
> prof_vp9_profile2 },
>  
>  { NULL,  0 },
>  };

Both patches LGTM.

(Whatever happened to Profile1?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[wm4]

On Thu, 12 Apr 2018 13:57:34 +0100
Rostislav Pehlivanov  wrote:

> On 12 April 2018 at 11:31, Paul B Mahol  wrote:
> 
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/dxv.c | 1006 ++
> > ++--
> >  1 file changed, 978 insertions(+), 28 deletions(-)
> >
> >
> > +
> > +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> > a)
> > +{
> > +int r, g, b;
> > +
> > +co = co - 127;
> > +cg = cg - 127;
> > +
> > +r = av_clip_uint8(yo + co - cg);
> > +g = av_clip_uint8(yo + cg);
> > +b = av_clip_uint8(yo - co - cg);
> > +
> > +return (a << 24) | (b << 16) | (g << 8) | (r);
> > +}  
> 
> 
> Cinepak all over again? We're not doing and are never going to do
> conversion inside decoders. Output it as YCoCg by writing directly to the
> data planes. We support it. It doesn't matter if it's perfectly mappable to
> RGB, if you allow for 2 more bits of precision.

+1

> On 12 April 2018 at 11:31, Paul B Mahol  wrote:
> 
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/dxv.c | 1006 ++
> > ++--
> >  1 file changed, 978 insertions(+), 28 deletions(-)
> >
> > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> > index 529e211258..6308163735 100644
> > --- a/libavcodec/dxv.c
> > +++ b/libavcodec/dxv.c
> > @@ -1,6 +1,7 @@
> >  /*
> >   * Resolume DXV decoder
> >   * Copyright (C) 2015 Vittorio Giovara 
> > + * Copyright (C) 2018 Paul B Mahol
> >   *
> >   * This file is part of FFmpeg.
> >   *
> > @@ -23,6 +24,7 @@
> >
> >  #include "libavutil/imgutils.h"
> >
> > +#include "mathops.h"
> >  #include "avcodec.h"
> >  #include "bytestream.h"
> >  #include "internal.h"
> > @@ -34,53 +36,250 @@ typedef struct DXVContext {
> >  TextureDSPContext texdsp;
> >  GetByteContext gbc;
> >
> > -uint8_t *tex_data;  // Compressed texture
> > -int tex_rat;// Compression ratio
> > -int tex_step;   // Distance between blocks
> > -int64_t tex_size;   // Texture size
> > +uint8_t *tex_data;   // Compressed texture
> > +uint8_t *ctex_data;  // Compressed texture
> > +int tex_rat; // Compression ratio
> > +int tex_step;// Distance between blocks
> > +int ctex_step;   // Distance between blocks
> > +int64_t tex_size;// Texture size
> > +int64_t ctex_size;   // Texture size
> >
> >  /* Optimal number of slices for parallel decoding */
> >  int slice_count;
> >
> > +uint8_t *op_data[4]; // Opcodes
> > +int64_t op_size[4];  // Opcodes size
> > +
> > +int texture_block_w;
> > +int texture_block_h;
> > +
> > +int ctexture_block_w;
> > +int ctexture_block_h;
> > +
> >  /* Pointer to the selected decompression function */
> >  int (*tex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t
> > *block);
> > +int (*ctex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t
> > *block);
> >  } DXVContext;
> >
> > +static void decompress_indices(uint8_t *dst, const uint8_t *src)
> > +{
> > +int block, i;
> > +
> > +for (block = 0; block < 2; block++) {
> > +int tmp = AV_RL24(src);
> > +
> > +/* Unpack 8x3 bit from last 3 byte block */
> > +for (i = 0; i < 8; i++)
> > +dst[i] = (tmp >> (i * 3)) & 0x7;
> > +
> > +src += 3;
> > +dst += 8;
> > +}
> > +}
> > +
> > +static int extract_component(int yo0, int yo1, int code)
> > +{
> > +int yo;
> > +
> > +if (yo0 == yo1) {
> > +yo = yo0;
> > +} else if (code == 0) {
> > +yo = yo0;
> > +} else if (code == 1) {
> > +yo = yo1;
> > +} else {
> > +if (yo0 > yo1) {
> > +yo = (uint8_t) (((8 - code) * yo0 +
> > + (code - 1) * yo1) / 7);
> > +} else {
> > +if (code == 6) {
> > +yo = 0;
> > +} else if (code == 7) {
> > +yo = 255;
> > +} else {
> > +yo = (uint8_t) (((6 - code) * yo0 +
> > + (code - 1) * yo1) / 5);
> > +}
> > +}
> > +}
> > +
> > +return yo;
> > +}
> > +
> > +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> > a)
> > +{
> > +int r, g, b;
> > +
> > +co = co - 127;
> > +cg = cg - 127;
> > +
> > +r = av_clip_uint8(yo + co - cg);
> > +g = av_clip_uint8(yo + cg);
> > +b = av_clip_uint8(yo - co - cg);
> > +
> > +return (a << 24) | (b << 16) | (g << 8) | (r);
> > +}
> > +
> > +static int cocg_block(uint8_t *dst, ptrdiff_t stride,
> > +  const uint8_t *block)
> > +{
> > +uint8_t co_indices[16];
> > +uint8_t cg_indices[16];
> > +uint8_t co0 = *(block);
> > +uint8_t co1 = *(block + 1);
> > +uint8_t cg0 = *(block + 8);
> > +

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 02:42:11PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dxv.c | 1032 
> --
>  1 file changed, 1003 insertions(+), 29 deletions(-)
> 
> diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> index 529e211258..cd7b693663 100644
> --- a/libavcodec/dxv.c
> +++ b/libavcodec/dxv.c
> @@ -1,6 +1,7 @@
>  /*
>   * Resolume DXV decoder
>   * Copyright (C) 2015 Vittorio Giovara 
> + * Copyright (C) 2018 Paul B Mahol
>   *
>   * This file is part of FFmpeg.
>   *

[...]

> @@ -169,6 +368,728 @@ static int dxv_decompress_dxt1(AVCodecContext *avctx)
>  return 0;
>  }
>  
> +typedef struct OpcodeTable {
> +int16_t next;
> +uint8_t val1;
> +uint8_t val2;
> +} OpcodeTable;
> +

> +static int fill_ltable(GetByteContext *gb, uint32_t *table, int *nb_elements)
> +{
> +unsigned half = 512, bits = 1023, left = 1024, input, mask;
> +int value, counter = 0, rshift = 10, lshift = 30;
> +
> +mask = bytestream2_get_le32(gb) >> 2;
> +while (left) {

> +if (bytestream2_get_bytes_left(gb) < 0 || counter >= 256)

bytestream2_get_bytes_left returns unsigned so it cannot be negative


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 01:57:34PM +0100, Rostislav Pehlivanov wrote:
> On 12 April 2018 at 11:31, Paul B Mahol  wrote:
> 
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/dxv.c | 1006 ++
> > ++--
> >  1 file changed, 978 insertions(+), 28 deletions(-)
> >
> >
> > +
> > +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> > a)
> > +{
> > +int r, g, b;
> > +
> > +co = co - 127;
> > +cg = cg - 127;
> > +
> > +r = av_clip_uint8(yo + co - cg);
> > +g = av_clip_uint8(yo + cg);
> > +b = av_clip_uint8(yo - co - cg);
> > +
> > +return (a << 24) | (b << 16) | (g << 8) | (r);
> > +}
> 
> 
> Cinepak all over again? We're not doing and are never going to do

no, its different.
The cinepak case was a volunteer who wanted to maintain the cinepak code, had
a patch that made the decoder several fold faster (in his practical use) and 
possibly closer in output to the binary reference. That by doing colorspace
convertion to the vector quantizer data tables IIRC

He was attacked
cinepak in ffmpeg is unmaintained since then and there has been no further
contribution from him since then either.

This case here is very different, noone depends on this IIUC.
So i have no strong oppinion on this.

The mention of cinepak as a "good" example is what makes me a bit upset.
I do not think we should be proud of how that cinepak case was handled.


> conversion inside decoders. Output it as YCoCg by writing directly to the
> data planes. We support it. It doesn't matter if it's perfectly mappable to
> RGB, if you allow for 2 more bits of precision.


Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/4] ffserver: Implement publisher

[Stephan Holljes]

---
 publisher.c | 278 
 publisher.h | 134 +
 2 files changed, 412 insertions(+)
 create mode 100644 publisher.c
 create mode 100644 publisher.h

diff --git a/publisher.c b/publisher.c
new file mode 100644
index 000..d1ccb95
--- /dev/null
+++ b/publisher.c
@@ -0,0 +1,278 @@
+#include "publisher.h"
+#include "segment.h"
+#include 
+
+void client_log(struct Client *c)
+{
+char state[64];
+sprintf("State: ", state);
+switch(c->state) {
+case FREE:
+sprintf(state, "FREE");
+break;
+case RESERVED:
+sprintf(state, "RESERVED");
+break;
+case WAIT:
+sprintf(state, "WAIT");
+break;
+case WRITABLE:
+sprintf(state, "WRITABLE");
+break;
+case BUSY:
+sprintf(state, "BUSY");
+break;
+case BUFFER_FULL:
+sprintf(state, "BUFFER_FULL");
+break;
+default:
+sprintf(state, "UNDEFINED");
+break;
+}
+av_log(NULL, AV_LOG_INFO, "%s\n", state);
+}
+
+void client_disconnect(struct Client *c)
+{
+struct Segment *seg;
+av_write_trailer(c->ofmt_ctx);
+avio_close(c->ofmt_ctx->pb);
+avformat_free_context(c->ofmt_ctx);
+while(av_fifo_size(c->buffer)) {
+av_fifo_generic_read(c->buffer, , sizeof(struct Segment*), NULL);
+segment_unref(seg);
+}
+client_set_state(c, FREE);
+c->current_segment_id = -1;
+}
+
+void client_set_state(struct Client *c, enum State state)
+{
+pthread_mutex_lock(>state_lock);
+c->state = state;
+pthread_mutex_unlock(>state_lock);
+}
+
+void client_push_segment(struct Client *c, struct Segment *seg)
+{
+if (av_fifo_space(c->buffer) == 0) {
+av_log(NULL, AV_LOG_WARNING, "Client buffer full, dropping 
Segment.\n");
+client_set_state(c, BUFFER_FULL);
+return;
+}
+segment_ref(seg);
+av_fifo_generic_write(c->buffer, , sizeof(struct Segment*), NULL);
+client_set_state(c, WRITABLE);
+}
+
+void publisher_init(struct PublisherContext **pub)
+{
+int i;
+struct PublisherContext *pc = (struct PublisherContext*) 
malloc(sizeof(struct PublisherContext));
+pc->nb_threads = 4;
+pc->current_segment_id = -1;
+pc->shutdown = 0;
+pc->buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+pc->fs_buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+for (i = 0; i < MAX_CLIENTS; i++) {
+struct Client *c = >clients[i];
+c->buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+c->id = i;
+c->current_segment_id = -1;
+pthread_mutex_init(>state_lock, NULL);
+client_set_state(c, FREE);
+}
+*pub = pc;
+}
+
+void publisher_push_segment(struct PublisherContext *pub, struct Segment *seg)
+{
+struct Segment *drop;
+av_fifo_generic_write(pub->buffer, , sizeof(struct Segment*), NULL);
+segment_ref(seg);
+if (av_fifo_size(pub->fs_buffer) >= BUFFER_SEGMENTS * sizeof(struct 
Segment*)) {
+av_fifo_generic_read(pub->fs_buffer, , sizeof(struct Segment*), 
NULL);
+segment_unref(drop);
+}
+av_fifo_generic_write(pub->fs_buffer, , sizeof(struct Segment*), NULL);
+segment_ref(seg);
+}
+
+int publisher_reserve_client(struct PublisherContext *pub)
+{
+int i;
+for (i = 0; i < MAX_CLIENTS; i++) {
+switch(pub->clients[i].state) {
+case FREE:
+client_set_state(>clients[i], RESERVED);
+return 0;
+default:
+continue;
+}
+}
+return 1;
+}
+
+void publisher_cancel_reserve(struct PublisherContext *pub)
+{
+int i;
+for (i = 0; i < MAX_CLIENTS; i++) {
+switch(pub->clients[i].state) {
+case RESERVED:
+client_set_state(>clients[i], FREE);
+return;
+default:
+continue;
+}
+}
+return;
+}
+
+void client_push_prebuffer(struct PublisherContext *pub, struct Client *c)
+{
+int off;
+int size;
+struct Segment *seg;
+size = av_fifo_size(pub->fs_buffer);
+for (off = 0; off < size; off += sizeof(struct Segment*)) {
+av_fifo_generic_peek_at(pub->fs_buffer, , off, sizeof(struct 
Segment*), NULL);
+client_push_segment(c, seg);
+}
+}
+
+void publisher_add_client(struct PublisherContext *pub, AVFormatContext 
*ofmt_ctx)
+{
+int i;
+struct Segment *prebuffer_seg;
+for (i = 0; i < MAX_CLIENTS; i++) {
+switch(pub->clients[i].state) {
+case RESERVED:
+pub->clients[i].ofmt_ctx = ofmt_ctx;
+client_set_state(>clients[i], WRITABLE);
+client_push_prebuffer(pub, >clients[i]);
+return;
+default:
+continue;
+}
+}
+}
+
+void publisher_free(struct PublisherContext *pub)
+{
+int i;
+struct Segment *seg;

[FFmpeg-devel] [PATCH 1/4] ffserver: Implement refcounted segments.

[Stephan Holljes]

---
 segment.c | 143 ++
 segment.h | 104 +
 2 files changed, 247 insertions(+)
 create mode 100644 segment.c
 create mode 100644 segment.h

diff --git a/segment.c b/segment.c
new file mode 100644
index 000..0ef58a1
--- /dev/null
+++ b/segment.c
@@ -0,0 +1,143 @@
+#include 
+#include "segment.h"
+#include 
+
+#include 
+#include 
+
+
+void save_segment(struct Segment *seg, const char *filename)
+{
+FILE *out = fopen(filename, "w");
+fwrite(seg->buf, seg->size, 1, out);
+fclose(out);
+}
+
+void segment_free(struct Segment *seg)
+{
+av_log(NULL, AV_LOG_DEBUG, "Freeing segment\n");
+avformat_free_context(seg->fmt_ctx);
+av_free(seg->io_ctx->buffer);
+av_free(seg->io_ctx);
+free(seg->buf);
+free(seg->ts);
+free(seg);
+}
+
+void segment_ref(struct Segment *seg)
+{
+pthread_mutex_lock(>nb_read_lock);
+seg->nb_read++;
+av_log(NULL, AV_LOG_DEBUG, "  ref Readers: %d\n", seg->nb_read);
+pthread_mutex_unlock(>nb_read_lock);
+}
+
+void segment_unref(struct Segment *seg)
+{
+pthread_mutex_lock(>nb_read_lock);
+seg->nb_read--;
+pthread_mutex_unlock(>nb_read_lock);
+av_log(NULL, AV_LOG_DEBUG, "unref Readers: %d\n", seg->nb_read);
+if (seg->nb_read == 0) {
+segment_free(seg);
+}
+}
+
+void segment_ts_append(struct Segment *seg, int64_t dts, int64_t pts)
+{
+seg->ts = (int64_t*) realloc(seg->ts, sizeof(int64_t) * 2  * (seg->ts_len 
+ 2));
+seg->ts[seg->ts_len] = dts;
+seg->ts[seg->ts_len + 1] = pts;
+seg->ts_len += 2;
+return;
+}
+
+int segment_write(void *opaque, unsigned char *buf, int buf_size)
+{
+struct Segment *seg = (struct Segment*) opaque;
+seg->size += buf_size;
+seg->buf = (char*) realloc(seg->buf, seg->size);
+memcpy(seg->buf + seg->size - buf_size, buf, buf_size);
+return buf_size;
+}
+
+int segment_read(void *opaque, unsigned char *buf, int buf_size)
+{
+struct SegmentReadInfo *info = (struct SegmentReadInfo*) opaque;
+buf_size = buf_size < info->left ? buf_size : info->left;
+
+/* copy internal buffer data to buf */
+memcpy(buf, info->buf, buf_size);
+info->buf  += buf_size;
+info->left -= buf_size;
+return buf_size ? buf_size : AVERROR_EOF;
+}
+
+
+void segment_close(struct Segment *seg)
+{
+av_write_trailer(seg->fmt_ctx);
+}
+
+void segment_init(struct Segment **seg_p, AVFormatContext *fmt)
+{
+int ret;
+int i;
+AVStream *in_stream, *out_stream;
+AVCodecContext *codec_ctx;
+struct Segment *seg = (struct Segment*) malloc(sizeof(struct Segment));
+
+seg->ifmt = fmt->iformat;
+seg->fmt_ctx = NULL;
+seg->nb_read = 0;
+seg->size = 0;
+seg->ts = NULL;
+seg->ts_len = 0;
+seg->buf = NULL;
+seg->avio_buffer = (unsigned char*) av_malloc(AV_BUFSIZE);
+pthread_mutex_init(>nb_read_lock, NULL);
+seg->io_ctx = avio_alloc_context(seg->avio_buffer, AV_BUFSIZE, 1, seg, 
NULL, _write, NULL);
+seg->io_ctx->seekable = 0;
+avformat_alloc_output_context2(>fmt_ctx, NULL, "matroska", NULL);
+if ((ret = av_opt_set_int(seg->fmt_ctx, "flush_packets", 1, 
AV_OPT_SEARCH_CHILDREN)) < 0) {
+av_log(NULL, AV_LOG_WARNING, "Could not set flush_packets!\n");
+}
+
+seg->fmt_ctx->flags |= AVFMT_FLAG_GENPTS;
+seg->fmt_ctx->oformat->flags &= AVFMT_NOFILE;
+
+av_log(NULL, AV_LOG_DEBUG, "Initializing segment\n");
+
+for (i = 0; i < fmt->nb_streams; i++) {
+in_stream = fmt->streams[i];
+codec_ctx = avcodec_alloc_context3(NULL);
+avcodec_parameters_to_context(codec_ctx, in_stream->codecpar);
+out_stream = avformat_new_stream(seg->fmt_ctx, codec_ctx->codec);
+avcodec_free_context(_ctx);
+if (!out_stream) {
+av_log(NULL, AV_LOG_WARNING, "Failed allocating output stream\n");
+continue;
+}
+ret = avcodec_parameters_copy(out_stream->codecpar, 
in_stream->codecpar);
+if (ret < 0) {
+av_log(NULL, AV_LOG_WARNING, "Failed to copy context from input to 
output stream codec context\n");
+continue;
+}
+av_dict_copy(_stream->metadata, in_stream->metadata, 0);
+}
+
+seg->fmt_ctx->pb = seg->io_ctx;
+ret = avformat_write_header(seg->fmt_ctx, NULL);
+avio_flush(seg->io_ctx);
+if (ret < 0) {
+segment_close(seg);
+av_log(NULL, AV_LOG_WARNING, "Error occured while writing header: 
%s\n", av_err2str(ret));
+}
+
+
+av_log(NULL, AV_LOG_DEBUG, "Initialized segment.\n");
+
+*seg_p = seg;
+
+return;
+}
diff --git a/segment.h b/segment.h
new file mode 100644
index 000..fecbc66
--- /dev/null
+++ b/segment.h
@@ -0,0 +1,104 @@
+#ifndef SEGMENT_H
+#define SEGMENT_H
+
+#include 
+
+#define AV_BUFSIZE 4096
+
+struct SegmentReadInfo {
+char *buf;
+int left;
+};
+
+struct Segment {
+char *buf;
+AVIOContext *io_ctx;
+

[FFmpeg-devel] [PATCH 4/4] ffserver: Add basic documentation of the architecture

[Stephan Holljes]

---
 Documentation.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation.txt

diff --git a/Documentation.txt b/Documentation.txt
new file mode 100644
index 000..de7b522
--- /dev/null
+++ b/Documentation.txt
@@ -0,0 +1,30 @@
+Documentation
+-
+
+The current implementation has three different types of work that is done in
+different threads. These types are: reading a stream, accepting HTTP
+connections and writing media data to clients.
+
+The design tries to follow a Publisher-Subscriber-Pattern. The PublisherContext
+struct contains buffers of read media data and the list of clients. Clients
+themselves contain a buffer of media data that still has to be sent to them.
+
+The reading thread takes care of segmenting the stream into independent chunks
+of data and pushing it to the PublisherContext, which publishes the new Segment
+to connected clients. This publishing only adds this Segment to the client's
+buffer.
+
+The writing thread does the actual writing of data over the network. It checks
+each client's state and if there is data available that can be written to that
+client it is sent.
+
+The accept thread accepts new clients over HTTP and if not all client slots are
+in use, writes the stream-header and adds the client to the PublisherContext.
+
+A Segment is only stored in memory once and is refcounted. Buffers in the
+PublisherContext and clients contain pointers to Segments.
+
+Buffers are implemented using AVFifoBuffer.
+
+Client states are protected by pthread-mutex-locks, making it possible to run
+multiple write threads.
-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] ffserver: Implement ffserver and add Makefile

[Stephan Holljes]

---
 Makefile   |  15 ++
 ffserver.c | 451 +
 2 files changed, 466 insertions(+)
 create mode 100644 Makefile
 create mode 100644 ffserver.c

diff --git a/Makefile b/Makefile
new file mode 100644
index 000..a57393a
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,15 @@
+all: ffserver
+LAV_FLAGS = $(shell pkg-config --libs --cflags libavformat libavcodec 
libavutil)
+# LAV_FLAGS = -L/usr/local/lib -lavcodec -lavformat -lavutil
+
+ffserver: segment.o publisher.o ffserver.c
+   cc -g -Wall $(LAV_FLAGS)  -lpthread -o ffserver segment.o publisher.o 
ffserver.c
+
+segment.o: segment.c segment.h
+   cc -g -Wall $(LAV_FLAGS) -lpthread -c segment.c
+
+publisher.o: publisher.c publisher.h
+   cc -g -Wall $(LAV_FLAGS) -lpthread -c publisher.c
+
+clean:
+   rm *.o server
diff --git a/ffserver.c b/ffserver.c
new file mode 100644
index 000..ecdcc64
--- /dev/null
+++ b/ffserver.c
@@ -0,0 +1,451 @@
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "segment.h"
+#include "publisher.h"
+
+#define  BUFFER_SECS 30
+#define LISTEN_TIMEOUT_MSEC 1000
+
+struct ReadInfo {
+struct PublisherContext *pub;
+AVFormatContext *ifmt_ctx;
+char *in_filename;
+};
+
+struct WriteInfo {
+struct PublisherContext *pub;
+int thread_id;
+};
+
+struct AcceptInfo {
+struct PublisherContext *pub;
+AVFormatContext *ifmt_ctx;
+const char *out_uri;
+};
+
+
+void *read_thread(void *arg)
+{
+struct ReadInfo *info = (struct ReadInfo*) arg;
+AVFormatContext *ifmt_ctx = info->ifmt_ctx;
+int ret, i;
+int video_idx = -1;
+int id = 0;
+int64_t pts, now, start;
+struct Segment *seg = NULL;
+AVPacket pkt;
+AVStream *in_stream;
+AVRational tb;
+tb.num = 1;
+tb.den = AV_TIME_BASE;
+AVStream *stream;
+AVCodecContext *avctx;
+AVCodecParameters *params;
+enum AVMediaType type;
+
+if ((ret = avformat_find_stream_info(ifmt_ctx, NULL)) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Could not get input stream info.\n");
+goto end;
+}
+
+av_log(NULL, AV_LOG_INFO, "Finding video stream.\n");
+for (i = 0; i < ifmt_ctx->nb_streams; i++) {
+av_log(NULL, AV_LOG_DEBUG, "Checking stream %d\n", i);
+stream = ifmt_ctx->streams[i];
+avctx = avcodec_alloc_context3(NULL);
+if (!avctx) {
+av_log(NULL, AV_LOG_ERROR, "Could not allocate AVCodecContext.\n");
+goto end;
+}
+if ((ret = avcodec_parameters_to_context(avctx, stream->codecpar)) < 
0) {
+av_log(NULL, AV_LOG_ERROR, "Could not copy codec parameters.\n");
+goto end;
+}
+params = stream->codecpar;
+type = params->codec_type;
+if (type == AVMEDIA_TYPE_VIDEO) {
+video_idx = i;
+break;
+}
+}
+if (video_idx == -1) {
+av_log(NULL, AV_LOG_ERROR, "No video stream found.\n");
+goto end;
+}
+
+
+// All information needed to start segmenting the file is gathered now.
+// start BUFFER_SECS seconds "in the past" to "catch up" to real-time. Has 
no effect on streamed sources.
+start = av_gettime_relative() - BUFFER_SECS * AV_TIME_BASE;
+
+// segmenting main-loop
+
+for (;;) {
+ret = av_read_frame(ifmt_ctx, );
+if (ret < 0)
+break;
+
+in_stream = ifmt_ctx->streams[pkt.stream_index];
+if (pkt.pts == AV_NOPTS_VALUE) {
+pkt.pts = 0;
+}
+if (pkt.dts == AV_NOPTS_VALUE) {
+pkt.dts = 0;
+}
+
+// current pts
+pts = av_rescale_q(pkt.pts, in_stream->time_base, tb);
+
+// current stream "uptime"
+now = av_gettime_relative() - start;
+
+// simulate real-time reading
+while (pts > now) {
+usleep(1000);
+now = av_gettime_relative() - start;
+}
+
+// keyframe or first Segment
+if ((pkt.flags & AV_PKT_FLAG_KEY && pkt.stream_index == video_idx) || 
!seg) {
+if (seg) {
+segment_close(seg);
+
+publisher_push_segment(info->pub, seg);
+av_log(NULL, AV_LOG_DEBUG, "New segment pushed.\n");
+publish(info->pub);
+   av_log(NULL, AV_LOG_DEBUG, "Published new 
segment.\n");
+}
+segment_init(, ifmt_ctx);
+seg->id = id++;
+av_log(NULL, AV_LOG_DEBUG, "Starting new segment, id: %d\n", 
seg->id);
+}
+
+segment_ts_append(seg, pkt.dts, pkt.pts);
+ret = av_write_frame(seg->fmt_ctx, );
+av_packet_unref();
+if (ret < 0) {
+av_log(NULL,AV_LOG_ERROR, "av_write_frame() failed.\n");
+goto end;
+}
+}
+
+if (ret < 0 && ret != 

[FFmpeg-devel] [GSoC] Qualification task, simple ffserver implementation.

[Stephan Holljes]

This patchset is a new simple implementation of ffserver for a new
repository. It is basically a port of https://github.com/klaxa/mkvserver_mk2
The self-implemented fifo buffers have been replaced by AVFifoBuffer.
Documentation on the architecture is present in a separate file.
Currently only matroska video and no configuration is supported.
These features are part of the future work to be done during GSoC.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Paul B Mahol]

On 4/12/18, Rostislav Pehlivanov  wrote:
> On 12 April 2018 at 11:31, Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dxv.c | 1006 ++
>> ++--
>>  1 file changed, 978 insertions(+), 28 deletions(-)
>>
>>
>> +
>> +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
>> a)
>> +{
>> +int r, g, b;
>> +
>> +co = co - 127;
>> +cg = cg - 127;
>> +
>> +r = av_clip_uint8(yo + co - cg);
>> +g = av_clip_uint8(yo + cg);
>> +b = av_clip_uint8(yo - co - cg);
>> +
>> +return (a << 24) | (b << 16) | (g << 8) | (r);
>> +}
>
>
> Cinepak all over again? We're not doing and are never going to do
> conversion inside decoders. Output it as YCoCg by writing directly to the
> data planes. We support it. It doesn't matter if it's perfectly mappable to
> RGB, if you allow for 2 more bits of precision.

This is subsampled YCgCo, which is never going to be implemented in libswscale.

And there is already code in texturedsp which deals with this, but it is
for non-subsampled case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Rostislav Pehlivanov]

On 12 April 2018 at 11:31, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dxv.c | 1006 ++
> ++--
>  1 file changed, 978 insertions(+), 28 deletions(-)
>
>
> +
> +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> a)
> +{
> +int r, g, b;
> +
> +co = co - 127;
> +cg = cg - 127;
> +
> +r = av_clip_uint8(yo + co - cg);
> +g = av_clip_uint8(yo + cg);
> +b = av_clip_uint8(yo - co - cg);
> +
> +return (a << 24) | (b << 16) | (g << 8) | (r);
> +}


Cinepak all over again? We're not doing and are never going to do
conversion inside decoders. Output it as YCoCg by writing directly to the
data planes. We support it. It doesn't matter if it's perfectly mappable to
RGB, if you allow for 2 more bits of precision.

On 12 April 2018 at 11:31, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dxv.c | 1006 ++
> ++--
>  1 file changed, 978 insertions(+), 28 deletions(-)
>
> diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> index 529e211258..6308163735 100644
> --- a/libavcodec/dxv.c
> +++ b/libavcodec/dxv.c
> @@ -1,6 +1,7 @@
>  /*
>   * Resolume DXV decoder
>   * Copyright (C) 2015 Vittorio Giovara 
> + * Copyright (C) 2018 Paul B Mahol
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -23,6 +24,7 @@
>
>  #include "libavutil/imgutils.h"
>
> +#include "mathops.h"
>  #include "avcodec.h"
>  #include "bytestream.h"
>  #include "internal.h"
> @@ -34,53 +36,250 @@ typedef struct DXVContext {
>  TextureDSPContext texdsp;
>  GetByteContext gbc;
>
> -uint8_t *tex_data;  // Compressed texture
> -int tex_rat;// Compression ratio
> -int tex_step;   // Distance between blocks
> -int64_t tex_size;   // Texture size
> +uint8_t *tex_data;   // Compressed texture
> +uint8_t *ctex_data;  // Compressed texture
> +int tex_rat; // Compression ratio
> +int tex_step;// Distance between blocks
> +int ctex_step;   // Distance between blocks
> +int64_t tex_size;// Texture size
> +int64_t ctex_size;   // Texture size
>
>  /* Optimal number of slices for parallel decoding */
>  int slice_count;
>
> +uint8_t *op_data[4]; // Opcodes
> +int64_t op_size[4];  // Opcodes size
> +
> +int texture_block_w;
> +int texture_block_h;
> +
> +int ctexture_block_w;
> +int ctexture_block_h;
> +
>  /* Pointer to the selected decompression function */
>  int (*tex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t
> *block);
> +int (*ctex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t
> *block);
>  } DXVContext;
>
> +static void decompress_indices(uint8_t *dst, const uint8_t *src)
> +{
> +int block, i;
> +
> +for (block = 0; block < 2; block++) {
> +int tmp = AV_RL24(src);
> +
> +/* Unpack 8x3 bit from last 3 byte block */
> +for (i = 0; i < 8; i++)
> +dst[i] = (tmp >> (i * 3)) & 0x7;
> +
> +src += 3;
> +dst += 8;
> +}
> +}
> +
> +static int extract_component(int yo0, int yo1, int code)
> +{
> +int yo;
> +
> +if (yo0 == yo1) {
> +yo = yo0;
> +} else if (code == 0) {
> +yo = yo0;
> +} else if (code == 1) {
> +yo = yo1;
> +} else {
> +if (yo0 > yo1) {
> +yo = (uint8_t) (((8 - code) * yo0 +
> + (code - 1) * yo1) / 7);
> +} else {
> +if (code == 6) {
> +yo = 0;
> +} else if (code == 7) {
> +yo = 255;
> +} else {
> +yo = (uint8_t) (((6 - code) * yo0 +
> + (code - 1) * yo1) / 5);
> +}
> +}
> +}
> +
> +return yo;
> +}
> +
> +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> a)
> +{
> +int r, g, b;
> +
> +co = co - 127;
> +cg = cg - 127;
> +
> +r = av_clip_uint8(yo + co - cg);
> +g = av_clip_uint8(yo + cg);
> +b = av_clip_uint8(yo - co - cg);
> +
> +return (a << 24) | (b << 16) | (g << 8) | (r);
> +}
> +
> +static int cocg_block(uint8_t *dst, ptrdiff_t stride,
> +  const uint8_t *block)
> +{
> +uint8_t co_indices[16];
> +uint8_t cg_indices[16];
> +uint8_t co0 = *(block);
> +uint8_t co1 = *(block + 1);
> +uint8_t cg0 = *(block + 8);
> +uint8_t cg1 = *(block + 9);
> +int x, y;
> +
> +decompress_indices(co_indices, block + 2);
> +decompress_indices(cg_indices, block + 10);
> +
> +for (y = 0; y < 4; y++) {
> +for (x = 0; x < 4; x++) {
> +int co_code = co_indices[x + y * 4];
> +int cg_code = cg_indices[x + y * 4];
> +uint8_t co, cg;
> +
> +co = extract_component(co0, co1, co_code);

[FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dxv.c | 1032 --
 1 file changed, 1003 insertions(+), 29 deletions(-)

diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 529e211258..cd7b693663 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -1,6 +1,7 @@
 /*
  * Resolume DXV decoder
  * Copyright (C) 2015 Vittorio Giovara 
+ * Copyright (C) 2018 Paul B Mahol
  *
  * This file is part of FFmpeg.
  *
@@ -23,6 +24,7 @@
 
 #include "libavutil/imgutils.h"
 
+#include "mathops.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "internal.h"
@@ -34,53 +36,250 @@ typedef struct DXVContext {
 TextureDSPContext texdsp;
 GetByteContext gbc;
 
-uint8_t *tex_data;  // Compressed texture
-int tex_rat;// Compression ratio
-int tex_step;   // Distance between blocks
-int64_t tex_size;   // Texture size
+uint8_t *tex_data;   // Compressed texture
+uint8_t *ctex_data;  // Compressed texture
+int tex_rat; // Compression ratio
+int tex_step;// Distance between blocks
+int ctex_step;   // Distance between blocks
+int64_t tex_size;// Texture size
+int64_t ctex_size;   // Texture size
 
 /* Optimal number of slices for parallel decoding */
 int slice_count;
 
+uint8_t *op_data[4]; // Opcodes
+int64_t op_size[4];  // Opcodes size
+
+int texture_block_w;
+int texture_block_h;
+
+int ctexture_block_w;
+int ctexture_block_h;
+
 /* Pointer to the selected decompression function */
 int (*tex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t *block);
+int (*ctex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t *block);
 } DXVContext;
 
+static void decompress_indices(uint8_t *dst, const uint8_t *src)
+{
+int block, i;
+
+for (block = 0; block < 2; block++) {
+int tmp = AV_RL24(src);
+
+/* Unpack 8x3 bit from last 3 byte block */
+for (i = 0; i < 8; i++)
+dst[i] = (tmp >> (i * 3)) & 0x7;
+
+src += 3;
+dst += 8;
+}
+}
+
+static int extract_component(int yo0, int yo1, int code)
+{
+int yo;
+
+if (yo0 == yo1) {
+yo = yo0;
+} else if (code == 0) {
+yo = yo0;
+} else if (code == 1) {
+yo = yo1;
+} else {
+if (yo0 > yo1) {
+yo = (uint8_t) (((8 - code) * yo0 +
+ (code - 1) * yo1) / 7);
+} else {
+if (code == 6) {
+yo = 0;
+} else if (code == 7) {
+yo = 255;
+} else {
+yo = (uint8_t) (((6 - code) * yo0 +
+ (code - 1) * yo1) / 5);
+}
+}
+}
+
+return yo;
+}
+
+static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int a)
+{
+int r, g, b;
+
+co = co - 127;
+cg = cg - 127;
+
+r = av_clip_uint8(yo + co - cg);
+g = av_clip_uint8(yo + cg);
+b = av_clip_uint8(yo - co - cg);
+
+return (a << 24) | (b << 16) | (g << 8) | (r);
+}
+
+static int cocg_block(uint8_t *dst, ptrdiff_t stride,
+  const uint8_t *block)
+{
+uint8_t co_indices[16];
+uint8_t cg_indices[16];
+uint8_t co0 = *(block);
+uint8_t co1 = *(block + 1);
+uint8_t cg0 = *(block + 8);
+uint8_t cg1 = *(block + 9);
+int x, y;
+
+decompress_indices(co_indices, block + 2);
+decompress_indices(cg_indices, block + 10);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int co_code = co_indices[x + y * 4];
+int cg_code = cg_indices[x + y * 4];
+uint8_t co, cg;
+
+co = extract_component(co0, co1, co_code);
+cg = extract_component(cg0, cg1, cg_code);
+
+dst[x * 8 + 1] = co;
+dst[x * 8 + 2] = cg;
+dst[x * 8 + 5] = co;
+dst[x * 8 + 6] = cg;
+dst[x * 8 + stride + 1] = co;
+dst[x * 8 + stride + 2] = cg;
+dst[x * 8 + stride + 5] = co;
+dst[x * 8 + stride + 6] = cg;
+}
+dst += 2 * stride;
+}
+
+return 16;
+}
+
+static void yo_subblock(uint8_t *dst, uint8_t *yo_indices,
+ptrdiff_t stride, const uint8_t *block)
+{
+uint8_t yo0 = *(block);
+uint8_t yo1 = *(block + 1);
+int x, y;
+
+decompress_indices(yo_indices, block + 2);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int yo_code = yo_indices[x + y * 4];
+uint8_t yo;
+
+yo = extract_component(yo0, yo1, yo_code);
+
+AV_WL32(dst + x * 4, 255u << 24 | yo);
+}
+dst += stride;
+}
+}
+
+static int yo_block(uint8_t *dst, ptrdiff_t stride,
+const uint8_t *block)
+{
+uint8_t yo_indices[16];
+
+yo_subblock(dst,  yo_indices, stride, block);
+yo_subblock(dst + 16, 

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_mc : add hevc_mc for checkasm

[Yingming Fan]

Hello,

Any review?

Yingming Fan

> On Apr 9, 2018, at 10:12 AM, Yingming Fan  wrote:
> 
> From: Yingming Fan 
> 
> ---
> Hi, there.
> I plane to submit our arm32 neon codes for qpel and epel.
> While before this i will submit hevc_mc checkasm codes.
> This hevc_mc checkasm codes check every qpel and epel function, including 8 
> 10 and 12 bit.
> Passed test by using 'checkasm --test=hevc_mc' under Linux x86_64 MacOS 
> x86_64 and Linux arm64 platform.
> Also passed FATE test. 
> 
> tests/checkasm/Makefile   |   2 +-
> tests/checkasm/checkasm.c |   1 +
> tests/checkasm/checkasm.h |   1 +
> tests/checkasm/hevc_mc.c  | 547 ++
> tests/fate/checkasm.mak   |   1 +
> 5 files changed, 551 insertions(+), 1 deletion(-)
> create mode 100644 tests/checkasm/hevc_mc.c
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0233d2f989..e6c94cd676 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
> AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
> AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
> AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
> -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o
> +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o hevc_mc.o
> AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
> AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
> AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 20ce56932f..b95efc674d 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -117,6 +117,7 @@ static const struct {
> { "hevc_add_res", checkasm_check_hevc_add_res },
> { "hevc_idct", checkasm_check_hevc_idct },
> { "hevc_sao", checkasm_check_hevc_sao },
> +{ "hevc_mc", checkasm_check_hevc_mc },
> #endif
> #if CONFIG_HUFFYUV_DECODER
> { "huffyuvdsp", checkasm_check_huffyuvdsp },
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index dcab74de06..5a4a612da7 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -58,6 +58,7 @@ void checkasm_check_h264qpel(void);
> void checkasm_check_hevc_add_res(void);
> void checkasm_check_hevc_idct(void);
> void checkasm_check_hevc_sao(void);
> +void checkasm_check_hevc_mc(void);
> void checkasm_check_huffyuvdsp(void);
> void checkasm_check_jpeg2000dsp(void);
> void checkasm_check_llviddsp(void);
> diff --git a/tests/checkasm/hevc_mc.c b/tests/checkasm/hevc_mc.c
> new file mode 100644
> index 00..018f322c11
> --- /dev/null
> +++ b/tests/checkasm/hevc_mc.c
> @@ -0,0 +1,547 @@
> +/*
> + * Copyright (c) 2018 Yingming Fan 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include 
> +
> +#include "libavutil/intreadwrite.h"
> +
> +#include "libavcodec/avcodec.h"
> +
> +#include "libavcodec/hevcdsp.h"
> +
> +#include "checkasm.h"
> +
> +static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
> +static const uint32_t idx_width_map[8][2] = {{1, 4}, {3, 8}, {4, 12}, {5, 
> 16}, {6, 24}, {7, 32}, {8, 48}, {9, 64}};
> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> +#define PIXEL_STRIDE (AV_INPUT_BUFFER_PADDING_SIZE + MAX_PB_SIZE + 
> AV_INPUT_BUFFER_PADDING_SIZE)
> +#define BUF_SIZE ((MAX_PB_SIZE+4+4) * PIXEL_STRIDE * 2)
> +
> +#define randomize_buffers(buf0, buf1, size) \
> +do {\
> +uint32_t mask = pixel_mask[(bit_depth - 8) >> 1];   \
> +int k;  \
> +for (k = 0; k < size; k += 4) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A(buf0 + k, r);  \
> +AV_WN32A(buf1 + k, r);  \
> +}   \
> +} while (0)
> +
> +#define randomize_buffers2(buf0, buf1, size)\
> +do { 

[FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dxv.c | 1006 --
 1 file changed, 978 insertions(+), 28 deletions(-)

diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 529e211258..6308163735 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -1,6 +1,7 @@
 /*
  * Resolume DXV decoder
  * Copyright (C) 2015 Vittorio Giovara 
+ * Copyright (C) 2018 Paul B Mahol
  *
  * This file is part of FFmpeg.
  *
@@ -23,6 +24,7 @@
 
 #include "libavutil/imgutils.h"
 
+#include "mathops.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "internal.h"
@@ -34,53 +36,250 @@ typedef struct DXVContext {
 TextureDSPContext texdsp;
 GetByteContext gbc;
 
-uint8_t *tex_data;  // Compressed texture
-int tex_rat;// Compression ratio
-int tex_step;   // Distance between blocks
-int64_t tex_size;   // Texture size
+uint8_t *tex_data;   // Compressed texture
+uint8_t *ctex_data;  // Compressed texture
+int tex_rat; // Compression ratio
+int tex_step;// Distance between blocks
+int ctex_step;   // Distance between blocks
+int64_t tex_size;// Texture size
+int64_t ctex_size;   // Texture size
 
 /* Optimal number of slices for parallel decoding */
 int slice_count;
 
+uint8_t *op_data[4]; // Opcodes
+int64_t op_size[4];  // Opcodes size
+
+int texture_block_w;
+int texture_block_h;
+
+int ctexture_block_w;
+int ctexture_block_h;
+
 /* Pointer to the selected decompression function */
 int (*tex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t *block);
+int (*ctex_funct)(uint8_t *dst, ptrdiff_t stride, const uint8_t *block);
 } DXVContext;
 
+static void decompress_indices(uint8_t *dst, const uint8_t *src)
+{
+int block, i;
+
+for (block = 0; block < 2; block++) {
+int tmp = AV_RL24(src);
+
+/* Unpack 8x3 bit from last 3 byte block */
+for (i = 0; i < 8; i++)
+dst[i] = (tmp >> (i * 3)) & 0x7;
+
+src += 3;
+dst += 8;
+}
+}
+
+static int extract_component(int yo0, int yo1, int code)
+{
+int yo;
+
+if (yo0 == yo1) {
+yo = yo0;
+} else if (code == 0) {
+yo = yo0;
+} else if (code == 1) {
+yo = yo1;
+} else {
+if (yo0 > yo1) {
+yo = (uint8_t) (((8 - code) * yo0 +
+ (code - 1) * yo1) / 7);
+} else {
+if (code == 6) {
+yo = 0;
+} else if (code == 7) {
+yo = 255;
+} else {
+yo = (uint8_t) (((6 - code) * yo0 +
+ (code - 1) * yo1) / 5);
+}
+}
+}
+
+return yo;
+}
+
+static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int a)
+{
+int r, g, b;
+
+co = co - 127;
+cg = cg - 127;
+
+r = av_clip_uint8(yo + co - cg);
+g = av_clip_uint8(yo + cg);
+b = av_clip_uint8(yo - co - cg);
+
+return (a << 24) | (b << 16) | (g << 8) | (r);
+}
+
+static int cocg_block(uint8_t *dst, ptrdiff_t stride,
+  const uint8_t *block)
+{
+uint8_t co_indices[16];
+uint8_t cg_indices[16];
+uint8_t co0 = *(block);
+uint8_t co1 = *(block + 1);
+uint8_t cg0 = *(block + 8);
+uint8_t cg1 = *(block + 9);
+int x, y;
+
+decompress_indices(co_indices, block + 2);
+decompress_indices(cg_indices, block + 10);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int co_code = co_indices[x + y * 4];
+int cg_code = cg_indices[x + y * 4];
+uint8_t co, cg;
+
+co = extract_component(co0, co1, co_code);
+cg = extract_component(cg0, cg1, cg_code);
+
+dst[x * 8 + 1] = co;
+dst[x * 8 + 2] = cg;
+dst[x * 8 + 5] = co;
+dst[x * 8 + 6] = cg;
+dst[x * 8 + stride + 1] = co;
+dst[x * 8 + stride + 2] = cg;
+dst[x * 8 + stride + 5] = co;
+dst[x * 8 + stride + 6] = cg;
+}
+dst += 2 * stride;
+}
+
+return 16;
+}
+
+static void yo_subblock(uint8_t *dst, uint8_t *yo_indices,
+ptrdiff_t stride, const uint8_t *block)
+{
+uint8_t yo0 = *(block);
+uint8_t yo1 = *(block + 1);
+int x, y;
+
+decompress_indices(yo_indices, block + 2);
+
+for (y = 0; y < 4; y++) {
+for (x = 0; x < 4; x++) {
+int yo_code = yo_indices[x + y * 4];
+uint8_t yo;
+
+yo = extract_component(yo0, yo1, yo_code);
+
+AV_WL32(dst + x * 4, 255u << 24 | yo);
+}
+dst += stride;
+}
+}
+
+static int yo_block(uint8_t *dst, ptrdiff_t stride,
+const uint8_t *block)
+{
+uint8_t yo_indices[16];
+
+yo_subblock(dst,  yo_indices, stride, block);
+yo_subblock(dst + 16, 

Re: [FFmpeg-devel] [PATCH] ffprobe: report unavailable SAR correctly in stream info

[Timo Teras]

On Thu, 12 Apr 2018 11:07:36 +0300
Timo Teräs  wrote:

> av_guess_sample_aspect_ratio() will return undefined or missing
> value as {0,1}. This fixes show_stream() to check numerator to
> display 'N/A' when appropriate. show_frame() does this already
> correctly.
> 
> Signed-off-by: Timo Teräs 

Btw. This patch is sent because I have a .mp4 file where 0/1 SAR was
reported. This is the obvious fix to report it as N/A instead.

But I was trying to figure out how to make it display a proper SAR too.
My findings are as follows.

1. MP4 dictates that if 'pasp' atom is found, it declares the aspect
   ratio and should be used. This is now required to be present if
   it's non-square SAR.

2. If 'pasp' is not found, mov demux uses the stream/codec width/height
   ratio to calculate SAR. But only if the widths and heights do not
   match.

ffprobe uses av_guess_sample_aspect_ratio() without frame to figure out
the stream's SAR. This basically return stream->sample_aspect_ratio if
set, and as a fallback it returns (frame's or) codec's SAR. If neither
is set it returns undefined. 

Now my understanding is that mov demux does #2 above so the codec/frame
SAR gets properly used if proper SAR cannot be deduced from the
stream/codec dimensions.

However, mp4 specs (both QuickTime FF specs and ISO/IEC 14496-12:2015
indicate that 'pasp' is optional if SAR is 1:1 (or square pixels). So
IMHO basically .mp4 files without 'pasp' or codec defined SAR should be
reported as 1:1 SAR (at least on ffprobe; it may make sense not to
report it on the API level so ffmpeg can leave 'pasp' out when copying
bitstreams).

This is what is happening with my file. There's no 'pasp' and the h264
codec defined sar is 'undefined'. Thus the mp4 format implied 1:1 SAR
should be assumed as last resort at least for ffprobe results.

So I am wonder how we could fix ffprobe report proper SAR instead of
N/A for above kind files. Could av_guess_sample_aspect_ratio() perhaps
be added a flag to default to 1/1 if nothing else is defined based on
some flag? Or should this be isolated to ffprobe? Any suggestions where
to store this flag, or even last-resort SAR that can be set by demux?

Or would it be reasonable for ffprobe to assume 1/1 SAR for all file
formats if SAR does not seem to be available?

Timo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hls: remove redundant code

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/hls.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index ae0545a086..74f0c2ccc5 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -945,14 +945,8 @@ static struct segment *next_segment(struct playlist *pls)
 return pls->segments[n];
 }
 
-enum ReadFromURLMode {
-READ_NORMAL,
-READ_COMPLETE,
-};
-
 static int read_from_url(struct playlist *pls, struct segment *seg,
- uint8_t *buf, int buf_size,
- enum ReadFromURLMode mode)
+ uint8_t *buf, int buf_size)
 {
 int ret;
 
@@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls, struct 
segment *seg,
 if (seg->size >= 0)
 buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
 
-if (mode == READ_COMPLETE) {
-ret = avio_read(pls->input, buf, buf_size);
-if (ret != buf_size)
-av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
-} else
-ret = avio_read(pls->input, buf, buf_size);
+ret = avio_read(pls->input, buf, buf_size);
+if (ret != buf_size)
+av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
 
 if (ret > 0)
 pls->cur_seg_offset += ret;
@@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
*buf,
 while (1) {
 /* see if we can retrieve enough data for ID3 header */
 if (*len < ID3v2_HEADER_SIZE && buf_size >= ID3v2_HEADER_SIZE) {
-bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
*len, READ_COMPLETE);
+bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
*len);
 if (bytes > 0) {
 
 if (bytes == ID3v2_HEADER_SIZE - *len)
@@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
*buf,
 
 if (remaining > 0) {
 /* read the rest of the tag in */
-if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
remaining, READ_COMPLETE) != remaining)
+if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
remaining) != remaining)
 break;
 id3_buf_pos += remaining;
 av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional %d HLS ID3 
bytes\n", remaining);
@@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
*buf,
 
 /* re-fill buffer for the caller unless EOF */
 if (*len >= 0 && (fill_buf || *len == 0)) {
-bytes = read_from_url(pls, seg, buf + *len, buf_size - *len, 
READ_NORMAL);
+bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
 
 /* ignore error if we already had some data */
 if (bytes >= 0)
@@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist *pls, 
struct segment *seg)
 av_fast_malloc(>init_sec_buf, >init_sec_buf_size, sec_size);
 
 ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
-pls->init_sec_buf_size, READ_COMPLETE);
+pls->init_sec_buf_size);
 ff_format_io_close(pls->parent, >input);
 
 if (ret < 0)
@@ -1506,7 +1497,7 @@ reload:
 }
 
 seg = current_segment(v);
-ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
+ret = read_from_url(v, seg, buf, buf_size);
 if (ret > 0) {
 if (just_opened && v->is_id3_timestamped != 0) {
 /* Intercept ID3 tags here, elementary audio streams are required
-- 
2.15.1



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] lavf/aviobuf: add ff_get_chomp_line

[Jun Zhao]

On 2018/4/11 16:52, Marton Balint wrote:
>
>
> On Wed, 11 Apr 2018, Jun Zhao wrote:
>
>>
>>
>> On 2018/4/10 21:54, Marton Balint wrote:
>>>
>>>
>>> On Tue, 10 Apr 2018, Jun Zhao wrote:
>>>


>>>
>>> Maybe you should use ff_read_line_to_bprint instead? It already chops
>>> the trailing line endings, not any whitespace though. Generally I
>>> think we should deprecate ff_get_line, because line length limits
>>> always pop here or there...
>>>
>> ff_read_line_to_bprint usually use when we don't know the length limits
>> and need to the caller free the AVBPrint resource, in hls case, I think
>> this is a simple case, the other reason is I don't want to mix the
>> AVBPrint and c native char * in hls. Thanks.
>
> Since it's just factorization of existing code, then I guess it is OK.
Pushed , thanks the comments, Marton.
>
> But new code should not use either that or ff_get_line. (MAX_URL_SIZE
> being 4096 does not even adhere to the RFC recommendation of
> supporting at least 8000 char length URLs)
>
> https://tools.ietf.org/html/rfc7230#section-3.1.1
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

[Bodecs Bela]

2018.04.12. 0:26 keltezéssel, Michael Niedermayer írta:

On Wed, Apr 11, 2018 at 10:37:41PM +0200, Bodecs Bela wrote:

fate test enclosed


2018.04.04. 10:39 keltezéssel, Bodecs Bela írta:


2018.04.04. 2:37 keltezéssel, Michael Niedermayer írta:

On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:

Dear All,

currently when specifying the program id you can only decide to select
all stream of the specified program (e.g. p:103 will select all streams
of program 103) or narrow the selection to a specific stream sub index
(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
specify like all audio streams of program 145 or 3rd video stream of
program 311.
In some case, mainly working with multiprogram mpeg-ts containers as
input, this feature would be handy.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream type and optionally its
index. Handled types: a, v, s, d.
Examples: p:601:a  will select all audio streams of program 601,
p:603:a:1 will select 2nd audio streams of program 603,
p:604:v:0 will select first video stream of program 604.
This syntax enhancement does not interfere in any way with
current/exiting syntax or working command lines

I think this is a good idea.
Can you also add fate test(s) for this ? (can be in a seperate patch
later of course)


ok, I will try.

bb


thx

[...]



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

  mpegts.mak |6 ++
  1 file changed, 6 insertions(+)
da6c059eab100872d0f61d14e40e46012f031bfe  
0002-fate-to-test-program-sub-stream-selection-by-its-typ.patch
 From 093bdb47d1c5093cbd9427fbd2383a1c802464bb Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Wed, 11 Apr 2018 22:33:02 +0200
Subject: [PATCH] fate: to test program sub stream selection by its type in
  mpegts

Signed-off-by: Bela Bodecs 
---
  tests/fate/mpegts.mak | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
index bb0d9d9..2b12849 100644
--- a/tests/fate/mpegts.mak
+++ b/tests/fate/mpegts.mak
@@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-la
  fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
  fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
  
+

+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-program
+fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) -select_streams 
p:769:v:0 -i "$(SRC)"
+
+
  FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)

missing reference file

reference file './tests/ref/fate/mpegts-probe-program' not found
./tests/fate-run.sh: 419: ./tests/fate-run.sh: cannot open 
tests/data/fate/mpegts-probe-program.diff: No such file
Test mpegts-probe-program failed. Look at 
tests/data/fate/mpegts-probe-program.err for details.
make: *** [fate-mpegts-probe-program] Error 1
make: *** Waiting for unfinished jobs

[...]



sorry, ref file was not included. Corrected patch enclosed.

bb



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


From 9df4f0261f475b0e84aad299f190f1c35a9e62c0 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Wed, 11 Apr 2018 22:33:02 +0200
Subject: [PATCH] fate: to test program sub stream selection by its type in
 mpegts

Signed-off-by: Bela Bodecs 
---
 tests/fate/mpegts.mak   | 6 ++
 tests/ref/fate/mpegts-probe-program | 8 
 2 files changed, 14 insertions(+)
 create mode 100644 tests/ref/fate/mpegts-probe-program

diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
index bb0d9d9..2b12849 100644
--- a/tests/fate/mpegts.mak
+++ b/tests/fate/mpegts.mak
@@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-la
 fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
 fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
 
+
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-program
+fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
-select_streams p:769:v:0 -i "$(SRC)"
+
+
 FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
 
 fate-mpegts: $(FATE_MPEGTS_PROBE-yes)
diff --git a/tests/ref/fate/mpegts-probe-program 
b/tests/ref/fate/mpegts-probe-program
new file mode 100644
index 000..bb1012c
--- /dev/null
+++ b/tests/ref/fate/mpegts-probe-program
@@ -0,0 +1,8 @@
+[PROGRAM]
+[STREAM]

[FFmpeg-devel] [PATCH] avformat/mux: ignore invalid timestamps on formats without timestamps

[Hendrik Leppkes]

---
 libavformat/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index a13f0e3a1b..0857419394 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -615,7 +615,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 }
 
 if (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE &&
-((!(s->oformat->flags & AVFMT_TS_NONSTRICT) &&
+((!(s->oformat->flags & (AVFMT_TS_NONSTRICT|AVFMT_NOTIMESTAMPS)) &&
   st->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE &&
   st->codecpar->codec_type != AVMEDIA_TYPE_DATA &&
   st->cur_dts >= pkt->dts) || st->cur_dts > pkt->dts)) {
-- 
2.16.1.windows.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffprobe: report unavailable SAR correctly in stream info

[Timo Teräs]

av_guess_sample_aspect_ratio() will return undefined or missing
value as {0,1}. This fixes show_stream() to check numerator to
display 'N/A' when appropriate. show_frame() does this already
correctly.

Signed-off-by: Timo Teräs 
---
 fftools/ffprobe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 82dfe4f58a..8b2a18b6b1 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2521,7 +2521,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 #endif
 print_int("has_b_frames", par->video_delay);
 sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
-if (sar.den) {
+if (sar.num) {
 print_q("sample_aspect_ratio", sar, ':');
 av_reduce(, ,
   par->width  * sar.num,
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: add option hls_delete_threshold

[Steven Liu]

> On 12 Apr 2018, at 08:38, Aman Gupta  wrote:
> 
> From: Steven Liu 
> 
> When using hls_list_size with hls_flags delete_segments, currently
> hls_list_size * 2 +- segments remain on disk. With this new option,
> the amount of disk space used can be controlled by the user.
> 
> fix ticket: #7131
> 
> Signed-off-by: Steven Liu 
> Signed-off-by: Aman Gupta 
> ---
> doc/muxers.texi  | 6 ++
> libavformat/hlsenc.c | 9 +
> 2 files changed, 15 insertions(+)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index cb75c261c5..f288764a23 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -513,6 +513,12 @@ Segment will be cut on the next key frame after this 
> time has passed.
> Set the maximum number of playlist entries. If set to 0 the list file
> will contain all the segments. Default value is 5.
> 
> +@item hls_delete_threshold @var{size}
> +Set the number of unreferenced segments to keep on disk before 
> @code{hls_flags delete_segments}
> +deletes them. Increase this to allow continue clients to download segments 
> which
> +were recently referenced in the playlist. Default value is 1, meaning 
> segments older than
> +@code{hls_list_size+1} will be deleted.
> +
> @item hls_ts_options @var{options_list}
> Set output format options using a :-separated list of key=value
> parameters. Values containing @code{:} special characters must be
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 8eb84212a0..1b4f84b653 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -173,6 +173,7 @@ typedef struct HLSContext {
> float time;// Set by a private option.
> float init_time;   // Set by a private option.
> int max_nb_segments;   // Set by a private option.
> +int hls_delete_threshold; // Set by a private option.
> #if FF_API_HLS_WRAP
> int  wrap; // Set by a private option.
> #endif
> @@ -445,6 +446,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
> HLSContext *hls,
> HLSSegment *segment, *previous_segment = NULL;
> float playlist_duration = 0.0f;
> int ret = 0, path_size, sub_path_size;
> +int segment_cnt = 0;
> char *dirname = NULL, *p, *sub_path;
> char *path = NULL;
> AVDictionary *options = NULL;
> @@ -458,14 +460,20 @@ static int hls_delete_old_segments(AVFormatContext *s, 
> HLSContext *hls,
> }
> 
> segment = vs->old_segments;
> +segment_cnt = 0;
> while (segment) {
> playlist_duration -= segment->duration;
> previous_segment = segment;
> segment = previous_segment->next;
> +segment_cnt++;
> if (playlist_duration <= -previous_segment->duration) {
> previous_segment->next = NULL;
> break;
> }
> +if (segment_cnt >= hls->hls_delete_threshold) {
> +previous_segment->next = NULL;
> +break;
> +}
> }
> 
> if (segment && !hls->use_localtime_mkdir) {
> @@ -2799,6 +2807,7 @@ static const AVOption options[] = {
> {"hls_time",  "set segment length in seconds",   
> OFFSET(time),AV_OPT_TYPE_FLOAT,  {.dbl = 2}, 0, FLT_MAX, E},
> {"hls_init_time", "set segment length in seconds at init list",   
> OFFSET(init_time),AV_OPT_TYPE_FLOAT,  {.dbl = 0}, 0, FLT_MAX, E},
> {"hls_list_size", "set maximum number of playlist entries",  
> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, 
> E},
> +{"hls_delete_threshold", "set number of unreferenced segments to keep 
> before deleting",  OFFSET(hls_delete_threshold),AV_OPT_TYPE_INT,{.i64 
> = 1}, 1, INT_MAX, E},
> {"hls_ts_options","set hls mpegts list of options for the container 
> format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = 
> NULL},  0, 0,E},
> {"hls_vtt_options","set hls vtt list of options for the container format 
> used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING, {.str = 
> NULL},  0, 0,E},
> #if FF_API_HLS_WRAP
> -- 
> 2.14.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

will apply

Thanks
Steven





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] doc: update loglevel option documentation

[Tobias Rapp]

On 12.04.2018 02:01, Lou Logan wrote:

On Tue, Apr 10, 2018, at 11:11 PM, Tobias Rapp wrote:


BTW: Is there some documentation on the generic flags syntax used in
FFmpeg for options like "-fflags" or "-cpuflags" and how to combine the
tokens with "+" or "-"? I couldn't find something on a quick scan.


Doesn't appear to be documented, but maybe I missed it.

On Tue, Apr 10, 2018, at 11:31 PM, Tobias Rapp wrote:

Updates documentation after the changes to loglevel flag prefix parsing
in 4b736bc921ed96ad6d312ce0cbe0de29b9e3fe81.

Signed-off-by: Tobias Rapp 
---
  doc/fftools-common-opts.texi | 37 +
  1 file changed, 29 insertions(+), 8 deletions(-)


LGTM, thanks.


Pushed, thanks for the review.

Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel