Re: [FFmpeg-devel] [PATCH 06/13] avformat/mxfenc: Add Sample width/height/x offset/y offset, Display x offset and F2 offset

[Tobias Rapp]

On 08.05.2018 12:40, Tomas Härdin wrote:

mån 2018-05-07 klockan 12:38 +0200 skrev Michael Niedermayer:

Signed-off-by: Michael Niedermayer 

+if (sc->interlaced) {
+//Display F2 Offset
+mxf_write_local_tag(pb, 4, 0x3217);
+avio_wb32(pb, -((st->codecpar->height - display_height)&1));


Negative values for DisplayF2Offset are not valid


Can't say anything about the formula but according to The MXF Book (ISBN 
978-0240806938, page 187) the DisplayF2Offset property is defined as 
Int32, not UInt32.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Jorge Ramirez-Ortiz]

On 05/09/2018 01:33 AM, Mark Thompson wrote:

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index ed5193ecc1..2b33badb08 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -23,12 +23,18 @@
  
  #include 

  #include 
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_drm.h"
  #include "libavutil/pixfmt.h"
  #include "libavutil/pixdesc.h"
  #include "libavutil/opt.h"
  #include "libavcodec/avcodec.h"
  #include "libavcodec/decode.h"
  
+#include "libavcodec/hwaccel.h"

+#include "libavcodec/internal.h"
+
  #include "v4l2_context.h"
  #include "v4l2_m2m.h"
  #include "v4l2_fmt.h"
@@ -183,6 +189,15 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
  capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
  capture->av_pix_fmt = avctx->pix_fmt;
  
+/* the client requests the codec to generate DRM frames:

+ *   - data[0] will therefore point to the returned AVDRMFrameDescriptor
+ *   check the ff_v4l2_buffer_to_avframe conversion function.
+ *   - the DRM frame format is passed in the DRM frame descriptor layer.
+ *   check the v4l2_get_drm_frame function.
+ */
+if (avctx->pix_fmt == AV_PIX_FMT_DRM_PRIME)
+s->output_drm = 1;
+
  ret = ff_v4l2_m2m_codec_init(avctx);
  if (ret) {
  av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");
@@ -202,6 +217,11 @@ static const AVOption options[] = {
  { NULL},
  };


As a follow up to your comment on pixel format negotiation 
(AvCodecContext.getformat), notice that this is a tentative request from 
the user to select a pixel format.
The actual pixel format negotiation - where the decoder will select the 
pixel format- will happen later during v4l2_try_start.


This change enables the v4l2m2m decoder to output either dmabuf 
descriptors to be consumed by a DRM or video frame formats to be 
consumed by SDL (for instance).
As an example, these changes have been tested with ffplay (SDL based 
display) and a simple DRM application [1]


Lukas tested with other tools.

[1]https://github.com/baylibre/ffmpeg-drm


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

Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Łukasz Krzciuk]

Any updates on this issue?

Regards,

*Łukasz Krzciuk*
Developer

Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska


On Thu, Apr 26, 2018 at 9:22 AM, Łukasz Krzciuk  wrote:

> Thank you.
>
> This change is really simple: set AV_DISPOSITION_DESCRIPTIONS bit when we
> have a specified stream. So a test could be simple too. But I cannot see
> many of tests in .../libavformat/tests dir. It seems 'disposition' is not
> tested at all currently. So if I will prepare a testcase for
> 'ff_parse_mpeg2_descriptor' function, then a test data could be a problem
> here. org.hbbtv_HTML50420 test is rather huge, and cannot be simply applied
> here.
>
>
> Regards,
>
> *Łukasz Krzciuk*
> Developer
>
> Vewd
> ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
>
>
> On Thu, Apr 26, 2018 at 2:05 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Wed, Apr 25, 2018 at 08:17:38AM +0200, Łukasz Krzciuk wrote:
>> > Yes, I have checked it and I implemented it according to OIPF spec:
>> 8.4.2
>> > AVComponent, audioDescription case (as I wrote in my 1st email). This
>> > implementation is tested by official org.hbbtv_HTML50420 testcase.
>>
>> ok, ill apply it then
>>
>> is it (easily) possibly to add some test for this to fate ?
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> it is not once nor twice but times without number that the same ideas make
>> their appearance in the world. -- Aristotle
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] avutil/hwcontext_cuda: add CUstream in cuda hwctx

[Timo Rothenpieler]

On 08.05.2018 23:00, James Almer wrote:
> On 5/8/2018 3:36 PM, Timo Rothenpieler wrote:
>> ---
>>  configure  | 6 --
>>  doc/APIchanges | 3 +++
>>  libavutil/hwcontext_cuda.c | 3 +++
>>  libavutil/hwcontext_cuda.h | 1 +
>>  libavutil/version.h| 2 +-
>>  5 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 6626111ff2..9743de05d0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5887,8 +5887,10 @@ check_type "va/va.h va/va_enc_vp9.h"  
>> "VAEncPictureParameterBufferVP9"
>>  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
>>  
>>  if ! disabled ffnvcodec; then
>> -check_pkg_config ffnvcodec "ffnvcodec >= 8.0.14.1" \
>> -"ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
>> ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" ""
>> +check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.2" \
>> +  "ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
>> ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" "" || \
>> +{ test_pkg_config ffnvcodec_tmp "ffnvcodec < 8.1" "" "" && 
>> check_pkg_config ffnvcodec "ffnvcodec >= 8.0.14.2" \
>> +  "ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
>> ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" ""; }
> 
> ffnvcodec_tmp?

I haven't found a more elegant way to do this.
Basically, the version requirement is

ffnvcodec >= 8.1.24.2 || (ffnvcodec < 8.1 && ffnvcodec >= 8.0.14.2)

As < 8.1 would also match 8.0.14.1, it must not enable ffnvcodec, which
is why i appended the _tmp.

pkg-config does not seem able to evaluate such complex version checks,
and there is no lower level function than test_pkg_config.



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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field

[Xiang, Haihao]

On Wed, 2018-05-09 at 07:50 +0200, Jerome Borsboom wrote:
> Contrary to VC-1 spec, VAAPI expects the row address of the first
> macroblock row in the first slice to start from zero for the second
> field in a field interlaced picture.
> 
> Signed-off-by: Jerome Borsboom 
> ---
> This patch set adds support for hardware decoding multi-slice field interlaced
> pictures. With this patch set, the SA10180 test file decodes correctly with
> VAAPI hardware acceleration. This was succesfully tested on Intel Haswell
> platform.
> 

I still see lots of artifacts for a multi-slice field interfaced VC-1 video on
Coffee Lake, maybe we should fix it in the driver 

Thanks
Haihao


>  libavcodec/vaapi_vc1.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
> index bdb5e24cc5..921ca6391b 100644
> --- a/libavcodec/vaapi_vc1.c
> +++ b/libavcodec/vaapi_vc1.c
> @@ -467,6 +467,7 @@ static int vaapi_vc1_decode_slice(AVCodecContext *avctx,
> const uint8_t *buffer,
>  const MpegEncContext *s = &v->s;
>  VAAPIDecodePicture *pic = s->current_picture_ptr-
> >hwaccel_picture_private;
>  VASliceParameterBufferVC1 slice_param;
> +int mb_height;
>  int err;
>  
>  /* Current bit buffer is beyond any marker for VC-1, so skip it */
> @@ -475,12 +476,17 @@ static int vaapi_vc1_decode_slice(AVCodecContext *avctx,
> const uint8_t *buffer,
>  size -= 4;
>  }
>  
> +if (v->fcm == ILACE_FIELD)
> +mb_height = avctx->coded_height + 31 >> 5;
> +else
> +mb_height = avctx->coded_height + 15 >> 4;
> +
>  slice_param = (VASliceParameterBufferVC1) {
>  .slice_data_size = size,
>  .slice_data_offset   = 0,
>  .slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
>  .macroblock_offset   = get_bits_count(&s->gb),
> -.slice_vertical_position = s->mb_y,
> +.slice_vertical_position = s->mb_y % mb_height,
>  };
>  
>  err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Jorge Ramirez-Ortiz]

On 05/09/2018 01:33 AM, Mark Thompson wrote:

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..9457fadb1e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
  struct v4l2_requestbuffers req = {
  .memory = V4L2_MEMORY_MMAP,
  .type = ctx->type,
-.count = 0, /* 0 -> unmaps buffers from the driver */
+.count = 0, /* 0 -> unmap all buffers from the driver */
  };
-int i, j;
+int ret, i, j;
  
  for (i = 0; i < ctx->num_buffers; i++) {

  V4L2Buffer *buffer = &ctx->buffers[i];
  
  for (j = 0; j < buffer->num_planes; j++) {

  struct V4L2Plane_info *p = &buffer->plane_info[j];
+
+if (V4L2_TYPE_IS_OUTPUT(ctx->type)) {
+/* output buffers are not EXPORTED */
+goto unmap;
+}
+
+if (ctx_to_m2mctx(ctx)->output_drm) {
+/* use the DRM frame to close */
+if (buffer->drm_frame.objects[j].fd >= 0) {
+if (close(buffer->drm_frame.objects[j].fd) < 0) {
+av_log(logger(ctx), AV_LOG_ERROR, "%s close drm fd "
+"[buffer=%2d, plane=%d, fd=%2d] - %s \n",
+ctx->name, i, j, buffer->drm_frame.objects[j].fd,
+av_err2str(AVERROR(errno)));
+}
+}
+}
+unmap:
  if (p->mm_addr && p->length)
  if (munmap(p->mm_addr, p->length) < 0)
-av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane (%s))\n", 
ctx->name, av_err2str(AVERROR(errno)));
+av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane (%s))\n",
+ctx->name, av_err2str(AVERROR(errno)));
  }
  }
  
-return ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);

+ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);
+if (ret < 0) {
+av_log(logger(ctx), AV_LOG_ERROR, "release all %s buffers (%s)\n",
+ctx->name, av_err2str(AVERROR(errno)));
+
+if (ctx_to_m2mctx(ctx)->output_drm)
+av_log(logger(ctx), AV_LOG_ERROR,
+"Make sure the DRM client releases all FB/GEM objects before 
closing the codec (ie):\n"
+"for all buffers: \n"
+"  1. drmModeRmFB(..)\n"
+"  2. drmIoctl(.., DRM_IOCTL_GEM_CLOSE,... )\n");

You should be able to keep references to all DRM PRIME frames as they leave the 
codec, and then only call this when all references have disappeared.



yes, that is the way it was working for non DRM frames.

If we need to guarantee that exact same behavior, ffmpeg needs to be 
able to remove the fb handles and close the gem objects on each buffer 
being released (so mirror the action we take with just munmap)


This is what I mean:
https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c#L391

I think this would mean that the libavcodec should open the drm device 
instead of the client application doing it and perform the actions above 
in unref.

would that be acceptable?

or perhaps we can just let the libavcodec client be responsible for all 
the drm device actions (which is what this patch does).







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

[FFmpeg-devel] [RFC] On behaviour of unlabelled outputs in filtergraphs.

[Gyan Doshi]

In the open ticket 7089, I reported that (terminal) filters with 
unlabelled output pads are automatically forwarded to the first output 
file and ordered before any expressly mapped streams. There's no warning 
issued.


Is this behaviour intended?


In the section on filtergraph syntax @ 
https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-syntax-1,


it says,

"If an output pad is not labelled, it is linked by default to the
 first unlabelled input pad of the next filter in the filterchain."

and

"In a complete filterchain all the unlabelled filter input and
 output pads must be connected. A filtergraph is considered valid
 if all the filter input and output pads of all the filterchains are
 connected."

There's no mention of unlabelled output pads being sent to an output file.

-

If the present behaviour does not constitute a bug I'll modify the docs. 
However, I believe it should be considered a bug.


In the section on Stream Selection @ 
https://ffmpeg.org/ffmpeg.html#Stream-selection,


it says,

"By default, ffmpeg includes only one stream of each type (video,
 audio, subtitle) present in the input files and adds them to each
 output file. It picks the "best" of each ... For full manual
 control, use the -map option, which disables the defaults just
 described."

So, in the absence of any map directives, only one stream at most of 
each of the three stream types should be included, and these should be 
the 'best' streams from among the inputs. But all unlabelled output pads 
are included, however many they are, and none of them may be the 'best' 
stream since the stream(s) being filtered may not have been selected on 
the same criterion.


And in the presence of the map option, by automatically including 
streams, "full manual control" is not true.



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

[FFmpeg-devel] [PATCH] fate: add more tests for hue video filter

[Tobias Rapp]

