[FFmpeg-devel] [PATCH 2/4] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.
There was one bug which was the hard-coded assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.
We also need to pass the SPS and PPS range extension flags.
Signed-off-by: Philip Langdale
---
libavcodec/hevcdec.c| 3 +++
libavcodec/nvdec.c | 42 +
libavcodec/nvdec_hevc.c | 30 +
3 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index b2a87d55db..967f8f1def 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -409,6 +409,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
HEVCSPS *sps)
#endif
break;
case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUV444P12:
#if CONFIG_HEVC_NVDEC_HWACCEL
*fmt++ = AV_PIX_FMT_CUDA;
#endif
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index c7d5379770..72201a1123 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -35,6 +35,11 @@
#include "nvdec.h"
#include "internal.h"
+#if !NVDECAPI_CHECK_VERSION(9, 0)
+#define cudaVideoSurfaceFormat_YUV444 2
+#define cudaVideoSurfaceFormat_YUV444_16Bit 3
+#endif
+
typedef struct NVDECDecoder {
CUvideodecoder decoder;
@@ -274,7 +279,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
CUVIDDECODECREATEINFO params = { 0 };
-int cuvid_codec_type, cuvid_chroma_format;
+cudaVideoSurfaceFormat output_format;
+int cuvid_codec_type, cuvid_chroma_format, chroma_444;
int ret = 0;
sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
@@ -292,6 +298,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
return AVERROR(ENOSYS);
}
+chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
if (!avctx->hw_frames_ctx) {
ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -299,6 +306,21 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
return ret;
}
+switch (sw_desc->comp[0].depth) {
+case 8:
+output_format = chroma_444 ? cudaVideoSurfaceFormat_YUV444 :
+ cudaVideoSurfaceFormat_NV12;
+break;
+case 10:
+case 12:
+output_format = chroma_444 ? cudaVideoSurfaceFormat_YUV444_16Bit :
+ cudaVideoSurfaceFormat_P016;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported bit depth\n");
+return AVERROR(ENOSYS);
+}
+
frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
params.ulWidth = avctx->coded_width;
@@ -306,8 +328,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
params.ulTargetWidth = avctx->coded_width;
params.ulTargetHeight = avctx->coded_height;
params.bitDepthMinus8 = sw_desc->comp[0].depth - 8;
-params.OutputFormat= params.bitDepthMinus8 ?
- cudaVideoSurfaceFormat_P016 :
cudaVideoSurfaceFormat_NV12;
+params.OutputFormat= output_format;
params.CodecType = cuvid_codec_type;
params.ChromaFormat= cuvid_chroma_format;
params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
@@ -386,6 +407,8 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
NVDECFrame*cf = (NVDECFrame*)fdd->hwaccel_priv;
NVDECDecoder *decoder = (NVDECDecoder*)cf->decoder_ref->data;
+AVHWFramesContext *hwctx = (AVHWFramesContext *)frame->hw_frames_ctx->data;
+
CUVIDPROCPARAMS vpp = { 0 };
NVDECFrame *unmap_data = NULL;
@@ -394,6 +417,7 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
unsigned int pitch, i;
unsigned int offset = 0;
+int shift_h = 0, shift_v = 0;
int ret = 0;
vpp.progressive_frame = 1;
@@ -427,10 +451,11 @@ static int nvdec_retrieve_data(void *logctx, AVFrame
*frame)
unmap_data->idx_ref = av_buffer_ref(cf->idx_ref);
unmap_data->decoder_ref = av_buffer_ref(cf->decoder_ref);
+av_pix_fmt_get_chroma_sub_sample(hwctx->sw_format, _h, _v);
for (i = 0; frame->linesize[i]; i++) {
frame->data[i] = (uint8_t*)(devptr + offset);
frame->linesize[i] = pitch;
-offset += pitch * (frame->height >> (i ? 1 : 0));
+offset += pitch * (frame->height >> (i ? shift_v : 0));
}
goto finish;
@@ -566,7 +591,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
{
AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
const AVPixFmtDescriptor *sw_desc;
-int
[FFmpeg-devel] [PATCH 1/4] avcodec/hevc_ps: Expose all SPS and PPS range extension flags
We need all the flags to be exposed to be able to pass them on to
HW decoders. I did not attempt to nuance any of the warnings about
flags being unsupported as there's no way, at the point we extract
flags, to say whether an HW decoder is being used.
Signed-off-by: Philip Langdale
---
libavcodec/hevc_ps.c | 19 ---
libavcodec/hevc_ps.h | 4
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ea984af0a1..80df417e4f 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1102,20 +1102,17 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
decode_vui(gb, avctx, apply_defdispwin, sps);
if (get_bits1(gb)) { // sps_extension_flag
-int sps_range_extension_flag = get_bits1(gb);
+sps->sps_range_extension_flag = get_bits1(gb);
skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
-if (sps_range_extension_flag) {
-int extended_precision_processing_flag;
-int cabac_bypass_alignment_enabled_flag;
-
+if (sps->sps_range_extension_flag) {
sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
sps->transform_skip_context_enabled_flag = get_bits1(gb);
sps->implicit_rdpcm_enabled_flag = get_bits1(gb);
sps->explicit_rdpcm_enabled_flag = get_bits1(gb);
-extended_precision_processing_flag = get_bits1(gb);
-if (extended_precision_processing_flag)
+sps->extended_precision_processing_flag = get_bits1(gb);
+if (sps->extended_precision_processing_flag)
av_log(avctx, AV_LOG_WARNING,
"extended_precision_processing_flag not yet implemented\n");
@@ -1127,8 +1124,8 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
sps->persistent_rice_adaptation_enabled_flag = get_bits1(gb);
-cabac_bypass_alignment_enabled_flag = get_bits1(gb);
-if (cabac_bypass_alignment_enabled_flag)
+sps->cabac_bypass_alignment_enabled_flag = get_bits1(gb);
+if (sps->cabac_bypass_alignment_enabled_flag)
av_log(avctx, AV_LOG_WARNING,
"cabac_bypass_alignment_enabled_flag not yet
implemented\n");
}
@@ -1686,9 +1683,9 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
pps->slice_header_extension_present_flag = get_bits1(gb);
if (get_bits1(gb)) { // pps_extension_present_flag
-int pps_range_extensions_flag = get_bits1(gb);
+pps->pps_range_extensions_flag = get_bits1(gb);
skip_bits(gb, 7); // pps_extension_7bits
-if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT &&
pps_range_extensions_flag) {
+if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT &&
pps->pps_range_extensions_flag) {
if ((ret = pps_range_extensions(gb, avctx, pps, sps)) < 0)
goto err;
}
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 1fbda199e3..bbaa9205ef 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -284,13 +284,16 @@ typedef struct HEVCSPS {
int max_transform_hierarchy_depth_inter;
int max_transform_hierarchy_depth_intra;
+int sps_range_extension_flag;
int transform_skip_rotation_enabled_flag;
int transform_skip_context_enabled_flag;
int implicit_rdpcm_enabled_flag;
int explicit_rdpcm_enabled_flag;
+int extended_precision_processing_flag;
int intra_smoothing_disabled_flag;
int high_precision_offsets_enabled_flag;
int persistent_rice_adaptation_enabled_flag;
+int cabac_bypass_alignment_enabled_flag;
///< coded frame dimension in various units
int width;
@@ -365,6 +368,7 @@ typedef struct HEVCPPS {
int num_extra_slice_header_bits;
uint8_t slice_header_extension_present_flag;
uint8_t log2_max_transform_skip_block_size;
+uint8_t pps_range_extensions_flag;
uint8_t cross_component_prediction_enabled_flag;
uint8_t chroma_qp_offset_list_enabled_flag;
uint8_t diff_cu_chroma_qp_offset_depth;
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content
This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.
Note that unlike with nvdec, there is no confusion about the ability
of a codec to output 444 formats. This is because the cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.
Signed-off-by: Philip Langdale
---
libavcodec/cuviddec.c | 66 ++-
1 file changed, 46 insertions(+), 20 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 03589367ce..d6f9c620f4 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -34,8 +34,14 @@
#include "avcodec.h"
#include "decode.h"
#include "hwaccel.h"
+#include "nvdec.h"
#include "internal.h"
+#if !NVDECAPI_CHECK_VERSION(9, 0)
+#define cudaVideoSurfaceFormat_YUV444 2
+#define cudaVideoSurfaceFormat_YUV444_16Bit 3
+#endif
+
typedef struct CuvidContext
{
AVClass *avclass;
@@ -106,6 +112,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void
*opaque, CUVIDEOFORMAT* form
CUVIDDECODECAPS *caps = NULL;
CUVIDDECODECREATEINFO cuinfo;
int surface_fmt;
+int chroma_444;
int old_width = avctx->width;
int old_height = avctx->height;
@@ -148,17 +155,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void
*opaque, CUVIDEOFORMAT* form
cuinfo.target_rect.right = cuinfo.ulTargetWidth;
cuinfo.target_rect.bottom = cuinfo.ulTargetHeight;
+chroma_444 = format->chroma_format == cudaVideoChromaFormat_444;
+
switch (format->bit_depth_luma_minus8) {
case 0: // 8-bit
-pix_fmts[1] = AV_PIX_FMT_NV12;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_NV12;
caps = >caps8;
break;
case 2: // 10-bit
-pix_fmts[1] = AV_PIX_FMT_P010;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P010;
caps = >caps10;
break;
case 4: // 12-bit
-pix_fmts[1] = AV_PIX_FMT_P016;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P016;
caps = >caps12;
break;
default:
@@ -261,12 +270,6 @@ static int CUDAAPI cuvid_handle_video_sequence(void
*opaque, CUVIDEOFORMAT* form
return 0;
}
-if (format->chroma_format != cudaVideoChromaFormat_420) {
-av_log(avctx, AV_LOG_ERROR, "Chroma formats other than 420 are not
supported\n");
-ctx->internal_error = AVERROR(EINVAL);
-return 0;
-}
-
ctx->chroma_format = format->chroma_format;
cuinfo.CodecType = ctx->codec_type = format->codec;
@@ -280,8 +283,15 @@ static int CUDAAPI cuvid_handle_video_sequence(void
*opaque, CUVIDEOFORMAT* form
case AV_PIX_FMT_P016:
cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016;
break;
+case AV_PIX_FMT_YUV444P:
+cuinfo.OutputFormat = cudaVideoSurfaceFormat_YUV444;
+break;
+case AV_PIX_FMT_YUV444P16:
+cuinfo.OutputFormat = cudaVideoSurfaceFormat_YUV444_16Bit;
+break;
default:
-av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12, P010 or
P016 are not supported\n");
+av_log(avctx, AV_LOG_ERROR, "Unsupported output format: %s\n",
+ av_get_pix_fmt_name(avctx->sw_pix_fmt));
ctx->internal_error = AVERROR(EINVAL);
return 0;
}
@@ -490,6 +500,7 @@ static int cuvid_output_frame(AVCodecContext *avctx,
AVFrame *frame)
return ret;
if (av_fifo_size(ctx->frame_queue)) {
+const AVPixFmtDescriptor *pixdesc;
CuvidParsedFrame parsed_frame;
CUVIDPROCPARAMS params;
unsigned int pitch = 0;
@@ -520,7 +531,10 @@ static int cuvid_output_frame(AVCodecContext *avctx,
AVFrame *frame)
goto error;
}
-for (i = 0; i < 2; i++) {
+pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
+
+for (i = 0; i < pixdesc->nb_components; i++) {
+int height = avctx->height >> (i ? pixdesc->log2_chroma_h : 0);
CUDA_MEMCPY2D cpy = {
.srcMemoryType = CU_MEMORYTYPE_DEVICE,
.dstMemoryType = CU_MEMORYTYPE_DEVICE,
@@ -530,22 +544,25 @@ static int cuvid_output_frame(AVCodecContext *avctx,
AVFrame *frame)
.dstPitch = frame->linesize[i],
.srcY = offset,
.WidthInBytes = FFMIN(pitch, frame->linesize[i]),
-.Height= avctx->height >> (i ? 1 : 0),
+.Height= height,
};
ret = CHECK_CU(ctx->cudl->cuMemcpy2DAsync(,
device_hwctx->stream));
if (ret < 0)
goto error;
-offset += avctx->height;
+offset += height;
}
ret =
[FFmpeg-devel] [PATCH 3/4] avcodec/nvdec: Explicitly mark codecs that support 444 output formats
With the introduction of HEVC 444 support, we technically have two
codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG,
it can decode, but can only output one of the semi-planar formats.
That means we need additional logic to decide whether to use a
444 output format or not.
Signed-off-by: Philip Langdale
---
libavcodec/nvdec.c| 7 ---
libavcodec/nvdec.h| 5 -
libavcodec/nvdec_h264.c | 2 +-
libavcodec/nvdec_hevc.c | 10 --
libavcodec/nvdec_mjpeg.c | 2 +-
libavcodec/nvdec_mpeg12.c | 2 +-
libavcodec/nvdec_mpeg4.c | 2 +-
libavcodec/nvdec_vc1.c| 2 +-
libavcodec/nvdec_vp8.c| 2 +-
libavcodec/nvdec_vp9.c| 2 +-
10 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 72201a1123..b60da24301 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -298,7 +298,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
return AVERROR(ENOSYS);
}
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = ctx->supports_444 && cuvid_chroma_format ==
cudaVideoChromaFormat_444;
if (!avctx->hw_frames_ctx) {
ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -587,7 +587,8 @@ static AVBufferRef *nvdec_alloc_dummy(int size)
int ff_nvdec_frame_params(AVCodecContext *avctx,
AVBufferRef *hw_frames_ctx,
- int dpb_size)
+ int dpb_size,
+ int supports_444)
{
AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
const AVPixFmtDescriptor *sw_desc;
@@ -608,7 +609,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
av_log(avctx, AV_LOG_VERBOSE, "Unsupported chroma format\n");
return AVERROR(EINVAL);
}
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = supports_444 && cuvid_chroma_format ==
cudaVideoChromaFormat_444;
frames_ctx->format= AV_PIX_FMT_CUDA;
frames_ctx->width = (avctx->coded_width + 1) & ~1;
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 85a0fcf725..09ae8c37e6 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -61,6 +61,8 @@ typedef struct NVDECContext {
unsigned *slice_offsets;
int nb_slices;
unsigned int slice_offsets_allocated;
+
+int supports_444;
} NVDECContext;
int ff_nvdec_decode_init(AVCodecContext *avctx);
@@ -72,7 +74,8 @@ int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const
uint8_t *buffer,
uint32_t size);
int ff_nvdec_frame_params(AVCodecContext *avctx,
AVBufferRef *hw_frames_ctx,
- int dpb_size);
+ int dpb_size,
+ int supports_444);
int ff_nvdec_get_ref_idx(AVFrame *frame);
#endif /* AVCODEC_NVDEC_H */
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 25b30329d0..116bd4fb5d 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -166,7 +166,7 @@ static int nvdec_h264_frame_params(AVCodecContext *avctx,
{
const H264Context *h = avctx->priv_data;
const SPS *sps = h->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count +
sps->num_reorder_frames);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count +
sps->num_reorder_frames, 0);
}
const AVHWAccel ff_h264_nvdec_hwaccel = {
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index d11b5e8a38..590278ba04 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -299,7 +299,13 @@ static int nvdec_hevc_frame_params(AVCodecContext *avctx,
{
const HEVCContext *s = avctx->priv_data;
const HEVCSPS *sps = s->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx,
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx,
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1, 1);
+}
+
+static int nvdec_hevc_decode_init(AVCodecContext *avctx) {
+NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+ctx->supports_444 = 1;
+return ff_nvdec_decode_init(avctx);
}
const AVHWAccel ff_hevc_nvdec_hwaccel = {
@@ -311,7 +317,7 @@ const AVHWAccel ff_hevc_nvdec_hwaccel = {
.end_frame= ff_nvdec_end_frame,
.decode_slice = nvdec_hevc_decode_slice,
.frame_params = nvdec_hevc_frame_params,
-.init = ff_nvdec_decode_init,
+.init = nvdec_hevc_decode_init,
.uninit = ff_nvdec_decode_uninit,
.priv_data_size = sizeof(NVDECContext),
};
diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
index
[FFmpeg-devel] [PATCH 0/4] nvdec/cuviddec: Support HEVC 4:4:4 decoding
With the official release of the Video SDK 9.0, I'm resending my previous patch series for the new decode capabilities. I have left out the new pixel formats representing MSB packed 444p10 and 444p12 due to the lack of concensus on introducing these pixel formats. That means we will always treat them as 444p16, which is not terrible, but does lose information (the actual bit depth). I will add a changelog entry and minor version bumps when I push. Philip Langdale (4): avcodec/hevc_ps: Expose all SPS and PPS range extension flags avcodec/nvdec: Add support for decoding HEVC 4:4:4 content avcodec/nvdec: Explicitly mark codecs that support 444 output formats avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content libavcodec/cuviddec.c | 66 +++ libavcodec/hevc_ps.c | 19 +-- libavcodec/hevc_ps.h | 4 +++ libavcodec/hevcdec.c | 3 ++ libavcodec/nvdec.c| 45 -- libavcodec/nvdec.h| 5 ++- libavcodec/nvdec_h264.c | 2 +- libavcodec/nvdec_hevc.c | 40 ++-- libavcodec/nvdec_mjpeg.c | 2 +- libavcodec/nvdec_mpeg12.c | 2 +- libavcodec/nvdec_mpeg4.c | 2 +- libavcodec/nvdec_vc1.c| 2 +- libavcodec/nvdec_vp8.c| 2 +- libavcodec/nvdec_vp9.c| 2 +- 14 files changed, 146 insertions(+), 50 deletions(-) -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support
On Wed, 13 Feb 2019 19:47:27 +0100 Timo Rothenpieler wrote: > On 13.02.2019 09:56, Roman Arzumanyan wrote: > > Hello, > > > > Please find attached patch, it adds HEVC YUV444P decoding support. > > > > Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE, > > AV_PIX_FMT_YUV444P12LE. > > > > This feature requires Video Codec SDK 9. > > There is one big issue with this. > And that is, that ffmpeg expects the data for YUV444P10 and YUV444P12 > to be in the least significant bits. > Nvenc (and I hope/assume as does nvdec/cuvid) on the other hand put > the data into the most significant bits. > > As a workaround we have so far resorted to using the 16 bit pix_fmt > everywhere, as it happens to match up. > That has the issue of losing the information about the bit depth. > So far every attempt at solving it (like, adding new pix_fmts that > match what nvenc/dec uses) have not found consent. > I am reworking my previous patch series (from when I 'reverse engineered' the new enum values) to reflect the new SDK and I'll resend later this week. It will include updates for cuviddec. Thanks, --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/generate-doc: replace yasm with x86asm
Signed-off-by: Lou Logan --- generate-doc.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generate-doc.sh b/generate-doc.sh index d8d01d3..4555a35 100755 --- a/generate-doc.sh +++ b/generate-doc.sh @@ -34,9 +34,9 @@ export FA_ICONS=true rm -rf build-doc mkdir build-doc && cd build-doc -$src/configure --enable-gpl --disable-yasm || die "configure failed" +$src/configure --enable-gpl --disable-x86asm || die "configure failed" make doc || die "doc not made" cp doc/*.html ../htdocs/ || die "copy failed" cd .. -rm -rf build-doc \ No newline at end of file +rm -rf build-doc -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/docs: remove ffserver links
ffserver documentation and sample configuration file has been moved to the wiki: https://trac.ffmpeg.org/wiki/ffserver The files unlinked by this patch will be removed from the server. Signed-off-by: Lou Logan --- src/documentation | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/documentation b/src/documentation index a4802be..7e222e4 100644 --- a/src/documentation +++ b/src/documentation @@ -18,9 +18,6 @@ ffplay-all: ffplay tool and FFmpeg components ffprobe: ffprobe tool ffprobe-all: ffprobe tool and FFmpeg components -ffserver: ffserver tool -ffserver-all: ffserver tool and FFmpeg components -sample ffserver configuration file -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_direct: Fix overflow in POC comparission
Fixes: runtime error: signed integer overflow: 2147421862 - -33624063 cannot be represented in type 'int' Fixes: 12885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5733516975800320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/h264_direct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_direct.c b/libavcodec/h264_direct.c index ec9fca0350..a01d823e7a 100644 --- a/libavcodec/h264_direct.c +++ b/libavcodec/h264_direct.c @@ -156,8 +156,8 @@ void ff_h264_direct_ref_list_init(const H264Context *const h, H264SliceContext * av_log(h->avctx, AV_LOG_ERROR, "co located POCs unavailable\n"); sl->col_parity = 1; } else -sl->col_parity = (FFABS(col_poc[0] - cur_poc) >= - FFABS(col_poc[1] - cur_poc)); +sl->col_parity = (FFABS(col_poc[0] - (int64_t)cur_poc) >= + FFABS(col_poc[1] - (int64_t)cur_poc)); ref1sidx = sidx = sl->col_parity; // FL -> FL & differ parity -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: parse some stream specifiers recursively
On Mon, 11 Feb 2019, Marton Balint wrote: On Tue, 5 Feb 2019, Marton Balint wrote: This removes lots of code duplication and also allows more complex specifiers, for example you can use p:204:a:m:language:eng to select the English language audio stream from program 204. Ping... Will apply soon. Pushed. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpegts: also convert strings without a specified encoding to UTF-8
On Tue, 12 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-11 23:42 GMT+01:00, Marton Balint : The default codepage (ISO6937) should be used in this case. lgtm Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mpegts: fix charset of type 0x11
On Tue, 12 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-11 23:42 GMT+01:00, Marton Balint : ISO-10646 alone means UCS-4 for iconv, the specs refers to the Basic Multilingual Plane (BMP), therefore we need UCS-2. VLC also using that. Signed-off-by: Marton Balint --- libavformat/mpegts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index b347ec1736..2594b1eeb1 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -683,7 +683,7 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end) "ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8", "ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13", "ISO-8859-14", "ISO-8859-15", "", "", "", "", -"", "ISO-10646", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", "", +"", "UCS-2BE", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", "", If you believe this is correct, please commit. Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available
So, should this go in? :)
On 2/8/19 11:10 PM, Mathieu Duponchelle wrote:
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 32
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 37 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..a283b9fddf 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
> display extension
> indicating the source of the video pictures. The default is
> @samp{unspecified},
> can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
> For maximum compatibility, use @samp{component}.
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Default is 1 (on).
> @end table
>
> @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index d0b458e34b..2bc5289d63 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
> static uint8_t mpeg1_index_run[2][64];
> static int8_t mpeg1_max_level[2][64];
>
> +#define A53_MAX_CC_COUNT 0x1f
> +
> static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
> {
> int i;
> @@ -544,6 +546,36 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s,
> int picture_number)
> }
> }
>
> +if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
> +side_data = av_frame_get_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_A53_CC);
> +if (side_data) {
> +if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size %
> 3 == 0) {
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(>pb, 8, 'G'); //
> user_identifier
> +put_bits(>pb, 8, 'A');
> +put_bits(>pb, 8, '9');
> +put_bits(>pb, 8, '4');
> +put_bits(>pb, 8, 3); //
> user_data_type_code
> +put_bits(>pb, 8,
> +(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); //
> flags, cc_count
> +put_bits(>pb, 8, 0xff); // em_data
> +
> +for (i = 0; i < side_data->size; i++)
> +put_bits(>pb, 8, side_data->data[i]);
> +
> +put_bits(>pb, 8, 0xff); // marker_bits
> +} else {
> +av_log(s->avctx, AV_LOG_WARNING,
> +"Warning Closed Caption size (%d) can not exceed 93
> bytes "
> +"and must be a multiple of 3\n", side_data->size);
> +}
> +}
> +}
> +
> s->mb_y = 0;
> ff_mpeg1_encode_slice_header(s);
> }
> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
> index bbc6b5646a..e1ff5f97dc 100644
> --- a/libavcodec/mpegvideo.h
> +++ b/libavcodec/mpegvideo.h
> @@ -455,6 +455,7 @@ typedef struct MpegEncContext {
> /* MPEG-2-specific - I wished not to have to support this mess. */
> int progressive_sequence;
> int mpeg_f_code[2][2];
> +int a53_cc;
>
> // picture structure defines are loaded from mpegutils.h
> int picture_structure;
> @@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
> {"ps", "RTP payload size in bytes",
> FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
> INT_MAX, FF_MPV_OPT_FLAGS }, \
> {"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
> FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
> INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
> {.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> +{"a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
>
> extern const AVOption ff_mpv_generic_options[];
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: change the assert in trailing_bits to accept zero bits when reading
On Sun, Feb 10, 2019 at 3:12 PM James Almer wrote: > If nb_bits is zero when reading an OBU, then it's not a bug in CBS but an > invalid bitstream, and we should abort gracefully instead. > > Signed-off-by: James Almer > --- > rav1e is currently encoding invalid Metadata OBUs without trailing bits, > which > are triggering the assert when parsed by CBS. This change makes sure to > instead > report the bitstream as invalid and gracefully return with an error code > instead of crashing. > In case anyone is interested, this got fixed tonight, rav1e can produce conformant bitstreams when encoding metadata now. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: Use correct channel count for AAC codec
---
libavformat/movenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7794330..bb8bbdb 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1088,6 +1088,7 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
} else { /* reserved for mp4/3gp */
if (track->par->codec_id == AV_CODEC_ID_FLAC ||
track->par->codec_id == AV_CODEC_ID_ALAC ||
+track->par->codec_id == AV_CODEC_ID_AAC ||
track->par->codec_id == AV_CODEC_ID_OPUS) {
avio_wb16(pb, track->par->channels);
} else {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/nvenc_hevc: adding B frame support
On 13.02.2019 09:52, Roman Arzumanyan wrote: Hello, Please find attached patch, it adds HEVC B-frames support to nvenc_hevc. This feature requires Video Codec SDK 9 + Turing card. Will it cause issues if set on an older card, or just plain get ignored? If it's ignored, this LGTM. 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] nv-codec-headers: Video Codec SDK 9 support
On 13.02.2019 09:47, Roman Arzumanyan wrote: Hello, Please find attached patch for nv-codec-headers. It adds Video Codec SDK 9 support. Applied and followed up with a patch adding some more new fields from SDK 9.0.18. 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/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support
On 13.02.2019 09:56, Roman Arzumanyan wrote: Hello, Please find attached patch, it adds HEVC YUV444P decoding support. Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV444P12LE. This feature requires Video Codec SDK 9. There is one big issue with this. And that is, that ffmpeg expects the data for YUV444P10 and YUV444P12 to be in the least significant bits. Nvenc (and I hope/assume as does nvdec/cuvid) on the other hand put the data into the most significant bits. As a workaround we have so far resorted to using the 16 bit pix_fmt everywhere, as it happens to match up. That has the issue of losing the information about the bit depth. So far every attempt at solving it (like, adding new pix_fmts that match what nvenc/dec uses) have not found consent. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavf/jacosubdec: compute subtitle duration correctly
When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (This test is based on JACOsub's demo.txt, and the end
time computed for the last line using @ now matches what the comments
there say it should be.)
Also tested in practice using MPV, a LaserDisc, and some authentic 1993
JACOsub files.
Signed-off-by: Adam Sampson
---
v2: update the test data too (thanks, Carl Eugen!)
libavformat/jacosubdec.c | 2 +-
tests/ref/fate/sub-jacosub | 22 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c
index 520c435cc5..f6be5df2d7 100644
--- a/libavformat/jacosubdec.c
+++ b/libavformat/jacosubdec.c
@@ -127,7 +127,7 @@ shift_and_ret:
ts_start = (ts_start + jacosub->shift) * 100 / jacosub->timeres;
ts_end= (ts_end + jacosub->shift) * 100 / jacosub->timeres;
*start= ts_start;
-*duration = ts_start + ts_end;
+*duration = ts_end - ts_start;
return buf + len;
}
diff --git a/tests/ref/fate/sub-jacosub b/tests/ref/fate/sub-jacosub
index a30fe4a196..5f282cdcf6 100644
--- a/tests/ref/fate/sub-jacosub
+++ b/tests/ref/fate/sub-jacosub
@@ -10,14 +10,14 @@ Style:
Default,Arial,16,0,0,0,0,100,100,0,0,1,1,0,2,10
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
-Dialogue: 0,0:00:00.12,0:00:04.36,Default,,0,0,0,,{\an5}JACOsub\N\NThis script
demonstrates some of the capabilities of JACOsub.
-Dialogue: 0,0:00:04.12,0:00:14.86,Default,,0,0,0,,{\an8}Text may be positioned
at the top,
-Dialogue: 0,0:00:05.12,0:00:17.46,Default,,0,0,0,,{\an5}middle,
-Dialogue: 0,0:00:06.12,0:00:20.06,Default,,0,0,0,,{\an2}or bottom of the
screen.
-Dialogue: 0,0:00:08.12,0:00:27.36,Default,,0,0,0,,{\an5}{this is a comment}
(And, you just saw, {another comment} timing ranges for different lines of text.
-Dialogue: 0,0:00:11.12,0:00:35.86,Default,,0,0,0,,{\an1}Within margin
constraints\Nthat you set, text may be\Nleft justified,
-Dialogue: 0,0:00:13.62,0:00:42.11,Default,,0,0,0,,{\an2}{the JC is redundant -
it's the default}center\Njustified,
-Dialogue: 0,0:00:14.87,0:00:45.86,Default,,0,0,0,,{\an3}and also\Nright
justified.
-Dialogue: 0,0:00:22.42,0:01:12.76,Default,,0,0,0,,Text may appear in different
styles\N(Normal, {\b1}Bold{\r}, {\i1}Italic{\r})
-Dialogue: 0,0:01:16.12,0:03:53.36,Default,,0,0,0,,{\an5}\N\NAt that time, you
may press any key to return to the Editor.
-Dialogue: 0,0:01:16.12,0:03:53.36,Default,,0,0,0,,OK, this script will be
finished when the screen goes blank.
+Dialogue: 0,0:00:00.12,0:00:04.12,Default,,0,0,0,,{\an5}JACOsub\N\NThis script
demonstrates some of the capabilities of JACOsub.
+Dialogue: 0,0:00:04.12,0:00:06.62,Default,,0,0,0,,{\an8}Text may be positioned
at the top,
+Dialogue: 0,0:00:05.12,0:00:07.22,Default,,0,0,0,,{\an5}middle,
+Dialogue: 0,0:00:06.12,0:00:07.82,Default,,0,0,0,,{\an2}or bottom of the
screen.
+Dialogue: 0,0:00:08.12,0:00:11.12,Default,,0,0,0,,{\an5}{this is a comment}
(And, you just saw, {another comment} timing ranges for different lines of text.
+Dialogue: 0,0:00:11.12,0:00:13.62,Default,,0,0,0,,{\an1}Within margin
constraints\Nthat you set, text may be\Nleft justified,
+Dialogue: 0,0:00:13.62,0:00:14.87,Default,,0,0,0,,{\an2}{the JC is redundant -
it's the default}center\Njustified,
+Dialogue: 0,0:00:14.87,0:00:16.12,Default,,0,0,0,,{\an3}and also\Nright
justified.
+Dialogue: 0,0:00:22.42,0:00:27.92,Default,,0,0,0,,Text may appear in different
styles\N(Normal, {\b1}Bold{\r}, {\i1}Italic{\r})
+Dialogue: 0,0:01:16.12,0:01:21.12,Default,,0,0,0,,{\an5}\N\NAt that time, you
may press any key to return to the Editor.
+Dialogue: 0,0:01:16.12,0:01:21.12,Default,,0,0,0,,OK, this script will be
finished when the screen goes blank.
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/muxers: fix typo
On 13-02-2019 09:36 PM, Reto Kromer wrote: Best regards, Reto A grammar change rather than a typo. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/muxers: fix typo
Best regards, Reto 0001-doc-muxers-fix-typo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/muxers: fix typo
Carl Eugen Hoyos wrote:
>> +Any hexadecimal value between @code{0x01} to @code{0xff} as defined in
>
>Shouldn't this be "between 0x01 and 0xff"?
Yep, of course. I will fix this. Thank you! Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/muxers: fix typo
2019-02-13 14:18 GMT+01:00, Reto Kromer :
> ffmpeg | branch: master | Reto Kromer | Wed Feb 13 14:08:23
> 2019 +0100| [bf78aa9ee9c42c89bcd88a301e23ce8efbd155ce] | committer: Gyan
> Doshi
>
> doc/muxers: fix typo
>
> Signed-off-by: Gyan Doshi
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=bf78aa9ee9c42c89bcd88a301e23ce8efbd155ce
> ---
>
> doc/muxers.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 18ce9b15c7..6a3266ab2e 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1523,7 +1523,7 @@ Set the program @samp{service_type}. Default is
> @code{digital_tv}.
> Accepts the following options:
> @table @samp
> @item hex_value
> -Any hexdecimal value between @code{0x01} to @code{0xff} as defined in
> +Any hexadecimal value between @code{0x01} to @code{0xff} as defined in
Shouldn't this be "between 0x01 and 0xff"?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cdg: unset duration on packets
2019-02-13 16:19 GMT+01:00, Guillaume Desmottes : > Thanks for testing my patch. I wasn't aware of this specific test, sorry > about that. > > What would be the proper way to address this? Should the fate reference > be updated? Yes, unless the change is wrong. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cdg: unset duration on packets
On 11/02/2019 23:41, Michael Niedermayer wrote: breaks fate-cdgraphics Hi Michael, Thanks for testing my patch. I wasn't aware of this specific test, sorry about that. What would be the proper way to address this? Should the fate reference be updated? The test file is still properly played by ffplay so playback isn't broken. This is my first ffmpeg patch so any pointer to help me getting this patch integrated would be really helpful. Thanks a lot, G. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/muxers: fix typo
On 13-02-2019 06:41 PM, Reto Kromer wrote: Best regards, Reto Pushed as bf78aa9ee9c42c89bcd88a301e23ce8efbd155ce Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/muxers: fix typo
Best regards, Reto 0001-doc-muxers-fix-typo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskadec: Check parents remaining length
Reported-by: Steve Lhomme
This was found through the Hacker One program on VLC but is not a security
issue in libavformat
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4ad99db7db..4b10f44712 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -792,6 +792,19 @@ static int matroska_resync(MatroskaDemuxContext *matroska,
int64_t last_pos)
return AVERROR_EOF;
}
+static int64_t ebml_parent_size_remaining(MatroskaDemuxContext *matroska)
+{
+AVIOContext *pb = matroska->ctx->pb;
+int64_t pos = avio_tell(pb);
+
+if (matroska->num_levels > 0) {
+MatroskaLevel *level = >levels[matroska->num_levels - 1];
+if (level->length != (uint64_t)-1)
+return level->length - (pos - level->start);
+}
+return INT64_MAX;
+}
+
/*
* Return: Whether we reached the end of a level in the hierarchy or not.
*/
@@ -1197,6 +1210,14 @@ static int ebml_parse_elem(MatroskaDemuxContext
*matroska,
length, max_lengths[syntax->type], syntax->type);
return AVERROR_INVALIDDATA;
}
+
+av_assert0(length <= INT64_MAX);
+if (ebml_parent_size_remaining(matroska) < (int64_t)length) {
+av_log(matroska->ctx, AV_LOG_ERROR,
+ "Invalid length 0x%"PRIx64" > 0x%"PRIx64" parent length\n",
+ length, ebml_parent_size_remaining(matroska));
+return AVERROR_INVALIDDATA;
+}
}
switch (syntax->type) {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream
On 12/02/2019 22:28, Michael Niedermayer wrote:
> @@ -5048,7 +5048,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> for (i = 0; i < c->fc->nb_streams; i++) {
> st = c->fc->streams[i];
> sc = st->priv_data;
> -if (!sc->has_sidx) {
> +if (ref_st && !sc->has_sidx) {
> st->duration = sc->track_end = av_rescale(ref_st->duration,
> sc->time_scale, ref_sc->time_scale);
> }
> }
Is it perhaps better to not run this loop at all if ref_sc or ref_st do not
exist?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
> >> sizeof(AVFrame) is not part of the ABI. You need to allocate it > >> somewhere. > >> > > Please tell more? > > See the documentation for AVFrame in libavutil/frame.h Use av_frame_alloc() > > Carl Eugen Thanks Carl ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
2019-02-13 8:52 GMT+01:00, Wang, Shaofei : >> > +AVFrame input_frm; >> >> sizeof(AVFrame) is not part of the ABI. You need to allocate it >> somewhere. >> > Please tell more? See the documentation for AVFrame in libavutil/frame.h Use av_frame_alloc() Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora decoding with mmi.
>-Original Message- >From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] >On Behalf Of gxw >Sent: Tuesday, February 12, 2019 6:56 PM >To: ffmpeg-devel@ffmpeg.org >Cc: gxw >Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora >decoding with mmi. > >Optimize theora decoding with mmi in functions: >1. ff_vp3_idct_add_mmi >2. ff_vp3_idct_put_mmi >3. ff_vp3_idct_dc_add_mmi >4. ff_put_no_rnd_pixels_l2_mmi > >Theora decoding speed improved about 32%(from 88fps to 116fps, Tested on >loongson 3A3000). >--- > libavcodec/mips/Makefile | 1 + > libavcodec/mips/vp3dsp_idct_mmi.c | 769 + > libavcodec/mips/vp3dsp_init_mips.c | 14 + > libavcodec/mips/vp3dsp_mips.h | 6 + > 4 files changed, 790 insertions(+) > create mode 100644 libavcodec/mips/vp3dsp_idct_mmi.c > Verified + 1, LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/webmdashenc: Check id in adaption_sets
Fixes: out of array access
Found-by: Wenxiang Qian
Signed-off-by: Michael Niedermayer
---
libavformat/webmdashenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index 1280d8a763..26b8727304 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -466,6 +466,7 @@ static int parse_adaptation_sets(AVFormatContext *s)
continue;
else if (state == new_set && !strncmp(p, "id=", 3)) {
void *mem = av_realloc(w->as, sizeof(*w->as) * (w->nb_as + 1));
+const char *comma;
if (mem == NULL)
return AVERROR(ENOMEM);
w->as = mem;
@@ -474,6 +475,11 @@ static int parse_adaptation_sets(AVFormatContext *s)
w->as[w->nb_as - 1].streams = NULL;
p += 3; // consume "id="
q = w->as[w->nb_as - 1].id;
+comma = strchr(p, ',');
+if (!comma || comma - p >= sizeof(w->as[w->nb_as - 1].id)) {
+av_log(s, AV_LOG_ERROR, "'id' in 'adaptation_sets' is
malformed.\n");
+return AVERROR(EINVAL);
+}
while (*p != ',') *q++ = *p++;
*q = 0;
p++;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/http: Fix Out-of-Bounds access in process_line()
From: Wenxiang Qian Signed-off-by: Michael Niedermayer --- libavformat/http.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/http.c b/libavformat/http.c index a0a0636cf2..072a6ce0b9 100644 --- a/libavformat/http.c +++ b/libavformat/http.c @@ -915,7 +915,7 @@ static int process_line(URLContext *h, char *line, int line_count, while (av_isspace(*p)) p++; resource = p; -while (!av_isspace(*p)) +while (*p && !av_isspace(*p)) p++; *(p++) = '\0'; av_log(h, AV_LOG_TRACE, "Requested resource: %s\n", resource); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393
From: Wenxiang Qian
Signed-off-by: Michael Niedermayer
---
libavformat/ftp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index e072067480..3adc04ee1f 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -389,7 +389,7 @@ static int ftp_file_size(FTPContext *s)
static const int size_codes[] = {213, 0};
snprintf(command, sizeof(command), "SIZE %s\r\n", s->path);
-if (ftp_send_command(s, command, size_codes, ) == 213 && res) {
+if (ftp_send_command(s, command, size_codes, ) == 213 && res &&
strlen(res) > 4) {
s->filesize = strtoll([4], NULL, 10);
} else {
s->filesize = -1;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support
Hello, Please find attached patch, it adds HEVC YUV444P decoding support. Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV444P12LE. This feature requires Video Codec SDK 9. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-HEVC-YUV444P-decoding-support.patch Description: 0001-Adding-HEVC-YUV444P-decoding-support.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?
Hi Harish, On Tue, 12 Feb 2019 19:43:33 +0530, Harish Krupo wrote: > Hi Niklas, > > Thanks a lot for your comments. Please find my reply inline. > > Niklas Haas writes: > > > Hi, > > > > The important thing to consider is what constraints we are trying to > > solve. And I think the expected behavior is that an SDR signal in SDR > > mode should look identical to an SDR signal in HDR mode, to the end > > user. > > > > This is, of course, an impossible constraint to solve, since we don't > > know anything about the display, either in HDR or in SDR mode. At best, > > in the absence of this knowledge, we could make a guess (e.g. it's > > roughly described by sRGB in SDR mode, and for HDR mode it roughly > > follows the techniques outlined in ITU-R Report BT.2390). Better yet > > would be to actually obtain this information from somewhere, but where? > > (The user? ICC profile? EDID?). > > Being the compositor we already have access to EDID, which means we can make > intelligent decisions based on the capabilities of the display. Also, benefit > of being the compositor is to have the complete knowledge of all the > buffers to be displayed, thus we can make informed decisions about the optimal > output for the display. The problem remains that the EDID information is really lacking. It doesn't give us specifics about what curve the display implements. The only realistic way of getting that information is with an ICC profile. Now, the average user will obviously not have an ICC profile for their display, but the average user will also most likely not care about colorimetric accuracy. So we can use an approximation based on EDID for the average case and consult an ICC profile instead when one is available. > > But the bottom line is that to solve the "make SDR in HDR mode appear > > identical to SDR in SDR mode" constraint, the curve you are trying to > > invert is not your own tone mapping operator, but the tone mapping > > operator implemented by the display (in HDR mode), which definitely > > depends on what brightness level the display is targeting (in both SDR > > and HDR modes). > > > > If I have to explain our implementation better, we decide on the target > HDR metadata and eotf and use this for both tone mapping as well as > settting output display configuration (like setting HDMI AVI infoframes), > which means the display and the compositor are in-sync about the eotf curve. There's no strict definition for how this HDR metadata is to be parsed, so the display is still free to do whatever it wants. Actually, the existence of HDR metadata further complicates matters, because a display that does metadata-dependent tone mapping can't even easily be characterized by an ICC profile (without making a separate profile for every possible metadata value you want to send it). Which means that, when using an ICC profile, we must force the display into the exact set of metadata used when generating this ICC profile. Most likely, rather than just having two modes "SDR" and "HDR", we would end up having a list of possible display modes, each with different associated metadata parameters (curve, peak, gamut, ...). If one of these modes has an attached ICC profile, that ICC profile is only valid for exactly that mode. > > For an ideal HDR display, this would simply be the PQ curve's exact > > definition (i.e. noop tone mapping). But in practice, the display will > > almost surely not be capable of displaying up to 10,000 nits, so it will > > implement a tone mapping operator of some kind (even if it's as simple > > as clipping the extra range). Some colorimetric/reference displays > > actually do the latter, since they prefer clipping out-of-range signals > > over distorting in-range ones. But most consumer displays will probably > > do something similar to the hable curve, most likely in per-channel > > modes. > > > > I agree. This is something which we thought of but as these > implementations are internal to the display, we anyways dont have any > control over this. Indeed. We should at least try and cover the most common cases, though. For more specific use cases, we should support ICC profiles as discussed above. There is some sort of obvious distinction here between "ICC mode" and "non-ICC mode". More specifically: ICC mode: - cannot set metadata dynamically, must set the exact values the ICC profile was generated for (but we can still dynamically pick the best mode based on the content) - more complicated handling, probably needs at least 1D LUTs, worst case scenario is a 3D LUT non-ICC mode: - can set metadata dynamically based on the contents - instead of an ICC profile, we need to implement our own EOTF functions based on the metadata values Most likely, in terms of the UI, the user will be able to provide a set of ICC profiles + metadata for the display, as well as choosing from a default EOTF/gamut to assume in the absence of an ICC profile. > > For an ideal SDR display, it
[FFmpeg-devel] [PATCH 1/2] libavcodec/nvenc_hevc: adding B frame support
Hello, Please find attached patch, it adds HEVC B-frames support to nvenc_hevc. This feature requires Video Codec SDK 9 + Turing card. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Adding-b_as_ref-support-for-HEVC.patch Description: 0001-Adding-b_as_ref-support-for-HEVC.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nv-codec-headers: Video Codec SDK 9 support
Hello, Please find attached patch for nv-codec-headers. It adds Video Codec SDK 9 support. -- BR, Roman Arzumanyan --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Updating-headers-for-Video-Codec-SDK-9-release.patch Description: 0001-Updating-headers-for-Video-Codec-SDK-9-release.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Niklas Haas > Sent: Saturday, February 09, 2019 1:30 AM > To: Kps, Harish Krupo > Cc: vittorio.giov...@gmail.com; Sharma, Shashank > ; Palli, Tapani ; > FFmpeg development discussions and patches ; > Strasser, Kevin > Subject: Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm? > > Hi, > > The important thing to consider is what constraints we are trying to > solve. And I think the expected behavior is that an SDR signal in SDR > mode should look identical to an SDR signal in HDR mode, to the end > user. > > This is, of course, an impossible constraint to solve, since we don't > know anything about the display, either in HDR or in SDR mode. At best, > in the absence of this knowledge, we could make a guess (e.g. it's > roughly described by sRGB in SDR mode, and for HDR mode it roughly > follows the techniques outlined in ITU-R Report BT.2390). Better yet > would be to actually obtain this information from somewhere, but where? > (The user? ICC profile? EDID?). just for your information. There might be a way (in future) to get this information via libdrm (at least intel platform), see https://lists.freedesktop.org/archives/dri-devel/2017-May/143135.html. > > But the bottom line is that to solve the "make SDR in HDR mode appear > identical to SDR in SDR mode" constraint, the curve you are trying to > invert is not your own tone mapping operator, but the tone mapping > operator implemented by the display (in HDR mode), which definitely > depends on what brightness level the display is targeting (in both SDR > and HDR modes). > > For an ideal HDR display, this would simply be the PQ curve's exact > definition (i.e. noop tone mapping). But in practice, the display will > almost surely not be capable of displaying up to 10,000 nits, so it will > implement a tone mapping operator of some kind (even if it's as simple > as clipping the extra range). Some colorimetric/reference displays > actually do the latter, since they prefer clipping out-of-range signals > over distorting in-range ones. But most consumer displays will probably > do something similar to the hable curve, most likely in per-channel > modes. > > For an ideal SDR display, it depends on who you ask (w.r.t what "ideal" > means). In the ITU-R world, an ideal SDR reference display implements > the BT.1886 transfer function. In practice, it's probably closer to a > pure power gamma 2.2 curve. Or maybe sRGB. We really have nothing else > to do here except either consult an ICC profile or just stick our head > in the sand and guess randomly. > > -- > > I'd also like to comment on your compositor design proposal. A few notes: > > 1. It's always beneficial to do as few color conversion steps as >possible, to minimize cumulative errors and optimize performance. If >you use a 3DLUT as any step (e.g. for implementing an ICC-profile >based mapping), the 3DLUT should be as "wide" as possible and cover >as many operations as possible, so that the 3DLUT can be end-to-end >optimized (by the CMM). > >If you insist on doing compositing in linear light, then I would >probably composite in display-referred linear light and convert it to >non-linear light during scanout (either by implementing the needed >OETF + linear tone mapping operator via the VCGTs, or by doing a >non-linear tone mapping pass). But I would recommend trying to avoid >any second gamut conversion step (e.g. from BT.2020 to the display's >space after compositing). > >Otherwise, I would composite directly in the target color space >(saving us one final conversion step), which would obviously be >preferable if there are no transparency effects to worry about. >Maybe we could even switch dynamically between the two depending on >whether any blending needs to occur? Assuming we can update the VCGTs >atomically and without meaningful latency. > > 2. Rec 2020 is not (inherently) HDR. Also, the choice of color gamut has >nothing to do with the choice of transfer function. I might have Rec >709 HDR content. In general, when ingesting a buffer, the user should >be responsible for tagging both its color primaries and its transfer >function. > > 3. If you're compositing in linear light, then you most likely want to >be using at least 16-bit per channel floating point buffers, with 1.0 >mapping to "SDR white", and HDR values being treated as above 1.0. > >This is also a good color space to use for ingesting buffers, since >it allows treating SDR and HDR inputs "identically", but extreme >caution must be applied due to the fact that with floating point >buffers, we're left at the mercy of what the client wants to put into >them (10^20? NaN? Negative values?). Extra metadata must still be >
