Re: [FFmpeg-devel] [PATCH] avdevice/decklink_enc: print preroll and buffer size

[Gyan Doshi]

On 24-08-2018 12:12 AM, Marton Balint wrote:



On Thu, 23 Aug 2018, Gyan Doshi wrote:


Plan to push tomorrow.


Ok, LGTM.


Thanks.

Pushed as d0b48a960448cc8eb0e2c86e0804b14bdcb3e751


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

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: improve read error handling

[myp...@gmail.com]

On Fri, Aug 24, 2018 at 5:38 AM Rodger Combs  wrote:
>
> We previously could fail to check errors entirely, or misinterpret read
errors
> as normal EOFs.
> ---
>  libavformat/mpegts.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 37a6aa8bff..1350213d39 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2475,6 +2475,8 @@ static int mpegts_resync(AVFormatContext *s, int
seekback, const uint8_t *curren
>
>  for (i = 0; i < ts->resync_size; i++) {
>  c = avio_r8(pb);
> +if (pb->error)
> +return pb->error;
>  if (avio_feof(pb))
>  return AVERROR_EOF;
>  if (c == 0x47) {
> @@ -2498,8 +2500,13 @@ static int read_packet(AVFormatContext *s, uint8_t
*buf, int raw_packet_size,
>
>  for (;;) {
>  len = ffio_read_indirect(pb, buf, TS_PACKET_SIZE, data);
> -if (len != TS_PACKET_SIZE)
> -return len < 0 ? len : AVERROR_EOF;
> +if (len != TS_PACKET_SIZE) {
> +if (len < 0)
> +return len;
> +if (pb->error)
> +return pb->error;
> +return AVERROR_EOF;
> +}
>  /* check packet sync byte */
>  if ((*data)[0] != 0x47) {
>  /* find a new packet start */
> @@ -2670,6 +2677,8 @@ static int mpegts_read_header(AVFormatContext *s)
>  /* read the first 8192 bytes to get packet size */
>  pos = avio_tell(pb);
>  len = avio_read(pb, buf, sizeof(buf));
> +if (len < 0)
> +return len;
>  ts->raw_packet_size = get_packet_size(buf, len);
>  if (ts->raw_packet_size <= 0) {
>  av_log(s, AV_LOG_WARNING, "Could not detect TS packet size,
defaulting to non-FEC/DVHS\n");
> --
As I understand, only after avio_xxx return < 0 to check pb->error, now we
coding like:
   len = avio_xxx(pb);
   if (len < 0)
return len;
if (pb->error)
return pb->error;

It's stranger way for me, consider Unix API read(2), we just check the
error after -1 is returned
(
http://man7.org/linux/man-pages/man2/read.2.html
)

we usually catch the error
/ error
number like:

len =  read(fd, buf, buf_size);
if (len < 0)
   handle the error with error number.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/flvdec: don't propagate empty extradata

[James Almer]

Fixes ticket #7379

Signed-off-by: James Almer 
---
 libavformat/flvdec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 93c7f85237..a2dea464e3 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -753,6 +753,9 @@ static int flv_read_close(AVFormatContext *s)
 
 static int flv_get_extradata(AVFormatContext *s, AVStream *st, int size)
 {
+if (!size)
+return 0;
+
 av_freep(>codecpar->extradata);
 if (ff_get_extradata(s, st->codecpar, s->pb, size) < 0)
 return AVERROR(ENOMEM);
@@ -763,6 +766,9 @@ static int flv_get_extradata(AVFormatContext *s, AVStream 
*st, int size)
 static int flv_queue_extradata(FLVContext *flv, AVIOContext *pb, int stream,
int size)
 {
+if (!size)
+return 0;
+
 av_free(flv->new_extradata[stream]);
 flv->new_extradata[stream] = av_mallocz(size +
 AV_INPUT_BUFFER_PADDING_SIZE);
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/opus_parser: Handle complete frames flag.

[Hendrik Leppkes]

On Thu, Aug 23, 2018 at 10:43 PM James Almer  wrote:
>
> On 8/21/2018 7:47 PM, James Almer wrote:
> > On 8/20/2018 3:35 PM, Jacob Trimble wrote:
> >> I am not entirely sure what this flag is supposed to be, since there
> >> is no documentation where it is defined.  But this was suggested by
> >> James Almer as a fix for my encrypted Opus problems and several other
> >> codec parsers do the same thing.
> >
> > It's a flag that lets the parser know what kind of frames it's getting.
> > libavformat will set it if the source is a demuxer that guarantees the
> > propagation of complete frames, like mp4, Matroska and Ogg.
> >
> > Applied, thanks.
>
> Had to revert this as it broke packet timestamp and duration generation
> for all Opus streams in Matroska and probably other containers.
> You can reproduce it with the mka test vectors in the FATE sample suite
> by doing a codec copy to the framecrc pseudo muxer. Decoding was
> apparently unaffected, so FATE didn't detect any regression.
>
> I don't know how to work around the issues you had with encrypted files
> if not with this. Maybe the Opus packet parsing could be done by the
> Matroska demuxer, much like the Ogg demuxer does (The only container
> apparently not negatively affected by the commit i just reverted).

You could probably fix that by refactoring opus_find_frame_end to
split the frame boundary finding and the actual packet header parsing
(which sets the duration info).

But it might be more interesting why it fails with encrypted streams
in the first place. Does it encrypt the entire frame, including frame
headers? Because if that would be the case, that change would not help
anylonger.
Maybe if a demuxer can know that, it should just set a flag to disable
parsing entirely then.

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

Re: [FFmpeg-devel] make work (live) libsrt

[myp...@gmail.com]

On Fri, Aug 24, 2018 at 2:55 AM Marton Balint  wrote:
>
>
>
> On Thu, 23 Aug 2018, myp...@gmail.com wrote:
>
> > On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu  wrote:
> >>
> >> Hello,
> >>
> >> I get errors when I try to send a live srt stream that the first packet is
> >> too big:
> >> 21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
> >> maximum allowed 1316
> >>
> >> Here are example commands for server and client:
> >> ffmpeg -re -i ~/Downloads/ToS-4k-1920.mov -vcodec libx264 -g 50 -refs 1 -s
> >> 640x360 -b:v 1000k -acodec aac -b:a 64k -flush_packets 0 -f mpegts "srt://
> >> 127.0.0.1:?mode=listener"
> >> ffplay srt://127.0.0.1:
> >>
> >> A patch that fully solves the issue is:
> >> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> >> index 0f9529d263..156a4776e2 100644
> >> --- a/libavformat/libsrt.c
> >> +++ b/libavformat/libsrt.c
> >> @@ -412,6 +412,8 @@ static int libsrt_open(URLContext *h, const char *uri,
> >> int flags)
> >>  return AVERROR_UNKNOWN;
> >>  }
> >>
> >> +h->max_packet_size = 1316;
> >> +
> >>  /* SRT options (srt/srt.h) */
> >>  p = strchr(uri, '?');
> >>  if (p) {
> >>
> >> How would you like this option to be made work in a way that can be
> >> accepted in ffmpeg?
> >> Is there a way to change the max packet size without this patch?
> >>
> > In your case, I don't think hard coding max packet size == 1316 is not
> > a good idea in loopback device, and after deep in the srt
> > library(https://github.com/Haivision/srt) source code, I think srt
> > library need to fix the hardcode about packet size limition.
>
> I can't think of a scenario where limiting the packet size actually causes
> problems, but if you insist on not limiting it in general, then the max
> packet size should be settable using an option, same way it is for UDP.
> (pkt_size option). I'd suggest using 1316 as default, because that
> is the more common (and currently the only working) use case...
>
> Thanks,
> Marton
I agree with you, giving an option like pkt_size and using 1316 as the
default in this case is a better way to fix this issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] examples/vaapi_dec_scaling: init export

[myp...@gmail.com]

On Fri, Aug 24, 2018 at 6:54 AM Mark Thompson  wrote:
>
> On 23/08/18 01:44, myp...@gmail.com wrote:
> > On Wed, Aug 22, 2018 at 5:51 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2018-08-22 2:42 GMT+02:00, myp...@gmail.com :
> >>> On Tue, Aug 21, 2018 at 4:45 PM Carl Eugen Hoyos  
> >>> wrote:
> 
>  2018-06-11 13:22 GMT+02:00, Jun Zhao :
> 
> > + * Copyright (c) 2018 Jun Zhao
> > + *
> > + * VA-API Acceleration API (video decoding/scaling) sample
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> 
>  This is not an ideal license for doc/examples.
> >>>
> >>> I didn't realize this problem, any other license be suggested? MIT ?
> >>
> >> I think so, yes.
> >>
> > Will change the license and update the other vaapi_xxx sample (after
> > asking the other related contributor with mail), Thanks.
>
> I agree that all of my changes to hw_decode.c, vaapi_encode.c, 
> vaapi_transcode.c in doc/examples can be relicensed to MIT.
>
> (I'm not sure anything other than b0d9eab7 is nontrivial enough to matter, 
> but the above is clear.)
>
> Thanks,
>
> - Mark
Thanks a lot, Mark.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] mpeg4video: Add Studio DPCM support

[Kieran Kunhya]

0001-mpeg4video-Add-Studio-DPCM-support.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 38/41] vaapi_encode: Let the reconstructed frame pool be sized dynamically

[Rostislav Pehlivanov]

On Thu, 23 Aug 2018 at 00:49, Mark Thompson  wrote:

> No supported encode driver requires the pool to be fixed-size, so just
> remove this constraint.
> ---
>  libavcodec/vaapi_encode.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index d03bd1925e..e20280065c 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1721,9 +1721,6 @@ static av_cold int
> vaapi_encode_create_recon_frames(AVCodecContext *avctx)
>  ctx->recon_frames->sw_format = recon_format;
>  ctx->recon_frames->width = ctx->surface_width;
>  ctx->recon_frames->height= ctx->surface_height;
> -// At most three IDR/I/P frames and two runs of B frames can be in
> -// flight at any one time.
> -ctx->recon_frames->initial_pool_size = 3 + 2 * ctx->b_per_p;
>
>  err = av_hwframe_ctx_init(ctx->recon_frames_ref);
>  if (err < 0) {
> --
> 2.18.0
>
> ___
> 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] [PATCH 1/2] avcodec/libopusenc: support encoding packets of sizes bigger than 60ms

[Rostislav Pehlivanov]

On Thu, 23 Aug 2018 at 23:18, James Almer  wrote:

> Packets of sizes 80ms, 100ms and 120ms can be encoded since libopus 1.2
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/libopusenc.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 4ae81b0bb2..7c025a66d7 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -271,12 +271,22 @@ static av_cold int
> libopus_encode_init(AVCodecContext *avctx)
>  case 960:
>  case 1920:
>  case 2880:
> +#ifdef OPUS_FRAMESIZE_120_MS
> +case 3840:
> +case 4800:
> +case 5760:
> +#endif
>  opus->opts.packet_size =
>  avctx->frame_size  = frame_size * avctx->sample_rate / 48000;
>  break;
>  default:
>  av_log(avctx, AV_LOG_ERROR, "Invalid frame duration: %g.\n"
> -   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40
> or 60.\n",
> +   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40"
> +#ifdef OPUS_FRAMESIZE_120_MS
> +   ", 60, 80, 100 or 120.\n",
> +#else
> +   " or 60.\n",
> +#endif
> opus->opts.frame_duration);
>  return AVERROR(EINVAL);
>  }
> @@ -463,10 +473,10 @@ static int libopus_encode(AVCodecContext *avctx,
> AVPacket *avpkt,
>  memset(audio, 0, opus->opts.packet_size * sample_size);
>  }
>
> -/* Maximum packet size taken from opusenc in opus-tools. 60ms packets
> - * consist of 3 frames in one packet. The maximum frame size is 1275
> +/* Maximum packet size taken from opusenc in opus-tools. 120ms packets
> + * consist of 6 frames in one packet. The maximum frame size is 1275
>   * bytes along with the largest possible packet header of 7 bytes. */
> -if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 3 + 7) *
> opus->stream_count, 0)) < 0)
> +if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 6 + 7) *
> opus->stream_count, 0)) < 0)
>  return ret;
>
>  if (avctx->sample_fmt == AV_SAMPLE_FMT_FLT)
> @@ -534,7 +544,7 @@ static const AVOption libopus_options[] = {
>  { "voip",   "Favor improved speech intelligibility",   0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_VOIP },0, 0,
> FLAGS, "application" },
>  { "audio",  "Favor faithfulness to the input", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_AUDIO },   0, 0,
> FLAGS, "application" },
>  { "lowdelay",   "Restrict to only the lowest delay modes", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_RESTRICTED_LOWDELAY }, 0, 0,
> FLAGS, "application" },
> -{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 60.0,
> FLAGS },
> +{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 120.0,
> FLAGS },
>  { "packet_loss","Expected packet loss percentage",
>  OFFSET(packet_loss),AV_OPT_TYPE_INT,   { .i64 = 0 },0,   100,
> FLAGS },
>  { "vbr","Variable bit rate mode",
> OFFSET(vbr),AV_OPT_TYPE_INT,   { .i64 = 1 },0,   2,
> FLAGS, "vbr" },
>  { "off","Use constant bit rate", 0,
> AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, FLAGS, "vbr" },
> --
> 2.18.0
>
> ___
> 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] [PATCH] examples/vaapi_dec_scaling: init export

