Re: [FFmpeg-devel] [PATCHv4 3/4] libavcodec: v4l2: add codec formats

[Jorge Ramirez]

On 08/09/2017 03:37 AM, Michael Niedermayer wrote:

On Tue, Aug 08, 2017 at 06:07:07PM +0200, Jorge Ramirez-Ortiz wrote:

In addition, enable the multi planar raw formats.

Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
  libavcodec/v4l2_fmt.c | 38 +-
  1 file changed, 37 insertions(+), 1 deletion(-)

[...]


+{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0,  , 0
},

This looks odd and doesnt build


The previous version was missing the last field which would have left it 
un-initialized (so just added a null flag since I assume this was simply 
an error case that would not be processed?) I will fix it in v5 and 
enable the two flags for clarity then.


um, so sorry about the build.
what machine are you building on please? (ie, kernel? or maybe if you 
can its /usr/include/linux/videodev2.h API so I can try to reproduce?


Things do obviously build on my end - fate tests pass and so does 
encoding/decoding so I think we are back to the issue that you 
originally flagged when building on relatively old kernels.


This addition to configure would have prevented the build error on your 
v3 kernel that you last shared with me in last time btw.
*check_code cc linux/videodev2.h "int i = V4L2_CAP_VIDEO_M2M_MPLANE | 
V4L2_CAP_VIDEO_M2M | V4L2_BUF_FLAG_LAST;" || disable v4l2_m2m*



These are v4l2 checks that allow enabling/disable codecs depending on 
them being present on the API.


# check V4L2 codecs available in the API
check_header linux/fb.h
check_header linux/videodev.h
check_header linux/videodev2.h
check_code cc linux/videodev2.h "struct v4l2_frmsizeenum vfse; 
vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
check_code cc linux/videodev2.h "int i = V4L2_CAP_VIDEO_M2M_MPLANE | 
V4L2_CAP_VIDEO_M2M | V4L2_BUF_FLAG_LAST;" || disable v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_VC1_ANNEX_G;" && 
enable vc1_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_MPEG1;" && enable 
mpeg1_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_MPEG2;" && enable 
mpeg2_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_MPEG4;" && enable 
mpeg4_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_HEVC;" && enable 
hevc_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_H263;" && enable 
h263_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_H264;" && enable 
h264_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_VP8;" && enable 
vp8_v4l2_m2m
check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_VP9;" && enable 
vp9_v4l2_m2m


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

Re: [FFmpeg-devel] [PATCH] ffprobe: fix use of uninitialized variable

[Zhao Zhili]

On Wed, Aug 9, 2017 at 1:23 AM, Michael Niedermayer 
wrote:

> On Sun, Aug 06, 2017 at 03:39:07PM +0800, Zhao Zhili wrote:
> > ---
> >  ffprobe.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/ffprobe.c b/ffprobe.c
> > index f22c4f57ad..ac9ff051fa 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -3328,6 +3328,7 @@ static int parse_read_interval(const char
> > *interval_spec,
> >  }
> >  interval->end = lli;
> >  } else {
> > +interval->duration_frames = 0;
> >  ret = av_parse_time(, p, 1);
> >  if (ret < 0) {
> >  av_log(NULL, AV_LOG_ERROR, "Invalid interval
> end/duration
> > specification '%s'\n", p);
> > @@ -3337,6 +3338,7 @@ static int parse_read_interval(const char
> > *interval_spec,
> >  }
> >  } else {
> >  interval->has_end = 0;
> > +interval->duration_frames = 0;
> >  }
> >
> >  end:
> > @@ -3357,7 +3359,7 @@ static int parse_read_intervals(const char
> > *intervals_spec)
> >  n++;
> >  n++;
> >
> > -read_intervals = av_malloc_array(n, sizeof(*read_intervals));
> > +read_intervals = av_mallocz_array(n, sizeof(*read_intervals));
> >  if (!read_intervals) {
> >  ret = AVERROR(ENOMEM);
> >  goto end;
> > --
> > 2.13.2
>
> >  ffprobe.c |4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 59efe1bf808d9621c14252fd0e71dc4b9a635c7a  0001-ffprobe-fix-use-of-
> uninitialized-variable.patch
> > From 1d3fe1eb4cd27efc337a1fae302f5539e3c7459b Mon Sep 17 00:00:00 2001
> > From: Zhao Zhili 
> > Date: Sun, 6 Aug 2017 15:33:42 +0800
> > Subject: [PATCH] ffprobe: fix use of uninitialized variable
> >
> > ---
> >  ffprobe.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/ffprobe.c b/ffprobe.c
> > index f22c4f57ad..ac9ff051fa 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -3328,6 +3328,7 @@ static int parse_read_interval(const char
> *interval_spec,
> >  }
> >  interval->end = lli;
> >  } else {
> > +interval->duration_frames = 0;
> >  ret = av_parse_time(, p, 1);
> >  if (ret < 0) {
> >  av_log(NULL, AV_LOG_ERROR, "Invalid interval
> end/duration specification '%s'\n", p);
>
> > @@ -3337,6 +3338,7 @@ static int parse_read_interval(const char
> *interval_spec,
> >  }
> >  } else {
> >  interval->has_end = 0;
> > +interval->duration_frames = 0;
> >  }
>
> isnt has_end and end_is_offset 0 here and all uses of duration_frames
> under code checking either ?
>
>
If end_is_offset is 1 and *p is not '#', then duration_frames is not
initialized. So check end_is_offset doesn't prevent access uninitialized
value. And the current code didn't always check end_is_offset before access
duration_frames.

A simple test case:
ffprobe -show_frames -select_streams v -read_intervals '%+60' foo



>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default

[Philip Langdale]

On Tue, 8 Aug 2017 05:15:52 +
Manoj Bonda  wrote:

> Hi , 
> 
> HEVC issue for read-back API has been fixed and will be part of the
> upcoming drivers. Please help us understand the issue with the open
> gl interop. As per our understanding we are mapping the video surface
> to gl using the gl-interop and the app(mpv) will be doing the
> merging/de-interlacing part.
> 
> As per our understanding, in mpv we see merging/de-interlacing is
> being done using shader at
> 
> Call stack:
>gl_sc_generate() at utils.c:1,162 0x565daa
>finish_pass_direct() at video.c:1,115 0x569cb2
>reinterleave_vdpau() at video.c:3,031 0x57277a 
>pass_upload_image() at video.c:3,079
> 0x572b6b pass_render_frame() at video.c:2,506 0x570162 
>gl_video_render_frame() at video.c:2,877
> 0x571ce9 draw_frame() at vo_opengl.c:133 0x57d920 
>render_frame() at vo.c:817 0x579113  
>vo_thread() at vo.c:916 0x579610
> 
> we are not able to get how ffmpeg is using the vdpau-opengl interop. 
> Please suggest us how to repro vdpau-opengl  interop issue with
> ffmpeg. 
> 
> Please help us understand what needs to be done from our side for
> resolving this issue. Please do let us know if any our understandings
> are wrong.

It's the same issue. The GL interop API returns video data as fields, so
the field splitting for hevc is done incorrectly, just as it was
incorrect for the read-back API. Presumably, depending on how the driver
code is written, you may have needed to fix only a single spot, but I'm
guessing you probably need to fix the GL case separately, given that
fixing the vdpau mixer didn't fix either of the other two paths.

There is no repro with ffmpeg as it does not use the GL interop.

The mpv code does field merging, but that is what any client using
vdpau gl interop would do. You could reproduce this in any client.

And just because we're discussing this, we'd all love it if there was a
new mode where the interop surfaces were frame, rather than field based.

Thanks,

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

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Michael Niedermayer]

On Mon, Aug 07, 2017 at 12:31:01PM -0700, Dale Curtis wrote:
> On Fri, Aug 4, 2017 at 4:40 PM, Rodger Combs  wrote:
> 
> > +sc->ctts_data = av_fast_realloc(sc->ctts_data,
> > >ctts_allocated_size, request_size);
> > ^ this line is incorrect; setting realloc's first arg to its return value
> > leaks the existing allocation in the OOM case. Since you're doing your own
> > calculation for the desired new size here, you may want to use av_reallocp
> > (which frees the original allocation on failure).
> >
> 
> Thanks, fixed; kept av_fast_realloc() for size setting simplicity, but
> reused function-scope ctts_data as temporary.
> 
> 
> >
> > When reading a trun that requires this sort of realloc, is it common for
> > there to be any existing entries in the range we're writing? Would it be
> > safe to remove+replace them? Could we do a single realloc + single memmove,
> > and then fill the newly-opened space, rather than repeating the memmove for
> > each entry?
> >
> 
> Yes it's common for their to be existing entries. To be clear this occurs
> with standard files that are of sufficient length that a seek can occur
> before all trun boxes are read. We could speculatively move all entries
> based on the first insert and total entries count, but their are several
> conditionals in av_add_index_entry() which may cause a bail out and such
> failure would be unrecoverable (maybe painfully?) if we moved everything
> ahead of time.
> 
> - dale

>  libavformat/isom.h   |1 
>  libavformat/mov.c|   79 +--
>  tests/fate/seek.mak  |3 +
>  tests/ref/seek/extra-mp4 |  134 
> +++
>  4 files changed, 189 insertions(+), 28 deletions(-)
> a2c3a9c29cc60b76508cc7fd9168bdffd60c6ead  ctts_fix_v7.patch
> From 4938dac2d9f3b40c62822d9129046edbde44468d Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Mon, 17 Jul 2017 17:38:09 -0700
> Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is
>  enabled.
> 
> When sidx box support is enabled, the code will skip reading all
> trun boxes (each containing ctts entries for samples inthat box).
> 
> If seeks are attempted before all ctts values are known, the old
> code would dump ctts entries into the wrong location. These are
> then used to compute pts values which leads to out of order and
> incorrectly timestamped packets.
> 
> This patch fixes ctts processing by always using the index returned
> by av_add_index_entry() as the ctts_data index. When the index gains
> new entries old values are reshuffled as appropriate.
> 
> This approach makes sense since the mov demuxer is already relying
> on the mapping of AVIndex entries to samples for correct demuxing.
> 
> As a result of this all ctts entries are now 1-count. A followup
> change will be submitted to remove support for > 1 count entries
> which will simplify seeking.
> 
> Notes for future improvement:
> Probably there are other boxes (stts, stsc, etc) that are impacted
> by this issue... this patch only attempts to fix ctts since it
> completely breaks packet timestamping.
> 
> This patch continues using an array for the ctts data, which is not
> the most ideal given the rearrangement that needs to happen (via
> memmove as new entries are read in). Ideally AVIndex and the ctts
> data would be set-type structures so addition is always worst case
> O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
> noticeable during seeks.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/isom.h   |   1 +
>  libavformat/mov.c|  79 ++--
>  tests/fate/seek.mak  |   3 ++
>  tests/ref/seek/extra-mp4 | 134 
> +++
>  4 files changed, 189 insertions(+), 28 deletions(-)
>  create mode 100644 tests/ref/seek/extra-mp4

the fate test seems to fail:

did i do something silly ?

TESTseek-extra-mp4
--- ./tests/ref/seek/extra-mp4  2017-08-09 03:46:04.041659416 +0200
+++ tests/data/fate/seek-extra-mp4  2017-08-09 03:46:18.565659589 +0200
@@ -1,134 +1,134 @@
-ret: 0 st: 0 flags:1 dts:-0.03 pts: 0.00 pos:   4174 size:   
147
-ret: 0 st: 0 flags:0 dts: 0.00 pts: 0.03 pos:   4321 size:
24
-ret: 0 st: 0 flags:0 dts: 0.03 pts: 0.07 pos:   4345 size:  
6779
-ret: 0 st: 0 flags:0 dts: 0.07 pts: 0.10 pos:  11124 size: 
11041
+ret: 0 st: 0 flags:1 dts:-0.03 pts: 0.00 pos: 48 size:   
147
+ret: 0 st: 0 flags:0 dts: 0.00 pts: 0.03 pos:195 size:
24
+ret: 0 st: 0 flags:0 dts: 0.03 pts: 0.07 pos:219 size:  
6779
+ret: 0 st: 0 flags:0 dts: 0.07 pts: 0.10 pos:   6998 size: 
11041
 ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts:-0.03 pts: 0.00 pos:   4174 size:   
147
-ret: 0 st: 0 flags:0 

[FFmpeg-devel] [PATCH] dynaudnorm: Increment input outside of the FFMIN macro so it doesn't get double incremented.

[andyndeanna]

Greetings,

Please find attached a patch for the dynaudnorm filter.  Under certain
conditions, the output to the filter will clip at the beginning.  This can
be demonstrated with the following:

ffmpeg -filter_complex "aevalsrc=0:s=48000:d=0.6
[a_in0];aevalsrc=0.1*sin(440*2*PI*t)*cos(0.5*2*PI*t):s=48000:d=20
[a_in1];[a_in0] [a_in1] concat=n=2:v=0:a=1 [a_in];[a_in]
dynaudnorm=b=1:m=100.0 [a_out]" -map "[a_out]" test.wav


The root cause is that the FFMIN macro evaluates the minimum argument
twice, resulting in the variable "input" getting incremented twice.

Thanks,
Andy


0001-Increment-input-outside-of-the-FFMIN-macro-so-it-doe.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support

[Jun Zhao]

V2: Follow libx264 "coder" option style, base on Hendrik Leppkes code review.
From 28e4dc3533be2b7c7493a08de7143c042c9923c1 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 8 Aug 2017 03:33:53 -0400
Subject: [PATCH V2] lavc/vaapi_encode_h264: add "coder" option support

Follow libx264 style to support coder option, default is
enabled cabac.

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

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f9fcd805a4..4e1df182a0 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -168,6 +168,8 @@ typedef struct VAAPIEncodeH264Options {
 int qp;
 int quality;
 int low_power;
+// Entropy encoder type
+int coder;
 } VAAPIEncodeH264Options;
 
 
@@ -783,6 +785,8 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 VAEncPictureParameterBufferH264   *vpic = ctx->codec_picture_params;
 VAAPIEncodeH264Context*priv = ctx->priv_data;
 VAAPIEncodeH264MiscSequenceParams *mseq = >misc_sequence_params;
+VAAPIEncodeH264Options *opt =
+(VAAPIEncodeH264Options*)ctx->codec_options_data;
 int i;
 
 {
@@ -927,8 +931,12 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 vpic->num_ref_idx_l0_active_minus1 = 0;
 vpic->num_ref_idx_l1_active_minus1 = 0;
 
-vpic->pic_fields.bits.entropy_coding_mode_flag =
-((avctx->profile & 0xff) != 66);
+if (opt->coder) {
+vpic->pic_fields.bits.entropy_coding_mode_flag =
+((avctx->profile & 0xff) != 66);
+} else {
+vpic->pic_fields.bits.entropy_coding_mode_flag = 0;
+}
 vpic->pic_fields.bits.weighted_pred_flag = 0;
 vpic->pic_fields.bits.weighted_bipred_idc = 0;
 vpic->pic_fields.bits.transform_8x8_mode_flag =
@@ -1283,6 +1291,12 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "low_power", "Use low-power encoding mode (experimental: only supported "
   "on some platforms, does not support all features)",
   OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
+{ "coder", "Entropy coder type",
+  OFFSET(coder), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS, "coder" },
+{ "cavlc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
+{ "cabac", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
+{ "vlc",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
+{ "ac",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
 { NULL },
 };
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCHv4 3/4] libavcodec: v4l2: add codec formats

[Michael Niedermayer]

On Tue, Aug 08, 2017 at 06:07:07PM +0200, Jorge Ramirez-Ortiz wrote:
> In addition, enable the multi planar raw formats.
> 
> Reviewed-by: Jorge Ramirez 
> Tested-by: Jorge Ramirez 
> ---
>  libavcodec/v4l2_fmt.c | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
[...]

> +{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0,  , 0  
>   },

This looks odd and doesnt build

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] pixfmt: Support chroma-derived and icpct color matrices

[Michael Niedermayer]

On Tue, Aug 08, 2017 at 04:14:30PM +0200, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara 
> ---
> Missing version bump.
> Vittorio
> 
>  libavutil/pixdesc.c | 4 
>  libavutil/pixfmt.h  | 3 +++
>  2 files changed, 7 insertions(+)

doesnt apply cleanly:

Applying: pixfmt: Support chroma-derived and icpct color matrices
error: patch failed: libavutil/pixdesc.c:1806
error: libavutil/pixdesc.c: patch does not apply
error: patch failed: libavutil/pixfmt.h:384
error: libavutil/pixfmt.h: patch does not apply
Patch failed at 0001 pixfmt: Support chroma-derived and icpct color matrices
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]

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

[FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Sasi Inguva]

According to 
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
 and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3

Signed-off-by: Sasi Inguva 
---
 libavformat/movenc.c| 22 +++---
 tests/ref/fate/adtstoasc_ticket3715 |  4 ++--
 tests/ref/fate/copy-psp |  4 ++--
 tests/ref/fate/movenc   | 12 ++--
 4 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0e5b45d150..5c53ab24e0 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2208,14 +2208,16 @@ static int mov_preroll_write_stbl_atoms(AVIOContext 
*pb, MOVTrack *track)
 (AVRational){1, 1000},
 (AVRational){1, 48000});
 
-if (track->entry) {
-sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
-if (!sgpd_entries)
-return AVERROR(ENOMEM);
-}
+if (!track->entry)
+return 0;
 
-av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS);
+sgpd_entries = av_malloc_array(track->entry, sizeof(*sgpd_entries));
+if (!sgpd_entries)
+return AVERROR(ENOMEM);
 
+av_assert0(track->par->codec_id == AV_CODEC_ID_OPUS || 
track->par->codec_id == AV_CODEC_ID_AAC);
+
+if (track->par->codec_id == AV_CODEC_ID_OPUS) {
 for (i = 0; i < track->entry; i++) {
 int roll_samples_remaining = roll_samples;
 int distance = 0;
@@ -2242,6 +2244,12 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb, 
MOVTrack *track)
 sgpd_entries[entries].group_description_index = distance ? ++group 
: 0;
 }
 }
+} else {
+entries++;
+sgpd_entries[entries].count = track->sample_count;
+sgpd_entries[entries].roll_distance = 1;
+sgpd_entries[entries].group_description_index = ++group;
+}
 entries++;
 
 if (!group) {
@@ -2304,7 +2312,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->cenc.aes_ctr) {
 ff_mov_cenc_write_stbl_atoms(>cenc, pb);
 }
