[FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of ticket #6677

[Zhong Li]

Signed-off-by: Zhong Li 
---
 tests/fate/video.mak|  3 +++
 tests/ref/fate/mpeg2-ticket6677 | 12 
 2 files changed, 15 insertions(+)
 create mode 100644 tests/ref/fate/mpeg2-ticket6677

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index 6f76365165..51678078a3 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -257,6 +257,9 @@ fate-mpeg2-ticket186: CMD = framecrc -flags +bitexact -idct 
simple -i $(TARGET_S
 FATE_VIDEO-$(call DEMDEC, MPEGPS, MPEG2VIDEO) += fate-mpeg2-ticket6024
 fate-mpeg2-ticket6024: CMD = framecrc -flags +bitexact -idct simple -flags 
+truncated -i $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg -an
 
+FATE_VIDEO-$(call DEMDEC, MPEGVIDEO, MPEG2VIDEO) += fate-mpeg2-ticket6677
+fate-mpeg2-ticket6677: CMD = framecrc -vsync drop -i 
$(TARGET_SAMPLES)/mpeg2/sony-ct3.bs
+
 FATE_VIDEO-$(call DEMDEC, MV, MVC1) += fate-mv-mvc1
 fate-mv-mvc1: CMD = framecrc -i $(TARGET_SAMPLES)/mv/posture.mv -an -frames 25 
-pix_fmt rgb555le
 
diff --git a/tests/ref/fate/mpeg2-ticket6677 b/tests/ref/fate/mpeg2-ticket6677
new file mode 100644
index 00..5fc7cb2a26
--- /dev/null
+++ b/tests/ref/fate/mpeg2-ticket6677
@@ -0,0 +1,12 @@
+#tb 0: 1/30
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 720x480
+#sar 0: 8/9
+0,  0,  0,1,   518400, 0x354b6fc3
+0,  1,  1,1,   518400, 0xd86f281b
+0,  2,  2,1,   518400, 0xdd2e2b38
+0,  3,  3,1,   518400, 0x589535d4
+0,  4,  4,1,   518400, 0x3f8f02b6
+0,  5,  5,1,   518400, 0xa81b246a
+0,  6,  6,1,   518400, 0xb98dd9f7
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V4 2/2] hwaccel_mpeg: check reference pictures are available

[Zhong Li]

some reference pictures are not existed but valid surface_ids are set,
(for example, the second field of the first key frame can be
P_Picture_Type but there is no preivous frame.)
then may cause some driver problems (e.g, segment fault on  mesa/AMD driver).

Signed-off-by: Zhong Li 
---
 libavcodec/dxva2_mpeg2.c  |  4 ++--
 libavcodec/vaapi_mpeg2.c  |  6 --
 libavcodec/vdpau_mpeg12.c | 15 ++-
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
index b7c69378f0..9117a3d7b1 100644
--- a/libavcodec/dxva2_mpeg2.c
+++ b/libavcodec/dxva2_mpeg2.c
@@ -51,11 +51,11 @@ static void fill_picture_parameters(AVCodecContext *avctx,
 memset(pp, 0, sizeof(*pp));
 pp->wDecodedPictureIndex = ff_dxva2_get_surface_index(avctx, ctx, 
current_picture->f);
 pp->wDeblockedPictureIndex   = 0;
-if (s->pict_type != AV_PICTURE_TYPE_I)
+if (s->pict_type != AV_PICTURE_TYPE_I && s->last_picture_ptr)
 pp->wForwardRefPictureIndex  = ff_dxva2_get_surface_index(avctx, ctx, 
s->last_picture.f);
 else
 pp->wForwardRefPictureIndex  = 0x;
-if (s->pict_type == AV_PICTURE_TYPE_B)
+if (s->pict_type == AV_PICTURE_TYPE_B && s->next_picture_ptr)
 pp->wBackwardRefPictureIndex = ff_dxva2_get_surface_index(avctx, ctx, 
s->next_picture.f);
 else
 pp->wBackwardRefPictureIndex = 0x;
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 0d197c9692..942711b39f 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -73,10 +73,12 @@ static int vaapi_mpeg2_start_frame(AVCodecContext *avctx, 
av_unused const uint8_
 
 switch (s->pict_type) {
 case AV_PICTURE_TYPE_B:
-pic_param.backward_reference_picture = 
ff_vaapi_get_surface_id(s->next_picture.f);
+if (s->next_picture_ptr)
+pic_param.backward_reference_picture = 
ff_vaapi_get_surface_id(s->next_picture.f);
 // fall-through
 case AV_PICTURE_TYPE_P:
-pic_param.forward_reference_picture = 
ff_vaapi_get_surface_id(s->last_picture.f);
+if (s->last_picture_ptr)
+pic_param.forward_reference_picture = 
ff_vaapi_get_surface_id(s->last_picture.f);
 break;
 }
 
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
index b657007ee7..b6391ea216 100644
--- a/libavcodec/vdpau_mpeg12.c
+++ b/libavcodec/vdpau_mpeg12.c
@@ -45,13 +45,18 @@ static int vdpau_mpeg_start_frame(AVCodecContext *avctx,
 
 switch (s->pict_type) {
 case AV_PICTURE_TYPE_B:
-ref = ff_vdpau_get_surface_id(s->next_picture.f);
-assert(ref != VDP_INVALID_HANDLE);
-info->backward_reference = ref;
+if (s->next_picture_ptr) {
+ref = ff_vdpau_get_surface_id(s->next_picture.f);
+av_assert0(ref != VDP_INVALID_HANDLE);
+info->backward_reference = ref;
+}
 /* fall through to forward prediction */
 case AV_PICTURE_TYPE_P:
-ref = ff_vdpau_get_surface_id(s->last_picture.f);
-info->forward_reference  = ref;
+if (s->last_picture_ptr) {
+ref = ff_vdpau_get_surface_id(s->last_picture.f);
+av_assert0(ref != VDP_INVALID_HANDLE);
+info->forward_reference  = ref;
+}
 }
 
 info->slice_count= 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V4 1/2] mpeg2_hwaccel: always submit the first field to HW.

[Zhong Li]

Though this patch to fix ticket #6668, I belive it
is unnecessary to set SLICE_FLAG_ALLOW_FIELD flag to other
hwaccels(dxva, vdpau, etc). Please also refer the orginal comment
of 9cb150c9ab520eba5636bbcf925db6a70e67f3e5

Signed-off-by: Zhong Li 
---
 libavcodec/mpeg12dec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 4e68be27f1..5dc4612c77 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1689,8 +1689,7 @@ static int mpeg_field_start(MpegEncContext *s, const 
uint8_t *buf, int buf_size)
 return AVERROR_INVALIDDATA;
 }
 
-if (s->avctx->hwaccel &&
-(s->avctx->slice_flags & SLICE_FLAG_ALLOW_FIELD)) {
+if (s->avctx->hwaccel) {
 if ((ret = s->avctx->hwaccel->end_frame(s->avctx)) < 0) {
 av_log(avctx, AV_LOG_ERROR,
"hardware accelerator failed to decode first field\n");
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings when decoding DolbyVision

[Hendrik Leppkes]

On Mon, Oct 23, 2017 at 5:22 AM, James Almer  wrote:
> On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences the many warnings shown when decoding streams
>> with DolbyVision content.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch
>>
>>
>> From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sun, 22 Oct 2017 02:17:27 +0200
>> Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.
>>
>> ---
>>  libavcodec/hevcdec.c |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 2e4add2..d5ed9f5 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const 
>> H2645NAL *nal)
>>  break;
>>  case HEVC_NAL_AUD:
>>  case HEVC_NAL_FD_NUT:
>> +case 62: // unspecified, used by DolbyVision
>> +case 63: // unspecified, used by DolbyVision
>
> No, the log message should be set to verbose level instead, like
> inff_hevc_decode_extradata(). It's something of little value for the
> info level and effectively just spams stderr when trying to decode files
> with unofficial or currently unsupported NAL units.
>

Note that 62 and 63 are not specific NAL types for DoVi, instead DoVi
inserts an additional 16-bit value between startcode and the typical
NAL-syntax (0x7E01 for the enhancement layer NALs, 0x7C01 for the
metadata NALs), so we're basically just parsing them "wrong", which
(intentionally) results in mapping to reserved NALs so any conformant
decoders ignore them. Just to avoid confusion in the future.

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

Re: [FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings when decoding DolbyVision

[Carl Eugen Hoyos]

2017-10-23 5:22 GMT+02:00 James Almer :
> On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences the many warnings shown when decoding streams
>> with DolbyVision content.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch
>>
>>
>> From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sun, 22 Oct 2017 02:17:27 +0200
>> Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.
>>
>> ---
>>  libavcodec/hevcdec.c |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 2e4add2..d5ed9f5 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const 
>> H2645NAL *nal)
>>  break;
>>  case HEVC_NAL_AUD:
>>  case HEVC_NAL_FD_NUT:
>> +case 62: // unspecified, used by DolbyVision
>> +case 63: // unspecified, used by DolbyVision
>
> No, the log message should be set to verbose level instead, like
> inff_hevc_decode_extradata(). It's something of little value for the
> info level and effectively just spams stderr when trying to decode files
> with unofficial or currently unsupported NAL units.

Don't we want users to upload such samples?

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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[Clément Bœsch]

On Sun, Oct 22, 2017 at 12:09:04PM -0400, Ronald S. Bultje wrote:
[...]
> > > The replacement will never be written if:
> > > a) nobody cares; AND
> > > b) we keep delaying the removal
> > >
> > > I'm considering veto'ing this patch.
> >
> > Personally I'm with Clement in this. The deprecation was poorly handled,
> > and the feature currently has no replacement. Michael uses it for
> > debugging, so removing it does not seem productive.
> >
> > But, also agreeing with Clement, this should absolutely be ported to the
> > codecview filter before the next bump, or it will be removed.
> >
> 
> But this is the whole problem. We're stuck in a stalemate between nothing
> and nobody. As with ffserver, we'll keep postponing this forever more until
> the stalemate is broken.

Well, AFAIK contrary to ffserver, this is not exactly much a hinder for
further development; MPEG related development is pretty much stalled these
days, and there is no real API abuse here, it's just in the wrong place.

Also, contrary to ffserver, maybe it lacked some visibility by the
interested parties to do the actual portage work.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Daniel Kučera]

2017-10-21 13:36 GMT+02:00 Jan Ekstrom :
>
> This seems to have broken seeking and files ending. FLAC was
> experienced yesterday but it seems like it's more general. This was
> reported on the mpv users' channel by sfan5, but I feel like this
> might be more general than related to just mpv. At first this was
> thought to be limited to HTTP, but later was found out to be
> applicable to local files as well.
>


Hi Jan,

please post a test case, ideally as an issue into trac.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffserver: Fix off by 1 error in path

[Clément Bœsch]

On Sun, Oct 22, 2017 at 05:11:20PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/ffserver.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fftools/ffserver.c b/fftools/ffserver.c
> index d4885dfa0e..51f31bc704 100644
> --- a/fftools/ffserver.c
> +++ b/fftools/ffserver.c
> @@ -499,9 +499,9 @@ static void start_children(FFServerStream *feed)
>  if (!slash) {
>  pathname = av_mallocz(sizeof("ffmpeg"));
>  } else {
> -pathname = av_mallocz(slash - my_program_name + sizeof("ffmpeg"));
> +pathname = av_mallocz(slash - my_program_name + 1 + 
> sizeof("ffmpeg"));
>  if (pathname != NULL) {
> -memcpy(pathname, my_program_name, slash - my_program_name);
> +memcpy(pathname, my_program_name, slash - my_program_name + 1);
>  }

maybe that's correct but the whole code around here needs rewrite.

how about changing the whole chunk with (untested):

prog = av_strdup(my_program_name);
dirname = av_dirname(prog);
pathname = *dirname ? av_asprintf("%s/%s", dirname, "ffmpeg")
: av_asprintf("ffmpeg")
av_free(filepath);

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] ffserver: Fix off by 1 error in path

[Clément Bœsch]

On Mon, Oct 23, 2017 at 10:42:53AM +0200, Clément Bœsch wrote:
[...]
> how about changing the whole chunk with (untested):
> 
> prog = av_strdup(my_program_name);
> dirname = av_dirname(prog);
> pathname = *dirname ? av_asprintf("%s/%s", dirname, "ffmpeg")
> : av_asprintf("ffmpeg")
> av_free(filepath);
  
  prog

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check reference pictures are available

[Li, Zhong]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, October 13, 2017 4:34 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check reference
> pictures are available
> 
> 2017-10-12 10:20 GMT+02:00 Zhong Li :
> > some reference pictures are not existed but valiad surface_ids are
> > set, (for example, the second field of the first key frame can be
> > P_Picture_Type but there is no preivous frame.) then may cause some
> > driver problems
> 
> > (e.g, segment fault on mesa/AMD driver).
> 
> Please also confirm that these driver bugs are fixed.

Sorry for late reply. Do you mean this patch should be verified on mesa/AMD 
environment, or another patch of Meda/AMD driver is needed? 

> Carl Eugen
> ___
> 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 V3 2/2] hwaccel_mpeg: check reference pictures are available