[Mark Thompson]

On 23/08/18 01:44, myp...@gmail.com wrote:
> On Wed, Aug 22, 2018 at 5:51 PM Carl Eugen Hoyos  wrote:
>>
>> 2018-08-22 2:42 GMT+02:00, myp...@gmail.com :
>>> On Tue, Aug 21, 2018 at 4:45 PM Carl Eugen Hoyos  wrote:

 2018-06-11 13:22 GMT+02:00, Jun Zhao :

> + * Copyright (c) 2018 Jun Zhao
> + *
> + * VA-API Acceleration API (video decoding/scaling) sample
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.

 This is not an ideal license for doc/examples.
>>>
>>> I didn't realize this problem, any other license be suggested? MIT ?
>>
>> I think so, yes.
>>
> Will change the license and update the other vaapi_xxx sample (after
> asking the other related contributor with mail), Thanks.

I agree that all of my changes to hw_decode.c, vaapi_encode.c, 
vaapi_transcode.c in doc/examples can be relicensed to MIT.

(I'm not sure anything other than b0d9eab7 is nontrivial enough to matter, but 
the above is clear.)

Thanks,

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

[FFmpeg-devel] [PATCH 1/2] avcodec/libopusenc: support encoding packets of sizes bigger than 60ms

[James Almer]

Packets of sizes 80ms, 100ms and 120ms can be encoded since libopus 1.2

Signed-off-by: James Almer 
---
 libavcodec/libopusenc.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 4ae81b0bb2..7c025a66d7 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -271,12 +271,22 @@ static av_cold int libopus_encode_init(AVCodecContext 
*avctx)
 case 960:
 case 1920:
 case 2880:
+#ifdef OPUS_FRAMESIZE_120_MS
+case 3840:
+case 4800:
+case 5760:
+#endif
 opus->opts.packet_size =
 avctx->frame_size  = frame_size * avctx->sample_rate / 48000;
 break;
 default:
 av_log(avctx, AV_LOG_ERROR, "Invalid frame duration: %g.\n"
-   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40 or 
60.\n",
+   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40"
+#ifdef OPUS_FRAMESIZE_120_MS
+   ", 60, 80, 100 or 120.\n",
+#else
+   " or 60.\n",
+#endif
opus->opts.frame_duration);
 return AVERROR(EINVAL);
 }
@@ -463,10 +473,10 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket 
*avpkt,
 memset(audio, 0, opus->opts.packet_size * sample_size);
 }
 
-/* Maximum packet size taken from opusenc in opus-tools. 60ms packets
- * consist of 3 frames in one packet. The maximum frame size is 1275
+/* Maximum packet size taken from opusenc in opus-tools. 120ms packets
+ * consist of 6 frames in one packet. The maximum frame size is 1275
  * bytes along with the largest possible packet header of 7 bytes. */
-if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 3 + 7) * 
opus->stream_count, 0)) < 0)
+if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 6 + 7) * 
opus->stream_count, 0)) < 0)
 return ret;
 
 if (avctx->sample_fmt == AV_SAMPLE_FMT_FLT)
@@ -534,7 +544,7 @@ static const AVOption libopus_options[] = {
 { "voip",   "Favor improved speech intelligibility",   0, 
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_VOIP },0, 0, 
FLAGS, "application" },
 { "audio",  "Favor faithfulness to the input", 0, 
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_AUDIO },   0, 0, 
FLAGS, "application" },
 { "lowdelay",   "Restrict to only the lowest delay modes", 0, 
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_RESTRICTED_LOWDELAY }, 0, 0, 
FLAGS, "application" },
-{ "frame_duration", "Duration of a frame in milliseconds", 
OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 60.0, FLAGS },
+{ "frame_duration", "Duration of a frame in milliseconds", 
OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 120.0, FLAGS },
 { "packet_loss","Expected packet loss percentage", 
OFFSET(packet_loss),AV_OPT_TYPE_INT,   { .i64 = 0 },0,   100,  FLAGS },
 { "vbr","Variable bit rate mode",  OFFSET(vbr),
AV_OPT_TYPE_INT,   { .i64 = 1 },0,   2,FLAGS, "vbr" },
 { "off","Use constant bit rate", 0, AV_OPT_TYPE_CONST, { 
.i64 = 0 }, 0, 0, FLAGS, "vbr" },
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 2/2] avformat/movenc: support Opus packets with more than 60ms of audio when writing the Sample Group Description Box

[James Almer]

Fixes assertion failures when trying to mux such streams.

Signed-off-by: James Almer 
---
 libavformat/movenc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 8ad7026741..1b1d765f7d 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2365,9 +2365,8 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, 
MOVTrack *track)
decoded. */
 if (roll_samples_remaining > 0)
 distance = 0;
-/* Verify distance is a minimum of 2 (60ms) packets and a maximum 
of
-   32 (2.5ms) packets. */
-av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
+/* Verify distance is a maximum of 32 (2.5ms) packets. */
+av_assert0(distance <= 32);
 if (i && distance == sgpd_entries[entries].roll_distance) {
 sgpd_entries[entries].count++;
 } else {
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH v3 32/41] vaapi_encode_h265: Improve profile support

[James Almer]

On 8/22/2018 8:45 PM, Mark Thompson wrote:
> Set profile compatibility/constraint flags properly (including the
> constraint flags used for RExt profiles, as all streams we can currently
> generate are RExt-compatible), and use that to add support for the "Main
> Intra" and "Main 10 Intra" RExt subprofiles (for which we can re-use the
> existing Main and Main10 VAAPI profiles).
> ---
>  libavcodec/Makefile|  2 +-
>  libavcodec/vaapi_encode_h265.c | 70 ++
>  2 files changed, 56 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index d07a9073af..756779ec16 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -373,7 +373,7 @@ OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec_h2645.o
>  OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o   \
>hevc_data.o
>  OBJS-$(CONFIG_HEVC_RKMPP_DECODER)  += rkmppdec.o
> -OBJS-$(CONFIG_HEVC_VAAPI_ENCODER)  += vaapi_encode_h265.o
> +OBJS-$(CONFIG_HEVC_VAAPI_ENCODER)  += h265_profile_level.o 
> vaapi_encode_h265.o

Wont this fail until the next patch is committed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Currently numerical option values are misinterpreted in vf_interlace filter.
Patch attached.

Regards,
Thomas


0001-avfilter-vf_interlace-fix-numerical-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb_bsf: don't fail on extradata with too few arrays

[Rodger Combs]

I've been given a sample that does this. Not sure exactly why, but the decoder
ignores it and plays normally.
---
 libavcodec/hevc_mp4toannexb_bsf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/hevc_mp4toannexb_bsf.c 
