[FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
Attached patch allows users to set x265 encoding profile.
Addresses ticket #6894.
Regards,
Gyan
From e45cd99804dab980d3441c0450b22c5b69b18474 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265.c - Add named option to set profile
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
---
libavcodec/libx265.c | 10 ++
libavcodec/version.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..2e144e1618 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -45,6 +45,7 @@ typedef struct libx265Context {
int forced_idr;
char *preset;
char *tune;
+char *profile;
char *x265_opts;
} libx265Context;
@@ -220,6 +221,14 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
}
+if (ctx->profile) {
+if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set :
%s.\n", ctx->profile);
+av_log(avctx, AV_LOG_INFO, "Profile must match bit depth and
chroma sampling of output stream.\n");
+return AVERROR(EINVAL);
+}
+}
+
ctx->encoder = ctx->api->encoder_open(ctx->params);
if (!ctx->encoder) {
av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -392,6 +401,7 @@ static const AVOption options[] = {
{ "forced-idr", "if forcing keyframes, force them as IDR frames",
OFFSET(forced_idr),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, VE },
{ "preset", "set the x265 preset",
OFFSET(preset),AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "tune","set the x265 tune parameter",
OFFSET(tune), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "x265-profile","set the x265 profile",
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "x265-params", "set the x265 configuration using a :-separated list of
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d67b689142..3b5c3000be 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 6
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MICRO 103
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
On 05.12.2017 01:38, Michael Niedermayer wrote: Noone is known to work on fixing this, so it should be disabled Signed-off-by: Michael Niedermayer --- tests/fate/mov.mak | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index 680baea773..869784fd31 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -6,7 +6,6 @@ FATE_MOV = fate-mov-3elist \ fate-mov-1elist-ends-last-bframe \ fate-mov-2elist-elist1-ends-bframe \ fate-mov-3elist-encrypted \ - fate-mov-invalid-elst-entry-count \ fate-mov-gpmf-remux \ fate-mov-440hz-10ms \ fate-mov-ibi-elst-starts-b \ Maybe add a FIXME comment to the test itself so that somebody reading the file doesn't think it is missing in this list by accident? Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On Tue, Dec 5, 2017 at 9:12 AM, Gyan Doshi wrote: > Attached patch allows users to set x265 encoding profile. > Addresses ticket #6894. > Please just name the option "profile" to stay consistent with all the other encoders. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change.
what is V1 and V2? On Tue, Dec 5, 2017 at 11:03 AM, Jun Zhao wrote: > ping ? > > On 2017/11/30 7:53, Jun Zhao wrote: > > V2: fix the V1 lead to webp crash issue. > > ___ > 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] avfilter/formats: fix wrong function name in error message
I prefer option 1). and microsoft vc++ uspport __FUNCTION__ On Tue, Dec 5, 2017 at 1:42 PM, Jun Zhao wrote: > > > On 2017/12/5 2:32, Michael Niedermayer wrote: > > On Mon, Dec 04, 2017 at 11:07:11AM +0100, Hendrik Leppkes wrote: > >> On Mon, Dec 4, 2017 at 10:53 AM, Moritz Barsnick > wrote: > >>> On Mon, Dec 04, 2017 at 13:02:20 +0800, Jun Zhao wrote: > Use perdefined micro __FUNCTION__ rather than hard coding function > name > to fix wrong function name in error message. > >>> AFAICT, "__FUNCTION__" is a C99 feature and thereby not supported by > >>> ffmpeg style. Or should it be? (It might be "supported by all compilers > >>> we care about".) > >>> > >>> http://ffmpeg.org/developer.html#C-language-features > >>> > >> __FUNCTION__ is not C99, its a compiler extension (which is understood > >> by GCC and some other compilers). __func__ is the C99 keyword. > >> Its likely that not all compilers we currently support would have > >> __func__, if they all have __FUNCTION__ however I cannot tell. > > There are some matches for __FUNCTION__ in git, so i wonder if all > > compilers we support do support it > So now we have 2 option: > > 1). Find a ways to get the current function on different platforms in > C90, > https://stackoverflow.com/questions/7008485/func-or- > function-or-manual-const-char-id > have some information for this way. （lot of #if defined ） > 2). Just remove __FUNCTION__ from the code. Total 5 __FUNCTION__ in > source code when grep the code. > > Personally, I prefer option 2 than option 1， any comments? > > > > [...] > > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix wrong function name in error message
On Tue, Dec 5, 2017 at 6:42 AM, Jun Zhao wrote: > > > On 2017/12/5 2:32, Michael Niedermayer wrote: >> On Mon, Dec 04, 2017 at 11:07:11AM +0100, Hendrik Leppkes wrote: >>> On Mon, Dec 4, 2017 at 10:53 AM, Moritz Barsnick wrote: On Mon, Dec 04, 2017 at 13:02:20 +0800, Jun Zhao wrote: > Use perdefined micro __FUNCTION__ rather than hard coding function name > to fix wrong function name in error message. AFAICT, "__FUNCTION__" is a C99 feature and thereby not supported by ffmpeg style. Or should it be? (It might be "supported by all compilers we care about".) http://ffmpeg.org/developer.html#C-language-features >>> __FUNCTION__ is not C99, its a compiler extension (which is understood >>> by GCC and some other compilers). __func__ is the C99 keyword. >>> Its likely that not all compilers we currently support would have >>> __func__, if they all have __FUNCTION__ however I cannot tell. >> There are some matches for __FUNCTION__ in git, so i wonder if all >> compilers we support do support it > So now we have 2 option: > > 1). Find a ways to get the current function on different platforms in > C90, > https://stackoverflow.com/questions/7008485/func-or-function-or-manual-const-char-id > have some information for this way. （lot of #if defined ） > 2). Just remove __FUNCTION__ from the code. Total 5 __FUNCTION__ in > source code when grep the code. > > Personally, I prefer option 2 than option 1， any comments? If __FUNCTION__ is already in use right now (and hence supported by all compilers we have), it should be fine to use it again, so no need for complex ifdefs, I would think. In fact I just checked, and its in use in a key part in avformat, not even an optional module, so any compiler not supporting it would already fail building it now. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/5/2017 2:33 PM, Hendrik Leppkes wrote:
Please just name the option "profile" to stay consistent with all the
other encoders.
Revised patch attached.
From bbb8013e7404360139a13b58a377a29d3ca69552 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265 - Add named option to set profile
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
---
libavcodec/libx265.c | 10 ++
libavcodec/version.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..64250ded62 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -45,6 +45,7 @@ typedef struct libx265Context {
int forced_idr;
char *preset;
char *tune;
+char *profile;
char *x265_opts;
} libx265Context;
@@ -220,6 +221,14 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
}
+if (ctx->profile) {
+if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set :
%s.\n", ctx->profile);
+av_log(avctx, AV_LOG_INFO, "Profile must match bit depth and
chroma sampling of output stream.\n");
+return AVERROR(EINVAL);
+}
+}
+
ctx->encoder = ctx->api->encoder_open(ctx->params);
if (!ctx->encoder) {
av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -392,6 +401,7 @@ static const AVOption options[] = {
{ "forced-idr", "if forcing keyframes, force them as IDR frames",
OFFSET(forced_idr),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, VE },
{ "preset", "set the x265 preset",
OFFSET(preset),AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "tune","set the x265 tune parameter",
OFFSET(tune), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "set the x265 profile",
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "x265-params", "set the x265 configuration using a :-separated list of
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d67b689142..3b5c3000be 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 6
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MICRO 103
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
i approve On Tue, Dec 5, 2017 at 5:22 PM, Gyan Doshi wrote: > > On 12/5/2017 2:33 PM, Hendrik Leppkes wrote: > >> >> Please just name the option "profile" to stay consistent with all the >> other encoders. >> > > Revised patch attached. > > ___ > 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] Add doc on ffmpeg-devel, update on -cvslog list (v3)
Hi, On Mon, Dec 4, 2017 at 4:43 AM Carl Eugen Hoyos wrote: > The patch is not ok, Carl Eugen It is clear that you have no respect for community consensus. 9 for removal of mandatory status (10 counting myself): TR: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220272.html PBM: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220441.html RB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221152.html RP: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221155.html CB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221204.html DB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221695.html HL: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221697.html wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221727.html LL: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221729.html 2 neutral: MT: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221174.html (personally uses -cvslog but "try to reply to -devel") MN: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221387.html (encourage subscription rather than require it) 1 against: You. As the Documentation maintainer, this patch LGTM. With community consensus, this is thusly applied. Thanks to you all. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
> After some tests:
> 1) #undef far
> after #include is wrong -- in oleauto.h is declaration
> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> and 'FAR' is defined as 'far' which is define as empty.
Yeah generally undefing all of them might result in errors in other
windows headers, so thats bad.
>
> 2) #undef near
> after #include works in ffmpeg but is danger -- see 1)
Doing it rather late, ie. right before its used in the file should be
relatively safe. If not, we can always rename the variable.
But it seems to work so far. And from the nature of this bug, it
should just error out instead of resulting in other breakage - if it
happens.
>
> 3) after
> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
> git revert 590136e78da3d091ea99ab5432543d47a559a461
> and patch
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> -MXFPackage packages[2] = {};
> +MXFPackage packages[2] = {{NULL}};
> VS 2017 can compile ffmpeg and fate stops at audiomatch-nero-16000-mono-he-m4a
> (without reverting 590136e hangs at api-flac-test.exe)
>
> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
> we can apply this patch and
We can't really revert those, so fixing them is better.
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..b34a3803b8 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
> AVLockOp op))
>
> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> {
> -_Bool exp = 0;
> +atomic_bool exp = 0;
> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
> return 0;
>
> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
> AVCodec *codec)
>
> int ff_unlock_avcodec(const AVCodec *codec)
> {
> -_Bool exp = 1;
> +atomic_bool exp = 1;
> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
> return 0;
>
>
atomic_compare_exchange* usage is a bit iffy because it uses pointers,
and the compat wrappers don't fully represent all types properly (for
simplicity, implementing them in a generic way would be madness).
So this work-around seems fine to me, if it builds with GCC as well.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate/hevc: add skip_loop_filter test
On 04.12.2017 at 18:49 Michael Niedermayer wrote:
> will apply
>
> can you add a fate test for this ?
>
> thanks
>
> [...]
Sure.
I've picked a random sample where skip_loop_filter={nokey,all} had
different output. Hope that's fine.
From 2f4e5bf1e37d0fbfce0631ebb8e7011b5f8128f1 Mon Sep 17 00:00:00 2001
From: sfan5
Date: Tue, 5 Dec 2017 12:47:47 +0100
Subject: [PATCH] fate/hevc: add skip_loop_filter test
---
tests/fate/hevc.mak| 3 +++
tests/ref/fate/hevc-skiploopfilter | 14 ++
2 files changed, 17 insertions(+)
create mode 100644 tests/ref/fate/hevc-skiploopfilter
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 5a3c156ee6..0e8859307d 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -239,6 +239,9 @@ fate-hevc-bsf-mp4toannexb: CMD = md5 -i $(TARGET_PATH)/tests/data/hevc-mp4.mov -
fate-hevc-bsf-mp4toannexb: CMP = oneline
fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
+fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact
+FATE_HEVC += fate-hevc-skiploopfilter
+
FATE_HEVC-$(call DEMDEC, HEVC, HEVC) += $(FATE_HEVC)
# this sample has two stsd entries and needs to reload extradata
diff --git a/tests/ref/fate/hevc-skiploopfilter b/tests/ref/fate/hevc-skiploopfilter
new file mode 100644
index 00..9c29909c51
--- /dev/null
+++ b/tests/ref/fate/hevc-skiploopfilter
@@ -0,0 +1,14 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+#stream#, dts,pts, duration, size, hash
+0, 0, 0,1, 3110400, 076c9288843ef1197a8cbef7f9a13fee
+0, 1, 1,1, 3110400, 6190eeea952805ebde69d22961aaeb45
+0, 2, 2,1, 3110400, 9aaa5111d5e6b25dcf5ddd19c58f17f7
+0, 3, 3,1, 3110400, 52a487e5f71b314e33e6632b4496f0a6
+0, 4, 4,1, 3110400, 13abb1c78313705b57a8298dc1e6c0e2
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/5/2017 9:22 AM, Gyan Doshi wrote:
> Revised patch attached.
[...]
> From bbb8013e7404360139a13b58a377a29d3ca69552 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Tue, 5 Dec 2017 13:17:53 +0530
> Subject: [PATCH] avcodec/libx265 - Add named option to set profile
>
> Adds call to x265_param_apply_profile after x265_param_parse.
> Added as private option since HEVC profiles other than
> Main, Main 10 and MSP in AVCodecContext are consolidated in a single
> constant.
This is inconsistent with the way libx264.c does it. It calls the profile
function before the param parsing.
> +if (ctx->profile) {
> +if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set
> : %s.\n", ctx->profile);
> +av_log(avctx, AV_LOG_INFO, "Profile must match bit depth and
> chroma sampling of output stream.\n");
Drop the second log line.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
On 12/5/2017 12:38 AM, Michael Niedermayer wrote: > Noone is known to work on fixing this, so it should be disabled > > Signed-off-by: Michael Niedermayer > --- > tests/fate/mov.mak | 1 - > 1 file changed, 1 deletion(-) *NAK* Disabling failing tests entirely defeats the point of having test! The commit that broke it should be reverted until the author of that commit can explain why it changed, or fix it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/5/2017 7:21 PM, Derek Buitenhuis wrote: This is inconsistent with the way libx264.c does it. It calls the profile function before the param parsing. From http://x265.readthedocs.io/en/default/cli.html#profile-level-tier "API users must call x265_param_apply_profile() after configuring their param structure. Any changes made to the param structure after this call might make the encode non-compliant." and "Also note that x265 determines the decoder requirement profile and level in three steps. First, the user configures an x265_param structure with their suggested encoder options and then optionally calls x265_param_apply_profile() to enforce a specific profile (main, main10, etc). " Will drop 2nd log line. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/5/2017 2:05 PM, Gyan Doshi wrote: > > On 12/5/2017 7:21 PM, Derek Buitenhuis wrote: > >> This is inconsistent with the way libx264.c does it. It calls the profile >> function before the param parsing. > > From http://x265.readthedocs.io/en/default/cli.html#profile-level-tier > > "API users must call x265_param_apply_profile() after configuring their > param structure. Any changes made to the param structure after this call > might make the encode non-compliant." > > and > > "Also note that x265 determines the decoder requirement profile and > level in three steps. First, the user configures an x265_param structure > with their suggested encoder options and then optionally calls > x265_param_apply_profile() to enforce a specific profile (main, main10, > etc). " Sounds like a very good reason to me, then. Patch OK with log line dropped. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/5/2017 7:37 PM, Derek Buitenhuis wrote:
Patch OK with log line dropped.
Revised patch v2 attached.
Thanks,
Gyan
From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265 - Add named option to set profile
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
---
libavcodec/libx265.c | 9 +
libavcodec/version.h | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..4058deac1c 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -45,6 +45,7 @@ typedef struct libx265Context {
int forced_idr;
char *preset;
char *tune;
+char *profile;
char *x265_opts;
} libx265Context;
@@ -220,6 +221,13 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
}
+if (ctx->profile) {
+if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set :
%s.\n", ctx->profile);
+return AVERROR(EINVAL);
+}
+}
+
ctx->encoder = ctx->api->encoder_open(ctx->params);
if (!ctx->encoder) {
av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -392,6 +400,7 @@ static const AVOption options[] = {
{ "forced-idr", "if forcing keyframes, force them as IDR frames",
OFFSET(forced_idr),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, VE },
{ "preset", "set the x265 preset",
OFFSET(preset),AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "tune","set the x265 tune parameter",
OFFSET(tune), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "set the x265 profile",
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "x265-params", "set the x265 configuration using a :-separated list of
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d67b689142..3b5c3000be 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 6
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MICRO 103
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/4/2017 8:31 PM, Mateusz wrote:
> After some tests:
> 1) #undef far
> after #include is wrong -- in oleauto.h is declaration
> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> and 'FAR' is defined as 'far' which is define as empty.
>
> 2) #undef near
> after #include works in ffmpeg but is danger -- see 1)
>
> 3) after
> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
> git revert 590136e78da3d091ea99ab5432543d47a559a461
> and patch
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> -MXFPackage packages[2] = {};
> +MXFPackage packages[2] = {{NULL}};
> VS 2017 can compile ffmpeg and fate stops at audiomatch-nero-16000-mono-he-m4a
> (without reverting 590136e hangs at api-flac-test.exe)
>
> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
> we can apply this patch and
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..b34a3803b8 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
> AVLockOp op))
>
> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> {
> -_Bool exp = 0;
> +atomic_bool exp = 0;
> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
> return 0;
>
> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
> AVCodec *codec)
>
> int ff_unlock_avcodec(const AVCodec *codec)
> {
> -_Bool exp = 1;
> +atomic_bool exp = 1;
No, these are not meant to be atomic.
_Bool is c99, so maybe we could replace its usage with int in these lock
functions. The result will be the exact same.
> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
> return 0;
>
>
> Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] configure: require external ffnvcodec headers
On Mon, Dec 04, 2017 at 08:41:42PM +0100, Timo Rothenpieler wrote: > The external headers can be found at > https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git > --- > configure | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) i cloned the repo referenced and did a make install but ./configure --enable-nvenc ERROR: nvenc requested, but not all dependencies are satisfied: cuda ls -alF /usr/local/include/ffnvcodec/ ls: cannot open directory /usr/local/include/ffnvcodec/: Permission denied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
> On 12/4/2017 8:31 PM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is define as empty.
>>
>> 2) #undef near
>> after #include works in ffmpeg but is danger -- see 1)
>>
>> 3) after
>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>> and patch
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> -MXFPackage packages[2] = {};
>> +MXFPackage packages[2] = {{NULL}};
>> VS 2017 can compile ffmpeg and fate stops at
>> audiomatch-nero-16000-mono-he-m4a
>> (without reverting 590136e hangs at api-flac-test.exe)
>>
>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>> we can apply this patch and
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..b34a3803b8 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>> AVLockOp op))
>>
>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>> {
>> -_Bool exp = 0;
>> +atomic_bool exp = 0;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>> AVCodec *codec)
>>
>> int ff_unlock_avcodec(const AVCodec *codec)
>> {
>> -_Bool exp = 1;
>> +atomic_bool exp = 1;
>
> No, these are not meant to be atomic.
>
int will also not work, since you would pass a pointer to an int to
something that expects a pointer to intptr_t.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>>> and 'FAR' is defined as 'far' which is define as empty.
>>>
>>> 2) #undef near
>>> after #include works in ffmpeg but is danger -- see 1)
>>>
>>> 3) after
>>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>>> and patch
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> -MXFPackage packages[2] = {};
>>> +MXFPackage packages[2] = {{NULL}};
>>> VS 2017 can compile ffmpeg and fate stops at
>>> audiomatch-nero-16000-mono-he-m4a
>>> (without reverting 590136e hangs at api-flac-test.exe)
>>>
>>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>>> we can apply this patch and
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index baf09119fe..b34a3803b8 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>>> AVLockOp op))
>>>
>>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>> {
>>> -_Bool exp = 0;
>>> +atomic_bool exp = 0;
>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>> !codec->init)
>>> return 0;
>>>
>>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>>> AVCodec *codec)
>>>
>>> int ff_unlock_avcodec(const AVCodec *codec)
>>> {
>>> -_Bool exp = 1;
>>> +atomic_bool exp = 1;
>>
>> No, these are not meant to be atomic.
>>
>
> int will also not work, since you would pass a pointer to an int to
> something that expects a pointer to intptr_t.
>
> - Hendrik
So it's not a problem of _Bool being undefined in msvc? Sounds like the
win32 stdatomic.h wrapper are not correct, then. This was not an issue
with the old lavu wrapper.
Why does it use intptr_t at all for that matter? Why not the types the
gcc wrapper uses?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
W dniu 05.12.2017 o 15:20, James Almer pisze:
> On 12/4/2017 8:31 PM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is define as empty.
>>
>> 2) #undef near
>> after #include works in ffmpeg but is danger -- see 1)
>>
>> 3) after
>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>> and patch
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> -MXFPackage packages[2] = {};
>> +MXFPackage packages[2] = {{NULL}};
>> VS 2017 can compile ffmpeg and fate stops at
>> audiomatch-nero-16000-mono-he-m4a
>> (without reverting 590136e hangs at api-flac-test.exe)
>>
>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>> we can apply this patch and
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..b34a3803b8 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>> AVLockOp op))
>>
>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>> {
>> -_Bool exp = 0;
>> +atomic_bool exp = 0;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>> AVCodec *codec)
>>
>> int ff_unlock_avcodec(const AVCodec *codec)
>> {
>> -_Bool exp = 1;
>> +atomic_bool exp = 1;
>
> No, these are not meant to be atomic.
>
> _Bool is c99, so maybe we could replace its usage with int in these lock
> functions. The result will be the exact same.
In atomic types the main thing is width (sizeof).
In atomic operations destination memory MUST BE sufficient
to copy all bytes from source, in
atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1)
sizeof(exp) MUST BE >= sizeof(ff_avcodec_locked) == sizeof(atomic_bool)
In ffmpeg implementation of atomic code for MSVC sizeof(atomic_bool) == 8
and sizeof(_Bool) < 8 -- it is the reason of hangs.
And all volatile objects MUST BE explicitly volatile -- instead of
static atomic_bool ff_avcodec_locked;
should be
static volatile atomic_bool ff_avcodec_locked;
I will prepare a patch (but not before Friday -- lots of work).
Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/5/2017 1:40 PM, Mateusz wrote:
> W dniu 05.12.2017 o 15:20, James Almer pisze:
>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>>> and 'FAR' is defined as 'far' which is define as empty.
>>>
>>> 2) #undef near
>>> after #include works in ffmpeg but is danger -- see 1)
>>>
>>> 3) after
>>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>>> and patch
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> -MXFPackage packages[2] = {};
>>> +MXFPackage packages[2] = {{NULL}};
>>> VS 2017 can compile ffmpeg and fate stops at
>>> audiomatch-nero-16000-mono-he-m4a
>>> (without reverting 590136e hangs at api-flac-test.exe)
>>>
>>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>>> we can apply this patch and
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index baf09119fe..b34a3803b8 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>>> AVLockOp op))
>>>
>>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>> {
>>> -_Bool exp = 0;
>>> +atomic_bool exp = 0;
>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>> !codec->init)
>>> return 0;
>>>
>>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>>> AVCodec *codec)
>>>
>>> int ff_unlock_avcodec(const AVCodec *codec)
>>> {
>>> -_Bool exp = 1;
>>> +atomic_bool exp = 1;
>>
>> No, these are not meant to be atomic.
>>
>> _Bool is c99, so maybe we could replace its usage with int in these lock
>> functions. The result will be the exact same.
>
> In atomic types the main thing is width (sizeof).
> In atomic operations destination memory MUST BE sufficient
> to copy all bytes from source, in
> atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1)
> sizeof(exp) MUST BE >= sizeof(ff_avcodec_locked) == sizeof(atomic_bool)
>
> In ffmpeg implementation of atomic code for MSVC sizeof(atomic_bool) == 8
> and sizeof(_Bool) < 8 -- it is the reason of hangs.
>
> And all volatile objects MUST BE explicitly volatile -- instead of
> static atomic_bool ff_avcodec_locked;
> should be
> static volatile atomic_bool ff_avcodec_locked;
No, the win32 wrapper should add volatile to the atomic_* typedefs if
anything. No other implementation needs it, so it must not be used here.
>
> I will prepare a patch (but not before Friday -- lots of work).
>
> Mateusz
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 5 December 2017 at 16:40, Mateusz wrote:
> W dniu 05.12.2017 o 15:20, James Almer pisze:
> > On 12/4/2017 8:31 PM, Mateusz wrote:
> >> After some tests:
> >> 1) #undef far
> >> after #include is wrong -- in oleauto.h is declaration
> >> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> >> and 'FAR' is defined as 'far' which is define as empty.
> >>
> >> 2) #undef near
> >> after #include works in ffmpeg but is danger -- see 1)
> >>
> >> 3) after
> >> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
> >> git revert 590136e78da3d091ea99ab5432543d47a559a461
> >> and patch
> >> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> >> -MXFPackage packages[2] = {};
> >> +MXFPackage packages[2] = {{NULL}};
> >> VS 2017 can compile ffmpeg and fate stops at
> audiomatch-nero-16000-mono-he-m4a
> >> (without reverting 590136e hangs at api-flac-test.exe)
> >>
> >> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
> >> we can apply this patch and
> >> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >> index baf09119fe..b34a3803b8 100644
> >> --- a/libavcodec/utils.c
> >> +++ b/libavcodec/utils.c
> >> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex,
> enum AVLockOp op))
> >>
> >> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> >> {
> >> -_Bool exp = 0;
> >> +atomic_bool exp = 0;
> >> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> !codec->init)
> >> return 0;
> >>
> >> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
> const AVCodec *codec)
> >>
> >> int ff_unlock_avcodec(const AVCodec *codec)
> >> {
> >> -_Bool exp = 1;
> >> +atomic_bool exp = 1;
> >
> > No, these are not meant to be atomic.
> >
> > _Bool is c99, so maybe we could replace its usage with int in these lock
> > functions. The result will be the exact same.
>
> In atomic types the main thing is width (sizeof).
> In atomic operations destination memory MUST BE sufficient
> to copy all bytes from source, in
> atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1)
> sizeof(exp) MUST BE >= sizeof(ff_avcodec_locked) == sizeof(atomic_bool)
>
> In ffmpeg implementation of atomic code for MSVC sizeof(atomic_bool) == 8
> and sizeof(_Bool) < 8 -- it is the reason of hangs.
>
> And all volatile objects MUST BE explicitly volatile -- instead of
> static atomic_bool ff_avcodec_locked;
> should be
> static volatile atomic_bool ff_avcodec_locked;
>
> I will prepare a patch (but not before Friday -- lots of work).
>
> Mateusz
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
That last thing belongs in the compat header rather than globablly in the
code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Tue, Dec 5, 2017 at 5:25 PM, James Almer wrote:
> On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
>> On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
>>> On 12/4/2017 8:31 PM, Mateusz wrote:
After some tests:
1) #undef far
after #include is wrong -- in oleauto.h is declaration
WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
and 'FAR' is defined as 'far' which is define as empty.
2) #undef near
after #include works in ffmpeg but is danger -- see 1)
3) after
git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
git revert 590136e78da3d091ea99ab5432543d47a559a461
and patch
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
-MXFPackage packages[2] = {};
+MXFPackage packages[2] = {{NULL}};
VS 2017 can compile ffmpeg and fate stops at
audiomatch-nero-16000-mono-he-m4a
(without reverting 590136e hangs at api-flac-test.exe)
4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
we can apply this patch and
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index baf09119fe..b34a3803b8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
AVLockOp op))
int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
{
-_Bool exp = 0;
+atomic_bool exp = 0;
if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
return 0;
@@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
AVCodec *codec)
int ff_unlock_avcodec(const AVCodec *codec)
{
-_Bool exp = 1;
+atomic_bool exp = 1;
>>>
>>> No, these are not meant to be atomic.
>>>
>>
>> int will also not work, since you would pass a pointer to an int to
>> something that expects a pointer to intptr_t.
>>
>> - Hendrik
>
> So it's not a problem of _Bool being undefined in msvc? Sounds like the
> win32 stdatomic.h wrapper are not correct, then. This was not an issue
> with the old lavu wrapper.
>
I don't know why atomic_compare_exchange* was implemented as a static
function and all types defined to the same type, instead of a macro
(like the GCC emulation).
In C++ you would use templates to handle all types, in C .. not sure
such mechanics exist.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
W dniu 05.12.2017 o 17:44, James Almer pisze:
> On 12/5/2017 1:40 PM, Mateusz wrote:
>> W dniu 05.12.2017 o 15:20, James Almer pisze:
>>> On 12/4/2017 8:31 PM, Mateusz wrote:
After some tests:
1) #undef far
after #include is wrong -- in oleauto.h is declaration
WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
and 'FAR' is defined as 'far' which is define as empty.
2) #undef near
after #include works in ffmpeg but is danger -- see 1)
3) after
git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
git revert 590136e78da3d091ea99ab5432543d47a559a461
and patch
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
-MXFPackage packages[2] = {};
+MXFPackage packages[2] = {{NULL}};
VS 2017 can compile ffmpeg and fate stops at
audiomatch-nero-16000-mono-he-m4a
(without reverting 590136e hangs at api-flac-test.exe)
4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
we can apply this patch and
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index baf09119fe..b34a3803b8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
AVLockOp op))
int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
{
-_Bool exp = 0;
+atomic_bool exp = 0;
if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
return 0;
@@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
AVCodec *codec)
int ff_unlock_avcodec(const AVCodec *codec)
{
-_Bool exp = 1;
+atomic_bool exp = 1;
>>>
>>> No, these are not meant to be atomic.
>>>
>>> _Bool is c99, so maybe we could replace its usage with int in these lock
>>> functions. The result will be the exact same.
>>
>> In atomic types the main thing is width (sizeof).
>> In atomic operations destination memory MUST BE sufficient
>> to copy all bytes from source, in
>> atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1)
>> sizeof(exp) MUST BE >= sizeof(ff_avcodec_locked) == sizeof(atomic_bool)
>>
>> In ffmpeg implementation of atomic code for MSVC sizeof(atomic_bool) == 8
>> and sizeof(_Bool) < 8 -- it is the reason of hangs.
>>
>> And all volatile objects MUST BE explicitly volatile -- instead of
>> static atomic_bool ff_avcodec_locked;
>> should be
>> static volatile atomic_bool ff_avcodec_locked;
>
> No, the win32 wrapper should add volatile to the atomic_* typedefs if
> anything. No other implementation needs it, so it must not be used here.
Yes, you are right -- it should work not only in Windows. It is a bit tricky...
In Linux stdatomic.h looks quite different than ffmpeg win32/gcc wrappers.
Now I have no opinion how it should be done right.
Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add doc on ffmpeg-devel, update on -cvslog list (v3)
On 2017-12-05 02:07, Timothy Gu wrote: Hi, [...] As the Documentation maintainer, this patch LGTM. With community consensus, this is thusly applied. Thanks to you all. Timothy Thank you, Timothy, and everyone who participated in this discussion. The end product is a small change to the documentation, but I think it is a high-impact fix for new contributors who are trying to figure out how the ffmpeg project works and how they can plug in to the process. As a bonus, it was also, for this new contributor, a real education in how the project works. Now if you'll excuse me, I'm going to take this wonderful tool and convert some audio and video content from one format to another. -- --Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 355-1027 Davie St, Vancouver BC V6E 4L2, Canada Canada mobile +1-604-376-8953 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
W dniu 05.12.2017 o 12:12, Hendrik Leppkes pisze:
> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is define as empty.
>
> Yeah generally undefing all of them might result in errors in other
> windows headers, so thats bad.
>
>>
>> 2) #undef near
>> after #include works in ffmpeg but is danger -- see 1)
>
> Doing it rather late, ie. right before its used in the file should be
> relatively safe. If not, we can always rename the variable.
> But it seems to work so far. And from the nature of this bug, it
> should just error out instead of resulting in other breakage - if it
> happens.
>
>>
>> 3) after
>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>> and patch
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> -MXFPackage packages[2] = {};
>> +MXFPackage packages[2] = {{NULL}};
>> VS 2017 can compile ffmpeg and fate stops at
>> audiomatch-nero-16000-mono-he-m4a
>> (without reverting 590136e hangs at api-flac-test.exe)
>>
>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>> we can apply this patch and
>
> We can't really revert those, so fixing them is better.
>
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..b34a3803b8 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>> AVLockOp op))
>>
>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>> {
>> -_Bool exp = 0;
>> +atomic_bool exp = 0;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>> AVCodec *codec)
>>
>> int ff_unlock_avcodec(const AVCodec *codec)
>> {
>> -_Bool exp = 1;
>> +atomic_bool exp = 1;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>>
>
> atomic_compare_exchange* usage is a bit iffy because it uses pointers,
> and the compat wrappers don't fully represent all types properly (for
> simplicity, implementing them in a generic way would be madness).
> So this work-around seems fine to me, if it builds with GCC as well.
>
> - Hendrik
Thanks for review.
I will try to write patches that not break ffmpeg on Linux
and will work with MSVC -- now it looks to me more complicated
than before but it should be possible.
Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
On Tue, Dec 05, 2017 at 01:54:27PM +, Derek Buitenhuis wrote: > On 12/5/2017 12:38 AM, Michael Niedermayer wrote: > > Noone is known to work on fixing this, so it should be disabled > > > > Signed-off-by: Michael Niedermayer > > --- > > tests/fate/mov.mak | 1 - > > 1 file changed, 1 deletion(-) > > *NAK* > > Disabling failing tests entirely defeats the point of having test! > > The commit that broke it should be reverted until the author > of that commit can explain why it changed, or fix it. The commit that added the test was the one that broke fate. It never worked. So this "sort of" reverts what caused the issue. Ill make this more clear in the commit message in case you otherwise agree to the change ? I can also exactly revert the commit that added the test if thats preferred? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is define as empty.
>
> Yeah generally undefing all of them might result in errors in other
> windows headers, so thats bad.
>
>>
>> 2) #undef near
>> after #include works in ffmpeg but is danger -- see 1)
>
> Doing it rather late, ie. right before its used in the file should be
> relatively safe. If not, we can always rename the variable.
> But it seems to work so far. And from the nature of this bug, it
> should just error out instead of resulting in other breakage - if it
> happens.
>
>>
>> 3) after
>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>> and patch
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> -MXFPackage packages[2] = {};
>> +MXFPackage packages[2] = {{NULL}};
>> VS 2017 can compile ffmpeg and fate stops at
>> audiomatch-nero-16000-mono-he-m4a
>> (without reverting 590136e hangs at api-flac-test.exe)
>>
>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>> we can apply this patch and
>
> We can't really revert those, so fixing them is better.
>
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..b34a3803b8 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>> AVLockOp op))
>>
>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>> {
>> -_Bool exp = 0;
>> +atomic_bool exp = 0;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>> AVCodec *codec)
>>
>> int ff_unlock_avcodec(const AVCodec *codec)
>> {
>> -_Bool exp = 1;
>> +atomic_bool exp = 1;
>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>> return 0;
>>
>>
>
> atomic_compare_exchange* usage is a bit iffy because it uses pointers,
> and the compat wrappers don't fully represent all types properly (for
> simplicity, implementing them in a generic way would be madness).
> So this work-around seems fine to me, if it builds with GCC as well.
GCC may accept it (No idea what code it would generate, though), but
chances are Clang will complain since it's stricter about correct type
usage in these functions, and making the variable to be passed as the
"expected" parameter atomic is not correct.
>
> - Hendrik
> ___
> 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] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
>> The commit that broke it should be reverted until the author >> of that commit can explain why it changed, or fix it. > > The commit that added the test was the one that broke fate. It never > worked. > So this "sort of" reverts what caused the issue. Wasn't the code it tests added directly before the commit that added this test? That's the code that is broken. The way I see it, the code is workaround for broken files, but it doesn't actually work. It should either be fixed, or the workaround removed if nobody (especially the author) is willing to fix it. > Ill make this more clear in the commit message in case you otherwise > agree to the change ? > > I can also exactly revert > the commit that added the test if thats preferred? See above. As I stated before, the entire point of tests is to show something is broken. They make FATE red so someone will fix it. Disabling the test demeans the entire point of having tests - if nobody is willing to fix the broken code it tests, that broken could should be removed, or not have been committed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Tue, Dec 5, 2017 at 8:23 PM, James Almer wrote:
> On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
>> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>>> and 'FAR' is defined as 'far' which is define as empty.
>>
>> Yeah generally undefing all of them might result in errors in other
>> windows headers, so thats bad.
>>
>>>
>>> 2) #undef near
>>> after #include works in ffmpeg but is danger -- see 1)
>>
>> Doing it rather late, ie. right before its used in the file should be
>> relatively safe. If not, we can always rename the variable.
>> But it seems to work so far. And from the nature of this bug, it
>> should just error out instead of resulting in other breakage - if it
>> happens.
>>
>>>
>>> 3) after
>>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
>>> git revert 590136e78da3d091ea99ab5432543d47a559a461
>>> and patch
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> -MXFPackage packages[2] = {};
>>> +MXFPackage packages[2] = {{NULL}};
>>> VS 2017 can compile ffmpeg and fate stops at
>>> audiomatch-nero-16000-mono-he-m4a
>>> (without reverting 590136e hangs at api-flac-test.exe)
>>>
>>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
>>> we can apply this patch and
>>
>> We can't really revert those, so fixing them is better.
>>
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index baf09119fe..b34a3803b8 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum
>>> AVLockOp op))
>>>
>>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>> {
>>> -_Bool exp = 0;
>>> +atomic_bool exp = 0;
>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>> !codec->init)
>>> return 0;
>>>
>>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
>>> AVCodec *codec)
>>>
>>> int ff_unlock_avcodec(const AVCodec *codec)
>>> {
>>> -_Bool exp = 1;
>>> +atomic_bool exp = 1;
>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>> !codec->init)
>>> return 0;
>>>
>>>
>>
>> atomic_compare_exchange* usage is a bit iffy because it uses pointers,
>> and the compat wrappers don't fully represent all types properly (for
>> simplicity, implementing them in a generic way would be madness).
>> So this work-around seems fine to me, if it builds with GCC as well.
>
> GCC may accept it (No idea what code it would generate, though), but
> chances are Clang will complain since it's stricter about correct type
> usage in these functions, and making the variable to be passed as the
> "expected" parameter atomic is not correct.
>
Why does this code use atomics anyway?
The actual locking is done using a lock manager, and it warns/errors
when the lock functions are used concurrently without locking.
So, perhaps we should just remove that?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/hevc_filter: implement skip_frame
On 04.12.2017 at 21:06 Carl Eugen Hoyos wrote:
> 2017-12-01 0:22 GMT+01:00 Stefan _ :
>
>> Attached patch adds full support for skip_loop_filter
>> (all levels) to the hevc decoder.
> Will you also work on -skip_frame for hevc?
>
> Carl Eugen
I gave it a try. The different levels should all work correctly, since I
compared the "effects" to a H.264 sample.
'make fate-hevc' passes.
From 8ee08adebd9994c3517c692cc99f0839d3d8f7ca Mon Sep 17 00:00:00 2001
From: sfan5
Date: Tue, 5 Dec 2017 23:26:14 +0100
Subject: [PATCH] libavcodec/hevc_filter: implement skip_frame
---
libavcodec/hevcdec.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 433a7056ea..37f2ad76eb 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2905,6 +2905,13 @@ static int decode_nal_unit(HEVCContext *s, const H2645NAL *nal)
if (ret < 0)
return ret;
+if (
+(s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == HEVC_SLICE_B) ||
+(s->avctx->skip_frame >= AVDISCARD_NONINTRA && s->sh.slice_type != HEVC_SLICE_I) ||
+(s->avctx->skip_frame >= AVDISCARD_NONKEY && !IS_IDR(s))) {
+break;
+}
+
if (s->sh.first_slice_in_pic_flag) {
if (s->max_ra == INT_MAX) {
if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
@@ -3028,7 +3035,29 @@ static int decode_nal_units(HEVCContext *s, const uint8_t *buf, int length)
/* decode the NAL units */
for (i = 0; i < s->pkt.nb_nals; i++) {
-ret = decode_nal_unit(s, &s->pkt.nals[i]);
+H2645NAL *nal = &s->pkt.nals[i];
+int is_n = 0;
+
+switch (nal->type) {
+case HEVC_NAL_TRAIL_N:
+case HEVC_NAL_TSA_N:
+case HEVC_NAL_STSA_N:
+case HEVC_NAL_RADL_N:
+case HEVC_NAL_RASL_N:
+case HEVC_NAL_VCL_N10:
+case HEVC_NAL_VCL_N12:
+case HEVC_NAL_VCL_N14:
+case HEVC_NAL_BLA_N_LP:
+case HEVC_NAL_IDR_N_LP:
+is_n = 1;
+break;
+default: break;
+}
+if ((s->avctx->skip_frame >= AVDISCARD_NONREF && is_n) ||
+s->avctx->skip_frame >= AVDISCARD_ALL)
+continue;
+
+ret = decode_nal_unit(s, nal);
if (ret < 0) {
av_log(s->avctx, AV_LOG_WARNING,
"Error parsing NAL unit #%d.\n", i);
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On Tue, 5 Dec 2017 19:46:09 +0530
Gyan Doshi wrote:
> From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Tue, 5 Dec 2017 13:17:53 +0530
> Subject: [PATCH] avcodec/libx265 - Add named option to set profile
>
> Adds call to x265_param_apply_profile after x265_param_parse.
> Added as private option since HEVC profiles other than
> Main, Main 10 and MSP in AVCodecContext are consolidated in a single
> constant.
> ---
> libavcodec/libx265.c | 9 +
> libavcodec/version.h | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 4456e300f2..4058deac1c 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -45,6 +45,7 @@ typedef struct libx265Context {
> int forced_idr;
> char *preset;
> char *tune;
> +char *profile;
> char *x265_opts;
> } libx265Context;
>
> @@ -220,6 +221,13 @@ static av_cold int libx265_encode_init(AVCodecContext
> *avctx)
> }
> }
>
> +if (ctx->profile) {
> +if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set
> : %s.\n", ctx->profile);
Nit: change "set :" to "set:".
Would it be possible to list the profiles with x265_profile_names
similar to what is done for libx264?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] ffplay: use AV_PKT_FLAG_DISPOSABLE in frame drop logic
On Mon, 4 Dec 2017, John Stebbins wrote:
On 12/03/2017 01:12 PM, Marton Balint wrote:
On Thu, 30 Nov 2017, John Stebbins wrote:
---
fftools/ffplay.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 10a917194d..152d220cdb 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -198,6 +198,8 @@ typedef struct Decoder {
int64_t next_pts;
AVRational next_pts_tb;
SDL_Thread *decoder_tid;
+int drop_disposable;
+int frame_drops_disposable;
} Decoder;
typedef struct VideoState {
@@ -660,10 +662,16 @@ static int decoder_decode_frame(Decoder *d, AVFrame
*frame, AVSubtitle *sub) {
ret = got_frame ? 0 : (pkt.data ? AVERROR(EAGAIN) :
AVERROR_EOF);
}
} else {
-if (avcodec_send_packet(d->avctx, &pkt) == AVERROR(EAGAIN)) {
-av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and send_packet
both returned EAGAIN, which is an API violation.\n");
-d->packet_pending = 1;
-av_packet_move_ref(&d->pkt, &pkt);
+if (d->avctx->codec_type == AVMEDIA_TYPE_VIDEO &&
+d->drop_disposable &&
+(pkt.flags & AV_PKT_FLAG_DISPOSABLE)) {
+d->frame_drops_disposable++;
+} else {
+if (avcodec_send_packet(d->avctx, &pkt) ==
AVERROR(EAGAIN)) {
+av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and
send_packet both returned EAGAIN, which is an API violation.\n");
+d->packet_pending = 1;
+av_packet_move_ref(&d->pkt, &pkt);
+}
}
}
av_packet_unref(&pkt);
@@ -1622,6 +1630,7 @@ retry:
frame_queue_next(&is->pictq);
goto retry;
}
+is->viddec.drop_disposable = 0;
}
if (is->subtitle_st) {
@@ -1699,7 +1708,8 @@ display:
get_master_clock(is),
(is->audio_st && is->video_st) ? "A-V" : (is->video_st ? "M-V" : (is->audio_st ?
"M-A" : " ")),
av_diff,
- is->frame_drops_early + is->frame_drops_late,
+ is->frame_drops_early + is->frame_drops_late +
+ is->viddec.frame_drops_disposable,
aqsize / 1024,
vqsize / 1024,
sqsize,
@@ -1767,6 +1777,7 @@ static int get_video_frame(VideoState *is, AVFrame *frame)
is->frame_drops_early++;
av_frame_unref(frame);
got_picture = 0;
+is->viddec.drop_disposable = 1;
}
}
}
The patch looks OK now, but as I mentioned earlier, please do not enable
this kind of frame dropping by default, either introduce a separate option
"hardframedrop", or make -framedrop an integer and use "2" for this kind
of hard dropping.
I can certainly do that. But I don't really understand the reason behind it.
Frame dropping is already happening in
the scenario where this would be enabled. There are 2 types of frame dropping that
currently happen in ffplay, "early"
and "late". "Early" frame dropping happens when it is detected that the frame
is too late for it's time slot
immediately after it is decoded. "Late" frame dropping happens when it is
detected that the frame is too late when it
is removed from the display queue. Dropping disposable frames in when "early"
frame dropping is happening gives the
player a better chance of actually being able to catch up to the current time
slot because it bypasses decoding those
frames. Without it only the first few of frames get displayed with the samples
I've been testing. After those first
few, decoding is slow enough that all subsequent frames are too late and get dropped by
the "early" frame drop logic.
With disposable frame dropping, the video plays reasonably well (with a stutter
here and there).
Ok, let's keep the patch as is then.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data
I am trying to playback encrypted content. I know that libavformat
handles decryption already when using clearkey, but I want to handle
the decryption myself. The encryption info is parsed in mov.c but not
exposed to the app.
This adds some structures to hold new side-data that will hold the
info needed to decrypt. I wanted to post this first before I
implemented the code in mov.c (and probably eventually matroskadec.c
for webm).
Also, can I use the flexible array member feature, it was introduced
in C99? Would a 0-length array be better?
From 608524d302bec8a8339e8389cfbdebfd573cf75b Mon Sep 17 00:00:00 2001
From: Jacob Trimble
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avpacket: Add encryption info side data.
Signed-off-by: Jacob Trimble
---
libavcodec/avcodec.h | 65
1 file changed, 65 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..7c9b071c48 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1112,6 +1112,58 @@ typedef struct AVCPBProperties {
uint64_t vbv_delay;
} AVCPBProperties;
+/**
+ * This describes encryption info for a packet. This contains frame-specific
+ * info for how to decrypt the packet before passing it to the decoder. If this
+ * side-data is present, then the packet is encrypted.
+ *
+ * Since this uses a flexible array member, the size and layout of this type
+ * is part of the public API/ABI.
+ */
+typedef struct AVPacketEncryptionInfo {
+/** The fourcc encryption scheme. */
+char scheme[4];
+
+/** The ID of the key used to encrypt the packet. */
+uint8_t key_id[16];
+
+/** The initialization vector. */
+uint8_t iv[16];
+
+/** The size of the IV, this will either be 8 or 16. */
+int iv_size;
+
+/**
+ * Only used for pattern encryption. This is the number of 16-byte blocks
+ * that are encrypted.
+ */
+unsigned int crypt_byte_size;
+
+/**
+ * Only used for pattern encryption. This is the number of 16-byte blocks
+ * that are clear.
+ */
+unsigned int skip_byte_size;
+
+/**
+ * The number of sub-samples in this packet. If 0, then the whole sample
+ * is encrypted.
+ */
+unsigned int subsample_count;
+
+struct {
+ /** The number of bytes that are clear. */
+ unsigned int bytes_of_clear_data;
+
+ /**
+ * The number of bytes that are protected. If using pattern encryption,
+ * the pattern applies to only the protected bytes; if not using pattern
+ * encryption, all these bytes are encrypted.
+ */
+ unsigned int bytes_of_protected_data;
+} subsamples[];
+} AVPacketEncryptionInfo;
+
/**
* The decoder will keep a reference to the frame and may reuse it later.
*/
@@ -1327,6 +1379,19 @@ enum AVPacketSideDataType {
*/
AV_PKT_DATA_A53_CC,
+/**
+ * This side data is encryption "initialization data".
+ * For MP4 this is the entire 'pssh' box.
+ * For WebM this is the key ID.
+ */
+AV_PKT_DATA_ENCRYPTION_INIT_DATA,
+
+/**
+ * This side data is an AVPacketEncryptionInfo structure and contains info
+ * about how the packet is encrypted.
+ */
+AV_PKT_DATA_PACKET_ENCRYPTION_INFO,
+
/**
* The number of side data types.
* This is not part of the public API/ABI in the sense that it may
--
2.15.1.424.g9478a66081-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors
On Tue, 5 Dec 2017 22:38:11 +0100
Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 8:23 PM, James Almer wrote:
> > On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
> >> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
> >>> After some tests:
> >>> 1) #undef far
> >>> after #include is wrong -- in oleauto.h is declaration
> >>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> >>> and 'FAR' is defined as 'far' which is define as empty.
> >>
> >> Yeah generally undefing all of them might result in errors in other
> >> windows headers, so thats bad.
> >>
> >>>
> >>> 2) #undef near
> >>> after #include works in ffmpeg but is danger -- see 1)
> >>
> >> Doing it rather late, ie. right before its used in the file should be
> >> relatively safe. If not, we can always rename the variable.
> >> But it seems to work so far. And from the nature of this bug, it
> >> should just error out instead of resulting in other breakage - if it
> >> happens.
> >>
> >>>
> >>> 3) after
> >>> git revert 3701d499f8734ec5f3e7359de7311b15d92070b0
> >>> git revert 590136e78da3d091ea99ab5432543d47a559a461
> >>> and patch
> >>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> >>> -MXFPackage packages[2] = {};
> >>> +MXFPackage packages[2] = {{NULL}};
> >>> VS 2017 can compile ffmpeg and fate stops at
> >>> audiomatch-nero-16000-mono-he-m4a
> >>> (without reverting 590136e hangs at api-flac-test.exe)
> >>>
> >>> 4) if for any reasons commits 3701d49 and 590136e shouldn't be reverted,
> >>> we can apply this patch and
> >>
> >> We can't really revert those, so fixing them is better.
> >>
> >>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >>> index baf09119fe..b34a3803b8 100644
> >>> --- a/libavcodec/utils.c
> >>> +++ b/libavcodec/utils.c
> >>> @@ -1943,7 +1943,7 @@ int av_lockmgr_register(int (*cb)(void **mutex,
> >>> enum AVLockOp op))
> >>>
> >>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> >>> {
> >>> -_Bool exp = 0;
> >>> +atomic_bool exp = 0;
> >>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>> !codec->init)
> >>> return 0;
> >>>
> >>> @@ -1969,7 +1969,7 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const
> >>> AVCodec *codec)
> >>>
> >>> int ff_unlock_avcodec(const AVCodec *codec)
> >>> {
> >>> -_Bool exp = 1;
> >>> +atomic_bool exp = 1;
> >>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>> !codec->init)
> >>> return 0;
> >>>
> >>>
> >>
> >> atomic_compare_exchange* usage is a bit iffy because it uses pointers,
> >> and the compat wrappers don't fully represent all types properly (for
> >> simplicity, implementing them in a generic way would be madness).
> >> So this work-around seems fine to me, if it builds with GCC as well.
> >
> > GCC may accept it (No idea what code it would generate, though), but
> > chances are Clang will complain since it's stricter about correct type
> > usage in these functions, and making the variable to be passed as the
> > "expected" parameter atomic is not correct.
> >
>
> Why does this code use atomics anyway?
> The actual locking is done using a lock manager, and it warns/errors
> when the lock functions are used concurrently without locking.
>
> So, perhaps we should just remove that?
Well, in the mid-range, we could just drop all lock manager and atomics
code by managing the codec list like the BSF list, and finishing the
codec static init cleanup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix leak discovered via fuzzing
---
libavcodec/extract_extradata_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf.c
index ed6509c681..d40907a675 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -78,7 +78,7 @@ static int extract_extradata_h2645(AVBSFContext *ctx,
AVPacket *pkt,
ret = ff_h2645_packet_split(&h2645_pkt, pkt->data, pkt->size,
ctx, 0, 0, ctx->par_in->codec_id, 1);
if (ret < 0)
-return ret;
+goto fail;
for (i = 0; i < h2645_pkt.nb_nals; i++) {
H2645NAL *nal = &h2645_pkt.nals[i];
--
2.15.0.531.g2ccb3012c9-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data
On 12/5/2017 11:00 PM, Jacob Trimble wrote: > Also, can I use the flexible array member feature, it was introduced > in C99? Would a 0-length array be better? No, I don't think this would be OK inside a public header, unfortunately. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eof cause play fail
On Tue, Dec 05, 2017 at 11:34:12AM +0800, tiejun.peng wrote:
> 1.add warning info about corrupted atom box parsing.
> 2.atom box parsing return eof cause mov_read_close called in mov_read_header
> and user have no chance to play the file.
i think someone should cleanup the english, it sounds a bit odd
[...]
> @@ -6609,7 +6632,8 @@ static int mov_read_header(AVFormatContext *s)
> do {
> if (mov->moov_retry)
> avio_seek(pb, 0, SEEK_SET);
> -if ((err = mov_read_default(mov, pb, atom)) < 0) {
> +/* EOF don't mean the file to play fail*/
> +if ((err = mov_read_default(mov, pb, atom) && err != AVERROR_EOF) < 0) {
this does look wrong
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault)
From: ffmpeg-devel on behalf of Steven Liu
Sent: December 4, 2017 4:52 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658
(Dash demuxer segfault)
2017-12-04 12:28 GMT+08:00 Colin NG :
> ---
> libavformat/dashdec.c | 112
> --
> 1 file changed, 99 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 3798649..d04bec0 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
> return av_gettime() / 100;
> }
>
> +static char * ishttp(char *url) {
> +char *proto_name = avio_find_protocol_name(url);
> +return av_strstart(proto_name, "http", NULL);
> +}
> +
> static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char
> *datetime)
> {
> struct tm timeinfo;
> @@ -392,7 +397,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
> const char *url,
> else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
> return AVERROR_INVALIDDATA;
>
> -ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +av_freep(pb);
> +ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
> +
> if (ret >= 0) {
> // update cookies on http response with setcookies.
> char *new_cookies = NULL;
> @@ -639,6 +646,87 @@ static int
> parse_manifest_segmenttimeline(AVFormatContext *s, struct representat
> return 0;
> }
>
> +static int resolve_content_path(AVFormatContext *s, const char *url,
> xmlNodePtr *baseurl_nodes, int n_baseurl_nodes) {
> +
> +int i;
> +char *text;
> +char *tmp_str = av_mallocz(MAX_URL_SIZE);
> +char *tmp_str_2= av_mallocz(MAX_URL_SIZE);
> +
> +char *path = av_mallocz(MAX_URL_SIZE);
> +int nameSize = 0;
> +int updated = 0;
> +
> +if (!tmp_str || !tmp_str_2 || !path) {
> +updated = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +av_strlcpy(tmp_str, url, strlen(url)+1);
> +char *mpdName = strtok (tmp_str," /");
> +
> +while ((mpdName =strtok (NULL, "/"))) {
What dose this do?
The above instruction will split the url (i.e. url of the mpd file) elements
with "/" separator in between.
> +nameSize = strlen(mpdName);
> +}
> +
> +av_strlcpy (path, url, strlen(url)-nameSize+1);
> +
> +int rootId = 0;
> +xmlNodePtr *node = NULL;
> +for (rootId = n_baseurl_nodes-1; rootId >0; rootId--) {
> +if (!(node = baseurl_nodes[rootId])) {
> +continue;
> +}
> +if (ishttp(xmlNodeGetContent(node))) {
> +break;
> +}
> +}
> +
> +node = baseurl_nodes[rootId];
> +char *baseurl = xmlNodeGetContent(node);
> +char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
> +
> +if (node) {
> +xmlNodeSetContent(node, root_url);
> +}
> +
> +int size = strlen(root_url);
> +char *isRootHttp= ishttp(root_url);
> +
> +char token ='/';
> +//if (root_url[size-1]==token) {
> +if (av_strncasecmp(&root_url[size-1],&token, 1) != 0) {
If this only compare 1 char, why don't use root_url[size-1] == token ?
> +av_strlcat(root_url, "/", size+2);
> +size+=2;
> +}
> +
> +for (i = 0; i < n_baseurl_nodes; ++i) {
> +if (i==rootId) {
> +continue;
> +}
> +text = xmlNodeGetContent(baseurl_nodes[i]);
> +if (text) {
> +memset(tmp_str, 0, strlen(tmp_str));
> +
> +if (!ishttp(text) && isRootHttp) {
> +av_strlcpy(tmp_str, root_url, size+1);
> +}
> +int start = (text[0]==token) ? 1: 0;
> +memset(tmp_str_2, 0, strlen(tmp_str_2));
> +av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
> +xmlFree(text);
> +xmlNodeSetContent(baseurl_nodes[i], tmp_str);
> +updated = 1;
> +}
> +}
> +
> +end:
> +av_free(path);
> +av_free(tmp_str);
> +av_free(tmp_str_2);
> +return updated;
> +
> +}
> static int parse_manifest_representation(AVFormatContext *s, const char *url,
> xmlNodePtr node,
> xmlNodePtr adaptionset_node,
> @@ -698,6 +786,12 @@ static int parse_manifest_representation(AVFormatContext
> *s, const char *url,
> baseurl_nodes[2] = adaptionset_baseurl_node;
> baseurl_nodes[3] = representation_baseurl_node;
>
> +ret = resolve_content_path(s, url, baseurl_nodes, 4);
> +
> +if (ret == AVERROR(ENOMEM)) {
What about ret < 0 ?
> +goto end;
> +}
> +
> if (representation_segmenttemplate_node || fragment_template_node) {
> fragment_timeline_node = NULL;
> fragment_templates_tab[0] = representation_segmenttemplate
Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
On Tue, Dec 05, 2017 at 08:17:14PM +, Derek Buitenhuis wrote: > >> The commit that broke it should be reverted until the author > >> of that commit can explain why it changed, or fix it. > > > > The commit that added the test was the one that broke fate. It never > > worked. > > So this "sort of" reverts what caused the issue. > > Wasn't the code it tests added directly before the commit that added this > test? That's the code that is broken. > > The way I see it, the code is workaround for broken files, but it doesn't > actually work. It should either be fixed, or the workaround removed if > nobody (especially the author) is willing to fix it. The test produces different output on qemu arm and x86-64. From this we know there is a bug, but not where the bug is. It can be in the test, the newly added code tested or code that was there before. My guess was, its the test, i cannot logically explain why. ive looked into this now and its missing -idct, adding that makes it produce the same result here ill push a fix for this thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate/hevc: add skip_loop_filter test
On Tue, Dec 05, 2017 at 11:57:07AM +, Stefan _ wrote:
> On 04.12.2017 at 18:49 Michael Niedermayer wrote:
> > will apply
> >
> > can you add a fate test for this ?
> >
> > thanks
> >
> > [...]
> Sure.
>
> I've picked a random sample where skip_loop_filter={nokey,all} had
> different output. Hope that's fine.
>
>
> fate/hevc.mak|3 +++
> ref/fate/hevc-skiploopfilter | 14 ++
> 2 files changed, 17 insertions(+)
> 4a5a55eee404e6fbbc66440bb8577cff91840235
> 0001-fate-hevc-add-skip_loop_filter-test.patch
> From 2f4e5bf1e37d0fbfce0631ebb8e7011b5f8128f1 Mon Sep 17 00:00:00 2001
> From: sfan5
> Date: Tue, 5 Dec 2017 12:47:47 +0100
> Subject: [PATCH] fate/hevc: add skip_loop_filter test
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
can it list profiles and levels?
On Wed, Dec 6, 2017 at 6:38 AM, Lou Logan wrote:
> On Tue, 5 Dec 2017 19:46:09 +0530
> Gyan Doshi wrote:
>
> > From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
> > From: Gyan Doshi
> > Date: Tue, 5 Dec 2017 13:17:53 +0530
> > Subject: [PATCH] avcodec/libx265 - Add named option to set profile
> >
> > Adds call to x265_param_apply_profile after x265_param_parse.
> > Added as private option since HEVC profiles other than
> > Main, Main 10 and MSP in AVCodecContext are consolidated in a single
> > constant.
> > ---
> > libavcodec/libx265.c | 9 +
> > libavcodec/version.h | 2 +-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> > index 4456e300f2..4058deac1c 100644
> > --- a/libavcodec/libx265.c
> > +++ b/libavcodec/libx265.c
> > @@ -45,6 +45,7 @@ typedef struct libx265Context {
> > int forced_idr;
> > char *preset;
> > char *tune;
> > +char *profile;
> > char *x265_opts;
> > } libx265Context;
> >
> > @@ -220,6 +221,13 @@ static av_cold int libx265_encode_init(AVCodecContext
> *avctx)
> > }
> > }
> >
> > +if (ctx->profile) {
> > +if (ctx->api->param_apply_profile(ctx->params, ctx->profile) <
> 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible
> profile set : %s.\n", ctx->profile);
>
> Nit: change "set :" to "set:".
>
> Would it be possible to list the profiles with x265_profile_names
> similar to what is done for libx264?
> ___
> 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] [RFC] avcodec/avcodec.h: Add encryption info side data
On Tue, Dec 5, 2017 at 3:25 PM, Derek Buitenhuis wrote: > On 12/5/2017 11:00 PM, Jacob Trimble wrote: >> Also, can I use the flexible array member feature, it was introduced >> in C99? Would a 0-length array be better? > > No, I don't think this would be OK inside a public header, unfortunately. Would a 0-length array work? Otherwise I would need to have it be a 1-length array and have to account for that when calculating the size to allocate; it would also require a comment to ignore the size of the array. The reason I want it to be an array is because I want a variable number of elements, but I want the data contained in the struct. Since this will be extra data, AFAIK it will only be free()'d, so I can't use pointers or it will leak. Another alternative would be to still malloc more than needed and have the memory past the struct be the array. That seems like a hack, but would allow a simple free(). For example: info = malloc(sizeof(AVPacketEncryptionInfo) + sizeof(AVPacketSubsampleInfo) * num_subsamples); info.subsamples = (uint8_t*)info + sizeof(AVPacketEncryptionInfo); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] lavc/libx265: mark disposable frames
Add ifdef to support versions of x265 <= 2.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames
Used by movenc to fill sdtp box --- libavcodec/libx265.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 4456e300f2..69bfc4fdaa 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -329,6 +329,13 @@ FF_DISABLE_DEPRECATION_WARNINGS FF_ENABLE_DEPRECATION_WARNINGS #endif +#if X265_BUILD >= 130 +if (x265pic_out.sliceType == X265_TYPE_B) +#else +if (x265pic_out.frameData.sliceType == 'b') +#endif +pkt->flags |= AV_PKT_FLAG_DISPOSABLE; + *got_packet = 1; return 0; } -- 2.14.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently
On 12/6/2017 12:12 AM, Michael Niedermayer wrote: > The test produces different output on qemu arm and x86-64. > From this we know there is a bug, but not where the bug is. > It can be in the test, the newly added code tested or code that was > there before. > > My guess was, its the test, i cannot logically explain why. > > ive looked into this now and its missing -idct, adding that makes it > produce the same result here > > ill push a fix for this Thank you for taking the time to look into it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data
On 12/6/2017 12:36 AM, Jacob Trimble wrote: > Would a 0-length array work? Otherwise I would need to have it be a > 1-length array and have to account for that when calculating the size > to allocate; it would also require a comment to ignore the size of the > array. Aren't 0-length arrays a GNU extensions? If so, I would gather that it probably is not OK in a public header, either. > The reason I want it to be an array is because I want a variable > number of elements, but I want the data contained in the struct. > Since this will be extra data, AFAIK it will only be free()'d, so I > can't use pointers or it will leak. > > Another alternative would be to still malloc more than needed and have > the memory past the struct be the array. That seems like a hack, but > would allow a simple free(). For example: I'm not entirely sure what way we prefer nowadays, but you can see we've had side data with variable length members before with e.g. AV_PKT_DATA_QUALITY_STATS, but that doesn't have a struct associated with it. I'm hoping someone more up to date with the side data stuff can chime in with a suggestion on what our current best practices are for it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault) - Add function 'resolve_content_path' to propagate the baseURL from upper level nodes. * if no baseURL is availa
---
libavformat/dashdec.c | 111 --
1 file changed, 98 insertions(+), 13 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 3798649..6e35e91 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
return av_gettime() / 100;
}
+static char * ishttp(char *url) {
+char *proto_name = avio_find_protocol_name(url);
+return av_strstart(proto_name, "http", NULL);
+}
+
static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char
*datetime)
{
struct tm timeinfo;
@@ -392,7 +397,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
return AVERROR_INVALIDDATA;
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
+av_freep(pb);
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
+
if (ret >= 0) {
// update cookies on http response with setcookies.
char *new_cookies = NULL;
@@ -639,6 +646,86 @@ static int parse_manifest_segmenttimeline(AVFormatContext
*s, struct representat
return 0;
}
+static int resolve_content_path(AVFormatContext *s, const char *url,
xmlNodePtr *baseurl_nodes, int n_baseurl_nodes) {
+
+int i;
+char *text;
+char *tmp_str = av_mallocz(MAX_URL_SIZE);
+char *tmp_str_2= av_mallocz(MAX_URL_SIZE);
+
+char *path = av_mallocz(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+if (!tmp_str || !tmp_str_2 || !path) {
+updated = AVERROR(ENOMEM);
+goto end;
+}
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/"))) {
+nameSize = strlen(mpdName);
+}
+
+av_strlcpy (path, url, strlen(url)-nameSize+1);
+
+int rootId = 0;
+xmlNodePtr *node = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--) {
+if (!(node = baseurl_nodes[rootId])) {
+continue;
+}
+if (ishttp(xmlNodeGetContent(node))) {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (node) {
+xmlNodeSetContent(node, root_url);
+}
+
+int size = strlen(root_url);
+char *isRootHttp = ishttp(root_url);
+
+char token ='/';
+if (root_url[size] == token) {
+av_strlcat(root_url, "/", size+2);
+size+=2;
+}
+
+for (i = 0; i < n_baseurl_nodes; ++i) {
+if (i == rootId) {
+continue;
+}
+text = xmlNodeGetContent(baseurl_nodes[i]);
+if (text) {
+memset(tmp_str, 0, strlen(tmp_str));
+
+if (!ishttp(text) && isRootHttp) {
+av_strlcpy(tmp_str, root_url, size+1);
+}
+int start = (text[0]==token) ? 1: 0;
+memset(tmp_str_2, 0, strlen(tmp_str_2));
+av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
+xmlFree(text);
+xmlNodeSetContent(baseurl_nodes[i], tmp_str);
+updated = 1;
+}
+}
+
+end:
+av_free(path);
+av_free(tmp_str);
+av_free(tmp_str_2);
+return updated;
+
+}
static int parse_manifest_representation(AVFormatContext *s, const char *url,
xmlNodePtr node,
xmlNodePtr adaptionset_node,
@@ -698,6 +785,12 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
baseurl_nodes[2] = adaptionset_baseurl_node;
baseurl_nodes[3] = representation_baseurl_node;
+ret = resolve_content_path(s, url, baseurl_nodes, 4);
+
+if (ret == AVERROR(ENOMEM) || ret == 0) {
+goto end;
+}
+
if (representation_segmenttemplate_node || fragment_template_node) {
fragment_timeline_node = NULL;
fragment_templates_tab[0] = representation_segmenttemplate_node;
@@ -993,6 +1086,9 @@ static int parse_manifest(AVFormatContext *s, const char
*url, AVIOContext *in)
}
mpd_baseurl_node = find_child_node_by_name(node, "BaseURL");
+if (!mpd_baseurl_node) {
+mpd_baseurl_node = xmlNewNode(node, "BaseURL");
+}
// at now we can handle only one period, with the longest duration
node = xmlFirstElementChild(node);
@@ -1315,6 +1411,7 @@ static int read_from_url(struct representation *pls,
struct fragment *seg,
} else {
ret = avio_read(pls->input, buf, buf_size);
}
+
if (ret > 0)
pls->cur_seg_offset += ret;
@@ -1343,18 +1440,6 @@ static int open_input(DASHContext *c, struct
representation *pls, struct fragmen
goto cleanup;
}
-/* Seek to the requested position. If this
Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault) - Add function 'resolve_content_path' to propagate the baseURL from upper level nodes. * if no baseURL is av
2017-12-06 9:42 GMT+08:00 Colin NG :
> ---
> libavformat/dashdec.c | 111
> --
> 1 file changed, 98 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 3798649..6e35e91 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
> return av_gettime() / 100;
> }
>
> +static char * ishttp(char *url) {
> +char *proto_name = avio_find_protocol_name(url);
> +return av_strstart(proto_name, "http", NULL);
> +}
> +
> static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char
> *datetime)
> {
> struct tm timeinfo;
> @@ -392,7 +397,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
> const char *url,
> else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
> return AVERROR_INVALIDDATA;
>
> -ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> +av_freep(pb);
> +ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
> +
> if (ret >= 0) {
> // update cookies on http response with setcookies.
> char *new_cookies = NULL;
> @@ -639,6 +646,86 @@ static int
> parse_manifest_segmenttimeline(AVFormatContext *s, struct representat
> return 0;
> }
>
> +static int resolve_content_path(AVFormatContext *s, const char *url,
> xmlNodePtr *baseurl_nodes, int n_baseurl_nodes) {
> +
> +int i;
> +char *text;
> +char *tmp_str = av_mallocz(MAX_URL_SIZE);
> +char *tmp_str_2= av_mallocz(MAX_URL_SIZE);
> +
> +char *path = av_mallocz(MAX_URL_SIZE);
> +int nameSize = 0;
> +int updated = 0;
> +
> +if (!tmp_str || !tmp_str_2 || !path) {
> +updated = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +av_strlcpy(tmp_str, url, strlen(url)+1);
> +char *mpdName = strtok (tmp_str," /");
> +
> +while ((mpdName =strtok (NULL, "/"))) {
> +nameSize = strlen(mpdName);
> +}
> +
> +av_strlcpy (path, url, strlen(url)-nameSize+1);
> +
> +int rootId = 0;
> +xmlNodePtr *node = NULL;
> +for (rootId = n_baseurl_nodes-1; rootId >0; rootId--) {
> +if (!(node = baseurl_nodes[rootId])) {
> +continue;
> +}
> +if (ishttp(xmlNodeGetContent(node))) {
> +break;
> +}
> +}
> +
> +node = baseurl_nodes[rootId];
> +char *baseurl = xmlNodeGetContent(node);
> +char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
> +
> +if (node) {
> +xmlNodeSetContent(node, root_url);
> +}
> +
> +int size = strlen(root_url);
> +char *isRootHttp = ishttp(root_url);
> +
> +char token ='/';
> +if (root_url[size] == token) {
> +av_strlcat(root_url, "/", size+2);
> +size+=2;
> +}
> +
> +for (i = 0; i < n_baseurl_nodes; ++i) {
> +if (i == rootId) {
> +continue;
> +}
> +text = xmlNodeGetContent(baseurl_nodes[i]);
> +if (text) {
> +memset(tmp_str, 0, strlen(tmp_str));
> +
> +if (!ishttp(text) && isRootHttp) {
> +av_strlcpy(tmp_str, root_url, size+1);
> +}
> +int start = (text[0]==token) ? 1: 0;
> +memset(tmp_str_2, 0, strlen(tmp_str_2));
> +av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
> +xmlFree(text);
> +xmlNodeSetContent(baseurl_nodes[i], tmp_str);
> +updated = 1;
> +}
> +}
> +
> +end:
> +av_free(path);
> +av_free(tmp_str);
> +av_free(tmp_str_2);
> +return updated;
> +
> +}
> static int parse_manifest_representation(AVFormatContext *s, const char *url,
> xmlNodePtr node,
> xmlNodePtr adaptionset_node,
> @@ -698,6 +785,12 @@ static int parse_manifest_representation(AVFormatContext
> *s, const char *url,
> baseurl_nodes[2] = adaptionset_baseurl_node;
> baseurl_nodes[3] = representation_baseurl_node;
>
> +ret = resolve_content_path(s, url, baseurl_nodes, 4);
> +
> +if (ret == AVERROR(ENOMEM) || ret == 0) {
> +goto end;
> +}
> +
> if (representation_segmenttemplate_node || fragment_template_node) {
> fragment_timeline_node = NULL;
> fragment_templates_tab[0] = representation_segmenttemplate_node;
> @@ -993,6 +1086,9 @@ static int parse_manifest(AVFormatContext *s, const char
> *url, AVIOContext *in)
> }
>
> mpd_baseurl_node = find_child_node_by_name(node, "BaseURL");
> +if (!mpd_baseurl_node) {
> +mpd_baseurl_node = xmlNewNode(node, "BaseURL");
> +}
>
> // at now we can handle only one period, with the longest duration
> node = xmlFirstElementChild(node);
> @@ -1315,6 +1411,7 @@ static int read_from_url(struct representation *pls,
> struct fragment
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On Tue, Dec 5, 2017, at 03:28 PM, Bang He wrote: > can it list profiles and levels? I don't know (also, too lazy to look into it). That's why I asked. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: move init operations from write_header to init
>
>
>
>On 12/4/17, 3:20 PM, "Steven Liu" wrote:
>
>
>
>Signed-off-by: Steven Liu
>
>---
>
> libavformat/hlsenc.c | 681 ++-
>
> 1 file changed, 345 insertions(+), 336 deletions(-)
>
>
>
>diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>
>index aeeed5bcd2..852663d28f 100644
>
>--- a/libavformat/hlsenc.c
>
>+++ b/libavformat/hlsenc.c
>
>@@ -1636,329 +1636,12 @@ static int hls_write_header(AVFormatContext *s)
>
> {
>
> HLSContext *hls = s->priv_data;
>
> int ret, i, j;
>
>-char *p = NULL;
>
>-const char *pattern = "%d.ts";
>
>-const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt(s);
>
>-const char *vtt_pattern = "%d.vtt";
>
> AVDictionary *options = NULL;
>
>-int basename_size = 0;
>
>-int vtt_basename_size = 0, m3u8_name_size = 0;
>
> VariantStream *vs = NULL;
>
>-int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>
>-
>
>-ret = update_variant_stream_info(s);
>
>-if (ret < 0) {
>
>-av_log(s, AV_LOG_ERROR, "Variant stream info update failed with
>status %x\n",
>
>-ret);
>
>-goto fail;
>
>-}
>
>-
>
>-//TODO: Updates needed to encryption functionality with periodic re-key
>when more than one variant streams are present
>
>-if (hls->nb_varstreams > 1 && hls->flags & HLS_PERIODIC_REKEY) {
>
>-ret = AVERROR(EINVAL);
>
>-av_log(s, AV_LOG_ERROR, "Periodic re-key not supported when more than
>one variant streams are present\n");
>
>-goto fail;
>
>-}
>
>-
>
>-if (hls->master_pl_name) {
>
>-ret = update_master_pl_info(s);
>
>-if (ret < 0) {
>
>-av_log(s, AV_LOG_ERROR, "Master stream info update failed with
>status %x\n",
>
>-ret);
>
>-goto fail;
>
>-}
>
>-}
>
>-
>
>-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>
>-pattern = "%d.m4s";
>
>-}
>
>-if ((hls->start_sequence_source_type ==
>HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH) ||
>
>-(hls->start_sequence_source_type ==
>HLS_START_SEQUENCE_AS_FORMATTED_DATETIME)) {
>
>-time_t t = time(NULL); // we will need it in either case
>
>-if (hls->start_sequence_source_type ==
>HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH) {
>
>-hls->start_sequence = (int64_t)t;
>
>-} else if (hls->start_sequence_source_type ==
>HLS_START_SEQUENCE_AS_FORMATTED_DATETIME) {
>
>-char b[15];
>
>-struct tm *p, tmbuf;
>
>-if (!(p = localtime_r(&t, &tmbuf)))
>
>-return AVERROR(ENOMEM);
>
>-if (!strftime(b, sizeof(b), "%Y%m%d%H%M%S", p))
>
>-return AVERROR(ENOMEM);
>
>-hls->start_sequence = strtoll(b, NULL, 10);
>
>-}
>
>-av_log(hls, AV_LOG_DEBUG, "start_number evaluated to %"PRId64"\n",
>hls->start_sequence);
>
>-}
>
>
>
> for (i = 0; i < hls->nb_varstreams; i++) {
>
> vs = &hls->var_streams[i];
>
>
>
>-vs->sequence = hls->start_sequence;
>
>-hls->recording_time = (hls->init_time ? hls->init_time : hls->time) *
>AV_TIME_BASE;
>
>-vs->start_pts = AV_NOPTS_VALUE;
>
>-vs->end_pts = AV_NOPTS_VALUE;
>
>-vs->current_segment_final_filename_fmt[0] = '\0';
>
>-
>
>-if (hls->flags & HLS_SPLIT_BY_TIME && hls->flags &
>HLS_INDEPENDENT_SEGMENTS) {
>
>-// Independent segments cannot be guaranteed when splitting by time
>
>-hls->flags &= ~HLS_INDEPENDENT_SEGMENTS;
>
>-av_log(s, AV_LOG_WARNING,
>
>- "'split_by_time' and 'independent_segments' cannot be enabled
>together. "
>
>- "Disabling 'independent_segments' flag\n");
>
>-}
>
>-
>
>-if (hls->flags & HLS_PROGRAM_DATE_TIME) {
>
>-time_t now0;
>
>-time(&now0);
>
>-vs->initial_prog_date_time = now0;
>
>-}
>
>-
>
>-if (hls->format_options_str) {
>
>-ret = av_dict_parse_string(&hls->format_options,
>hls->format_options_str, "=", ":", 0);
>
>-if (ret < 0) {
>
>-av_log(s, AV_LOG_ERROR, "Could not parse format options list
>'%s'\n", hls->format_options_str);
>
>-goto fail;
>
>-}
>
>-}
>
>-
>
>-for (j = 0; j < vs->nb_streams; j++) {
>
>-vs->has_video +=
>
>-vs->streams[j]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO;
>
>-vs->has_subtitle +=
>
>-vs->streams[j]->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE;
>
>-}
>
>-
>
>-if (vs->has_video > 1)
>
>-av_log(s, AV_LOG_WARNING,
>
>- "More than a single video stream present, "
>
>- "expect issues decoding it.\n");
>
>-
>
>-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>
>-vs->oformat = av_guess_format("mp4", NULL, NULL);
>
>-} else {
>
>-vs->oformat = av_guess_format("mpegts", NULL, NULL);
>
>-}
>
>-
>
>-if (!vs->oformat) {
>
>-ret = AVERROR_MU
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On 12/6/2017 4:08 AM, Lou Logan wrote:
Nit: change "set :" to "set:".
Would it be possible to list the profiles with x265_profile_names
similar to what is done for libx264?
Both done.
From 607ed6fd623cee0e2d49a70d9446b8360c799498 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265 - Add named option to set profile
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
---
libavcodec/libx265.c | 14 ++
libavcodec/version.h | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..cbb106aeed 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -45,6 +45,7 @@ typedef struct libx265Context {
int forced_idr;
char *preset;
char *tune;
+char *profile;
char *x265_opts;
} libx265Context;
@@ -220,6 +221,18 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
}
+if (ctx->profile) {
+if (ctx->api->param_apply_profile(ctx->params, ctx->profile) < 0) {
+int i;
+av_log(avctx, AV_LOG_ERROR, "Invalid or incompatible profile set:
%s.\n", ctx->profile);
+av_log(avctx, AV_LOG_INFO, "Possible profiles:");
+for (i = 0; x265_profile_names[i]; i++)
+av_log(avctx, AV_LOG_INFO, " %s", x265_profile_names[i]);
+av_log(avctx, AV_LOG_INFO, "\n");
+return AVERROR(EINVAL);
+}
+}
+
ctx->encoder = ctx->api->encoder_open(ctx->params);
if (!ctx->encoder) {
av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -392,6 +405,7 @@ static const AVOption options[] = {
{ "forced-idr", "if forcing keyframes, force them as IDR frames",
OFFSET(forced_idr),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, VE },
{ "preset", "set the x265 preset",
OFFSET(preset),AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "tune","set the x265 tune parameter",
OFFSET(tune), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "set the x265 profile",
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "x265-params", "set the x265 configuration using a :-separated list of
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d67b689142..3b5c3000be 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 6
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MICRO 103
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile
On Tue, Dec 5, 2017, at 09:36 PM, Gyan Doshi wrote: > Both done. Thanks, and LGTM. As it is late here I plan to test and commit this tomorrow unless someone else does first. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