[Carl Eugen Hoyos]

2017-10-23 10:49 GMT+02:00 Li, Zhong :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: Friday, October 13, 2017 4:34 AM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check reference
>> pictures are available
>>
>> 2017-10-12 10:20 GMT+02:00 Zhong Li :
>> > some reference pictures are not existed but valiad surface_ids are
>> > set, (for example, the second field of the first key frame can be
>> > P_Picture_Type but there is no preivous frame.) then may cause
>> > some driver problems
>>
>> > (e.g, segment fault on mesa/AMD driver).
>>
>> Please also confirm that these driver bugs are fixed.
>
> Sorry for late reply. Do you mean this patch should be verified
> on mesa/AMD environment, or another patch of Meda/AMD
> driver is needed?

I believe it is a good idea to add a work-around for a Mesa
bug into the FFmpeg code-base (not all users will immediately
update their graphics driver) but only if the Mesa bug is either
fixed or at least going to be fixed with some certainty.

The driver should never segfault.

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

Re: [FFmpeg-devel] [PATCH] swscale: more accurate DITHER_COPY macro for full and limited range

[Mateusz]

W dniu 2017-10-20 o 20:07, Jan Ekstrom pisze:
> On Fri, Oct 20, 2017 at 10:26 AM, Mateusz  wrote:
>> W dniu 2017-10-06 o 17:33, Mateusz pisze:
>>> Fixed DITHER_COPY macro (only C code), updated FATE tests.
>>>
>>> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is 
>>> there.
>>
>> Ping.
> 
> Hi,
> 
> The updated PSNR values look really good (and the max difference going
> from 1 to 0), but unfortunately I lack the capacity to verify that the
> code is doing the same thing as the original thing.
> 
> Can we please have someone's eyes on this? If a patchwork URL makes it
> simpler, it's https://patchwork.ffmpeg.org/patch/5440/ .
> 
> 
> Jan

There was discussion about this code in thread "swscale_unscaled: fix 
DITHER_COPY macro, use it only for dst_depth == 8". Conclusion was that it 
should be the same code for dst_depth from 8 to 15 bit (in all possible cases).

The worse quality scenario for this DITHER_COPY macro is when dst_depth is 8. 
It is hard to see differences from normal 8 bit to dithered 8 bit (too good 
quality).

I've prepared example movies with new DITHER_COPY macro versus downshift only 
with dst_depth == 5 (impossible in normal code, only for testing).

Movie Sintel in resolution 2K with bit depth 5 (original 5 most significant 
bits):
www.msystem.waw.pl/x265/sintel-org5.mkv

The same movie with bit depth 5, but dithered 5 bit instead of original:
www.msystem.waw.pl/x265/sintel-dit5.mkv

Mateusz

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

Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check reference pictures are available

[Li, Zhong]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Monday, October 23, 2017 4:53 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check reference
> pictures are available
> 
> 2017-10-23 10:49 GMT+02:00 Li, Zhong :
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> >> Sent: Friday, October 13, 2017 4:34 AM
> >> To: FFmpeg development discussions and patches
> >> 
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 2/2] hwaccel_mpeg: check
> >> reference pictures are available
> >>
> >> 2017-10-12 10:20 GMT+02:00 Zhong Li :
> >> > some reference pictures are not existed but valiad surface_ids are
> >> > set, (for example, the second field of the first key frame can be
> >> > P_Picture_Type but there is no preivous frame.) then may cause some
> >> > driver problems
> >>
> >> > (e.g, segment fault on mesa/AMD driver).
> >>
> >> Please also confirm that these driver bugs are fixed.
> >
> > Sorry for late reply. Do you mean this patch should be verified on
> > mesa/AMD environment, or another patch of Meda/AMD driver is needed?
> 
> I believe it is a good idea to add a work-around for a Mesa bug into the
> FFmpeg code-base (not all users will immediately update their graphics driver)
> but only if the Mesa bug is either fixed or at least going to be fixed with
> some certainty.
> 
> The driver should never segfault.

Exactly, a better way should be "return with some error message". 
But I have no AMD GPU on hand, this issue is reported by Mark Thompson when 
https://patchwork.ffmpeg.org/patch/5538/ applied.
Maybe Mark can give some comments. 
BTW, this patch is not just a work-around, it improves the robustness. 
Application should make sure the parameters passing to driver are really valid.

> 
> Carl Eugen
> ___
> 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]lavf/avio: Also print the https warning for missing tls protocol

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 01:15:27AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> On redirection to https, FFmpeg only shows "protocol missing" without
> a hint to what is missing.
> 
> Please comment, Carl Eugen

>  avio.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> e7b346c9ce0c4f07004caec31c40bb561becc6e5  
> 0001-lavf-avio-Print-the-https-error-also-for-missing-tls.patch
> From 8c068d06fa425471590a8ee8765ef510476a180d Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 22 Oct 2017 01:11:55 +0200
> Subject: [PATCH] lavf/avio: Print the https warning also for missing tls
>  protocol.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH]lavf/avio: Also print the https warning for missing tls protocol

[Carl Eugen Hoyos]

2017-10-23 11:30 GMT+02:00 Michael Niedermayer :
> On Sun, Oct 22, 2017 at 01:15:27AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> On redirection to https, FFmpeg only shows "protocol missing" without
>> a hint to what is missing.
>>
>> Please comment, Carl Eugen
>
>>  avio.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> e7b346c9ce0c4f07004caec31c40bb561becc6e5  
>> 0001-lavf-avio-Print-the-https-error-also-for-missing-tls.patch
>> From 8c068d06fa425471590a8ee8765ef510476a180d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sun, 22 Oct 2017 01:11:55 +0200
>> Subject: [PATCH] lavf/avio: Print the https warning also for missing tls
>>  protocol.
>
> LGTM

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop VDA

[Clément Bœsch]

On Fri, Sep 29, 2017 at 06:59:56PM -0300, James Almer wrote:
[...]
> Then IMO we should wait until the major bump (Which is not too far
> away). Leaving a stub object for the symbols and configure clutter
> should be avoided.

Patch applied.

Thanks

-- 
Clément B.


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

Re: [FFmpeg-devel] [RFC] v4l2_m2m: Fix races around freeing data on close

[Jorge Ramirez]

On 10/23/2017 01:47 AM, Mark Thompson wrote:

so let's make this work then and fix the SIGSEGV present in master asap (btw 
this RFC also seg-fault when the above is applied)

Where does that version segfault?  (It doesn't for me.)


the patch will segfault if the changes below are applied to the baseline.

those changes simulate the case where the client doesnt provide the 
height/width; when that happens, since ffmpeg registers for the v4l2 
kernel event which provides the resolution, ffmpeg will have to dequeue 
the old buffers and queue new ones capable of storing the frame to the 
driver (in the code that is handled by reinit/full_reinit.


note that full_reinit has not been implemented properly (I had to close 
the driver to work around a venus issue ...it is an easy fix once I have 
a driver that works)




diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 831fd81..1dd8cf0 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -176,8 +176,8 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
   * by the v4l2 driver; this event will trigger a full pipeline reconfig 
and
   * the proper values will be retrieved from the kernel driver.
   */
-output->height = capture->height = avctx->coded_height;
-output->width = capture->width = avctx->coded_width;
+output->height = capture->height = 0; //avctx->coded_height;
+output->width = capture->width = 0; //avctx->coded_width;

  output->av_codec_id = avctx->codec_id;
  output->av_pix_fmt  = AV_PIX_FMT_NONE;


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

Re: [FFmpeg-devel] [PATCH] mov: fix decode of fragments that overlap in time

[Michael Niedermayer]

On Thu, Oct 12, 2017 at 10:59:23AM -0700, John Stebbins wrote:
> When keyframe intervals of dash segments are not perfectly aligned,
> fragments in the stream can overlap in time. The previous sorting by
> timestamp causes packets to be read out of decode order and results
> in decode errors.
> 
> Insert new "trun" index entries into index_entries in the order that
> the trun are referenced by the sidx.
> ---
>  libavformat/isom.h |  26 +-
>  libavformat/mov.c  | 684 
> -
>  2 files changed, 485 insertions(+), 225 deletions(-)

will apply

can you add a fate test for this ?

thanks

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH 2/3] ffmpeg: add -bitexact flag to simplify enabling bitexact mode in (de)muxer and (de/en)coder

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 01:41:57AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/ffmpeg.h |  1 +
>  fftools/ffmpeg_opt.c | 16 
>  2 files changed, 17 insertions(+)

applied with documentation

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

[FFmpeg-devel] [PATCH] MXF format fix for Sony Station compatibility

[Development]

This patch fixes the MXF format write. This is required for Sony XDCAM
Station and Sony Content Browser compatibility.


Axel Technology development team.




0001-Sony-XDCAM-Fix.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] MXF format fix for Sony Station compatibility