b/libavcodec/hevc_mp4toannexb_bsf.c
index 09bce5b34c..fb4ea34a93 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -52,6 +52,11 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
 num_arrays  = bytestream2_get_byte();
 
 for (i = 0; i < num_arrays; i++) {
+if (bytestream2_get_bytes_left() < 3) {
+av_log(ctx, AV_LOG_WARNING, "Extradata contained fewer arrays than 
indicated\n");
+break;
+}
+
 int type = bytestream2_get_byte() & 0x3f;
 int cnt  = bytestream2_get_be16();
 
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 2/2] lavc/hevc_mp4toannexb_bsf: warn if a NAL size would overflow the buffer

[Rodger Combs]

This didn't actually cause a buffer overread previously, but it could result
in the end of a NAL being filled with zeros silently.
---
 libavcodec/hevc_mp4toannexb_bsf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/hevc_mp4toannexb_bsf.c 
b/libavcodec/hevc_mp4toannexb_bsf.c
index fb4ea34a93..c40308f367 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -70,6 +70,10 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
 
 for (j = 0; j < cnt; j++) {
 int nalu_len = bytestream2_get_be16();
+if (nalu_len < 1 || bytestream2_get_bytes_left() < nalu_len) {
+av_log(ctx, AV_LOG_WARNING, "Extradata NAL ended 
prematurely\n");
+goto done;
+}
 
 if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX - 
new_extradata_size) {
 ret = AVERROR_INVALIDDATA;
@@ -86,6 +90,7 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
 }
 }
 
+done:
 av_freep(>par_out->extradata);
 ctx->par_out->extradata  = new_extradata;
 ctx->par_out->extradata_size = new_extradata_size;
-- 
2.18.0

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

[FFmpeg-devel] [PATCH] lavf/mpegts: improve read error handling

[Rodger Combs]

We previously could fail to check errors entirely, or misinterpret read errors
as normal EOFs.
---
 libavformat/mpegts.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 37a6aa8bff..1350213d39 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2475,6 +2475,8 @@ static int mpegts_resync(AVFormatContext *s, int 
seekback, const uint8_t *curren
 
 for (i = 0; i < ts->resync_size; i++) {
 c = avio_r8(pb);
+if (pb->error)
+return pb->error;
 if (avio_feof(pb))
 return AVERROR_EOF;
 if (c == 0x47) {
@@ -2498,8 +2500,13 @@ static int read_packet(AVFormatContext *s, uint8_t *buf, 
int raw_packet_size,
 
 for (;;) {
 len = ffio_read_indirect(pb, buf, TS_PACKET_SIZE, data);
-if (len != TS_PACKET_SIZE)
-return len < 0 ? len : AVERROR_EOF;
+if (len != TS_PACKET_SIZE) {
+if (len < 0)
+return len;
+if (pb->error)
+return pb->error;
+return AVERROR_EOF;
+}
 /* check packet sync byte */
 if ((*data)[0] != 0x47) {
 /* find a new packet start */
@@ -2670,6 +2677,8 @@ static int mpegts_read_header(AVFormatContext *s)
 /* read the first 8192 bytes to get packet size */
 pos = avio_tell(pb);
 len = avio_read(pb, buf, sizeof(buf));
+if (len < 0)
+return len;
 ts->raw_packet_size = get_packet_size(buf, len);
 if (ts->raw_packet_size <= 0) {
 av_log(s, AV_LOG_WARNING, "Could not detect TS packet size, defaulting 
to non-FEC/DVHS\n");
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation

[Michael Niedermayer]

On Thu, Aug 16, 2018 at 03:07:50PM +0800, Linjie Fu wrote:
> Fix the live stream encoding problem using qsv when the first frame
> is not an IDR frame.
> 
> Add the extradata information when the IDR frame is missing in the
> first GOP.
> 
> Fix the bug reported in  ticket #6418.
> 
> [PATCH V2] Fix the coding style.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/h264_mp4toannexb_bsf.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
> b/libavcodec/h264_mp4toannexb_bsf.c
> index 794c82e650..fbb9f1fe20 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -33,6 +33,7 @@ typedef struct H264BSFContext {
>  int32_t  pps_offset;
>  uint8_t  length_size;
>  uint8_t  new_idr;
> +uint8_t  new_nal_slice;
>  uint8_t  idr_sps_seen;
>  uint8_t  idr_pps_seen;
>  int  extradata_parsed;
> @@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *out)
> buf, nal_size, 1)) < 0)
>  goto fail;
>  s->new_idr = 0;
> +s->new_nal_slice = 1;
>  /* if only SPS has been seen, also insert PPS */
>  } else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && 
> s->idr_sps_seen && !s->idr_pps_seen) {
>  if (s->pps_offset == -1) {
> @@ -253,6 +255,12 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *out)
>  ctx->par_out->extradata + 
> s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
>  buf, nal_size, 1)) < 0)
>  goto fail;
> +} else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE == 
> unit_type && !s->idr_sps_seen && !s->idr_pps_seen){
> +av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE when there is 
> no IDR.\n");
> +if ((ret = alloc_and_copy(out, ctx->par_out->extradata, 
> ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
> +goto fail;
> +s->new_nal_slice = 1;
> +s->new_idr = 0;

The commit message is insufficient
this adds the extradata if new_idr is set not just in the absence of IDR at
the begin

also teh addded code is identical to the first if() just a different NAL is
checked for, this code duplication is not a good idea in already complex
code

thx

[...]

-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:58 GMT+02:00, Carl Eugen Hoyos :
> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos :
>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>>> From 100x real-time decoding to 138x real-time decoding for 320x240
>>> video.
>>
>> On x86_64 I get an even better improvement, on x86_32
>> decoding gets slower by approximately 10%.
>> Without the patch, decoding is faster on x86_32 than
>> x86_64 here...
>
> Using vanilla gcc-6.4.
>
> clang 3.4:
> 5% slower with patch on x86_32
>>40% faster with patch on x86_64
> x86_32 again faster than x86_64 without patch.

On Linux ppc, gcc 7.2.1
64bit: 580 -> 740 fps
32bit: ~730fps, both with and without the patch

On Linux aarch64, gcc 4.8
358 -> 492 fps

Not sure if I can find a reliable arm 32bit target.
(Only mobile phones)

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

Re: [FFmpeg-devel] [PATCH 01/12] avformat/mxfenc: automatically update descriptors klv size

[Baptiste Coudurier]

Hey Carl,

On Wed, Aug 22, 2018 at 12:00 PM, Carl Eugen Hoyos 
wrote:

> 2018-07-06 19:17 GMT+02:00, Carl Eugen Hoyos :
> > 2018-07-04 20:35 GMT+02:00, Baptiste Coudurier
> > :
> >> ---
> >>  libavformat/mxfenc.c | 80 +---
> >>  1 file changed, 39 insertions(+), 41 deletions(-)
> >
> > Does any of the patches fix ticket #6693?
>
> Ping?
>
> Or #6781?


I haven't tested, so I don't know.

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

[FFmpeg-devel] [PATCH] ffmpeg.c: add an option "detail_stats" to allow ffmpeg to output stats for each stream

[Wang Cao]

From: Wang Cao 

Add an option "detail_stats" to ffmpeg to output stats for each video/audio 
streams and each ouptut file ffmpeg output log in print_report. The format of 
stats is unchanged.

Signed-off-by: Wang Cao 
---
 doc/ffmpeg.texi  |  4 
 fftools/ffmpeg.c | 53 +++-
 fftools/ffmpeg.h |  1 +
 fftools/ffmpeg_opt.c |  4 +++-
 4 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 3717f22d42..53a5be9791 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1623,6 +1623,10 @@ rtp stream. (Requires at least one of the output formats 
to be rtp).
 Allows discarding specific streams or frames of streams at the demuxer.
 Not all demuxers support this.
 
+@item -detail_stats (@emph{global})
+Allows printing stats for each output stream and output file at the end of
+processing.
+
 @table @option
 @item none
 Discard no frame.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2459374f08..2bd057ace1 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1530,17 +1530,28 @@ static int reap_filters(int flush)
 return 0;
 }
 
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
 {
 uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
 uint64_t subtitle_size = 0;
 uint64_t data_size = 0;
+int64_t total_size;
 float percent = -1.0;
 int i, j;
 int pass1_used = 1;
-
-for (i = 0; i < nb_output_streams; i++) {
+int nb_display_streams = enable_detail_stats ? nb_output_streams : 1;
+AVFormatContext *oc;
+
+for (i = 0; i < nb_display_streams; i++) {
 OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
 switch (ost->enc_ctx->codec_type) {
 case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
 case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1552,7 +1563,13 @@ static void print_final_stats(int64_t total_size)
 if (   (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 | 
AV_CODEC_FLAG_PASS2))
 != AV_CODEC_FLAG_PASS1)
 pass1_used = 0;
-}
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index != 
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx;
+total_size =  avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with 
non seekable output too
+total_size = avio_tell(oc->pb);
 
 if (data_size && total_size>0 && total_size >= data_size)
 percent = 100.0 * (total_size - data_size) / data_size;
@@ -1568,6 +1585,8 @@ static void print_final_stats(int64_t total_size)
 else
 av_log(NULL, AV_LOG_INFO, "unknown");
 av_log(NULL, AV_LOG_INFO, "\n");
+}
+}
 
 /* print verbose per-stream stats */
 for (i = 0; i < nb_input_files; i++) {
@@ -1680,13 +1699,6 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 
 t = (cur_time-timer_start) / 100.0;
 
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non 
seekable output too
-total_size = avio_tell(oc->pb);
-
 vid = 0;
 av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprint_init(_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
@@ -1697,12 +1709,14 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 if (!ost->stream_copy)
 q = ost->quality / (float) FF_QP2LAMBDA;
 
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 av_bprintf(, "q=%2.1f ", q);
 av_bprintf(_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
 }
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+// Only print the stats for the first stream during processing
+if ((is_last_report && (enable_detail_stats && vid || !vid)) || 
!is_last_report && !vid) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 float fps;
 
 frame_number = ost->frame_number;
@@ -1761,7 +1775,9 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
   ost->st->time_base, AV_TIME_BASE_Q));
 if (is_last_report)
 nb_frames_drop += ost->last_dropped;
-}
+total_size = avio_size(output_files[ost->file_index]->ctx->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works 

Re: [FFmpeg-devel] make work (live) libsrt

[Marton Balint]

On Thu, 23 Aug 2018, myp...@gmail.com wrote:


On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu  wrote:


Hello,

I get errors when I try to send a live srt stream that the first packet is
too big:
21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
maximum allowed 1316

Here are example commands for server and client:
ffmpeg -re -i ~/Downloads/ToS-4k-1920.mov -vcodec libx264 -g 50 -refs 1 -s
640x360 -b:v 1000k -acodec aac -b:a 64k -flush_packets 0 -f mpegts "srt://
127.0.0.1:?mode=listener"
ffplay srt://127.0.0.1:

A patch that fully solves the issue is:
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0f9529d263..156a4776e2 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -412,6 +412,8 @@ static int libsrt_open(URLContext *h, const char *uri,
int flags)
 return AVERROR_UNKNOWN;
 }

+h->max_packet_size = 1316;
+
 /* SRT options (srt/srt.h) */
 p = strchr(uri, '?');
 if (p) {

How would you like this option to be made work in a way that can be
accepted in ffmpeg?
Is there a way to change the max packet size without this patch?


In your case, I don't think hard coding max packet size == 1316 is not
a good idea in loopback device, and after deep in the srt
library(https://github.com/Haivision/srt) source code, I think srt
library need to fix the hardcode about packet size limition.


I can't think of a scenario where limiting the packet size actually causes 
problems, but if you insist on not limiting it in general, then the max 
packet size should be settable using an option, same way it is for UDP. 
(pkt_size option). I'd suggest using 1316 as default, because that

is the more common (and currently the only working) use case...

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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink_enc: print preroll and buffer size

[Marton Balint]

On Thu, 23 Aug 2018, Gyan Doshi wrote:


Plan to push tomorrow.


Ok, LGTM.

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

[FFmpeg-devel] swscale : add bitexact conv for grayf32 and gray16 to f32 conv

[Martin Vignali]

Hello,

Patch in attach add some bitexact conversion for grayf32
and unscaled conv for gray16 to grayf32.

Pass fate test for me (x86_64, macos 10.12)

001 : Add bit exact conv for float to uint16
002 : Add bit exact conv for float to uint8
003 : Add bit exact lut generation for 8b to float (alloc/free the lut).
004 : Add bit exact and non bitexact lut generation for 16b to float and
add unscale conv from uint16 to grayF32.
In bit exact mode, the last part of the lut (32768 to 65535), have on some
value an offset of 1 in the mantissa part (comparing to float conv). In
practice, doesn't have a visual impact on the result.

I will add later patch to add swap managment in the unscale part for float
input/output

I still have a problem with output func :
yuv2plane1_float_c_template/yuv2planeX_float_c_template,
where i would like to use the uint2float lut, store inside SwsContext, but
doesn't find a way to pass it to the processing func.


Will take a look later, for SIMD for the float to uint conv (in order to
decide if we keep float and bitexact version of the conv).
For lut generation, i'm not sure, trying to add SIMD is need
(probably not a lot of impact on global speed)


Martin


0001-swscale-input-add-bit_exact-for-float-to-uint16-conv.patch
Description: Binary data


0003-swscale-add-bit_exact-lut-creation-for-8bit-to-float.patch
Description: Binary data


0004-swscale-swscale_unscaled-add-conversion-from-float-Y.patch
Description: Binary data


0002-swscale-unscale-add-bitexact-conversion-for-float-to.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [bisected] Crashing Firefox

[Mohammad_AlSaleh]

On Fri, Aug 17, 2018 at 12:07:56AM -0300, James Almer wrote:
> On 7/28/2018 6:28 PM, Michael Niedermayer wrote:
> > On Sat, Jul 28, 2018 at 01:25:36PM -0300, James Almer wrote:
> >> On 7/28/2018 4:09 AM, Michael Niedermayer wrote:
> >>> On Fri, Jul 27, 2018 at 11:11:47PM -0300, James Almer wrote:
>  On 7/27/2018 10:58 PM, Michael Niedermayer wrote:
> > On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote:
> >> Certain AVCodecParameters, like the contents of the extradata, may be 
> >> changed
> >> by the init() function of any of the bitstream filters in the chain.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> Now it's not going to be called after the codec has been opened.
> >>
> >>  libavcodec/decode.c | 4 
> >>  1 file changed, 4 insertions(+)
> >
> > This breaks:
> > ffmpeg -i 
> > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png
> >  -bitexact -pix_fmt rgba -f framecrc -
> 
>  Is any other decoder failing the same way? Because the apng decoder
>  threading code may be faulty otherwise. Plenty of avctx fields are
>  changed after ff_thread_init() is called within avcodec_open2(). There
>  should not be a race at this point.
> >>>
> >>> I found a failure with mpeg4 (with bframes) decoding + pcm_alaw from mkv 
> >>> but it
> >>> does not want to reproduce. The slightest change i do makes this not 
> >>> happen
> >>> even just duplicating a command line parameter (which should have no 
> >>> effect)
> >>> simply adding the -threads parameter to it independant of value makes it 
> >>> go away
> >>> too
> >>>
> >>>
> >>> in the png case
> >>> this hits teh issue:
> >>> -threads 2 -i 
> >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png
> >>>   -f framecrc -
> >>>
> >>> this does not:
> >>> -threads 1 -i 
> >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png
> >>>   -f framecrc -
> >>>
> >>> also odly the bitexact flag made a differnce in how it fails outside 
> >>> valgrind
> >>> last i tried. (doesnt make a difference in valgrind it seems)
> >>
> >> A solution may be moving the ff_decode_bsfs_init call in patch 7/8 right
> >> above the call to ff_thread_init (See attachment), hopefully preventing
> >> this race once this patch is applied afterwards, but it will result in
> >> the bsfs initialized before the decoder, and some of the avctx fields
> >> that are changed later in avcodec_open2 like channels and bit_rate not
> >> being reflected during said bsfs initialization.
> >> I can't say if the former is correct or ideal, but for now the latter
> >> would not be an issue. I don't know what may happen if we were to
> >> autoinsert a filter that does care about such fields in the future, though.
> >>
> >> If the above change doesn't solve it, or is not ideal, then this patch
> >> 8/8 can be dropped or postponed, and the rest of the set pushed without it.
> > 
> > with this patch, the pachset seems not to trigger these errors anymore
> > 
> > thanks
> 
> Set pushed. Thanks.
>

Just so you know, f631c328e680a3dd491936b92f69970c20cdcfc7
causes Firefox's media playback thread to crash.

Just try playing any local or remote mp4 file. The crash is
reproducible.

Tested and bisected with FF Developer Edition (64-bit linux).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c

[Shlomi Fish]

On Fri, 20 Jul 2018 14:31:55 +0300
Shlomi Fish  wrote:

> On Wed, 11 Jul 2018 19:42:09 +0300
> Shlomi Fish  wrote:
> 
> > On Wed, 4 Jul 2018 23:10:46 +0300
> > Shlomi Fish  wrote:
> > 
> > Ping! Can this patch be reviewed please?
> >   
> 
> Ping!

bump / ping.

-- 
-
Shlomi Fish   http://www.shlomifish.org/
My Aphorisms - http://www.shlomifish.org/humour.html

Tomorrow never dies, unless Chuck Norris volunteers to take it out of its
misery.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Rostislav Pehlivanov]

On Wed, 22 Aug 2018 at 20:12, Michael Niedermayer 
wrote:

> On Wed, Aug 22, 2018 at 03:14:53PM +0200, Jean-Baptiste Kempf wrote:
> > Hello fellow devs,
> >
> > VideoLAN is happy to invite you to the usual conference of the end of
> the summer:
> > VDD2018 is happening in Paris, for the 10 years of the original conf.
> >
> > As usual, this is a very technical conference focused on open source
> multimedia development.
> > We will talk about AV1, FFv1, FFv2, x264/x265, VLC, FFmpeg and other
> related technologies.
>
> what is FFv2 ?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I'm working on it
https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 26/41] lavc/h264: Add common code for level handling

[James Almer]

On 8/22/2018 8:44 PM, Mark Thompson wrote:
> Including a unit test.
> ---
>  libavcodec/Makefile|   3 +-
>  libavcodec/h264_levels.c   | 130 +++
>  libavcodec/h264_levels.h   |  53 ++
>  libavcodec/tests/.gitignore|   1 +
>  libavcodec/tests/h264_levels.c | 183 +
>  tests/fate/libavcodec.mak  |   5 +
>  6 files changed, 374 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/h264_levels.c
>  create mode 100644 libavcodec/h264_levels.h
>  create mode 100644 libavcodec/tests/h264_levels.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index cbbfc9af2e..d07a9073af 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -355,7 +355,7 @@ OBJS-$(CONFIG_H264_OMX_ENCODER)+= omx.o
>  OBJS-$(CONFIG_H264_QSV_DECODER)+= qsvdec_h2645.o
>  OBJS-$(CONFIG_H264_QSV_ENCODER)+= qsvenc_h264.o
>  OBJS-$(CONFIG_H264_RKMPP_DECODER)  += rkmppdec.o
> -OBJS-$(CONFIG_H264_VAAPI_ENCODER)  += vaapi_encode_h264.o
> +OBJS-$(CONFIG_H264_VAAPI_ENCODER)  += h264_levels.o vaapi_encode_h264.o
>  OBJS-$(CONFIG_H264_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o
>  OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
>  OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
> @@ -1134,6 +1134,7 @@ TESTPROGS-$(CONFIG_IDCTDSP)   += dct
>  TESTPROGS-$(CONFIG_IIRFILTER) += iirfilter
>  TESTPROGS-$(HAVE_MMX) += motion
>  TESTPROGS-$(CONFIG_MPEGVIDEO) += mpeg12framerate
> +TESTPROGS-$(CONFIG_H264_VAAPI_ENCODER)+= h264_levels

Needing h264_vaapi_encoder to test this is not ideal. You'd be limiting
the amount of fate clients testing an internal module to those with an
unrelated external encoder enabled.

Maybe just add h264_levels.o to h264parse, and check for that instead?
Alternatively, since you need to add that object to h264_metadata to fix
the build failure Michael reported for patch 28, you could check for
that bsf instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 28/41] h264_metadata: Add option to set the level of the stream

[Michael Niedermayer]

On Thu, Aug 23, 2018 at 12:45:01AM +0100, Mark Thompson wrote:
> ---
>  doc/bitstream_filters.texi |  9 
>  libavcodec/h264_metadata_bsf.c | 90 ++
>  2 files changed, 99 insertions(+)

fails to build on mingw64

libavcodec/h264_metadata_bsf.c:243: undefined reference to `ff_h264_guess_level'
libavcodec/h264_metadata_bsf.c:243:(.text+0x36c): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `ff_h264_guess_level'


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

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


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 16:00 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos :
 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
> From 100x real-time decoding to 138x real-time decoding for 320x240
> video.

 On x86_64 I get an even better improvement, on x86_32
 decoding gets slower by approximately 10%.
 Without the patch, decoding is faster on x86_32 than
 x86_64 here...
>>>
>>> Using vanilla gcc-6.4.
>>>
>>> clang 3.4:
>>> 5% slower with patch on x86_32
40% faster with patch on x86_64
>>> x86_32 again faster than x86_64 without patch.
>>
>> x86_32 is going to be less and less used.
>
> Is there a reason why we cannot use
> the change in the x86_64 case (and others that we
> show to be faster) but not for x86_32?

The define could be only enabled for x86_64.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Tools: drop hard dependency on python2

[Michael Niedermayer]

On Thu, Aug 23, 2018 at 11:54:25AM +0200, Mayeul Cantan wrote:
> Some tools had an artificial dependency on python2: zmqshell.py and 
> normalize.py
> 
> This patch changes the requested environment to a generic "python",
> and add parenthesis to the "print" calls. 2to3 shows no other
> modifications are needed, so I expect this to be okay.
> 
> Please note that this was untested.
> 
> ---
>  tools/normalize.py | 13 +++--
>  tools/zmqshell.py  |  7 ---
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/normalize.py b/tools/normalize.py
> index 7d87c5e154..a550d06906 100755
> --- a/tools/normalize.py
> +++ b/tools/normalize.py
> @@ -1,4 +1,5 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python
> +# This script is compatible both with python 2 and 3; please keep it so
> 
>  import sys, subprocess
> 
> @@ -7,7 +8,7 @@ if len(sys.argv) > 2:
>  encopt = sys.argv[2:-1]
>  ofile  = sys.argv[-1]
>  else:
> -print 'usage: %s  [encode_options] ' % sys.argv[0]
> +print('usage: %s  [encode_options] ' % sys.argv[0])
>  sys.exit(1)
> 
>  analysis_cmd  = 'ffprobe -v error -of compact=p=0:nk=1 '
> @@ -15,7 +16,7 @@ analysis_cmd += '-show_entries
> frame_tags=lavfi.r128.I -f lavfi '

this patch looks corrupted by newlines

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 16:00 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos :
>>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
 From 100x real-time decoding to 138x real-time decoding for 320x240
 video.
>>>
>>> On x86_64 I get an even better improvement, on x86_32
>>> decoding gets slower by approximately 10%.
>>> Without the patch, decoding is faster on x86_32 than
>>> x86_64 here...
>>
>> Using vanilla gcc-6.4.
>>
>> clang 3.4:
>> 5% slower with patch on x86_32
>>>40% faster with patch on x86_64
>> x86_32 again faster than x86_64 without patch.
>
> x86_32 is going to be less and less used.

Is there a reason why we cannot use
the change in the x86_64 case (and others that we
show to be faster) but not for x86_32?

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

Re: [FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch removes an unused function from cfhd.c.
>
> Please comment, Carl Eugen
>

Not acceptable. Function is needed, but was dropped due programmer's error.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos :
>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>>> From 100x real-time decoding to 138x real-time decoding for 320x240
>>> video.
>>
>> On x86_64 I get an even better improvement, on x86_32
>> decoding gets slower by approximately 10%.
>> Without the patch, decoding is faster on x86_32 than
>> x86_64 here...
>
> Using vanilla gcc-6.4.
>
> clang 3.4:
> 5% slower with patch on x86_32
>>40% faster with patch on x86_64
> x86_32 again faster than x86_64 without patch.

x86_32 is going to be less and less used.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function

[Carl Eugen Hoyos]

Hi!

Attached patch removes an unused function from cfhd.c.

Please comment, Carl Eugen
From 191c7baea8b820d07bbcf1ddb50ffcff8f6c6a08 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 23 Aug 2018 15:56:06 +0200
Subject: [PATCH] lavc/cfhd: Remove an unused function.

---
 libavcodec/cfhd.c |   14 --
 1 file changed, 14 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334..616f5af 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak *peak, int length)
 band[i] = bytestream2_get_le16(>base);
 }
 
-static inline void process_alpha(int16_t *alpha, int width)
-{
-int i, channel;
-for (i = 0; i < width; i++) {
-channel   = alpha[i];
-channel  -= ALPHA_COMPAND_DC_OFFSET;
-channel <<= 3;
-channel  *= ALPHA_COMPAND_GAIN;
-channel >>= 16;
-channel   = av_clip_uintp2(channel, 12);
-alpha[i]  = channel;
-}
-}
-
 static inline void filter(int16_t *output, ptrdiff_t out_stride,
   int16_t *low, ptrdiff_t low_stride,
   int16_t *high, ptrdiff_t high_stride,
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos :
> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>> From 100x real-time decoding to 138x real-time decoding for 320x240
>> video.
>
> On x86_64 I get an even better improvement, on x86_32
> decoding gets slower by approximately 10%.
> Without the patch, decoding is faster on x86_32 than
> x86_64 here...

Using vanilla gcc-6.4.

clang 3.4:
5% slower with patch on x86_32
>40% faster with patch on x86_64
x86_32 again faster than x86_64 without patch.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Reto Kromer]

Paul B Mahol wrote:

>Byte Order:  Little Endian

I will check the mixed endian on my PDP-11 ;-)

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:35 GMT+02:00, Paul B Mahol :
> On 8/23/18, James Almer  wrote:
>> On 8/23/2018 10:24 AM, Paul B Mahol wrote:
>>> On 8/23/18, Carl Eugen Hoyos  wrote:
 2018-08-23 15:21 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>>> From 100x real-time decoding to 138x real-time decoding for 320x240