-if (track->par->codec_id == AV_CODEC_ID_OPUS) {
+if (track->par->codec_id == AV_CODEC_ID_OPUS || track->par->codec_id == 
AV_CODEC_ID_AAC) {
 mov_preroll_write_stbl_atoms(pb, track);
 }
 return update_size(pb, pos);
diff --git a/tests/ref/fate/adtstoasc_ticket3715 
b/tests/ref/fate/adtstoasc_ticket3715
index 949b565c2f..96795a2ca3 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,5 +1,5 @@
-ef8ce3cbd1d86113e7c991a816086068 *tests/data/fate/adtstoasc_ticket3715.mov
-33270 tests/data/fate/adtstoasc_ticket3715.mov
+0221e04333e6ac432fa42960502f0d5a *tests/data/fate/adtstoasc_ticket3715.mov
+33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
 #media_type 0: audio
diff --git a/tests/ref/fate/copy-psp b/tests/ref/fate/copy-psp
index 6603d3ff26..81eb172549 100644
--- a/tests/ref/fate/copy-psp
+++ b/tests/ref/fate/copy-psp
@@ -1,5 +1,5 @@
-6889223644fc560069c8591984175a62 *tests/data/fate/copy-psp.psp
-2041379 tests/data/fate/copy-psp.psp
+cada61453a2483ef8ba1fb82c8bbff25 *tests/data/fate/copy-psp.psp
+2041433 tests/data/fate/copy-psp.psp
 #extradata 0:   51, 0xaf6d1012
 #extradata 1:2, 0x00b200a1
 #tb 0: 1/9
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 09e603aeb7..47bcf9d515 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -1,18 +1,18 @@
 write_data len 36, time nopts, type header atom ftyp
-write_data len 2335, time nopts, type header atom -
+write_data len 2389, time nopts, type header atom -
 write_data len 788, time 100, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-214242e9c7c93171d2f47f5b47776559 3269 non-empty-moov
+17a37691eba8b858cf15e60aa9a7dbf7 3323 non-empty-moov
 write_data len 36, time nopts, type header atom ftyp
-write_data len 2667, time nopts, type header atom -
+write_data len 2721, time nopts, type header atom -
 write_data len 908, time 97, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-44467d568a3cc38d414fd8ed4b2a968f 3721 non-empty-moov-elst
+0026ffe059c06c592021f972bf2c5e79 3775 non-empty-moov-elst
 write_data len 36, time nopts, type header atom ftyp
-write_data len 2575, time nopts, type header atom -
+write_data len 2629, time nopts, type header atom -
 write_data len 908, time 100, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-de22b98a3885f9b4b83cdd48ff46aeb9 3629 non-empty-moov-no-elst
+c184e168ac1e5bb3d9c70e580ab6179c 3683 non-empty-moov-no-elst
 write_data len 20, time nopts, type header atom ftyp
 write_data len 1171, time nopts, type header atom -
 write_data len 728, time 0, type sync atom moof
-- 
2.14.0.434.g98096fd7a8-goog

Re: [FFmpeg-devel] [WIP] libcodec2 wrapper + de/muxer in FFmpeg

[Tomas Härdin]

On Fri, 2017-08-04 at 19:20 +0200, Tomas Härdin wrote:
> TODO:
> 
> * have -mode be an integer and use the CONST system Nicolas mentioned
> * option for demuxing multiple frames at a time
> * sort the extradata aliasing thing
> * address API issues in libcodec2, possibly modify the format (there
> should still be time)

Had some time today and went over and addressed all TODOs but the API
issue in libcodec2. For that I need to figure out why reCAPTCHA is
broken on sourceforge.net, to be able to fix my ML registration >:|

I split the patchset into one for lavc and a second for lavf, plus a
third for the small ffmpeg CLI fix. Should make review simpler.

I also removed the 0xC0DEC2 magic from extradata, mostly as part of
reworking codec2utils

Finally I made codec2_probe only award AVPROBE_SCORE_MAX if the file
extension is .c2

Feel free to comment

/Tomas
From b693b6175289e6ad0c643462d8f69f6830086099 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Thu, 3 Aug 2017 17:33:04 +0200
Subject: [PATCH 3/3] Don't complain about codec2's 700 bit/s modes in ffmpeg.c

---
 ffmpeg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 888d19a647..09a5b541c0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3480,7 +3480,8 @@ static int init_output_stream(OutputStream *ost, char *error, int error_len)
 av_buffersink_set_frame_size(ost->filter->filter,
 ost->enc_ctx->frame_size);
 assert_avoptions(ost->encoder_opts);
-if (ost->enc_ctx->bit_rate && ost->enc_ctx->bit_rate < 1000)
+if (ost->enc_ctx->bit_rate && ost->enc_ctx->bit_rate < 1000 &&
+ost->enc_ctx->codec_id != AV_CODEC_ID_CODEC2 /* don't complain about 700 bit/s modes */)
 av_log(NULL, AV_LOG_WARNING, "The bitrate parameter is set too low."
  " It takes bits/s as argument, not kbits/s\n");
 
-- 
2.13.3

From 057b941e82aeb8ccc835fb6a11baac4cb245a531 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Tue, 8 Aug 2017 15:28:06 +0200
Subject: [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files

---
 Changelog|   1 +
 doc/general.texi |   2 +
 libavformat/Makefile |   4 +
 libavformat/allformats.c |   2 +
 libavformat/codec2.c | 313 +++
 libavformat/rawenc.c |  13 ++
 libavformat/utils.c  |   1 +
 libavformat/version.h|   2 +-
 8 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/codec2.c

diff --git a/Changelog b/Changelog
index a3a16f0073..c95ffa8d16 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - tlut2 video filter
 - floodfill video filter
 - codec2 en/decoding via libcodec2
+- muxer/demuxer for raw codec2 files and .c2 files
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/general.texi b/doc/general.texi
index fd8d657e4e..4bcc2b2d91 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -299,6 +299,8 @@ library:
 @item BRSTM @tab   @tab X
 @tab Audio format used on the Nintendo Wii.
 @item BWF   @tab X @tab X
+@item codec2 (raw)  @tab X @tab X
+@item codec2 (.c2 files)@tab X @tab X
 @item CRI ADX   @tab X @tab X
 @tab Audio-only format used in console video games.
 @item Discworld II BMV  @tab   @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index b0ef82cdd4..9aa3466161 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -128,6 +128,10 @@ OBJS-$(CONFIG_CAVSVIDEO_MUXER)   += rawenc.o
 OBJS-$(CONFIG_CDG_DEMUXER)   += cdg.o
 OBJS-$(CONFIG_CDXL_DEMUXER)  += cdxl.o
 OBJS-$(CONFIG_CINE_DEMUXER)  += cinedec.o
+OBJS-$(CONFIG_CODEC2_DEMUXER)+= ../libavcodec/codec2utils.o codec2.o rawdec.o pcm.o
+OBJS-$(CONFIG_CODEC2_MUXER)  += ../libavcodec/codec2utils.o codec2.o rawenc.o
+OBJS-$(CONFIG_CODEC2RAW_DEMUXER) += ../libavcodec/codec2utils.o codec2.o rawdec.o pcm.o
+OBJS-$(CONFIG_CODEC2RAW_MUXER)   += rawenc.o
 OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1ebc14231c..26f0f1eccd 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -94,6 +94,8 @@ static void register_all(void)
 REGISTER_DEMUXER (CDG,  cdg);
 REGISTER_DEMUXER (CDXL, cdxl);
 REGISTER_DEMUXER (CINE, cine);
+REGISTER_MUXDEMUX(CODEC2,   codec2);
+REGISTER_MUXDEMUX(CODEC2RAW,codec2raw);
 REGISTER_DEMUXER (CONCAT,   concat);
 REGISTER_MUXER   (CRC,  crc);
 REGISTER_MUXER   (DASH,

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Carl Eugen Hoyos]

Hi!

> Am 08.08.2017 um 22:55 schrieb Sasi Inguva :
> 
> Ping!

Please send a patch without the cosmetic changes to allow reviewing.

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Sasi Inguva]

Ping!

On Aug 5, 2017 10:08 AM, "Sasi Inguva"  wrote:

> To the best of my knowledge, all fate changes are benign. All of them
> correspond to a size increase of 54 bytes, which is the total size of the
> new atoms added.
>
> On Sat, Aug 5, 2017 at 9:27 AM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 8/4/2017 9:35 PM, Sasi Inguva wrote:
>> > According to https://developer.apple.com/li
>> brary/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>> and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3
>> >
>> > Signed-off-by: Sasi Inguva 
>> > ---
>> >  libavformat/movenc.c| 70 +-
>> ---
>> >  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
>> >  tests/ref/fate/copy-psp |  4 +--
>> >  tests/ref/fate/movenc   | 12 +++
>> >  4 files changed, 49 insertions(+), 41 deletions(-)
>>
>> Probably OK, if FATE changes are benign.
>>
>> - Derek
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding

[Clément Bœsch]

On Tue, Aug 08, 2017 at 09:09:44AM +, maxime taisant wrote:
> From: Maxime Taisant 
> 
> Hi,
> 
> Here is some SSE optimisations for the dwt function used to decode JPEG2000.
> I tested this code by using the time command while reading a JPEG2000 encoded 
> video with ffmpeg and, on average, I observed a 4.05% general improvement, 
> and a 12.67% improvement on the dwt decoding part alone.
> In the nasm code, you can notice that the SR1DFLOAT macro appear twice. One 
> version is called in the nasm code by the HORSD macro and the other is called 
> in the C code of the dwt function, I couldn't figure out a way to make only 
> one macro.
> I also couldn't figure out a good way to optimize the VER_SD part, so that is 
> why I left it unchanged, with just a SSE-optimized version of the SR_1D_FLOAT 
> function.
> 
> Regards.
> 
> ---
>  libavcodec/jpeg2000dwt.c  |  21 +-
>  libavcodec/jpeg2000dwt.h  |   6 +
>  libavcodec/x86/jpeg2000dsp.asm| 794 
> ++
>  libavcodec/x86/jpeg2000dsp_init.c |  55 +++
>  4 files changed, 863 insertions(+), 13 deletions(-)
> 
> diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
> index 55dd5e89b5..69c935980d 100644
> --- a/libavcodec/jpeg2000dwt.c
> +++ b/libavcodec/jpeg2000dwt.c
> @@ -558,16 +558,19 @@ int ff_jpeg2000_dwt_init(DWTContext *s, int 
> border[2][2],
>  }
>  switch (type) {
>  case FF_DWT97:
> +dwt_decode = dwt_decode97_float;
>  s->f_linebuf = av_malloc_array((maxlen + 12), sizeof(*s->f_linebuf));
>  if (!s->f_linebuf)
>  return AVERROR(ENOMEM);
>  break;
>   case FF_DWT97_INT:
> +dwt_decode = dwt_decode97_int;
>  s->i_linebuf = av_malloc_array((maxlen + 12), sizeof(*s->i_linebuf));
>  if (!s->i_linebuf)
>  return AVERROR(ENOMEM);
>  break;
>  case FF_DWT53:
> +dwt_decode = dwt_decode53;
>  s->i_linebuf = av_malloc_array((maxlen +  6), sizeof(*s->i_linebuf));
>  if (!s->i_linebuf)
>  return AVERROR(ENOMEM);

Using globals is not acceptable, you need to fix that.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCHv4 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/08/2017 06:07 PM, Jorge Ramirez-Ortiz wrote:

  OBJS-$(CONFIG_VP8_MEDIACODEC_DECODER)  += mediacodecdec.o
  OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec_other.o
  OBJS-$(CONFIG_VP8_VAAPI_ENCODER)   += vaapi_encode_vp8.o
+OBJS-$(CONFIG_VP8_V4L2M2M_DECODER) += v4l2_m2m_dec.o
+OBJS-$(CONFIG_VP8_V4L2M2M_ENCODER) += v4l2_m2m_enc.o
  OBJS-$(CONFIG_VP9_DECODER) += vp9.o vp9data.o vp9dsp.o vp9lpf.o 
vp9recon.o \
vp9block.o vp9prob.o vp9mvs.o 
vp56rac.o \
vp9dsp_8bpp.o vp9dsp_10bpp.o 
vp9dsp_12bpp.o
  OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
  OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
  OBJS-$(CONFIG_VP9_VAAPI_ENCODER)   += vaapi_encode_vp9.o


sorry, fixing the below in v5 as well as the carriage returns introduced 
in Changelog.



-OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
+OBJS-$(CONFIG_VP9_V4L2M2M_DECODER)  += v4l2_m2m_dec.o
  OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
  OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
  OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4712592..d154ac9 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -207,8 +207,10 @@ static void register_all(void)
  REGISTER_ENCDEC (H263,  h263);
  REGISTER_DECODER(H263I, h263i);
  REGISTER_ENCDEC (H263P, h263p);
+REGISTER_ENCDEC (H263_V4L2M2M,  h263_v4l2m2m);
  REGISTER_DECODER(H264,  h264);
  REGISTER_DECODER(H264_CRYSTALHD,h264_crystalhd);
+REGISTER_ENCDEC (H264_V4L2M2M,  h264_v4l2m2m);


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

Re: [FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding

[Ivan Kalvachev]

On 8/8/17, maxime taisant  wrote:
> From: Maxime Taisant 
>
> Hi,
>
> Here is some SSE optimisations for the dwt function used to decode JPEG2000.
> I tested this code by using the time command while reading a JPEG2000
> encoded video with ffmpeg and, on average, I observed a 4.05% general
> improvement, and a 12.67% improvement on the dwt decoding part alone.
> In the nasm code, you can notice that the SR1DFLOAT macro appear twice. One
> version is called in the nasm code by the HORSD macro and the other is
> called in the C code of the dwt function, I couldn't figure out a way to
> make only one macro.

You want to use the same macro at two locations or
you want to have 1 function and "call" it from 2 places?

For the former, I'd guess that you might have been getting
errors about duplicated labels, since you use the local to the file form
instead local to the macro form. aka: ".loop" vs "%%loop".

> I also couldn't figure out a good way to optimize the VER_SD part, so that
> is why I left it unchanged, with just a SSE-optimized version of the
> SR_1D_FLOAT function.

[...]
> +.extend:
> +shl i0d, 2
> +shl i1d, 2
> +mov j0q, i0q
> +mov j1q, i1q
> +movups m0, [lineq+j0q+4]
> +shufps m0, m0, 0x1B

The x86inc provides with readable method for the shuffle constant.
q where X is index in the source reg.
Using q3210 would generate constant that leaves all elements at their
original places.
The 0x1B is q0123 , that is swap, isn't it?.

Also, minor cosmetic nitpick.
 usually the first parameters are placed so their commas are vertically aligned.
This applies only when the parameter is register (so no jmp labels or
[] addresses ).

[...]
> +;line{2*i,2*(i+1),2*(i+2),2*(i+3)} -=
> F_LFTG_DELTA*(line{2*i-1,2*(i+1)-1,2*(i+2)-1,2*(i+3)-1}+line{2*i+1,2*(i+1)+1,2*(i+2)+1,2*(i+3)+1})
> +movups m0, [lineq+2*j0q-28]
> +movups m4, [lineq+2*j0q-12]
> +movups m1, m0
> +shufps m0, m4, 0xDD
> +shufps m1, m4, 0x88

The x86inc provides with a way to emulate 3 operand avx.
This means it hides one of the movaps (use 'a' for reg reg).
shufps m1, m0, m4, 0x88
shufps m0, m4, 0xDD

[...]
> +movups m2, [lineq+2*j0q-24]
> +movups m5, [lineq+2*j0q-8]
> +shufps m2, m5, 0xDD
> +addps m2, m1
> +mulps m2, m3
> +subps m0, m2
> +movups m4, m1
> +shufps m1, m0, 0x44 ; 0100'0100 q1010
Is that movlhps m1, m0 ?

> +shufps m1, m1, q3120
> +shufps m4, m0, 0xEE
> +shufps m4, m4, 0xD8


That's not comprehensive review, so other should still join in.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dvenc: Support adjusting the quantizer deadzone

[Michael Niedermayer]

On Mon, Aug 07, 2017 at 01:20:55AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dv.h|  3 +++
>  libavcodec/dvenc.c | 24 +++-
>  2 files changed, 26 insertions(+), 1 deletion(-)

patchset applied

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH] ffprobe: fix use of uninitialized variable

[Michael Niedermayer]

On Sun, Aug 06, 2017 at 03:39:07PM +0800, Zhao Zhili wrote:
> ---
>  ffprobe.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/ffprobe.c b/ffprobe.c
> index f22c4f57ad..ac9ff051fa 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -3328,6 +3328,7 @@ static int parse_read_interval(const char
> *interval_spec,
>  }
>  interval->end = lli;
>  } else {
> +interval->duration_frames = 0;
>  ret = av_parse_time(, p, 1);
>  if (ret < 0) {
>  av_log(NULL, AV_LOG_ERROR, "Invalid interval end/duration
> specification '%s'\n", p);
> @@ -3337,6 +3338,7 @@ static int parse_read_interval(const char
> *interval_spec,
>  }
>  } else {
>  interval->has_end = 0;
> +interval->duration_frames = 0;
>  }
> 
>  end:
> @@ -3357,7 +3359,7 @@ static int parse_read_intervals(const char
> *intervals_spec)
>  n++;
>  n++;
> 
> -read_intervals = av_malloc_array(n, sizeof(*read_intervals));
> +read_intervals = av_mallocz_array(n, sizeof(*read_intervals));
>  if (!read_intervals) {
>  ret = AVERROR(ENOMEM);
>  goto end;
> -- 
> 2.13.2

>  ffprobe.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 59efe1bf808d9621c14252fd0e71dc4b9a635c7a  
> 0001-ffprobe-fix-use-of-uninitialized-variable.patch
> From 1d3fe1eb4cd27efc337a1fae302f5539e3c7459b Mon Sep 17 00:00:00 2001
> From: Zhao Zhili 
> Date: Sun, 6 Aug 2017 15:33:42 +0800
> Subject: [PATCH] ffprobe: fix use of uninitialized variable
> 
> ---
>  ffprobe.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/ffprobe.c b/ffprobe.c
> index f22c4f57ad..ac9ff051fa 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -3328,6 +3328,7 @@ static int parse_read_interval(const char 
> *interval_spec,
>  }
>  interval->end = lli;
>  } else {
> +interval->duration_frames = 0;
>  ret = av_parse_time(, p, 1);
>  if (ret < 0) {
>  av_log(NULL, AV_LOG_ERROR, "Invalid interval end/duration 
> specification '%s'\n", p);

> @@ -3337,6 +3338,7 @@ static int parse_read_interval(const char 
> *interval_spec,
>  }
>  } else {
>  interval->has_end = 0;
> +interval->duration_frames = 0;
>  }

isnt has_end and end_is_offset 0 here and all uses of duration_frames
under code checking either ?


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97*

[Michael Niedermayer]

On Sun, Aug 06, 2017 at 05:01:45AM +0200, Michael Niedermayer wrote:
> Fix multiple: runtime error: signed integer overflow: 6497 * 3409630 cannot 
> be represented in type 'int'
> Fixes: 2819/clusterfuzz-testcase-minimized-4743700301217792
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dirac_dwt.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Vittorio Giovara]

> If I want to render this video on screen, say a SDR screen, or my
> player is just not HDR capable (yet), what transfer do I use? The
> value avcodec gives me has not much meaning in that case (because I
> can't deal with HLG yet), and the original "legacy" value meant to be
> used in these cases was overriden and lost.

Uh? The original "legacy" value has no meaning, bt709, bt2020, and the
SDR part of HLG are all the same.
The libavcodec decoder "prefers" using the alternative transfer
because it is the "real one", and ffmpeg offers means to support it
correctly (zscale).
As long as you don't use any odd transfer (like log316) or the ones
that are typically used for SD content, it will render the SDR
transfer correctly.
I believe this is a safe assumption for a software system (like
ffmpeg), less so for a hardware one (like a broadcaster's decoder),
hence the SEI dance.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv4 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez-Ortiz]

This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).

This has been tested on Qualcomm's DragonBoard 410c and 820c

Tested decoders:
   - h264
   - mpeg4
   - vp8
   - vp9
   - hevc

Tested encoders:
- h264
- h263
- mpeg4

Tested transcoding (concurrent encoding/decoding)

Some of the changes introduced:
- v4l2: code cleanup and abstractions added
- v4l2: follow the new encode/decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS.
- v4l2: vp8 and mpeg4 decoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: fixed make install and fate issues.
- v4l2: codecs enabled/disabled depending on pixfmt defined
- v4l2: pass timebase/framerate to the context

[1] https://lwn.net/Articles/697956/

Reviewed-by: Jorge Ramirez 
Reviewed-by: Alexis Ballier 
Tested-by: Jorge Ramirez 
---
 Changelog |   3 +-
 configure |  30 ++-
 libavcodec/Makefile   |  19 +-
 libavcodec/allcodecs.c|   9 +
 libavcodec/v4l2_buffers.c | 585 ++
 libavcodec/v4l2_buffers.h | 249 ++
 libavcodec/v4l2_fmt.c |  11 +-
 libavcodec/v4l2_m2m.c | 381 +++
 libavcodec/v4l2_m2m.h |  52 
 libavcodec/v4l2_m2m_avcodec.h |  32 +++
 libavcodec/v4l2_m2m_dec.c | 239 +
 libavcodec/v4l2_m2m_enc.c | 290 +
 12 files changed, 1889 insertions(+), 11 deletions(-)
 create mode 100644 libavcodec/v4l2_buffers.c
 create mode 100644 libavcodec/v4l2_buffers.h
 create mode 100644 libavcodec/v4l2_m2m.c
 create mode 100644 libavcodec/v4l2_m2m.h
 create mode 100644 libavcodec/v4l2_m2m_avcodec.h
 create mode 100644 libavcodec/v4l2_m2m_dec.c
 create mode 100644 libavcodec/v4l2_m2m_enc.c

diff --git a/Changelog b/Changelog
index c797d68..b1bc7fb 100644
--- a/Changelog
+++ b/Changelog
@@ -32,6 +32,7 @@ version :
 - unpremultiply video filter
 - tlut2 video filter
 - floodfill video filter
+- V4L2 mem2mem HW accelerated codecs support
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
@@ -68,7 +69,6 @@ version 3.3:
 - Intel QSV-accelerated VP8 video decoding
 - VAAPI-accelerated deinterlacing
 
-
 version 3.2:
 - libopenmpt demuxer
 - tee protocol
@@ -108,7 +108,6 @@ version 3.2:
 - Changed mapping of rtp MIME type G726 to codec g726le.
 - spec compliant VAAPI/DXVA2 VC-1 decoding of slices in frame-coded images
 
-
 version 3.1:
 - DXVA2-accelerated HEVC Main10 decoding
 - fieldhint filter
diff --git a/configure b/configure
index ed94de0..6040c6f 100755
--- a/configure
+++ b/configure
@@ -149,6 +149,7 @@ Component options:
   --disable-pixelutils disable pixel utils in libavutil
 
 Individual component options:
+  --disable-v4l2_m2m   disable V4L2 mem2mem code [autodetect]
   --disable-everything disable all components listed below
   --disable-encoder=NAME   disable encoder NAME
   --enable-encoder=NAMEenable encoder NAME
@@ -1432,6 +1433,7 @@ AVCODEC_COMPONENTS="
 
 AVDEVICE_COMPONENTS="
 indevs
+v4l2_m2m
 outdevs
 "
 AVFILTER_COMPONENTS="
@@ -2270,6 +2272,7 @@ map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
 loongson2_deps="mips"
 loongson3_deps="mips"
 v4l2_deps_any="linux_videodev2_h sys_videoio_h"
+v4l2_m2m_select="v4l2"
 mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
@@ -2742,6 +2745,8 @@ nvenc_deps="cuda"
 nvenc_deps_any="dlopen LoadLibrary"
 nvenc_encoder_deps="nvenc"
 
+h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
+h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
 h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
 h264_cuvid_decoder_deps="cuda cuvid"
 h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
@@ -2760,6 +2765,8 @@ h264_vda_decoder_deps="vda"
 h264_vda_decoder_select="h264_decoder"
 h264_vdpau_decoder_deps="vdpau"
 h264_vdpau_decoder_select="h264_decoder"
+h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
+h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
 hevc_cuvid_decoder_deps="cuda cuvid"
 hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
 hevc_mediacodec_decoder_deps="mediacodec"
@@ -2771,12 +2778,15 @@ hevc_qsv_encoder_deps="libmfx"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="vaapi_encode golomb"
+hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
+hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
 mjpeg_cuvid_decoder_deps="cuda cuvid"
 mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 

[FFmpeg-devel] [PATCHv4 3/4] libavcodec: v4l2: add codec formats

[Jorge Ramirez-Ortiz]

In addition, enable the multi planar raw formats.

Reviewed-by: Jorge Ramirez 
Tested-by: Jorge Ramirez 
---
 libavcodec/v4l2_fmt.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 855cc64..3338984 100644
--- a/libavcodec/v4l2_fmt.c
+++ b/libavcodec/v4l2_fmt.c
@@ -58,7 +58,43 @@ const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = 
{
 { AV_PIX_FMT_BAYER_GRBG8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SGRBG8 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 { AV_PIX_FMT_BAYER_RGGB8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SRGGB8 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #endif
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0},
+#ifdef V4L2_PIX_FMT_NV12M
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_NV21M
+{ AV_PIX_FMT_NV21,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV21M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_YUV420M
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420M, 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_NV16M
+{ AV_PIX_FMT_NV16,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV16M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_DV
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_DVVIDEO,  V4L2_PIX_FMT_DV , 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_H263
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H263, V4L2_PIX_FMT_H263   , 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG1
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG1VIDEO, V4L2_PIX_FMT_MPEG1, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG2
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG2VIDEO, V4L2_PIX_FMT_MPEG2, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VC1_ANNEX_G
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VC1,  V4L2_PIX_FMT_VC1_ANNEX_G, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VP8
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VP8,  V4L2_PIX_FMT_VP8, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_HEVC
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_HEVC, V4L2_PIX_FMT_HEVC, 
FF_V4L_PACK_AVPACKET},
+#endif
+#ifdef V4L2_PIX_FMT_VP9
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VP9,  V4L2_PIX_FMT_VP9, 
FF_V4L_PACK_AVPACKET },
+#endif
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0,  , 0
},
 };
 
 uint32_t avpriv_v4l_fmt_ff2v4l(enum AVPixelFormat pix_fmt, enum AVCodecID 
codec_id, int pack_flags)
-- 
2.7.4

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

[FFmpeg-devel] [PATCHv4 2/4] libavcodec: v4l2: add pack_flags to the conversion tables

[Jorge Ramirez-Ortiz]

From: Alexis Ballier 

Extend the mapping function to use the v4l2 conversion tables.

Reviewed-by: Jorge Ramirez 
Tested-by: Jorge Ramirez 
---
 libavcodec/v4l2_fmt.c | 63 ++-
 libavcodec/v4l2_fmt.h | 17 +-
 libavdevice/v4l2.c|  2 +-
 libavdevice/v4l2enc.c |  2 +-
 4 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 322f595..855cc64 100644
--- a/libavcodec/v4l2_fmt.c
+++ b/libavcodec/v4l2_fmt.c
@@ -19,49 +19,49 @@
 #include "v4l2_fmt.h"
 
 const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
-//ff_fmt  codec_id  v4l2_fmt
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
-{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
-{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
-{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
-{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
-{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
-{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
-{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
-{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
-{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
-{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
-{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
-{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },
-{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+/* ff_fmt  codec_id  v4l2_fmt  
pack_flags */
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P, 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P, 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #ifdef V4L2_PIX_FMT_Y16
-{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #endif
-{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12},
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG   },
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG},
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12   , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG  , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG   , 
FF_V4L_PACK_AVPACKET },
 #ifdef V4L2_PIX_FMT_H264
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264   , 
FF_V4L_PACK_AVPACKET 

[FFmpeg-devel] [PATCHv4 1/4] Move lavd/v4l2-common.* to lavc

[Jorge Ramirez-Ortiz]

From: Alexis Ballier 

In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.

v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)

Signed-off-by: Alexis Ballier 
Reviewed-by: Jorge Ramirez-Ortiz 
---
 configure |   6 ++-
 libavcodec/Makefile   |   1 +
 libavcodec/v4l2_fmt.c | 105 ++
 libavcodec/v4l2_fmt.h |  57 +
 libavdevice/Makefile  |   6 +--
 libavdevice/v4l2-common.c | 105 --
 libavdevice/v4l2-common.h |  61 ---
 libavdevice/v4l2.c|  40 --
 libavdevice/v4l2enc.c |  12 +-
 9 files changed, 206 insertions(+), 187 deletions(-)
 create mode 100644 libavcodec/v4l2_fmt.c
 create mode 100644 libavcodec/v4l2_fmt.h
 delete mode 100644 libavdevice/v4l2-common.c
 delete mode 100644 libavdevice/v4l2-common.h

diff --git a/configure b/configure
index 66c7b94..ed94de0 100755
--- a/configure
+++ b/configure
@@ -1671,6 +1671,7 @@ SUBSYSTEM_LIST="
 pixelutils
 network
 rdft
+v4l2
 "
 
 # COMPONENT_LIST needs to come last to ensure correct dependency checking
@@ -2268,6 +2269,7 @@ map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
 
 loongson2_deps="mips"
 loongson3_deps="mips"
+v4l2_deps_any="linux_videodev2_h sys_videoio_h"
 mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
@@ -3041,8 +3043,8 @@ sdl2_outdev_deps="sdl2"
 sndio_indev_deps="sndio"
 sndio_outdev_deps="sndio"
 v4l_indev_deps="linux_videodev_h"
-v4l2_indev_deps_any="linux_videodev2_h sys_videoio_h"
-v4l2_outdev_deps_any="linux_videodev2_h sys_videoio_h"
+v4l2_indev_select="v4l2"
+v4l2_outdev_select="v4l2"
 vfwcap_indev_deps="vfw32 vfwcap_defines"
 xcbgrab_indev_deps="libxcb"
 xv_outdev_deps="X11_extensions_Xvlib_h XvGetPortAttribute"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b0c39ac..6be1b4b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -101,6 +101,7 @@ OBJS-$(CONFIG_LZF) += lzf.o
 OBJS-$(CONFIG_MDCT)+= mdct_fixed.o mdct_float.o 
mdct_fixed_32.o
 OBJS-$(CONFIG_ME_CMP)  += me_cmp.o
 OBJS-$(CONFIG_MEDIACODEC)  += mediacodecdec_common.o 
mediacodec_surface.o mediacodec_wrapper.o mediacodec_sw_buffer.o
+OBJS-$(CONFIG_V4L2)+= v4l2_fmt.o
 OBJS-$(CONFIG_MPEG_ER) += mpeg_er.o
 OBJS-$(CONFIG_MPEGAUDIO)   += mpegaudio.o
 OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o\
diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
new file mode 100644
index 000..322f595
--- /dev/null
+++ b/libavcodec/v4l2_fmt.c
@@ -0,0 +1,105 @@
+/*
+ * 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 "v4l2_fmt.h"
+
+const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
+//ff_fmt  codec_id  v4l2_fmt
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
+{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
+{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },

[FFmpeg-devel] V4L2 M2M version 4 of the patchset

[Jorge Ramirez-Ortiz]

This patchset contains quite a bit of code reorganization with respect
to v3. In it, I removed plenty of sedimented code and improved the
semantics by adding some abstractions.

I have also addressed most of the concerns raised by Mark Thompson
during the v3 revision (I'll continue to scan my emails in case I have
missed something)

There are still two major issues that need work:

 - encoder: set the extra data.
[fyi, as it is in this patchset,  I still can use mplay to
reproduce all the tested encoded videos (h263, h264 and mpeg4]

- decoder: changing resolution mid-stream.


looking forward to more comments
thanks


[PATCHv4 1/4] Move lavd/v4l2-common.* to lavc
[PATCHv4 2/4] libavcodec: v4l2: add pack_flags to the conversion tables
[PATCHv4 3/4] libavcodec: v4l2: add codec formats
[PATCHv4 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:52 PM, Vittorio Giovara
 wrote:
>> Following their logic, what if I can't deal with HLG yet, and I want
>> the original transfer?
>> Maybe it should be exported somehow, or have an option to not use the
>> alternate one, or something?
>>
>> One of the key points of HLG is compatibility with non-HDR systems, so
>> if the bitstream already offers this choice, maybe so should we,
>> without having to "guess" if its bt709 or bt2020 or...?
>
> You don't have to guess anything with HGL, the backward compatible
> slope supports both.
> I believe this system was designed for decoders that discard unknown
> or unsupported frame properties: such a decoder will read bt709
> instead of "unknown" so it be able to render the SDR version
> correctly, rather than let the decoder choose the transfer in an
> uncontrolled manner. An updated decoder can read this SEI and apply
> the proper transfer: if the decoder supports HDR, then it will use the
> full HLG, otherwise it will use the compatible slope, which matches
> the bt709 one (or bt2020).
> I don't think there is a need for extra options, because the
> libavcodec decoder can detect and support correctly both transfers.
> It's the encoder that needs to be updated for the case that you
> mention, but I haven't found encoders interacting with color
> properties in libavcodec.

The decoder doesn't need to support anything about the transfer. But
anything afterwards might.

If I want to render this video on screen, say a SDR screen, or my
player is just not HDR capable (yet), what transfer do I use? The
value avcodec gives me has not much meaning in that case (because I
can't deal with HLG yet), and the original "legacy" value meant to be
used in these cases was overriden and lost.

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

Re: [FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Vittorio Giovara]

> Following their logic, what if I can't deal with HLG yet, and I want
> the original transfer?
> Maybe it should be exported somehow, or have an option to not use the
> alternate one, or something?
>
> One of the key points of HLG is compatibility with non-HDR systems, so
> if the bitstream already offers this choice, maybe so should we,
> without having to "guess" if its bt709 or bt2020 or...?

You don't have to guess anything with HGL, the backward compatible
slope supports both.
I believe this system was designed for decoders that discard unknown
or unsupported frame properties: such a decoder will read bt709
instead of "unknown" so it be able to render the SDR version
correctly, rather than let the decoder choose the transfer in an
uncontrolled manner. An updated decoder can read this SEI and apply
the proper transfer: if the decoder supports HDR, then it will use the
full HLG, otherwise it will use the compatible slope, which matches
the bt709 one (or bt2020).
I don't think there is a need for extra options, because the
libavcodec decoder can detect and support correctly both transfers.
It's the encoder that needs to be updated for the case that you
mention, but I haven't found encoders interacting with color
properties in libavcodec.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v12] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

Dear Ali,

> Is the Turing Codec interface patch going to be pushed after the fix of flag 
> problem ?

The problem with the static flag is already fixed in the current version of the 
patch (v12). If you want to test it, you can manually copy the patch and apply 
it on top of the latest ffmpeg HEAD.

Thanks,
Saverio

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

Re: [FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:36 PM, Vittorio Giovara
 wrote:
> The use of this SEI is for backward compatibility in HLG HDR systems:
> older devices that cannot interpret the "arib-std-b67" transfer will
> get the compatible transfer (usually bt709 or bt2020) from the VUI,
> while newer devices that can interpret HDR will read the SEI and use
> its value instead.
>

Following their logic, what if I can't deal with HLG yet, and I want
the original transfer?
Maybe it should be exported somehow, or have an option to not use the
alternate one, or something?

One of the key points of HLG is compatibility with non-HDR systems, so
if the bitstream already offers this choice, maybe so should we,
without having to "guess" if its bt709 or bt2020 or...?

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

Re: [FFmpeg-devel] [PATCH] pixfmt: Support chroma-derived and icpct color matrices

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:14 PM, Vittorio Giovara
 wrote:
> Signed-off-by: Vittorio Giovara 
> ---
> Missing version bump.
> Vittorio
>
>  libavutil/pixdesc.c | 4 
>  libavutil/pixfmt.h  | 3 +++
>  2 files changed, 7 insertions(+)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 7fa6dd7c0b..a72ef3faf0 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -1806,6 +1806,10 @@ static const char * const color_space_names[] = {
>  [AVCOL_SPC_BT2020_NCL] = "bt2020nc",
>  [AVCOL_SPC_BT2020_CL] = "bt2020c",
>  [AVCOL_SPC_SMPTE2085] = "smpte2085",
> +[AVCOL_SPC_CHROMA_DERIVED_NCL] = "chroma-derived-nc",
> +[AVCOL_SPC_CHROMA_DERIVED_CL] = "chroma-derived-c",
> +[AVCOL_SPC_ICPCT] = "icpct",
> +
>  };
>
>  static const char * const chroma_location_names[] = {
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 2ba7ad1c88..93fd95da58 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -384,6 +384,9 @@ enum AVColorSpace {
>  AVCOL_SPC_BT2020_NCL  = 9,  ///< ITU-R BT2020 non-constant luminance 
> system
>  AVCOL_SPC_BT2020_CL   = 10, ///< ITU-R BT2020 constant luminance system
>  AVCOL_SPC_SMPTE2085   = 11, ///< SMPTE 2085, Y'D'zD'x
> +AVCOL_SPC_CHROMA_DERIVED_NCL = 12, ///< Chromaticity-derived 
> non-constant luminance system
> +AVCOL_SPC_CHROMA_DERIVED_CL = 13, ///< Chromaticity-derived constant 
> luminance system
> +AVCOL_SPC_ICPCT   = 14, ///< ITU-R BT.2100-0 ICTCP
>  AVCOL_SPC_NB,   ///< Not part of ABI
>  };
>

The spelling of ICtCp is not consistent (differs between comment and
symbol). From what I can see, ICtCp should be the correct order
according to the standards, and not ICpCt, so please use that
consistently. :)

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

[FFmpeg-devel] [PATCH] pixfmt: Support chroma-derived and ictcp color matrices

[Vittorio Giovara]

Signed-off-by: Vittorio Giovara 
---
Now without the typo in the name.
Vittorio

 libavutil/pixdesc.c | 4 
 libavutil/pixfmt.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 7fa6dd7c0b..f1e35f2254 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1806,6 +1806,10 @@ static const char * const color_space_names[] = {
 [AVCOL_SPC_BT2020_NCL] = "bt2020nc",
 [AVCOL_SPC_BT2020_CL] = "bt2020c",
 [AVCOL_SPC_SMPTE2085] = "smpte2085",
+[AVCOL_SPC_CHROMA_DERIVED_NCL] = "chroma-derived-nc",
+[AVCOL_SPC_CHROMA_DERIVED_CL] = "chroma-derived-c",
+[AVCOL_SPC_ICTCP] = "ictcp",
+
 };
 
 static const char * const chroma_location_names[] = {
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 2ba7ad1c88..2823a7ea36 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -384,6 +384,9 @@ enum AVColorSpace {
 AVCOL_SPC_BT2020_NCL  = 9,  ///< ITU-R BT2020 non-constant luminance system
 AVCOL_SPC_BT2020_CL   = 10, ///< ITU-R BT2020 constant luminance system
 AVCOL_SPC_SMPTE2085   = 11, ///< SMPTE 2085, Y'D'zD'x
+AVCOL_SPC_CHROMA_DERIVED_NCL = 12, ///< Chromaticity-derived non-constant 
luminance system
+AVCOL_SPC_CHROMA_DERIVED_CL = 13, ///< Chromaticity-derived constant 
luminance system
+AVCOL_SPC_ICTCP   = 14, ///< ITU-R BT.2100-0 ICTCP
 AVCOL_SPC_NB,   ///< Not part of ABI
 };
 
-- 
2.13.2

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

[FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Vittorio Giovara]

The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.

Signed-off-by: Vittorio Giovara 
---
 libavcodec/h264_sei.c   | 11 +++
 libavcodec/h264_sei.h   |  9 -
 libavcodec/h264_slice.c |  6 ++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index a7e627eba3..889bea2ee0 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -382,6 +382,14 @@ static int decode_green_metadata(H264SEIGreenMetaData *h, 
GetBitContext *gb)
 return 0;
 }
 
+static int decode_alternative_transfer(H264SEIAlternativeTransfer *h,
+   GetBitContext *gb)
+{
+h->present = 1;
+h->preferred_transfer_characteristics = get_bits(gb, 8);
+return 0;
+}
+
 int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
const H264ParamSets *ps, void *logctx)
 {
@@ -437,6 +445,9 @@ int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
 case SEI_TYPE_GREEN_METADATA:
 ret = decode_green_metadata(>green_metadata, gb);
 break;
+case SEI_TYPE_ALTERNATIVE_TRANSFER:
+ret = decode_alternative_transfer(>alternative_transfer, gb);
+break;
 default:
 av_log(logctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
 }
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index da3b391860..5f5d895e89 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -32,7 +32,8 @@ typedef enum {
 SEI_TYPE_RECOVERY_POINT = 6,   ///< recovery point (frame # to 
decoder sync)
 SEI_TYPE_FRAME_PACKING  = 45,  ///< frame packing arrangement
 SEI_TYPE_DISPLAY_ORIENTATION= 47,  ///< display orientation
-SEI_TYPE_GREEN_METADATA = 56   ///< GreenMPEG information
+SEI_TYPE_GREEN_METADATA = 56,  ///< GreenMPEG information
+SEI_TYPE_ALTERNATIVE_TRANSFER   = 147, ///< alternative transfer
 } SEI_Type;
 
 /**
@@ -144,6 +145,11 @@ typedef struct H264SEIGreenMetaData {
 uint16_t xsd_metric_value;
 } H264SEIGreenMetaData;
 
+typedef struct H264SEIAlternativeTransfer {
+int present;
+int preferred_transfer_characteristics;
+} H264SEIAlternativeTransfer;
+
 typedef struct H264SEIContext {
 H264SEIPictureTiming picture_timing;
 H264SEIAFD afd;
@@ -154,6 +160,7 @@ typedef struct H264SEIContext {
 H264SEIFramePacking frame_packing;
 H264SEIDisplayOrientation display_orientation;
 H264SEIGreenMetaData green_metadata;
+H264SEIAlternativeTransfer alternative_transfer;
 } H264SEIContext;
 
 struct H264ParamSets;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 4e7eba4adb..ebff7b33e3 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,6 +1287,12 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+if (h->sei.alternative_transfer.present &&
+
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
 &&
+h->sei.alternative_transfer.preferred_transfer_characteristics != 
AVCOL_TRC_UNSPECIFIED) {
+h->avctx->color_trc = cur->f->color_trc = 
h->sei.alternative_transfer.preferred_transfer_characteristics;
+}
+
 return 0;
 }
 
-- 
2.13.2

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

[FFmpeg-devel] [PATCH] pixfmt: Support chroma-derived and icpct color matrices

[Vittorio Giovara]

Signed-off-by: Vittorio Giovara 
---
Missing version bump.
Vittorio

 libavutil/pixdesc.c | 4 
 libavutil/pixfmt.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 7fa6dd7c0b..a72ef3faf0 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1806,6 +1806,10 @@ static const char * const color_space_names[] = {
 [AVCOL_SPC_BT2020_NCL] = "bt2020nc",
 [AVCOL_SPC_BT2020_CL] = "bt2020c",
 [AVCOL_SPC_SMPTE2085] = "smpte2085",
+[AVCOL_SPC_CHROMA_DERIVED_NCL] = "chroma-derived-nc",
+[AVCOL_SPC_CHROMA_DERIVED_CL] = "chroma-derived-c",
+[AVCOL_SPC_ICPCT] = "icpct",
+
 };
 
 static const char * const chroma_location_names[] = {
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 2ba7ad1c88..93fd95da58 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -384,6 +384,9 @@ enum AVColorSpace {
 AVCOL_SPC_BT2020_NCL  = 9,  ///< ITU-R BT2020 non-constant luminance system
 AVCOL_SPC_BT2020_CL   = 10, ///< ITU-R BT2020 constant luminance system
 AVCOL_SPC_SMPTE2085   = 11, ///< SMPTE 2085, Y'D'zD'x
+AVCOL_SPC_CHROMA_DERIVED_NCL = 12, ///< Chromaticity-derived non-constant 
luminance system
+AVCOL_SPC_CHROMA_DERIVED_CL = 13, ///< Chromaticity-derived constant 
luminance system
+AVCOL_SPC_ICPCT   = 14, ///< ITU-R BT.2100-0 ICTCP
 AVCOL_SPC_NB,   ///< Not part of ABI
 };
 
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

Le primidi 21 thermidor, an CCXXV, Michael Niedermayer a écrit :
> Iam a bit puzzled that you really seem not to see what damage this
> would do.

I am a lot puzzled that you really imagine it would do such damage.

> All scripts, all applications using libavfilter must be changed to
> use the named arguments if the shorthand is not stable.
> all examples will need to be changed too or the examples would show
> syntax that is non stable.
> Examples do not target scripts or end users specifically so we may
> end up with duplication and extra complexity.
> 
> If you dislike C language lawyerng over undefined behavior, this is
> exactly the same but worse.
> If we say it may be unstable even if its very very unlikely everyone
> who takes stability serious will change their code, tutorials, docs
> and examples.
> This will also add alot of confusion to teh end user as suddenly
> the consistent use of shorthand is replaced by some documents and
> tutorials using the shorthand in accordance of it being ok-ish and
> some take the strict approuch and remove all shorthand use.
> Extra explanations to clarify "why" added, cause the user to waste more
> time to learn about "why"

This is all in a day's work for anybody upgrading any kind of program.
People switching to later versions of Firefox or LibreOffice have a
harder time than that.

> The whole would add a reason to avoid libavfilter and use an
> alternative

Nonsense, the syntax with named options is stable.

Your ability to imagine what would annoy users and cause damage is
obviously not much better than mine, which is worthless. It is not
surprising, neither of us is a normal user. Then let us stop speculating
and let us listen to what actual users have said on the matter about the
issue on this very mailing-list, please.

Regards,

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

Re: [FFmpeg-devel] [PATCH] zscale: Fix memory leak

[Michael Niedermayer]

On Sun, Aug 06, 2017 at 12:58:45AM -0400, Jkldjfset wrote:
> Empty Message

>  vf_zscale.c |1 +
>  1 file changed, 1 insertion(+)
> 5a8bdac178519a9ff7d65d5e5b75aa13e7690527  
> 0001-avfilter-zscale-fix-memory-leak.patch
> From 89e2c7e90f17ca2c2a4565358a48449da1a8d0ff Mon Sep 17 00:00:00 2001

> From: sdfokjpgd 

This is not a valid email address nor name.
If you wish to stay anoymous please use a pseudonym and
mail address that could be used to contact you

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

Hi

On Tue, Aug 08, 2017 at 11:20:31AM +0200, Nicolas George wrote:
> Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit :
> > That is why I believe a breaking change such as the overlay filter option
> > order change should be mentioned in the Changelog.
> 
> Yes, you are completely right.
> 
> Also, let me clarify something: pushing this documentation change does
> not mean I intend to break the order of options at a whim. Not at all.
> In practice, nothing will change, almost. But it means that if there is
> a strong need to change the order, we can consider it comfortably, and
> without wasting valuable developer time with compatibility workarounds.
> 

> Regarding the exact rule: we could document that there are some options
> we do not intend to touch (essential options), but what would be the
> point, really?

Iam a bit puzzled that you really seem not to see what damage this
would do.

All scripts, all applications using libavfilter must be changed to
use the named arguments if the shorthand is not stable.
all examples will need to be changed too or the examples would show
syntax that is non stable.
Examples do not target scripts or end users specifically so we may
end up with duplication and extra complexity.

If you dislike C language lawyerng over undefined behavior, this is
exactly the same but worse.
If we say it may be unstable even if its very very unlikely everyone
who takes stability serious will change their code, tutorials, docs
and examples.
This will also add alot of confusion to teh end user as suddenly
the consistent use of shorthand is replaced by some documents and
tutorials using the shorthand in accordance of it being ok-ish and
some take the strict approuch and remove all shorthand use.
Extra explanations to clarify "why" added, cause the user to waste more
time to learn about "why"

The whole would add a reason to avoid libavfilter and use an
alternative
If i "as a user" have the choice between 2 libs, one with a long term
stable interface and gurantee by its developers that it will stay stable
and a lib that in practice broke its interface and added a declaration
that parts which where stable before are not anymore and unspecified
future changes are possible". I would favor he lib with stable interface.
And loss of users also always means a loss of potential developers,
as users of a lib is a source of developers of that lib.
Loss of some users is bad on its own of course ...

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] add gray9 support

[Michael Niedermayer]

On Sat, Aug 05, 2017 at 03:23:54PM +0200, Paul B Mahol wrote:
> Hi,
> 
> patches attached.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH v12] - Added Turing codec interface for ffmpeg

[Ali KIZIL]

2017-07-17 14:19 GMT+03:00 Saverio Blasi :

> >> Thanks a lot, this makes sense. I thought that flag was compulsory and
> therefore we only included linking against libraries in "Libs.private" in
> the pc file. I have just pushed a fix to the Turing repo to include that in
> the Libs as well.
> >>
> >> I have tested this and it seems to work fine in my machine and in the
> Docker with Ubuntu and debian with and without the flag now. No changes are
> needed to the actual patch, it should work as long as you update Turing to
> the latest commit.
>
>
> So we have now further tested this extensively in different machines. I
> believe the problems with linking against dynamic libraries are solved in v
> 12 of the patch. In all our tests the patch works correctly with either
> settings of the pkg-config-flags. Could you please help us and confirm that
> this is the case? I think this was the only blocker with this latest
> version of the patch?
>
> Thanks,
> 
> Saverio Blasi
> Senior Research Engineer
> BBC Research & Development
> Centre House|56 Wood Lane|London|W12 7SB
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Is the Turing Codec interface patch going to be pushed after the fix of
flag problem ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 08/08/17 09:33, Jorge Ramirez wrote:
> On 08/08/2017 10:23 AM, Martin Storsjö wrote:
>
 This doesn't set extradata - you need to extract the codec global headers 
>>> (such as H.264 SPS and PPS) at init time to be able to write correct files 
>>> for some codecs (such as H.264) with muxers requiring global headers (such 
>>> as MP4).  It kindof works without it, but the files created will not 
>>> conform and will not be usable on some players.

>>> ah that might explain some things (when I play back the encoded video the 
>>> quality is pretty lousy)
>>> is there already some code I can use as a reference? I might be out of my 
>>> depth here so any help will be more than welcome
>>
>> This is exactly the thing I was trying to tell you about, off list, before.
> 
> Hi Martin,
> 
> yes sorry I was just thinking about that. I was going to follow up but little 
> details here on this patchset keep on piling up.
> 
> btw -just for info- the encoding issues I was seeing were related to the time 
> stamps not being properly passed to the encoder...still trying to figure out 
> that as well but at least I now get a proper encoded/decoded frame (even 
> though just one, that keeps on being played when I reproduce the encoded 
> video)
> 
> the encoder however does not complain during the process so I assume the 
> other frames are also there
> 
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.63e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.61e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.6e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.58e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.56e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.55e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.53e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.52e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.5e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.48e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.47e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.45e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.44e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.42e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.41e-07x
> [rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
> 1920trate=4923.1kbits/s speed=3.39e-07x
> [out_0_0 @ 0xe5e64be0] EOF on sink link 
> out_0_0:default.bitrate=4923.1kbits/s speed=3.36e-07x
> 
> No more output streams to write to, finishing.
> frame=  232 fps=1.0 q=-0.0 Lsize=  42kB time=00:00:00.00 
> bitrate=736989.3kbits/s speed=2.01e-06x
> video:41kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
> overhead: 1.783316%
> Input file #0 (/home/linaro/Videos/raw/freeway.yuv):
>   Input stream #0:0 (video): 232 packets read (320716800 bytes); 232 frames 
> decoded;
>   Total: 232 packets (320716800 bytes) demuxed
> Output file #0 (out/out.h264.mp4):
>   Output stream #0:0 (video): 232 frames encoded; 6 packets muxed (42449 
> bytes);
>   Total: 6 packets (42449 bytes) muxed
> 232 frames successfully decoded, 0 decoding errors
> 
>>
>> In the OMX driver used on android, this is requested on startup, via an 
>> ioctl with the following private ioctl value:
>> V4L2_CID_MPEG_VIDC_VIDEO_REQUEST_SEQ_HEADER
>>
>> See this code here:
>> https://android.googlesource.com/platform/hardware/qcom/media/+/63abe022/msm8996/mm-video-v4l2/vidc/venc/src/video_encoder_device_v4l2.cpp#2991
>>
>> This is a qcom specific, private ioctl. In the android kernel for qualcomm, 
>> this is handled correctly here:
>>
>> https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_venc.c#2987
>> https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_vidc_common.c#3767
>>
>> In the dragonboard kernel snapshot I had been testing, that I referred to 
>> you before, there are incomplete stubs of handling of this. In the 
>> debian-qcom-dragonboard410c-16.04 tag in the linaro kernel tree:
>>
>> http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/drivers/media/platform/msm/vidc/msm_venc-ctrls.c?h=debian-qcom-dragonboard410c-16.04=8205f603ceeb02d08a720676d9075c9e75e47b0f#n2116
>> This increments seq_hdr_reqs, just like in the android 

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

[Maksym Veremeyenko]

On 05.08.2017 22:46, Marton Balint wrote:

On Thu, 3 Aug 2017, Maksym Veremeyenko wrote:

[...]

About the warnings for the bottom field order and the negative linesize,
I still think it is better to reject them (return an error), this way
the user will be forced to fix the input, by changing the field order
(e.g by using the fieldorder filter before passing video) or getting rid
of the negative linesize.

done


To support negative linesizes, there is one more thing you might do: If the
source frame has a negative linesize, then instead of cloning, allocate
a new
avframe with av_frame_alloc, set widht/height/format, use
av_frame_get_buffer
to allocate a buffer, then use av_frame_copy to copy the data from the
source
frame to the newly allocated one which should have a positive linesize.
A bit too much work for a rarely used feature, but if you are
interested, it is
doable. You can generate a negative linesize source with the vflip filter.


i though it really transparent...


I did some further tests, and I still cannot see my own ffmpeg generated
source, I am running this command:

./ffmpeg -nostdin -f libndi_newtek -wait_sources 10 -find_sources 1 -i
none & ./ffmpeg -f lavfi -i mptestsrc,format=pix_fmts=uyvy422 -f
libndi_newtek dummy

Even after 10 seconds, the first process finds 0 sources, the second
process is
running happily. Does this work for you?


Check if *avahi* daemon is running and firewall turned off.

[root@dev-5 ffmpeg.git-head]# ffmpeg -v debug -nostdin -f libndi_newtek 
-wait_sources 10 -find_sources 1 -i none & ffmpeg -f lavfi -i 
mptestsrc,format=pix_fmts=uyvy422 -f libndi_newtek dummy

/.../
[libndi_newtek @ 0x211bdc0] Waiting for sources 1 miliseconds
Output #0, libndi_newtek, to 'dummy':
  Metadata:
encoder : Lavf57.76.100
Stream #0:0: Video: wrapped_avframe, uyvy422, 512x512 [SAR 1:1 DAR 
1:1], q=2-31, 200 kb/s, 25 fps, 1k tbn, 25 tbc

Metadata:
  encoder : Lavc57.102.100 wrapped_avframe
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 1 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 1 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 1 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1peed=40.1x
[libndi_newtek @ 0x211bdc0] Waiting for sources 1 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 
0speed=41.4x

[libndi_newtek @ 0x211bdc0] Found 4 NDI sources:
[libndi_newtek @ 0x211bdc0] 'DEV-5.INTERNAL.M1STEREO.TV (dummy)' 
'10.1.5.57:5961'

[libndi_newtek @ 0x211bdc0] 'H264-LIVE (CH1)'   '10.1.5.99:5961'
[libndi_newtek @ 0x211bdc0] 'H264-LIVE (CH2)'   '10.1.5.99:5962'
[libndi_newtek @ 0x211bdc0] 'H264-LIVE (CH3)'   '10.1.5.99:5963'
none: Immediate exit requested
frame=24732 fps=1036 q=-0.0 Lsize=N/A time=00:16:29.24 bitrate=N/A 
speed=41.4x

/.../

i also found that there are some problem with older version of dbus that 
supplied with CentOs7 - it is not thread-safe of NDI functioning.



+@subsection Examples
+
+@itemize
+
+@item
+Play video clip:
+@example
+ffmpeg -i
"udp://@239.1.1.1:10480?fifo_size=100_nonfatal=1" -vf
"scale=720:576,fps=fps=25,setdar=dar=16/9,format=pix_fmts=uyvy422" -f
libndi_newtek NEW_NDI1


@ needs escaping into @@

done


+while (1)
+{
+int f, t = ctx->wait_sources / 1000;
+av_log(avctx, AV_LOG_DEBUG, "Waiting for sources %d
miliseconds\n", t);
+f = NDIlib_find_wait_for_sources(ctx->ndi_find, t);
+av_log(avctx, AV_LOG_DEBUG, "NDIlib_find_wait_for_sources
returns %d\n", f);
+if (!f)
+break;
+};


You should not loop indefinitely, give up after a few tries.


from my researches, each loop iteration adds new source, so if you have 
40 sources, then you'll have 40+ iterations. moreover, if no new sources 
found, NDIlib_find_wait_for_sources will block only for specified period 
(default value is 0.5 second). so, there are no default way to make this 
loop indefinite.



+static int ndi_write_video_packet(AVFormatContext *avctx, AVStream
*st, AVPacket *pkt)
+{
+struct NDIContext *ctx = avctx->priv_data;
+AVFrame *avframe, *tmp = (AVFrame *)pkt->data;
+
+if (tmp->format != AV_PIX_FMT_UYVY422 ||
+tmp->width  != ctx->video->xres ||
+tmp->height != ctx->video->yres) {
+av_log(avctx, AV_LOG_ERROR, "Got a frame with invalid pixel
format or dimension.\n");
+av_log(avctx, AV_LOG_ERROR, "tmp->width=%d, tmp->height=%d,
ctx->video->xres=%d, ctx->video->yres=%d\n", tmp->width, tmp->height,
ctx->video->xres, ctx->video->yres);
+return AVERROR(EINVAL);
+}
+avframe = av_frame_clone(tmp);
+if (!avframe) {
+av_log(avctx, AV_LOG_ERROR, "Could not clone video frame.\n");


For ENOMEM 

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

[Maksym Veremeyenko]

On 03.08.2017 10:41, Steinar H. Gunderson wrote:

On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:

You should reject bottom field first formats, as NDI explicitly
disallows them.

even if it disallowed, why to drop? may be warning message would be enough?


FWIW, the documentation may say that formats are always TFF, but on the wire,
it seems the bottom field actually goes first.

(I guess this is a bug that isn't noticed because there's actually no way
from the API to get at the individual fields)


i dropped bottom field order support.


+NDI is very picky about the formats it supports. Pixel format is always
+uyvy422.


Or bgra (internally, uyvya4224, I suppose).

i extended supported pixel format, except uyvya4224 that is not 
supported by ffmpeg



+recv_create_desc.allow_video_fields = ctx->allow_video_fields;


I'm not convinced you ever want to set this to false, as what's happening if
you do is simply that the SDK applies a vertical blur to incoming interlaced
frames. FFmpeg has much better deinterlacers if that's what you want.
i dont know which method used by SDK to deinterlace, but if it provided, 
then it could be used for some reason.


--
Maksym Veremeyenko

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit :
> That is why I believe a breaking change such as the overlay filter option
> order change should be mentioned in the Changelog.

Yes, you are completely right.

Also, let me clarify something: pushing this documentation change does
not mean I intend to break the order of options at a whim. Not at all.
In practice, nothing will change, almost. But it means that if there is
a strong need to change the order, we can consider it comfortably, and
without wasting valuable developer time with compatibility workarounds.

Regarding the exact rule: we could document that there are some options
we do not intend to touch (essential options), but what would be the
point, really? Do we require users to learn the list by rote? Are they
supposed to  look in the documentation each time? The rule "use named
options, it will keep working" is simple, easy to remember, and the
extra requirement (write "x=", "y=", essential options are usually
short) is minimal and small compared to the task of learning which
option would be stable and which would not.

With that said, what about this change?

Regards,

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

[FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding

[maxime taisant]

From: Maxime Taisant 

Hi,

Here is some SSE optimisations for the dwt function used to decode JPEG2000.
I tested this code by using the time command while reading a JPEG2000 encoded 
video with ffmpeg and, on average, I observed a 4.05% general improvement, and 
a 12.67% improvement on the dwt decoding part alone.
In the nasm code, you can notice that the SR1DFLOAT macro appear twice. One 
version is called in the nasm code by the HORSD macro and the other is called 
in the C code of the dwt function, I couldn't figure out a way to make only one 
macro.
I also couldn't figure out a good way to optimize the VER_SD part, so that is 
why I left it unchanged, with just a SSE-optimized version of the SR_1D_FLOAT 
function.

Regards.

---
 libavcodec/jpeg2000dwt.c  |  21 +-
 libavcodec/jpeg2000dwt.h  |   6 +
 libavcodec/x86/jpeg2000dsp.asm| 794 ++
 libavcodec/x86/jpeg2000dsp_init.c |  55 +++
 4 files changed, 863 insertions(+), 13 deletions(-)

diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
index 55dd5e89b5..69c935980d 100644
--- a/libavcodec/jpeg2000dwt.c
+++ b/libavcodec/jpeg2000dwt.c
@@ -558,16 +558,19 @@ int ff_jpeg2000_dwt_init(DWTContext *s, int border[2][2],
 }
 switch (type) {
 case FF_DWT97:
+dwt_decode = dwt_decode97_float;
 s->f_linebuf = av_malloc_array((maxlen + 12), sizeof(*s->f_linebuf));
 if (!s->f_linebuf)
 return AVERROR(ENOMEM);
 break;
  case FF_DWT97_INT:
+dwt_decode = dwt_decode97_int;
 s->i_linebuf = av_malloc_array((maxlen + 12), sizeof(*s->i_linebuf));
 if (!s->i_linebuf)
 return AVERROR(ENOMEM);
 break;
 case FF_DWT53:
+dwt_decode = dwt_decode53;
 s->i_linebuf = av_malloc_array((maxlen +  6), sizeof(*s->i_linebuf));
 if (!s->i_linebuf)
 return AVERROR(ENOMEM);
@@ -575,6 +578,10 @@ int ff_jpeg2000_dwt_init(DWTContext *s, int border[2][2],
 default:
 return -1;
 }
+
+if (ARCH_X86)
+ff_jpeg2000dwt_init_x86(s, type);
+
 return 0;
 }
 
@@ -601,19 +608,7 @@ int ff_dwt_decode(DWTContext *s, void *t)
 if (s->ndeclevels == 0)
 return 0;
 
-switch (s->type) {
-case FF_DWT97:
-dwt_decode97_float(s, t);
-break;
-case FF_DWT97_INT:
-dwt_decode97_int(s, t);
-break;
-case FF_DWT53:
-dwt_decode53(s, t);
-break;
-default:
-return -1;
-}
+dwt_decode(s,t);
 return 0;
 }
 
diff --git a/libavcodec/jpeg2000dwt.h b/libavcodec/jpeg2000dwt.h
index 718d183ac1..8462ddf8cd 100644
--- a/libavcodec/jpeg2000dwt.h
+++ b/libavcodec/jpeg2000dwt.h
@@ -50,6 +50,8 @@ typedef struct DWTContext {
 float   *f_linebuf;  ///< float buffer used by transform
 } DWTContext;
 
+void (*dwt_decode)(DWTContext *s, void *t);
+
 /**
  * Initialize DWT.
  * @param s DWT context
@@ -65,4 +67,8 @@ int ff_dwt_decode(DWTContext *s, void *t);
 
 void ff_dwt_destroy(DWTContext *s);
 
+void dwt_decode97_float_sse(DWTContext *s, float *t);
+
+void ff_jpeg2000dwt_init_x86(DWTContext *s, int type);
+
 #endif /* AVCODEC_JPEG2000DWT_H */
diff --git a/libavcodec/x86/jpeg2000dsp.asm b/libavcodec/x86/jpeg2000dsp.asm
index 56b5fbd606..262704f288 100644
--- a/libavcodec/x86/jpeg2000dsp.asm
+++ b/libavcodec/x86/jpeg2000dsp.asm
@@ -2,6 +2,7 @@
 ;* SIMD-optimized JPEG2000 DSP functions
 ;* Copyright (c) 2014 Nicolas Bertrand
 ;* Copyright (c) 2015 James Almer
+;* Copyright (c) 2017 Maxime Taisant
 ;*
 ;* This file is part of FFmpeg.
 ;*
@@ -29,6 +30,16 @@ pf_ict1: times 8 dd 0.34413
 pf_ict2: times 8 dd 0.71414
 pf_ict3: times 8 dd 1.772
 
+F_LFTG_K: dd 1.230174104914001
+F_LFTG_X: dd 0.812893066115961
+
+F_LFTG_ALPHA: times 8 dd 1.586134342059924
+F_LFTG_BETA: times 8 dd 0.052980118572961
+F_LFTG_GAMMA: times 8 dd 0.882911075530934
+F_LFTG_DELTA: times 8 dd 0.443506852043971
+
+TWO: dd 2.0
+
 SECTION .text
 
 ;***
@@ -142,3 +153,786 @@ RCT_INT
 INIT_YMM avx2
 RCT_INT
 %endif
+
+;***
+; ff_sr_ld97_float_(float *line, int i0, int i1)
+;***
+%macro SR1D97FLOAT 1
+cglobal sr_1d97_float, 3, 5, %1, line, i0, i1, j0, j1
+mov j0q, i0q
+mov j1q, i1q
+add j0q, 1
+cmp j1q, j0q
+jg .extend
+sub j0q, 2
+jnz .else
+movss m0, [lineq+4]
+movss m1, [F_LFTG_K]
+movss m2, [TWO]
+divss m1, m2
+mulss m0, m1
+movss [lineq+4], m0
+jmp .end
+
+.else:
+movss m0, [lineq]
+movss m1, [F_LFTG_X]
+mulss m0, m1
+movss [lineq], m0
+jmp .end
+
+.extend:
+shl i0d, 2
+shl i1d, 2
+mov j0q, i0q
+mov j1q, i1q
+movups m0, [lineq+j0q+4]
+shufps m0, m0, 0x1B
+movups [lineq+j0q-16], m0

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add "cabac" option support

[Jun Zhao]

On 2017/8/8 15:49, Hendrik Leppkes wrote:
> On Tue, Aug 8, 2017 at 9:40 AM, Jun Zhao  wrote:
>>
> 
> Making the option compatible with what libx264 takes, for example,
> would probably be best.
> 
> ie. libx264 uses for CABAC:
> -coder cabac
> -coder ac
> 
> or for CAVLC:
> -coder cavlc
> -coder vlc
> 
> Check the options table in libx264.c how its done.
> 
> - Hendrik

Ok, will follow x264 style. :)

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/08/2017 10:23 AM, Martin Storsjö wrote:


This doesn't set extradata - you need to extract the codec global 
headers 
(such as H.264 SPS and PPS) at init time to be able to write correct 
files for some codecs (such as H.264) with muxers requiring global 
headers (such as MP4).  It kindof works without it, but the files 
created will not conform and will not be usable on some players.


ah that might explain some things (when I play back the encoded video 
the quality is pretty lousy)
is there already some code I can use as a reference? I might be out 
of my depth here so any help will be more than welcome


This is exactly the thing I was trying to tell you about, off list, 
before.


Hi Martin,

yes sorry I was just thinking about that. I was going to follow up but 
little details here on this patchset keep on piling up.


btw -just for info- the encoding issues I was seeing were related to the 
time stamps not being properly passed to the encoder...still trying to 
figure out that as well but at least I now get a proper encoded/decoded 
frame (even though just one, that keeps on being played when I reproduce 
the encoded video)


the encoder however does not complain during the process so I assume the 
other frames are also there


[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.63e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.61e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.6e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.58e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.56e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.55e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.53e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.52e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.5e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.48e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.47e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.45e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.44e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.42e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.41e-07x
[rawvideo @ 0xe5e600a0] PACKET SIZE: 1382400, STRIDE: 
1920trate=4923.1kbits/s speed=3.39e-07x
[out_0_0 @ 0xe5e64be0] EOF on sink link 
out_0_0:default.bitrate=4923.1kbits/s speed=3.36e-07x


No more output streams to write to, finishing.
frame=  232 fps=1.0 q=-0.0 Lsize=  42kB time=00:00:00.00 
bitrate=736989.3kbits/s speed=2.01e-06x
video:41kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 1.783316%

Input file #0 (/home/linaro/Videos/raw/freeway.yuv):
  Input stream #0:0 (video): 232 packets read (320716800 bytes); 232 
frames decoded;

  Total: 232 packets (320716800 bytes) demuxed
Output file #0 (out/out.h264.mp4):
  Output stream #0:0 (video): 232 frames encoded; 6 packets muxed 
(42449 bytes);

  Total: 6 packets (42449 bytes) muxed
232 frames successfully decoded, 0 decoding errors



In the OMX driver used on android, this is requested on startup, via 
an ioctl with the following private ioctl value:

V4L2_CID_MPEG_VIDC_VIDEO_REQUEST_SEQ_HEADER

See this code here:
https://android.googlesource.com/platform/hardware/qcom/media/+/63abe022/msm8996/mm-video-v4l2/vidc/venc/src/video_encoder_device_v4l2.cpp#2991 



This is a qcom specific, private ioctl. In the android kernel for 
qualcomm, this is handled correctly here:


https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_venc.c#2987 

https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_vidc_common.c#3767 



In the dragonboard kernel snapshot I had been testing, that I referred 
to you before, there are incomplete stubs of handling of this. In the 
debian-qcom-dragonboard410c-16.04 tag in the linaro kernel tree:


http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/drivers/media/platform/msm/vidc/msm_venc-ctrls.c?h=debian-qcom-dragonboard410c-16.04=8205f603ceeb02d08a720676d9075c9e75e47b0f#n2116 

This increments seq_hdr_reqs, just like in the android kernel tree 
(where this is working). However in this kernel tree, nothing actually 
ever reads the seq_hdr_reqs, so it's a non-functional stub.


ok. thanks for the info



Now in the kernel tree you referred me to, in the 
release/db820c/qcomlt-4.11 

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Martin Storsjö]

Hi Jorge,

On Mon, 7 Aug 2017, Jorge Ramirez wrote:


On 08/03/2017 01:53 AM, Mark Thompson wrote:

+default:
+return 0;
+}
+
+SET_V4L_EXT_CTRL(value, qmin, avctx->qmin, "minimum video quantizer 

scale");
+SET_V4L_EXT_CTRL(value, qmax, avctx->qmax, "maximum video quantizer 

scale");

+
+return 0;
+}
This doesn't set extradata - you need to extract the codec global headers 
(such as H.264 SPS and PPS) at init time to be able to write correct files 
for some codecs (such as H.264) with muxers requiring global headers (such as 
MP4).  It kindof works without it, but the files created will not conform and 
will not be usable on some players.


ah that might explain some things (when I play back the encoded video 
the quality is pretty lousy)
is there already some code I can use as a reference? I might be out of 
my depth here so any help will be more than welcome


This is exactly the thing I was trying to tell you about, off list, 
before.


In the OMX driver used on android, this is requested on startup, via an 
ioctl with the following private ioctl value:

V4L2_CID_MPEG_VIDC_VIDEO_REQUEST_SEQ_HEADER

See this code here:
https://android.googlesource.com/platform/hardware/qcom/media/+/63abe022/msm8996/mm-video-v4l2/vidc/venc/src/video_encoder_device_v4l2.cpp#2991

This is a qcom specific, private ioctl. In the android kernel for 
qualcomm, this is handled correctly here:


https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_venc.c#2987
https://android.googlesource.com/kernel/msm/+/android-7.1.2_r0.33/drivers/media/platform/msm/vidc/msm_vidc_common.c#3767

In the dragonboard kernel snapshot I had been testing, that I referred to 
you before, there are incomplete stubs of handling of this. In the 
debian-qcom-dragonboard410c-16.04 tag in the linaro kernel tree:


http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/drivers/media/platform/msm/vidc/msm_venc-ctrls.c?h=debian-qcom-dragonboard410c-16.04=8205f603ceeb02d08a720676d9075c9e75e47b0f#n2116
This increments seq_hdr_reqs, just like in the android kernel tree (where 
this is working). However in this kernel tree, nothing actually ever reads 
the seq_hdr_reqs, so it's a non-functional stub.


Now in the kernel tree you referred me to, in the 
release/db820c/qcomlt-4.11 branch, I don't see anything similar to 
V4L2_CID_MPEG_VIDC_VIDEO_REQUEST_SEQ_HEADER. I can't help you from there, 
you need to figure that out what alternative codepath there is, intended 
to replace it - if any. If there aren't any, you first need to fix the 
v4l2 driver before userspace apps can get what they need.


There is a clear need for this, as you witness in the android version of 
the kernel. It just seems to have been removed in the vanilla linux 
version of the driver.


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add "cabac" option support

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 9:40 AM, Jun Zhao  wrote:
>

Making the option compatible with what libx264 takes, for example,
would probably be best.

ie. libx264 uses for CABAC:
-coder cabac
-coder ac

or for CAVLC:
-coder cavlc
-coder vlc

Check the options table in libx264.c how its done.

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add "cabac" option support

[Jun Zhao]

From c95be027e1f109fbcec3102371a6cb0cbfc7e551 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 8 Aug 2017 03:33:53 -0400
Subject: [PATCH] lavc/vaapi_encode_h264: add "cabac" option support

0 means no-cabac, 1 means enable cabac when profile > baseline.
Default is enable cabac.

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

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f9fcd805a4..8107dc62a8 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -168,6 +168,7 @@ typedef struct VAAPIEncodeH264Options {
 int qp;
 int quality;
 int low_power;
+int cabac;
 } VAAPIEncodeH264Options;
 
 
@@ -783,6 +784,8 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 VAEncPictureParameterBufferH264   *vpic = ctx->codec_picture_params;
 VAAPIEncodeH264Context*priv = ctx->priv_data;
 VAAPIEncodeH264MiscSequenceParams *mseq = >misc_sequence_params;
+VAAPIEncodeH264Options *opt =
+(VAAPIEncodeH264Options*)ctx->codec_options_data;
 int i;
 
 {
@@ -927,8 +930,12 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 vpic->num_ref_idx_l0_active_minus1 = 0;
 vpic->num_ref_idx_l1_active_minus1 = 0;
 
-vpic->pic_fields.bits.entropy_coding_mode_flag =
-((avctx->profile & 0xff) != 66);
+if (opt->cabac) {
+vpic->pic_fields.bits.entropy_coding_mode_flag =
+((avctx->profile & 0xff) != 66);
+} else {
+vpic->pic_fields.bits.entropy_coding_mode_flag = 0;
+}
 vpic->pic_fields.bits.weighted_pred_flag = 0;
 vpic->pic_fields.bits.weighted_bipred_idc = 0;
 vpic->pic_fields.bits.transform_8x8_mode_flag =
@@ -1283,6 +1290,8 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "low_power", "Use low-power encoding mode (experimental: only supported "
   "on some platforms, does not support all features)",
   OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
+{ "cabac", "Use CABAC (Context-adaptive binary arithmetic coding) entropy 
coding.",
+  OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS },
 { NULL },
 };
 
-- 
2.11.0

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

[FFmpeg-devel] shyamal das invited you to check out Dropbox

[Dropbox]

Hi there,

shyamal das (shyamaldass...@gmail.com) thinks you should use Dropbox! It’s a 
free and easy way to access and share your docs, photos, and videos with 
colleagues and friends—even if they don’t have Dropbox accounts.

Accept invite[1]

Get started through this email, and you’ll get an extra 500 MB added to your 2 
GB of free space.

Happy Dropboxing!

[1]: https://www.dropbox.com/l/AABbF0jnKTf0VIGppuxUWaGslke1yeVUByI
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel