Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/vpcc: Calculate VP9 level from Luma's Sample rate and Picture size

[Jeyapal, Karthick]

>From: "Ronald S. Bultje" 
>Hi, 
>
>On Mon, Apr 23, 2018 at 2:10 AM, Karthick J  wrote:
>>-    int level = par->level == FF_LEVEL_UNKNOWN ? 0 : par->level;
>>+    int level = par->level == FF_LEVEL_UNKNOWN ?
>+        get_vp9_level(par, frame_rate) : par->level;
>
>
>After this change, how will I create a file without a level?
For best player side behavior, you shouldn't create a file without a level. 
Theoretically level is meant to signal the player, a maximum decoder complexity 
required to play the encoded content. Ideally the player should compare the 
stream's level with its maximum VP9 level supported by the device to decide if 
the device is capable of playing the current VP9 stream. 
If we set this to 0, based on the player implementation it will either take it 
as invalid or will assume the stream has a level lower than the device's 
maximum supported level. 
Hence setting the level more accurately is always better than setting it as 0, 
for best player side experience. Also, as James mentioned 0 is not mentioned in 
the spec as "unknown" or "unspecified".
>
>This patch blurs the line between "unknown", "unspecified", "non-existent" and 
>"autodetect". Linguistically, each of these mean something fundamentally 
>different. I think it's acceptable to not have too many ways of specifying 
>something which in practice comes down to >"nope", but you're removing the 
>"nope" altogether, which isn't quite right either.

>
>Ronald 

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder

[Hendrik Leppkes]

On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme  wrote:
> If we don't do that get_format might not be called for a while and the proper
> SAR not used.
>
> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
> ---
>  libavcodec/h264_slice.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index e6b7998834..319a37f5b6 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const 
> H264SliceContext *sl, int first_sl
>  || (non_j_pixfmt(h->avctx->pix_fmt) != 
> non_j_pixfmt(get_pixel_format(h, 0
>  must_reinit = 1;
>
> -if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
> +if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) {
>  must_reinit = 1;
> +ff_set_sar(h->avctx, sps->sar);
> +}
>
>  if (!h->setup_finished) {
>  h->avctx->profile = ff_h264_get_profile(sps);
> --
> 2.14.2

Why do we even do a get_format call for aspect ratio changes in the
first place? It doesn't change the physical image properties, the
format of image buffers etc remains the same, hwaccel decisions remain
the same.. anyone know why this is?

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder

[Steve Lhomme]

ping ?


Le 19/01/2018 à 13:01, Steve Lhomme a écrit :

If we don't do that get_format might not be called for a while and the proper
SAR not used.

See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
---
  libavcodec/h264_slice.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index e6b7998834..319a37f5b6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const 
H264SliceContext *sl, int first_sl
  || (non_j_pixfmt(h->avctx->pix_fmt) != 
non_j_pixfmt(get_pixel_format(h, 0
  must_reinit = 1;
  
-if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))

+if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) {
  must_reinit = 1;
+ff_set_sar(h->avctx, sps->sar);
+}
  
  if (!h->setup_finished) {

  h->avctx->profile = ff_h264_get_profile(sps);


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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 23.04.2018 21:33, Rostislav Pehlivanov wrote:
> On 23 April 2018 at 20:16, Thomas Volkert  wrote:
>
>> On 23.04.2018 11:27, Thomas Volkert wrote:
>>> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
 2018-04-22 20:00 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-04-22):
>> How do you detect that this is not the "current version" of mbed?
> Is it really our responsibility?
 We try to always do it and I believe that allowing LGPL makes
 more sense and less headache: Since we do the checks so
 rigorously it makes sense to assume we did it as correctly
 for this case.

 I don't understand why we don't go the easy way that clearly
 has advantages instead for the complicated way (with at
 least some disadvantages).
>>> Okay. I looked over their web page and the Debian packages again.
>>> The web page of mbedTLS declares Apache license as the "primary open
>>> source license".
>>>
>>> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
>>> their are no further objections.
>> pushed
>>
>>
>> Sorry, had to revert, I'd still like to know what gains (disk space,
>> performance, maybe security-wise too if possible), this would have over
>> existing TLS libraries. Code-wise it looked fine.
>>
Okay.

Is the idea to have a detailed comparison (measurement values, feature
comparison) between the TLS implementations and then decide if we accept
or drop the patch?
Do you have already defined threshold values for disk space and
performance by which you will decide if it is worth to integrate mbedTLS
in FFmpeg?

Best regards,
Thomas.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 23.04.2018 21:02, James Almer wrote:
> On 4/23/2018 6:27 AM, Thomas Volkert wrote:
>> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
>>> 2018-04-22 20:00 GMT+02:00, Nicolas George :
 Carl Eugen Hoyos (2018-04-22):
> How do you detect that this is not the "current version" of mbed?
 Is it really our responsibility?
>>> We try to always do it and I believe that allowing LGPL makes
>>> more sense and less headache: Since we do the checks so
>>> rigorously it makes sense to assume we did it as correctly
>>> for this case.
>>>
>>> I don't understand why we don't go the easy way that clearly
>>> has advantages instead for the complicated way (with at
>>> least some disadvantages).
>> Okay. I looked over their web page and the Debian packages again.
>> The web page of mbedTLS declares Apache license as the "primary open
>> source license".
>>
>> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
>> their are no further objections.
> Not only there was an objection/request by Rostislav Pehlivanov you
> ignored, 
I haven't ignored him, I answered him.
My mails were delayed by some minutes.

> you also pushed this after ONE day in the ml, 

I posted the patch 3 times on the mailing list, it was for 2 days on the
list.

> with absolutely
> no review. 
There were already answers which contained reasonable feedback (in my
opinion).
Please, make a a review in the way you like and send it to the list.

> What exactly was the hurry?
>
> Please, revert this. Forcing your way through is not how code should be
> committed.
That was not the intention.
Let's focus on the content.

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

[FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: use memcpy when assembling fragments

[James Almer]

before:
419022 decicycles in assemble_fragment,2047 runs,  1 skips

after:
104621 decicycles in assemble_fragment,2045 runs,  3 skips

Benched with a 2 minutes long 720x480 DVD mpeg2 sample.

Signed-off-by: James Almer 
---
 libavcodec/cbs_mpeg2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index bfb64a0851..94b9591b21 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -362,7 +362,7 @@ static int 
cbs_mpeg2_assemble_fragment(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag)
 {
 uint8_t *data;
-size_t size, dp, sp;
+size_t size, dp;
 int i;
 
 size = 0;
@@ -382,8 +382,8 @@ static int 
cbs_mpeg2_assemble_fragment(CodedBitstreamContext *ctx,
 data[dp++] = 0;
 data[dp++] = 1;
 
-for (sp = 0; sp < unit->data_size; sp++)
-data[dp++] = unit->data[sp];
+memcpy(data + dp, unit->data, unit->data_size);
+dp += unit->data_size;
 }
 
 av_assert0(dp == size);
-- 
2.17.0

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

[FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: use existing buffer reference if available when splitting fragments

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/cbs_mpeg2.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index bfb64a0851..086d08ed64 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -146,14 +146,17 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext 
*ctx,
 unit_size = (end - 4) - (start - 1);
 }
 
-unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!unit_data)
-return AVERROR(ENOMEM);
-memcpy(unit_data, start - 1, unit_size);
-memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+if (header) {
+unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!unit_data)
+return AVERROR(ENOMEM);
+memcpy(unit_data, start - 1, unit_size);
+memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+} else
+unit_data = (uint8_t *)start - 1;
 
 err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type,
-  unit_data, unit_size, NULL);
+  unit_data, unit_size, frag->data_ref);
 if (err < 0) {
 av_freep(&unit_data);
 return err;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH 23/26] lavc/cbs: Add JPEG support

[James Almer]

On 4/22/2018 12:29 PM, Mark Thompson wrote:
> +static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
> +   CodedBitstreamFragment *frag,
> +   int header)
> +{
> +uint8_t *unit_data;
> +size_t unit_size;
> +int unit, start, end, marker, next_start, next_marker;
> +int err, i, j;
> +
> +if (frag->data_size < 4) {
> +// Definitely too short to be meaningful.
> +return AVERROR_INVALIDDATA;
> +}
> +
> +for (i = 0; i + 1 < frag->data_size && frag->data[i] != 0xff; i++);
> +if (i > 0) {
> +av_log(ctx->log_ctx, AV_LOG_WARNING, "Discarding %d bytes at "
> +   "beginning of image.\n", i);
> +}
> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size && frag->data[i]) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "no SOI marker found.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +marker = frag->data[i];
> +if (marker != JPEG_MARKER_SOI) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: first "
> +   "marker is %02x, should be SOI.\n", marker);
> +return AVERROR_INVALIDDATA;
> +}
> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "no image content found.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +marker = frag->data[i];
> +start  = i + 1;
> +
> +for (unit = 0;; unit++) {
> +if (marker == JPEG_MARKER_EOI) {
> +break;
> +} else if (marker == JPEG_MARKER_SOS) {
> +for (i = start; i + 1 < frag->data_size; i++) {
> +if (frag->data[i] != 0xff)
> +continue;
> +end = i;
> +for (++i; i + 1 < frag->data_size &&
> +  frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +next_marker = -1;
> +} else {
> +if (frag->data[i] == 0x00)
> +continue;
> +next_marker = frag->data[i];
> +next_start  = i + 1;
> +}
> +break;
> +}
> +} else {
> +int length;
> +i = start;
> +if (i + 2 > frag->data_size)
> +break;
> +length = frag->data[i] << 8 | frag->data[i + 1];
> +av_log(ctx->log_ctx, AV_LOG_DEBUG, "Length = %d (i = %d)\n", 
> length, i);
> +if (i + length > frag->data_size)
> +break;
> +end = start + length;
> +
> +i = end;
> +if (frag->data[i] != 0xff) {
> +next_marker = -1;
> +} else {
> +for (++i; i + 1 < frag->data_size &&
> +  frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +next_marker = -1;
> +} else {
> +next_marker = frag->data[i];
> +next_start  = i + 1;
> +}
> +}
> +}
> +
> +av_log(ctx->log_ctx, AV_LOG_DEBUG, "start = %d, end = %d, marker = 
> %02x\n",
> +   start, end, marker);
> +
> +unit_size = end - start;
> +unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!unit_data)
> +return AVERROR(ENOMEM);
> +if (marker == JPEG_MARKER_SOS) {
> +for (i = start, j = 0; i < end; i++, j++) {
> +if (frag->data[i] == 0xff) {
> +while (frag->data[i] == 0xff)
> +++i;
> +unit_data[j] = 0xff;
> +} else {
> +unit_data[j] = frag->data[i];
> +}
> +}
> +unit_size = j;
> +} else {
> +memcpy(unit_data, frag->data + start, unit_size);

Create a new frag->data_ref reference instead in this case. There's no
need to allocate a new buffer for these units.

> +}
> +memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +err = ff_cbs_insert_unit_data(ctx, frag, unit, marker,
> +  unit_data, unit_size, NULL);
> +if (err < 0) {
> +av_free(&unit_data);
> +return err;
> +}
> +
> +if (next_marker == -1)
> +break;
> +marker = next_marker;
> +start  = next_start;
> +}
> +
> +return 0;
> +}

[...]

> +static int cbs_jpeg_assemble_fragment(CodedBitstreamContext *ctx,
> +   CodedBitstreamFragment *frag)
> +{
> +const CodedBitstreamUnit *unit;
> +uint8_t *data;

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Michael Niedermayer]

On Mon, Apr 23, 2018 at 11:15:17PM +0200, Paul B Mahol wrote:
> On 4/23/18, Nicolas George  wrote:
> > Paul B Mahol (2018-04-23):
> >> It is big threat.
> >
> > Will you please give arguments instead of repeating the same things
> > endlessly?
> >
> > I think I intuitively agree with your position, but as it is, you
> > objection is worthless, and Thilo would be entitled to just ignore it.
> 

> Why would we link to binary blobs that deny REing?

how could that work ?
LGPL says this:
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

[...]

-- 
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 2/4] avfilter/avfiltergraph: fix has_alpha in pick_format

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 02:10:53AM +0200, Michael Niedermayer wrote:
> On Mon, Apr 23, 2018 at 04:50:54AM +0200, Marton Balint wrote:
> > 
> > 
> > On Mon, 23 Apr 2018, Michael Niedermayer wrote:
> > 
> > >On Sun, Apr 22, 2018 at 01:44:19PM +0200, Marton Balint wrote:
> > >>
> > >>
> > >>On Fri, 20 Apr 2018, Michael Niedermayer wrote:
> > >>
> > >>>On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> > A pixel format which has a palette also has alpha, without this patch 
> > the
> > format negotiation might have preferred formats without alpha even if 
> > the
> > source had alpha.
> > 
> > Signed-off-by: Marton Balint 
> > ---
> > libavfilter/avfiltergraph.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> > index 4cc6892404..e18f733e23 100644
> > --- a/libavfilter/avfiltergraph.c
> > +++ b/libavfilter/avfiltergraph.c
> > @@ -679,7 +679,7 @@ static int pick_format(AVFilterLink *link, 
> > AVFilterLink *ref)
> > 
> > if (link->type == AVMEDIA_TYPE_VIDEO) {
> > if(ref && ref->type == AVMEDIA_TYPE_VIDEO){
> > -int has_alpha= 
> > av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0;
> > +int has_alpha= 
> > av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0 || 
> > (av_pix_fmt_desc_get(ref->format)->flags & AV_PIX_FMT_FLAG_PAL);
> > >>>
> > >>>This causes various output files to grow in size with a unused alpha 
> > >>>plane
> > >>>
> > >>>a random example: (there are likels better examples)
> > >>>./ffmpeg -y -i ~/tickets/1116/1023.bmp -vf negate fileX.bmp
> > >>>
> > >>>Iam not sure unconditionally treating all palettes as if they have
> > >>>non fully opaque entries is a good idea.
> > >>
> > >>Obviously not, but it is already treated this way in most places. Having a
> > >>bigger image with alpha is better than losing alpha. And the user can 
> > >>always
> > >>force losing alpha with a filter, and sometimes he has to do that anyway
> > >>because for example fre0r filters have no way of signalling if they use
> > >>alpha or not...
> > >
> > >you can, the average user certainly doesnt have the knowledge to adjust
> > >anything alpha by hand, the average user isnt even aware of that the issue
> > >is alpha or pal8 related probably
> > >
> > >also about "better", i saw a few cases that got bigger, i dont remember
> > >seeing a case that was fixed.
> > >Have you seen real usecases this fixes ?
> > 
> > A source file with a palette and alpha and a filter which supports formats
> > with both alpha and without:
> > 
> > https://dab1nmslvvntp.cloudfront.net/images/blogs/design/8bit-trans.png
> > 
> > ffmpeg -i 8bit-trans.png -vf negate out.bmp
> 
> i assume fate doesnt cover this yet, so a new fate test probably makes sense

i still think it would be more ideal if this is fully fixed 
(by alpha / non alpha pal8) or other.

Because as is we have a set of bugs, and with this patchset we fix some while
introducing other (maybe less important though) bugs.
Then later behavior changes again when this is all fixed.
A smaller number of behavior changes should be better and less confusing to
users.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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/4] avfilter/avfiltergraph: fix has_alpha in pick_format

[Michael Niedermayer]

On Mon, Apr 23, 2018 at 04:50:54AM +0200, Marton Balint wrote:
> 
> 
> On Mon, 23 Apr 2018, Michael Niedermayer wrote:
> 
> >On Sun, Apr 22, 2018 at 01:44:19PM +0200, Marton Balint wrote:
> >>
> >>
> >>On Fri, 20 Apr 2018, Michael Niedermayer wrote:
> >>
> >>>On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> A pixel format which has a palette also has alpha, without this patch the
> format negotiation might have preferred formats without alpha even if the
> source had alpha.
> 
> Signed-off-by: Marton Balint 
> ---
> libavfilter/avfiltergraph.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index 4cc6892404..e18f733e23 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -679,7 +679,7 @@ static int pick_format(AVFilterLink *link, 
> AVFilterLink *ref)
> 
> if (link->type == AVMEDIA_TYPE_VIDEO) {
> if(ref && ref->type == AVMEDIA_TYPE_VIDEO){
> -int has_alpha= 
> av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0;
> +int has_alpha= 
> av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0 || 
> (av_pix_fmt_desc_get(ref->format)->flags & AV_PIX_FMT_FLAG_PAL);
> >>>
> >>>This causes various output files to grow in size with a unused alpha plane
> >>>
> >>>a random example: (there are likels better examples)
> >>>./ffmpeg -y -i ~/tickets/1116/1023.bmp -vf negate fileX.bmp
> >>>
> >>>Iam not sure unconditionally treating all palettes as if they have
> >>>non fully opaque entries is a good idea.
> >>
> >>Obviously not, but it is already treated this way in most places. Having a
> >>bigger image with alpha is better than losing alpha. And the user can always
> >>force losing alpha with a filter, and sometimes he has to do that anyway
> >>because for example fre0r filters have no way of signalling if they use
> >>alpha or not...
> >
> >you can, the average user certainly doesnt have the knowledge to adjust
> >anything alpha by hand, the average user isnt even aware of that the issue
> >is alpha or pal8 related probably
> >
> >also about "better", i saw a few cases that got bigger, i dont remember
> >seeing a case that was fixed.
> >Have you seen real usecases this fixes ?
> 
> A source file with a palette and alpha and a filter which supports formats
> with both alpha and without:
> 
> https://dab1nmslvvntp.cloudfront.net/images/blogs/design/8bit-trans.png
> 
> ffmpeg -i 8bit-trans.png -vf negate out.bmp

i assume fate doesnt cover this yet, so a new fate test probably makes sense

thx

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Jan Ekström]

On Tue, Apr 24, 2018 at 1:47 AM, Marton Balint  wrote:
>
> That's fine, I even understand and relate to that. However, as a user, I
> utterly don't care about it, as a I user I want to use the best tool
> available today, let it be free or not, open source or not. If you are
> making it harder for me because of your _idealism_, well... please don't.
>

Hi,

Coming back from the side that tries to help users get what they can
from FFmpeg, it's funny how I've already seen cases where people try
to build feature XYZ in a new version of FFmpeg just to find
themselves in a position where it is not possible because the
back-bone of what they're trying to do is basing on a proprietary
library, which is - in this specific case - not available for the
architecture which the user wanted to utilize. It can be really hard
to explain to a user that no, he cannot have this feature. That there
is no technical reason why it wouldn't be possible, but just the fact
that it is dependent on a vendor. The end result being "Well, go ask
$VENDOR if they are nice enough to give you an $ARCH SDK". And it
might not always be the architecture, it could be parameters or
capabilities or anything in between that the user might want from this
new feature, which is not available from the closed source SDK.

So while users might not care on some level, they often end up caring
why we have something as a feature if they cannot utilize it or
utilize it in the way that they wish to.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Hendrik Leppkes]

On Tue, Apr 24, 2018 at 12:47 AM, Marton Balint  wrote:
>
>
> On Mon, 23 Apr 2018, Ronald S. Bultje wrote:
>
>> Hi Thilo,
>>
>> On Mon, Apr 23, 2018 at 4:45 PM, Thilo Borgmann 
>> wrote:
>>
>>> From the users perspective I don't see why we don't have wrappers for a
>>> commercial codec.
>>
>>
>>
>> Right, that's the core thing.
>>
>> Why doesn't FFmpeg "promote" the use of this closed-source software?
>>
>> Maybe it's because some of us contribute to this project not just out of
>> utility ("I can do XYZ with it"), but out of some sort of idealism ("I
>> like
>> opensource"), trying to promote the common good of free software, kind of
>> like volunteering in some local community thing.
>
>
> That's fine, I even understand and relate to that. However, as a user, I
> utterly don't care about it, as a I user I want to use the best tool
> available today, let it be free or not, open source or not. If you are
> making it harder for me because of your _idealism_, well... please don't.

You could turn that argument easily around at Realnetworks - if the
user experience is the most important, why do we have to bend over and
take it, instead of asking Realnetworks to actually make an
open-source codec?
That would not only eliminate this discussion, but actually allow
shipping of their codec with ffmpeg onto millions of PCs - instant
support for their codec!

You can always make up some argument that somehow the users benefit
from whatever one is trying to push through, but that doesn't mean its
the right thing to do.

>
>>
>> For these contributors, "promoting" closed-source software would run
>> directly contra to this ideal.
>
>
> This is hardly a technical argument.

Does it have to be? This is pretty polarizing topic in open-source
projects in general, and alienating those people does in no way
benefit the project. So we get one wrapper for some codec that may or
may not ever even be successfull, but some contributors may lose some
of their motivation to work? Not a good deal.

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

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1enc: Check that the crc + version combination is supported

[Michael Niedermayer]

On Sat, Apr 21, 2018 at 10:19:31PM +0200, Michael Niedermayer wrote:
> The crc flag is only stored since version 3 thus before this crcs do not
> work. We increase the version as needed same as we do with pix_fmts
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1enc.c | 4 
>  1 file changed, 4 insertions(+)

will apply

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH 10/26] vaapi_encode: Choose profiles dynamically

[Mark Thompson]

On 23/04/18 03:54, Michael Niedermayer wrote:
> On Sun, Apr 22, 2018 at 04:29:05PM +0100, Mark Thompson wrote:
>> Previously there was one fixed choice for each codec (e.g. H.265 -> Main
>> profile), and using anything else then required an explicit option from
>> the user.  This changes to selecting the profile based on the input format
>> and the set of profiles actually supported by the driver (e.g. P010 input
>> will choose Main 10 profile for H.265 if the driver supports it).
>>
>> The entrypoint and render target format are also chosen dynamically in the
>> same way, removing those explicit selections from the per-codec code.
>> ---
>>  doc/encoders.texi   |   3 +
>>  libavcodec/vaapi_encode.c   | 261 
>> +++-
>>  libavcodec/vaapi_encode.h   |  41 +--
>>  libavcodec/vaapi_encode_h264.c  |  45 ++-
>>  libavcodec/vaapi_encode_h265.c  |  43 +++
>>  libavcodec/vaapi_encode_mjpeg.c |  13 +-
>>  libavcodec/vaapi_encode_mpeg2.c |  36 ++
>>  libavcodec/vaapi_encode_vp8.c   |  11 +-
>>  libavcodec/vaapi_encode_vp9.c   |  34 ++
>>  9 files changed, 306 insertions(+), 181 deletions(-)
> 
> breaks build on linux x86-64 ubuntu
> 
> CClibavcodec/vaapi_encode.o
> libavcodec/vaapi_encode.c:1007:5: error: ‘VAEntrypointEncSliceLP’ undeclared 
> here (not in a function)
>  VAEntrypointEncSliceLP,
>  ^
> libavcodec/vaapi_encode.c:1011:5: error: initializer element is not constant
>  VAEntrypointEncSliceLP,
>  ^
> libavcodec/vaapi_encode.c:1011:5: error: (near initialization for 
> ‘vaapi_encode_entrypoints_low_power[0]’)
> make: *** [libavcodec/vaapi_encode.o] Error 1
> 
> 
> [...]

Right, that lost some of preprocessor checks around EncSliceLP in the 
refactoring.

Fixed locally (don't include it in the normal list and don't include the 
low-power list at all in that case).  I'll try to test again with more old 
versions to make sure there aren't any similar build failures lurking.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/2] vaapi_encode_h265: Insert mastering display colour colume if needed

[Mark Thompson]

On 23/04/18 08:08, Xiang, Haihao wrote:>> On 20/04/18 08:27, Haihao Xiang wrote:
>>> '-sei xxx' is added to control SEI insertion, so far only mastering
>>> display colour colume is available for testing. Another patch is
>>> required to change mastering display settings later.
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/vaapi_encode_h265.c | 94
>>> +-
>>>  1 file changed, 93 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>>> index 5203c6871d..a8cb6a6d8b 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -29,10 +29,14 @@
>>>  #include "cbs.h"
>>>  #include "cbs_h265.h"
>>>  #include "hevc.h"
>>> +#include "hevc_sei.h"
>>>  #include "internal.h"
>>>  #include "put_bits.h"
>>>  #include "vaapi_encode.h"
>>>  
>>> +enum {
>>> +SEI_MASTERING_DISPLAY   = 0x01,
>>
>> Since the options are essentially the same I think it would be nice if these
>> values matched the H.264 ones?  (That is, make this value 8.)
>>
> 
> My original thought was to make this value 8, but I am not sure whether 
> another 
> SEI_XXX will be added for H.264 in the future. Will we use 8 for a new 
> SEI_XXX 
> for H.264? 

I think that's fine - if we do add anything new for H.264 then it can have 
another value.

It would also be possible to add support for the HDR metadata to the H.264 
code, though it's probably not of much use here when hardware isn't going to 
support >8-bit video.

>> Should this be mastering display specifically, or would it be better for this
>> option to be called something like "HDR metadata" (just "hdr" as the option
>> name?) which also includes content light level?  (Compare the -sei timing
>> option on H.264, which gives you both buffering period and picture timing
>> SEI.)
>>
> 
> Good idea, I prefer using hdr for mastering display and content light level.
> Actually adding support for content light level is in my todo list. 

Ok, nice :)

>>> +};
>>>  
>>>  typedef struct VAAPIEncodeH265Context {
>>>  unsigned int ctu_width;
>>> @@ -47,6 +51,9 @@ typedef struct VAAPIEncodeH265Context {
>>>  H265RawSPS sps;
>>>  H265RawPPS pps;
>>>  H265RawSlice slice;
>>> +H265RawSEI sei;
>>> +
>>> +H265RawSEIMasteringDiplayColorVolume mastering_display;
>>>  
>>>  int64_t last_idr_frame;
>>>  int pic_order_cnt;
>>> @@ -58,6 +65,7 @@ typedef struct VAAPIEncodeH265Context {
>>>  CodedBitstreamContext *cbc;
>>>  CodedBitstreamFragment current_access_unit;
>>>  int aud_needed;
>>> +int sei_needed;
>>>  } VAAPIEncodeH265Context;
>>>  
>>>  typedef struct VAAPIEncodeH265Options {
>>> @@ -65,6 +73,7 @@ typedef struct VAAPIEncodeH265Options {
>>>  int aud;
>>>  int profile;
>>>  int level;
>>> +int sei;
>>>  } VAAPIEncodeH265Options;
>>>  
>>>  
>>> @@ -175,6 +184,61 @@ fail:
>>>  return err;
>>>  }
>>>  
>>> +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
>>> +VAAPIEncodePicture *pic,
>>> +int index, int *type,
>>> +char *data, size_t
>>> *data_len)
>>> +{
>>> +VAAPIEncodeContext  *ctx = avctx->priv_data;
>>> +VAAPIEncodeH265Context *priv = ctx->priv_data;
>>> +VAAPIEncodeH265Options  *opt = ctx->codec_options;
>>> +CodedBitstreamFragment   *au = &priv->current_access_unit;
>>> +int err, i;
>>> +
>>> +if (priv->sei_needed) {
>>> +if (priv->aud_needed) {
>>> +err = vaapi_encode_h265_add_nal(avctx, au, &priv->aud);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->aud_needed = 0;
>>> +}
>>> +
>>> +memset(&priv->sei, 0, sizeof(priv->sei));
>>> +priv->sei.nal_unit_header.nal_unit_type = HEVC_NAL_SEI_PREFIX;
>>> +priv->sei.nal_unit_header.nuh_temporal_id_plus1 = 1;
>>
>> Might look nicer as a compound literal?
> 
> Agree, I will update the patch.
> 
>>
>>> +i = 0;
>>> +
>>> +if (opt->sei & SEI_MASTERING_DISPLAY && pic->type ==
>>> PICTURE_TYPE_IDR) {
>>> +priv->sei.payload[i].payload_type =
>>> HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
>>> +priv->sei.payload[i].payload.mastering_display = priv-
 mastering_display;
>>> +++i;
>>> +}
>>> +
>>> +priv->sei.payload_count = i;
>>> +av_assert0(priv->sei.payload_count > 0);
>>> +
>>> +err = vaapi_encode_h265_add_nal(avctx, au, &priv->sei);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->sei_needed = 0;
>>> +
>>> +err = vaapi_encode_h265_write_access_unit(avctx, data, data_len,
>>> au);
>>> +if (err < 0)
>>> +goto fail;
>>> +
>>> +ff_cbs_fragment_uninit(priv->cbc, au);
>>> +
>>> +*type = VAEncPackedHeaderRawData;
>>> +re

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Marton Balint]

On Mon, 23 Apr 2018, Ronald S. Bultje wrote:


Hi Thilo,

On Mon, Apr 23, 2018 at 4:45 PM, Thilo Borgmann 
wrote:


From the users perspective I don't see why we don't have wrappers for a
commercial codec.



Right, that's the core thing.

Why doesn't FFmpeg "promote" the use of this closed-source software?

Maybe it's because some of us contribute to this project not just out of
utility ("I can do XYZ with it"), but out of some sort of idealism ("I like
opensource"), trying to promote the common good of free software, kind of
like volunteering in some local community thing.


That's fine, I even understand and relate to that. However, as a user, I 
utterly don't care about it, as a I user I want to use the best tool 
available today, let it be free or not, open source or not. If you are 
making it harder for me because of your _idealism_, well... please don't.




For these contributors, "promoting" closed-source software would run
directly contra to this ideal.


This is hardly a technical argument.


As an analogy, imagine that the Linux kernel started including wrappers to
promote the use of custom binary graphics device drivers. That would run
directly contra to the ideals that the project stands for. You personally
may not care so much, I understand that much, but please do see that some
other contributors might care far more.


You can build a module without rebuilding the whole kernel, ffmpeg is not 
that flexible...


Obviously a separate repo for non-free is an option, but do we really need 
a separate repo for closed source components because some people don't 
like closed source out of idealism? I really feel that the religous 
arguments dominate this discussion.


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

Re: [FFmpeg-devel] [PATCH 1/2] cbs_h265: read/write HEVC PREFIX SEI

[Mark Thompson]

On 23/04/18 06:55, Xiang, Haihao wrote:
> 
>> On 20/04/18 08:27, Haihao Xiang wrote:
>>> Similar to cbs_h264, cbs_h265_{read, write}_nal_unit() can handle HEVC
>>> prefix SEI NAL units now. Currently mastering display colour volume SEI
>>> message is added only, we may add more SEI message if needed later
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/cbs_h2645.c|  43 ++
>>>  libavcodec/cbs_h265.h |  38 +
>>>  libavcodec/cbs_h265_syntax_template.c | 150
>>> ++
>>>  3 files changed, 231 insertions(+)
>>>
>>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>>> index 5585831cf6..6fc5832966 100644
>>> --- a/libavcodec/cbs_h2645.c
>>> +++ b/libavcodec/cbs_h2645.c
>>> @@ -29,6 +29,7 @@
>>>  #include "h264_sei.h"
>>>  #include "h2645_parse.h"
>>>  #include "hevc.h"
>>> +#include "hevc_sei.h"
>>>  
>>>  
>>>  static int cbs_read_ue_golomb(CodedBitstreamContext *ctx, GetBitContext
>>> *gbc,
>>> @@ -465,6 +466,26 @@ static void cbs_h265_free_slice(void *unit, uint8_t
>>> *content)
>>>  av_freep(&content);
>>>  }
>>>  
>>> +static void cbs_h265_free_sei_payload(H265RawSEIPayload *payload)
>>> +{
>>> +switch (payload->payload_type) {
>>> +case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
>>> +break;
>>> +default:
>>> +av_buffer_unref(&payload->payload.other.data_ref);
>>> +break;
>>> +}
>>> +}
>>> +
>>> +static void cbs_h265_free_sei(void *unit, uint8_t *content)
>>> +{
>>> +H265RawSEI *sei = (H265RawSEI*)content;
>>> +int i;
>>> +for (i = 0; i < sei->payload_count; i++)
>>> +cbs_h265_free_sei_payload(&sei->payload[i]);
>>> +av_freep(&content);
>>> +}
>>> +
>>>  static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>> CodedBitstreamFragment *frag,
>>> const H2645Packet *packet)
>>> @@ -972,6 +993,20 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext
>>> *ctx,
>>>  }
>>>  break;
>>>  
>>> +case HEVC_NAL_SEI_PREFIX:
>>
>> I don't think it would be too hard to handling SEI_SUFFIX here too?  (The
>> different set of valid payloads doesn't matter when we aren't checking that
>> below.)
>>
> 
> I also don't think so. But it seems most pre-defined SEI types in hevc_sei.h 
> are
> SEI_PREFIX, hence my thought is we may add support for SEI_SUFFIX in the 
> future
> if SEI_SUFFIX is really needed.

Might be nice for trace_headers output?  But yes, it's probably easier not too 
for now; so, sure, stay with what you wrote initially.