[Carl Eugen Hoyos]

2017-10-23 12:31 GMT+02:00  :
> This patch fixes the MXF format write. This is required for
> Sony XDCAM Station and Sony Content Browser compatibility.

The patch contains trailing whitespace and tabs, both cannot
be committed to the FFmpeg repository.
You can use tools/patcheck to find the issues.

> +mxf_write_local_tag(pb, 4, 0x3308);
> +if (st->codec->pix_fmt == AV_PIX_FMT_YUV420P)
> +avio_wb32(pb, 2);
> +else
> +avio_wb32(pb, 1);

This looks a little suspicious:
What does "2" mean, what does "1" mean?

(And please consider adding braces around "else", makes
future patches in general simpler.)

Is there a reason why this patch does not name an author?

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

Re: [FFmpeg-devel] [PATCH] MXF format fix for Sony Station compatibility

[Carl Eugen Hoyos]

2017-10-23 13:07 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-23 12:31 GMT+02:00  :
>> This patch fixes the MXF format write. This is required for
>> Sony XDCAM Station and Sony Content Browser compatibility.

>> +mxf_write_local_tag(pb, 4, 0x3308);
>> +if (st->codec->pix_fmt == AV_PIX_FMT_YUV420P)
>> +avio_wb32(pb, 2);
>> +else
>> +avio_wb32(pb, 1);
>
> This looks a little suspicious:

See what's done for 0x3302, add a new context variable
v_chroma_sub_sample, set it together with the existing
h_chroma_sub_sample and use it here.

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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[Ronald S. Bultje]

Hi,

On Mon, Oct 23, 2017 at 4:27 AM, Clément Bœsch  wrote:

> On Sun, Oct 22, 2017 at 12:09:04PM -0400, Ronald S. Bultje wrote:
> [...]
> > > > The replacement will never be written if:
> > > > a) nobody cares; AND
> > > > b) we keep delaying the removal
> > > >
> > > > I'm considering veto'ing this patch.
> > >
> > > Personally I'm with Clement in this. The deprecation was poorly
> handled,
> > > and the feature currently has no replacement. Michael uses it for
> > > debugging, so removing it does not seem productive.
> > >
> > > But, also agreeing with Clement, this should absolutely be ported to
> the
> > > codecview filter before the next bump, or it will be removed.
> > >
> >
> > But this is the whole problem. We're stuck in a stalemate between nothing
> > and nobody. As with ffserver, we'll keep postponing this forever more
> until
> > the stalemate is broken.
>
> Well, AFAIK contrary to ffserver, this is not exactly much a hinder for
> further development; MPEG related development is pretty much stalled these
> days
>

You cut the second half of my message. Ask Kieran if the above statement is
true.

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

Re: [FFmpeg-devel] order T-shirts

[Compn]

On Sun, 22 Oct 2017 21:29:52 +0200, Thilo Borgmann
 wrote:
> >> So what do others think about colors? Shall I make a 3-color-sample first?
> >> We might do more than one version.
> >> They open again Tuesday...
> >>
> > 
> > I personally don't think it's a big deal either way, but green logo would
> > be nice, I believe the original logo (and current favicon) was green.
> 
> Okay then I'll try to have the logo in green and white printing. I'd order all
> green printings for the case that green/white printings would be too much 
> extra
> cost (>15/shirt I'd say).

i am fine with green or white. i hope that the green (light green?) is
visible on a black shirt of course.

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

Re: [FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings when decoding DolbyVision

[James Almer]

On 10/23/2017 5:09 AM, Carl Eugen Hoyos wrote:
> 2017-10-23 5:22 GMT+02:00 James Almer :
>> On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch silences the many warnings shown when decoding streams
>>> with DolbyVision content.
>>>
>>> Please comment, Carl Eugen
>>>
>>>
>>> 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch
>>>
>>>
>>> From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sun, 22 Oct 2017 02:17:27 +0200
>>> Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.
>>>
>>> ---
>>>  libavcodec/hevcdec.c |2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>>> index 2e4add2..d5ed9f5 100644
>>> --- a/libavcodec/hevcdec.c
>>> +++ b/libavcodec/hevcdec.c
>>> @@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const 
>>> H2645NAL *nal)
>>>  break;
>>>  case HEVC_NAL_AUD:
>>>  case HEVC_NAL_FD_NUT:
>>> +case 62: // unspecified, used by DolbyVision
>>> +case 63: // unspecified, used by DolbyVision
>>
>> No, the log message should be set to verbose level instead, like
>> inff_hevc_decode_extradata(). It's something of little value for the
>> info level and effectively just spams stderr when trying to decode files
>> with unofficial or currently unsupported NAL units.
> 
> Don't we want users to upload such samples?

Nothing in the current log messages hints the user to provide us with
samples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[James Almer]

On 10/23/2017 5:25 AM, Daniel Kučera wrote:
> 2017-10-21 13:36 GMT+02:00 Jan Ekstrom :
>>
>> This seems to have broken seeking and files ending. FLAC was
>> experienced yesterday but it seems like it's more general. This was
>> reported on the mpv users' channel by sfan5, but I feel like this
>> might be more general than related to just mpv. At first this was
>> thought to be limited to HTTP, but later was found out to be
>> applicable to local files as well.
>>
> 
> 
> Hi Jan,
> 
> please post a test case, ideally as an issue into trac.

https://trac.ffmpeg.org/ticket/6767
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Hendrik Leppkes]

On Mon, Oct 23, 2017 at 3:22 PM, James Almer  wrote:
> On 10/23/2017 5:25 AM, Daniel Kučera wrote:
>> 2017-10-21 13:36 GMT+02:00 Jan Ekstrom :
>>>
>>> This seems to have broken seeking and files ending. FLAC was
>>> experienced yesterday but it seems like it's more general. This was
>>> reported on the mpv users' channel by sfan5, but I feel like this
>>> might be more general than related to just mpv. At first this was
>>> thought to be limited to HTTP, but later was found out to be
>>> applicable to local files as well.
>>>
>>
>>
>> Hi Jan,
>>
>> please post a test case, ideally as an issue into trac.
>
> https://trac.ffmpeg.org/ticket/6767

This appears to be an API break, since those avio callbacks are
basically public API. Previously ret 0 for EOF was perfectly valid
(just like many OS I/O functions also act), and now it needs special
casing. I had to update my own code as well for this breakage.
We should fix the API break somehow.

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

[FFmpeg-devel] [PATCH] avutil/frame: deprecate getters and setters for AVFrame fields

[James Almer]

The fields can be accessed directly, so these are not needed anymore.

Signed-off-by: James Almer 
---
 libavutil/frame.c   |  2 ++
 libavutil/frame.h   | 26 ++
 libavutil/version.h |  3 +++
 3 files changed, 31 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 09dd98a6b5..982fbb5c81 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -31,6 +31,7 @@ static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 AVBufferRef *buf);
 
+#if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_pos)
@@ -42,6 +43,7 @@ MAKE_ACCESSORS(AVFrame, frame, int, decode_error_flags)
 MAKE_ACCESSORS(AVFrame, frame, int, pkt_size)
 MAKE_ACCESSORS(AVFrame, frame, enum AVColorSpace, colorspace)
 MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, color_range)