>>> video.
>>
>> On which hardware did you test?
>
> That is highly confidental info.

 In that case this patch is not ok.
>>>
>>> Ugh, can you explain why?
>>
>> Christ, just say what CPU you used already.
>
> When you insist!
>
> Architecture:x86_64
> CPU op-mode(s):  32-bit, 64-bit

Sorry if you disagree but this is not a useful answer:
The important question is (actually was, now that I
confirmed what was claimed earlier) if you compiled
for 32 or 64 bit.

Yes, my original question wasn't much better: Sorry
about it!

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:08 GMT+02:00, Paul B Mahol :
> From 100x real-time decoding to 138x real-time decoding for 320x240 video.

On x86_64 I get an even better improvement, on x86_32
decoding gets slower by approximately 10%.
Without the patch, decoding is faster on x86_32 than
x86_64 here...

Testfile produced with:
$ ffmpeg -f lavfi -i testsrc=s=320x240 -vcodec utvideo -vframes 1 out.avi

Same question I thought of when this patch was originally dropped:
Is there any problem with using the new reader on some targets
but not others?

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, James Almer  wrote:
> On 8/23/2018 10:24 AM, Paul B Mahol wrote:
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-23 15:21 GMT+02:00, Paul B Mahol :
 On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>> From 100x real-time decoding to 138x real-time decoding for 320x240
>> video.
>
> On which hardware did you test?

 That is highly confidental info.
>>>
>>> In that case this patch is not ok.
>>
>> Ugh, can you explain why?
>
> Christ, just say what CPU you used already.

When you insist!

Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   61
Model name:  Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz
Stepping:4
CPU MHz: 1895.954
CPU max MHz: 1900,
CPU min MHz: 500,
BogoMIPS:3990.53
Virtualization:  VT-x
L1d cache:   32K
L1i cache:   32K
L2 cache:256K
L3 cache:3072K
NUMA node0 CPU(s):   0-3
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm
abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms
invpcid rdseed adx smap intel_pt xsaveopt dtherm arat pln pts
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:25 GMT+02:00, Nicolas George :
> Paul B Mahol (2018-08-23):
>> Ugh, can you explain why?
>
> Need provable claims.

What I meant was just that I would prefer to only test on other
platforms...

Not that it wouldn't make sense to add the tested platform
to the commit message though.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[James Almer]

On 8/23/2018 10:24 AM, Paul B Mahol wrote:
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 15:21 GMT+02:00, Paul B Mahol :
>>> On 8/23/18, Carl Eugen Hoyos  wrote:
 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
> From 100x real-time decoding to 138x real-time decoding for 320x240
> video.

 On which hardware did you test?
>>>
>>> That is highly confidental info.
>>
>> In that case this patch is not ok.
> 
> Ugh, can you explain why?

Christ, just say what CPU you used already.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Nicolas George]

Paul B Mahol (2018-08-23):
> Try it yourself

Your patch. Still not ok.

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, Nicolas George  wrote:
> Paul B Mahol (2018-08-23):
>> Ugh, can you explain why?
>
> Need provable claims.

Try it yourself, that is only way you will prove it to self.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Nicolas George]

Paul B Mahol (2018-08-23):
> Ugh, can you explain why?

Need provable claims.

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 15:21 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
 From 100x real-time decoding to 138x real-time decoding for 320x240
 video.
>>>
>>> On which hardware did you test?
>>
>> That is highly confidental info.
>
> In that case this patch is not ok.

Ugh, can you explain why?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:21 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>>> From 100x real-time decoding to 138x real-time decoding for 320x240
>>> video.
>>
>> On which hardware did you test?
>
> That is highly confidental info.

In that case this patch is not ok.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 15:08 GMT+02:00, Paul B Mahol :
>> From 100x real-time decoding to 138x real-time decoding for 320x240 video.
>
> On which hardware did you test?

That is highly confidental info.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-08-23 15:08 GMT+02:00, Paul B Mahol :
> From 100x real-time decoding to 138x real-time decoding for 320x240 video.

On which hardware did you test?

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

[FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/get_bits.h | 218 +-
 libavcodec/golomb.h   | 151 +
 2 files changed, 367 insertions(+), 2 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 56ef5f0cbe..58ebb64656 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -1,5 +1,6 @@
 /*
- * copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2016 Alexandra Hájková
  *
  * This file is part of FFmpeg.
  *
@@ -55,11 +56,19 @@
 
 typedef struct GetBitContext {
 const uint8_t *buffer, *buffer_end;
+#ifdef CACHED_BITSTREAM_READER
+uint64_t cache;
+unsigned bits_left;
+#endif
 int index;
 int size_in_bits;
 int size_in_bits_plus8;
 } GetBitContext;
 
+static inline unsigned int get_bits(GetBitContext *s, int n);
+static inline void skip_bits(GetBitContext *s, int n);
+static inline unsigned int show_bits(GetBitContext *s, int n);
+
 /* Bitstream reader API docs:
  * name
  *   arbitrary name which is used as prefix for the internal variables
@@ -107,12 +116,16 @@ typedef struct GetBitContext {
  * For examples see get_bits, show_bits, skip_bits, get_vlc.
  */
 
-#ifdef LONG_BITSTREAM_READER
+#ifdef CACHED_BITSTREAM_READER
+#   define MIN_CACHE_BITS 64
+#elif defined LONG_BITSTREAM_READER
 #   define MIN_CACHE_BITS 32
 #else
 #   define MIN_CACHE_BITS 25
 #endif
 
+#ifndef CACHED_BITSTREAM_READER
+
 #define OPEN_READER_NOSIZE(name, gb)\
 unsigned int name ## _index = (gb)->index;  \
 unsigned int av_unused name ## _cache
@@ -197,11 +210,75 @@ typedef struct GetBitContext {
 
 #define GET_CACHE(name, gb) ((uint32_t) name ## _cache)
 
+#endif
+
 static inline int get_bits_count(const GetBitContext *s)
 {
+#ifdef CACHED_BITSTREAM_READER
+return s->index - s->bits_left;
+#else
 return s->index;
+#endif
+}
+
+#ifdef CACHED_BITSTREAM_READER
+static inline void refill_32(GetBitContext *s)
+{
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache   = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
s->bits_left | s->cache;
+#else
+s->cache   = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3)) 
<< (32 - s->bits_left);
+#endif
+s->index += 32;
+s->bits_left += 32;
 }
 
+static inline void refill_64(GetBitContext *s)
+{
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache = AV_RL64(s->buffer + (s->index >> 3));
+#else
+s->cache = AV_RB64(s->buffer + (s->index >> 3));
+#endif
+s->index += 64;
+s->bits_left = 64;
+}
+
+static inline uint64_t get_val(GetBitContext *s, unsigned n, int is_le)
+{
+uint64_t ret;
+av_assert2(n>0 && n<=63);
+if (is_le) {
+ret = s->cache & ((UINT64_C(1) << n) - 1);
+s->cache >>= n;
+} else {
+ret = s->cache >> (64 - n);
+s->cache <<= n;
+}
+s->bits_left -= n;
+return ret;
+}
+
+static inline unsigned show_val(const GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+return s->cache & ((UINT64_C(1) << n) - 1);
+#else
+return s->cache >> (64 - n);
+#endif
+}
+#endif
+
 /**
  * Skips the specified number of bits.
  * @param n the number of bits to skip,
@@ -211,13 +288,29 @@ static inline int get_bits_count(const GetBitContext *s)
  */
 static inline void skip_bits_long(GetBitContext *s, int n)
 {
+#ifdef CACHED_BITSTREAM_READER
+skip_bits(s, n);
+#else
 #if UNCHECKED_BITSTREAM_READER
 s->index += n;
 #else
 s->index += av_clip(n, -s->index, s->size_in_bits_plus8 - s->index);
 #endif
+#endif
 }
 
+#ifdef CACHED_BITSTREAM_READER
+static inline void skip_remaining(GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+s->cache >>= n;
+#else
+s->cache <<= n;
+#endif
+s->bits_left -= n;
+}
+#endif
+
 /**
  * Read MPEG-1 dc-style VLC (sign bit + mantissa with no MSB).
  * if MSB not set it is negative
@@ -225,6 +318,13 @@ static inline void skip_bits_long(GetBitContext *s, int n)
  */
 static inline int get_xbits(GetBitContext *s, int n)
 {
+#ifdef CACHED_BITSTREAM_READER
+int32_t cache = show_bits(s, 32);
+int sign = ~cache >> 31;
+skip_remaining(s, n);
+
+return uint32_t)(sign ^ cache)) >> (32 - n)) ^ sign) - sign;
+#else
 register int sign;
 register int32_t cache;
 OPEN_READER(re, s);
@@ -235,8 +335,10 @@ static inline int get_xbits(GetBitContext *s, int n)
 LAST_SKIP_BITS(re, s, n);
 CLOSE_READER(re, s);
 return (NEG_USR32(sign ^ cache, n) ^ sign) - sign;
+#endif
 }
 
+#ifndef CACHED_BITSTREAM_READER
 static inline int get_xbits_le(GetBitContext *s, int n)
 {
 register int sign;
@@ -250,16 +352,22 @@ static inline int get_xbits_le(GetBitContext *s, int n)
 CLOSE_READER(re, s);
 return 

[FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

From 100x real-time decoding to 138x real-time decoding for 320x240 video.

Signed-off-by: Paul B Mahol 
---
 libavcodec/utvideodec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 82cb038ccd..99b37aa0f3 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#define CACHED_BITSTREAM_READER
 #define UNCHECKED_BITSTREAM_READER 1
 
 #include "libavutil/intreadwrite.h"
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 2/3] doc/libav-merge: bitstream reader is now merged

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/libav-merge.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
index 8c182ae78d..d5e671ca55 100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@ -95,7 +95,6 @@ Stuff that didn't reach the codebase:
   - 0cef06df0 checkasm: add HEVC MC tests
   - e7078e842 hevcdsp: add x86 SIMD for MC
   - 7993ec19a hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64
-- new bitstream reader (see 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html)
 - use av_cpu_max_align() instead of hardcoding alignment requirements (see 
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215834.html)
   - f44ec22e0 lavc: use av_cpu_max_align() instead of hardcoding alignment 
requirements
   - 4de220d2e frame: allow align=0 (meaning automatic) for 
av_frame_get_buffer()
-- 
2.17.1

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

[FFmpeg-devel] [PATCH V2] examples/vaapi_dec_scaling: add a vaapi decoding/scaling sample

[Jun Zhao]

add a vaapi decoding/scaling sample.

Signed-off-by: Jun Zhao 
---
 configure|2 +
 doc/examples/Makefile|1 +
 doc/examples/vaapi_dec_scaling.c |  377 ++
 3 files changed, 380 insertions(+), 0 deletions(-)
 create mode 100644 doc/examples/vaapi_dec_scaling.c

diff --git a/configure b/configure
index 9b5421d..77ed4bf 100755
--- a/configure
+++ b/configure
@@ -1612,6 +1612,7 @@ EXAMPLE_LIST="
 scaling_video_example
 transcode_aac_example
 transcoding_example
+vaapi_dec_scaling_example
 vaapi_encode_example
 vaapi_transcode_example
 "
@@ -3461,6 +3462,7 @@ resampling_audio_example_deps="avutil swresample"
 scaling_video_example_deps="avutil swscale"
 transcode_aac_example_deps="avcodec avformat swresample"
 transcoding_example_deps="avfilter avcodec avformat avutil"
+vaapi_dec_scaling_example_deps="avfilter avcodec avformat avutil"
 vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
 vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
 
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 928ff30..3ea6899 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += 
resampling_audio
 EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
 EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
 EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
+EXAMPLES-$(CONFIG_VAAPI_DEC_SCALING_EXAMPLE) += vaapi_dec_scaling
 EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
 EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)   += vaapi_transcode
 