>>> +err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H265RawSEI),
>>> +&cbs_h265_free_sei);
>>> +
>>> +if (err < 0)
>>> +return err;
>>> +
>>> +err = cbs_h265_read_sei(ctx, &gbc, unit->content);
>>> +
>>> +if (err < 0)
>>> +return err;
>>> +
>>> +break;
>>> +
>>>  default:
>>>  return AVERROR(ENOSYS);
>>>  }
>>> @@ -1212,6 +1247,14 @@ static int
>>> cbs_h265_write_nal_unit(CodedBitstreamContext *ctx,
>>>  }
>>>  break;
>>>  
>>> +case HEVC_NAL_SEI_PREFIX:
>>> +err = cbs_h265_write_sei(ctx, pbc, unit->content);
>>> +
>>> +if (err < 0)
>>> +return err;
>>> +
>>> +break;
>>> +
>>
>> Please make these cases match the styling of the others.
>>
> 
> My original patch used the same coding style of the others, but patcheck in
> FFmpeg reported a warning below:
> 
> { should be on the same line as the related previous statement
> 0001-vaapi_encode_h265-Insert-SEI-if-needed.patch:24:+{
> 
> I will update it if you prefer the same coding style. 

I think it's more important to match what's already there.  (Also I don't agree 
with that test, isolated blocks are useful...)

>>>  default:
>>>  av_log(ctx->log_ctx, AV_LOG_ERROR, "Write unimplemented for "
>>> "NAL unit type %"PRIu32".\n", unit->type);
>>> diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
>>> index 33e71fc234..e37c1b8d94 100644
>>> --- a/libavcodec/cbs_h265.h
>>> +++ b/libavcodec/cbs_h265.h
>>> @@ -25,6 +25,14 @@
>>>  #include "cbs_h2645.h"
>>>  #include "hevc.h"
>>>  
>>> +enum {
>>> +// This limit is arbitrary - it is sufficient for one message of each
>>> +// type plus some repeats, and will therefore easily cover all sane
>>> +// streams.  However, it is possible to make technically-valid streams
>>> +// for which it will fail (for example, by including a large number of
>>> +// user-data-unregistered messages).
>>> +H265_MAX_SEI_PAYLOADS = 64,
>>> +};
>>>  
>>>  typedef struct H265RawNALUnitHeader {
>>>  uint8_t forbidden_zero_bit;
>>> @@ -516,6 +524,36 @@ typedef struct H265RawSlice {
>>>  AVBufferRef *data_ref;
>>>  } H265RawSlice;
>>>  
>>> +typedef struct H265RawSEIMasteringDiplayColorVolume {
>>
>> The H

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based on framesync

[Mark Thompson]

On 23/04/18 08:22, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Sunday, April 22, 2018 3:21 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based
>> on framesync
>>
>> On 03/04/18 02:50, Ruiling Song wrote:
>>> The existing version which was cherry-picked from Libav does not work
>>> with FFmpeg framework, because ff_request_frame() was totally
>>> different between Libav (recursive) and FFmpeg (non-recursive).
>>> The existing overlay_qsv implementation depends on the recursive version
>>> of ff_request_frame to trigger immediate call to request_frame() on input 
>>> pad.
>>> But this has been removed in FFmpeg since "lavfi: make request_frame() non-
>> recursive."
>>> Now that we have handy framesync support in FFmpeg, so I make it work
>>> based on framesync. Some other fixing which is also needed to make
>>> overlay_qsv work are put in a separate patch.
>>>
>>> v2:
>>> add .preinit field to initilize framesync options.
>>> export more options like vf_overlay.c
>>>
>>> Signed-off-by: Ruiling Song 
>>> ---
>>>  libavfilter/Makefile |   2 +-
>>>  libavfilter/vf_overlay_qsv.c | 213 
>>> ---
>>>  2 files changed, 78 insertions(+), 137 deletions(-)
>>>
>> On 03/04/18 02:50, Ruiling Song wrote:
>>> For filters based on framesync, the input frame was managed
>>> by framesync, so we should not directly keep and destroy it,
>>> instead we make a clone of it here, or else double-free will occur.
>>> But for other filters not based on framesync, we still need to
>>> free the input frame inside filter_frame. That's why I made
>>> this v2 to fix the side-effect on normal filters.
>>>
>>> v2:
>>> and one av_frame_free() in vf_vpp_qsv.c
>>>
>>> Signed-off-by: Ruiling Song 
>>> ---
>>>  libavfilter/qsvvpp.c | 4 ++--
>>>  libavfilter/vf_vpp_qsv.c | 5 -
>>>  2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> Tested, LGTM, set applied with one minor merge fixup - it collided with the
>> change to pass through unmodified frames directly.  (Apologies for the 
>> delay!)
>>
>> Shall I apply this to the 4.0 branch as well?
> 
> Sure, I think it's better to merge to 4.0. I noticed this feature was 
> included in the release note. 

Ok, I've cherry-picked it to the 4.0 branch as well.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] avcodec/vaapi: do not parse MVMODE for VC-1 interlaced frame pictures

[Mark Thompson]

On 23/04/18 19:58, Jerome Borsboom wrote:
> On 29-3-2018 13:43, Jerome Borsboom wrote:
>> Interlaced frame pictures do not contain the MVMODE or MVMODE2 bitstream
>> element. Trying to parse this element and passing a nonzero value to the
>> hardware decoder results in small inaccuracies in the decoded picture.
>>
>> Signed-off-by: Jerome Borsboom 
>> ---
>> With this patch the Intel hardware decoded fate test for ilaced_twomv.vc1
>> perfectly matches the output from the Microsoft software decoder.
>>
>>  libavcodec/vaapi_vc1.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
>> index 74ba783141..bdb5e24cc5 100644
>> --- a/libavcodec/vaapi_vc1.c
>> +++ b/libavcodec/vaapi_vc1.c
>> @@ -138,8 +138,9 @@ static int vc1_get_FPTYPE(const VC1Context *v)
>>  /** Reconstruct bitstream MVMODE (7.1.1.32) */
>>  static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context *v)
>>  {
>> -if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
>> -(v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type))
>> +if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
>> +((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
>> + (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type)))
>>  return get_VAMvModeVC1(v->mv_mode);
>>  return 0;
>>  }
>> @@ -147,7 +148,8 @@ static inline VAMvModeVC1 vc1_get_MVMODE(const 
>> VC1Context *v)
>>  /** Reconstruct bitstream MVMODE2 (7.1.1.33) */
>>  static inline VAMvModeVC1 vc1_get_MVMODE2(const VC1Context *v)
>>  {
>> -if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
>> +if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
>> +(v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
>>  v->mv_mode == MV_PMODE_INTENSITY_COMP)
>>  return get_VAMvModeVC1(v->mv_mode2);
>>  return 0;
>> -- 
>> 2.13.6
> 
> Could someone please have a look at this patch?

Tested, looks good and matches the reference output for me as well, applied.

Thanks!

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

Re: [FFmpeg-devel] [PATCH 2/5] reitnerlace - tinterlace-like filter under LGPL

[Paul B Mahol]

On 4/23/18, Vasile Toncu  wrote:
> Hello,
>
> Here is patches 2. Please review.
>
> Thank you,
> Vasile Toncu
>

Please fix those two patches.

They must have proper short description.

Looks like it is missing pix formats in query_formats, and thus cannot
be compiled as is.
___
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

[Paul B Mahol]

On 4/23/18, Vasile Toncu  wrote:
>> This patch is still corrupted by your mailer, by introducing line
>> breaks. Please attach it as a file, or use "git send-email"
>>
>> Moritz
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> Hello,
>
> I have attached the patch. It's strange, my mailer shows the message
> with no line breaks, but on the list it appears like that. I hope this
> solves the problem.
>
> Kind regards,
> Vasile
>

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

Re: [FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

[Mark Wachsler]

Ping.

On Fri, Apr 20, 2018 at 4:21 PM, Mark Wachsler  wrote:

> The -benchmark and -benchmark_all options now show user, system, and real
> time,
> instead of just user time.
> ---
>  fftools/ffmpeg.c | 50 ++--
>  1 file changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 4dbe72186d..d37171d567 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
>  NULL
>  };
>
> +typedef struct TimeStamps {
> +  int64_t real_usec;
> +  int64_t user_usec;
> +  int64_t sys_usec;
> +} TimeStamps;
> +
>  static void do_video_stats(OutputStream *ost, int frame_size);
> -static int64_t getutime(void);
> +static TimeStamps get_time_stamps(void);
>  static int64_t getmaxrss(void);
>  static int ifilter_has_all_input_formats(FilterGraph *fg);
>
> @@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
>
>  static int want_sdp = 1;
>
> -static int current_time;
> +static TimeStamps current_time;
>  AVIOContext *progress_avio = NULL;
>
>  static uint8_t *subtitle_out;
> @@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int
> encoder)
>  static void update_benchmark(const char *fmt, ...)
>  {
>  if (do_benchmark_all) {
> -int64_t t = getutime();
> +TimeStamps t = get_time_stamps();
>  va_list va;
>  char buf[1024];
>
> @@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
>  va_start(va, fmt);
>  vsnprintf(buf, sizeof(buf), fmt, va);
>  va_end(va);
> -av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t -
> current_time, buf);
> +av_log(NULL, AV_LOG_INFO,
> +   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64
> " real %s \n",
> +   t.user_usec - current_time.user_usec,
> +   t.sys_usec - current_time.sys_usec,
> +   t.real_usec - current_time.real_usec, buf);
>  }
>  current_time = t;
>  }
> @@ -4715,23 +4725,30 @@ static int transcode(void)
>  return ret;
>  }
>
> -
> -static int64_t getutime(void)
> -{
> +static TimeStamps get_time_stamps(void) {
> +  TimeStamps time_stamps;
> +  time_stamps.real_usec = av_gettime_relative();
>  #if HAVE_GETRUSAGE
>  struct rusage rusage;
>
>  getrusage(RUSAGE_SELF, &rusage);
> -return (rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
> +time_stamps.user_usec =
> +(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
> +time_stamps.sys_usec =
> +(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
>  #elif HAVE_GETPROCESSTIMES
>  HANDLE proc;
>  FILETIME c, e, k, u;
>  proc = GetCurrentProcess();
>  GetProcessTimes(proc, &c, &e, &k, &u);
> -return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> +time_stamps.user_usec =
> +((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> +time_stamps.sys_usec =
> +((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
>  #else
> -return av_gettime_relative();
> +time_stamps.user_usec = time_stamps.sys_usec = 0;
>  #endif
> +return time_stamps;
>  }
>
>  static int64_t getmaxrss(void)
> @@ -4759,7 +4776,7 @@ static void log_callback_null(void *ptr, int level,
> const char *fmt, va_list vl)
>  int main(int argc, char **argv)
>  {
>  int i, ret;
> -int64_t ti;
> +TimeStamps ti;
>
>  init_dynload();
>
> @@ -4811,12 +4828,17 @@ int main(int argc, char **argv)
>  want_sdp = 0;
>  }
>
> -current_time = ti = getutime();
> +current_time = ti = get_time_stamps();
>  if (transcode() < 0)
>  exit_program(1);
> -ti = getutime() - ti;
>  if (do_benchmark) {
> -av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti /
> 100.0);
> +  current_time = get_time_stamps();
> +  int64_t utime = current_time.user_usec - ti.user_usec;
> +  int64_t stime = current_time.sys_usec - ti.sys_usec;
> +  int64_t rtime = current_time.real_usec - ti.real_usec;
> +  av_log(NULL, AV_LOG_INFO,
> + "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
> + utime / 100.0, stime / 100.0, rtime / 100.0);
>  }
>  av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded,
> %"PRIu64" decoding errors\n",
> decode_error_stat[0], decode_error_stat[1]);
> --
> 2.17.0.484.g0c8726318c-goog
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Ronald S. Bultje]

Hi Thilo,

On Mon, Apr 23, 2018 at 4:45 PM, Thilo Borgmann 
wrote:

> From the users perspective I don't see why we don't have wrappers for a
> commercial codec.


Right, that's the core thing.

Why doesn't FFmpeg "promote" the use of this closed-source software?

Maybe it's because some of us contribute to this project not just out of
utility ("I can do XYZ with it"), but out of some sort of idealism ("I like
opensource"), trying to promote the common good of free software, kind of
like volunteering in some local community thing.

For these contributors, "promoting" closed-source software would run
directly contra to this ideal.

As an analogy, imagine that the Linux kernel started including wrappers to
promote the use of custom binary graphics device drivers. That would run
directly contra to the ideals that the project stands for. You personally
may not care so much, I understand that much, but please do see that some
other contributors might care far more.

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

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Paul B Mahol]

On 4/23/18, Nicolas George  wrote:
> Paul B Mahol (2018-04-23):
>> It is big threat.
>
> Will you please give arguments instead of repeating the same things
> endlessly?
>
> I think I intuitively agree with your position, but as it is, you
> objection is worthless, and Thilo would be entitled to just ignore it.

Why would we link to binary blobs that deny REing?

This is all messy to me. We are either good guys or we do not care and
do what every one does.

Adding wrappers like this, means we support them and we obey their rules.

Supporting closed source solutions also decrease chances for open source ones.

If you desperately need this: add it to VLC or GStreamer project.

If we supported external plugins this would not be problem.

Nobody came to me for REing this codec nor provided binary that does decoding.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Nicolas George]

Paul B Mahol (2018-04-23):
> It is big threat.

Will you please give arguments instead of repeating the same things
endlessly?

I think I intuitively agree with your position, but as it is, you
objection is worthless, and Thilo would be entitled to just ignore it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Paul B Mahol]

On 4/23/18, Thilo Borgmann  wrote:
> Am 23.04.18 um 22:47 schrieb Paul B Mahol:
>> On 4/23/18, Thilo Borgmann  wrote:
>>> Hi,
>>>
 not expressing specific agreement or disagreement.

 On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann 
 wrote:

> Am 23.04.18 um 03:36 schrieb James Almer:
>> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
>>> On 4/22/18, Thilo Borgmann  wrote:
 Hi,

 V3 drops the MLTI part, no idea how it survived
 02fff499362daedcdcb0a9cdd517257843600563 on our side...
 Also dropped audio override, could not get a sample requiring it.

 Adapted to current HEAD.
>>>
>>> I'm strongly against applying this to our tree.
>>
>> The de/muxing code can and should be applied as long as there are not
>> technical limitations. They are native code and depend on nothing
> external.
>>
>> And regarding the decoder and encoder wrappers, you need to explain
>> the
>> reasons for your hard NAK...
>
> Yes Paul please do, and while you're on it, please add your thoughts
> about
> making it good enough for our tree that come to your mind. I assume it
> is
> not RV11 or its library wrapper for itself you don't like to see
> pushed...


 So, let's take the hypothetical argument of the encoder. So, clearly,
 the
 company ("they") offering that encoder makes money and would benefit
 financially from seeing that encoder integrated with FFmpeg. Also, the
 maintenance effort would fall entirely on the opensource community
 ("we").
 For example, if we change API (big or small), we have to update their
 wrapper. However, their encoder itself (not wrapper) is still
 closed-source. So, it seems very one-sided in terms of who benefits at
 what
 cost and to who.

 My impression has always been that for opensource encoders, we were OK
 with
 this trade-off (there is GPL vs. LGPL etc., but we make it work in a
 variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
 with that, since GPL is still opensource, and for many end use cases,
 that
 works out fine anyway. However, for closed-source encoders, Iv'e always
 assumed that our default position is "no, thanks", and recommend these
 companies to maintain their patchset out-of-tree, so the cost of
 updating
 is on them, not us.

 Hypothetically, again, let's say this patch (encoder wrapper, or even
 decoder wrapper) went in, does that mean my companies' VP9 encoder
 wrapper
 can go in also? What about commercial H264/HEVC encoders? (There's many
 of
 them.) How do we decide which goes in if there's many and we don't know
 their quality/speed at various use cases because we don't have access to
 these under liberal licenses we are all comfortable with?

 (No specific opinion intended, just putting a wider frame on the
 discussion.)
>>>
>>> I totally see your point in us having to care for the wrapper if it is
>>> not
>>> out-of-tree. Also that this is or might easily be a financial saving for
>>> a
>>> company.
>>>
>>> I don't see us having a maintenance burden that big to refuse such code
>>> just
>>> of that, though.
>>> Of course, feeling "used" by a company to do "their" work adds to a
>>> negative
>>> impact. I added myself to be maintainer of that code in question and I
>>> don't
>>> feel that way (and no, I'm not on a permanent payroll of RealNetworks).
>>>
>>> Thinking of code that is not getting the devotion of any maintainer - we
>>> just removed that code in the past and why should that not happen to a
>>> wrapper utilizing a commercial binary. A company who wanted such a
>>> wrapper
>>> and shows no further interest in maintaining suffers from removed support
>>> sooner or later. Which might raise their interested again, doesn't it?
>>>
>>> From the users perspective I don't see why we don't have wrappers for a
>>> commercial codec. If the user wants to use it, why should we forbid such
>>> code. Having an out-of-tree repo to merge into the code for supporting
>>> such
>>> codec _is_ of course a way for the user to get it anyway. But from that
>>> only
>>> the users compiling & patching the code themselves are capable of doing
>>> so
>>> benefit - we lose sight of all others going that way.
>>>
>>> Paul and Rostislav adding a concern about killing the project with it by
>>> supporting closed source solutions.
>>> I don't get your big picture with that concern. I don't see how FFmpeg
>>> supporting external commercial codecs is a threat to our project. Please
>>> enlighten me and I'm serious about it. When I was asked about helping
>>> with
>>> such a wrapper for that library, my "natural" intention is to get FFmpeg
>>> support it if we don't have native or other support for that codec - to
>>> support every codec there is, which is one of our goals, isn't

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Thilo Borgmann]

Am 23.04.18 um 22:47 schrieb Paul B Mahol:
> On 4/23/18, Thilo Borgmann  wrote:
>> Hi,
>>
>>> not expressing specific agreement or disagreement.
>>>
>>> On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann 
>>> wrote:
>>>
 Am 23.04.18 um 03:36 schrieb James Almer:
> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
>> On 4/22/18, Thilo Borgmann  wrote:
>>> Hi,
>>>
>>> V3 drops the MLTI part, no idea how it survived
>>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
>>> Also dropped audio override, could not get a sample requiring it.
>>>
>>> Adapted to current HEAD.
>>
>> I'm strongly against applying this to our tree.
>
> The de/muxing code can and should be applied as long as there are not
> technical limitations. They are native code and depend on nothing
 external.
>
> And regarding the decoder and encoder wrappers, you need to explain the
> reasons for your hard NAK...

 Yes Paul please do, and while you're on it, please add your thoughts
 about
 making it good enough for our tree that come to your mind. I assume it is
 not RV11 or its library wrapper for itself you don't like to see
 pushed...
>>>
>>>
>>> So, let's take the hypothetical argument of the encoder. So, clearly, the
>>> company ("they") offering that encoder makes money and would benefit
>>> financially from seeing that encoder integrated with FFmpeg. Also, the
>>> maintenance effort would fall entirely on the opensource community ("we").
>>> For example, if we change API (big or small), we have to update their
>>> wrapper. However, their encoder itself (not wrapper) is still
>>> closed-source. So, it seems very one-sided in terms of who benefits at
>>> what
>>> cost and to who.
>>>
>>> My impression has always been that for opensource encoders, we were OK
>>> with
>>> this trade-off (there is GPL vs. LGPL etc., but we make it work in a
>>> variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
>>> with that, since GPL is still opensource, and for many end use cases, that
>>> works out fine anyway. However, for closed-source encoders, Iv'e always
>>> assumed that our default position is "no, thanks", and recommend these
>>> companies to maintain their patchset out-of-tree, so the cost of updating
>>> is on them, not us.
>>>
>>> Hypothetically, again, let's say this patch (encoder wrapper, or even
>>> decoder wrapper) went in, does that mean my companies' VP9 encoder wrapper
>>> can go in also? What about commercial H264/HEVC encoders? (There's many of
>>> them.) How do we decide which goes in if there's many and we don't know
>>> their quality/speed at various use cases because we don't have access to
>>> these under liberal licenses we are all comfortable with?
>>>
>>> (No specific opinion intended, just putting a wider frame on the
>>> discussion.)
>>
>> I totally see your point in us having to care for the wrapper if it is not
>> out-of-tree. Also that this is or might easily be a financial saving for a
>> company.
>>
>> I don't see us having a maintenance burden that big to refuse such code just
>> of that, though.
>> Of course, feeling "used" by a company to do "their" work adds to a negative
>> impact. I added myself to be maintainer of that code in question and I don't
>> feel that way (and no, I'm not on a permanent payroll of RealNetworks).
>>
>> Thinking of code that is not getting the devotion of any maintainer - we
>> just removed that code in the past and why should that not happen to a
>> wrapper utilizing a commercial binary. A company who wanted such a wrapper
>> and shows no further interest in maintaining suffers from removed support
>> sooner or later. Which might raise their interested again, doesn't it?
>>
>> From the users perspective I don't see why we don't have wrappers for a
>> commercial codec. If the user wants to use it, why should we forbid such
>> code. Having an out-of-tree repo to merge into the code for supporting such
>> codec _is_ of course a way for the user to get it anyway. But from that only
>> the users compiling & patching the code themselves are capable of doing so
>> benefit - we lose sight of all others going that way.
>>
>> Paul and Rostislav adding a concern about killing the project with it by
>> supporting closed source solutions.
>> I don't get your big picture with that concern. I don't see how FFmpeg
>> supporting external commercial codecs is a threat to our project. Please
>> enlighten me and I'm serious about it. When I was asked about helping with
>> such a wrapper for that library, my "natural" intention is to get FFmpeg
>> support it if we don't have native or other support for that codec - to
>> support every codec there is, which is one of our goals, isn't it?
> 
> 
> Please, I'm not supporting binary blobs, nor do I intend to use them.

And you're welcome to do so. How is it an argument to have everyone to obey 
that?


>> I can't stress enough how seriously I want y

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Paul B Mahol]

On 4/23/18, Thilo Borgmann  wrote:
> Hi,
>
>> not expressing specific agreement or disagreement.
>>
>> On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann 
>> wrote:
>>
>>> Am 23.04.18 um 03:36 schrieb James Almer:
 On 4/22/2018 6:43 PM, Paul B Mahol wrote:
> On 4/22/18, Thilo Borgmann  wrote:
>> Hi,
>>
>> V3 drops the MLTI part, no idea how it survived
>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
>> Also dropped audio override, could not get a sample requiring it.
>>
>> Adapted to current HEAD.
>
> I'm strongly against applying this to our tree.

 The de/muxing code can and should be applied as long as there are not
 technical limitations. They are native code and depend on nothing
>>> external.

 And regarding the decoder and encoder wrappers, you need to explain the
 reasons for your hard NAK...
>>>
>>> Yes Paul please do, and while you're on it, please add your thoughts
>>> about
>>> making it good enough for our tree that come to your mind. I assume it is
>>> not RV11 or its library wrapper for itself you don't like to see
>>> pushed...
>>
>>
>> So, let's take the hypothetical argument of the encoder. So, clearly, the
>> company ("they") offering that encoder makes money and would benefit
>> financially from seeing that encoder integrated with FFmpeg. Also, the
>> maintenance effort would fall entirely on the opensource community ("we").
>> For example, if we change API (big or small), we have to update their
>> wrapper. However, their encoder itself (not wrapper) is still
>> closed-source. So, it seems very one-sided in terms of who benefits at
>> what
>> cost and to who.
>>
>> My impression has always been that for opensource encoders, we were OK
>> with
>> this trade-off (there is GPL vs. LGPL etc., but we make it work in a
>> variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
>> with that, since GPL is still opensource, and for many end use cases, that
>> works out fine anyway. However, for closed-source encoders, Iv'e always
>> assumed that our default position is "no, thanks", and recommend these
>> companies to maintain their patchset out-of-tree, so the cost of updating
>> is on them, not us.
>>
>> Hypothetically, again, let's say this patch (encoder wrapper, or even
>> decoder wrapper) went in, does that mean my companies' VP9 encoder wrapper
>> can go in also? What about commercial H264/HEVC encoders? (There's many of
>> them.) How do we decide which goes in if there's many and we don't know
>> their quality/speed at various use cases because we don't have access to
>> these under liberal licenses we are all comfortable with?
>>
>> (No specific opinion intended, just putting a wider frame on the
>> discussion.)
>
> I totally see your point in us having to care for the wrapper if it is not
> out-of-tree. Also that this is or might easily be a financial saving for a
> company.
>
> I don't see us having a maintenance burden that big to refuse such code just
> of that, though.
> Of course, feeling "used" by a company to do "their" work adds to a negative
> impact. I added myself to be maintainer of that code in question and I don't
> feel that way (and no, I'm not on a permanent payroll of RealNetworks).
>
> Thinking of code that is not getting the devotion of any maintainer - we
> just removed that code in the past and why should that not happen to a
> wrapper utilizing a commercial binary. A company who wanted such a wrapper
> and shows no further interest in maintaining suffers from removed support
> sooner or later. Which might raise their interested again, doesn't it?
>
> From the users perspective I don't see why we don't have wrappers for a
> commercial codec. If the user wants to use it, why should we forbid such
> code. Having an out-of-tree repo to merge into the code for supporting such
> codec _is_ of course a way for the user to get it anyway. But from that only
> the users compiling & patching the code themselves are capable of doing so
> benefit - we lose sight of all others going that way.
>
> Paul and Rostislav adding a concern about killing the project with it by
> supporting closed source solutions.
> I don't get your big picture with that concern. I don't see how FFmpeg
> supporting external commercial codecs is a threat to our project. Please
> enlighten me and I'm serious about it. When I was asked about helping with
> such a wrapper for that library, my "natural" intention is to get FFmpeg
> support it if we don't have native or other support for that codec - to
> support every codec there is, which is one of our goals, isn't it?


Please, I'm not supporting binary blobs, nor do I intend to use them.

>
> I can't stress enough how seriously I want you to explain me your point of
> view. I'm doing a lot of things in the best interest of FFmpeg, I'm spending
> money in the name of the project, talking to a million different faces about
> it and if "go with an out-of-tree wrapp

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Thilo Borgmann]

Hi,

> not expressing specific agreement or disagreement.
> 
> On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann 
> wrote:
> 
>> Am 23.04.18 um 03:36 schrieb James Almer:
>>> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
 On 4/22/18, Thilo Borgmann  wrote:
> Hi,
>
> V3 drops the MLTI part, no idea how it survived
> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
> Also dropped audio override, could not get a sample requiring it.
>
> Adapted to current HEAD.

 I'm strongly against applying this to our tree.
>>>
>>> The de/muxing code can and should be applied as long as there are not
>>> technical limitations. They are native code and depend on nothing
>> external.
>>>
>>> And regarding the decoder and encoder wrappers, you need to explain the
>>> reasons for your hard NAK...
>>
>> Yes Paul please do, and while you're on it, please add your thoughts about
>> making it good enough for our tree that come to your mind. I assume it is
>> not RV11 or its library wrapper for itself you don't like to see pushed...
> 
> 
> So, let's take the hypothetical argument of the encoder. So, clearly, the
> company ("they") offering that encoder makes money and would benefit
> financially from seeing that encoder integrated with FFmpeg. Also, the
> maintenance effort would fall entirely on the opensource community ("we").
> For example, if we change API (big or small), we have to update their
> wrapper. However, their encoder itself (not wrapper) is still
> closed-source. So, it seems very one-sided in terms of who benefits at what
> cost and to who.
> 
> My impression has always been that for opensource encoders, we were OK with
> this trade-off (there is GPL vs. LGPL etc., but we make it work in a
> variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
> with that, since GPL is still opensource, and for many end use cases, that
> works out fine anyway. However, for closed-source encoders, Iv'e always
> assumed that our default position is "no, thanks", and recommend these
> companies to maintain their patchset out-of-tree, so the cost of updating
> is on them, not us.
> 
> Hypothetically, again, let's say this patch (encoder wrapper, or even
> decoder wrapper) went in, does that mean my companies' VP9 encoder wrapper
> can go in also? What about commercial H264/HEVC encoders? (There's many of
> them.) How do we decide which goes in if there's many and we don't know
> their quality/speed at various use cases because we don't have access to
> these under liberal licenses we are all comfortable with?
> 
> (No specific opinion intended, just putting a wider frame on the
> discussion.)

I totally see your point in us having to care for the wrapper if it is not 
out-of-tree. Also that this is or might easily be a financial saving for a 
company.

I don't see us having a maintenance burden that big to refuse such code just of 
that, though.
Of course, feeling "used" by a company to do "their" work adds to a negative 
impact. I added myself to be maintainer of that code in question and I don't 
feel that way (and no, I'm not on a permanent payroll of RealNetworks).

Thinking of code that is not getting the devotion of any maintainer - we just 
removed that code in the past and why should that not happen to a wrapper 
utilizing a commercial binary. A company who wanted such a wrapper and shows no 
further interest in maintaining suffers from removed support sooner or later. 
Which might raise their interested again, doesn't it?

From the users perspective I don't see why we don't have wrappers for a 
commercial codec. If the user wants to use it, why should we forbid such code. 
Having an out-of-tree repo to merge into the code for supporting such codec 
_is_ of course a way for the user to get it anyway. But from that only the 
users compiling & patching the code themselves are capable of doing so benefit 
- we lose sight of all others going that way.

Paul and Rostislav adding a concern about killing the project with it by 
supporting closed source solutions.
I don't get your big picture with that concern. I don't see how FFmpeg 
supporting external commercial codecs is a threat to our project. Please 
enlighten me and I'm serious about it. When I was asked about helping with such 
a wrapper for that library, my "natural" intention is to get FFmpeg support it 
if we don't have native or other support for that codec - to support every 
codec there is, which is one of our goals, isn't it?

I can't stress enough how seriously I want you to explain me your point of 
view. I'm doing a lot of things in the best interest of FFmpeg, I'm spending 
money in the name of the project, talking to a million different faces about it 
and if "go with an out-of-tree wrapper" is our opinion on that for a reason I 
want you to convince of that. Give me a call if you feel to, I mean it - I 
don't care much about a commercial flaming discussion nor do I want to make a 
point about the topic,

Re: [FFmpeg-devel] [PATCH 08/14] avcodec/vc1: implement interlaced out-of-bounds reference pixel replication

[Paul B Mahol]

On 4/23/18, Jerome Borsboom  wrote:
> The existing implementation did out-of-bounds reference pixel replication
> for
> progressive reference frames. In interlaced reference frames both the even
> and
> odd line on the horizontal edges need to be replicated.
>
> Signed-off-by: Jerome Borsboom 
> ---
>  libavcodec/vc1_mc.c | 376
> +---
>  tests/ref/fate/vc1_ilaced_twomv |  18 +-
>  2 files changed, 318 insertions(+), 76 deletions(-)
>

Thanks, this one fixes #3262.

Could you look at #4372 sample?

http://trac.ffmpeg.org/ticket/4372

Reference decoder decodes it fine.

I plan to push this patchset in following days.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Rostislav Pehlivanov]

On 23 April 2018 at 20:32, Paul B Mahol  wrote:

> On 4/23/18, Thilo Borgmann  wrote:
> > Am 23.04.18 um 03:36 schrieb James Almer:
> >> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
> >>> On 4/22/18, Thilo Borgmann  wrote:
>  Hi,
> 
>  V3 drops the MLTI part, no idea how it survived
>  02fff499362daedcdcb0a9cdd517257843600563 on our side...
>  Also dropped audio override, could not get a sample requiring it.
> 
>  Adapted to current HEAD.
> >>>
> >>> I'm strongly against applying this to our tree.
> >>
> >> The de/muxing code can and should be applied as long as there are not
> >> technical limitations. They are native code and depend on nothing
> >> external.
> >>
> >> And regarding the decoder and encoder wrappers, you need to explain the
> >> reasons for your hard NAK...
> >
> > Yes Paul please do, and while you're on it, please add your thoughts
> about
> > making it good enough for our tree that come to your mind. I assume it is
> > not RV11 or its library wrapper for itself you don't like to see
> pushed...
>
> This will allow any random guy to send wrappers that supports any closed
> source
> solution.
>
> Yes, we have hardware stuff and other devices, but for decoders I
> strongly object
> to commit this wrapper for closed source solution.
>
> If we go to the closed source way, we may kill project right a way and
> remove all
> native code.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Rostislav Pehlivanov]

On 23 April 2018 at 20:16, Thomas Volkert  wrote:

>
> On 23.04.2018 11:27, Thomas Volkert wrote:
> > On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
> >> 2018-04-22 20:00 GMT+02:00, Nicolas George :
> >>> Carl Eugen Hoyos (2018-04-22):
>  How do you detect that this is not the "current version" of mbed?
> >>> Is it really our responsibility?
> >> We try to always do it and I believe that allowing LGPL makes
> >> more sense and less headache: Since we do the checks so
> >> rigorously it makes sense to assume we did it as correctly
> >> for this case.
> >>
> >> I don't understand why we don't go the easy way that clearly
> >> has advantages instead for the complicated way (with at
> >> least some disadvantages).
> > Okay. I looked over their web page and the Debian packages again.
> > The web page of mbedTLS declares Apache license as the "primary open
> > source license".
> >
> > I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> > their are no further objections.
>
> pushed
>
> Best regards,
> Thomas.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Sorry, had to revert, I'd still like to know what gains (disk space,
performance, maybe security-wise too if possible), this would have over
existing TLS libraries. Code-wise it looked fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Paul B Mahol]