Adds tests for the hue angle and brightness filter parameters.
Renames the existing saturation parameter test for consistency.

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak | 10 --
 tests/ref/fate/filter-hue   |  1 -
 tests/ref/fate/filter-hue1  |  1 +
 tests/ref/fate/filter-hue2  |  1 +
 tests/ref/fate/filter-hue3  |  1 +
 5 files changed, 11 insertions(+), 3 deletions(-)
 delete mode 100644 tests/ref/fate/filter-hue
 create mode 100644 tests/ref/fate/filter-hue1
 create mode 100644 tests/ref/fate/filter-hue2
 create mode 100644 tests/ref/fate/filter-hue3

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 17d6363..f2ab263 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -499,8 +499,14 @@ fate-filter-edgedetect: CMD = video_filter 
"format=gray,perms=random,edgedetect"
 FATE_FILTER_VSYNTH-$(call ALLYES, FORMAT_FILTER PERMS_FILTER 
EDGEDETECT_FILTER) += fate-filter-edgedetect-colormix
 fate-filter-edgedetect-colormix: CMD = video_filter 
"format=gbrp,perms=random,edgedetect=mode=colormix" -frames:v 20
 
-FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue
-fate-filter-hue: CMD = video_filter "perms=random,hue=s=sin(2*PI*t)+1" 
-frames:v 20
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue1
+fate-filter-hue1: CMD = video_filter "perms=random,hue=s=sin(2*PI*t)+1" 
-frames:v 20
+
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue2
+fate-filter-hue2: CMD = video_filter "perms=random,hue=h=18*n" -frames:v 20
+
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue3
+fate-filter-hue3: CMD = video_filter "perms=random,hue=b=n-10" -frames:v 20
 
 FATE_FILTER_VSYNTH-$(CONFIG_IDET_FILTER) += fate-filter-idet
 fate-filter-idet: CMD = framecrc -flags bitexact -idct simple -i $(SRC) -vf 
idet -frames:v 25 -flags +bitexact
diff --git a/tests/ref/fate/filter-hue b/tests/ref/fate/filter-hue
deleted file mode 100644
index 2f1ae61..000
--- a/tests/ref/fate/filter-hue
+++ /dev/null
@@ -1 +0,0 @@
-hue 57463dd9bc17156a51b704dd7271c863
diff --git a/tests/ref/fate/filter-hue1 b/tests/ref/fate/filter-hue1
new file mode 100644
index 000..7059ba7
--- /dev/null
+++ b/tests/ref/fate/filter-hue1
@@ -0,0 +1 @@
+hue157463dd9bc17156a51b704dd7271c863
diff --git a/tests/ref/fate/filter-hue2 b/tests/ref/fate/filter-hue2
new file mode 100644
index 000..2e060e1
--- /dev/null
+++ b/tests/ref/fate/filter-hue2
@@ -0,0 +1 @@
+hue2e951ae8ffb279552abc4354c4de7cb5b
diff --git a/tests/ref/fate/filter-hue3 b/tests/ref/fate/filter-hue3
new file mode 100644
index 000..14a8379
--- /dev/null
+++ b/tests/ref/fate/filter-hue3
@@ -0,0 +1 @@
+hue3149dc22f5dc9f578f7d281dc3120c09b
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field

[Jerome Borsboom]

>> Contrary to VC-1 spec, VAAPI expects the row address of the first
>> macroblock row in the first slice to start from zero for the second
>> field in a field interlaced picture.
>> 
>> Signed-off-by: Jerome Borsboom 
>> ---
>> This patch set adds support for hardware decoding multi-slice field 
>> interlaced
>> pictures. With this patch set, the SA10180 test file decodes correctly with
>> VAAPI hardware acceleration. This was succesfully tested on Intel Haswell
>> platform.
>> 
> 
> I still see lots of artifacts for a multi-slice field interfaced VC-1 video on
> Coffee Lake, maybe we should fix it in the driver 
> 
> Thanks
> Haihao

I suppose you also applied the second part of this patch and still see
artifacts. I cannot check for Coffee Lake, but there may be issues with
the VAAPI driver for CL platform. The patches are just a copy of the
multi-slice support for frame interlaced images, so nothing special there.

Could you share (part of) the video you used to check on Coffee Lake so
that I can see how Haswell performs?


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

[FFmpeg-devel] About the future of component registration APIs

[Yu Xiaolei]

Hello,
I noticed that commit 7e8eba2d87 deprecated avcodec_register and there was
some disagreement on this issue. Will there be some sort of replacement for
it?

We want to build ffmpeg in a way that only the most frequently used
components are shipped initially and others are downloaded on demand. This
can be implemented for now with a custom link step but will be impossible
if this API were removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avcodec/cbs_h2645: use AVBufferRef to store list of active parameter sets

[Mark Thompson]

On 09/05/18 02:12, James Almer wrote:
> Removes unnecessary data copies, and partially fixes potential issues
> with dangling references held in said lists.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs_h264.h  |  2 ++
>  libavcodec/cbs_h2645.c | 46 --
>  libavcodec/cbs_h265.h  |  3 +++
>  3 files changed, 31 insertions(+), 20 deletions(-)
> 
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index 2219d9da8d..d953c1f66b 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -421,6 +421,8 @@ typedef struct CodedBitstreamH264Context {
>  
>  // All currently available parameter sets.  These are updated when
>  // any parameter set NAL unit is read/written with this context.
> +AVBufferRef *sps_ref[H264_MAX_SPS_COUNT];
> +AVBufferRef *pps_ref[H264_MAX_PPS_COUNT];
>  H264RawSPS *sps[H264_MAX_SPS_COUNT];
>  H264RawPPS *pps[H264_MAX_PPS_COUNT];
>  
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 64a1a2d1ee..1ce42c6950 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -677,9 +677,10 @@ static int 
> cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
>  
>  #define cbs_h2645_replace_ps(h26n, ps_name, ps_var, id_element) \
>  static int cbs_h26 ## h26n ## _replace_ ## ps_var(CodedBitstreamContext 
> *ctx, \
> -  const H26 ## h26n ## Raw 
> ## ps_name *ps_var)  \
> +  CodedBitstreamUnit *unit)  
> \
>  { \
>  CodedBitstreamH26 ## h26n ## Context *priv = ctx->priv_data; \
> +H26 ## h26n ## Raw ## ps_name *ps_var = unit->content; \
>  unsigned int id = ps_var->id_element; \
>  if (id > FF_ARRAY_ELEMS(priv->ps_var)) { \
>  av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid " #ps_name \
> @@ -688,11 +689,16 @@ static int cbs_h26 ## h26n ## _replace_ ## 
> ps_var(CodedBitstreamContext *ctx, \
>  } \
>  if (priv->ps_var[id] == priv->active_ ## ps_var) \
>  priv->active_ ## ps_var = NULL ; \
> -av_freep(&priv->ps_var[id]); \
> -priv->ps_var[id] = av_malloc(sizeof(*ps_var)); \
> -if (!priv->ps_var[id]) \
> +av_buffer_unref(&priv->ps_var ## _ref[id]); \
> +if (unit->content_ref) \
> +priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
> +else \
> +priv->ps_var ## _ref[id] = av_buffer_alloc(sizeof(*ps_var)); \
> +if (!priv->ps_var ## _ref[id]) \
>  return AVERROR(ENOMEM); \
> -memcpy(priv->ps_var[id], ps_var, sizeof(*ps_var)); \
> +priv->ps_var[id] = (H26 ## h26n ## Raw ## ps_name *)priv->ps_var ## 
> _ref[id]->data; \
> +if (!unit->content_ref) \
> +memcpy(priv->ps_var[id], ps_var, sizeof(*ps_var)); \
>  return 0; \
>  }
>  
> @@ -726,7 +732,7 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h264_replace_sps(ctx, sps);
> +err = cbs_h264_replace_sps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -760,7 +766,7 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h264_replace_pps(ctx, pps);
> +err = cbs_h264_replace_pps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -873,7 +879,7 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h265_replace_vps(ctx, vps);
> +err = cbs_h265_replace_vps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -892,7 +898,7 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h265_replace_sps(ctx, sps);
> +err = cbs_h265_replace_sps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -912,7 +918,7 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h265_replace_pps(ctx, pps);
> +err = cbs_h265_replace_pps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -1002,7 +1008,7 @@ static int 
> cbs_h264_write_nal_unit(CodedBitstreamContext *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h264_replace_sps(ctx, sps);
> +err = cbs_h264_replace_sps(ctx, unit);
>  if (err < 0)
>  return err;
>  }
> @@ -1026,7 +1032,7 @@ static int 
> cbs_h264_write_nal_unit(CodedBitstreamContext *ctx,
>  if (err < 0)
>  return err;
>  
> -err = cbs_h264_replace_pps(ctx, pp

Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode: Initialize the pointer

[Mark Thompson]

On 09/05/18 05:29, Xiang, Haihao wrote:
> On Tue, 2018-05-08 at 22:34 +0100, Mark Thompson wrote:
>> On 08/05/18 03:35, Xiang, Haihao wrote:
>>> On Mon, 2018-05-07 at 21:46 +0100, Mark Thompson wrote:
 On 04/05/18 15:41, Haihao Xiang wrote:
> Otherwise it might use unitialized last_pic in av_assert0(last_pic)
>
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vaapi_encode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 36c85a3815..141e50c8ad 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -760,7 +760,7 @@ fail:
>  static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAAPIEncodePicture *pic, *last_pic, *next;
> +VAAPIEncodePicture *pic, *last_pic = NULL, *next;
>  
>  // Find the last picture we actually have input for.
>  for (pic = ctx->pic_start; pic; pic = pic->next) {
>

 How do you hit this?  last_pic should always get set.

>>>
>>> It was reported by some static analysis tools, but I agree with you that
>>> last_pic should get set in the code path, however if we consider
>>> vaapi_encode_truncate_gop() only,  last_pic will be uninitialized if ctx-
 pic_start is non-NULL but ctx->pic_start->input_available is not set. How
 about
>>>
>>> to add av_assert0(!ctx->pic_start || ctx->pic_start->input_available) before
>>> the
>>>  for () statement and remove av_assert0(last_pic)?
>>
>> I think you mean "av_assert0(ctx->pic_start && ctx->pic_start-
>>> input_available)"?
>>
> 
> No. I meant "av_assert0(!ctx->pic_start || ctx->pic_start->input_available)". 
> I
> thought ctx->pic_start might be NULL when vaapi_encode_truncate_gop() is 
> called
> in vaapi_encode.c, line 865. 

Apologies, you are correct.  I was thinking of the test in the wrong place.

> However testing a simple transcode of H265 showed input_image->pict_type is
> always AV_PICTURE_TYPE_NONE (a bug?), which means vaapi_encode_truncate_gop() 
> in
> vaapi_encode.c, line 865 is never called. This piece of code was added in 
> commit
> c667c0979cbc2e04d1d00964b82ac49746caa43c to support forcing IDR frame. How do 
> I
> set a forced IDR via AVFrame.pict_type?

The setting of pict_type on encoders is intended for library users to force key 
frames where required by other constraints (e.g. when stream synchronisation is 
lost in a videoconferencing-type setup).  Usually an encoder has free choice of 
what GOP structure to use and where to place key frames, and this is only used 
in specific setups requiring it.

Given that, the ffmpeg utility doesn't set any frame types by default.  For 
testing with it you can override the key frame behaviour with the 
-force_key_frames option, which sets an expression for frames to force as key 
frames by the pict_type mechanism, or you could write a program using 
libavcodec which sets them directly.

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

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

[Mark Thompson]

On 09/05/18 05:48, Xiang, Haihao wrote:
> On Tue, 2018-05-08 at 22:51 +0100, Mark Thompson wrote:
>> On 08/05/18 04:54, Xiang, Haihao wrote:
>>> On Mon, 2018-05-07 at 22:03 +0100, Mark Thompson wrote:
 On 04/05/18 09:54, Xiang, Haihao wrote:
> On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
>> On 03/05/18 04:07, Haihao Xiang wrote:
>>> '-sei xxx' is added to control SEI insertion, so far only mastering
>>> display colour colume is available for testing.
>>
>> Typo: "colume" (also in the commit title).
>>
>
> Thanks for catching the typo, I will correct it in the new version of
> patch.
>
>>> v2: use the mastering display parameters from
>>> AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to match
>>> the H.264 part and take VAAPIEncodeH265Context::sei_needed as a ORed
>>> value so that we needn't check the correspoding SEI message again
>>> when
>>> writting the header.
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/vaapi_encode_h265.c | 128
>>> -
>>>  1 file changed, 127 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c
>>> b/libavcodec/vaapi_encode_h265.c
>>> index 5203c6871d..326fe4fe66 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -24,15 +24,20 @@
>>>  #include "libavutil/avassert.h"
>>>  #include "libavutil/common.h"
>>>  #include "libavutil/opt.h"
>>> +#include "libavutil/mastering_display_metadata.h"
>>>  
>>>  #include "avcodec.h"
>>>  #include "cbs.h"
>>>  #include "cbs_h265.h"
>>>  #include "hevc.h"
>>> +#include "hevc_sei.h"
>>>  #include "internal.h"
>>>  #include "put_bits.h"
>>>  #include "vaapi_encode.h"
>>>  
>>> +enum {
>>> +SEI_MASTERING_DISPLAY   = 0x08,
>>> +};
>>>  
>>>  typedef struct VAAPIEncodeH265Context {
>>>  unsigned int ctu_width;
>>> @@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
>>>  H265RawSPS sps;
>>>  H265RawPPS pps;
>>>  H265RawSlice slice;
>>> +H265RawSEI sei;
>>> +
>>> +H265RawSEIMasteringDiplayColourVolume mastering_display;
>>>  
>>>  int64_t last_idr_frame;
>>>  int pic_order_cnt;
>>> @@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
>>>  CodedBitstreamContext *cbc;
>>>  CodedBitstreamFragment current_access_unit;
>>>  int aud_needed;
>>> +int sei_needed;
>>>  } VAAPIEncodeH265Context;
>>>  
>>>  typedef struct VAAPIEncodeH265Options {
>>> @@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
>>>  int aud;
>>>  int profile;
>>>  int level;
>>> +int sei;
>>>  } VAAPIEncodeH265Options;
>>>  
>>>  
>>> @@ -175,6 +185,64 @@ fail:
>>>  return err;
>>>  }
>>>  
>>> +static int vaapi_encode_h265_write_extra_header(AVCodecContext
>>> *avctx,
>>> +VAAPIEncodePicture
>>> *pic,
>>> +int index, int
>>> *type,
>>> +char *data, size_t
>>> *data_len)
>>> +{
>>> +VAAPIEncodeContext  *ctx = avctx->priv_data;
>>> +VAAPIEncodeH265Context *priv = ctx->priv_data;
>>> +CodedBitstreamFragment   *au = &priv->current_access_unit;
>>> +int err, i;
>>> +
>>> +if (priv->sei_needed) {
>>> +if (priv->aud_needed) {
>>> +err = vaapi_encode_h265_add_nal(avctx, au, &priv->aud);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->aud_needed = 0;
>>> +}
>>> +
>>> +memset(&priv->sei, 0, sizeof(priv->sei));
>>> +priv->sei.nal_unit_header  = (H265RawNALUnitHeader) {
>>> +.nal_unit_type = HEVC_NAL_SEI_PREFIX,
>>> +.nuh_layer_id  = 0,
>>> +.nuh_temporal_id_plus1 = 1,
>>> +};
>>> +
>>> +i = 0;
>>> +
>>> +if (priv->sei_needed & SEI_MASTERING_DISPLAY) {
>>> +priv->sei.payload[i].payload_type =
>>> HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
>>> +priv->sei.payload[i].payload.mastering_display = priv-
 mastering_display;
>>>
>>> +++i;
>>> +}
>>> +
>>> +priv->sei.payload_count = i;
>>> +av_assert0(priv->sei.payload_count > 0);
>>> +
>>> +err = vaapi_encode_h265_add_nal(avctx, au, &priv->sei);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->sei_needed = 0;
>>> +
>>> +err = vaapi_encode_h265_write_access_unit(avctx, data,
>>> data_len,
>

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Mark Thompson]

On 09/05/18 08:57, Jorge Ramirez-Ortiz wrote:
> On 05/09/2018 01:33 AM, Mark Thompson wrote:
>> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
>> index ed5193ecc1..2b33badb08 100644
>> --- a/libavcodec/v4l2_m2m_dec.c
>> +++ b/libavcodec/v4l2_m2m_dec.c
>> @@ -23,12 +23,18 @@
>>     #include 
>>   #include 
>> +
>> +#include "libavutil/hwcontext.h"
>> +#include "libavutil/hwcontext_drm.h"
>>   #include "libavutil/pixfmt.h"
>>   #include "libavutil/pixdesc.h"
>>   #include "libavutil/opt.h"
>>   #include "libavcodec/avcodec.h"
>>   #include "libavcodec/decode.h"
>>   +#include "libavcodec/hwaccel.h"
>> +#include "libavcodec/internal.h"
>> +
>>   #include "v4l2_context.h"
>>   #include "v4l2_m2m.h"
>>   #include "v4l2_fmt.h"
>> @@ -183,6 +189,15 @@ static av_cold int v4l2_decode_init(AVCodecContext 
>> *avctx)
>>   capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
>>   capture->av_pix_fmt = avctx->pix_fmt;
>>   +    /* the client requests the codec to generate DRM frames:
>> + *   - data[0] will therefore point to the returned AVDRMFrameDescriptor
>> + *   check the ff_v4l2_buffer_to_avframe conversion function.
>> + *   - the DRM frame format is passed in the DRM frame descriptor layer.
>> + *   check the v4l2_get_drm_frame function.
>> + */
>> +    if (avctx->pix_fmt == AV_PIX_FMT_DRM_PRIME)
>> +    s->output_drm = 1;
>> +
>>   ret = ff_v4l2_m2m_codec_init(avctx);
>>   if (ret) {
>>   av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");
>> @@ -202,6 +217,11 @@ static const AVOption options[] = {
>>   { NULL},
>>   };
> 
> As a follow up to your comment on pixel format negotiation 
> (AvCodecContext.getformat), notice that this is a tentative request from the 
> user to select a pixel format.
> The actual pixel format negotiation - where the decoder will select the pixel 
> format- will happen later during v4l2_try_start.

Indeed.  get_format() will have to be called during the pixel format 
negotiation so that the user can pick between whatever the supported software 
format is (NV12, NV21, YUV420P P010, whatever) or the DRM-PRIME object hardware 
format (if supported).

AVCodecContext.pix_fmt is intended to be set by the decoder to say what pix_fmt 
it intends to produce (though even in that role it's highly dubious given 
threaded decoders and stream changes).  For historical reasons it is also 
allowed to be set externally (because of libavformat interactions), but this 
shouldn't be used for configuration.

> This change enables the v4l2m2m decoder to output either dmabuf descriptors 
> to be consumed by a DRM or video frame formats to be consumed by SDL (for 
> instance).
> As an example, these changes have been tested with ffplay (SDL based display) 
> and a simple DRM application [1]
> 
> Lukas tested with other tools.
> 
> [1]https://github.com/baylibre/ffmpeg-drm

We should make this usable in the ffmpeg application too.  The DRM object 
format is works fine in ffmpeg already with Rockchip decoder (consumed by the 
hwmap/hwdownload filters, or by mapping to OpenCL), but that doesn't need the 
format selection part.  (There are also kmsgrab and VAAPI, but those aren't 
making DRM PRIME frames directly at a decoder.)  I believe this should be 
straightforward with a small modification to get_format() in ffmpeg.c to accept 
AV_CODEC_HW_CONFIG_METHOD_INTERNAL, I can look at this once we have a codec 
which will need it.

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

Re: [FFmpeg-devel] [PATCH v3] avcodec/cbs_h2645: use AVBufferRef to store list of active parameter sets

[James Almer]

On 5/9/2018 10:41 AM, Mark Thompson wrote:
> Tested with VAAPI encode, LGTM.
> 

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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Mark Thompson]

On 09/05/18 10:02, Jorge Ramirez-Ortiz wrote:
> On 05/09/2018 01:33 AM, Mark Thompson wrote:
>>> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
>>> index efcb0426e4..9457fadb1e 100644
>>> --- a/libavcodec/v4l2_context.c
>>> +++ b/libavcodec/v4l2_context.c
>>> @@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
>>>  struct v4l2_requestbuffers req = {
>>>  .memory = V4L2_MEMORY_MMAP,
>>>  .type = ctx->type,
>>> -.count = 0, /* 0 -> unmaps buffers from the driver */
>>> +.count = 0, /* 0 -> unmap all buffers from the driver */
>>>  };
>>> -int i, j;
>>> +int ret, i, j;
>>>  
>>>  for (i = 0; i < ctx->num_buffers; i++) {
>>>  V4L2Buffer *buffer = &ctx->buffers[i];
>>>  
>>>  for (j = 0; j < buffer->num_planes; j++) {
>>>  struct V4L2Plane_info *p = &buffer->plane_info[j];
>>> +
>>> +if (V4L2_TYPE_IS_OUTPUT(ctx->type)) {
>>> +/* output buffers are not EXPORTED */
>>> +goto unmap;
>>> +}
>>> +
>>> +if (ctx_to_m2mctx(ctx)->output_drm) {
>>> +/* use the DRM frame to close */
>>> +if (buffer->drm_frame.objects[j].fd >= 0) {
>>> +if (close(buffer->drm_frame.objects[j].fd) < 0) {
>>> +av_log(logger(ctx), AV_LOG_ERROR, "%s close drm fd 
>>> "
>>> +"[buffer=%2d, plane=%d, fd=%2d] - %s \n",
>>> +ctx->name, i, j, 
>>> buffer->drm_frame.objects[j].fd,
>>> +av_err2str(AVERROR(errno)));
>>> +}
>>> +}
>>> +}
>>> +unmap:
>>>  if (p->mm_addr && p->length)
>>>  if (munmap(p->mm_addr, p->length) < 0)
>>> -av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
>>> (%s))\n", ctx->name, av_err2str(AVERROR(errno)));
>>> +av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
>>> (%s))\n",
>>> +ctx->name, av_err2str(AVERROR(errno)));
>>>  }
>>>  }
>>>  
>>> -return ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);
>>> +ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);
>>> +if (ret < 0) {
>>> +av_log(logger(ctx), AV_LOG_ERROR, "release all %s buffers 
>>> (%s)\n",
>>> +ctx->name, av_err2str(AVERROR(errno)));
>>> +
>>> +if (ctx_to_m2mctx(ctx)->output_drm)
>>> +av_log(logger(ctx), AV_LOG_ERROR,
>>> +"Make sure the DRM client releases all FB/GEM objects 
>>> before closing the codec (ie):\n"
>>> +"for all buffers: \n"
>>> +"  1. drmModeRmFB(..)\n"
>>> +"  2. drmIoctl(.., DRM_IOCTL_GEM_CLOSE,... )\n");
>> You should be able to keep references to all DRM PRIME frames as they leave 
>> the codec, and then only call this when all references have disappeared.
>>
> 
> yes, that is the way it was working for non DRM frames.
> 
> If we need to guarantee that exact same behavior, ffmpeg needs to be able to 
> remove the fb handles and close the gem objects on each buffer being released 
> (so mirror the action we take with just  munmap)

I believe the unref function should only need to close the PRIME file 
descriptors.  (Assuming they are new rather than magically reused somehow - 
VAAPI makes new fds which have to be closed, while Rockchip reuses them so they 
shouldn't be.  This is handled correctly by the buffer references in each case, 
the user does not need to do anything differently.)  Any framebuffer handles 
and related are created by the user rather than libavcodec, who won't unref the 
frame they are made from until everything derived from it is suitably released.

> This is what I mean:
> https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c#L391
> 
> I think this would mean that the libavcodec should open the drm device 
> instead of the client application doing it and perform the actions above in 
> unref.
> would that be acceptable?

Is there necessarily an explicit DRM device associated with a V4L2 decoder?  
(And if so, how do you find it?)  For comparison, there isn't one for Rockchip 
- there we create a dummy device to host the frames context.

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

Re: [FFmpeg-devel] [PATCH] lavc/qsv: suppress code scan complain

[Mark Thompson]

On 09/05/18 07:13, Zhong Li wrote:
> Suppress the complain "variables 'type' is used but maybe uninitialized".
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 45e1c25..b578da0 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -197,7 +197,7 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx, 
> QSVFrame *frame)
>  
>  enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
>  {
> -enum AVPictureType type;
> +enum AVPictureType type = AV_PICTURE_TYPE_NONE;
>  switch (mfx_pic_type & 0x7) {
>  case MFX_FRAMETYPE_I:
>  if (mfx_pic_type & MFX_FRAMETYPE_S)
> 

Might it be better to add a default case to the switch and assert that it's 
never reached?  I think if the pic type doesn't hit one of the existing cases 
then something must be very broken.

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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Dave Stevenson]

On 9 May 2018 at 15:31, Mark Thompson  wrote:
> On 09/05/18 10:02, Jorge Ramirez-Ortiz wrote:
>> On 05/09/2018 01:33 AM, Mark Thompson wrote:
 diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
 index efcb0426e4..9457fadb1e 100644
 --- a/libavcodec/v4l2_context.c
 +++ b/libavcodec/v4l2_context.c
 @@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
  struct v4l2_requestbuffers req = {
  .memory = V4L2_MEMORY_MMAP,
  .type = ctx->type,
 -.count = 0, /* 0 -> unmaps buffers from the driver */
 +.count = 0, /* 0 -> unmap all buffers from the driver */
  };
 -int i, j;
 +int ret, i, j;

  for (i = 0; i < ctx->num_buffers; i++) {
  V4L2Buffer *buffer = &ctx->buffers[i];

  for (j = 0; j < buffer->num_planes; j++) {
  struct V4L2Plane_info *p = &buffer->plane_info[j];
 +
 +if (V4L2_TYPE_IS_OUTPUT(ctx->type)) {
 +/* output buffers are not EXPORTED */
 +goto unmap;
 +}
 +
 +if (ctx_to_m2mctx(ctx)->output_drm) {
 +/* use the DRM frame to close */
 +if (buffer->drm_frame.objects[j].fd >= 0) {
 +if (close(buffer->drm_frame.objects[j].fd) < 0) {
 +av_log(logger(ctx), AV_LOG_ERROR, "%s close drm 
 fd "
 +"[buffer=%2d, plane=%d, fd=%2d] - %s \n",
 +ctx->name, i, j, 
 buffer->drm_frame.objects[j].fd,
 +av_err2str(AVERROR(errno)));
 +}
 +}
 +}
 +unmap:
  if (p->mm_addr && p->length)
  if (munmap(p->mm_addr, p->length) < 0)
 -av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
 (%s))\n", ctx->name, av_err2str(AVERROR(errno)));
 +av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
 (%s))\n",
 +ctx->name, av_err2str(AVERROR(errno)));
  }
  }

 -return ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);
 +ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, &req);
 +if (ret < 0) {
 +av_log(logger(ctx), AV_LOG_ERROR, "release all %s buffers 
 (%s)\n",
 +ctx->name, av_err2str(AVERROR(errno)));
 +
 +if (ctx_to_m2mctx(ctx)->output_drm)
 +av_log(logger(ctx), AV_LOG_ERROR,
 +"Make sure the DRM client releases all FB/GEM objects 
 before closing the codec (ie):\n"
 +"for all buffers: \n"
 +"  1. drmModeRmFB(..)\n"
 +"  2. drmIoctl(.., DRM_IOCTL_GEM_CLOSE,... )\n");
>>> You should be able to keep references to all DRM PRIME frames as they leave 
>>> the codec, and then only call this when all references have disappeared.
>>>
>>
>> yes, that is the way it was working for non DRM frames.
>>
>> If we need to guarantee that exact same behavior, ffmpeg needs to be able to 
>> remove the fb handles and close the gem objects on each buffer being 
>> released (so mirror the action we take with just  munmap)
>
> I believe the unref function should only need to close the PRIME file 
> descriptors.  (Assuming they are new rather than magically reused somehow - 
> VAAPI makes new fds which have to be closed, while Rockchip reuses them so 
> they shouldn't be.  This is handled correctly by the buffer references in 
> each case, the user does not need to do anything differently.)  Any 
> framebuffer handles and related are created by the user rather than 
> libavcodec, who won't unref the frame they are made from until everything 
> derived from it is suitably released.

Videobuf2 (the V4L2 buffer allocation/handlier) will have created a
dmabuf fd for each buffer/plane via the VIDIOC_EXPBUF ioctl. It is up
to the client to close those.

There is an odd-ball in videobuf2. On the REQBUFS(0) call to release
all the buffers it checks the number of users of the buffers, and
fails the release call if anyone is using it. It's even documented
that way [1].
This had been raised with the V4L2 maintainers as strange and
annoying, but not resolved [2]. It probably needs picking up again and
getting merged into mainline, but that will then have a hard
requirement of needing a latest kernel.

The error message here is really for information that things haven't
cleaned up in the manner that you might expect. Either you just ignore
it and let V4L2 clean up eventually when the main V4L2 device fd gets
closed, or you need applications to behave in a particular manner.
Ignoring it has potential knockon issues as calls like S_FMT to
request a different format/resolution will typically fail if

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Dave Stevenson]

On 9 May 2018 at 00:33, Mark Thompson  wrote:
> On 08/05/18 19:24, Lukas Rusak wrote:
>> +
>> +layer->format = avbuf->context->av_pix_fmt == AV_PIX_FMT_NV12 ?
>> +DRM_FORMAT_NV12 : DRM_FORMAT_NV21;
>> +layer->nb_planes = 2;
>> +
>> +layer->planes[1].object_index = 0;
>> +layer->planes[1].offset = avbuf->plane_info[0].bytesperline *
>> +avbuf->context->format.fmt.pix_mp.height;
>
> Is that always true?  I would expect that some driver might want more 
> vertical alignment (especially with tiled formats) and would provide this 
> number somewhere else.

The V4L2 spec defines their NV12/21 as:
"These are two-plane versions of the YUV 4:2:0 format. The three
components are separated into two sub-images or planes. The Y plane is
first. The Y plane has one byte per pixel. For V4L2_PIX_FMT_NV12, a
combined CbCr plane immediately follows the Y plane in memory. " [1]

Please be aware that there is now the V4L2 multi-planar API which
returns the planes in independent buffers (and an independent dma_buf
fd for each plane). That is not the case being handled here.
If being a real pedant, then it wants to be "layer->planes[1].offset =
avbuf->plane_info[0].bytesperline *
avbuf->context->format.fmt.pix.height;" as this should be using the
single planar API union member. width and height align between the two
structures anyway.

If you want the buffer to be a multiple of macroblocks or have other
padding requirements, then the width and height are defined to be that
size. Use the selection API [2] to get the cropping window.

>> +layer->planes[1].pitch = avbuf->plane_info[0].bytesperline;
>> +break;
>> +
>> +case AV_PIX_FMT_YUV420P:
>> +
>> +if (avbuf->num_planes > 1)
>> +break;
>> +
>> +layer->format = DRM_FORMAT_YUV420;
>> +layer->nb_planes = 3;
>> +
>> +layer->planes[1].object_index = 0;
>> +layer->planes[1].offset = avbuf->plane_info[0].bytesperline *
>> +avbuf->context->format.fmt.pix_mp.height;
>> +layer->planes[1].pitch = avbuf->plane_info[0].bytesperline >> 1;
>> +
>> +layer->planes[2].object_index = 0;
>> +layer->planes[2].offset = layer->planes[1].offset +
>> +((avbuf->plane_info[0].bytesperline *
>> +  avbuf->context->format.fmt.pix_mp.height) >> 2);
>> +layer->planes[2].pitch = avbuf->plane_info[0].bytesperline >> 1;
>
> Similarly here, and the pitch feels dubious as well.  Is 
> plane_info[n].bytesperline set for n > 0?

Likewise the definition of YU12/YV12 is that the planes will follow
immediately [3]

Pass on plane_info[n] - I only know V4L2 in any depth.

>> +break;
>> +
>> +default:
>
> Probably want a more explicit failure in other cases.  Is there any 10-bit 
> handling here yet (P010, I guess)?

Based on a quick search I don't believe V4L2 has added support for any
10 bit formats as yet, therefore it would be strange to get here with
a 10bit format selected.

  Dave

[1] https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-nv12.html
[2] 
https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-g-selection.html#vidioc-g-selection
[3] https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-yuv420.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] About the future of component registration APIs

[Jan Ekström]

On Wed, May 9, 2018 at 3:38 PM, Yu Xiaolei  wrote:
> Hello,
> I noticed that commit 7e8eba2d87 deprecated avcodec_register and there was
> some disagreement on this issue. Will there be some sort of replacement for
> it?
>
> We want to build ffmpeg in a way that only the most frequently used
> components are shipped initially and others are downloaded on demand. This
> can be implemented for now with a custom link step but will be impossible
> if this API were removed.

Hi,

The problem was that the things in FFmpeg until then did not make it
actually possible to dynamically register external things. Not to
mention that there were internal symbols required to even create what
you were trying to register. In other words, it looked as if you could
add external things, but in reality you could not with the public
APIs.

The other alternative, where you just wanted to distribute internal
parts of FFmpeg separately, was not supported by the build system in
any other form than what Debian did. Namely, they built one shared
library with certain decoders and encoders disabled, and then another
version which was a replacement for the first one. And this is still
possible.

If you require proper separation of components within libraries, and
then their dynamic registration, that needs a proper public API
design. Currently there is no replacement for the function you
mention, while I am not sure what you could do with it and the
standard build system options.

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

Re: [FFmpeg-devel] [PATCH 2/5] avutil/hwcontext_cuda: add CUstream in cuda hwctx

[Timo Rothenpieler]

Am 09.05.2018 um 10:49 schrieb Timo Rothenpieler:

On 08.05.2018 23:00, James Almer wrote:

On 5/8/2018 3:36 PM, Timo Rothenpieler wrote:

---
  configure  | 6 --
  doc/APIchanges | 3 +++
  libavutil/hwcontext_cuda.c | 3 +++
  libavutil/hwcontext_cuda.h | 1 +
  libavutil/version.h| 2 +-
  5 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 6626111ff2..9743de05d0 100755
--- a/configure
+++ b/configure
@@ -5887,8 +5887,10 @@ check_type "va/va.h va/va_enc_vp9.h"  
"VAEncPictureParameterBufferVP9"
  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
  
  if ! disabled ffnvcodec; then

-check_pkg_config ffnvcodec "ffnvcodec >= 8.0.14.1" \
-"ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h 
ffnvcodec/dynlink_nvcuvid.h" ""
+check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.2" \
+  "ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h 
ffnvcodec/dynlink_nvcuvid.h" "" || \
+{ test_pkg_config ffnvcodec_tmp "ffnvcodec < 8.1" "" "" && check_pkg_config 
ffnvcodec "ffnvcodec >= 8.0.14.2" \
+  "ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h 
ffnvcodec/dynlink_nvcuvid.h" ""; }


ffnvcodec_tmp?


I haven't found a more elegant way to do this.
Basically, the version requirement is

ffnvcodec >= 8.1.24.2 || (ffnvcodec < 8.1 && ffnvcodec >= 8.0.14.2)

As < 8.1 would also match 8.0.14.1, it must not enable ffnvcodec, which
is why i appended the _tmp.

pkg-config does not seem able to evaluate such complex version checks,
and there is no lower level function than test_pkg_config.


I'd like to push the series, and this is the only thing holding it up.
Did I miss a better way to do this, or is it good to go?



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] help with ffmpeg in livevideo and recordings

[Radim Benovsky]

Hello ffmpeg development team, 

We are a international company that works with live TV and nPVR. We are 
currently working on one projects and got it to a little struggle with the 
settings of the ffmpeg. 

We would like to consult the live streams and it’s optimization with RAM / CPU 
on the Nvidia GPU. 

can you please direct us to the right person who might help?

I have included our development team who will be communicating from our side.  

thank you very much.






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

[FFmpeg-devel] [PATCH] mpegvideo_enc: add option to disable intra mbs in p frames

[Ramiro Polla]

This option prevents the mpv encoders from using intra macroblocks in
predictive frames.

It is useful for glitch artists to generate input material. This option
allows them to split and merge two video files while maintaining fluid
motion from the second video without having intra macroblocks restoring
chunks of the first video.
---
 libavcodec/motion_est.c| 4 ++--
 libavcodec/mpegvideo.h | 2 ++
 libavcodec/mpegvideo_enc.c | 5 +++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index 8b5ce2117a..827e2282f7 100644
--- a/libavcodec/motion_est.c
+++ b/libavcodec/motion_est.c
@@ -971,7 +971,7 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
 int i_score= varc-500+(s->lambda2>>FF_LAMBDA_SHIFT)*20;
 c->scene_change_score+= ff_sqrt(p_score) - ff_sqrt(i_score);
 
-if (vard*2 + 200*256 > varc)
+if (vard*2 + 200*256 > varc && !(s->mpv_flags & FF_MPV_FLAG_NOPIMB))
 mb_type|= CANDIDATE_MB_TYPE_INTRA;
 if (varc*2 + 200*256 > vard || s->qscale > 24){
 //if (varc*2 + 200*256 + 50*(s->lambda2>>FF_LAMBDA_SHIFT) > vard){
@@ -1042,7 +1042,7 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
 }
 intra_score += c->mb_penalty_factor*16;
 
-if(intra_score < dmin){
+if(intra_score < dmin && !(s->mpv_flags & FF_MPV_FLAG_NOPIMB)){
 mb_type= CANDIDATE_MB_TYPE_INTRA;
 s->current_picture.mb_type[mb_y*s->mb_stride + mb_x] = 
CANDIDATE_MB_TYPE_INTRA; //FIXME cleanup
 }else
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index e16deb64e7..b7ac2c7b48 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -586,6 +586,7 @@ typedef struct MpegEncContext {
 #define FF_MPV_FLAG_CBP_RD   0x0008
 #define FF_MPV_FLAG_NAQ  0x0010
 #define FF_MPV_FLAG_MV0  0x0020
+#define FF_MPV_FLAG_NOPIMB   0x0040
 
 #define FF_MPV_OPT_CMP_FUNC \
 { "sad","Sum of absolute differences, fast", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_CMP_SAD }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS, "cmp_func" }, \
@@ -617,6 +618,7 @@ FF_MPV_OPT_CMP_FUNC, \
 { "cbp_rd", "use rate distortion optimization for CBP",  0, 
AV_OPT_TYPE_CONST, { .i64 = FF_MPV_FLAG_CBP_RD }, 0, 0, FF_MPV_OPT_FLAGS, 
"mpv_flags" },\
 { "naq","normalize adaptive quantization",   0, 
AV_OPT_TYPE_CONST, { .i64 = FF_MPV_FLAG_NAQ },0, 0, FF_MPV_OPT_FLAGS, 
"mpv_flags" },\
 { "mv0","always try a mb with mv=<0,0>", 0, 
AV_OPT_TYPE_CONST, { .i64 = FF_MPV_FLAG_MV0 },0, 0, FF_MPV_OPT_FLAGS, 
"mpv_flags" },\
+{ "nopimb", "do not use intra mbs for predictive frames",0, 
AV_OPT_TYPE_CONST, { .i64 = FF_MPV_FLAG_NOPIMB }, 0, 0, FF_MPV_OPT_FLAGS, 
"mpv_flags" },\
 { "luma_elim_threshold",   "single coefficient elimination threshold for 
luminance (negative values also consider dc coefficient)",\
   
FF_MPV_OFFSET(luma_elim_threshold), AV_OPT_TYPE_INT, { .i64 = 0 }, INT_MIN, 
INT_MAX, FF_MPV_OPT_FLAGS },\
 { "chroma_elim_threshold", "single coefficient elimination threshold for 
chrominance (negative values also consider dc coefficient)",\
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 9fdab31a25..e41a8f40cf 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3752,6 +3752,7 @@ static int encode_picture(MpegEncContext *s, int 
picture_number)
 
 if(!s->umvplus){
 if(s->pict_type==AV_PICTURE_TYPE_P || s->pict_type==AV_PICTURE_TYPE_S) 
{
+int truncate = s->mpv_flags & FF_MPV_FLAG_NOPIMB;
 s->f_code= ff_get_best_fcode(s, s->p_mv_table, 
CANDIDATE_MB_TYPE_INTER);
 
 if (s->avctx->flags & AV_CODEC_FLAG_INTERLACED_ME) {
@@ -3762,13 +3763,13 @@ static int encode_picture(MpegEncContext *s, int 
picture_number)
 }
 
 ff_fix_long_p_mvs(s);
-ff_fix_long_mvs(s, NULL, 0, s->p_mv_table, s->f_code, 
CANDIDATE_MB_TYPE_INTER, 0);
+ff_fix_long_mvs(s, NULL, 0, s->p_mv_table, s->f_code, 
CANDIDATE_MB_TYPE_INTER, truncate);
 if (s->avctx->flags & AV_CODEC_FLAG_INTERLACED_ME) {
 int j;
 for(i=0; i<2; i++){
 for(j=0; j<2; j++)
 ff_fix_long_mvs(s, s->p_field_select_table[i], j,
-s->p_field_mv_table[i][j], s->f_code, 
CANDIDATE_MB_TYPE_INTER_I, 0);
+s->p_field_mv_table[i][j], s->f_code, 
CANDIDATE_MB_TYPE_INTER_I, truncate);
 }
 }
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/2] avformat/mpegts: reindent after last change

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavformat/mpegts.c | 70 ++--
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 3c9f9421cb..9c09819531 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -412,44 +412,44 @@ static void write_section_data(MpegTSContext *ts, 
MpegTSFilter *tss1,
 offset = 0;
 cur_section_buf = tss->section_buf;
 while (cur_section_buf - tss->section_buf < MAX_SECTION_SIZE && 
cur_section_buf[0] != 0xff) {
-/* compute section length if possible */
-if (tss->section_h_size == -1 && tss->section_index - offset >= 3) {
-len = (AV_RB16(cur_section_buf + 1) & 0xfff) + 3;
-if (len > MAX_SECTION_SIZE)
-return;
-tss->section_h_size = len;
-}
-
-if (tss->section_h_size != -1 &&
-tss->section_index >= offset + tss->section_h_size) {
-int crc_valid = 1;
-tss->end_of_section_reached = 1;
-
-if (tss->check_crc) {
-crc_valid = !av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1, 
cur_section_buf, tss->section_h_size);
-if (tss->section_h_size >= 4)
-tss->crc = AV_RB32(cur_section_buf + tss->section_h_size - 4);
+/* compute section length if possible */
+if (tss->section_h_size == -1 && tss->section_index - offset >= 3) {
+len = (AV_RB16(cur_section_buf + 1) & 0xfff) + 3;
+if (len > MAX_SECTION_SIZE)
+return;
+tss->section_h_size = len;
+}
 
+if (tss->section_h_size != -1 &&
+tss->section_index >= offset + tss->section_h_size) {
+int crc_valid = 1;
+tss->end_of_section_reached = 1;
+
+if (tss->check_crc) {
+crc_valid = !av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1, 
cur_section_buf, tss->section_h_size);
+if (tss->section_h_size >= 4)
+tss->crc = AV_RB32(cur_section_buf + tss->section_h_size - 
4);
+
+if (crc_valid) {
+ts->crc_validity[ tss1->pid ] = 100;
+}else if (ts->crc_validity[ tss1->pid ] > -10) {
+ts->crc_validity[ tss1->pid ]--;
+}else
+crc_valid = 2;
+}
 if (crc_valid) {
-ts->crc_validity[ tss1->pid ] = 100;
-}else if (ts->crc_validity[ tss1->pid ] > -10) {
-ts->crc_validity[ tss1->pid ]--;
-}else
-crc_valid = 2;
-}
-if (crc_valid) {
-tss->section_cb(tss1, cur_section_buf, tss->section_h_size);
-if (crc_valid != 1)
-tss->last_ver = -1;
-}
+tss->section_cb(tss1, cur_section_buf, tss->section_h_size);
+if (crc_valid != 1)
+tss->last_ver = -1;
+}
 
-cur_section_buf += tss->section_h_size;
-offset += tss->section_h_size;
-tss->section_h_size = -1;
-} else {
-tss->end_of_section_reached = 0;
-break;
-}
+cur_section_buf += tss->section_h_size;
+offset += tss->section_h_size;
+tss->section_h_size = -1;
+} else {
+tss->end_of_section_reached = 0;
+break;
+}
 }
 }
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/2] avformat/mpegts: parse sections with multiple tables

[Aman Gupta]

From: Aman Gupta 

Fixes PMT parsing in some mpegts streams which contain
multiple tables within the PMT pid. Previously, the parser
assumed only one table was present in each packet, and discarded
the rest of the section data after attempting to parse the first
table.

A similar issue was documented in the BeyondTV software[1], which
helped me diagnose the same bug in the ffmpeg mpegts demuxer. I also
tried DVBInspector, libdvbpsi's dvbinfo, and tstools' tsinfo to
help debug. The former two properly read PMTs with multiple tables,
whereas the last has the same bug as ffmpeg.

I've created a minimal sample[2] which contains the combined PMT.
Here's what ffmpeg probe shows before and after this patch:

Before:

Input #0, mpegts, from 'combined-pmt-tids.ts':
  Duration: 00:00:01.08, start: 4932.966167, bitrate: 741 kb/s
  Program 1
  No Program
Stream #0:0[0xf9d]: Audio: ac3, 48000 Hz, mono, fltp, 96 kb/s
Stream #0:1[0xf9b]: Audio: mp3, 0 channels, fltp
Stream #0:2[0xf9c]: Unknown: none

After:

Input #0, mpegts, from 'combined-pmt-tids.ts':
  Duration: 00:00:01.11, start: 4932.966167, bitrate: 718 kb/s
  Program 1
Stream #0:0[0xf9b]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv, 
top first), 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
Stream #0:1[0xf9c](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
5.1(side), fltp, 384 kb/s
Stream #0:2[0xf9d](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
mono, fltp, 96 kb/s

With the patch, the PMT is parsed correctly so the streams are
created in the correct order, are associated with "Program 1",
and their codecs are set correctly.

[1] http://forums.snapstream.com/vb/showpost.php?p=343816&postcount=201
[2] https://s3.amazonaws.com/tmm1/combined-pmt-tids.ts

Signed-off-by: Aman Gupta 
---
 libavformat/mpegts.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0d1dda1c36..3c9f9421cb 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -391,7 +391,8 @@ static void write_section_data(MpegTSContext *ts, 
MpegTSFilter *tss1,
const uint8_t *buf, int buf_size, int is_start)
 {
 MpegTSSectionFilter *tss = &tss1->u.section_filter;
-int len;
+uint8_t *cur_section_buf = NULL;
+int len, offset;
 
 if (is_start) {
 memcpy(tss->section_buf, buf, buf_size);
@@ -408,23 +409,26 @@ static void write_section_data(MpegTSContext *ts, 
MpegTSFilter *tss1,
 tss->section_index += len;
 }
 
+offset = 0;
+cur_section_buf = tss->section_buf;
+while (cur_section_buf - tss->section_buf < MAX_SECTION_SIZE && 
cur_section_buf[0] != 0xff) {
 /* compute section length if possible */
-if (tss->section_h_size == -1 && tss->section_index >= 3) {
-len = (AV_RB16(tss->section_buf + 1) & 0xfff) + 3;
+if (tss->section_h_size == -1 && tss->section_index - offset >= 3) {
+len = (AV_RB16(cur_section_buf + 1) & 0xfff) + 3;
 if (len > MAX_SECTION_SIZE)
 return;
 tss->section_h_size = len;
 }
 
 if (tss->section_h_size != -1 &&
-tss->section_index >= tss->section_h_size) {
+tss->section_index >= offset + tss->section_h_size) {
 int crc_valid = 1;
 tss->end_of_section_reached = 1;
 
 if (tss->check_crc) {
-crc_valid = !av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1, 
tss->section_buf, tss->section_h_size);
+crc_valid = !av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1, 
cur_section_buf, tss->section_h_size);
 if (tss->section_h_size >= 4)
-tss->crc = AV_RB32(tss->section_buf + tss->section_h_size - 4);
+tss->crc = AV_RB32(cur_section_buf + tss->section_h_size - 4);
 
 if (crc_valid) {
 ts->crc_validity[ tss1->pid ] = 100;
@@ -434,10 +438,18 @@ static void write_section_data(MpegTSContext *ts, 
MpegTSFilter *tss1,
 crc_valid = 2;
 }
 if (crc_valid) {
-tss->section_cb(tss1, tss->section_buf, tss->section_h_size);
+tss->section_cb(tss1, cur_section_buf, tss->section_h_size);
 if (crc_valid != 1)
 tss->last_ver = -1;
 }
+
+cur_section_buf += tss->section_h_size;
+offset += tss->section_h_size;
+tss->section_h_size = -1;
+} else {
+tss->end_of_section_reached = 0;
+break;
+}
 }
 }
 
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 6/6] fate/cbs: Add an SEI test

[James Almer]

On 5/7/2018 9:30 PM, Mark Thompson wrote:
> On 08/05/18 01:06, James Almer wrote:
>> On 5/7/2018 8:11 PM, Mark Thompson wrote:
>>> The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
>>> and the following SEI message types:
>>> * Buffering period
>>> * Picture timing
>>> * Pan-scan rectangle (display as 4:3)
>>> * User data registered, containing A/53 closed captions (captions match
>>>   frame content, including reordering)
>>> * Recovery point (at the I frame)
>>> * Display orientation (identity transformation)
>>> * Mastering display (with arbitrary contents)
>>> * Undefined SEI type 1234 (containing ascending bytes)
>>> ---
>>> Sample file at .  (Named -1 
>>> anticipating the possibility of adding more in future.)
>>>
>>> 140ddba635960ac73935a0fb268748a43c647151  fate/h264/sei-1.h264
>>
>> If you crafted this file using the mastering display implementation from
>> patch 5/6 then you may need to create it again with the fixed element sizes.
> 
> It didn't change because the numbers I had there were < 2^16, but I've 
> regenerated anyway with a larger number as max so that it does get tested.
> 
> b8f3b5443c8e437a83d36a72657478529c2afcfc  fate/h264/sei-1.h264

Uploaded then.

> 
>>>
>>>
>>>  tests/fate/cbs.mak | 8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
>>> index bee349ed45..911e7704aa 100644
>>> --- a/tests/fate/cbs.mak
>>> +++ b/tests/fate/cbs.mak
>>> @@ -14,7 +14,7 @@ endef
>>>  
>>>  # H.264 read/write
>>>  
>>> -FATE_CBS_H264_SAMPLES =   \
>>> +FATE_CBS_H264_CONFORMANCE_SAMPLES = \
>>>  SVA_Base_B.264\
>>>  BASQP1_Sony_C.jsv \
>>>  FM1_BT_B.h264 \
>>> @@ -30,7 +30,11 @@ FATE_CBS_H264_SAMPLES =   \
>>>  CVSE2_Sony_B.jsv  \
>>>  CABACI3_Sony_B.jsv
>>>  
>>> -$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
>>> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
>>> +FATE_CBS_H264_SAMPLES = \
>>> +sei-1.h264
>>> +
>>> +$(foreach N,$(FATE_CBS_H264_CONFORMANCE_SAMPLES),$(eval $(call 
>>> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
>>> +$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
>>> FATE_CBS_TEST,h264,$(basename $(N)),h264/$(N),h264)))
>>
>> Missing ref files? Or it doesn't generate them?
> 
> Missed, sorry:
> 
> diff --git a/tests/ref/fate/cbs-h264-sei-1 b/tests/ref/fate/cbs-h264-sei-1
> new file mode 100644
> index 00..2d1cb1fe7f
> --- /dev/null
> +++ b/tests/ref/fate/cbs-h264-sei-1
> @@ -0,0 +1 @@
> +5f537551b7dfab76a172f1aebb028986
> 
>>>  
>>>  FATE_CBS_H264-$(call FATE_CBS_DEPS, H264, H264, H264, H264, H264) = 
>>> $(FATE_CBS_h264)
>>>  FATE_SAMPLES_AVCONV += $(FATE_CBS_H264-yes)
>>>
> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH 2/6] avcodec/nvdec: avoid needless copy of output frame

[Timo Rothenpieler]

applied
follow-up CUstream patches also applied



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

[Timo Rothenpieler]

dropped this one.
Missed I could just override the pool.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Jorge Ramirez-Ortiz]

On 05/09/2018 04:11 PM, Mark Thompson wrote:

On 09/05/18 08:57, Jorge Ramirez-Ortiz wrote:

On 05/09/2018 01:33 AM, Mark Thompson wrote:

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index ed5193ecc1..2b33badb08 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -23,12 +23,18 @@
     #include 
   #include 
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_drm.h"
   #include "libavutil/pixfmt.h"
   #include "libavutil/pixdesc.h"
   #include "libavutil/opt.h"
   #include "libavcodec/avcodec.h"
   #include "libavcodec/decode.h"
   +#include "libavcodec/hwaccel.h"
+#include "libavcodec/internal.h"
+
   #include "v4l2_context.h"
   #include "v4l2_m2m.h"
   #include "v4l2_fmt.h"
@@ -183,6 +189,15 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
   capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
   capture->av_pix_fmt = avctx->pix_fmt;
   +    /* the client requests the codec to generate DRM frames:
+ *   - data[0] will therefore point to the returned AVDRMFrameDescriptor
+ *   check the ff_v4l2_buffer_to_avframe conversion function.
+ *   - the DRM frame format is passed in the DRM frame descriptor layer.
+ *   check the v4l2_get_drm_frame function.
+ */
+    if (avctx->pix_fmt == AV_PIX_FMT_DRM_PRIME)
+    s->output_drm = 1;
+
   ret = ff_v4l2_m2m_codec_init(avctx);
   if (ret) {
   av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");
@@ -202,6 +217,11 @@ static const AVOption options[] = {
   { NULL},
   };

As a follow up to your comment on pixel format negotiation 
(AvCodecContext.getformat), notice that this is a tentative request from the 
user to select a pixel format.
The actual pixel format negotiation - where the decoder will select the pixel 
format- will happen later during v4l2_try_start.

Indeed.  get_format() will have to be called during the pixel format 
negotiation so that the user can pick between whatever the supported software 
format is (NV12, NV21, YUV420P P010, whatever) or the DRM-PRIME object hardware 
format (if supported).


but in the use case that we are trying to implement, it is the user - 
not the codec - the one that has to specifically request DRM support to 
libavcodec since the v4l2m2m decoder can provide either of them 
indistinctly.


it is just not clear to me how the libavcodec client can request the DRM 
pix_fmt if not tentatively setting the pix_fmt during v4l2_decode_init.





AVCodecContext.pix_fmt is intended to be set by the decoder to say what pix_fmt 
it intends to produce (though even in that role it's highly dubious given 
threaded decoders and stream changes).  For historical reasons it is also 
allowed to be set externally (because of libavformat interactions), but this 
shouldn't be used for configuration.


This change enables the v4l2m2m decoder to output either dmabuf descriptors to 
be consumed by a DRM or video frame formats to be consumed by SDL (for 
instance).
As an example, these changes have been tested with ffplay (SDL based display) 
and a simple DRM application [1]

Lukas tested with other tools.

[1]https://github.com/baylibre/ffmpeg-drm

We should make this usable in the ffmpeg application too.  The DRM object 
format is works fine in ffmpeg already with Rockchip decoder (consumed by the 
hwmap/hwdownload filters, or by mapping to OpenCL), but that doesn't need the 
format selection part.  (There are also kmsgrab and VAAPI, but those aren't 
making DRM PRIME frames directly at a decoder.)  I believe this should be 
straightforward with a small modification to get_format() in ffmpeg.c to accept 
AV_CODEC_HW_CONFIG_METHOD_INTERNAL, I can look at this once we have a codec 
which will need it.


so what would be the sequence of calls for an libavcodec client to 
request the DRM format?

https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c#L598





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


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] checkasm: add vf_nlmeans test for ssd_integral_image

[Michael Niedermayer]

On Tue, May 08, 2018 at 08:29:00AM +, Clément Bœsch wrote:
> ffmpeg | branch: master | Clément Bœsch  | Sun May  6 10:57:23 
> 2018 +0200| [f679711c1b516786a39f9e582622a200502fff74] | committer: Clément 
> Bœsch
> 
> checkasm: add vf_nlmeans test for ssd_integral_image
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=f679711c1b516786a39f9e582622a200502fff74
> ---
> 
>  tests/checkasm/Makefile |   1 +
>  tests/checkasm/checkasm.c   |   3 ++
>  tests/checkasm/checkasm.h   |   1 +
>  tests/checkasm/vf_nlmeans.c | 113 
> 
>  4 files changed, 118 insertions(+)

This causes
tests/checkasm/checkasm
to crash
(make fate does not crash)

tell me if you cant reproduce it then ill rebuild and get a proper backtrace & 
valgrind

only got this ATM:
checkasm: using random seed 1025639728
*** buffer overflow detected ***: tests/checkasm/checkasm terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7fe82d5de29f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fe82d67987c]
/lib/x86_64-linux-gnu/libc.so.6(+0x10d750)[0x7fe82d678750]
tests/checkasm/checkasm[0x4c36c7]
tests/checkasm/checkasm[0x4a1774]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fe82d58cf45]
tests/checkasm/checkasm[0x4a1923]


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

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH v3] avformat/mxfenc: add h264 profiles

[Michael Niedermayer]

On Tue, May 08, 2018 at 06:32:12PM +0200, Thomas Mundt wrote:
> 2018-05-07 10:40 GMT+02:00 Tomas Härdin :
> 
> > sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> > > 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
> > >
> > > > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > > > Hi,
> > > > >
> > > > > this is a better version of the patch.
> > > > > 10 bit and TFF are mandatory for AVC Intra only. Other profiles
> > > > > differ.
> > > > >
> > > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > > index 3bb7032..81513dc 100644
> > > > > --- a/libavformat/mxfenc.c
> > > > > +++ b/libavformat/mxfenc.c
> > > > > @@ -1947,22 +1947,31 @@ static const struct {
> > > > >  int frame_size;
> > > > >  int profile;
> > > > >  uint8_t interlaced;
> > > > > +int long_gop;
> > > >
> > > > A comment here explaining the difference between -1, 0 and 1 would
> > > > be
> > > > nice. The rest looks OK, but I didn't read the relevant specs to be
> > > > 100% sure
> > > > 
> > > >
> > >
> > > New patch attached.
> >
> > Looks OK
> 
> 
> Thanks,
> 
> can you or someone else push it please.

will apply

thx

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

Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Michael Niedermayer]

On Wed, May 09, 2018 at 10:19:26AM +0200, Łukasz Krzciuk wrote:
> Any updates on this issue?

about adding a testcase ?
adding a huge sample file is not possible.
It either has to be made smaller or generated by a muxer
or last resort, no test

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: Fix scaling lists

[Philip Langdale]

The main issue here was the use of [i] instead of [i * 3] for the 32x32
matrix. As part of fixing this, I changed the code to match that used
in vdpau_hevc, which I spent a lot of time verifying.

I also changed to calculating NumPocTotalCurr using the existing helper,
which is what vdpau does.
---
 libavcodec/nvdec_hevc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index 008963130b..e04a701f3a 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -58,12 +58,13 @@ static void fill_scaling_lists(CUVIDHEVCPICPARAMS *ppc, 
const HEVCContext *s)
 ppc->ScalingList16x16[i][j] = sl->sl[2][i][pos];
 
 if (i < 2)
-ppc->ScalingList32x32[i][j] = sl->sl[3][i][pos];
+ppc->ScalingList32x32[i][j] = sl->sl[3][i * 3][pos];
 }
-}
 
-memcpy(ppc->ScalingListDCCoeff16x16, sl->sl_dc[0], 
sizeof(ppc->ScalingListDCCoeff16x16));
-memcpy(ppc->ScalingListDCCoeff32x32, sl->sl_dc[1], 
sizeof(ppc->ScalingListDCCoeff32x32));
+ppc->ScalingListDCCoeff16x16[i] = sl->sl_dc[0][i];
+if (i < 2)
+ppc->ScalingListDCCoeff32x32[i] = sl->sl_dc[1][i * 3];
+}
 }
 
 static int nvdec_hevc_start_frame(AVCodecContext *avctx,
@@ -166,8 +167,7 @@ static int nvdec_hevc_start_frame(AVCodecContext *avctx,
 
 .NumBitsForShortTermRPSInSlice= 
s->sh.short_term_rps ? s->sh.short_term_ref_pic_set_size : 0,
 .NumDeltaPocsOfRefRpsIdx  = 
s->sh.short_term_rps ? s->sh.short_term_rps->rps_idx_num_delta_pocs : 0,
-.NumPocTotalCurr  = 
s->rps[ST_CURR_BEF].nb_refs + s->rps[ST_CURR_AFT].nb_refs +
-
s->rps[LT_CURR].nb_refs,
+.NumPocTotalCurr  = 
ff_hevc_frame_nb_refs(s),
 .NumPocStCurrBefore   = 
s->rps[ST_CURR_BEF].nb_refs,
 .NumPocStCurrAfter= 
s->rps[ST_CURR_AFT].nb_refs,
 .NumPocLtCurr = 
s->rps[LT_CURR].nb_refs,
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/2] avformat/mpegtsenc: set AVFMT_NODIMENSIONS

[Aman Gupta]

From: Aman Gupta 

This allows remuxing streams from one mpegts container to another,
without requiring avformat_find_stream_info() (or using `ffmpeg
-probesize 32` on the cli).
---
 libavformat/mpegtsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 8b0736ac4e..3339e26d50 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1983,6 +1983,6 @@ AVOutputFormat ff_mpegts_muxer = {
 .write_trailer  = mpegts_write_end,
 .deinit = mpegts_deinit,
 .check_bitstream = mpegts_check_bitstream,
-.flags  = AVFMT_ALLOW_FLUSH | AVFMT_VARIABLE_FPS,
+.flags  = AVFMT_ALLOW_FLUSH | AVFMT_VARIABLE_FPS | 
AVFMT_NODIMENSIONS,
 .priv_class = &mpegts_muxer_class,
 };
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: set AVFMT_NODIMENSIONS

[Aman Gupta]

From: Aman Gupta 

Same as previous commit but for mpegts inside HLS.
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c27a66ea79..9c06551ea6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2875,7 +2875,7 @@ AVOutputFormat ff_hls_muxer = {
 .audio_codec= AV_CODEC_ID_AAC,
 .video_codec= AV_CODEC_ID_H264,
 .subtitle_codec = AV_CODEC_ID_WEBVTT,
-.flags  = AVFMT_NOFILE | AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH,
+.flags  = AVFMT_NOFILE | AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH | 
AVFMT_NODIMENSIONS,
 .init   = hls_init,
 .write_header   = hls_write_header,
 .write_packet   = hls_write_packet,
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode: Initialize the pointer

[Xiang, Haihao]

On Wed, 2018-05-09 at 14:48 +0100, Mark Thompson wrote:
> On 09/05/18 05:29, Xiang, Haihao wrote:
> > On Tue, 2018-05-08 at 22:34 +0100, Mark Thompson wrote:
> > > On 08/05/18 03:35, Xiang, Haihao wrote:
> > > > On Mon, 2018-05-07 at 21:46 +0100, Mark Thompson wrote:
> > > > > On 04/05/18 15:41, Haihao Xiang wrote:
> > > > > > Otherwise it might use unitialized last_pic in av_assert0(last_pic)
> > > > > > 
> > > > > > Signed-off-by: Haihao Xiang 
> > > > > > ---
> > > > > >  libavcodec/vaapi_encode.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > > > index 36c85a3815..141e50c8ad 100644
> > > > > > --- a/libavcodec/vaapi_encode.c
> > > > > > +++ b/libavcodec/vaapi_encode.c
> > > > > > @@ -760,7 +760,7 @@ fail:
> > > > > >  static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
> > > > > >  {
> > > > > >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > > > -VAAPIEncodePicture *pic, *last_pic, *next;
> > > > > > +VAAPIEncodePicture *pic, *last_pic = NULL, *next;
> > > > > >  
> > > > > >  // Find the last picture we actually have input for.
> > > > > >  for (pic = ctx->pic_start; pic; pic = pic->next) {
> > > > > > 
> > > > > 
> > > > > How do you hit this?  last_pic should always get set.
> > > > > 
> > > > 
> > > > It was reported by some static analysis tools, but I agree with you that
> > > > last_pic should get set in the code path, however if we consider
> > > > vaapi_encode_truncate_gop() only,  last_pic will be uninitialized if
> > > > ctx-
> > > > > pic_start is non-NULL but ctx->pic_start->input_available is not set.
> > > > > How
> > > > > about
> > > > 
> > > > to add av_assert0(!ctx->pic_start || ctx->pic_start->input_available)
> > > > before
> > > > the
> > > >  for () statement and remove av_assert0(last_pic)?
> > > 
> > > I think you mean "av_assert0(ctx->pic_start && ctx->pic_start-
> > > > input_available)"?
> > 
> > No. I meant "av_assert0(!ctx->pic_start || ctx->pic_start-
> > >input_available)". I
> > thought ctx->pic_start might be NULL when vaapi_encode_truncate_gop() is
> > called
> > in vaapi_encode.c, line 865. 
> 
> Apologies, you are correct.  

Never mind.

> I was thinking of the test in the wrong place.
> 
> > However testing a simple transcode of H265 showed input_image->pict_type is
> > always AV_PICTURE_TYPE_NONE (a bug?), which means
> > vaapi_encode_truncate_gop() in
> > vaapi_encode.c, line 865 is never called. This piece of code was added in
> > commit
> > c667c0979cbc2e04d1d00964b82ac49746caa43c to support forcing IDR frame. How
> > do I
> > set a forced IDR via AVFrame.pict_type?
> 
> The setting of pict_type on encoders is intended for library users to force
> key frames where required by other constraints (e.g. when stream
> synchronisation is lost in a videoconferencing-type setup).  Usually an
> encoder has free choice of what GOP structure to use and where to place key
> frames, and this is only used in specific setups requiring it.
> 
> Given that, the ffmpeg utility doesn't set any frame types by default.  For
> testing with it you can override the key frame behaviour with the
> -force_key_frames option, which sets an expression for frames to force as key
> frames by the pict_type mechanism, or you could write a program using
> libavcodec which sets them directly.
> 

Thanks for your explanation, I confirmed pic->start can be NULL when using
-force_key_frame option.

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

Re: [FFmpeg-devel] [PATCH 2/6] avcodec/nvdec: avoid needless copy of output frame

[Wang Bin]

>
>
>
> -offset += cpy.Height;
> +frame->buf[1] = av_buffer_create((uint8_t *)unmap_data,
> sizeof(*unmap_data),
> + nvdec_unmap_mapped_frame,
> (void*)devptr,
> + AV_BUFFER_FLAG_READONLY);
> +if (!frame->buf[1]) {
> +ret = AVERROR(ENOMEM);
> +goto copy_fail;
>  }
>
>
If AVFrame.buf[i] is non-NULL, then buf[j] must be non-NULL for all j < i,
see libavutil/frame.h. So either change the comment in frame.h or change
your implementation is required
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] hwcontext_vaapi: Add an assert in vaapi_map_from_drm()

[Haihao Xiang]

Every fourcc in vaapi_drm_format_map should be in
vaapi_format_map, so add an assert to ensure we have the right maps.

Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_vaapi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 7daaa951cc..e55bb8db3f 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1028,6 +1028,8 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, 
AVFrame *dst,
 va_rt_format = vaapi_format_map[i].rt_format;
 }
 
+av_assert0(i < FF_ARRAY_ELEMS(vaapi_format_map));
+
 buffer_handle = desc->objects[0].fd;
 buffer_desc.pixel_format = va_fourcc;
 buffer_desc.width= src_fc->width;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/2] vaapi_encode: Add an assert in vaapi_encode_truncate_gop()

[Haihao Xiang]

The flag of input_available must be set when pic_start is not NULL, so
add an assert to ensure it is true. In addition, the assert on last_pic
is unnecessary now, so remove this assert.

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 36c85a3815..910fd1b365 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -762,6 +762,8 @@ static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodePicture *pic, *last_pic, *next;
 
+av_assert0(!ctx->pic_start || ctx->pic_start->input_available);
+
 // Find the last picture we actually have input for.
 for (pic = ctx->pic_start; pic; pic = pic->next) {
 if (!pic->input_available)
@@ -770,8 +772,6 @@ static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
 }
 
 if (pic) {
-av_assert0(last_pic);
-
 if (last_pic->type == PICTURE_TYPE_B) {
 // Some fixing up is required.  Change the type of this
 // picture to P, then modify preceding B references which
-- 
2.17.0

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

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

[Xiang, Haihao]

On Wed, 2018-05-09 at 14:53 +0100, Mark Thompson wrote:
> On 09/05/18 05:48, Xiang, Haihao wrote:
> > On Tue, 2018-05-08 at 22:51 +0100, Mark Thompson wrote:
> > > On 08/05/18 04:54, Xiang, Haihao wrote:
> > > > On Mon, 2018-05-07 at 22:03 +0100, Mark Thompson wrote:
> > > > > On 04/05/18 09:54, Xiang, Haihao wrote:
> > > > > > On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
> > > > > > > On 03/05/18 04:07, Haihao Xiang wrote:
> > > > > > > > '-sei xxx' is added to control SEI insertion, so far only
> > > > > > > > mastering
> > > > > > > > display colour colume is available for testing.
> > > > > > > 
> > > > > > > Typo: "colume" (also in the commit title).
> > > > > > > 
> > > > > > 
> > > > > > Thanks for catching the typo, I will correct it in the new version
> > > > > > of
> > > > > > patch.
> > > > > > 
> > > > > > > > v2: use the mastering display parameters from
> > > > > > > > AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to
> > > > > > > > match
> > > > > > > > the H.264 part and take VAAPIEncodeH265Context::sei_needed as a
> > > > > > > > ORed
> > > > > > > > value so that we needn't check the correspoding SEI message
> > > > > > > > again
> > > > > > > > when
> > > > > > > > writting the header.
> > > > > > > > 
> > > > > > > > Signed-off-by: Haihao Xiang 
> > > > > > > > ---
> > > > > > > >  libavcodec/vaapi_encode_h265.c | 128
> > > > > > > > -
> > > > > > > >  1 file changed, 127 insertions(+), 1 deletion(-)
> > > > > > > > 
> > > > > > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > > > > > b/libavcodec/vaapi_encode_h265.c
> > > > > > > > index 5203c6871d..326fe4fe66 100644
> > > > > > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > > > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > > > > > @@ -24,15 +24,20 @@
> > > > > > > >  #include "libavutil/avassert.h"
> > > > > > > >  #include "libavutil/common.h"
> > > > > > > >  #include "libavutil/opt.h"
> > > > > > > > +#include "libavutil/mastering_display_metadata.h"
> > > > > > > >  
> > > > > > > >  #include "avcodec.h"
> > > > > > > >  #include "cbs.h"
> > > > > > > >  #include "cbs_h265.h"
> > > > > > > >  #include "hevc.h"
> > > > > > > > +#include "hevc_sei.h"
> > > > > > > >  #include "internal.h"
> > > > > > > >  #include "put_bits.h"
> > > > > > > >  #include "vaapi_encode.h"
> > > > > > > >  
> > > > > > > > +enum {
> > > > > > > > +SEI_MASTERING_DISPLAY   = 0x08,
> > > > > > > > +};
> > > > > > > >  
> > > > > > > >  typedef struct VAAPIEncodeH265Context {
> > > > > > > >  unsigned int ctu_width;
> > > > > > > > @@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
> > > > > > > >  H265RawSPS sps;
> > > > > > > >  H265RawPPS pps;
> > > > > > > >  H265RawSlice slice;
> > > > > > > > +H265RawSEI sei;
> > > > > > > > +
> > > > > > > > +H265RawSEIMasteringDiplayColourVolume mastering_display;
> > > > > > > >  
> > > > > > > >  int64_t last_idr_frame;
> > > > > > > >  int pic_order_cnt;
> > > > > > > > @@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
> > > > > > > >  CodedBitstreamContext *cbc;
> > > > > > > >  CodedBitstreamFragment current_access_unit;
> > > > > > > >  int aud_needed;
> > > > > > > > +int sei_needed;
> > > > > > > >  } VAAPIEncodeH265Context;
> > > > > > > >  
> > > > > > > >  typedef struct VAAPIEncodeH265Options {
> > > > > > > > @@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
> > > > > > > >  int aud;
> > > > > > > >  int profile;
> > > > > > > >  int level;
> > > > > > > > +int sei;
> > > > > > > >  } VAAPIEncodeH265Options;
> > > > > > > >  
> > > > > > > >  
> > > > > > > > @@ -175,6 +185,64 @@ fail:
> > > > > > > >  return err;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > +static int vaapi_encode_h265_write_extra_header(AVCodecContext
> > > > > > > > *avctx,
> > > > > > > > +VAAPIEncodePict
> > > > > > > > ure
> > > > > > > > *pic,
> > > > > > > > +int index, int
> > > > > > > > *type,
> > > > > > > > +char *data,
> > > > > > > > size_t
> > > > > > > > *data_len)
> > > > > > > > +{
> > > > > > > > +VAAPIEncodeContext  *ctx = avctx->priv_data;
> > > > > > > > +VAAPIEncodeH265Context *priv = ctx->priv_data;
> > > > > > > > +CodedBitstreamFragment   *au = &priv->current_access_unit;
> > > > > > > > +int err, i;
> > > > > > > > +
> > > > > > > > +if (priv->sei_needed) {
> > > > > > > > +if (priv->aud_needed) {
> > > > > > > > +err = vaapi_encode_h265_add_nal(avctx, au, &priv-
> > > > > > > > >aud);
> > > > > > > > +if (err < 0)
> > > > > > > > +goto fail;
> > > > > > > > +priv->aud_needed = 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +memset(&priv->sei, 0, sizeof(priv->sei));
> > > > > > > 

[FFmpeg-devel] [PATCH v3 1/4] cbs_h265: read/write HEVC PREFIX SEI

[Haihao Xiang]

Similar to H264, cbs_h265_{read, write}_nal_unit() can handle HEVC
prefix SEI NAL units. Currently mastering display colour volume SEI
message is added only, we may add more SEI message if needed later

v2: Fix coding style and rebase the code

v3: Fix assertion failure when running the command below:
ffmpeg -i input-with-sei.mkv -c:v copy -bsf:v trace_headers -f null -
Fix the ranges for max_display_mastering_luminance and 
min_display_mastering_luminance

Signed-off-by: Haihao Xiang 
---
 libavcodec/cbs_h2645.c|  45 ++
 libavcodec/cbs_h265.h |  36 
 libavcodec/cbs_h265_syntax_template.c | 158 ++
 3 files changed, 239 insertions(+)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 1ce42c6950..dd13d8ab5f 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -29,6 +29,7 @@
 #include "h264_sei.h"
 #include "h2645_parse.h"
 #include "hevc.h"
+#include "hevc_sei.h"
 
 
 static int cbs_read_ue_golomb(CodedBitstreamContext *ctx, GetBitContext *gbc,
@@ -483,6 +484,26 @@ static void cbs_h265_free_slice(void *unit, uint8_t 
*content)
 av_freep(&content);
 }
 
+static void cbs_h265_free_sei_payload(H265RawSEIPayload *payload)
+{
+switch (payload->payload_type) {
+case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
+break;
+default:
+av_buffer_unref(&payload->payload.other.data_ref);
+break;
+}
+}
+
+static void cbs_h265_free_sei(void *unit, uint8_t *content)
+{
+H265RawSEI *sei = (H265RawSEI*)content;
+int i;
+for (i = 0; i < sei->payload_count; i++)
+cbs_h265_free_sei_payload(&sei->payload[i]);
+av_freep(&content);
+}
+
 static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
const H2645Packet *packet)
@@ -986,6 +1007,21 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_SEI_PREFIX:
+{
+err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H265RawSEI),
+&cbs_h265_free_sei);
+
+if (err < 0)
+return err;
+
+err = cbs_h265_read_sei(ctx, &gbc, unit->content);
+
+if (err < 0)
+return err;
+}
+break;
+
 default:
 return AVERROR(ENOSYS);
 }
@@ -1226,6 +1262,15 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_SEI_PREFIX:
+{
+err = cbs_h265_write_sei(ctx, pbc, unit->content);
+
+if (err < 0)
+return err;
+}
+break;
+
 default:
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Write unimplemented for "
"NAL unit type %"PRIu32".\n", unit->type);
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index 6d02979a17..b5715aed03 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -25,6 +25,14 @@
 #include "cbs_h2645.h"
 #include "hevc.h"
 
+enum {
+// This limit is arbitrary - it is sufficient for one message of each
+// type plus some repeats, and will therefore easily cover all sane
+// streams.  However, it is possible to make technically-valid streams
+// for which it will fail (for example, by including a large number of
+// user-data-unregistered messages).
+H265_MAX_SEI_PAYLOADS = 64,
+};
 
 typedef struct H265RawNALUnitHeader {
 uint8_t forbidden_zero_bit;
@@ -516,6 +524,34 @@ typedef struct H265RawSlice {
 AVBufferRef *data_ref;
 } H265RawSlice;
 
+typedef struct H265RawSEIMasteringDiplayColourVolume {
+uint16_t display_primaries_x[3];
+uint16_t display_primaries_y[3];
+uint16_t white_point_x;
+uint16_t white_point_y;
+uint32_t max_display_mastering_luminance;
+uint32_t min_display_mastering_luminance;
+} H265RawSEIMasteringDiplayColourVolume;
+
+typedef struct H265RawSEIPayload {
+uint32_t payload_type;
+uint32_t payload_size;
+union {
+H265RawSEIMasteringDiplayColourVolume mastering_display;
+struct {
+uint8_t *data;
+size_t data_length;
+AVBufferRef *data_ref;
+} other;
+} payload;
+} H265RawSEIPayload;
+
+typedef struct H265RawSEI {
+H265RawNALUnitHeader nal_unit_header;
+
+H265RawSEIPayload payload[H265_MAX_SEI_PAYLOADS];
+uint8_t payload_count;
+} H265RawSEI;
 
 typedef struct CodedBitstreamH265Context {
 // Reader/writer context in common with the H.264 implementation.
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 9f13061f38..593b6afd10 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1504,3 +1504,161 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
 
 return 0;

[FFmpeg-devel] [PATCH v3 3/4] cbs_h265: read/write content light level information SEI message

[Haihao Xiang]

Signed-off-by: Haihao Xiang 
---
 libavcodec/cbs_h2645.c|  1 +
 libavcodec/cbs_h265.h |  6 ++
 libavcodec/cbs_h265_syntax_template.c | 17 +
 3 files changed, 24 insertions(+)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index dd13d8ab5f..54f7e93755 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -488,6 +488,7 @@ static void cbs_h265_free_sei_payload(H265RawSEIPayload 
*payload)
 {
 switch (payload->payload_type) {
 case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
+case HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
 break;
 default:
 av_buffer_unref(&payload->payload.other.data_ref);
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index b5715aed03..46d28dd2ec 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -533,11 +533,17 @@ typedef struct H265RawSEIMasteringDiplayColourVolume {
 uint32_t min_display_mastering_luminance;
 } H265RawSEIMasteringDiplayColourVolume;
 
+typedef struct H265RawSEIContentLightLevelInfo {
+uint16_t max_content_light_level;
+uint16_t max_pic_average_light_level;
+} H265RawSEIContentLightLevelInfo;
+
 typedef struct H265RawSEIPayload {
 uint32_t payload_type;
 uint32_t payload_size;
 union {
 H265RawSEIMasteringDiplayColourVolume mastering_display;
+H265RawSEIContentLightLevelInfo content_light_level;
 struct {
 uint8_t *data;
 size_t data_length;
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 593b6afd10..9b39201e39 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1526,6 +1526,17 @@ static int 
FUNC(sei_mastering_display)(CodedBitstreamContext *ctx, RWContext *rw
 return 0;
 }
 
+static int FUNC(sei_content_light_level)(CodedBitstreamContext *ctx, RWContext 
*rw,
+ H265RawSEIContentLightLevelInfo 
*current)
+{
+int err;
+
+u(16, max_content_light_level, 0, MAX_UINT_BITS(16));
+u(16, max_pic_average_light_level, 0, MAX_UINT_BITS(16));
+
+return 0;
+}
+
 static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
  H265RawSEIPayload *current)
 {
@@ -1545,6 +1556,12 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 
 break;
 
+case HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
+CHECK(FUNC(sei_content_light_level)
+  (ctx, rw, ¤t->payload.content_light_level));
+
+break;
+
 default:
 {
 #ifdef READ
-- 
2.14.1

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

[FFmpeg-devel] [PATCH v3 4/4] vaapi_encode_h265: Insert content light level information

[Haihao Xiang]

v2: clip the value to 16bits and look for the metadata on I/IDR frame

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode_h265.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 4ff569c21f..b6ce12d320 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -37,6 +37,7 @@
 
 enum {
 SEI_MASTERING_DISPLAY   = 0x08,
+SEI_CONTENT_LIGHT_LEVEL = 0x10,
 };
 
 typedef struct VAAPIEncodeH265Context {
@@ -55,6 +56,7 @@ typedef struct VAAPIEncodeH265Context {
 H265RawSEI sei;
 
 H265RawSEIMasteringDiplayColourVolume mastering_display;
+H265RawSEIContentLightLevelInfo content_light_level;
 
 int64_t last_idr_frame;
 int pic_order_cnt;
@@ -218,6 +220,12 @@ static int 
vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
 ++i;
 }
 
+if (priv->sei_needed & SEI_CONTENT_LIGHT_LEVEL) {
+priv->sei.payload[i].payload_type = 
HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO;
+priv->sei.payload[i].payload.content_light_level = 
priv->content_light_level;
+++i;
+}
+
 priv->sei.payload_count = i;
 av_assert0(priv->sei.payload_count > 0);
 
@@ -706,6 +714,25 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 }
 }
 
+if ((opt->sei & SEI_CONTENT_LIGHT_LEVEL) &&
+(pic->type == PICTURE_TYPE_I || pic->type == PICTURE_TYPE_IDR)) {
+AVFrameSideData *sd =
+av_frame_get_side_data(pic->input_image,
+   AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+
+if (sd) {
+AVContentLightMetadata *clm =
+(AVContentLightMetadata *)sd->data;
+
+priv->content_light_level.max_content_light_level =
+FFMIN(clm->MaxCLL, 65535);
+priv->content_light_level.max_pic_average_light_level =
+FFMIN(clm->MaxFALL, 65535);
+
+priv->sei_needed |= SEI_CONTENT_LIGHT_LEVEL;
+}
+}
+
 vpic->decoded_curr_pic = (VAPictureHEVC) {
 .picture_id= pic->recon_surface,
 .pic_order_cnt = priv->pic_order_cnt,
@@ -1127,10 +1154,13 @@ static const AVOption vaapi_encode_h265_options[] = {
 
 { "sei", "Set SEI to include",
   OFFSET(sei), AV_OPT_TYPE_FLAGS,
-  { .i64 = SEI_MASTERING_DISPLAY },
+  { .i64 = SEI_MASTERING_DISPLAY | SEI_CONTENT_LIGHT_LEVEL },
   0, INT_MAX, FLAGS, "sei" },
-{ "hdr", "Include HDR metadata for mastering display colour volume",
-  0, AV_OPT_TYPE_CONST, { .i64 = SEI_MASTERING_DISPLAY },
+{ "hdr",
+  "Include HDR metadata for mastering display colour volume "
+  "and content light level information",
+  0, AV_OPT_TYPE_CONST,
+  { .i64 = SEI_MASTERING_DISPLAY | SEI_CONTENT_LIGHT_LEVEL },
   INT_MIN, INT_MAX, FLAGS, "sei" },
 
 { NULL },
-- 
2.14.1

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

[FFmpeg-devel] [PATCH v3 2/4] vaapi_encode_h265: Insert mastering display colour volume if needed

[Haihao Xiang]

'-sei xxx' is added to control SEI insertion, so far only mastering
display colour volume is available for testing.

v2: use the mastering display parameters from
AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to match
the H.264 part and take VAAPIEncodeH265Context::sei_needed as a ORed
value so that we needn't check the correspoding SEI message again when
writting the header.

v3: fix typo in commit log, change the option to '-sei hdr' and add some
comments about the medtadata update

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode_h265.c | 132 -
 1 file changed, 131 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 5203c6871d..4ff569c21f 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -24,15 +24,20 @@
 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
+#include "libavutil/mastering_display_metadata.h"
 
 #include "avcodec.h"
 #include "cbs.h"
 #include "cbs_h265.h"
 #include "hevc.h"
+#include "hevc_sei.h"
 #include "internal.h"
 #include "put_bits.h"
 #include "vaapi_encode.h"
 
+enum {
+SEI_MASTERING_DISPLAY   = 0x08,
+};
 
 typedef struct VAAPIEncodeH265Context {
 unsigned int ctu_width;
@@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
 H265RawSPS sps;
 H265RawPPS pps;
 H265RawSlice slice;
+H265RawSEI sei;
+
+H265RawSEIMasteringDiplayColourVolume mastering_display;
 
 int64_t last_idr_frame;
 int pic_order_cnt;
@@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
 CodedBitstreamContext *cbc;
 CodedBitstreamFragment current_access_unit;
 int aud_needed;
+int sei_needed;
 } VAAPIEncodeH265Context;
 
 typedef struct VAAPIEncodeH265Options {
@@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
 int aud;
 int profile;
 int level;
+int sei;
 } VAAPIEncodeH265Options;
 
 
@@ -175,6 +185,64 @@ fail:
 return err;
 }
 
+static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
+VAAPIEncodePicture *pic,
+int index, int *type,
+char *data, size_t *data_len)
+{
+VAAPIEncodeContext  *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = ctx->priv_data;
+CodedBitstreamFragment   *au = &priv->current_access_unit;
+int err, i;
+
+if (priv->sei_needed) {
+if (priv->aud_needed) {
+err = vaapi_encode_h265_add_nal(avctx, au, &priv->aud);
+if (err < 0)
+goto fail;
+priv->aud_needed = 0;
+}
+
+memset(&priv->sei, 0, sizeof(priv->sei));
+priv->sei.nal_unit_header  = (H265RawNALUnitHeader) {
+.nal_unit_type = HEVC_NAL_SEI_PREFIX,
+.nuh_layer_id  = 0,
+.nuh_temporal_id_plus1 = 1,
+};
+
+i = 0;
+
+if (priv->sei_needed & SEI_MASTERING_DISPLAY) {
+priv->sei.payload[i].payload_type = 
HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
+priv->sei.payload[i].payload.mastering_display = 
priv->mastering_display;
+++i;
+}
+
+priv->sei.payload_count = i;
+av_assert0(priv->sei.payload_count > 0);
+
+err = vaapi_encode_h265_add_nal(avctx, au, &priv->sei);
+if (err < 0)
+goto fail;
+priv->sei_needed = 0;
+
+err = vaapi_encode_h265_write_access_unit(avctx, data, data_len, au);
+if (err < 0)
+goto fail;
+
+ff_cbs_fragment_uninit(priv->cbc, au);
+
+*type = VAEncPackedHeaderRawData;
+return 0;
+} else {
+return AVERROR_EOF;
+}
+
+fail:
+ff_cbs_fragment_uninit(priv->cbc, au);
+return err;
+}
+
 static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 {
 VAAPIEncodeContext*ctx = avctx->priv_data;
@@ -587,6 +655,57 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 priv->aud_needed = 0;
 }
 
+priv->sei_needed = 0;
+
+// Only look for the metadata on I/IDR frame on the output. We
+// may force an IDR frame on the output where the medadata gets
+// changed on the input frame.
+if ((opt->sei & SEI_MASTERING_DISPLAY) &&
+(pic->type == PICTURE_TYPE_I || pic->type == PICTURE_TYPE_IDR)) {
+AVFrameSideData *sd =
+av_frame_get_side_data(pic->input_image,
+   AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (sd) {
+AVMasteringDisplayMetadata *mdm =
+(AVMasteringDisplayMetadata *)sd->data;
+
+// SEI is needed when both the primaries and luminance are set
+if (mdm->has_primaries && mdm->has_luminance) {
+const int mapping[3] = {1, 2, 0};
+