diff --git a/doc/examples/vaapi_dec_scaling.c b/doc/examples/vaapi_dec_scaling.c
new file mode 100644
index 000..30aa163
--- /dev/null
+++ b/doc/examples/vaapi_dec_scaling.c
@@ -0,0 +1,377 @@
+/*
+ * Copyright (c) 2018 Jun Zhao
+ *
+ * VA-API Acceleration API (video decoding/scaling) sample
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * @file
+ * VA-API-Accelerated decoding/scaling example.
+ *
+ * @example vaapi_dec_scaling.c
+ * This example shows how to do VA-API-accelerated decoding/scaling with output
+ * frames from the HW video surfaces.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static AVBufferRef *hw_device_ctx = NULL;
+static enum AVPixelFormat hw_pix_fmt;
+static FILE *output_file = NULL;
+AVFilterContext *buffersink_ctx;
+AVFilterContext *buffersrc_ctx;
+AVFilterGraph *filter_graph;
+const char *filter_descr =
+"format=vaapi,scale_vaapi=w=iw/2:h=ih/2,hwdownload,format=nv12";
+int init_filter = 0;
+
+static int init_hw_decode(AVCodecContext *ctx, const enum AVHWDeviceType type)
+{
+int err = 0;
+
+if ((err = av_hwdevice_ctx_create(_device_ctx, type,
+  NULL, NULL, 0)) < 0) {
+fprintf(stderr, "Failed to create specified HW device.\n");
+return err;
+}
+ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+
+return err;
+}
+
+static int init_filters(AVFormatContext *fmt_ctx, AVCodecContext *dec_ctx,
+int video_stream_index, const char *filters_descr)
+{
+char args[512];
+int ret = 0;
+const AVFilter *buffersrc  = avfilter_get_by_name("buffer");
+const AVFilter *buffersink = avfilter_get_by_name("buffersink");
+AVFilterInOut *outputs = avfilter_inout_alloc();
+AVFilterInOut *inputs  = avfilter_inout_alloc();
+AVRational time_base = fmt_ctx->streams[video_stream_index]->time_base;
+AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
+
+filter_graph = avfilter_graph_alloc();
+if (!outputs || !inputs || !filter_graph || !par) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+/* buffer video source: the decoded frames from the decoder will be 
inserted 

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 14:51 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
 On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
 On 8/22/18, Carl Eugen Hoyos  wrote:
> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>
>> +switch (avctx->bits_per_coded_sample) {
>> +case 12:
>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>> + break;
>> +default:
>> + return AVERROR_INVALIDDATA;
>> +}
>
> Why are the condition and the error needed?

 Because only that is supported.
>>>
>>> Do valid samples with other values exist?
>>
>> No.
>
> Then I suggest to make the whole block above just:
> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;

 Nope, bits per coded sample must be checked.
>>>
>>> Could you explain why?
>>
>> Reference decoder checks it, so do we.
>
> Shouldn't we try to decode files if at all possible?

Nope.

>
>>> Am I correct that no other decoder does that?
>>
>> Nope.
>
> Which decoder does it?
>

Utvideo, magicyuv, y41p...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Carl Eugen Hoyos]

2018-08-23 14:51 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
>>> On 8/23/18, Carl Eugen Hoyos  wrote:
 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>>> On 8/22/18, Carl Eugen Hoyos  wrote:
 2018-08-22 18:00 GMT+02:00, Paul B Mahol :

> +switch (avctx->bits_per_coded_sample) {
> +case 12:
> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
> + break;
> +default:
> + return AVERROR_INVALIDDATA;
> +}

 Why are the condition and the error needed?
>>>
>>> Because only that is supported.
>>
>> Do valid samples with other values exist?
>
> No.

 Then I suggest to make the whole block above just:
 s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>>
>>> Nope, bits per coded sample must be checked.
>>
>> Could you explain why?
>
> Reference decoder checks it, so do we.

Shouldn't we try to decode files if at all possible?

>> Am I correct that no other decoder does that?
>
> Nope.

Which decoder does it?

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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
 On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>> On 8/22/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>>
 +switch (avctx->bits_per_coded_sample) {
 +case 12:
 + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
 + break;
 +default:
 + return AVERROR_INVALIDDATA;
 +}
>>>
>>> Why are the condition and the error needed?
>>
>> Because only that is supported.
>
> Do valid samples with other values exist?

 No.
>>>
>>> Then I suggest to make the whole block above just:
>>> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>
>> Nope, bits per coded sample must be checked.
>
> Could you explain why?

Reference decoder checks it, so do we.

>
> Am I correct that no other decoder does that?

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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Carl Eugen Hoyos]

2018-08-23 14:29 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>>> On 8/23/18, Carl Eugen Hoyos  wrote:
 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
> On 8/22/18, Carl Eugen Hoyos  wrote:
>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>
>>> +switch (avctx->bits_per_coded_sample) {
>>> +case 12:
>>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>> + break;
>>> +default:
>>> + return AVERROR_INVALIDDATA;
>>> +}
>>
>> Why are the condition and the error needed?
>
> Because only that is supported.

 Do valid samples with other values exist?
>>>
>>> No.
>>
>> Then I suggest to make the whole block above just:
>> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>
> Nope, bits per coded sample must be checked.

Could you explain why?

Am I correct that no other decoder does that?

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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
 On 8/22/18, Carl Eugen Hoyos  wrote:
> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>
>> +switch (avctx->bits_per_coded_sample) {
>> +case 12:
>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>> + break;
>> +default:
>> + return AVERROR_INVALIDDATA;
>> +}
>
> Why are the condition and the error needed?

 Because only that is supported.
>>>
>>> Do valid samples with other values exist?
>>
>> No.
>
> Then I suggest to make the whole block above just:
> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;

Nope, bits per coded sample must be checked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Carl Eugen Hoyos]

2018-08-23 11:11 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos  wrote:
>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>>> On 8/22/18, Carl Eugen Hoyos  wrote:
 2018-08-22 18:00 GMT+02:00, Paul B Mahol :

> +switch (avctx->bits_per_coded_sample) {
> +case 12:
> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
> + break;
> +default:
> + return AVERROR_INVALIDDATA;
> +}

 Why are the condition and the error needed?
>>>
>>> Because only that is supported.
>>
>> Do valid samples with other values exist?
>
> No.

Then I suggest to make the whole block above just:
s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;

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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Paul B Mahol]

On 8/23/18, Michael Niedermayer  wrote:
> On Wed, Aug 22, 2018 at 06:00:54PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/Makefile |   1 +
>>  libavcodec/allcodecs.c  |   1 +
>>  libavcodec/avcodec.h|   1 +
>>  libavcodec/codec_desc.c |   7 +
>>  libavcodec/prosumer.c   | 405 
>>  libavformat/riff.c  |   1 +
>>  6 files changed, 416 insertions(+)
>>  create mode 100644 libavcodec/prosumer.c
>>

[...]

>> +}
>> +pos = bytestream2_tell(gb) ^ 2;
>> +bytestream2_seek(gb, pos, SEEK_SET);
>> +AV_WN16(, bytestream2_peek_le16(gb));
>> +pos = pos ^ 2;
>> +bytestream2_seek(gb, pos, SEEK_SET);
>> +bytestream2_skip(gb, 2);
>> +cnt = 4;
>> +idx--;
>> +}
>
>> +b = PAIR(4, a) >> 16;
>
> I think this assumes sizeof(int) == 4, this is not guranteed it could be 8

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

Re: [FFmpeg-devel] Correct opus-in-mp4 pre-skip to be uint16_t versus int16_t.

[Michael Niedermayer]

On Wed, Aug 22, 2018 at 12:58:13AM -0300, James Almer wrote:
> On 8/21/2018 7:45 PM, Dale Curtis wrote:
> > This field is a uint16_t, see docs:
> > http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
> > 
> > Signed-off-by: Dale Curtis 
> > 
> > 
> > 0001-Correct-opus-in-mp4-pre-skip-to-be-uint16_t-versus-i.patch
> > 
> > 
> > From 7f1588bc92ef4a70025aa140a8e660a36875c89c Mon Sep 17 00:00:00 2001
> > From: Dale Curtis 
> > Date: Tue, 21 Aug 2018 15:42:31 -0700
> > Subject: [PATCH] Correct opus-in-mp4 pre-skip to be uint16_t versus int16_t.
> > 
> > This field is a uint16_t, see docs:
> > http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
> > 
> > Signed-off-by: Dale Curtis 
> > ---
> >  libavformat/mov.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 1bd7d7e483..02f6c1e0a1 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -6608,7 +6608,7 @@ static int mov_read_dops(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> >  const int OPUS_SEEK_PREROLL_MS = 80;
> >  AVStream *st;
> >  size_t size;
> > -int16_t pre_skip;
> > +uint16_t pre_skip;
> >  
> >  if (c->fc->nb_streams < 1)
> >  return 0;
> > -- 2.18.0.1017.ga543ac7ca45-goog
> 
> Should be ok.

will apply

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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add lut1d filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  31 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_lut3d.c   | 438 +++
 4 files changed, 471 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..37e79d34e1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10962,6 +10962,37 @@ Set maximal size in number of frames. Default is 0.
 Set first frame of loop. Default is 0.
 @end table
 
+@section lut1d
+
+Apply a 1D LUT to an input video.
+
+The filter accepts the following options:
+
+@table @option
+@item file
+Set the 1D LUT file name.
+
+Currently supported formats:
+@table @samp
+@item cube
+Iridas
+@end table
+
+@item interp
+Select interpolation mode.
+
+Available values are:
+
+@table @samp
+@item nearest
+Use values from the nearest defined point.
+@item linear
+Interpolate values using the linear interpolation.
+@item cubic
+Interpolate values using the cubic interpolation.
+@end table
+@end table
+
 @anchor{lut3d}
 @section lut3d
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e5d3a57af7..e412000c8f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -258,6 +258,7 @@ OBJS-$(CONFIG_LIBVMAF_FILTER)+= 
vf_libvmaf.o framesync.o
 OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
 OBJS-$(CONFIG_LOOP_FILTER)   += f_loop.o
 OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
+OBJS-$(CONFIG_LUT1D_FILTER)  += vf_lut3d.o
 OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
 OBJS-$(CONFIG_LUT2_FILTER)   += vf_lut2.o framesync.o
 OBJS-$(CONFIG_LUT3D_FILTER)  += vf_lut3d.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9732ae5345..2fa9460335 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ extern AVFilter ff_vf_limiter;
 extern AVFilter ff_vf_loop;
 extern AVFilter ff_vf_lumakey;
 extern AVFilter ff_vf_lut;
+extern AVFilter ff_vf_lut1d;
 extern AVFilter ff_vf_lut2;
 extern AVFilter ff_vf_lut3d;
 extern AVFilter ff_vf_lutrgb;
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 27b79b860b..6ec0cad650 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2013 Clément Bœsch
+ * Copyright (c) 2018 Paul B Mahol
  *
  * This file is part of FFmpeg.
  *
@@ -975,3 +976,440 @@ AVFilter ff_vf_haldclut = {
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL | 
AVFILTER_FLAG_SLICE_THREADS,
 };
 #endif
+
+#if CONFIG_LUT1D_FILTER
+
+enum interp_1d_mode {
+INTERPOLATE_1D_NEAREST,
+INTERPOLATE_1D_LINEAR,
+INTERPOLATE_1D_CUBIC,
+NB_INTERP_1D_MODE
+};
+
+#define MAX_1D_LEVEL 65536
+
+typedef struct LUT1DContext {
+const AVClass *class;
+char *file;
+int interpolation;  ///lutsize = size;
+for (i = 0; i < size; i++) {
+lut1d->lut[0][i] = i * c;
+lut1d->lut[1][i] = i * c;
+lut1d->lut[2][i] = i * c;
+}
+}
+
+static int parse_cube_1d(AVFilterContext *ctx, FILE *f)
+{
+LUT1DContext *lut1d = ctx->priv;
+char line[MAX_LINE_SIZE];
+float min[3] = {0.0, 0.0, 0.0};
+float max[3] = {1.0, 1.0, 1.0};
+
+while (fgets(line, sizeof(line), f)) {
+if (!strncmp(line, "LUT_1D_SIZE ", 12)) {
+const int size = strtol(line + 12, NULL, 0);
+int i;
+
+if (size < 2 || size > MAX_1D_LEVEL) {
+av_log(ctx, AV_LOG_ERROR, "Too large or invalid 1D LUT 
size\n");
+return AVERROR(EINVAL);
+}
+lut1d->lutsize = size;
+for (i = 0; i < size; i++) {
+do {
+try_again:
+NEXT_LINE(0);
+if (!strncmp(line, "DOMAIN_", 7)) {
+float *vals = NULL;
+if  (!strncmp(line + 7, "MIN ", 4)) vals = min;
+else if (!strncmp(line + 7, "MAX ", 4)) vals = max;
+if (!vals)
+return AVERROR_INVALIDDATA;
+sscanf(line + 11, "%f %f %f", vals, vals + 1, vals + 
2);
+av_log(ctx, AV_LOG_DEBUG, "min: %f %f %f | max: %f %f 
%f\n",
+   min[0], min[1], min[2], max[0], max[1], max[2]);
+goto try_again;
+}
+} while (skip_line(line));
+if (sscanf(line, "%f %f %f", >lut[0][i], 
>lut[1][i], >lut[2][i]) != 3)
+return AVERROR_INVALIDDATA;
+lut1d->lut[0][i] *= max[0] - min[0];
+lut1d->lut[1][i] *= max[1] - min[1];
+lut1d->lut[2][i] *= max[2] - min[2];
+}
+break;
+}
+}
+return 0;
+}
+
+static const AVOption lut1d_options[] = {
+{ "file", "set 1D LUT file name", OFFSET(file), 

Re: [FFmpeg-devel] [PATCH] lavc/extract_extradata_bsf.c: add AVS2

[Michael Niedermayer]

On Tue, Aug 21, 2018 at 09:27:27PM -0300, James Almer wrote:
> On 8/6/2018 10:42 AM, hwren wrote:
> > Signed-off-by: hwren 
> > ---
> >  libavcodec/extract_extradata_bsf.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/extract_extradata_bsf.c 
> > b/libavcodec/extract_extradata_bsf.c
> > index 6deb663..f37427c 100644
> > --- a/libavcodec/extract_extradata_bsf.c
> > +++ b/libavcodec/extract_extradata_bsf.c
> > @@ -331,6 +331,7 @@ static const struct {
> > uint8_t **data, int *size);
> >  } extract_tab[] = {
> >  { AV_CODEC_ID_AV1,extract_extradata_av1 },
> > +{ AV_CODEC_ID_AVS2,   extract_extradata_mpeg4   },
> >  { AV_CODEC_ID_CAVS,   extract_extradata_mpeg4   },
> >  { AV_CODEC_ID_H264,   extract_extradata_h2645   },
> >  { AV_CODEC_ID_HEVC,   extract_extradata_h2645   },
> > @@ -397,6 +398,7 @@ static void extract_extradata_close(AVBSFContext *ctx)
> >  
> >  static const enum AVCodecID codec_ids[] = {
> >  AV_CODEC_ID_AV1,
> > +AV_CODEC_ID_AVS2,
> >  AV_CODEC_ID_CAVS,
> >  AV_CODEC_ID_H264,
> >  AV_CODEC_ID_HEVC,
> > 
> 
> Should be ok.

will apply

thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Michael Niedermayer]

On Wed, Aug 22, 2018 at 06:00:54PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  libavcodec/prosumer.c   | 405 
>  libavformat/riff.c  |   1 +
>  6 files changed, 416 insertions(+)
>  create mode 100644 libavcodec/prosumer.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f0c8226283..9a309c348e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -515,6 +515,7 @@ OBJS-$(CONFIG_PRORES_DECODER)  += proresdec2.o 
> proresdsp.o proresdata.o
>  OBJS-$(CONFIG_PRORES_ENCODER)  += proresenc_anatoliy.o
>  OBJS-$(CONFIG_PRORES_AW_ENCODER)   += proresenc_anatoliy.o
>  OBJS-$(CONFIG_PRORES_KS_ENCODER)   += proresenc_kostya.o proresdata.o
> +OBJS-$(CONFIG_PROSUMER_DECODER)+= prosumer.o
>  OBJS-$(CONFIG_PSD_DECODER) += psd.o
>  OBJS-$(CONFIG_PTX_DECODER) += ptx.o
>  OBJS-$(CONFIG_QCELP_DECODER)   += qcelpdec.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fd35fc1d0b..b1d1ef26c0 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -235,6 +235,7 @@ extern AVCodec ff_prores_encoder;
>  extern AVCodec ff_prores_decoder;
>  extern AVCodec ff_prores_aw_encoder;
>  extern AVCodec ff_prores_ks_encoder;
> +extern AVCodec ff_prosumer_decoder;
>  extern AVCodec ff_psd_decoder;
>  extern AVCodec ff_ptx_decoder;
>  extern AVCodec ff_qdraw_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 31e50d5a94..2a4be2ca4f 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -448,6 +448,7 @@ enum AVCodecID {
>  AV_CODEC_ID_GDV,
>  AV_CODEC_ID_FITS,
>  AV_CODEC_ID_IMM4,
> +AV_CODEC_ID_PROSUMER,
>  
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
> start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index af66b35d2b..e611183599 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1661,6 +1661,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .long_name = NULL_IF_CONFIG_SMALL("Infinity IMM4"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_PROSUMER,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "prosumer",
> +.long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
>  
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
> new file mode 100644
> index 00..7b9d5e7bdb
> --- /dev/null
> +++ b/libavcodec/prosumer.c
> @@ -0,0 +1,405 @@
> +/*
> + * Brooktree ProSumer Video decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ProSumerContext {
> +GetByteContext gb;
> +PutByteContext pb;
> +
> +unsigned stride;
> +unsigned size;
> +unsigned lut[0x1];
> +uint8_t *table_b;
> +uint8_t *decbuffer;
> +} ProSumerContext;
> +
> +#define PAIR(high, low) (((uint64_t)(high)< +
> +static int decompress(GetByteContext *gb, int size, PutByteContext *pb, 
> const unsigned *lut)
> +{
> +int i, pos, idx, cnt, fill;
> +unsigned a, b, c;
> +
> +bytestream2_skip(gb, 32);
> +cnt = 4;
> +a = bytestream2_get_le32(gb);
> +idx = a >> 20;
> +b = lut[2 * idx];
> +
> +while (1) {
> +if (((b & 0xFF00u) != 0x8000u) || (b & 0xFFu)) {
> +if ((b & 0xFF00u) != 0x8000u) {
> +bytestream2_put_le16(pb, b);
> +} else if (b & 0xFFu) {
> +idx = 0;
> +for (i = 0; i < (b & 0xFFu); i++)

Re: [FFmpeg-devel] [PATCH] mpeg4video: Add Studio DPCM support

[Michael Niedermayer]

On Wed, Aug 22, 2018 at 12:29:57AM +0100, Kieran Kunhya wrote:
> $subj
> 
> Depends on Michael's patch.
> I have a FATE sample frame.

>  mpeg4videodec.c |  101 
> ++--
>  mpegvideo.c |   75 -
>  mpegvideo.h |2 +
>  3 files changed, 158 insertions(+), 20 deletions(-)
> 530459506bce209c83f6e3d477c2bbf77cd5d072  
> 0001-mpeg4video-Add-Studio-DPCM-support.patch
> From 909fba9afc7edc94a8fd043899ff44c022a32d17 Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya 
> Date: Sun, 19 Aug 2018 02:31:42 +0100
> Subject: [PATCH] mpeg4video: Add Studio DPCM support
> 
> ---
>  libavcodec/mpeg4videodec.c | 101 
> +++--
>  libavcodec/mpegvideo.c |  75 +
>  libavcodec/mpegvideo.h |   2 +
>  3 files changed, 158 insertions(+), 20 deletions(-)
> 
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 1686ed1001..dda462c2ea 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -24,6 +24,7 @@
>  
>  #include "libavutil/internal.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  #include "error_resilience.h"
>  #include "hwaccel.h"
>  #include "idctdsp.h"
> @@ -36,6 +37,7 @@
>  #include "profiles.h"
>  #include "thread.h"
>  #include "xvididct.h"
> +#include "unary.h"
>  
>  /* The defines below define the number of bits that are read at once for
>   * reading vlc values. Changing these may improve speed and data cache needs
> @@ -1923,10 +1925,101 @@ static int mpeg4_decode_studio_block(MpegEncContext 
> *s, int32_t block[64], int n
>  return 0;
>  }
>  
> +static int mpeg4_decode_dpcm_macroblock(MpegEncContext *s, int16_t 
> macroblock[256], int n)
> +{
> +int i, j, w, h, idx = 0;
> +int block_mean, rice_parameter, rice_prefix_code, rice_suffix_code;
> +int dpcm_residual, a, b, c, p, p2;

> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(s->avctx->pix_fmt);
> +h = 16 >> (n ? desc->log2_chroma_h : 0);
> +w = 16 >> (n ? desc->log2_chroma_w : 0);

you can use chroma_x_shift, chroma_y_shift from the context, theres no
need to obtain a AVPixFmtDescriptor


> +
> +block_mean = get_bits(>gb, s->avctx->bits_per_raw_sample);
> +if (block_mean == 0){
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden block_mean\n");
> +return AVERROR_INVALIDDATA;
> +}
> +s->last_dc[n] = block_mean * (1 << (s->dct_precision + 
> s->intra_dc_precision));
> +
> +rice_parameter = get_bits(>gb, 4);
> +if (rice_parameter == 0) {
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden rice_parameter\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (rice_parameter == 15)
> +rice_parameter = 0;
> +
> +if (rice_parameter > 11) {
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden rice_parameter\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +for (i = 0; i < h; i++) {
> +for (j = 0; j < w; j++) {

> +rice_prefix_code = get_unary(>gb, 1, 12);
> +
> +/* Escape */
> +if (rice_prefix_code == 11)
> +dpcm_residual = get_bits(>gb, 
> s->avctx->bits_per_raw_sample);
> +else {
> +rice_suffix_code = get_bitsz(>gb, rice_parameter);
> +dpcm_residual = (rice_prefix_code << rice_parameter) + 
> rice_suffix_code;
> +}
> +
> +/* Map to a signed residual */
> +if (dpcm_residual & 1)
> +dpcm_residual = (-1 * dpcm_residual) >> 1;
> +else
> +dpcm_residual = (dpcm_residual >> 1);