On 4/23/18, Thilo Borgmann  wrote:
> Am 23.04.18 um 03:36 schrieb James Almer:
>> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
>>> On 4/22/18, Thilo Borgmann  wrote:
 Hi,

 V3 drops the MLTI part, no idea how it survived
 02fff499362daedcdcb0a9cdd517257843600563 on our side...
 Also dropped audio override, could not get a sample requiring it.

 Adapted to current HEAD.
>>>
>>> I'm strongly against applying this to our tree.
>>
>> The de/muxing code can and should be applied as long as there are not
>> technical limitations. They are native code and depend on nothing
>> external.
>>
>> And regarding the decoder and encoder wrappers, you need to explain the
>> reasons for your hard NAK...
>
> Yes Paul please do, and while you're on it, please add your thoughts about
> making it good enough for our tree that come to your mind. I assume it is
> not RV11 or its library wrapper for itself you don't like to see pushed...

This will allow any random guy to send wrappers that supports any closed source
solution.

Yes, we have hardware stuff and other devices, but for decoders I
strongly object
to commit this wrapper for closed source solution.

If we go to the closed source way, we may kill project right a way and
remove all
native code.
___
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.

[Rostislav Pehlivanov]

On 23 April 2018 at 17:02, Drew Allen 
wrote:

> We have spent the past 2 years with the draft relatively unchanged aside
> from minor edits on the draft. It is headed to a working group for
> finalization very soon and no one has yet raised a single issue regarding
> any proposed changes that this patch introduces. I wrote the
> OpusProjection* API and it has been adopted in all Opus-related xiph master
> branches.
>

Good to hear. I know the IETF can take an extraordinarily long amount of
time to publish a draft and make it an RFC and wish you all the luck on
getting it completed quickly.


I worked closely with Jean-Marc Valin to design the API in Opus 1.3 to his
> specification. Opus 1.3 beta already contains this new API and upon
> release, I have 100% assurance from Jean-Marc that the OpusProjection* API
> will be supported in 1.3 RC.
>

...hidden behind a configure flag and not enabled by default. No one will
enable it until its ready and becomes accepted, which is why it isn't
enabled by default.



> I disagree that a filter or some other layer of abstraction is necessary
> here. OpusProjection* does not code the ambisonic channels directly.
> Instead, they are mixed using a mixing matrix that minimizes coding
> artifacts over the sphere. The demixing matrix on the decoder is vital in
> order to get back the original ambisonic channels and OpusProjectionDecoder
> handles this automatically.
>

Ah, okay. In which case what we need still is an API to signal the
ambisonics order and any other metadata needed. We can't just say "here's a
frame with a bunch of channels, based on their numer you could probably
figure its some ambisonics" and clients shouldn't use heuristics like "this
frame has 16 channels, its probably ambisonics". This information needs to
be indicated properly.


I completely disagree. The IETF draft has been stable for over a year and
> these same changes to support the new API are already present in Opus,
> libopusenc, opusfile and opus-tools.


Stable != accepted. The option to enable the API is still hidden behind a
configure flag for libopus. And it will remain like this until it becomes
an RFC, just like the previous RFC which butc... updated the codec with
some fixes.

If libopus had the new API enabled by default I wouldn't mind this patch at
all and would apply it, since I'd be sure it wouldn't change. But as it
stands, both it and the signalling changes in the RFC can change at any
time despite being stable by yourself.

Also your mail client stripped the quote marks and made things confusing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[wm4]

On Mon, 23 Apr 2018 21:09:09 +0200
Thomas Volkert  wrote:

> On 23.04.2018 14:08, Rostislav Pehlivanov wrote:
> > On 23 April 2018 at 10:27, Thomas Volkert  wrote:
> >  
> >> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:  
> >>> 2018-04-22 20:00 GMT+02:00, Nicolas George :  
>  Carl Eugen Hoyos (2018-04-22):  
> > How do you detect that this is not the "current version" of mbed?  
>  Is it really our responsibility?  
> >>> We try to always do it and I believe that allowing LGPL makes
> >>> more sense and less headache: Since we do the checks so
> >>> rigorously it makes sense to assume we did it as correctly
> >>> for this case.
> >>>
> >>> I don't understand why we don't go the easy way that clearly
> >>> has advantages instead for the complicated way (with at
> >>> least some disadvantages).  
> >> Okay. I looked over their web page and the Debian packages again.
> >> The web page of mbedTLS declares Apache license as the "primary open
> >> source license".
> >>
> >> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> >> their are no further objections.
> >>
> >> Best regards,
> >> Thomas.
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>  
> > I'd like some memory usage and performance comparisons to gnutls and  
> 
> The mbedTLS library uses less than half of the disc space compared to
> OpenSSL in this context.
> I don't have exact figures for memory consumption for different
> scenarios right now.
> 
> 
> > openssl before you push. This is the 6th (!!) TLS library we'd be
> > supporting.  
> 
> Two of the existing ones are OS specific.
> 
> In general, I see mbedTLS as an enrichment for FFmpeg. MbedTLS seems to
> be a promising alternative to OpenSSL and other TLS implementations in
> the context of embedded systems: the disk footprint is smaller out of
> the box, the memory footprint is smaller, the library is intentionally
> modular so that these can be reduced further at need
> (https://tls.mbed.org/tiny-ssl-library,
> https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint).
> 
> Additionally, in the planned context the mbedTLS library is already used
> for signaling out-of-band control messages between network peers. And it
> is planned to do some more tuning to the overall setup to get an even
> smaller version of mbedTLS on the target device.

To be honest that's not really convincing. How does it compare with
e.g. libtls?

In my opinion it's probably not wrong to give another TLS lib a try,
but:
1. It was kind of too early. You should at least have given us some
   time to respond.
2. Having many TLS wrappers is actually not a good thing because it
   will confuse users about which one to pick, and the wrappers will
   all have subtly different behavior that can become a problem for
   ffmpeg and libav* users.
3. It's hard to remove redundant things even after it has turned out
   that they were not that useful. (See e.g. how much effort it was to
   remove some of the virtually useless codec lib wrappers.)
But it's just my opinion that having fewer well maintained choices is
better than many with maintenance deficits.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 23.04.2018 11:27, Thomas Volkert wrote:
> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
>> 2018-04-22 20:00 GMT+02:00, Nicolas George :
>>> Carl Eugen Hoyos (2018-04-22):
 How do you detect that this is not the "current version" of mbed?
>>> Is it really our responsibility?
>> We try to always do it and I believe that allowing LGPL makes
>> more sense and less headache: Since we do the checks so
>> rigorously it makes sense to assume we did it as correctly
>> for this case.
>>
>> I don't understand why we don't go the easy way that clearly
>> has advantages instead for the complicated way (with at
>> least some disadvantages).
> Okay. I looked over their web page and the Debian packages again.
> The web page of mbedTLS declares Apache license as the "primary open
> source license".
>
> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> their are no further objections.

pushed

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

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Ronald S. Bultje]

Hi Thilo,

not expressing specific agreement or disagreement.

On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann 
wrote:

> Am 23.04.18 um 03:36 schrieb James Almer:
> > On 4/22/2018 6:43 PM, Paul B Mahol wrote:
> >> On 4/22/18, Thilo Borgmann  wrote:
> >>> Hi,
> >>>
> >>> V3 drops the MLTI part, no idea how it survived
> >>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
> >>> Also dropped audio override, could not get a sample requiring it.
> >>>
> >>> Adapted to current HEAD.
> >>
> >> I'm strongly against applying this to our tree.
> >
> > The de/muxing code can and should be applied as long as there are not
> > technical limitations. They are native code and depend on nothing
> external.
> >
> > And regarding the decoder and encoder wrappers, you need to explain the
> > reasons for your hard NAK...
>
> Yes Paul please do, and while you're on it, please add your thoughts about
> making it good enough for our tree that come to your mind. I assume it is
> not RV11 or its library wrapper for itself you don't like to see pushed...


So, let's take the hypothetical argument of the encoder. So, clearly, the
company ("they") offering that encoder makes money and would benefit
financially from seeing that encoder integrated with FFmpeg. Also, the
maintenance effort would fall entirely on the opensource community ("we").
For example, if we change API (big or small), we have to update their
wrapper. However, their encoder itself (not wrapper) is still
closed-source. So, it seems very one-sided in terms of who benefits at what
cost and to who.

My impression has always been that for opensource encoders, we were OK with
this trade-off (there is GPL vs. LGPL etc., but we make it work in a
variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
with that, since GPL is still opensource, and for many end use cases, that
works out fine anyway. However, for closed-source encoders, Iv'e always
assumed that our default position is "no, thanks", and recommend these
companies to maintain their patchset out-of-tree, so the cost of updating
is on them, not us.

Hypothetically, again, let's say this patch (encoder wrapper, or even
decoder wrapper) went in, does that mean my companies' VP9 encoder wrapper
can go in also? What about commercial H264/HEVC encoders? (There's many of
them.) How do we decide which goes in if there's many and we don't know
their quality/speed at various use cases because we don't have access to
these under liberal licenses we are all comfortable with?

(No specific opinion intended, just putting a wider frame on the
discussion.)

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 23.04.2018 14:08, Rostislav Pehlivanov wrote:
> On 23 April 2018 at 10:27, Thomas Volkert  wrote:
>
>> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
>>> 2018-04-22 20:00 GMT+02:00, Nicolas George :
 Carl Eugen Hoyos (2018-04-22):
> How do you detect that this is not the "current version" of mbed?
 Is it really our responsibility?
>>> We try to always do it and I believe that allowing LGPL makes
>>> more sense and less headache: Since we do the checks so
>>> rigorously it makes sense to assume we did it as correctly
>>> for this case.
>>>
>>> I don't understand why we don't go the easy way that clearly
>>> has advantages instead for the complicated way (with at
>>> least some disadvantages).
>> Okay. I looked over their web page and the Debian packages again.
>> The web page of mbedTLS declares Apache license as the "primary open
>> source license".
>>
>> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
>> their are no further objections.
>>
>> Best regards,
>> Thomas.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> I'd like some memory usage and performance comparisons to gnutls and

The mbedTLS library uses less than half of the disc space compared to
OpenSSL in this context.
I don't have exact figures for memory consumption for different
scenarios right now.


> openssl before you push. This is the 6th (!!) TLS library we'd be
> supporting.

Two of the existing ones are OS specific.

In general, I see mbedTLS as an enrichment for FFmpeg. MbedTLS seems to
be a promising alternative to OpenSSL and other TLS implementations in
the context of embedded systems: the disk footprint is smaller out of
the box, the memory footprint is smaller, the library is intentionally
modular so that these can be reduced further at need
(https://tls.mbed.org/tiny-ssl-library,
https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint).

Additionally, in the planned context the mbedTLS library is already used
for signaling out-of-band control messages between network peers. And it
is planned to do some more tuning to the overall setup to get an even
smaller version of mbedTLS on the target device.


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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[James Almer]

On 4/23/2018 6:27 AM, Thomas Volkert wrote:
> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
>> 2018-04-22 20:00 GMT+02:00, Nicolas George :
>>> Carl Eugen Hoyos (2018-04-22):
 How do you detect that this is not the "current version" of mbed?
>>> Is it really our responsibility?
>> We try to always do it and I believe that allowing LGPL makes
>> more sense and less headache: Since we do the checks so
>> rigorously it makes sense to assume we did it as correctly
>> for this case.
>>
>> I don't understand why we don't go the easy way that clearly
>> has advantages instead for the complicated way (with at
>> least some disadvantages).
> 
> Okay. I looked over their web page and the Debian packages again.
> The web page of mbedTLS declares Apache license as the "primary open
> source license".
> 
> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> their are no further objections.

Not only there was an objection/request by Rostislav Pehlivanov you
ignored, you also pushed this after ONE day in the ml, with absolutely
no review. What exactly was the hurry?

Please, revert this. Forcing your way through is not how code should be
committed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 3/4] avutil/pixdesc: add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8

[wm4]

On Mon, 23 Apr 2018 20:25:40 +0200 (CEST)
Marton Balint  wrote:

> On Sun, 22 Apr 2018, wm4 wrote:
> 
> > On Sun, 22 Apr 2018 13:24:11 +0200 (CEST)
> > Marton Balint  wrote:
> >  
> >> On Fri, 20 Apr 2018, wm4 wrote:
> >>   
> >> > On Thu, 19 Apr 2018 23:25:03 +0200
> >> > Marton Balint  wrote:
> >> >   
> >> >> Signed-off-by: Marton Balint 
> >> >> ---
> >> >>  doc/APIchanges| 3 +++
> >> >>  libavutil/pixdesc.c   | 3 +--
> >> >>  libavutil/pixdesc.h   | 8 ++--
> >> >>  libavutil/tests/pixdesc.c | 4 
> >> >>  libavutil/version.h   | 2 +-
> >> >>  5 files changed, 7 insertions(+), 13 deletions(-)
> >> >> 
> >> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> >> index 4f6ac2a031..d9b457e080 100644
> >> >> --- a/doc/APIchanges
> >> >> +++ b/doc/APIchanges
> >> >> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >> >>
> >> >>  API changes, most recent first:
> >> >> 
> >> >> +2018-04-xx - xx - lavu 56.16.100 - pixdesc.h
> >> >> +  Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
> >> >> +   
> >> 
> >> [..]
> >>   
> >> >
> >> > Probably fine. While I like it, we also have to be careful about the
> >> > consequences. Does it change FATE or the results of that pixfmt choosing
> >> > function, avcodec_find_best_pix_fmt_of_list()?   
> >> 
> >> Fate passes. I am not sure about avcodec_find_best_pix_fmt_of_list(), but 
> >> since pixdesc_has_alpha() in avutil/pixdesc.c already considered PAL8 as a 
> >> format with alpha, I don't think it changes.  
> >
> > Oh, interesting point. So this whole discussion is moot anyway, since
> > it always suggested RGBA when converting PAL8 to a non-paletted RGB
> > format?  
> 
> Only if has_alpha was true when the user called 
> avcodec_find_best_pix_fmt_of_list() or av_find_best_pix_fmt_of_2().
> 
> For avfiltergraph format negotiation or for ffmpeg.c automatic codec pixel 
> format selection, pal8 was not considered as a format with alpha 
> (nb_components % 2 == 0 check was used), so they called 
> av_find_best_pix_fmt_of_2() with has_alpha=false, therefore alpha loss was 
> not penalized. A subsequent patch takes care of that.

Right. That's a bit of a mess. So if anyone thinks that's a problem,
the avfilter code can still be special-cased, or we could introduce a
non-alpha PAL format.

LGTM anyway, it's a nice cleanup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 14/14] avcodec/vc1: correct forgotten v->blocks_off

[Jerome Borsboom]

correct forgotten v->blocks_off

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_pred.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 3a52a22bc6..de736ec775 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -254,7 +254,7 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int 
dmv_y,
 v->luma_mv[s->mb_x][0] = v->luma_mv[s->mb_x][1] = 0;
 s->current_picture.motion_val[1][xy + 1 + v->blocks_off][0]
= 0;
 s->current_picture.motion_val[1][xy + 1 + v->blocks_off][1]
= 0;
-s->current_picture.motion_val[1][xy + wrap][0] 
= 0;
+s->current_picture.motion_val[1][xy + wrap + v->blocks_off][0] 
= 0;
 s->current_picture.motion_val[1][xy + wrap + v->blocks_off][1] 
= 0;
 s->current_picture.motion_val[1][xy + wrap + 1 + v->blocks_off][0] 
= 0;
 s->current_picture.motion_val[1][xy + wrap + 1 + v->blocks_off][1] 
= 0;
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 12/14] avcodec/vc1: correct mspel for field-interlace B frames

[Jerome Borsboom]

mspel indicates the use of bicubic interpolation. The check wrongly included
MVMODE MV_PMODE_1MV_HPEL as using bilinear interpolation.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index 2b9f8db3ee..20cc84eb8e 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -1224,7 +1224,7 @@ int ff_vc1_parse_frame_header_adv(VC1Context *v, 
GetBitContext* gb)
 v->mv_mode  = ff_vc1_mv_pmode_table2[lowquant][mvmode];
 v->qs_last  = v->s.quarter_sample;
 v->s.quarter_sample = (v->mv_mode == MV_PMODE_1MV || v->mv_mode == 
MV_PMODE_MIXED_MV);
-v->s.mspel  = !(v->mv_mode == MV_PMODE_1MV_HPEL_BILIN || 
v->mv_mode == MV_PMODE_1MV_HPEL);
+v->s.mspel  = (v->mv_mode != MV_PMODE_1MV_HPEL_BILIN);
 status = bitplane_decoding(v->forward_mb_plane, &v->fmb_is_raw, v);
 if (status < 0)
 return -1;
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 11/14] avcodec/vc1: remove unused overlap smooting and loop filter

[Jerome Borsboom]

remove unused overlap smooting and loop filter

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1.h|   3 -
 libavcodec/vc1_loopfilter.c | 297 
 2 files changed, 300 deletions(-)

diff --git a/libavcodec/vc1.h b/libavcodec/vc1.h
index 0dfdef78cd..1d283f8589 100644
--- a/libavcodec/vc1.h
+++ b/libavcodec/vc1.h
@@ -423,11 +423,8 @@ int  ff_vc1_decode_end(AVCodecContext *avctx);
 void ff_vc1_decode_blocks(VC1Context *v);
 
 void ff_vc1_loop_filter_iblk(VC1Context *v, int pq);
-void ff_vc1_loop_filter_iblk_delayed(VC1Context *v, int pq);
-void ff_vc1_smooth_overlap_filter_iblk(VC1Context *v);
 void ff_vc1_i_overlap_filter(VC1Context *v);
 void ff_vc1_p_overlap_filter(VC1Context *v);
-void ff_vc1_apply_p_loop_filter(VC1Context *v);
 void ff_vc1_i_loop_filter(VC1Context *v);
 void ff_vc1_p_loop_filter(VC1Context *v);
 void ff_vc1_p_intfr_loop_filter(VC1Context *v);
diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c
index 7ef0fd1ea2..bab28a649f 100644
--- a/libavcodec/vc1_loopfilter.c
+++ b/libavcodec/vc1_loopfilter.c
@@ -61,153 +61,6 @@ void ff_vc1_loop_filter_iblk(VC1Context *v, int pq)
 }
 }
 
-void ff_vc1_loop_filter_iblk_delayed(VC1Context *v, int pq)
-{
-MpegEncContext *s = &v->s;
-int j;
-
-/* The loopfilter runs 1 row and 1 column behind the overlap filter, which
- * means it runs two rows/cols behind the decoding loop. */
-if (!s->first_slice_line) {
-if (s->mb_x) {
-if (s->mb_y >= s->start_mb_y + 2) {
-v->vc1dsp.vc1_v_loop_filter16(s->dest[0] - 16 * s->linesize - 
16, s->linesize, pq);
-
-if (s->mb_x >= 2)
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 32 * 
s->linesize - 16, s->linesize, pq);
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 32 * s->linesize - 
8, s->linesize, pq);
-if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY))
-for (j = 0; j < 2; j++) {
-v->vc1dsp.vc1_v_loop_filter8(s->dest[j + 1] - 8 * 
s->uvlinesize - 8, s->uvlinesize, pq);
-if (s->mb_x >= 2) {
-v->vc1dsp.vc1_h_loop_filter8(s->dest[j + 1] - 16 * 
s->uvlinesize - 8, s->uvlinesize, pq);
-}
-}
-}
-v->vc1dsp.vc1_v_loop_filter16(s->dest[0] - 8 * s->linesize - 16, 
s->linesize, pq);
-}
-
-if (s->mb_x == s->mb_width - 1) {
-if (s->mb_y >= s->start_mb_y + 2) {
-v->vc1dsp.vc1_v_loop_filter16(s->dest[0] - 16 * s->linesize, 
s->linesize, pq);
-
-if (s->mb_x)
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 32 * 
s->linesize, s->linesize, pq);
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 32 * s->linesize + 
8, s->linesize, pq);
-if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY))
-for (j = 0; j < 2; j++) {
-v->vc1dsp.vc1_v_loop_filter8(s->dest[j + 1] - 8 * 
s->uvlinesize, s->uvlinesize, pq);
-if (s->mb_x >= 2) {
-v->vc1dsp.vc1_h_loop_filter8(s->dest[j + 1] - 16 * 
s->uvlinesize, s->uvlinesize, pq);
-}
-}
-}
-v->vc1dsp.vc1_v_loop_filter16(s->dest[0] - 8 * s->linesize, 
s->linesize, pq);
-}
-
-if (s->mb_y == s->end_mb_y) {
-if (s->mb_x) {
-if (s->mb_x >= 2)
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 16 * 
s->linesize - 16, s->linesize, pq);
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 16 * s->linesize - 
8, s->linesize, pq);
-if (s->mb_x >= 2 && (!CONFIG_GRAY || !(s->avctx->flags & 
AV_CODEC_FLAG_GRAY))) {
-for (j = 0; j < 2; j++) {
-v->vc1dsp.vc1_h_loop_filter8(s->dest[j + 1] - 8 * 
s->uvlinesize - 8, s->uvlinesize, pq);
-}
-}
-}
-
-if (s->mb_x == s->mb_width - 1) {
-if (s->mb_x)
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 16 * 
s->linesize, s->linesize, pq);
-v->vc1dsp.vc1_h_loop_filter16(s->dest[0] - 16 * s->linesize + 
8, s->linesize, pq);
-if (s->mb_x && (!CONFIG_GRAY || !(s->avctx->flags & 
AV_CODEC_FLAG_GRAY))) {
-for (j = 0; j < 2; j++) {
-v->vc1dsp.vc1_h_loop_filter8(s->dest[j + 1] - 8 * 
s->uvlinesize, s->uvlinesize, pq);
-}
-}
-}
-}
-}
-}
-
-void ff_vc1_smooth_overlap_filter_iblk(VC1Context *v)
-{
-MpegEncContext *s = &v->s;
-int mb_pos;
-
-if (v->condover == CONDOVER_NONE)
-return;
-
-mb_pos = s->mb_x + s->mb_y * s->mb_stride;
-
-/* Within a MB, the horizontal overlap always runs before the vertical.
- * To accomplish that, we run the H on left

[FFmpeg-devel] [PATCH 10/14] avcodec/vc1: add overlap smooting and loop filter for frame/field-interlace

[Jerome Borsboom]

Add previously omitted overlap smooting and loop filtering for
frame/field-interlace pictures. For progressive pictures switch to the
re-implemented versions of overlap smooting and loop filtering.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_block.c  | 111 +++-
 tests/ref/fate/vc1_ilaced_twomv |  26 +-
 tests/ref/fate/vc1_sa10143  |  60 +++---
 3 files changed, 83 insertions(+), 114 deletions(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index f2f5c7f88b..7d6d5c781c 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -1328,16 +1328,6 @@ static int vc1_decode_p_mb(VC1Context *v)
 if (v->rangeredfrm)
 for (j = 0; j < 64; j++)
 v->block[v->cur_blk_idx][i][j] <<= 1;
-
s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_idx][i],
-  s->dest[dst_idx] + off,
-  i & 4 ? s->uvlinesize
-: s->linesize);
-if (v->pq >= 9 && v->overlap) {
-if (v->c_avail)
-v->vc1dsp.vc1_h_overlap(s->dest[dst_idx] + off, i 
& 4 ? s->uvlinesize : s->linesize);
-if (v->a_avail)
-v->vc1dsp.vc1_v_overlap(s->dest[dst_idx] + off, i 
& 4 ? s->uvlinesize : s->linesize);
-}
 block_cbp   |= 0xF << (i << 2);
 block_intra |= 1 << i;
 } else if (val) {
@@ -1439,16 +1429,6 @@ static int vc1_decode_p_mb(VC1Context *v)
 if (v->rangeredfrm)
 for (j = 0; j < 64; j++)
 v->block[v->cur_blk_idx][i][j] <<= 1;
-
s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_idx][i],
-  s->dest[dst_idx] + off,
-  (i & 4) ? s->uvlinesize
-  : s->linesize);
-if (v->pq >= 9 && v->overlap) {
-if (v->c_avail)
-v->vc1dsp.vc1_h_overlap(s->dest[dst_idx] + off, i 
& 4 ? s->uvlinesize : s->linesize);
-if (v->a_avail)
-v->vc1dsp.vc1_v_overlap(s->dest[dst_idx] + off, i 
& 4 ? s->uvlinesize : s->linesize);
-}
 block_cbp   |= 0xF << (i << 2);
 block_intra |= 1 << i;
 } else if (is_coded[i]) {
@@ -1479,6 +1459,10 @@ static int vc1_decode_p_mb(VC1Context *v)
 }
 }
 end:
+if (v->overlap && v->pq >= 9)
+ff_vc1_p_overlap_filter(v);
+vc1_put_signed_blocks_clamped(v);
+
 v->cbp[s->mb_x]  = block_cbp;
 v->ttblk[s->mb_x]= block_tt;
 v->is_intra[s->mb_x] = block_intra;
@@ -1506,7 +1490,7 @@ static int vc1_decode_p_mb_intfr(VC1Context *v)
 int skipped, fourmv = 0, twomv = 0;
 int block_cbp = 0, pat, block_tt = 0;
 int idx_mbmode = 0, mvbp;
-int stride_y, fieldtx;
+int fieldtx;
 
 mquant = v->pq; /* Lossy initialization */
 
@@ -1584,17 +1568,10 @@ static int vc1_decode_p_mb_intfr(VC1Context *v)
 if (CONFIG_GRAY && (i > 3) && (s->avctx->flags & 
AV_CODEC_FLAG_GRAY))
 continue;
 v->vc1dsp.vc1_inv_trans_8x8(v->block[v->cur_blk_idx][i]);
-if (i < 4) {
-stride_y = s->linesize << fieldtx;
+if (i < 4)
 off = (fieldtx) ? ((i & 1) * 8) + ((i & 2) >> 1) * 
s->linesize : (i & 1) * 8 + 4 * (i & 2) * s->linesize;
-} else {
-stride_y = s->uvlinesize;
+else
 off = 0;
-}
-s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_idx][i],
-  s->dest[dst_idx] + off,
-  stride_y);
-//TODO: loop filter
 block_cbp |= 0xf << (i << 2);
 }
 
@@ -1693,6 +1670,10 @@ static int vc1_decode_p_mb_intfr(VC1Context *v)
 ff_vc1_mc_1mv(v, 0);
 v->fieldtx_plane[mb_pos] = 0;
 }
+if (v->overlap && v->pq >= 9)
+ff_vc1_p_overlap_filter(v);
+vc1_put_signed_blocks_clamped(v);
+
 v->cbp[s->mb_x]  = block_cbp;
 v->ttblk[s->mb_x]= block_tt;
 
@@ -1754,11 +1735,6 @@ static int vc1_decode_p_mb_intfi(VC1Context *v)
 continue;
 v->vc1dsp.vc1_inv_trans_8x8(v->block[v->cur_blk_idx][i]);
 off  = (i & 4) ? 0 : ((i & 1) * 8 + (i & 2) * 4 * s->linesize);
-s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_

[FFmpeg-devel] [PATCH 13/14] avcodec/vc1: correct AC inverse quantization scaling

[Jerome Borsboom]

HALFQP should only be added to the inverse quantizer when the block is
coded with PQUANT. See 8.1.3.8 in VC-1 spec.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 7d6d5c781c..af40fbd21d 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -944,7 +944,7 @@ static int vc1_decode_intra_block(VC1Context *v, int16_t 
block[64], int n,
 ac_val = s->ac_val[0][0] + s->block_index[n] * 16;
 ac_val2 = ac_val;
 
-scale = mquant * 2 + v->halfpq;
+scale = mquant * 2 + ((mquant == v->pq) ? v->halfpq : 0);
 
 if (dc_pred_dir) //left
 ac_val -= 16;
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 09/14] avcodec/vc1: re-implement vc1_put_signed_blocks_clamped

[Jerome Borsboom]

The existing implementation only used vc1_put_signed_blocks_clamped for I and
BI frames. This rewritten version is also applicable to P frame both
progressive and frame/field-interlace.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_block.c | 116 -
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index f641a011f2..f2f5c7f88b 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -69,70 +69,70 @@ static inline void init_block_index(VC1Context *v)
 static void vc1_put_signed_blocks_clamped(VC1Context *v)
 {
 MpegEncContext *s = &v->s;
-int topleft_mb_pos, top_mb_pos;
-int stride_y, fieldtx = 0;
-int v_dist;
-
-/* The put pixels loop is always one MB row behind the decoding loop,
- * because we can only put pixels when overlap filtering is done, and
- * for filtering of the bottom edge of a MB, we need the next MB row
- * present as well.
- * Within the row, the put pixels loop is also one MB col behind the
- * decoding loop. The reason for this is again, because for filtering
- * of the right MB edge, we need the next MB present. */
-if (!s->first_slice_line) {
+uint8_t *dest;
+int block_count = CONFIG_GRAY && (s->avctx->flags & AV_CODEC_FLAG_GRAY) ? 
4 : 6;
+int fieldtx = 0;
+int i;
+
+/* The put pixels loop is one MB row and one MB column behind the decoding
+ * loop because we can only put pixels when overlap filtering is done. For
+ * interlaced frame pictures, however, the put pixels loop is only one
+ * column behind the decoding loop as interlaced frame pictures only need
+ * horizontal overlap filtering. */
+if (!s->first_slice_line && v->fcm != ILACE_FRAME) {
+if (s->mb_x) {
+for (i = 0; i < block_count; i++) {
+if (i > 3 ? v->mb_type[0][s->block_index[i] - s->block_wrap[i] 
- 1] :
+v->mb_type[0][s->block_index[i] - 2 * 
s->block_wrap[i] - 2]) {
+dest = s->dest[0] + ((i & 2) - 4) * 4 * s->linesize + ((i 
& 1) - 2) * 8;
+
s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][i],
+  i > 3 ? s->dest[i - 3] - 
8 * s->uvlinesize - 8 : dest,
+  i > 3 ? s->uvlinesize : 
s->linesize);
+}
+}
+}
+if (s->mb_x == s->mb_width - 1) {
+for (i = 0; i < block_count; i++) {
+if (i > 3 ? v->mb_type[0][s->block_index[i] - 
s->block_wrap[i]] :
+v->mb_type[0][s->block_index[i] - 2 * 
s->block_wrap[i]]) {
+dest = s->dest[0] + ((i & 2) - 4) * 4 * s->linesize + (i & 
1) * 8;
+
s->idsp.put_signed_pixels_clamped(v->block[v->top_blk_idx][i],
+  i > 3 ? s->dest[i - 3] - 
8 * s->uvlinesize : dest,
+  i > 3 ? s->uvlinesize : 
s->linesize);
+}
+}
+}
+}
+if (s->mb_y == s->end_mb_y - 1 || v->fcm == ILACE_FRAME) {
 if (s->mb_x) {
-topleft_mb_pos = (s->mb_y - 1) * s->mb_stride + s->mb_x - 1;
 if (v->fcm == ILACE_FRAME)
-fieldtx = v->fieldtx_plane[topleft_mb_pos];
-stride_y   = s->linesize << fieldtx;
-v_dist = (16 - fieldtx) >> (fieldtx == 0);
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][0],
-  s->dest[0] - 16 * s->linesize - 
16,
-  stride_y);
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][1],
-  s->dest[0] - 16 * s->linesize - 
8,
-  stride_y);
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][2],
-  s->dest[0] - v_dist * 
s->linesize - 16,
-  stride_y);
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][3],
-  s->dest[0] - v_dist * 
s->linesize - 8,
-  stride_y);
-if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][4],
-  s->dest[1] - 8 * s->uvlinesize - 
8,
-  s->uvlinesize);
-s->idsp.put_signed_pixels_clamped(v->block[v->topleft_blk_idx][5],
-  s->dest[2] - 8 * s->uvlinesize - 
8,
-  s->uvlinesize);
+ 

[FFmpeg-devel] [PATCH 08/14] avcodec/vc1: implement interlaced out-of-bounds reference pixel replication

[Jerome Borsboom]

The existing implementation did out-of-bounds reference pixel replication for
progressive reference frames. In interlaced reference frames both the even and
odd line on the horizontal edges need to be replicated.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_mc.c | 376 +---
 tests/ref/fate/vc1_ilaced_twomv |  18 +-
 2 files changed, 318 insertions(+), 76 deletions(-)

diff --git a/libavcodec/vc1_mc.c b/libavcodec/vc1_mc.c
index 5eacaaa8ee..04b359204c 100644
--- a/libavcodec/vc1_mc.c
+++ b/libavcodec/vc1_mc.c
@@ -254,9 +254,14 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
 uvsrc_y = av_clip(uvsrc_y,  -8, s->mb_height *  8);
 } else {
 src_x   = av_clip(  src_x, -17, s->avctx->coded_width);
-src_y   = av_clip(  src_y, -18, s->avctx->coded_height + 1);
 uvsrc_x = av_clip(uvsrc_x,  -8, s->avctx->coded_width  >> 1);
-uvsrc_y = av_clip(uvsrc_y,  -8, s->avctx->coded_height >> 1);
+if (v->fcm == ILACE_FRAME) {
+src_y = av_clip(src_y, -18 + (src_y & 1), s->avctx->coded_height + 
(src_y & 1));
+uvsrc_y = av_clip(uvsrc_y, -8 + (uvsrc_y & 1), 
(s->avctx->coded_height >> 1) + (uvsrc_y & 1));
+} else {
+src_y = av_clip(src_y, -18, s->avctx->coded_height + 1);
+uvsrc_y = av_clip(uvsrc_y, -8, s->avctx->coded_height >> 1);
+}
 }
 
 srcY += src_y   * s->linesize   + src_x;
@@ -284,22 +289,113 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
 const int k = 17 + s->mspel * 2;
 
 srcY -= s->mspel * (1 + s->linesize);
-s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer, srcY,
- s->linesize, s->linesize,
- k, k,
- src_x - s->mspel, src_y - s->mspel,
- s->h_edge_pos, v_edge_pos);
+if (v->fcm == ILACE_FRAME) {
+if (src_y - s->mspel & 1) {
+s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer,
+ srcY,
+ 2 * s->linesize,
+ 2 * s->linesize,
+ k,
+ k + 1 >> 1,
+ src_x - s->mspel,
+ src_y - s->mspel >> 1,
+ s->h_edge_pos,
+ v_edge_pos + 1 >> 1);
+s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer + s->linesize,
+ srcY + s->linesize,
+ 2 * s->linesize,
+ 2 * s->linesize,
+ k,
+ k >> 1,
+ src_x - s->mspel,
+ src_y - s->mspel + 1 >> 1,
+ s->h_edge_pos,
+ v_edge_pos >> 1);
+} else {
+s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer,
+ srcY,
+ 2 * s->linesize,
+ 2 * s->linesize,
+ k,
+ k + 1 >> 1,
+ src_x - s->mspel,
+ src_y - s->mspel >> 1,
+ s->h_edge_pos,
+ v_edge_pos >> 1);
+s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer + s->linesize,
+ srcY + s->linesize,
+ 2 * s->linesize,
+ 2 * s->linesize,
+ k,
+ k >> 1,
+ src_x - s->mspel,
+ src_y - s->mspel + 1 >> 1,
+ s->h_edge_pos,
+ v_edge_pos + 1 >> 1);
+}
+} else
+s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer, srcY,
+ s->linesize, s->linesize,
+ k, k,
+ src_x - s->mspel, src_y - s->mspel,
+ s->h_edge_pos, v_edge_pos);
 srcY = s->sc.edge_emu_buffer;
-s->vdsp.emulated_edge_mc(ubuf, srcU,
- s->uvlinesize, s->uvlinesize,
- 8 + 1, 8 + 1,
- uvsrc_x, uvsrc_y,
- s->h_edge_

[FFmpeg-devel] [PATCH 07/14] avcodec/vc1: correct ff_vc1_dqscale

[Jerome Borsboom]

According to VC-1 spec table 74, the last value in ff_vc1_dqscale should be
0x1041 instead of 0x1000.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc1data.c b/libavcodec/vc1data.c
index 0df7d4d666..19f1cad45f 100644
--- a/libavcodec/vc1data.c
+++ b/libavcodec/vc1data.c
@@ -1090,7 +1090,7 @@ const int32_t ff_vc1_dqscale[63] = {
  0x1F08,  0x1E1E,  0x1D42,  0x1C72, 0x1BAD, 0x1AF3, 0x1A42, 0x199A,
  0x18FA,  0x1862,  0x17D0,  0x1746, 0x16C1, 0x1643, 0x15CA, 0x1555,
  0x14E6,  0x147B,  0x1414,  0x13B1, 0x1352, 0x12F7, 0x129E, 0x1249,
- 0x11F7,  0x11A8,  0x115B,  0x, 0x10C9, 0x1084, 0x1000
+ 0x11F7,  0x11A8,  0x115B,  0x, 0x10C9, 0x1084, 0x1041
 };
 
 /* P Interlaced field picture MV predictor scaling values (Table 114) */
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 06/14] avcodec/vc1: correct ff_vc1_mbmode_intfrp

[Jerome Borsboom]

According to VC-1 spec 10.7.3.4, FIELDTX shall be set to the same type as the
motion vector for zero-coded blocks.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1data.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vc1data.c b/libavcodec/vc1data.c
index fc9ba6da13..0df7d4d666 100644
--- a/libavcodec/vc1data.c
+++ b/libavcodec/vc1data.c
@@ -61,7 +61,7 @@ const uint8_t ff_vc1_mbmode_intfrp[2][15][4] = {
 { MV_PMODE_INTFR_1MV  , 1, 0, 1 },
 { MV_PMODE_INTFR_2MV_FIELD, 0, 0, 1 },
 { MV_PMODE_INTFR_2MV_FIELD, 1, 0, 1 },
-{ MV_PMODE_INTFR_2MV_FIELD, 0, 0, 0 },
+{ MV_PMODE_INTFR_2MV_FIELD, 1, 0, 0 },
 { MV_PMODE_INTFR_INTRA, 0, 0, 0 }
 },
 {
@@ -73,13 +73,13 @@ const uint8_t ff_vc1_mbmode_intfrp[2][15][4] = {
 { MV_PMODE_INTFR_1MV  , 1, 0, 1 },
 { MV_PMODE_INTFR_2MV_FIELD, 0, 0, 1 },
 { MV_PMODE_INTFR_2MV_FIELD, 1, 0, 1 },
-{ MV_PMODE_INTFR_2MV_FIELD, 0, 0, 0 },
+{ MV_PMODE_INTFR_2MV_FIELD, 1, 0, 0 },
 { MV_PMODE_INTFR_4MV  , 0, 0, 1 },
 { MV_PMODE_INTFR_4MV  , 1, 0, 1 },
 { MV_PMODE_INTFR_4MV  , 0, 0, 0 },
 { MV_PMODE_INTFR_4MV_FIELD, 0, 0, 1 },
 { MV_PMODE_INTFR_4MV_FIELD, 1, 0, 1 },
-{ MV_PMODE_INTFR_4MV_FIELD, 0, 0, 0 },
+{ MV_PMODE_INTFR_4MV_FIELD, 1, 0, 0 },
 { MV_PMODE_INTFR_INTRA, 0, 0, 0 }
 }
 };
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 04/14] avcodec/vc1: store additional bitstream elements during MB decoding

[Jerome Borsboom]

The new loop filter needs additional MB properties to make its filtering
decisions.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_block.c | 58 +-
 libavcodec/vc1dec.c| 16 +++---
 2 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 1c3577796e..f641a011f2 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -1595,6 +1595,7 @@ static int vc1_decode_p_mb_intfr(VC1Context *v)
   s->dest[dst_idx] + off,
   stride_y);
 //TODO: loop filter