+#endif
 
 #define CHECK_CHANNELS_CONSISTENCY(frame) \
 av_assert2(!(frame)->channel_layout || \
diff --git a/libavutil/frame.h b/libavutil/frame.h
index fef558ea2f..0c6aab1c02 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -565,36 +565,62 @@ typedef struct AVFrame {
  */
 } AVFrame;
 
+#if FF_API_FRAME_GET_SET
 /**
  * Accessors for some AVFrame fields. These used to be provided for ABI
  * compatibility, and do not need to be used anymore.
  */
+attribute_deprecated
 int64_t av_frame_get_best_effort_timestamp(const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_best_effort_timestamp(AVFrame *frame, int64_t val);
+attribute_deprecated
 int64_t av_frame_get_pkt_duration (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_pkt_duration (AVFrame *frame, int64_t val);
+attribute_deprecated
 int64_t av_frame_get_pkt_pos  (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_pkt_pos  (AVFrame *frame, int64_t val);
+attribute_deprecated
 int64_t av_frame_get_channel_layout   (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_channel_layout   (AVFrame *frame, int64_t val);
+attribute_deprecated
 int av_frame_get_channels (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_channels (AVFrame *frame, int val);
+attribute_deprecated
 int av_frame_get_sample_rate  (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_sample_rate  (AVFrame *frame, int val);
+attribute_deprecated
 AVDictionary *av_frame_get_metadata   (const AVFrame *frame);
+attribute_deprecated
 void  av_frame_set_metadata   (AVFrame *frame, AVDictionary *val);
+attribute_deprecated
 int av_frame_get_decode_error_flags   (const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_decode_error_flags   (AVFrame *frame, int val);
+attribute_deprecated
 int av_frame_get_pkt_size(const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_pkt_size(AVFrame *frame, int val);
 #if FF_API_FRAME_QP
+attribute_deprecated
 int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type);
+attribute_deprecated
 int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int type);
 #endif
+attribute_deprecated
 enum AVColorSpace av_frame_get_colorspace(const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_colorspace(AVFrame *frame, enum AVColorSpace val);
+attribute_deprecated
 enum AVColorRange av_frame_get_color_range(const AVFrame *frame);
+attribute_deprecated
 voidav_frame_set_color_range(AVFrame *frame, enum AVColorRange val);
+#endif
 
 /**
  * Get the name of a colorspace.
diff --git a/libavutil/version.h b/libavutil/version.h
index aa56ad2fbd..7b4ae9beab 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -136,6 +136,9 @@
 #ifndef FF_API_CRYPTO_SIZE_T
 #define FF_API_CRYPTO_SIZE_T(LIBAVUTIL_VERSION_MAJOR < 57)
 #endif
+#ifndef FF_API_FRAME_GET_SET
+#define FF_API_FRAME_GET_SET(LIBAVUTIL_VERSION_MAJOR < 57)
+#endif
 
 
 /**
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Derek Buitenhuis]

On 10/23/2017 3:56 AM, Michael Niedermayer wrote:
> the initialization should be thread safe as it never writes a different
> value in the same spot
> This would avoid the need to alwas hardcode the tables

Still no reason to *not* put it under ff_thread_once, though,
to minimize work done.

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

Re: [FFmpeg-devel] [PATCH] mov: fix decode of fragments that overlap in time

[John Stebbins]

On 10/23/2017 03:24 AM, Michael Niedermayer wrote:
> On Thu, Oct 12, 2017 at 10:59:23AM -0700, John Stebbins wrote:
>> When keyframe intervals of dash segments are not perfectly aligned,
>> fragments in the stream can overlap in time. The previous sorting by
>> timestamp causes packets to be read out of decode order and results
>> in decode errors.
>>
>> Insert new "trun" index entries into index_entries in the order that
>> the trun are referenced by the sidx.
>> ---
>>  libavformat/isom.h |  26 +-
>>  libavformat/mov.c  | 684 
>> -
>>  2 files changed, 485 insertions(+), 225 deletions(-)
> will apply
>
> can you add a fate test for this ?
>
>

I should be able to do that.  I'm a bit busy, so might not happen right away.  
But I should be able to do something
within a week I think.

-- 
John  GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7




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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Mark Thompson]

On 23/10/17 03:56, Michael Niedermayer wrote:
> the initialization should be thread safe as it never writes a different
> value in the same spot

This is not true; please be very careful with assumptions like this.

The C standard calls this a data race and it is undefined behaviour.

It is not just a theoretical concern, either - on architectures with 
destructive write-hint instructions ("fill cache line with unspecified data 
without loading it from memory, because I'm about to overwrite all of it", 
exactly what you want to use (and therefore the compiler will generate) to 
avoid pointless loads when overwriting a large table) other threads can and do 
see different contents transiently when the same data is written to the 
location.

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

[FFmpeg-devel] [PATCH 1/2] avformat: move public AVStream fields up in the struct

[James Almer]

Remove the silly second notice.

Signed-off-by: James Almer 
---
 libavformat/avformat.h | 65 ++
 1 file changed, 28 insertions(+), 37 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index ece1b179f3..7594277f06 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -980,6 +980,34 @@ typedef struct AVStream {
 int event_flags;
 #define AVSTREAM_EVENT_FLAG_METADATA_UPDATED 0x0001 ///< The call resulted in 
updated metadata.
 
+/**
+ * Real base framerate of the stream.
+ * This is the lowest framerate with which all timestamps can be
+ * represented accurately (it is the least common multiple of all
+ * framerates in the stream). Note, this value is just a guess!
+ * For example, if the time base is 1/9 and all frames have either
+ * approximately 3600 or 1800 timer ticks, then r_frame_rate will be 50/1.
+ */
+AVRational r_frame_rate;
+
+/**
+ * String containing paris of key and values describing recommended 
encoder configuration.
+ * Paris are separated by ','.
+ * Keys are separated from values by '='.
+ */
+char *recommended_encoder_configuration;
+
+/**
+ * Codec parameters associated with this stream. Allocated and freed by
+ * libavformat in avformat_new_stream() and avformat_free_context()
+ * respectively.
+ *
+ * - demuxing: filled by libavformat on stream creation or in
+ * avformat_find_stream_info()
+ * - muxing: filled by the caller before avformat_write_header()
+ */
+AVCodecParameters *codecpar;
+
 /*
  * All fields below this line are not part of the public API. They
  * may not be used outside of libavformat and can be changed and
@@ -1064,19 +1092,6 @@ typedef struct AVStream {
 int nb_index_entries;
 unsigned int index_entries_allocated_size;
 
-/**
- * Real base framerate of the stream.
- * This is the lowest framerate with which all timestamps can be
- * represented accurately (it is the least common multiple of all
- * framerates in the stream). Note, this value is just a guess!
- * For example, if the time base is 1/9 and all frames have either
- * approximately 3600 or 1800 timer ticks, then r_frame_rate will be 50/1.
- *
- * Code outside avformat should access this field using:
- * av_stream_get/set_r_frame_rate(stream)
- */
-AVRational r_frame_rate;
-
 /**
  * Stream Identifier
  * This is the MPEG-TS stream identifier +1
@@ -1182,19 +1197,6 @@ typedef struct AVStream {
  */
 int inject_global_side_data;
 
-/*
- * All fields above this line are not part of the public API.
- * Fields below are part of the public API and ABI again.
- *
- */
-
-/**
- * String containing paris of key and values describing recommended 
encoder configuration.
- * Paris are separated by ','.
- * Keys are separated from values by '='.
- */
-char *recommended_encoder_configuration;
-
 /**
  * display aspect ratio (0 if unknown)
  * - encoding: unused
@@ -1209,17 +1211,6 @@ typedef struct AVStream {
  * Must not be accessed in any way by callers.
  */
 AVStreamInternal *internal;
-
-/*
- * Codec parameters associated with this stream. Allocated and freed by
- * libavformat in avformat_new_stream() and avformat_free_context()
- * respectively.
- *
- * - demuxing: filled by libavformat on stream creation or in
- * avformat_find_stream_info()
- * - muxing: filled by the caller before avformat_write_header()
- */
-AVCodecParameters *codecpar;
 } AVStream;
 
 AVRational av_stream_get_r_frame_rate(const AVStream *s);
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] avformat: deprecate getters and setters for AVFormatContext and AVStream fields

[James Almer]

The fields can be accessed directly, so these are not needed anymore.

Signed-off-by: James Almer 
---
 libavformat/avformat.h | 30 +-
 libavformat/utils.c|  4 
 libavformat/version.h  |  3 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7594277f06..b2db234041 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1213,11 +1213,22 @@ typedef struct AVStream {
 AVStreamInternal *internal;
 } AVStream;
 
+#if FF_API_FORMAT_GET_SET
+/**
+ * Accessors for some AVStream fields. These used to be provided for ABI
+ * compatibility, and do not need to be used anymore.
+ */
+attribute_deprecated
 AVRational av_stream_get_r_frame_rate(const AVStream *s);
+attribute_deprecated
 void   av_stream_set_r_frame_rate(AVStream *s, AVRational r);
-struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
+attribute_deprecated
 char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
+attribute_deprecated
 void  av_stream_set_recommended_encoder_configuration(AVStream *s, char 
*configuration);
+#endif
+
+struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
 
 /**
  * Returns the pts of the last muxed packet + its duration
@@ -1889,29 +1900,46 @@ typedef struct AVFormatContext {
 int max_streams;
 } AVFormatContext;
 
+#if FF_API_FORMAT_GET_SET
 /**
  * Accessors for some AVFormatContext fields. These used to be provided for ABI
  * compatibility, and do not need to be used anymore.
  */
+attribute_deprecated
 int av_format_get_probe_score(const AVFormatContext *s);
+attribute_deprecated
 AVCodec * av_format_get_video_codec(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_video_codec(AVFormatContext *s, AVCodec *c);
+attribute_deprecated
 AVCodec * av_format_get_audio_codec(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_audio_codec(AVFormatContext *s, AVCodec *c);
+attribute_deprecated
 AVCodec * av_format_get_subtitle_codec(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_subtitle_codec(AVFormatContext *s, AVCodec *c);
+attribute_deprecated
 AVCodec * av_format_get_data_codec(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_data_codec(AVFormatContext *s, AVCodec *c);
+attribute_deprecated
 int   av_format_get_metadata_header_padding(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_metadata_header_padding(AVFormatContext *s, int c);
+attribute_deprecated
 void *av_format_get_opaque(const AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_opaque(AVFormatContext *s, void *opaque);
+attribute_deprecated
 av_format_control_message av_format_get_control_message_cb(const 
AVFormatContext *s);
+attribute_deprecated
 void  av_format_set_control_message_cb(AVFormatContext *s, 
av_format_control_message callback);
 #if FF_API_OLD_OPEN_CALLBACKS
 attribute_deprecated AVOpenCallback av_format_get_open_cb(const 
AVFormatContext *s);
 attribute_deprecated void av_format_set_open_cb(AVFormatContext *s, 
AVOpenCallback callback);
 #endif
+#endif
 
 /**
  * This function will cause global side data to be injected in the next packet
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6dbc48d54d..8fd7b82c67 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -104,6 +104,7 @@ static int64_t wrap_timestamp(const AVStream *st, int64_t 
timestamp)
 return timestamp;
 }
 
+#if FF_API_FORMAT_GET_SET
 MAKE_ACCESSORS(AVStream, stream, AVRational, r_frame_rate)
 MAKE_ACCESSORS(AVStream, stream, char *, recommended_encoder_configuration)
 MAKE_ACCESSORS(AVFormatContext, format, AVCodec *, video_codec)
@@ -118,6 +119,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
 MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
+#endif
 
 int64_t av_stream_get_end_pts(const AVStream *st)
 {
@@ -215,10 +217,12 @@ static const AVCodec *find_probe_decoder(AVFormatContext 
*s, const AVStream *st,
 return codec;
 }
 
+#if FF_API_FORMAT_GET_SET
 int av_format_get_probe_score(const AVFormatContext *s)
 {
 return s->probe_score;
 }
+#endif
 
 /* an arbitrarily chosen "sane" max packet size -- 50M */
 #define SANE_CHUNK_SIZE (5000)
diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788c36..8765b59435 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -79,6 +79,9 @@
 #ifndef FF_API_OLD_ROTATE_API
 #define FF_API_OLD_ROTATE_API   (LIBAVFORMAT_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_FORMAT_GET_SET
+#define FF_API_FORMAT_GET_SET   (LIBAVFORMAT_VERSION_MAJOR < 59)
+#endif
 
 
 #ifndef FF_API_R_FRAME_RATE
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/libx264: add me_method alias to set X264Context->motion_est

[James Almer]

Replaces the now dropped global option.

Addresses ticket #6771.

Signed-off-by: James Almer 
---
 libavcodec/libx264.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index b11ede6198..b5e04d674d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -958,6 +958,7 @@ static const AVOption options[] = {
 { "vbr",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = X264_NAL_HRD_VBR},  
INT_MIN, INT_MAX, VE, "nal-hrd" },
 { "cbr",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = X264_NAL_HRD_CBR},  
INT_MIN, INT_MAX, VE, "nal-hrd" },
 { "avcintra-class","AVC-Intra class 50/100/200",  
OFFSET(avcintra_class),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 200   , VE},
+{ "me_method","Set motion estimation method", 
OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA, VE, 
"motion-est"},
 { "motion-est",   "Set motion estimation method", 
OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA, VE, 
"motion-est"},
 { "dia",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = X264_ME_DIA },  
INT_MIN, INT_MAX, VE, "motion-est" },
 { "hex",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = X264_ME_HEX },  
INT_MIN, INT_MAX, VE, "motion-est" },
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: add me_method alias to set X264Context->motion_est

[Paul B Mahol]

On 10/23/17, James Almer  wrote:
> Replaces the now dropped global option.
>
> Addresses ticket #6771.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/libx264.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index b11ede6198..b5e04d674d 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -958,6 +958,7 @@ static const AVOption options[] = {
>  { "vbr",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> X264_NAL_HRD_VBR},  INT_MIN, INT_MAX, VE, "nal-hrd" },
>  { "cbr",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> X264_NAL_HRD_CBR},  INT_MIN, INT_MAX, VE, "nal-hrd" },
>  { "avcintra-class","AVC-Intra class 50/100/200",
> OFFSET(avcintra_class),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 200   , VE},
> +{ "me_method","Set motion estimation method",
> OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA,
> VE, "motion-est"},
>  { "motion-est",   "Set motion estimation method",
> OFFSET(motion_est),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, X264_ME_TESA,
> VE, "motion-est"},
>  { "dia",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = X264_ME_DIA },
> INT_MIN, INT_MAX, VE, "motion-est" },
>  { "hex",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = X264_ME_HEX },
> INT_MIN, INT_MAX, VE, "motion-est" },
> --
> 2.14.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Am 20.10.17 um 17:16 schrieb Thilo Borgmann:
> Hi,
> 
>>> Some guys at the VDD asked for FFmpeg T-shirts.
>>> I'd like to do a new T-shirt order. The shirts could be given to
>>> multimedia devs who stop at one of our next booths.
>>>
>>> My idea is to order 25 shirts:
>>>
>>> 1*S
>>> 5*M
>>> 10*L
>>> 7*XL
>>> 2*XXL
>>>
>>> Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
>>> So, we are talking about a maximum price of 562,50 Euro (excluding
>>> delivery costs).
>>
>> since I had my own shirt exchanged during VDD, I don't even have one for the 
>> next conf thing I might go to so I hereby revive this thread. I promised 
>> some shirts to Mozilla, Nicolas reminded me of getting one for him also 
>> during VDD...
>>
>> I went to a nice shop today and they can offer a quite nice price for shirts 
>> based on Thomas' last design with breast and neck printings. So I ordered 
>> four samples for just 12€ each! I had the unprinted shirts in my hand and 
>> the quality is good in spite of that nice price. I even think that 12€ per 
>> shirt can't be beaten by Liu's offer to have them printed in China... 
>> shipping should eat up anything we might save by China-shirts.
>>
>> I'll get the printed samples tomorrow and one of these will definitely find 
>> its way to Nicolas.
>> If we're happy with the samples, I'd like to order a pile of shirts for us 
>> and that could be the amount Thomas listed in the beginning of this thread. 
>> I'd also like to add some more for the shirts I've already promised to send 
>> to several people. This means I expect something like 350-400€ including 
>> shipping to various places.
>>
>> This is even cheaper than what Thomas estimation was so I hope nobody 
>> objects :)
>>
>> This shop can also do stitching on basecaps, with a little longer waiting 
>> time also the coffee mugs.
>> I also talked about stickers that would come in a similar manner like the 
>> nice ones we got from the Kodi guy some years ago and that are almost gone. 
>> However I want to get the shirts done first.
> 
> I got the samples done and I think they are good! You can find pictures of 
> what the design is here:
> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
> 
> I add to the numbers for our stock of shirts (list quoted above) the 
> additional need I have for already assigned/promised shirts and subtract the 
> number of samples I made, what comes out are the following numbers:
> 
> S1
> M6
> L   11
> XL  11
> 2XL  3
> 
> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
> Then there will be some costs for shipping, so I expect a low 400+ € total.
> 
> If there are no objections, I will order them and ship early next week :)

Because I've already got a lot of requests for shirts - all from either 
developers or well-known users - I think I should give you an update on the 
raise of the overall numbers:

S1
M7
L   15
XL  15
2XL  3

This will leave 25 shirts with us and the remaining shirts will be shipped to 7 
different countries.
So we should end up with 492€ (+multicolor maybe) for the shirts + shipping.

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

Re: [FFmpeg-devel] [PATCH] swscale: more accurate DITHER_COPY macro for full and limited range

[Michael Niedermayer]

On Fri, Oct 06, 2017 at 05:33:22PM +0200, Mateusz wrote:
> Fixed DITHER_COPY macro (only C code), updated FATE tests.
> 
> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is 
> there.
> 
> Please review.
> 
> Mateusz
> 

>  libswscale/swscale_unscaled.c  |   73 
> +++--
>  tests/ref/vsynth/vsynth1-ffvhuff420p12 |4 -
>  tests/ref/vsynth/vsynth1-vc2-420p10|4 -
>  tests/ref/vsynth/vsynth1-vc2-420p12|4 -
>  tests/ref/vsynth/vsynth2-ffvhuff420p12 |4 -
>  tests/ref/vsynth/vsynth2-vc2-420p10|4 -
>  tests/ref/vsynth/vsynth2-vc2-420p12|4 -
>  tests/ref/vsynth/vsynth3-ffvhuff420p12 |4 -
>  tests/ref/vsynth/vsynth_lena-ffvhuff420p12 |4 -
>  tests/ref/vsynth/vsynth_lena-vc2-420p10|4 -
>  tests/ref/vsynth/vsynth_lena-vc2-420p12|4 -
>  11 files changed, 58 insertions(+), 55 deletions(-)
> 3a5b24e81786299d53ab52b07eabc26dcec2766e  
> 0001-swscale-more-accurate-DITHER_COPY-macro-for-full-and.patch
> From d870ba10aa4b3520fc30215fbbd57565faa13df4 Mon Sep 17 00:00:00 2001
> From: Mateusz 
> Date: Fri, 6 Oct 2017 16:49:54 +0200
> Subject: [PATCH] swscale: more accurate DITHER_COPY macro for full and limited
>  range

applied

thanks


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

[Paul B Mahol]

On 9/14/17, Richard Ling  wrote:
> Hi,
>
> This patch adds a filter to normalize (contrast stretch) RGB video.
> Comments welcome.
>
> R.
>
> From f08f132ecd79718d0ce6fb07f99c84ab5dd52ee4 Mon Sep 17 00:00:00 2001
> From: Richard Ling 
> Date: Thu, 14 Sep 2017 13:18:50 +1000
> Subject: [PATCH] avfilter: add normalize filter
>
> ---
>  doc/filters.texi   |  79 +
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_normalize.c | 415
> +
>  4 files changed, 496 insertions(+)
>  create mode 100644 libavfilter/vf_normalize.c
>

What's status of this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libopus: Add channel mapping 2 support in libopusdec

[Dale Curtis]

Any update on this patch? We've been carrying it in Chrome for a while.

- dale

On Fri, Apr 7, 2017 at 11:14 AM, Felicia Lim 
wrote:

> Hi,
>
> Just wanted to follow up and check if there any changes I should add to
> this patch?
>
> Thanks for taking a look.
>
> Felicia
>
> On Mon, Mar 27, 2017 at 5:35 PM Felicia Lim  wrote:
>
> > Hi all,
> >
> > Here is another patch to decode Opus ambisonics files using channel
> > mapping 2 [1], this time in libopusdec.c.
> >
> > Please let me know if there are any concerns.
> >
> > Thanks,
> > Felicia
> >
> > [1] *https://trac.tools.ietf.org/html/draft-ietf-codec-
> ambisonics-02#section-3.1
> >  ambisonics-02#section-3.1>*
> >
> ___
> 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

[FFmpeg-devel] [PATCH] lavfi/paletteuse: fix to support transparency

[Bjorn Roche]

This patch enables paletteuse to identify the transparency in incoming
video and tag transparent pixels on outgoing video with the correct
index from the palette.

This requires tracking the transparency index in the palette,
establishing an alpha threshold below which a pixel is considered
transparent and above which the pixel is considered opaque, and
additional changes to track the alpha value throughout the conversion
process.

This change is a partial fix for https://trac.ffmpeg.org/ticket/4443
However, animated GIFs are still output incorrectly due to a bug
in gif optimization which does not correctly handle transparency.
---
 doc/filters.texi|   7 ++
 libavfilter/vf_paletteuse.c | 195 
 2 files changed, 131 insertions(+), 71 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 57189c77b0..690a60f569 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11531,6 +11531,13 @@ The option must be an integer value in the range 
[0,5]. Default is @var{2}.
 @item diff_mode
 If set, define the zone to process
 
+@item threshold
+Sets the alpha threshold for transparency. Alpha values above this threshold
+will be treated as completely opaque, and values below this threshold will be
+treated as completely transparent.
+
+The option must be an integer value in the range [0,255]. Default is 128.
+
 @table @samp
 @item rectangle
 Only the changing rectangle will be reprocessed. This is similar to GIF
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index 79a0672891..40ec3b2a78 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -56,7 +56,7 @@ enum diff_mode {
 };
 
 struct color_node {
-uint8_t val[3];
+uint8_t val[4];
 uint8_t palette_id;
 int split;
 int left_id, right_id;
@@ -86,6 +86,8 @@ typedef struct PaletteUseContext {
 struct cache_node cache[CACHE_SIZE];/* lookup cache */
 struct color_node map[AVPALETTE_COUNT]; /* 3D-Tree (KD-Tree with K=3) for 
reverse colormap */
 uint32_t palette[AVPALETTE_COUNT];
+int transparency_index; /* index in the palette of transparency. -1 if 
there is no transparency in the palette. */
+int trans_thresh;
 int palette_loaded;
 int dither;
 int new;
@@ -116,6 +118,7 @@ static const AVOption paletteuse_options[] = {
 { "bayer_scale", "set scale for bayer dithering", OFFSET(bayer_scale), 
AV_OPT_TYPE_INT, {.i64=2}, 0, 5, FLAGS },
 { "diff_mode",   "set frame difference mode", OFFSET(diff_mode),   
AV_OPT_TYPE_INT, {.i64=DIFF_MODE_NONE}, 0, NB_DIFF_MODE-1, FLAGS, "diff_mode" },
 { "rectangle", "process smallest different rectangle", 0, 
AV_OPT_TYPE_CONST, {.i64=DIFF_MODE_RECTANGLE}, INT_MIN, INT_MAX, FLAGS, 
"diff_mode" },
+{ "threshold", "set the alpha threshold for transparency.", 
OFFSET(trans_thresh), AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },
 
 /* following are the debug options, not part of the official API */
 { "debug_kdtree", "save Graphviz graph of the kdtree in specified file", 
OFFSET(dot_filename), AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN, CHAR_MAX, 
FLAGS },
@@ -157,34 +160,43 @@ static int query_formats(AVFilterContext *ctx)
 
 static av_always_inline int dither_color(uint32_t px, int er, int eg, int eb, 
int scale, int shift)
 {
-return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 24  ) << 24
+ | av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<>  8 & 0xff) + ((eg * scale) / (1<= trans_thresh && c2[0] >= trans_thresh) {
+return dr*dr + dg*dg + db*db;
+} else {
+return 255*255 + 255*255 + 255*255;
+}
 }
 
-static av_always_inline uint8_t colormap_nearest_bruteforce(const uint32_t 
*palette, const uint8_t *rgb)
+static av_always_inline uint8_t colormap_nearest_bruteforce(const uint32_t 
*palette, const uint8_t *argb, const int trans_thresh)
 {
 int i, pal_id = -1, min_dist = INT_MAX;
 
 for (i = 0; i < AVPALETTE_COUNT; i++) {
 const uint32_t c = palette[i];
 
-if ((c & 0xff00) == 0xff00) { // ignore transparent entry
-const uint8_t palrgb[] = {
+if ( c >> 24 >= trans_thresh ) { // ignore transparent entry
+const uint8_t palargb[] = {
+palette[i]>>24 & 0xff,
 palette[i]>>16 & 0xff,
 palette[i]>> 8 & 0xff,
 palette[i] & 0xff,
 };
-const int d = diff(palrgb, rgb);
+const int d = diff(palargb, argb, trans_thresh);
 if (d < min_dist) {
 pal_id = i;
 min_dist = d;
@@ -203,13 +215,14 @@ struct nearest_color {
 static void colormap_nearest_node(const struct color_node *map,
   const int node_pos,
   const uint8_t *target,
+  const int trans_thresh,
  

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Bjorn Roche]

On Sat, Oct 21, 2017 at 4:00 PM, Clément Bœsch  wrote:

> On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote:
> > 2017-10-21 21:43 GMT+02:00 Clément Bœsch :
> > > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
> > >> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
> > >>
> > >> > Aside from these nitpicks, I'm still concerned about how it's going
> > >> > to conflict with GIF encoding where the transparent color is
> actually
> > >> > used as a mean of not updating pixels from previous frames.
> > >>
> > >> But is this really related to this patch?
> > >
> > > Maybe not, but we need to keep that in mind and not make a
> > > hasty decision wrt how we handle the transparency, because
> > > it might makes future related development much harder.
> >
> > Given that this is a libavfilter-only patch and we can reproduce
> > the issue without using libavfilter, I am not completely
> > convinced, but this is of course your decision.
> >
>
> Yes it should be fine, I just want to be sure that using
> palettegen/paletteuse will not create input streams that the limited GIF
> encoder does not handle well because it doesn't make a difference between
> "transparency flavours". If paletteuse starts inserting transparent colors
> that are not meant to be used for the frame-diff system it could become a
> problem.
>

There is a bug in the GIF encoder. I have a fix for that issue as well.

In the meantime, I have submitted another patch to address the concerns
that are specific to this fix.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[Sasi Inguva]

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c   | 15 +++-
 tests/fate/mov.mak  |  4 ++
 tests/ref/fate/mov-invalid-elst-entry-count | 57 +
 3 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count

diff --git a/libavformat/mov.c b/libavformat/mov.c
index b22a116140..424293ad93 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4597,6 +4597,7 @@ static int mov_read_elst(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 {
 MOVStreamContext *sc;
 int i, edit_count, version;
+int64_t elst_entry_size;
 
 if (c->fc->nb_streams < 1 || c->ignore_editlist)
 return 0;
@@ -4605,6 +4606,15 @@ static int mov_read_elst(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 version = avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */
 edit_count = avio_rb32(pb); /* entries */
+atom.size -= 8;
+
+elst_entry_size = version == 1 ? 20 : 12;
+if (atom.size != edit_count * elst_entry_size &&
+c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d for 
elst atom of size: %"PRId64" bytes.\n",
+   edit_count, atom.size + 8);
+return AVERROR_INVALIDDATA;
+}
 
 if (!edit_count)
 return 0;
@@ -4617,17 +4627,20 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return AVERROR(ENOMEM);
 
 av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n", 
c->fc->nb_streams - 1, edit_count);
-for (i = 0; i < edit_count && !pb->eof_reached; i++) {
+for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached; i++) {
 MOVElst *e = &sc->elst_data[i];
 
 if (version == 1) {
 e->duration = avio_rb64(pb);
 e->time = avio_rb64(pb);
+atom.size -= 16;
 } else {
 e->duration = avio_rb32(pb); /* segment duration */
 e->time = (int32_t)avio_rb32(pb); /* media time */
+atom.size -= 8;
 }
 e->rate = avio_rb32(pb) / 65536.0;
+atom.size -= 4;
 av_log(c->fc, AV_LOG_TRACE, "duration=%"PRId64" time=%"PRId64" 
rate=%f\n",
e->duration, e->time, e->rate);
 
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index cfdada7a2e..ef250a12d8 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -6,6 +6,7 @@ FATE_MOV = fate-mov-3elist \
fate-mov-1elist-ends-last-bframe \
fate-mov-2elist-elist1-ends-bframe \
fate-mov-3elist-encrypted \
+   fate-mov-invalid-elst-entry-count \
fate-mov-gpmf-remux \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
@@ -39,6 +40,9 @@ fate-mov-1elist-ends-last-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-1e
 # Makes sure that we handle timestamps of packets in case of multiple edit 
lists with one of them ending on a B-frame correctly.
 fate-mov-2elist-elist1-ends-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-2elist-elist1-ends-bframe.mov
 
+# Makes sure that we handle invalid edit list entry count correctly.
+fate-mov-invalid-elst-entry-count: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/invalid_elst_entry_count.mov
+
 fate-mov-aac-2048-priming: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_packets 
-print_format compact $(TARGET_SAMPLES)/mov/aac-2048-priming.mov
 
 fate-mov-zombie: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_streams 
-show_packets -show_frames -bitexact -print_format compact 
$(TARGET_SAMPLES)/mov/white_zombie_scrunch-part.mov
diff --git a/tests/ref/fate/mov-invalid-elst-entry-count 
b/tests/ref/fate/mov-invalid-elst-entry-count
new file mode 100644
index 00..13b575816b
--- /dev/null
+++ b/tests/ref/fate/mov-invalid-elst-entry-count
@@ -0,0 +1,57 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 640x480
+#sar 0: 1/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,1,   460800, 549730883a0b56e6accaf021903daecf
+0,  1,  1,1,   460800, 783389b4342d4be925fc5244791e760a
+0,  2,  2,1,   460800, 8384af6426d94a2077930c93013e09ad
+0,  3,  3,1,   460800, 9380a1d9ecacf5b3105383c1c8083188
+0,  4,  4,1,   460800, eb28174acfceb868b9058757bed049c5
+0,  5,  5,1,   460800, 9732bd4a58884dbf2be48d819433130f
+0,  6,  6,1,   460800, 0c553fb530cf042eb84f5b13817a96a6
+0,  7,  7,1,   460800, 621f02aded5e35fa1f373afd3ed283bd
+0,  8,  8,1,   460800, c76167c6bda91f657708c88252ea315d
+0,  9,  9,1,   460800, 872df2d8c522e2440ddd04bca7dce497
+0, 10, 10,1,   460800, 6ee9154e48c5132ad4ba122b255bd2bb
+0, 11, 11,  

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[Sasi Inguva]

On Fri, Oct 20, 2017 at 4:26 PM, Michael Niedermayer  wrote:

> On Wed, Oct 18, 2017 at 08:12:50PM -0700, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c   | 16 +++-
> >  tests/fate/mov.mak  |  6 ++-
> >  tests/ref/fate/mov-invalid-elst-entry-count | 57
> +
> >  3 files changed, 76 insertions(+), 3 deletions(-)
> >  create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index b22a116140..8d2602c739 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -4596,7 +4596,7 @@ free_and_return:
> >  static int mov_read_elst(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> >  {
> >  MOVStreamContext *sc;
> > -int i, edit_count, version;
> > +int i, edit_count, version, elst_entry_size;
> >
> >  if (c->fc->nb_streams < 1 || c->ignore_editlist)
> >  return 0;
> > @@ -4605,6 +4605,15 @@ static int mov_read_elst(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >  version = avio_r8(pb); /* version */
> >  avio_rb24(pb); /* flags */
> >  edit_count = avio_rb32(pb); /* entries */
>
> > +atom.size -= 8;
>
> > +
> > +elst_entry_size = version == 1 ? 20 :  12;
> > +if (atom.size != edit_count * elst_entry_size &&
>
> the edit_count * elst_entry_size can overflow
>
> Thanks. Changed elst_entry_size to int64

>
> > +c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
> > +av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d
> for elst atom of size: %"PRId64" bytes.\n",
> > +   edit_count, atom.size + 8);
> > +return AVERROR_INVALIDDATA;
> > +}
> >
> >  if (!edit_count)
> >  return 0;
> > @@ -4617,17 +4626,20 @@ static int mov_read_elst(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >  return AVERROR(ENOMEM);
> >
> >  av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n",
> c->fc->nb_streams - 1, edit_count);
> > -for (i = 0; i < edit_count && !pb->eof_reached; i++) {
> > +for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached;
> i++) {
> >  MOVElst *e = &sc->elst_data[i];
>
> isnt atom.size < 0 an error condition ?
> this could would not error out in that case
> is that intended ?
>
> we are comparing that atom.size is exactly equal to edit_count *
elst_entry_size . The for loop will decrease elst_entry_size bytes from
atom.size in each iteration, so it can only be < 0 iff  it wasn't exactly
equal to edit_count * elst_entry_size .


> [...]
> --
> 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
>
> ___
> 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] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Niki Bowe]

On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-19 20:46 GMT+02:00 Nikolas Bowe :
> > Found via fuzzing.
> > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has
> many NALUs
> > Before this change:
> >   $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)"  ./ffprobe
> /tmp/poc 2>&1 | tail -n 1
> > 2158192 Max Resident Set Size (Kb)
> > After this change:
> >   $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)"  ./ffprobe
> /tmp/poc 2>&1 | tail -n 1
> > 1046812 Max Resident Set Size (Kb)
>
> This does not look like a fix for a "quadratic" memory consumption or
> do I misunderstand?
>

Before this patch, for each NALU in the packet, rbsp_buffer would be sized
from the start of the NALU to the end of the packet, not the end of the
NALU.
This would occur for each NALU in the packet. Total memory allocated in all
the rbsp_buffers for all the NALUs in the packet would be N + (N+x1) +
(N+x2) + ...
This is quadratic in the number of NALUs in the packet.

The fuzzer's proof of concept file is a bit extreme. It has over 2000 small
NALUs in one packet.
An easier way to trigger this would be to put some small NALUs (perhaps
SEI) in front of large IDRs. Each small NALU added to the front doubles the
total memory allocated for rbsp_buffers for that packet.


> Does the patch have a measurable speed impact?
>
>
Is there a standard set of benchmarks I can run?

For typical videos the speed impact is small, due to NALU fitting in cache,
but for videos with many large NALUs there can be some slowdown.

Here is the decode time for some typical video and some extreme cases,
taking the result with the best user+system time of 3 runs.
Measured via
for i in {1..3}; do /usr/bin/time -f "\t%U User CPU seconds\n\t%S System
CPU seconds\n\t%M Max Resident Set Size (Kb)" ./ffmpeg -loglevel quiet
-nostats -threads 1 -i $file -f null - ; done

Tears of Steel HD
Somewhat typical HD short movie. 728 MB, 8314kb/s
  no patch:
113.69 User CPU seconds
0.60 System CPU seconds
44784 Max Resident Set Size (Kb)
  patch:
112.52 User CPU seconds
0.40 System CPU seconds
44780 Max Resident Set Size (Kb)
  1% slower.

Tears of Steel 4k
Somewhat typical high-ish bitrate 4k movie. 73244 kb/s.
  no patch:
682.70 User CPU seconds
2.99 System CPU seconds
104420 Max Resident Set Size (Kb)
  patch:
716.06 User CPU seconds
4.08 System CPU seconds
103632 Max Resident Set Size (Kb)
  5% slower.

random 50 Mbps i-only video I had laying around
  no patch:
421.33 User CPU seconds
1.21 System CPU seconds
28284 Max Resident Set Size (Kb)
  patch
423.00 User CPU seconds
1.98 System CPU seconds
27300 Max Resident Set Size (Kb)
   <1% slower

foo_200M.ts
10 seconds of /dev/urandom at 4k, encoded at 200Mbps using 2 pass, 2 second
GOP (it actually used P frames even though its encoding random noise).
This is
  no patch:
11.52 User CPU seconds
0.19 System CPU seconds
68668 Max Resident Set Size (Kb)
  patch:
11.92 User CPU seconds
0.15 System CPU seconds
68656 Max Resident Set Size (Kb)
  3% slower

large_nals.ts
This is an extreme case. I tried to come up with a very bad case for
slowdown. Every packets has very large VCL NALUs.
Generated via ./ffmpeg -f rawvideo -video_size 3840x2160 -pixel_format
yuv420p -framerate 30 -i /dev/urandom -t 5 -c:v libx264 -preset ultrafast
-crf 0 -g 1 -y large_nals.ts
Each packet in large_nals.ts is close to 20 MB. There's 5 NALUs per packet:
9 (AUD) 7 (SPS) 8 (PPS) 6(SEI) 5 (IDR slice).
This is of course unrealistically large at over 4 Gbps, but it should be a
decent worst case example.
  no patch:
46.76 User CPU seconds
3.10 System CPU seconds
199148 Max Resident Set Size (Kb)
  patch:
54.42 User CPU seconds
1.79 System CPU seconds
156720 Max Resident Set Size (Kb)
  13% slower when there are very large NALUs (also 21% less memory usage)



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



-- 

Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137 <(408)%20565-5137>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Michael Niedermayer]

Hi

On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
> On 23/10/17 03:56, Michael Niedermayer wrote:
> > the initialization should be thread safe as it never writes a different
> > value in the same spot
> 
> This is not true; please be very careful with assumptions like this.
> 
> The C standard calls this a data race and it is undefined behaviour.

Thats interresting, we definitly do not want undefined behavior
can you quote the relevant parts of the C standard
which make writing the same value, a data race ?

I was not aware of this if its true.
Also i dont immedeatly see this in the "latest" draft i am looking at
atm

What i see is this:
4 Two expression evaluations conflict if one of them modifies a memory location 
and the
  other one reads or modifies the same memory location.
...
25 The execution of a program contains a data race if it contains two 
conflicting actions in
   different threads, at least one of which is not atomic, and neither happens 
before the
   other. Any such data race results in undefined behavior.

This seems carefully worded to not include writing the same value.
As "modification" implies change which does not occur when writing the
same value.


> 
> It is not just a theoretical concern, either - on architectures with 
> destructive write-hint instructions ("fill cache line with unspecified data 
> without loading it from memory, because I'm about to overwrite all of it", 
> exactly what you want to use (and therefore the compiler will generate) to 
> avoid pointless loads when overwriting a large table) other threads can and 
> do see different contents transiently when the same data is written to the 
> location.

This might violate:
27 NOTE 13 Compiler transformations that introduce assignments to a potentially 
shared memory location
   that would not be modified by the abstract machine are generally precluded 
by this standard, since such an
   assignment might overwrite another assignment by a different thread in cases 
in which an abstract machine
   execution would not have encountered a data race. This includes 
implementations of data member
   assignment that overwrite adjacent members in separate memory locations. We 
also generally preclude
   reordering of atomic loads in cases in which the atomics in question may 
alias, since this may violate the
   "visible sequence" rules.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

[Carl Eugen Hoyos]

2017-10-24 1:43 GMT+02:00 Niki Bowe :
> On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos 
> wrote:

>> Does the patch have a measurable speed impact?
>>
> Is there a standard set of benchmarks I can run?
>
> For typical videos the speed impact is small, due to NALU fitting in cache,
> but for videos with many large NALUs there can be some slowdown.

(5% overall slowdown would make every patch unacceptable
but I doubt this is the case.)

Use the TIMER makros from libavutil/timer.h, put them around all
calls to ff_h2645_extract_rbsp().

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

[FFmpeg-devel] [PATCH]lavc/dvbsub: Allow 256 colour encoding

[Carl Eugen Hoyos]

Hi!

Trying to encode 256-colour subtitles to dvbsub currently fails in the
"region" section, a hunk of Joolz' patch was not committed six years
ago.
Attached patch has two hunks: The forgotten hunk from the original
patch and further up a fix that I created now (to be committed
separately):
The line separator from the ETSI DVB blue book was missing for rle8 encodings.

Please comment, Carl Eugen
From 06fd4904b6aa04c3ab8e056ef4f6be4a89093a1c Mon Sep 17 00:00:00 2001
From: JULIAN GARDNER 
Date: Tue, 24 Oct 2017 01:59:51 +0200
Subject: [PATCH] lavc/dvbsub: Allow 256 colour encoding.

Fixes ticket #6769.
---
 libavcodec/dvbsub.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dvbsub.c b/libavcodec/dvbsub.c
index 3cdbade..8cce702 100644
--- a/libavcodec/dvbsub.c
+++ b/libavcodec/dvbsub.c
@@ -239,9 +239,9 @@ static void dvb_encode_rle8(uint8_t **pq,
 x += len;
 }
 /* end of line */
-//   end of 8-bit/pixel_code_string
-*q++ = 0x00;
+//  end of 8-bit/pixel_code_string
 *q++ = 0x00;
+*q++ = 0xf0;
 bitmap += linesize;
 }
 *pq = q;
@@ -342,6 +342,9 @@ static int encode_dvb_subtitles(DVBSubtitleContext *s,
 } else if (h->rects[region_id]->nb_colors <= 16) {
 /* 4 bpp, standard encoding */
 bpp_index = 1;
+} else if (h->rects[region_id]->nb_colors <= 256) {
+/* 8 bpp, standard encoding */
+bpp_index = 2;
 } else {
 return -1;
 }
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/2] ffserver: Fix off by 1 error in path

[Michael Niedermayer]

On Mon, Oct 23, 2017 at 10:44:07AM +0200, Clément Bœsch wrote:
> On Mon, Oct 23, 2017 at 10:42:53AM +0200, Clément Bœsch wrote:
> [...]
> > how about changing the whole chunk with (untested):
> > 
> > prog = av_strdup(my_program_name);
> > dirname = av_dirname(prog);
> > pathname = *dirname ? av_asprintf("%s/%s", dirname, "ffmpeg")
> > : av_asprintf("ffmpeg")
> > av_free(filepath);
>   
>   prog

works fine, will push with this

thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Mark Thompson]

On 24/10/17 00:52, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
>> On 23/10/17 03:56, Michael Niedermayer wrote:
>>> the initialization should be thread safe as it never writes a different
>>> value in the same spot
>>
>> This is not true; please be very careful with assumptions like this.
>>
>> The C standard calls this a data race and it is undefined behaviour.
> 
> Thats interresting, we definitly do not want undefined behavior
> can you quote the relevant parts of the C standard
> which make writing the same value, a data race ?
> 
> I was not aware of this if its true.
> Also i dont immedeatly see this in the "latest" draft i am looking at
> atm
> 
> What i see is this:
> 4 Two expression evaluations conflict if one of them modifies a memory 
> location and the
>   other one reads or modifies the same memory location.
> ...
> 25 The execution of a program contains a data race if it contains two 
> conflicting actions in
>different threads, at least one of which is not atomic, and neither 
> happens before the
>other. Any such data race results in undefined behavior.
> 
> This seems carefully worded to not include writing the same value.
> As "modification" implies change which does not occur when writing the
> same value.

All writes are modifications.

See section 3.1 note 2:
"""
3 NOTE 2   "Modify"€™ includes the case where the new value being stored is the 
same as the previous value.
"""

>> It is not just a theoretical concern, either - on architectures with 
>> destructive write-hint instructions ("fill cache line with unspecified data 
>> without loading it from memory, because I'm about to overwrite all of it", 
>> exactly what you want to use (and therefore the compiler will generate) to 
>> avoid pointless loads when overwriting a large table) other threads can and 
>> do see different contents transiently when the same data is written to the 
>> location.
> 
> This might violate:
> 27 NOTE 13 Compiler transformations that introduce assignments to a 
> potentially shared memory location
>that would not be modified by the abstract machine are generally precluded 
> by this standard, since such an
>assignment might overwrite another assignment by a different thread in 
> cases in which an abstract machine
>execution would not have encountered a data race. This includes 
> implementations of data member
>assignment that overwrite adjacent members in separate memory locations. 
> We also generally preclude
>reordering of atomic loads in cases in which the atomics in question may 
> alias, since this may violate the
>"visible sequence" rules.

Yes, in order to match the behaviour of the abstract machine the transformation 
requires that the region in question is:
* Not atomic: if atomic, another thread would be allowed to observe the 
intermediate state directly.
* Overwritten entirely: if not overwritten entirely, other data would be 
touched which should not be, and that could be observed by another thread.
* Without external ordering: if external synchronisation were present, another 
thread would be able to read values on one or other side of that boundary 
without a data race and observe an inconsistent state.

The CRC table construction satisfies all of these conditions.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/2] tests/ffserver.regression.ref: update checksums to what ffserver currently produces

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 05:11:21PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/ffserver.regression.ref | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

will apply

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] order T-shirts

[Lou Logan]

On Sat, Oct 21, 2017, at 07:53 AM, Lou Logan wrote:
> I'll attach the SVG file when I get back home on Monday or Tuesday.

SVG attached. Let me know if you need changes or if the printer needs a
different format.

These shirts will be silk screened, right? If so, the green is intended
to be "PMS 354C Spring Green Pantone Solid Coated" which is a little
brighter than the original green color so it stands out more from the
black shirt.

The black part is of course just there so the lettering is visible. If
they prefer a false white for the letters I can do that.

I envisioned the design to be horizontally centered on the front of the
shirt, chest high, design width of 15-18 cm, back of shirt plain. Mockup
attached.

Thanks.

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
> On 24/10/17 00:52, Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
> >> On 23/10/17 03:56, Michael Niedermayer wrote:
> >>> the initialization should be thread safe as it never writes a different
> >>> value in the same spot
> >>
> >> This is not true; please be very careful with assumptions like this.
> >>
> >> The C standard calls this a data race and it is undefined behaviour.
> > 
> > Thats interresting, we definitly do not want undefined behavior
> > can you quote the relevant parts of the C standard
> > which make writing the same value, a data race ?
> > 
> > I was not aware of this if its true.
> > Also i dont immedeatly see this in the "latest" draft i am looking at
> > atm
> > 
> > What i see is this:
> > 4 Two expression evaluations conflict if one of them modifies a memory 
> > location and the
> >   other one reads or modifies the same memory location.
> > ...
> > 25 The execution of a program contains a data race if it contains two 
> > conflicting actions in
> >different threads, at least one of which is not atomic, and neither 
> > happens before the
> >other. Any such data race results in undefined behavior.
> > 
> > This seems carefully worded to not include writing the same value.
> > As "modification" implies change which does not occur when writing the
> > same value.
> 
> All writes are modifications.
> 
> See section 3.1 note 2:
> """
> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored is 
> the same as the previous value.
> """

That resolves the difference between our interpretation

thanks

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

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[James Almer]

On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
> On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>> On 24/10/17 00:52, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
 On 23/10/17 03:56, Michael Niedermayer wrote:
> the initialization should be thread safe as it never writes a different
> value in the same spot

 This is not true; please be very careful with assumptions like this.

 The C standard calls this a data race and it is undefined behaviour.
>>>
>>> Thats interresting, we definitly do not want undefined behavior
>>> can you quote the relevant parts of the C standard
>>> which make writing the same value, a data race ?
>>>
>>> I was not aware of this if its true.
>>> Also i dont immedeatly see this in the "latest" draft i am looking at
>>> atm
>>>
>>> What i see is this:
>>> 4 Two expression evaluations conflict if one of them modifies a memory 
>>> location and the
>>>   other one reads or modifies the same memory location.
>>> ...
>>> 25 The execution of a program contains a data race if it contains two 
>>> conflicting actions in
>>>different threads, at least one of which is not atomic, and neither 
>>> happens before the
>>>other. Any such data race results in undefined behavior.
>>>
>>> This seems carefully worded to not include writing the same value.
>>> As "modification" implies change which does not occur when writing the
>>> same value.
>>
>> All writes are modifications.
>>
>> See section 3.1 note 2:
>> """
>> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored is 
>> the same as the previous value.
>> """
> 
> That resolves the difference between our interpretation
> 
> thanks

Should i push this, or does someone want to give ff_thread_once() a try?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd()

[James Almer]

This prevents potential ABI issues with GetByteContext.

Signed-off-by: James Almer 
---
 libavcodec/exif.c | 16 +---
 libavcodec/exif.h |  6 --
 libavcodec/mjpegdec.c |  2 +-
 libavcodec/webp.c |  2 +-
 libavformat/avidec.c  |  4 ++--
 5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/libavcodec/exif.c b/libavcodec/exif.c
index 07ce1741c2..2874772db4 100644
--- a/libavcodec/exif.c
+++ b/libavcodec/exif.c
@@ -92,7 +92,7 @@ static int exif_decode_tag(void *logctx, GetByteContext 
*gbytes, int le,
 // store metadata or proceed with next IFD
 ret = ff_tis_ifd(id);
 if (ret) {
-ret = avpriv_exif_decode_ifd(logctx, gbytes, le, depth + 1, metadata);
+ret = ff_exif_decode_ifd(logctx, gbytes, le, depth + 1, metadata);
 } else {
 const char *name = exif_get_tag_name(id);
 char *use_name   = (char*) name;
@@ -119,8 +119,8 @@ static int exif_decode_tag(void *logctx, GetByteContext 
*gbytes, int le,
 }
 
 
-int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
-   int depth, AVDictionary **metadata)
+int ff_exif_decode_ifd(void *logctx, GetByteContext *gbytes,
+   int le, int depth, AVDictionary **metadata)
 {
 int i, ret;
 int entries;
@@ -140,3 +140,13 @@ int avpriv_exif_decode_ifd(void *logctx, GetByteContext 
*gbytes, int le,
 // return next IDF offset or 0x0 or a value < 0 for failure
 return ff_tget_long(gbytes, le);
 }
+
+int avpriv_exif_decode_ifd(void *logctx, const uint8_t *buf, int size,
+   int le, int depth, AVDictionary **metadata)
+{
+GetByteContext gb;
+
+bytestream2_init(&gb, buf, size);
+
+return ff_exif_decode_ifd(logctx, &gb, le, depth, metadata);
+}
diff --git a/libavcodec/exif.h b/libavcodec/exif.h
index 5f09208b9d..314065b4b2 100644
--- a/libavcodec/exif.h
+++ b/libavcodec/exif.h
@@ -164,7 +164,9 @@ static const struct exif_tag tag_list[] = { // JEITA 
CP-3451 EXIF specification:
 
 /** Recursively decodes all IFD's and
  *  adds included TAGS into the metadata dictionary. */
-int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
-   int depth, AVDictionary **metadata);
+int avpriv_exif_decode_ifd(void *logctx, const uint8_t *buf, int size,
+   int le, int depth, AVDictionary **metadata);
+int ff_exif_decode_ifd(void *logctx, GetByteContext *gbytes,
+   int le, int depth, AVDictionary **metadata);
 
 #endif /* AVCODEC_EXIF_H */
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5b2409755c..d980ac99a1 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1867,7 +1867,7 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
 
 // read 0th IFD and store the metadata
 // (return values > 0 indicate the presence of subimage metadata)
-ret = avpriv_exif_decode_ifd(s->avctx, &gbytes, le, 0, 
&s->exif_metadata);
+ret = ff_exif_decode_ifd(s->avctx, &gbytes, le, 0, 
&s->exif_metadata);
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "mjpeg: error decoding EXIF 
data\n");
 }
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index efa864a6f1..c8475faa2d 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1504,7 +1504,7 @@ static int webp_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 }
 
 bytestream2_seek(&exif_gb, ifd_offset, SEEK_SET);
-if (avpriv_exif_decode_ifd(avctx, &exif_gb, le, 0, &exif_metadata) 
< 0) {
+if (ff_exif_decode_ifd(avctx, &exif_gb, le, 0, &exif_metadata) < 
0) {
 av_log(avctx, AV_LOG_ERROR, "error decoding Exif data\n");
 goto exif_end;
 }
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index b8a31dcff2..3ff515d492 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -401,10 +401,10 @@ static int avi_extract_stream_metadata(AVFormatContext 
*s, AVStream *st)
 // skip 4 byte padding
 bytestream2_skip(&gb, 4);
 offset = bytestream2_tell(&gb);
-bytestream2_init(&gb, data + offset, data_size - offset);
 
 // decode EXIF tags from IFD, AVI is always little-endian
-return avpriv_exif_decode_ifd(s, &gb, 1, 0, &st->metadata);
+return avpriv_exif_decode_ifd(s, data + offset, data_size - offset,
+  1, 0, &st->metadata);
 break;
 case MKTAG('C', 'A', 'S', 'I'):
 avpriv_request_sample(s, "RIFF stream data tag type CASI (%u)", tag);
-- 
2.14.2

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

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Hi,

Am 24.10.17 um 02:43 schrieb Lou Logan:
> On Sat, Oct 21, 2017, at 07:53 AM, Lou Logan wrote:
>> I'll attach the SVG file when I get back home on Monday or Tuesday.
> 
> SVG attached. Let me know if you need changes or if the printer needs a
> different format.

then we are talking about a completely different design.


> These shirts will be silk screened, right? If so, the green is intended
> to be "PMS 354C Spring Green Pantone Solid Coated" which is a little
> brighter than the original green color so it stands out more from the
> black shirt.

No. They offer different techniques, though.


> The black part is of course just there so the lettering is visible. If
> they prefer a false white for the letters I can do that.
> 
> I envisioned the design to be horizontally centered on the front of the
> shirt, chest high, design width of 15-18 cm, back of shirt plain. Mockup
> attached.

I'll do go there and get an offer for that design and ask about possible print 
techniques.

Depending on that, we should decide what to order. 
I'd appreciate to hear more opinions about the design question in the mean time.

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

[Jun Zhao]

From db142742fa9adb74dea2b376db618075c86a5731 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 24 Oct 2017 13:25:21 +0800
Subject: [PATCH] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering
 setting.

vseq.max_num_ref_frames not init before the VUI
max_dec_frame_buffering setting, so use sps.max_dec_frame_buffering
in this case.

Signed-off-by: Jun Zhao 
Signed-off-by: Wang, Yi A 
---
 libavcodec/vaapi_encode_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 9a4bd53da1..1d43e934ef 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -441,7 +441,7 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 sps->vui.log2_max_mv_length_horizontal = 16;
 sps->vui.log2_max_mv_length_vertical   = 16;
 sps->vui.max_num_reorder_frames= (ctx->b_per_p > 0);
-sps->vui.max_dec_frame_buffering   = vseq->max_num_ref_frames;
+sps->vui.max_dec_frame_buffering   = sps->max_num_ref_frames;
 
 pps->nal_unit_header.nal_ref_idc = 3;
 pps->nal_unit_header.nal_unit_type = H264_NAL_PPS;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

[Jun Zhao]

On 2017/10/24 13:42, Jun Zhao wrote:
The commit comment is wrong, will re-submit V2 to fix the typo.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Dixit, Vishwanath]

>On 10/22/17, 1:28 PM, "Liu Steven"  wrote:
>Two patches should be ok, add FATE cases please :)
I am not familiar with FATE and I could not find any sample hlsenc FATE cases 
in ffmpeg workspace. Could you please help me with this? If some basic hlsenc 
tests are available, I can extend them further for variant stream creation and 
master playlist creation.

Regards,
Vishwanath
 
 

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

[FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting.

[Jun Zhao]

From 24b8e1c70fd4bf4eb76404fd9e2020fe3bbd90cb Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 24 Oct 2017 13:25:21 +0800
Subject: [PATCH V2] lavc/vaapi_encode_h264: correct VUI
 max_dec_frame_buffering setting.

vseq.max_num_ref_frames not init before the VUI
max_dec_frame_buffering setting, so use sps.max_num_ref_frames
in this case.

Signed-off-by: Jun Zhao 
Signed-off-by: Wang, Yi A 
---
 libavcodec/vaapi_encode_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 9a4bd53da1..1d43e934ef 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -441,7 +441,7 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 sps->vui.log2_max_mv_length_horizontal = 16;
 sps->vui.log2_max_mv_length_vertical   = 16;
 sps->vui.max_num_reorder_frames= (ctx->b_per_p > 0);
-sps->vui.max_dec_frame_buffering   = vseq->max_num_ref_frames;
+sps->vui.max_dec_frame_buffering   = sps->max_num_ref_frames;
 
 pps->nal_unit_header.nal_ref_idc = 3;
 pps->nal_unit_header.nal_unit_type = H264_NAL_PPS;
-- 
2.14.1

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