This could be optimized, not sure how common DPCM blocks are so maybe this
doesnt matter


> +
> +/* Calculate predictors
> +   a = left
> +   b = top
> +   c = top left
> + */

> +if (j == 0)
> +a = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +a = macroblock[idx-1];

you can move this out of the loop and just update "a" at the end of the loop, as
its the previous value


> +
> +if (i == 0)
> +b = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +b = macroblock[idx-w];
> +

> +if ((j == 0) || (i == 0))
> +c = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +c = macroblock[idx-w-1];

this too can be avoided by simply updating "c" at the end of teh loop and
setting it outside before the loop


> +
> +p = a + b - c;
> +if (p < FFMIN(a, b))
> +p = FFMIN(a, b);
> +
> +if (p > FFMAX(a, b))
> +p = FFMAX(a, b);
> +
> +p2 = (FFMIN3(a, b, c) + FFMAX3(a, b, c)) / 2;

using >> instead of /2 should be faster here
also FFMIN(a, b) and FFMAX(a, b) have already been 

Re: [FFmpeg-devel] [PATCH v3] doc/filters: Add double-pass example for loudnorm

[Reino Wijnsma]

On 22-8-2018 12:52, Gyan Doshi  wrote:
> On 22-08-2018 04:01 PM, Marvin Scholz wrote:
>> [Parsed_aresample_1 @ 0x7fb7c540d500] Cannot select channel layout for the 
>> link between filters Parsed_aresample_1 and format_out_0_1.
> For this file,
>
> aresample=48000:ocl=stereo
>
>
> Gyan
Related and still unresolved: https://trac.ffmpeg.org/ticket/6638.

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

[FFmpeg-devel] [PATCH] Tools: drop hard dependency on python2

[Mayeul Cantan]

Some tools had an artificial dependency on python2: zmqshell.py and normalize.py

This patch changes the requested environment to a generic "python",
and add parenthesis to the "print" calls. 2to3 shows no other
modifications are needed, so I expect this to be okay.

Please note that this was untested.

---
 tools/normalize.py | 13 +++--
 tools/zmqshell.py  |  7 ---
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/tools/normalize.py b/tools/normalize.py
index 7d87c5e154..a550d06906 100755
--- a/tools/normalize.py
+++ b/tools/normalize.py
@@ -1,4 +1,5 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
+# This script is compatible both with python 2 and 3; please keep it so

 import sys, subprocess

@@ -7,7 +8,7 @@ if len(sys.argv) > 2:
 encopt = sys.argv[2:-1]
 ofile  = sys.argv[-1]
 else:
-print 'usage: %s  [encode_options] ' % sys.argv[0]
+print('usage: %s  [encode_options] ' % sys.argv[0])
 sys.exit(1)

 analysis_cmd  = 'ffprobe -v error -of compact=p=0:nk=1 '
@@ -15,7 +16,7 @@ analysis_cmd += '-show_entries
frame_tags=lavfi.r128.I -f lavfi '
 analysis_cmd += "amovie='%s',ebur128=metadata=1" % ifile
 try:
 probe_out = subprocess.check_output(analysis_cmd, shell=True)
-except subprocess.CalledProcessError, e:
+except subprocess.CalledProcessError as e:
 sys.exit(e.returncode)
 loudness = ref = -23
 for line in probe_out.splitlines():
@@ -24,10 +25,10 @@ for line in probe_out.splitlines():
 loudness = sline
 adjust = ref - float(loudness)
 if abs(adjust) < 0.0001:
-print 'No normalization needed for ' + ifile
+print('No normalization needed for ' + ifile)
 else:
-print "Adjust %s by %.1fdB" % (ifile, adjust)
+print("Adjust %s by %.1fdB" % (ifile, adjust))
 norm_cmd  = ['ffmpeg', '-i', ifile, '-af', 'volume=%fdB' % adjust]
 norm_cmd += encopt + [ofile]