+block_cbp |= 0xf << (i << 2);
 }
 
 } else { // inter MB
@@ -1690,9 +1691,11 @@ static int vc1_decode_p_mb_intfr(VC1Context *v)
 v->blk_mv_type[s->block_index[3]] = 0;
 ff_vc1_pred_mv_intfr(v, 0, 0, 0, 1, v->range_x, v->range_y, 
v->mb_type[0], 0);
 ff_vc1_mc_1mv(v, 0);
+v->fieldtx_plane[mb_pos] = 0;
 }
-if (s->mb_x == s->mb_width - 1)
-memmove(v->is_intra_base, v->is_intra, 
sizeof(v->is_intra_base[0])*s->mb_stride);
+v->cbp[s->mb_x]  = block_cbp;
+v->ttblk[s->mb_x]= block_tt;
+
 return 0;
 }
 
@@ -1756,6 +1759,7 @@ static int vc1_decode_p_mb_intfi(VC1Context *v)
   (i & 4) ? s->uvlinesize
   : s->linesize);
 // TODO: loop filter
+block_cbp |= 0xf << (i << 2);
 }
 } else {
 s->mb_intra = v->is_intra[s->mb_x] = 0;
@@ -1810,8 +1814,9 @@ static int vc1_decode_p_mb_intfi(VC1Context *v)
 }
 }
 }
-if (s->mb_x == s->mb_width - 1)
-memmove(v->is_intra_base, v->is_intra, sizeof(v->is_intra_base[0]) * 
s->mb_stride);
+v->cbp[s->mb_x]  = block_cbp;
+v->ttblk[s->mb_x]= block_tt;
+
 return 0;
 }
 
@@ -1988,6 +1993,7 @@ static void vc1_decode_b_mb_intfi(VC1Context *v)
 int fwd;
 int dmv_x[2], dmv_y[2], pred_flag[2];
 int bmvtype = BMV_TYPE_BACKWARD;
+int block_cbp = 0, pat, block_tt = 0;
 int idx_mbmode;
 
 mquant  = v->pq; /* Lossy initialization */
@@ -2118,16 +2124,19 @@ static void vc1_decode_b_mb_intfi(VC1Context *v)
 val = ((cbp >> (5 - i)) & 1);
 off = (i & 4) ? 0 : (i & 1) * 8 + (i & 2) * 4 * s->linesize;
 if (val) {
-vc1_decode_p_block(v, s->block[i], i, mquant, ttmb,
-   first_block, s->dest[dst_idx] + off,
-   (i & 4) ? s->uvlinesize : s->linesize,
-   CONFIG_GRAY && (i & 4) && (s->avctx->flags 
& AV_CODEC_FLAG_GRAY), NULL);
+pat = vc1_decode_p_block(v, s->block[i], i, mquant, ttmb,
+ first_block, s->dest[dst_idx] + off,
+ (i & 4) ? s->uvlinesize : s->linesize,
+ CONFIG_GRAY && (i & 4) && 
(s->avctx->flags & AV_CODEC_FLAG_GRAY), &block_tt);
+block_cbp |= pat << (i << 2);
 if (!v->ttmbf && ttmb < 8)
 ttmb = -1;
 first_block = 0;
 }
 }
 }
+v->cbp[s->mb_x]  = block_cbp;
+v->ttblk[s->mb_x]= block_tt;
 }
 
 /** Decode one B-frame MB (in interlaced frame B picture)
@@ -2468,12 +2477,12 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
 if (direct || bmvtype == BMV_TYPE_INTERPOLATED) {
 ff_vc1_interp_mc(v);
 }
+v->fieldtx_plane[mb_pos] = 0;
 }
 }
-if (s->mb_x == s->mb_width - 1)
-memmove(v->is_intra_base, v->is_intra, sizeof(v->is_intra_base[0]) * 
s->mb_stride);
 v->cbp[s->mb_x]  = block_cbp;
 v->ttblk[s->mb_x]= block_tt;
+
 return 0;
 }
 
@@ -2703,6 +2712,8 @@ static void vc1_decode_i_blocks_adv(VC1Context *v)
 s->c_dc_scale = s->c_dc_scale_table[mquant];
 
 for (k = 0; k < 6; k++) {
+v->mb_type[0][s->block_index[k]] = 1;
+
 val = ((cbp >> (5 - k)) & 1);
 
 if (k < 4) {
@@ -2799,7 +2810,7 @@ static void vc1_decode_p_blocks(VC1Context *v)
 apply_loop_filter   = s->loop_filter && !(s->avctx->skip_loop_filter >= 
AVDISCARD_NONKEY) &&
   v->fcm == PROGRESSIVE;
 s->first_slice_line = 1;
-memset(v->cbp_base, 0, sizeof(v->cbp_base[0])*2*s->mb_stride);
+memset(v->cbp_base, 0, sizeof(v->cbp_base[0]) * 3 * s->mb_stride);
 for (s->mb_y = s->start_mb_y; s->mb_y < s->end_mb_y; s->mb_y++) {
 s->mb_x = 0;
 init_block_index(v);
@@ -2825,10 +2836,18 @@ static void vc1_decode_p_blocks(VC1Context *v)
 inc_blk_idx(v->left_blk_idx);
 inc_blk_idx(v->cur_blk_idx);
 }
-memmove(v->cb

[FFmpeg-devel] [PATCH 05/14] avcodec/vc1: store color-difference reference field type

[Jerome Borsboom]

The loop filter for P interlace field pictures needs the reference field type.
For luma, the reference field type was already available. Store the reference
field type for color-difference as well.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_mc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/vc1_mc.c b/libavcodec/vc1_mc.c
index 75c74cad8d..5eacaaa8ee 100644
--- a/libavcodec/vc1_mc.c
+++ b/libavcodec/vc1_mc.c
@@ -344,6 +344,10 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
 v->vc1dsp.put_no_rnd_vc1_chroma_pixels_tab[0](s->dest[1], srcU, 
s->uvlinesize, 8, uvmx, uvmy);
 v->vc1dsp.put_no_rnd_vc1_chroma_pixels_tab[0](s->dest[2], srcV, 
s->uvlinesize, 8, uvmx, uvmy);
 }
+if (v->field_mode) {
+v->mv_f[dir][s->block_index[4] + v->mb_off] = v->cur_field_type != 
v->ref_field_type[dir];
+v->mv_f[dir][s->block_index[5] + v->mb_off] = v->cur_field_type != 
v->ref_field_type[dir];
+}
 }
 
 /** Do motion compensation for 4-MV macroblock - luminance block
@@ -636,6 +640,10 @@ void ff_vc1_mc_4mv_chroma(VC1Context *v, int dir)
 v->vc1dsp.put_no_rnd_vc1_chroma_pixels_tab[0](s->dest[1], srcU, 
s->uvlinesize, 8, uvmx, uvmy);
 v->vc1dsp.put_no_rnd_vc1_chroma_pixels_tab[0](s->dest[2], srcV, 
s->uvlinesize, 8, uvmx, uvmy);
 }
+if (v->field_mode) {
+v->mv_f[dir][s->block_index[4] + v->mb_off] = v->cur_field_type != 
chroma_ref_type;
+v->mv_f[dir][s->block_index[5] + v->mb_off] = v->cur_field_type != 
chroma_ref_type;
+}
 }
 
 /** Do motion compensation for 4-MV interlaced frame chroma macroblock (both U 
and V)
-- 
2.13.6


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

[FFmpeg-devel] [PATCH 03/14] avcodec/vc1: re-implement and expand VC-1 loop filtering

[Jerome Borsboom]

The existing implementation did loop filtering for progressive
frames only. This rewritten version implements loop filtering for
all applicable frame types for both progessive and
frame/field-interlace.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1.h|4 +
 libavcodec/vc1_loopfilter.c | 1042 +++
 2 files changed, 1046 insertions(+)

diff --git a/libavcodec/vc1.h b/libavcodec/vc1.h
index 85504c2f9f..0dfdef78cd 100644
--- a/libavcodec/vc1.h
+++ b/libavcodec/vc1.h
@@ -428,6 +428,10 @@ void ff_vc1_smooth_overlap_filter_iblk(VC1Context *v);
 void ff_vc1_i_overlap_filter(VC1Context *v);
 void ff_vc1_p_overlap_filter(VC1Context *v);
 void ff_vc1_apply_p_loop_filter(VC1Context *v);
+void ff_vc1_i_loop_filter(VC1Context *v);
+void ff_vc1_p_loop_filter(VC1Context *v);
+void ff_vc1_p_intfr_loop_filter(VC1Context *v);
+void ff_vc1_b_intfi_loop_filter(VC1Context *v);
 
 void ff_vc1_mc_1mv(VC1Context *v, int dir);
 void ff_vc1_mc_4mv_luma(VC1Context *v, int n, int dir, int avg);
diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c
index 3122b1a258..7ef0fd1ea2 100644
--- a/libavcodec/vc1_loopfilter.c
+++ b/libavcodec/vc1_loopfilter.c
@@ -451,3 +451,1045 @@ void ff_vc1_apply_p_loop_filter(VC1Context *v)
 }
 }
 }
+
+#define LEFT_EDGE   (1 << 0)
+#define RIGHT_EDGE  (1 << 1)
+#define TOP_EDGE(1 << 2)
+#define BOTTOM_EDGE (1 << 3)
+
+static av_always_inline void vc1_i_h_loop_filter(VC1Context *v, uint8_t *dest,
+ uint32_t flags, int block_num)
+{
+MpegEncContext *s  = &v->s;
+int pq = v->pq;
+uint8_t *dst;
+
+if (block_num & 2)
+return;
+
+if (!(flags & LEFT_EDGE) || (block_num & 5) == 1) {
+if (block_num > 3)
+dst = dest;
+else
+dst = dest + (block_num & 2) * 4 * s->linesize + (block_num & 1) * 
8;
+
+if (v->fcm == ILACE_FRAME)
+if (block_num > 3) {
+v->vc1dsp.vc1_h_loop_filter4(dst, 2 * s->uvlinesize, pq);
+v->vc1dsp.vc1_h_loop_filter4(dst + s->uvlinesize, 2 * 
s->uvlinesize, pq);
+} else {
+v->vc1dsp.vc1_h_loop_filter8(dst, 2 * s->linesize, pq);
+v->vc1dsp.vc1_h_loop_filter8(dst + s->linesize, 2 * 
s->linesize, pq);
+}
+else
+if (block_num > 3)
+v->vc1dsp.vc1_h_loop_filter8(dst, s->uvlinesize, pq);
+else
+v->vc1dsp.vc1_h_loop_filter16(dst, s->linesize, pq);
+}
+}
+
+static av_always_inline void vc1_i_v_loop_filter(VC1Context *v, uint8_t *dest,
+ uint32_t flags, uint8_t 
fieldtx,
+ int block_num)
+{
+MpegEncContext *s  = &v->s;
+int pq = v->pq;
+uint8_t *dst;
+
+if ((block_num & 5) == 1)
+return;
+
+if (!(flags & TOP_EDGE) || block_num & 2) {
+if (block_num > 3)
+dst = dest;
+else
+dst = dest + (block_num & 2) * 4 * s->linesize + (block_num & 1) * 
8;
+
+if (v->fcm == ILACE_FRAME) {
+if (block_num > 3) {
+v->vc1dsp.vc1_v_loop_filter8(dst, 2 * s->uvlinesize, pq);
+v->vc1dsp.vc1_v_loop_filter8(dst + s->uvlinesize, 2 * 
s->uvlinesize, pq);
+} else if (block_num < 2 || !fieldtx) {
+v->vc1dsp.vc1_v_loop_filter16(dst, 2 * s->linesize, pq);
+v->vc1dsp.vc1_v_loop_filter16(dst + s->linesize, 2 * 
s->linesize, pq);
+}
+} else
+if (block_num > 3)
+v->vc1dsp.vc1_v_loop_filter8(dst, s->uvlinesize, pq);
+else
+v->vc1dsp.vc1_v_loop_filter16(dst, s->linesize, pq);
+}
+}
+
+void ff_vc1_i_loop_filter(VC1Context *v)
+{
+MpegEncContext *s = &v->s;
+int block_count = CONFIG_GRAY && (s->avctx->flags & AV_CODEC_FLAG_GRAY) ? 
4 : 6;
+int mb_pos = s->mb_x + s->mb_y * s->mb_stride;
+uint8_t *dest, fieldtx;
+uint32_t flags = 0;
+int i;
+
+/* Within a MB, the vertical loop filter always runs before the horizontal.
+ * To accomplish that, we run the V loop filter on top and internal
+ * horizontal borders of the last overlap filtered MB. Then, we wait for
+ * the loop filter iteration on the next row to do V loop filter on the
+ * bottom edge of this MB, before moving over and running the H loop
+ * filter on the left and internal vertical borders. Therefore, the loop
+ * filter trails by one row and one column relative to the overlap filter
+ * and two rows and two colums relative to the decoding loop. */
+if (!s->first_slice_line) {
+dest = s->dest[0] - 16 * s->linesize - 16;
+flags = s->mb_y == s->start_mb_y + 1 ? TOP_EDGE : 0;
+if (s->mb_x) {
+fieldtx = v->fieldtx_plane[mb_pos - s->mb_stride - 1];
+for (i = 0; i < block_count; i

Re: [FFmpeg-devel] [PATCH] avcodec/vaapi: do not parse MVMODE for VC-1 interlaced frame pictures

[Jerome Borsboom]

On 29-3-2018 13:43, Jerome Borsboom wrote:
> Interlaced frame pictures do not contain the MVMODE or MVMODE2 bitstream
> element. Trying to parse this element and passing a nonzero value to the
> hardware decoder results in small inaccuracies in the decoded picture.
> 
> Signed-off-by: Jerome Borsboom 
> ---
> With this patch the Intel hardware decoded fate test for ilaced_twomv.vc1
> perfectly matches the output from the Microsoft software decoder.
> 
>  libavcodec/vaapi_vc1.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
> index 74ba783141..bdb5e24cc5 100644
> --- a/libavcodec/vaapi_vc1.c
> +++ b/libavcodec/vaapi_vc1.c
> @@ -138,8 +138,9 @@ static int vc1_get_FPTYPE(const VC1Context *v)
>  /** Reconstruct bitstream MVMODE (7.1.1.32) */
>  static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context *v)
>  {
> -if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
> -(v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type))
> +if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
> +((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
> + (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type)))
>  return get_VAMvModeVC1(v->mv_mode);
>  return 0;
>  }
> @@ -147,7 +148,8 @@ static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context 
> *v)
>  /** Reconstruct bitstream MVMODE2 (7.1.1.33) */
>  static inline VAMvModeVC1 vc1_get_MVMODE2(const VC1Context *v)
>  {
> -if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
> +if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
> +(v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
>  v->mv_mode == MV_PMODE_INTENSITY_COMP)
>  return get_VAMvModeVC1(v->mv_mode2);
>  return 0;
> -- 
> 2.13.6

Could someone please have a look at this patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 02/14] avcodec/vc1: change to using v->block instead of s->block for P frames

[Jerome Borsboom]

The new overlap smooting filter smoothes image pixels stored in v->block.
Switch to v->block instead of s->block for storing decoded image pixels for P
frames. Additionally, we must take incrementing *_blk_idx out of the
vc1_put_signed_blocks_clamped function.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_block.c | 55 --
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index f9f26f7e42..1c3577796e 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -136,6 +136,7 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
 }
 }
 }
+}
 
 #define inc_blk_idx(idx) do { \
 idx++; \
@@ -143,12 +144,6 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
 idx = 0; \
 } while (0)
 
-inc_blk_idx(v->topleft_blk_idx);
-inc_blk_idx(v->top_blk_idx);
-inc_blk_idx(v->left_blk_idx);
-inc_blk_idx(v->cur_blk_idx);
-}
-
 /***/
 /**
  * @name VC-1 Block-level functions
@@ -1325,15 +1320,15 @@ static int vc1_decode_p_mb(VC1Context *v)
 if (i == 1 || i == 3 || s->mb_x)
 v->c_avail = v->mb_type[0][s->block_index[i] - 1];
 
-vc1_decode_intra_block(v, s->block[i], i, val, mquant,
+vc1_decode_intra_block(v, v->block[v->cur_blk_idx][i], i, 
val, mquant,
(i & 4) ? v->codingset2 : 
v->codingset);
 if (CONFIG_GRAY && (i > 3) && (s->avctx->flags & 
AV_CODEC_FLAG_GRAY))
 continue;
-v->vc1dsp.vc1_inv_trans_8x8(s->block[i]);
+v->vc1dsp.vc1_inv_trans_8x8(v->block[v->cur_blk_idx][i]);
 if (v->rangeredfrm)
 for (j = 0; j < 64; j++)
-s->block[i][j] <<= 1;
-s->idsp.put_signed_pixels_clamped(s->block[i],
+v->block[v->cur_blk_idx][i][j] <<= 1;
+
s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_idx][i],
   s->dest[dst_idx] + off,
   i & 4 ? s->uvlinesize
 : s->linesize);
@@ -1346,7 +1341,7 @@ static int vc1_decode_p_mb(VC1Context *v)
 block_cbp   |= 0xF << (i << 2);
 block_intra |= 1 << i;
 } else if (val) {
-pat = vc1_decode_p_block(v, s->block[i], i, mquant, ttmb, 
first_block,
+pat = vc1_decode_p_block(v, v->block[v->cur_blk_idx][i], 
i, mquant, ttmb, first_block,
  s->dest[dst_idx] + off, (i & 4) ? 
s->uvlinesize : s->linesize,
  CONFIG_GRAY && (i & 4) && 
(s->avctx->flags & AV_CODEC_FLAG_GRAY), &block_tt);
 block_cbp |= pat << (i << 2);
@@ -1436,15 +1431,15 @@ static int vc1_decode_p_mb(VC1Context *v)
 if (i == 1 || i == 3 || s->mb_x)
 v->c_avail = v->mb_type[0][s->block_index[i] - 1];
 
-vc1_decode_intra_block(v, s->block[i], i, is_coded[i], 
mquant,
+vc1_decode_intra_block(v, v->block[v->cur_blk_idx][i], i, 
is_coded[i], mquant,
(i & 4) ? v->codingset2 : 
v->codingset);
 if (CONFIG_GRAY && (i > 3) && (s->avctx->flags & 
AV_CODEC_FLAG_GRAY))
 continue;
-v->vc1dsp.vc1_inv_trans_8x8(s->block[i]);
+v->vc1dsp.vc1_inv_trans_8x8(v->block[v->cur_blk_idx][i]);
 if (v->rangeredfrm)
 for (j = 0; j < 64; j++)
-s->block[i][j] <<= 1;
-s->idsp.put_signed_pixels_clamped(s->block[i],
+v->block[v->cur_blk_idx][i][j] <<= 1;
+
s->idsp.put_signed_pixels_clamped(v->block[v->cur_blk_idx][i],
   s->dest[dst_idx] + off,
   (i & 4) ? s->uvlinesize
   : s->linesize);
@@ -1457,7 +1452,7 @@ static int vc1_decode_p_mb(VC1Context *v)
 block_cbp   |= 0xF << (i << 2);
 block_intra |= 1 << i;
 } else if (is_coded[i]) {
-pat = vc1_decode_p_block(v, s->block[i], i, mquant, ttmb,
+pat = vc1_decode_p_block(v, v->block[v->cur_blk_idx][i], 
i, mquant, ttmb,
  first_block, s->dest[dst_idx] + 
off,
  (i & 4) ? s->uvl

[FFmpeg-devel] [PATCH 01/14] avcodec/vc1: re-implement and expand VC-1 overlap smooting

[Jerome Borsboom]

The existing implementation did overlap smoothing for progressive
frames only. This rewritten version implements overlap smoothing
for all applicable frame types for both progessive and
frame/field-interlace.

Signed-off-by: Jerome Borsboom 
---
This patch-set improves the VC-1 software decoder to the point where the fate
checksums are equal to checksums from the Intel hardware decoded image on 
Haswell.

 libavcodec/vc1.h|  2 +
 libavcodec/vc1_loopfilter.c | 94 +
 2 files changed, 96 insertions(+)

diff --git a/libavcodec/vc1.h b/libavcodec/vc1.h
index 8fc0729cb8..85504c2f9f 100644
--- a/libavcodec/vc1.h
+++ b/libavcodec/vc1.h
@@ -425,6 +425,8 @@ void ff_vc1_decode_blocks(VC1Context *v);
 void ff_vc1_loop_filter_iblk(VC1Context *v, int pq);
 void ff_vc1_loop_filter_iblk_delayed(VC1Context *v, int pq);
 void ff_vc1_smooth_overlap_filter_iblk(VC1Context *v);
+void ff_vc1_i_overlap_filter(VC1Context *v);
+void ff_vc1_p_overlap_filter(VC1Context *v);
 void ff_vc1_apply_p_loop_filter(VC1Context *v);
 
 void ff_vc1_mc_1mv(VC1Context *v, int dir);
diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c
index 025776bac9..3122b1a258 100644
--- a/libavcodec/vc1_loopfilter.c
+++ b/libavcodec/vc1_loopfilter.c
@@ -208,6 +208,100 @@ void ff_vc1_smooth_overlap_filter_iblk(VC1Context *v)
 }
 }
 
+static av_always_inline void vc1_h_overlap_filter(VC1Context *v, int16_t 
(*left_block)[64],
+  int16_t (*right_block)[64], 
int block_num)
+{
+if (left_block != right_block || (block_num & 5) == 1) {
+if (block_num > 3)
+v->vc1dsp.vc1_h_s_overlap(left_block[block_num], 
right_block[block_num]);
+else if (block_num & 1)
+v->vc1dsp.vc1_h_s_overlap(right_block[block_num - 1], 
right_block[block_num]);
+else
+v->vc1dsp.vc1_h_s_overlap(left_block[block_num + 1], 
right_block[block_num]);
+}
+}
+
+static av_always_inline void vc1_v_overlap_filter(VC1Context *v, int16_t 
(*top_block)[64],
+  int16_t (*bottom_block)[64], 
int block_num)
+{
+if (top_block != bottom_block || block_num & 2) {
+if (block_num > 3)
+v->vc1dsp.vc1_v_s_overlap(top_block[block_num], 
bottom_block[block_num]);
+else if (block_num & 2)
+v->vc1dsp.vc1_v_s_overlap(bottom_block[block_num - 2], 
bottom_block[block_num]);
+else
+v->vc1dsp.vc1_v_s_overlap(top_block[block_num + 2], 
bottom_block[block_num]);
+}
+}
+
+void ff_vc1_i_overlap_filter(VC1Context *v)
+{
+MpegEncContext *s = &v->s;
+int16_t (*topleft_blk)[64], (*top_blk)[64], (*left_blk)[64], 
(*cur_blk)[64];
+int block_count = CONFIG_GRAY && (s->avctx->flags & AV_CODEC_FLAG_GRAY) ? 
4 : 6;
+int mb_pos = s->mb_x + s->mb_y * s->mb_stride;
+int i;
+
+topleft_blk = v->block[v->topleft_blk_idx];
+top_blk = v->block[v->top_blk_idx];
+left_blk = v->block[v->left_blk_idx];
+cur_blk = v->block[v->cur_blk_idx];
+
+/* Within a MB, the horizontal overlap always runs before the vertical.
+ * To accomplish that, we run the H on the left and internal vertical
+ * borders of the currently decoded MB. Then, we wait for the next overlap
+ * iteration to do H overlap on the right edge of this MB, before moving
+ * over and running the V overlap on the top and internal horizontal
+ * borders. Therefore, the H overlap trails by one MB col and the
+ * V overlap trails by one MB row. This is reflected in the time at which
+ * we run the put_pixels loop, i.e. delayed by one row and one column. */
+for (i = 0; i < block_count; i++)
+if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
+(v->over_flags_plane[mb_pos] && ((i & 5) == 1 || 
v->over_flags_plane[mb_pos - 1])))
+vc1_h_overlap_filter(v, s->mb_x ? left_blk : cur_blk, cur_blk, i);
+
+if (v->fcm != ILACE_FRAME)
+for (i = 0; i < block_count; i++) {
+if (s->mb_x && (v->pq >= 9 || v->condover == CONDOVER_ALL ||
+(v->over_flags_plane[mb_pos - 1] &&
+ ((i & 2) || v->over_flags_plane[mb_pos - 1 - s->mb_stride]
+vc1_v_overlap_filter(v, s->first_slice_line ? left_blk : 
topleft_blk, left_blk, i);
+if (s->mb_x == s->mb_width - 1)
+if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
+(v->over_flags_plane[mb_pos] &&
+ ((i & 2) || v->over_flags_plane[mb_pos - s->mb_stride])))
+vc1_v_overlap_filter(v, s->first_slice_line ? cur_blk : 
top_blk, cur_blk, i);
+}
+}
+
+void ff_vc1_p_overlap_filter(VC1Context *v)
+{
+MpegEncContext *s = &v->s;
+int16_t (*topleft_blk)[64], (*top_blk)[64], (*left_blk)[64], 
(*cur_blk)[64];
+int block_count = CONFIG_GRAY && (s->avctx->flags & AV_CODEC_FLAG_GRAY) ? 
4 : 6;
+int i;
+
+t

Re: [FFmpeg-devel] [V3 PATCH 1/3] Add muxing/demuxing of RMHD

[Thilo Borgmann]

Am 22.04.18 um 23:44 schrieb Paul B Mahol:
> On 4/22/18, Thilo Borgmann  wrote:
>> -Thilo
>>
> 
> To many changes, hard to track.

I assume this means you also prefer a more splitted patch?

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

Re: [FFmpeg-devel] [V2 PATCH 2/4] Add muxing/demuxing of RMHD

[Thilo Borgmann]

Am 23.04.18 um 14:17 schrieb Carl Eugen Hoyos:
> 2018-02-02 3:43 GMT+01:00, Thilo Borgmann :
>> Does not add a new demuxer anymore.
> 
> Good, now please split the patches, the demuxer patches
> look relatively easy to review.
> 
>> For the muxer I'm not sure it should be done - would require more logic to
>> check for valid codec ids for both cases I think (like for AAC audio).
> 
> Not sure I understand: Aren't all the functions identical for both muxers?
> 
> If easily avoidable, no new muxer should be added, Carl Eugen

Have you just answered to the wrong mail and your comments apply to [V3 PATCH 
1/3]?

If so, please elaborate your expectations about a better way to split things.

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

Re: [FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer

[Thilo Borgmann]

Am 23.04.18 um 03:36 schrieb James Almer:
> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
>> On 4/22/18, Thilo Borgmann  wrote:
>>> Hi,
>>>
>>> V3 drops the MLTI part, no idea how it survived
>>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
>>> Also dropped audio override, could not get a sample requiring it.
>>>
>>> Adapted to current HEAD.
>>
>> I'm strongly against applying this to our tree.
> 
> The de/muxing code can and should be applied as long as there are not
> technical limitations. They are native code and depend on nothing external.
> 
> And regarding the decoder and encoder wrappers, you need to explain the
> reasons for your hard NAK...

Yes Paul please do, and while you're on it, please add your thoughts about 
making it good enough for our tree that come to your mind. I assume it is not 
RV11 or its library wrapper for itself you don't like to see pushed...

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

Re: [FFmpeg-devel] [V3 PATCH 3/3] Add docs and Changelog

[Thilo Borgmann]

Am 23.04.18 um 14:18 schrieb Carl Eugen Hoyos:
> 2018-04-22 23:16 GMT+02:00, Thilo Borgmann :
> 
> Why is this a separate patch?

To make the git-work a bit easier - do you want it to be merged into the 
others, would it be sufficient to do that before pushing?

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

Re: [FFmpeg-devel] [V3 PATCH 2/3] Add codec wrapper for librv11

[Thilo Borgmann]

Am 23.04.18 um 14:21 schrieb Carl Eugen Hoyos:
> 2018-04-22 23:16 GMT+02:00, Thilo Borgmann :
> 
>> +#include 
> 
> Why is this include needed?

Not anymore, will remove locally.

-Thilo

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

Re: [FFmpeg-devel] [PATCHv2 3/4] avutil/pixdesc: add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8

[Marton Balint]

On Sun, 22 Apr 2018, wm4 wrote:


On Sun, 22 Apr 2018 13:24:11 +0200 (CEST)
Marton Balint  wrote:


On Fri, 20 Apr 2018, wm4 wrote:

> On Thu, 19 Apr 2018 23:25:03 +0200
> Marton Balint  wrote:
> 
>> Signed-off-by: Marton Balint 

>> ---
>>  doc/APIchanges| 3 +++
>>  libavutil/pixdesc.c   | 3 +--
>>  libavutil/pixdesc.h   | 8 ++--
>>  libavutil/tests/pixdesc.c | 4 
>>  libavutil/version.h   | 2 +-
>>  5 files changed, 7 insertions(+), 13 deletions(-)
>> 
>> diff --git a/doc/APIchanges b/doc/APIchanges

>> index 4f6ac2a031..d9b457e080 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>>
>>  API changes, most recent first:
>> 
>> +2018-04-xx - xx - lavu 56.16.100 - pixdesc.h

>> +  Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
>> + 


[..]

>
> Probably fine. While I like it, we also have to be careful about the
> consequences. Does it change FATE or the results of that pixfmt choosing
> function, avcodec_find_best_pix_fmt_of_list()? 

Fate passes. I am not sure about avcodec_find_best_pix_fmt_of_list(), but 
since pixdesc_has_alpha() in avutil/pixdesc.c already considered PAL8 as a 
format with alpha, I don't think it changes.


Oh, interesting point. So this whole discussion is moot anyway, since
it always suggested RGBA when converting PAL8 to a non-paletted RGB
format?


Only if has_alpha was true when the user called 
avcodec_find_best_pix_fmt_of_list() or av_find_best_pix_fmt_of_2().


For avfiltergraph format negotiation or for ffmpeg.c automatic codec pixel 
format selection, pal8 was not considered as a format with alpha 
(nb_components % 2 == 0 check was used), so they called 
av_find_best_pix_fmt_of_2() with has_alpha=false, therefore alpha loss was 
not penalized. A subsequent patch takes care of that.


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

[FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

[Jacob Trimble]

While integrating my encryption info changes, I noticed a problem with
the init info structs.  I implemented them as side-data on the Stream.
But this means there can only be one per stream.  However, there can
be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
multiple key systems). (sorry for not noticing sooner)

Attached is a patch to fix this by making the init info a
singly-linked-list.  It is ABI compatible and is still easy to use and
understand.  The alternative would be to break ABI and have the
side-data methods return an array of pointers.  I could do that
instead if that is preferable.
From bb941a77e882e93629d63d63059d0063b9519e29 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Mon, 23 Apr 2018 10:33:58 -0700
Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.

It is possible for there to be multiple encryption init info structure.
For example, to support multiple key systems or in key rotation.  This
changes the AVEncryptionInitInfo struct to be a linked list so there
can be multiple structs without breaking ABI.

Signed-off-by: Jacob Trimble 
---
 libavutil/encryption_info.c | 154 +++-
 libavutil/encryption_info.h |   5 ++
 2 files changed, 106 insertions(+), 53 deletions(-)

diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
index 20a752d6b4..9935c10d74 100644
--- a/libavutil/encryption_info.c
+++ b/libavutil/encryption_info.c
@@ -160,13 +160,16 @@ uint8_t *av_encryption_info_add_side_data(const AVEncryptionInfo *info, size_t *
 }
 
 // The format of the AVEncryptionInitInfo side data:
-// u32be system_id_size
-// u32be num_key_ids
-// u32be key_id_size
-// u32be data_size
-// u8[system_id_size] system_id
-// u8[key_id_size][num_key_id] key_ids
-// u8[data_size] data
+// u32be init_info_count
+// {
+//   u32be system_id_size
+//   u32be num_key_ids
+//   u32be key_id_size
+//   u32be data_size
+//   u8[system_id_size] system_id
+//   u8[key_id_size][num_key_id] key_ids
+//   u8[data_size] data
+// }[init_info_count]
 
 #define FF_ENCRYPTION_INIT_INFO_EXTRA 16
 
@@ -215,6 +218,7 @@ void av_encryption_init_info_free(AVEncryptionInitInfo *info)
 for (i = 0; i < info->num_key_ids; i++) {
 av_free(info->key_ids[i]);
 }
+av_encryption_init_info_free(info->next);
 av_free(info->system_id);
 av_free(info->key_ids);
 av_free(info->data);
@@ -225,71 +229,115 @@ void av_encryption_init_info_free(AVEncryptionInitInfo *info)
 AVEncryptionInitInfo *av_encryption_init_info_get_side_data(
 const uint8_t *side_data, size_t side_data_size)
 {
-AVEncryptionInitInfo *info;
+AVEncryptionInitInfo *ret = NULL, *info;
 uint64_t system_id_size, num_key_ids, key_id_size, data_size, i;
+uint64_t init_info_count;
 
-if (!side_data || side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA)
-return NULL;
-
-system_id_size = AV_RB32(side_data);
-num_key_ids = AV_RB32(side_data + 4);
-key_id_size = AV_RB32(side_data + 8);
-data_size = AV_RB32(side_data + 12);
-
-// UINT32_MAX + UINT32_MAX + UINT32_MAX * UINT32_MAX == UINT64_MAX
-if (side_data_size - FF_ENCRYPTION_INIT_INFO_EXTRA < system_id_size + data_size + num_key_ids * key_id_size)
-return NULL;
-
-info = av_encryption_init_info_alloc(system_id_size, num_key_ids, key_id_size, data_size);
-if (!info)
+if (!side_data || side_data_size < 4)
 return NULL;
 
-memcpy(info->system_id, side_data + 16, system_id_size);
-side_data += system_id_size + 16;
-for (i = 0; i < num_key_ids; i++) {
-  memcpy(info->key_ids[i], side_data, key_id_size);
-  side_data += key_id_size;
+init_info_count = AV_RB32(side_data);
+side_data += 4;
+side_data_size -= 4;
+for (i = 0; i < init_info_count; i++) {
+  if (side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA) {
+  av_encryption_init_info_free(ret);
+  return NULL;
+  }
+
+  system_id_size = AV_RB32(side_data);
+  num_key_ids = AV_RB32(side_data + 4);
+  key_id_size = AV_RB32(side_data + 8);
+  data_size = AV_RB32(side_data + 12);
+
+  // UINT32_MAX + UINT32_MAX + UINT32_MAX * UINT32_MAX == UINT64_MAX
+  if (side_data_size - FF_ENCRYPTION_INIT_INFO_EXTRA < system_id_size + data_size + num_key_ids * key_id_size) {
+  av_encryption_init_info_free(ret);
+  return NULL;
+  }
+  side_data += FF_ENCRYPTION_INIT_INFO_EXTRA;
+  side_data_size -= FF_ENCRYPTION_INIT_INFO_EXTRA;
+
+  info = av_encryption_init_info_alloc(system_id_size, num_key_ids, key_id_size, data_size);
+  if (!info) {
+  av_encryption_init_info_free(ret);
+  return NULL;
+  }
+  info->next = ret;
+  ret = info;
+
+  memcpy(info->system_id, side_data, system_id_size);
+  side_data += system_id_size;
+  side_data_size -= system_id_size;
+  for (i = 0; i < num_key_ids; i++) {
+memcpy(info->key_id

Re: [FFmpeg-devel] [PATCH 2/5] reitnerlace - tinterlace-like filter under LGPL

[Vasile Toncu]

Hello,

Here is patches 2. Please review.

Thank you,
Vasile Toncu
>From cb12fbb6de88acfb3f7f54bd83b91661063e92ff Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Mon, 23 Apr 2018 18:10:18 +0300
Subject: [PATCH] Patch2

Signed-off-by: Vasile Toncu 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/reinterlace.h | 140 +++
 libavfilter/vf_reinterlace.c  | 754 ++
 libavfilter/x86/Makefile  |   1 +
 libavfilter/x86/vf_reinterlace_init.c | 102 +
 6 files changed, 999 insertions(+)
 create mode 100644 libavfilter/reinterlace.h
 create mode 100644 libavfilter/vf_reinterlace.c
 create mode 100644 libavfilter/x86/vf_reinterlace_init.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index cfb0f1d..5b503a1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -291,6 +291,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
+OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 68b2992..281eaa5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -282,6 +282,7 @@ extern AVFilter ff_vf_random;
 extern AVFilter ff_vf_readeia608;
 extern AVFilter ff_vf_readvitc;
 extern AVFilter ff_vf_realtime;
+extern AVFilter ff_vf_reinterlace;
 extern AVFilter ff_vf_remap;
 extern AVFilter ff_vf_removegrain;
 extern AVFilter ff_vf_removelogo;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
new file mode 100644
index 000..10832f5
--- /dev/null
+++ b/libavfilter/reinterlace.h
@@ -0,0 +1,140 @@
+/*
+ * Copyright (c) 2018 Vasile Toncu 
+ * Copyright (c) 2017 Thomas Mundt 
+ *
+ * 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
+ */
+
+#include 
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "libavutil/bswap.h"
+
+enum FilterMode {
+MODE_MERGE,
+MODE_DROP_EVEN,
+MODE_DROP_ODD,
+MODE_PAD,
+MODE_INTERLEAVE_TOP,
+MODE_INTERLEAVE_BOTTOM,
+MODE_INTERLACE_X2,
+MODE_MERGE_X2,
+MODE_MERGE_TFF,
+MODE_MERGE_BFF,
+MODE_NB
+};
+
+enum FilterFlags {
+FLAG_NOTHING= 0x00,
+FLAG_VLPF   = 0x01,
+FLAG_EXACT_TB   = 0x02,
+FLAG_CVLPF  = 0x04,
+FLAG_NB
+};
+
+static const AVRational standard_tbs[] = {
+{1, 25},
+{1, 30},
+{1001, 3},
+};
+
+typedef struct {
+const AVClass *class;
+int mode;
+int flags;
+
+AVFrame *prev_frame, *current_frame;
+int64_t current_frame_index;
+
+void *black_vec[4];
+
+int skip_next_frame;
+
+void *thread_data;
+
+uint8_t bit_depth;
+
+void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
+ ptrdiff_t mref, ptrdiff_t pref, int clip_max);
+
+AVRational preout_time_base;
+
+} ReInterlaceContext;
+
+#if CONFIG_GPL
+void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
+#endif
+
+#define OFFSET(x) offsetof(ReInterlaceContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption reinterlace_options[] = {
+{ "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, {.i64=MODE_MERGE}, 0, MODE_NB - 1, FLAGS, "mode" },
+{ "merge", "merge frames",0, AV_OPT_TYPE_CONST, {.i64=MODE_MERGE},INT_MIN, INT_MAX, FLAGS, "mode"},
+{ "drop_even", "drop even frames",0, AV_OPT_TYPE_CONST, {.i64=MODE_DROP_EVEN},INT_MIN, INT_MAX, FLAGS, "mode"},
+{ "drop_odd",  "drop odd frames", 0, AV_OPT_TYPE_CONST, {.i64=MODE_DROP_ODD}, INT_MIN

Re: [FFmpeg-devel] [PATCH 3/5] reitnerlace - tinterlace-like filter under LGPL

[Vasile Toncu]

Hello,

Here is patch 3. Please review.

Thank you,
Vasile
>From 180d0b61ca2d835bdc58a17db07d4c79532b1b1e Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Mon, 23 Apr 2018 18:59:52 +0300
Subject: [PATCH] Patch3

Signed-off-by: Vasile Toncu 
---
 configure |   1 -
 libavfilter/Makefile  |   1 -
 libavfilter/allfilters.c  |   1 -
 libavfilter/reinterlace.h | 140 --
 libavfilter/tinterlace.h  | 170 +--
 libavfilter/vf_reinterlace.c  | 754 --
 libavfilter/vf_tinterlace.c   | 842 +-
 libavfilter/x86/Makefile  |   1 -
 libavfilter/x86/vf_reinterlace_init.c | 102 
 libavfilter/x86/vf_tinterlace_init.c  |  41 +-
 10 files changed, 678 insertions(+), 1375 deletions(-)
 delete mode 100644 libavfilter/reinterlace.h
 delete mode 100644 libavfilter/vf_reinterlace.c
 delete mode 100644 libavfilter/x86/vf_reinterlace_init.c

diff --git a/configure b/configure
index a6f32f8..f1b4935 100755
--- a/configure
+++ b/configure
@@ -3387,7 +3387,6 @@ stereo3d_filter_deps="gpl"
 subtitles_filter_deps="avformat avcodec libass"
 super2xsai_filter_deps="gpl"
 pixfmts_super2xsai_test_deps="super2xsai_filter"
-tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5b503a1..cfb0f1d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -291,7 +291,6 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
-OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 281eaa5..68b2992 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -282,7 +282,6 @@ extern AVFilter ff_vf_random;
 extern AVFilter ff_vf_readeia608;
 extern AVFilter ff_vf_readvitc;
 extern AVFilter ff_vf_realtime;
-extern AVFilter ff_vf_reinterlace;
 extern AVFilter ff_vf_remap;
 extern AVFilter ff_vf_removegrain;
 extern AVFilter ff_vf_removelogo;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
deleted file mode 100644
index 10832f5..000
--- a/libavfilter/reinterlace.h
+++ /dev/null
@@ -1,140 +0,0 @@
-/*
- * Copyright (c) 2018 Vasile Toncu 
- * Copyright (c) 2017 Thomas Mundt 
- *
- * 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
- */
-
-#include 
-
-#include "avfilter.h"
-#include "formats.h"
-#include "internal.h"
-#include "video.h"
-#include "libavutil/avassert.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
-
-#include "libavutil/bswap.h"
-
-enum FilterMode {
-MODE_MERGE,
-MODE_DROP_EVEN,
-MODE_DROP_ODD,
-MODE_PAD,
-MODE_INTERLEAVE_TOP,
-MODE_INTERLEAVE_BOTTOM,
-MODE_INTERLACE_X2,
-MODE_MERGE_X2,
-MODE_MERGE_TFF,
-MODE_MERGE_BFF,
-MODE_NB
-};
-
-enum FilterFlags {
-FLAG_NOTHING= 0x00,
-FLAG_VLPF   = 0x01,
-FLAG_EXACT_TB   = 0x02,
-FLAG_CVLPF  = 0x04,
-FLAG_NB
-};
-
-static const AVRational standard_tbs[] = {
-{1, 25},
-{1, 30},
-{1001, 3},
-};
-
-typedef struct {
-const AVClass *class;
-int mode;
-int flags;
-
-AVFrame *prev_frame, *current_frame;
-int64_t current_frame_index;
-
-void *black_vec[4];
-
-int skip_next_frame;
-
-void *thread_data;
-
-uint8_t bit_depth;
-
-void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
- ptrdiff_t mref, ptrdiff_t pref, int clip_max);
-
-AVRational preout_time_base;
-
-} ReInterlaceContext;
-
-#if CONFIG_GPL
-void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
-#endif
-
-#define OFFSET(x) offsetof(ReInt

[FFmpeg-devel] Feeling Ecstatic for Getting selected in GSOC

[Gagandeep Singh]

Hi Guys,

I am really happy for your trust in me to handle the project, and for
giving me the opportunity by approving the project for GSOC.

I will try to do my best for the same.

Kierank and Durandal_1707, special thanks for the support throughout.

Sincerely,
Gagandeep Singh
___
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.

[Drew Allen]

Hi Rostislav,

Here is my feedback:

I am sorry, I don't agree that this should be merged quite yet.

First of all, the draft upon which how the channel family is interpreted
(draft-ietf-codec-ambisonics-04) isn't finalized yet. What if it changes
after we make a release? We can't really change it. This affects both
encoding and decoding.

We have spent the past 2 years with the draft relatively unchanged aside
from minor edits on the draft. It is headed to a working group for
finalization very soon and no one has yet raised a single issue regarding
any proposed changes that this patch introduces. I wrote the
OpusProjection* API and it has been adopted in all Opus-related xiph master
branches.

Second, the API isn't in any libopus release yet. What if we make a
release, the draft changes, so the API in libopus needs to be changed. Or
the API in the current git master of libopus changes? We can't rely on an
unstable API in a library.

I worked closely with Jean-Marc Valin to design the API in Opus 1.3 to his
specification. Opus 1.3 beta already contains this new API and upon
release, I have 100% assurance from Jean-Marc that the OpusProjection* API
will be supported in 1.3 RC.

Third, this patch makes the decoder always do demixing with the data in
extradata. What if someone wants to just decode and do their own demixing
with positional information? We'd break decoding for anyone who's depending
on the behaviour if we were to change this so the decoder outputs raw
ambisonics. We never do any mixing or conversions in decoders. Hence
ambisonics data needs to be exposed directly, and anyone wanting to demix
it should use a filter (there's an unmerged filter to do that) or do it
themselves.
What we need to do to properly handle ambisonics is:
1. Be able to describe ambisonics. This needs a new API.
2. Be able to expose the demixing matrix via frame side data.
3. Have a filter which can use both to provide a demixed output, better yet
with positional information.

I disagree that a filter or some other layer of abstraction is necessary
here. OpusProjection* does not code the ambisonic channels directly.
Instead, they are mixed using a mixing matrix that minimizes coding
artifacts over the sphere. The demixing matrix on the decoder is vital in
order to get back the original ambisonic channels and OpusProjectionDecoder
handles this automatically.

I think the draft should become an RFC first. That gives us enough time to
work on 1.), which should take the longest time to do and agree on. 2.) is
trivial and 3.) is from what I know mostly done.

I completely disagree. The IETF draft has been stable for over a year and
these same changes to support the new API are already present in Opus,
libopusenc, opusfile and opus-tools.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

[Derek Buitenhuis]

The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.

Technically, we shouldn't be using the stts atom at all for
calculating stream durations.

This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.

The FATE changes are expected, and output is more correct (the
AAC frame is not 1028 samples).

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c   | 6 +++---
 tests/ref/fate/adtstoasc_ticket3715 | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 8fea670..1975011 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2932,7 +2932,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 st->nb_frames= total_sample_count;
 if (duration)
-st->duration= duration;
+st->duration= FFMIN(st->duration, duration);
 sc->track_end = duration;
 return 0;
 }
@@ -3671,8 +3671,8 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 }
 }
 
-// Update av stream length
-st->duration = edit_list_dts_entry_end - start_dts;
+// Update av stream length, if it ends up shorter than the track's media 
duration
+st->duration = FFMIN(st->duration, edit_list_dts_entry_end - start_dts);
 msc->start_pad = st->skip_samples;
 
 // Free the old index and the old CTTS structures
diff --git a/tests/ref/fate/adtstoasc_ticket3715 
b/tests/ref/fate/adtstoasc_ticket3715
index 96795a2..c5f03e4 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -92,4 +92,4 @@
 0,  83968,  83968, 1024,  465, 0xeb3ce0af
 0,  84992,  84992, 1024,  326, 0x7be4a667
 0,  86016,  86016, 1024,  339, 0x2cf4a71f
-0,  87040,  87040, 1028,  258, 0xd4007ad4
+0,  87040,  87040, 1024,  258, 0xd4007ad4
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/vpcc: Calculate VP9 level from Luma's Sample rate and Picture size

[James Almer]

On 4/23/2018 8:58 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Apr 23, 2018 at 2:10 AM, Karthick J  wrote:
> 
>> -int level = par->level == FF_LEVEL_UNKNOWN ? 0 : par->level;
>> +int level = par->level == FF_LEVEL_UNKNOWN ?
>> +get_vp9_level(par, frame_rate) : par->level;
> 
> 
> 
> After this change, how will I create a file without a level?
> 
> This patch blurs the line between "unknown", "unspecified", "non-existent"
> and "autodetect". Linguistically, each of these mean something
> fundamentally different. I think it's acceptable to not have too many ways
> of specifying something which in practice comes down to "nope", but you're
> removing the "nope" altogether, which isn't quite right either.

The spec (VP9 in mp4) doesn't allow 0 nor defines an "unknown" value to
be muxed into the vpcc atom. Technically speaking, we have been creating
invalid files all this time by using 0 when the profile is unknown.
See https://www.webmproject.org/vp9/mp4/

I don't think anything really looks at this field, beyond maybe just
making sure it's a valid value if the parser is super pedantic, as it's
not needed to actually start decoding. So an approximation is probably
better than an out of range value like 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V3 PATCH 2/3] Add codec wrapper for librv11

[Carl Eugen Hoyos]

2018-04-22 23:16 GMT+02:00, Thilo Borgmann :

> +#include 

Why is this include needed?

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

Re: [FFmpeg-devel] [V3 PATCH 3/3] Add docs and Changelog

[Carl Eugen Hoyos]

2018-04-22 23:16 GMT+02:00, Thilo Borgmann :

Why is this a separate patch?

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

Re: [FFmpeg-devel] [V2 PATCH 2/4] Add muxing/demuxing of RMHD

[Carl Eugen Hoyos]

2018-02-02 3:43 GMT+01:00, Thilo Borgmann :
> Does not add a new demuxer anymore.

Good, now please split the patches, the demuxer patches
look relatively easy to review.

> For the muxer I'm not sure it should be done - would require more logic to
> check for valid codec ids for both cases I think (like for AAC audio).

Not sure I understand: Aren't all the functions identical for both muxers?

If easily avoidable, no new muxer should be added, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Rostislav Pehlivanov]

On 23 April 2018 at 10:27, Thomas Volkert  wrote:

> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
> > 2018-04-22 20:00 GMT+02:00, Nicolas George :
> >> Carl Eugen Hoyos (2018-04-22):
> >>> How do you detect that this is not the "current version" of mbed?
> >> Is it really our responsibility?
> > We try to always do it and I believe that allowing LGPL makes
> > more sense and less headache: Since we do the checks so
> > rigorously it makes sense to assume we did it as correctly
> > for this case.
> >
> > I don't understand why we don't go the easy way that clearly
> > has advantages instead for the complicated way (with at
> > least some disadvantages).
>
> Okay. I looked over their web page and the Debian packages again.
> The web page of mbedTLS declares Apache license as the "primary open
> source license".
>
> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> their are no further objections.
>
> Best regards,
> Thomas.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd like some memory usage and performance comparisons to gnutls and
openssl before you push. This is the 6th (!!) TLS library we'd be
supporting.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/vpcc: Calculate VP9 level from Luma's Sample rate and Picture size

[Ronald S. Bultje]

Hi,

On Mon, Apr 23, 2018 at 2:10 AM, Karthick J  wrote:

> -int level = par->level == FF_LEVEL_UNKNOWN ? 0 : par->level;
> +int level = par->level == FF_LEVEL_UNKNOWN ?
> +get_vp9_level(par, frame_rate) : par->level;



After this change, how will I create a file without a level?

This patch blurs the line between "unknown", "unspecified", "non-existent"
and "autodetect". Linguistically, each of these mean something
fundamentally different. I think it's acceptable to not have too many ways
of specifying something which in practice comes down to "nope", but you're
removing the "nope" altogether, which isn't quite right either.

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

Re: [FFmpeg-devel] lavf/os_support: Only compile inet_aton() if getaddrinfo() is needed

[Carl Eugen Hoyos]

2018-04-22 0:52 GMT+02:00, Reino Wijnsma :
> On 16-4-2018 1:33, Carl Eugen Hoyos  wrote:
>> Attached patch is supposed to silence a user-reported warning when
>> inet_aton() is missing but getaddrinfo() is supported.
>> Untested.
>>
>> Please review, Carl Eugen
> $ make libavformat/os_support.o
> CC  libavformat/os_support.o
> libavformat/os_support.c: In function 'ff_poll':
> libavformat/os_support.c:248:23: warning: comparison of unsigned expression
> < 0 is always false [-Wtype-limits]
>  if (fds[i].fd < 0)
>^
>
> The warning this patch is for is gone now.

Pushed this patch.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
> 2018-04-22 20:00 GMT+02:00, Nicolas George :
>> Carl Eugen Hoyos (2018-04-22):
>>> How do you detect that this is not the "current version" of mbed?
>> Is it really our responsibility?
> We try to always do it and I believe that allowing LGPL makes
> more sense and less headache: Since we do the checks so
> rigorously it makes sense to assume we did it as correctly
> for this case.
>
> I don't understand why we don't go the easy way that clearly
> has advantages instead for the complicated way (with at
> least some disadvantages).

Okay. I looked over their web page and the Debian packages again.
The web page of mbedTLS declares Apache license as the "primary open
source license".

I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
their are no further objections.

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

Re: [FFmpeg-devel] fate/hap : add test for hap encoding

[Carl Eugen Hoyos]

2018-03-14 7:31 GMT+01:00, Martin Vignali :

> In that case we can let the test using "none"
> compression (bypass the snappy part)

These tests are also broken, please fix or
remove them:
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=i386&ver=7%3A4.0-1&stamp=152218&raw=0
("Error 1")

Carl Eugen
___
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

[Vasile Toncu]

This patch is still corrupted by your mailer, by introducing line
breaks. Please attach it as a file, or use "git send-email"

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


Hello,

I have attached the patch. It's strange, my mailer shows the message 
with no line breaks, but on the list it appears like that. I hope this 
solves the problem.


Kind regards,
Vasile
>From b93c2bc52d1892ffc9dd3f22e409aeeebd4cc163 Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Tue, 17 Apr 2018 13:48:28 +0300
Subject: [PATCH] Remove interlace.h and x86/vf_interlace_init.c

---
 libavfilter/Makefile|   2 +-
 libavfilter/interlace.h |  68 ---
 libavfilter/vf_interlace.c  | 366 
 libavfilter/vf_tinterlace.c |  26 +++
 libavfilter/x86/Makefile|   2 +-
 libavfilter/x86/vf_interlace_init.c |  88 -
 6 files changed, 28 insertions(+), 524 deletions(-)
 delete mode 100644 libavfilter/interlace.h
 delete mode 100644 libavfilter/vf_interlace.c
 delete mode 100644 libavfilter/x86/vf_interlace_init.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3a9fb02..cfb0f1d 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/interlace.h b/libavfilter/interlace.h
deleted file mode 100644
index b41f0d5..000
--- a/libavfilter/interlace.h
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * 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.
- */
-
-/**
- * @file
- * progressive to interlaced content filter, inspired by heavy debugging of
- * tinterlace filter.
- */
-
-#ifndef AVFILTER_INTERLACE_H
-#define AVFILTER_INTERLACE_H
-
-#include "libavutil/bswap.h"
-#include "libavutil/common.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
-
-#include "avfilter.h"
-#include "formats.h"
-#include "internal.h"
-#include "video.h"
-
-enum ScanMode {
-MODE_TFF = 0,
-MODE_BFF = 1,
-};
-
-enum FieldType {
-FIELD_UPPER = 0,
-FIELD_LOWER = 1,
-};
-
-enum VLPFilter {
-VLPF_OFF = 0,
-VLPF_LIN = 1,
-VLPF_CMP = 2,
-};
-
-typedef struct InterlaceContext {
-const AVClass *class;
-enum ScanMode scan;// top or bottom field first scanning
-int lowpass;   // enable or disable low pass filtering
-AVFrame *cur, *next;   // the two frames from which the new one is obtained
-const AVPixFmtDescriptor *csp;
-void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const uint8_t *srcp,
- ptrdiff_t mref, ptrdiff_t pref, int clip_max);
-} InterlaceContext;
-
-void ff_interlace_init(InterlaceContext *interlace, int depth);
-void ff_interlace_init_x86(InterlaceContext *interlace, int depth);
-
-#endif /* AVFILTER_INTERLACE_H */
diff --git a/libavfilter/vf_interlace.c b/libavfilter/vf_interlace.c
deleted file mode 100644
index 24c422d..000
--- a/libavfilter/vf_interlace.c
+++ /dev/null
@@ -1,366 +0,0 @@
-/*
- * Copyright (c) 2003 Michael Zucchi 
- * Copyright (c) 2010 Baptiste Coudurier
- * Copyright (c) 2011 Stefano Sabatini
- * Copyright (c) 2013 Vittorio Giovara 
- * Copyright (c) 2017 Thomas Mundt 
- *
- * 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
- * MERCHANTABI

Re: [FFmpeg-devel] [PATCH] avcodec/vc1_block: simplify ac_val computation

[Paul B Mahol]

On 4/23/18, Michael Niedermayer  wrote:
> also fixes: runtime error: index 1456 out of bounds for type 'int16_t [16]'
>
> Found-by: durandal_1707
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vc1_block.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based on framesync

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Sunday, April 22, 2018 3:21 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based
> on framesync
> 
> On 03/04/18 02:50, Ruiling Song wrote:
> > The existing version which was cherry-picked from Libav does not work
> > with FFmpeg framework, because ff_request_frame() was totally
> > different between Libav (recursive) and FFmpeg (non-recursive).
> > The existing overlay_qsv implementation depends on the recursive version
> > of ff_request_frame to trigger immediate call to request_frame() on input 
> > pad.
> > But this has been removed in FFmpeg since "lavfi: make request_frame() non-
> recursive."
> > Now that we have handy framesync support in FFmpeg, so I make it work
> > based on framesync. Some other fixing which is also needed to make
> > overlay_qsv work are put in a separate patch.
> >
> > v2:
> > add .preinit field to initilize framesync options.
> > export more options like vf_overlay.c
> >
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavfilter/Makefile |   2 +-
> >  libavfilter/vf_overlay_qsv.c | 213 
> > ---
> >  2 files changed, 78 insertions(+), 137 deletions(-)
> >
> On 03/04/18 02:50, Ruiling Song wrote:
> > For filters based on framesync, the input frame was managed
> > by framesync, so we should not directly keep and destroy it,
> > instead we make a clone of it here, or else double-free will occur.
> > But for other filters not based on framesync, we still need to
> > free the input frame inside filter_frame. That's why I made
> > this v2 to fix the side-effect on normal filters.
> >
> > v2:
> > and one av_frame_free() in vf_vpp_qsv.c
> >
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavfilter/qsvvpp.c | 4 ++--
> >  libavfilter/vf_vpp_qsv.c | 5 -
> >  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> Tested, LGTM, set applied with one minor merge fixup - it collided with the
> change to pass through unmodified frames directly.  (Apologies for the delay!)
> 
> Shall I apply this to the 4.0 branch as well?

Sure, I think it's better to merge to 4.0. I noticed this feature was included 
in the release note. 
Thanks Mark!

Ruiling
> 
> Thanks,
> 
> - Mark
> ___
> 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 2/2] vaapi_encode_h265: Insert mastering display colour colume if needed

[Xiang, Haihao]

> On 20/04/18 08:27, Haihao Xiang wrote:
> > '-sei xxx' is added to control SEI insertion, so far only mastering
> > display colour colume is available for testing. Another patch is
> > required to change mastering display settings later.
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vaapi_encode_h265.c | 94
> > +-
> >  1 file changed, 93 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> > index 5203c6871d..a8cb6a6d8b 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -29,10 +29,14 @@
> >  #include "cbs.h"
> >  #include "cbs_h265.h"
> >  #include "hevc.h"
> > +#include "hevc_sei.h"
> >  #include "internal.h"
> >  #include "put_bits.h"
> >  #include "vaapi_encode.h"
> >  
> > +enum {
> > +SEI_MASTERING_DISPLAY   = 0x01,
> 
> Since the options are essentially the same I think it would be nice if these
> values matched the H.264 ones?  (That is, make this value 8.)
> 

My original thought was to make this value 8, but I am not sure whether another 
SEI_XXX will be added for H.264 in the future. Will we use 8 for a new SEI_XXX 
for H.264? 

> Should this be mastering display specifically, or would it be better for this
> option to be called something like "HDR metadata" (just "hdr" as the option
> name?) which also includes content light level?  (Compare the -sei timing
> option on H.264, which gives you both buffering period and picture timing
> SEI.)
> 

Good idea, I prefer using hdr for mastering display and content light level.
Actually adding support for content light level is in my todo list. 

> > +};
> >  
> >  typedef struct VAAPIEncodeH265Context {
> >  unsigned int ctu_width;
> > @@ -47,6 +51,9 @@ typedef struct VAAPIEncodeH265Context {
> >  H265RawSPS sps;
> >  H265RawPPS pps;
> >  H265RawSlice slice;
> > +H265RawSEI sei;
> > +
> > +H265RawSEIMasteringDiplayColorVolume mastering_display;
> >  
> >  int64_t last_idr_frame;
> >  int pic_order_cnt;
> > @@ -58,6 +65,7 @@ typedef struct VAAPIEncodeH265Context {
> >  CodedBitstreamContext *cbc;
> >  CodedBitstreamFragment current_access_unit;
> >  int aud_needed;
> > +int sei_needed;
> >  } VAAPIEncodeH265Context;
> >  
> >  typedef struct VAAPIEncodeH265Options {
> > @@ -65,6 +73,7 @@ typedef struct VAAPIEncodeH265Options {
> >  int aud;
> >  int profile;
> >  int level;
> > +int sei;
> >  } VAAPIEncodeH265Options;
> >  
> >  
> > @@ -175,6 +184,61 @@ fail:
> >  return err;
> >  }
> >  
> > +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
> > +VAAPIEncodePicture *pic,
> > +int index, int *type,
> > +char *data, size_t
> > *data_len)
> > +{
> > +VAAPIEncodeContext  *ctx = avctx->priv_data;
> > +VAAPIEncodeH265Context *priv = ctx->priv_data;
> > +VAAPIEncodeH265Options  *opt = ctx->codec_options;
> > +CodedBitstreamFragment   *au = &priv->current_access_unit;
> > +int err, i;
> > +
> > +if (priv->sei_needed) {
> > +if (priv->aud_needed) {
> > +err = vaapi_encode_h265_add_nal(avctx, au, &priv->aud);
> > +if (err < 0)
> > +goto fail;
> > +priv->aud_needed = 0;
> > +}
> > +
> > +memset(&priv->sei, 0, sizeof(priv->sei));
> > +priv->sei.nal_unit_header.nal_unit_type = HEVC_NAL_SEI_PREFIX;
> > +priv->sei.nal_unit_header.nuh_temporal_id_plus1 = 1;
> 
> Might look nicer as a compound literal?

Agree, I will update the patch.

> 
> > +i = 0;
> > +
> > +if (opt->sei & SEI_MASTERING_DISPLAY && pic->type ==
> > PICTURE_TYPE_IDR) {
> > +priv->sei.payload[i].payload_type =
> > HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
> > +priv->sei.payload[i].payload.mastering_display = priv-
> > >mastering_display;
> > +++i;
> > +}
> > +
> > +priv->sei.payload_count = i;
> > +av_assert0(priv->sei.payload_count > 0);
> > +
> > +err = vaapi_encode_h265_add_nal(avctx, au, &priv->sei);
> > +if (err < 0)
> > +goto fail;
> > +priv->sei_needed = 0;
> > +
> > +err = vaapi_encode_h265_write_access_unit(avctx, data, data_len,
> > au);
> > +if (err < 0)
> > +goto fail;
> > +
> > +ff_cbs_fragment_uninit(priv->cbc, au);
> > +
> > +*type = VAEncPackedHeaderRawData;
> > +return 0;
> > +} else {
> > +return AVERROR_EOF;
> > +}
> > +
> > +fail:
> > +ff_cbs_fragment_uninit(priv->cbc, au);
> > +return err;
> > +}
> > +
> >  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> >  {
> >  VAAPIEncodeContext*ctx = avctx->priv_data;
> > @@ -587,6 +651,23 @@ static