-print ' => %s' % ' '.join(norm_cmd)
+print(' => %s' % ' '.join(norm_cmd))
 subprocess.call(norm_cmd)
diff --git a/tools/zmqshell.py b/tools/zmqshell.py
index a7d1126006..ff229b29c9 100755
--- a/tools/zmqshell.py
+++ b/tools/zmqshell.py
@@ -1,4 +1,5 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
+# This script is compatible both with python 2 and 3; please keep it so

 import sys, zmq, cmd

@@ -14,10 +15,10 @@ class LavfiCmd(cmd.Cmd):
 def onecmd(self, cmd):
 if cmd == 'EOF':
 sys.exit(0)
-print 'Sending command:[%s]' % cmd
+print('Sending command:[%s]' % cmd)
 self.requester.send(cmd)
 message = self.requester.recv()
-print 'Received reply:[%s]' % message
+print('Received reply:[%s]' % message)

 try:
 bind_address = sys.argv[1] if len(sys.argv) > 1 else "tcp://localhost:"
-- 
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Reto Kromer]

Michael Niedermayer wrote:

>I think future work should be done as FFV1v5 v6 v7 on
>CELLAR/IETF

That is how it should be, in my opinion.

>why you ask ?
>because that way 
>its on its way to be a proper IETF standard from day 1
>there are already people who are interrested in this there,
>like myself and IIRC reto, and iam sure there are many more who
>would like to see more discussions about improving and
>extending the codecs in more fundamental ways.

Indeed, you remember correctly.

>also, you get more comments and testing on IETF/CELLAR
>and for work beyond ffv1v3/4 to be successfull a critical mass
>of people / time is needed. If everyone works seperate, which
>it seems a bit to me thats what is happening, it would be
>harder to move such an effort to completion

I plenty agree with you! The reason why I worked more alone is
the not welcoming environment. I am really too ill now and I do
not have anymore the energy for just ignoring the insults.

If you have any concrete idea how the environment could be made
more welcoming, I would be more than happy. (I am not thinking
about another code of conduct ;-) I would like to continue the
FFV1 journey with you and other interested people, because it
could be a fascinating one!

Best regards, Reto

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

[FFmpeg-devel] [PATCH] avfilter: add lut1d filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  29 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_lut3d.c   | 404 +++
 4 files changed, 435 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..72ce95f94a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10962,6 +10962,35 @@ Set maximal size in number of frames. Default is 0.
 Set first frame of loop. Default is 0.
 @end table
 
+@section lut1d
+
+Apply a 1D LUT to an input video.
+
+The filter accepts the following options:
+
+@table @option
+@item file
+Set the 1D LUT file name.
+
+Currently supported formats:
+@table @samp
+@item cube
+Iridas
+@end table
+
+@item interp
+Select interpolation mode.
+
+Available values are:
+
+@table @samp
+@item nearest
+Use values from the nearest defined point.
+@item linear
+Interpolate values using the linear interpolation.
+@end table
+@end table
+
 @anchor{lut3d}
 @section lut3d
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e5d3a57af7..e412000c8f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -258,6 +258,7 @@ OBJS-$(CONFIG_LIBVMAF_FILTER)+= 
vf_libvmaf.o framesync.o
 OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
 OBJS-$(CONFIG_LOOP_FILTER)   += f_loop.o
 OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
+OBJS-$(CONFIG_LUT1D_FILTER)  += vf_lut3d.o
 OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
 OBJS-$(CONFIG_LUT2_FILTER)   += vf_lut2.o framesync.o
 OBJS-$(CONFIG_LUT3D_FILTER)  += vf_lut3d.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9732ae5345..2fa9460335 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ extern AVFilter ff_vf_limiter;
 extern AVFilter ff_vf_loop;
 extern AVFilter ff_vf_lumakey;
 extern AVFilter ff_vf_lut;
+extern AVFilter ff_vf_lut1d;
 extern AVFilter ff_vf_lut2;
 extern AVFilter ff_vf_lut3d;
 extern AVFilter ff_vf_lutrgb;
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 27b79b860b..b5673b82bf 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2013 Clément Bœsch
+ * Copyright (c) 2018 Paul B Mahol
  *
  * This file is part of FFmpeg.
  *
@@ -975,3 +976,406 @@ AVFilter ff_vf_haldclut = {
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL | 
AVFILTER_FLAG_SLICE_THREADS,
 };
 #endif
+
+#if CONFIG_LUT1D_FILTER
+
+enum interp_1d_mode {
+INTERPOLATE_1D_NEAREST,
+INTERPOLATE_1D_LINEAR,
+NB_INTERP_1D_MODE
+};
+
+#define MAX_1D_LEVEL 65536
+
+typedef struct LUT1DContext {
+const AVClass *class;
+char *file;
+int interpolation;  ///lutsize = size;
+for (i = 0; i < size; i++) {
+lut1d->lut[0][i] = i * c;
+lut1d->lut[1][i] = i * c;
+lut1d->lut[2][i] = i * c;
+}
+}
+
+static int parse_cube_1d(AVFilterContext *ctx, FILE *f)
+{
+LUT1DContext *lut1d = ctx->priv;
+char line[MAX_LINE_SIZE];
+float min[3] = {0.0, 0.0, 0.0};
+float max[3] = {1.0, 1.0, 1.0};
+
+while (fgets(line, sizeof(line), f)) {
+if (!strncmp(line, "LUT_1D_SIZE ", 12)) {
+const int size = strtol(line + 12, NULL, 0);
+int i;
+
+if (size < 2 || size > MAX_1D_LEVEL) {
+av_log(ctx, AV_LOG_ERROR, "Too large or invalid 1D LUT 
size\n");
+return AVERROR(EINVAL);
+}
+lut1d->lutsize = size;
+for (i = 0; i < size; i++) {
+do {
+try_again:
+NEXT_LINE(0);
+if (!strncmp(line, "DOMAIN_", 7)) {
+float *vals = NULL;
+if  (!strncmp(line + 7, "MIN ", 4)) vals = min;
+else if (!strncmp(line + 7, "MAX ", 4)) vals = max;
+if (!vals)
+return AVERROR_INVALIDDATA;
+sscanf(line + 11, "%f %f %f", vals, vals + 1, vals + 
2);
+av_log(ctx, AV_LOG_DEBUG, "min: %f %f %f | max: %f %f 
%f\n",
+   min[0], min[1], min[2], max[0], max[1], max[2]);
+goto try_again;
+}
+} while (skip_line(line));
+if (sscanf(line, "%f %f %f", >lut[0][i], 
>lut[1][i], >lut[2][i]) != 3)
+return AVERROR_INVALIDDATA;
+lut1d->lut[0][i] *= max[0] - min[0];
+lut1d->lut[1][i] *= max[1] - min[1];
+lut1d->lut[2][i] *= max[2] - min[2];
+}
+break;
+}
+}
+return 0;
+}
+
+static const AVOption lut1d_options[] = {
+{ "file", "set 1D LUT file name", OFFSET(file), AV_OPT_TYPE_STRING, 
{.str=NULL}, .flags = FLAGS },
+{ "interp", "select interpolation mode", 

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Paul B Mahol]

On 8/23/18, Carl Eugen Hoyos  wrote:
> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>> On 8/22/18, Carl Eugen Hoyos  wrote:
>>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>>
 +switch (avctx->bits_per_coded_sample) {
 +case 12:
 + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
 + break;
 +default:
 + return AVERROR_INVALIDDATA;
 +}
>>>
>>> Why are the condition and the error needed?
>>
>> Because only that is supported.
>
> Do valid samples with other values exist?

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

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Carl Eugen Hoyos]

2018-08-22 21:24 GMT+02:00, Paul B Mahol :
> On 8/22/18, Carl Eugen Hoyos  wrote:
>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>
>>> +switch (avctx->bits_per_coded_sample) {
>>> +case 12:
>>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>> + break;
>>> +default:
>>> + return AVERROR_INVALIDDATA;
>>> +}
>>
>> Why are the condition and the error needed?
>
> Because only that is supported.

Do valid samples with other values exist?

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

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Michael Niedermayer]

On Wed, Aug 22, 2018 at 03:24:05PM -0500, Dave Rice wrote:
> 
> >> On Aug 22, 2018, at 14:12, Michael Niedermayer  
> >> wrote:
> >> 
> >> On Wed, Aug 22, 2018 at 03:14:53PM +0200, Jean-Baptiste Kempf wrote:
> >> Hello fellow devs,
> >> 
> >> VideoLAN is happy to invite you to the usual conference of the end of the 
> >> summer:
> >> VDD2018 is happening in Paris, for the 10 years of the original conf.
> >> 
> >> As usual, this is a very technical conference focused on open source 
> >> multimedia development.
> >> We will talk about AV1, FFv1, FFv2, x264/x265, VLC, FFmpeg and other 
> >> related technologies.
> > 
> > what is FFv2 ?
> 
> FFV2 is referenced in this patch http://akuvian.org/src/x264/ffv2.94.diff.
> 
> Also FFV2 is referenced as a derivative experimental work from Daala. 
> https://twitter.com/atomnuker/status/924846477083578368?s=21
> 
> Also FFV2 is referenced by Reto Kromer as a forked alternative to the work on 
> FFV1 version 4 by the IETF cellar working group. 
> https://twitter.com/retokromer/status/884030201050648576?s=21

I think future work should be done as FFV1v5 v6 v7 on CELLAR/IETF
why you ask ?
because that way 
its on its way to be a proper IETF standard from day 1
there are already people who are interrested in this there, like myself
and IIRC reto, and iam sure there are many more who would like to see
more discussions about improving and extending the codecs in more fundamental
ways.
also, you get more comments and testing on IETF/CELLAR
and for work beyond ffv1v3/4 to be successfull a critical mass of people / time
is needed. If everyone works seperate, which it seems a bit to me thats what
is happening, it would be harder to move such an effort to completion

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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation

[Fu, Linjie]

-Original Message-
From: Fu, Linjie 
Sent: Thursday, August 16, 2018 15:08
To: ffmpeg-devel@ffmpeg.org
Cc: Fu, Linjie 
Subject: [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation

Fix the live stream encoding problem using qsv when the first frame is not an 
IDR frame.

Add the extradata information when the IDR frame is missing in the first GOP.

Fix the bug reported in  ticket #6418.

[PATCH V2] Fix the coding style.

Signed-off-by: Linjie Fu 
---
 libavcodec/h264_mp4toannexb_bsf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
b/libavcodec/h264_mp4toannexb_bsf.c
index 794c82e650..fbb9f1fe20 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -33,6 +33,7 @@ typedef struct H264BSFContext {
 int32_t  pps_offset;
 uint8_t  length_size;
 uint8_t  new_idr;
+uint8_t  new_nal_slice;
 uint8_t  idr_sps_seen;
 uint8_t  idr_pps_seen;
 int  extradata_parsed;
@@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
AVPacket *out)
buf, nal_size, 1)) < 0)
 goto fail;
 s->new_idr = 0;
+s->new_nal_slice = 1;
 /* if only SPS has been seen, also insert PPS */
 } else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && 
s->idr_sps_seen && !s->idr_pps_seen) {
 if (s->pps_offset == -1) {
@@ -253,6 +255,12 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
AVPacket *out)
 ctx->par_out->extradata + 
s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
 buf, nal_size, 1)) < 0)
 goto fail;
+} else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE == 
unit_type && !s->idr_sps_seen && !s->idr_pps_seen){
+av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE when there is no 
IDR.\n");
+if ((ret = alloc_and_copy(out, ctx->par_out->extradata, 
ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
+goto fail;
+s->new_nal_slice = 1;
+s->new_idr = 0;
 } else {
 if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size, unit_type == 
H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
 goto fail;
--
2.17.1

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

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Reto Kromer]

Paul B Mahol wrote:

>So we already have 3 FFV2 variants.
>
>Which of them are actually useful?

Useful for what? E.g. 1 is a great source of inspiration! (At
least to me, since Dave Rice tweeted it on 2016-07-15.)

Best regards, Reto

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