[FFmpeg-devel] [PATCH v2] avformat/hls: clean up duplicate option fields

[rshaffer]

From: Richard Shaffer 

The HLSContext struct contains fields which duplicate the data stored in the
avio_opts field. This change removes those fields in favor of avio_opts, and
updates the code accordingly.
---
The original patch caused the buffer pointed to by new_cookies in open_url to be
leaked. The only thing that buffer is used for is to store the value until it
can be passed to av_dict_set. To fix the leak, v2 of the patch simply calls
av_dict_set with the AV_DICT_DONT_STRDUP_VAL flag, so that the dictionary takes
ownership of the memory instead of copying it again.

 libavformat/hls.c | 74 +++
 1 file changed, 9 insertions(+), 65 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1257cd101c..d6158c0ada 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -202,11 +202,6 @@ typedef struct HLSContext {
 int64_t first_timestamp;
 int64_t cur_timestamp;
 AVIOInterruptCB *interrupt_callback;
-char *referer;   ///< holds HTTP referer set as an 
AVOption to the HTTP protocol context
-char *user_agent;///< holds HTTP user agent set as an 
AVOption to the HTTP protocol context
-char *cookies;   ///< holds HTTP cookie values set in 
either the initial response or as an AVOption to the HTTP protocol context
-char *headers;   ///< holds HTTP headers set as an 
AVOption to the HTTP protocol context
-char *http_proxy;///< holds the address of the HTTP 
proxy server
 AVDictionary *avio_opts;
 int strict_std_compliance;
 char *allowed_extensions;
@@ -267,10 +262,6 @@ static void free_playlist_list(HLSContext *c)
 av_free(pls);
 }
 av_freep(>playlists);
-av_freep(>cookies);
-av_freep(>user_agent);
-av_freep(>headers);
-av_freep(>http_proxy);
 c->n_playlists = 0;
 }
 
@@ -593,14 +584,6 @@ static int ensure_playlist(HLSContext *c, struct playlist 
**pls, const char *url
 return 0;
 }
 
-static void update_options(char **dest, const char *name, void *src)
-{
-av_freep(dest);
-av_opt_get(src, name, AV_OPT_SEARCH_CHILDREN, (uint8_t**)dest);
-if (*dest && !strlen(*dest))
-av_freep(dest);
-}
-
 static int open_url_keepalive(AVFormatContext *s, AVIOContext **pb,
   const char *url)
 {
@@ -684,12 +667,8 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 if (!(s->flags & AVFMT_FLAG_CUSTOM_IO))
 av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
(uint8_t**)_cookies);
 
-if (new_cookies) {
-av_free(c->cookies);
-c->cookies = new_cookies;
-}
-
-av_dict_set(, "cookies", c->cookies, 0);
+if (new_cookies)
+av_dict_set(, "cookies", new_cookies, 
AV_DICT_DONT_STRDUP_VAL);
 }
 
 av_dict_free();
@@ -736,14 +715,7 @@ static int parse_playlist(HLSContext *c, const char *url,
 
 if (!in) {
 AVDictionary *opts = NULL;
-/* Some HLS servers don't like being sent the range header */
-av_dict_set(, "seekable", "0", 0);
-
-// broker prior HTTP options that should be consistent across requests
-av_dict_set(, "user_agent", c->user_agent, 0);
-av_dict_set(, "cookies", c->cookies, 0);
-av_dict_set(, "headers", c->headers, 0);
-av_dict_set(, "http_proxy", c->http_proxy, 0);
+av_dict_copy(, c->avio_opts, 0);
 
 if (c->http_persistent)
 av_dict_set(, "multiple_requests", "1", 0);
@@ -1169,14 +1141,6 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg,
 int ret;
 int is_http = 0;
 
-// broker prior HTTP options that should be consistent across requests
-av_dict_set(, "user_agent", c->user_agent, 0);
-av_dict_set(, "referer", c->referer, 0);
-av_dict_set(, "cookies", c->cookies, 0);
-av_dict_set(, "headers", c->headers, 0);
-av_dict_set(, "http_proxy", c->http_proxy, 0);
-av_dict_set(, "seekable", "0", 0);
-
 if (c->http_persistent)
 av_dict_set(, "multiple_requests", "1", 0);
 
@@ -1193,7 +1157,6 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg,
 if (seg->key_type == KEY_NONE) {
 ret = open_url(pls->parent, in, seg->url, c->avio_opts, opts, 
_http);
 } else if (seg->key_type == KEY_AES_128) {
-AVDictionary *opts2 = NULL;
 char iv[33], key[33], url[MAX_URL_SIZE];
 if (strcmp(seg->key, pls->key_url)) {
 AVIOContext *pb = NULL;
@@ -1218,14 +1181,10 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg,
 else
 snprintf(url, sizeof(url), "crypto:%s", seg->url);
 
-av_dict_copy(, c->avio_opts, 0);
-av_dict_set(, "key", key, 0);
-av_dict_set(, "iv", iv, 0);
-
-ret = 

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[James Almer]

On 4/13/2018 3:59 PM, Michael Niedermayer wrote:
> On Thu, Apr 12, 2018 at 03:34:29PM -0300, James Almer wrote:
>> If the parser returns full frames, then the output pointer retured by
>> av_parser_parse2() is guaranteed to point to data contained in the
>> input packet's buffer.
>>
>> Create a new reference to said buffer in that case, to avoid
>> unnecessary data copy when queueing the packet later in the function.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/utils.c | 23 ---
>>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> LGTM
> 
> thx

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

[FFmpeg-devel] [PATCH] libavformat/http: Fix memory leak in get_cookies.

[rshaffer]

From: Richard Shaffer 

---
 libavformat/http.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 983034f083..b4a1919f24 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1103,6 +1103,7 @@ static int get_cookies(HTTPContext *s, char **cookies, 
const char *path,
 snprintf(*cookies, str_size, "%s; %s=%s", tmp, cookie_entry->key, 
cookie_entry->value);
 av_free(tmp);
 }
+av_dict_free(_params);
 }
 
 av_free(set_cookies);
-- 
2.15.1 (Apple Git-101)

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

Re: [FFmpeg-devel] [PATCH] configure: fix clang-cl detection

[Dale Curtis]

lgtm, I was able to build ffmpeg for windows on Linux with this patch by
following my notes here:

https://bugs.chromium.org/p/chromium/issues/detail?id=783021#c6

- dale

On Thu, Feb 1, 2018 at 2:52 AM Alexander Bilyak 
wrote:

> When using clang-cl it expects parameters passed in MSVC-style, so
> appropriate toolchain should be selected.
> As soon as both clang and clang-cl report themselfs as "clang" with -v
> option the only chance to detect
> clang-cl is passing -? option to both which is valid for clang-cl.exe and
> not for clang.exe.
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index fcfa7aa442..f8c55876e5 100755
> --- a/configure
> +++ b/configure
> @@ -4216,7 +4216,7 @@ probe_cc(){
>  _depflags='-MMD'
>  _cflags_speed='-O3'
>  _cflags_size='-Os'
> -elif $_cc -v 2>&1 | grep -q clang; then
> +elif $_cc -v 2>&1 | grep -q clang && ! $_cc -? > /dev/null 2>&1; then
>  _type=clang
>  _ident=$($_cc --version 2>/dev/null | head -n1)
>  _depflags='-MMD -MF $(@:.o=.d) -MT $@'
> @@ -4287,7 +4287,7 @@ probe_cc(){
>  _flags_filter=msvc_flags
>  _ld_lib='lib%.a'
>  _ld_path='-libpath:'
> -elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
> +elif $_cc -nologo- 2>&1 | grep -q Microsoft || $_cc -v 2>&1 | grep -q
> clang && $_cc -? > /dev/null 2>&1; then
>  _type=msvc
>  _ident=$($_cc 2>&1 | head -n1)
>  _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> --
> 2.15.0
>
> ___
> 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] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.

[Rahul Chaudhry]

When compiling for THUMB-2, the conditional branch to PLT results in a
R_ARM_THM_JUMP19 relocation. Some linkers don't support this relocation
in THUMB-2 (ld.gold), while others can end up truncating the relocation
to fit (ld.bfd).

Adding an "it eq" before the branch converts it into an unconditional
branch, which uses R_ARM_THM_JUMP24 relocation that has a range of 16MB.

See https://github.com/android-ndk/ndk/issues/337 for background.

The current workaround is to disable neon during gstreamer build,
which is not optimal and can be reverted after this patch.

Rahul
From 8dbb701398cf26a6a2f4686f871c5032dcbf1158 Mon Sep 17 00:00:00 2001
From: Rahul Chaudhry 
Date: Thu, 12 Apr 2018 16:27:31 -0700
Subject: [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.

When compiling for THUMB-2, the conditional branch to PLT results in a
R_ARM_THM_JUMP19 relocation. Some linkers don't support this relocation
in THUMB-2 (ld.gold), while others can end up truncating the relocation
to fit (ld.bfd).

Adding an "it eq" before the branch converts it into an unconditional
branch, which uses R_ARM_THM_JUMP24 relocation that has a range of 16MB.
---
 libswresample/arm/audio_convert_neon.S | 1 +
 1 file changed, 1 insertion(+)

diff --git libswresample/arm/audio_convert_neon.S libswresample/arm/audio_convert_neon.S
index 1f88316ddec838dfe791b08cbe72533207994741..bc933fb4bd00071702f553cc0f3e74797c33ab12 100644
--- libswresample/arm/audio_convert_neon.S
+++ libswresample/arm/audio_convert_neon.S
@@ -134,6 +134,7 @@ function swri_oldapi_conv_fltp_to_s16_nch_neon, export=1
 itt lt
 ldrlt   r1,  [r1]
 blt X(swri_oldapi_conv_flt_to_s16_neon)
+it  eq
 beq X(swri_oldapi_conv_fltp_to_s16_2ch_neon)
 
 push{r4-r8, lr}
-- 
2.13.5

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Enforce minimum width also for VP5/6

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 03:12:46AM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: poc_0411
> 
> Found-by: GwanYeong Kim 
> Tested-by: GwanYeong Kim 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

will apply

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/truemotion2: Propagate out of bounds error from GET_TOK()

[Michael Niedermayer]

On Tue, Apr 10, 2018 at 11:25:40PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 6389/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5695918121680896
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truemotion2.c | 6 ++
>  1 file changed, 6 insertions(+)

will apply

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Fix integer overflow in end time calculation in update_stream_timings()

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 03:12:45AM +0200, Michael Niedermayer wrote:
> Fixes: crbug 829153
> 
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement 2.

[Bodecs Bela]

2018.04.13. 20:54 keltezéssel, Michael Niedermayer írta:

On Fri, Apr 13, 2018 at 12:16:52PM +0200, Bodecs Bela wrote:

Dear All,

In some cases, mainly working with multiprogram mpeg-ts containers as
input, it would be handy to select sub stream of a specific program by
their metadata.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream metadata.

Examples:
p:601:m:language:hun  will select all sub streams of program with id 601
where sub streams have metadata key named 'language' with value 'hun'.
p:602:m:guide  will select all sub streams of program with id 602 where
sub streams have metadata key named 'guide'.

This syntax enhancement does not interfere in any way with
current/existing syntax or working command lines.

please review this patch.

thank you in advance,

best,

Bela

  doc/fftools-common-opts.texi |   10 --
  libavformat/utils.c  |   28 
  2 files changed, 36 insertions(+), 2 deletions(-)
03f0760a24e25b89f4515e3fd860f3af1061ae23  
0001-avformat-utils-Stream-specifier-enhancement-2.patch
 From fbec3c0c9b8189b1517f33394548c58c112a48ed Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 13 Apr 2018 12:11:32 +0200
Subject: [PATCH] avformat/utils: Stream specifier enhancement 2.

will apply

can you also add a fate test ?

thanks

[...]
I have searched but there is no mpeg-ts with metadata among test files. 
which is the preferred solution:

a.) send a files into the fate-suite or b.) create on-the-fly for test?

bb




___
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] avcodec/prores_ks : use official quant matrix

[Paul B Mahol]

On 4/13/18, Martin Vignali  wrote:
>> You sure those are actually used in binary?
>>
>>
> luma, chroma matrix in prores is write in each frame.
> So i take these values, from a real sample (prores made with official
> encoder (and for xq, you can also, compare with arri sample footage)
>
> For the proxy chroma version is also the same matrix use in prores_aw

Patch is OK then, assumming FATE still passes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/prores_ks : use official quant matrix

[Martin Vignali]

> You sure those are actually used in binary?
>
>
luma, chroma matrix in prores is write in each frame.
So i take these values, from a real sample (prores made with official
encoder (and for xq, you can also, compare with arri sample footage)

For the proxy chroma version is also the same matrix use in prores_aw

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

Re: [FFmpeg-devel] avcodec/prores_ks : use official quant matrix

[Paul B Mahol]

On 4/13/18, Martin Vignali  wrote:
> Hello,
>
> Patch in attach, add support to a separate luma and chroma matrix
> for prores encoding
>
> like proxy and xq codec version, doesn't have the same luma and chroma
> matrix
>
> The official xq luma matrix is not use for now (need to fix something
> elsein the encoder in order to use it
> (desaturate the picture if use in the current state)

You sure those are actually used in binary?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avcodec/prores_ks : use official quant matrix

[Martin Vignali]

Hello,

Patch in attach, add support to a separate luma and chroma matrix
for prores encoding

like proxy and xq codec version, doesn't have the same luma and chroma
matrix

The official xq luma matrix is not use for now (need to fix something
elsein the encoder in order to use it
(desaturate the picture if use in the current state)


Martin


0001-avcodec-prores_ks-use-official-quant_matrix-for-prox.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/utils: use the existing packet reference when parsing complete frames

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 03:34:29PM -0300, James Almer wrote:
> If the parser returns full frames, then the output pointer retured by
> av_parser_parse2() is guaranteed to point to data contained in the
> input packet's buffer.
> 
> Create a new reference to said buffer in that case, to avoid
> unnecessary data copy when queueing the packet later in the function.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement 2.

[Michael Niedermayer]

On Fri, Apr 13, 2018 at 12:16:52PM +0200, Bodecs Bela wrote:
> Dear All,
> 
> In some cases, mainly working with multiprogram mpeg-ts containers as
> input, it would be handy to select sub stream of a specific program by
> their metadata.
> This patch makes it possible to narrow the stream selection among
> streams of the specified program by stream metadata.
> 
> Examples:
> p:601:m:language:hun  will select all sub streams of program with id 601
> where sub streams have metadata key named 'language' with value 'hun'.
> p:602:m:guide  will select all sub streams of program with id 602 where
> sub streams have metadata key named 'guide'.
> 
> This syntax enhancement does not interfere in any way with
> current/existing syntax or working command lines.
> 
> please review this patch.
> 
> thank you in advance,
> 
> best,
> 
> Bela
> 

>  doc/fftools-common-opts.texi |   10 --
>  libavformat/utils.c  |   28 
>  2 files changed, 36 insertions(+), 2 deletions(-)
> 03f0760a24e25b89f4515e3fd860f3af1061ae23  
> 0001-avformat-utils-Stream-specifier-enhancement-2.patch
> From fbec3c0c9b8189b1517f33394548c58c112a48ed Mon Sep 17 00:00:00 2001
> From: Bela Bodecs 
> Date: Fri, 13 Apr 2018 12:11:32 +0200
> Subject: [PATCH] avformat/utils: Stream specifier enhancement 2.

will apply

can you also add a fate test ?

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to documentation section

[Lou Logan]

On Wed, 11 Apr 2018 21:53:25 +0530
Gyan Doshi  wrote:

> rom b18cb5bfb7c8df130892f9ec9552287edac2b17a Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Wed, 11 Apr 2018 21:46:03 +0530
> Subject: [PATCH] MAINTAINERS: add myself to documentation section
> 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

[FFmpeg-devel] [PATCH] avcodec/nvdec: correctly set intra_pic_flag for h264/hevc

[Timo Rothenpieler]

---
 libavcodec/nvdec_h264.c | 8 +++-
 libavcodec/nvdec_hevc.c | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 35f54f2ed5..25b30329d0 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -74,7 +74,7 @@ static int nvdec_h264_start_frame(AVCodecContext *avctx,
 .bottom_field_flag = h->picture_structure == PICT_BOTTOM_FIELD,
 .second_field  = FIELD_PICTURE(h) && !h->first_field,
 .ref_pic_flag  = h->nal_ref_idc != 0,
-.intra_pic_flag= 0,
+.intra_pic_flag= 1,
 
 .CodecSpecific.h264 = {
 .log2_max_frame_num_minus4= sps->log2_max_frame_num - 
4,
@@ -132,6 +132,9 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx, 
const uint8_t *buffer,
uint32_t size)
 {
 NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+CUVIDPICPARAMS *pp = >pic_params;
+const H264Context *h = avctx->priv_data;
+const H264SliceContext *sl = >slice_ctx[0];
 void *tmp;
 
 tmp = av_fast_realloc(ctx->bitstream, >bitstream_allocated,
@@ -152,6 +155,9 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx, 
const uint8_t *buffer,
 ctx->bitstream_len += size + 3;
 ctx->nb_slices++;
 
+if (sl->slice_type != AV_PICTURE_TYPE_I && sl->slice_type != 
AV_PICTURE_TYPE_SI)
+pp->intra_pic_flag = 0;
+
 return 0;
 }
 
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index e89256d75a..008963130b 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -93,7 +93,7 @@ static int nvdec_hevc_start_frame(AVCodecContext *avctx,
 .FrameHeightInMbs  = sps->height / 16,
 .CurrPicIdx= cf->idx,
 .ref_pic_flag  = 1,
-.intra_pic_flag= 0,
+.intra_pic_flag= IS_IRAP(s),
 
 .CodecSpecific.hevc = {
 .pic_width_in_luma_samples= sps->width,
-- 
2.16.2

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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/13/2018 10:48 AM, Michael Niedermayer wrote:
> On Fri, Apr 13, 2018 at 10:33:32AM -0300, James Almer wrote:
>> On 4/13/2018 9:59 AM, Michael Niedermayer wrote:
>>> On Thu, Apr 12, 2018 at 10:17:51PM -0300, James Almer wrote:
 On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
>>> [...]
>>>
>
>
>> and apply the fix to the c11 check in configure.
>
> you want me to apply it ?
> or i misunderstand ?

 You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
 whichever you prefer, yes.
>>>
>>> do you have a link to your patch ?
>>
>> I gave you https://pastebin.com/qt6wBHG8 on IRC the other day to test,
>> and you also tried a version using foo += bar instead of bar = 0. You
>> mentioned both seemed to work, so as i said just push whichever you
>> think is better, or just tell me which one to push if you're busy.
> 
> iam always busy ;)
> push what you prefer, push yours if you still cant decide
> 
> thanks!

Pushed yours.

I don't think we need to backport this to release/3.4 seeing the file
using stdatomic.h you reported was failing (h264_slice.c) was ported to
it only a month or so ago, but guess we'll know once the relevant fate
client runs. I can see release/3.3 at least works.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Fri, Apr 13, 2018 at 03:44:40PM +0200, Łukasz Krzciuk wrote:
> Hi,
> 
> this change is needed according to OIPF spec: 8.4.2 AVComponent,
> audioDescription case:
> 
>1. an audio component with an ISO_639_language_descriptor in the PMT
>with the audio_type field set to 0x03
>2. a supplementary_audio_descriptor with the editorial_classification
>field set to 0x01
>3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
>component_type field with the service_type flags set to Visually Impaired
> 
> 
> Regards,
> 
> *Łukasz Krzciuk*
> Developer
> 
> Vewd
> ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska

>  mpegts.c |   30 ++
>  1 file changed, 30 insertions(+)
> 863b7bca7f23f9ea337fde33f5bb9265ef3b4270  
> 0001-avformat-mpegts-set-AV_DISPOSITION_DESCRIPTIONS-for-.patch
> From 12ef5cdd9c443b1601dc98d910feac87233b1040 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?= 
> Date: Fri, 13 Apr 2018 14:57:57 +0200
> Subject: [PATCH] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF
>  cases
> 
> 1. an audio component with an ISO_639_language_descriptor in the PMT with the
> audio_type field set to 0x03
> 2. a supplementary_audio_descriptor with the editorial_classification field 
> set
> to 0x01
> 3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a component_type 
> field
> with the service_type flags set to Visually Impaired
> ---
>  libavformat/mpegts.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 37a6aa8..df2b3aa 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -1835,6 +1835,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  break;
>  case 0x03:
>  st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
>  break;
>  }
>  }
> @@ -1910,6 +1911,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  switch ((flags >> 2) & 0x1F) { /* editorial_classification */
>  case 0x01:
>  st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
>  break;
>  case 0x02:
>  st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
> @@ -1934,6 +1936,34 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
>  }
>  }
>  break;
> +case 0x6a: /* ac-3_descriptor */
> +{
> +int component_type_flag = get8(pp, desc_end) & (1 << 7);
> +if (component_type_flag) {
> +int component_type = get8(pp, desc_end);
> +int service_type_mask = 0x38;  // 0b00111000
> +int service_type = ((component_type & service_type_mask) >> 
> 3);
> +if (service_type == 0x02 /* 0b010 */) {
> +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
> +av_log(ts->stream, AV_LOG_INFO, "New track disposition 
> for id %u: %u\n", st->id, st->disposition);

AV_LOG_INFO is likely too noisy for normal usecases

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 2/4] ffserver: Implement publisher

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 03:35:47PM +0200, Stephan Holljes wrote:
> ---
>  publisher.c | 278 
> 
>  publisher.h | 134 +
>  2 files changed, 412 insertions(+)
>  create mode 100644 publisher.c
>  create mode 100644 publisher.h
> 
> diff --git a/publisher.c b/publisher.c
> new file mode 100644
> index 000..d1ccb95
> --- /dev/null
> +++ b/publisher.c
> @@ -0,0 +1,278 @@
> +#include "publisher.h"
> +#include "segment.h"
> +#include 
> +
> +void client_log(struct Client *c)
> +{
> +char state[64];
> +sprintf("State: ", state);
> +switch(c->state) {
> +case FREE:
> +sprintf(state, "FREE");
> +break;
> +case RESERVED:
> +sprintf(state, "RESERVED");
> +break;
> +case WAIT:
> +sprintf(state, "WAIT");
> +break;
> +case WRITABLE:
> +sprintf(state, "WRITABLE");
> +break;
> +case BUSY:
> +sprintf(state, "BUSY");
> +break;
> +case BUFFER_FULL:
> +sprintf(state, "BUFFER_FULL");
> +break;
> +default:
> +sprintf(state, "UNDEFINED");
> +break;
> +}
> +av_log(NULL, AV_LOG_INFO, "%s\n", state);

const char *state = "UNDEFINED";
...
case WAIT:
state = "WAIT"
...

av_log(..., "State: %s", state);

simpler, no buffer, no copy (which lacks buffer size checks)


[...]
> +void publisher_gen_status_json(struct PublisherContext *pub, char *status)
> +{
> +int nb_free = 0, nb_reserved = 0, nb_wait = 0, nb_writable = 0, nb_busy 
> = 0, nb_buffer_full = 0, current_read = 0, newest_write = 0, oldest_write = 0;
> +int i;
> +struct Client *c;
> +
> +current_read = pub->current_segment_id;
> +oldest_write = current_read;
> +
> +for (i = 0; i < MAX_CLIENTS; i++) {
> +c = >clients[i];
> +if (c->current_segment_id > 0 && c->current_segment_id < 
> oldest_write) {
> +oldest_write = c->current_segment_id;
> +}
> +if (c->current_segment_id > newest_write) {
> +newest_write = c->current_segment_id;
> +}
> +
> +switch(c->state) {
> +case FREE:
> +nb_free++;
> +continue;
> +case RESERVED:
> +nb_reserved++;
> +continue;
> +case WAIT:
> +nb_wait++;
> +continue;
> +case WRITABLE:
> +nb_writable++;
> +continue;
> +case BUSY:
> +nb_busy++;
> +continue;
> +case BUFFER_FULL:
> +nb_buffer_full++;
> +continue;
> +default:
> +continue;
> +}
> +}

you can simplify this substantially:

int nb_table[STATE_NB] = {0};

...
for()
nb_table[c->state]++;

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH] configure: disable direct stripping in OpenBSD

[James Almer]

On 4/10/2018 8:54 PM, James Almer wrote:
> On 4/9/2018 11:35 AM, Derek Buitenhuis wrote:
>> On 4/9/2018 3:32 PM, James Almer wrote:
>>> Maybe they already know and it was fixed at some point, seeing the
>>> OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to
>>> assume equally outdated binutils).
>>
>> OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks,
>> so probably still useful.
>>
> 
> Looking at the packages shipped by OpenBSD in its latest version, they
> are using GCC 4.9, so I'm going to assume this was fixed long ago.
> 
> Does anyone use a recent OpenBSD to confirm this, in any case? I may be
> able to add a GCC version check depending on that to this patch.

Pushed it as is in the meantime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] ffserver: Implement refcounted segments.

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 03:35:46PM +0200, Stephan Holljes wrote:
> ---
>  segment.c | 143 
> ++
>  segment.h | 104 +
>  2 files changed, 247 insertions(+)
>  create mode 100644 segment.c
>  create mode 100644 segment.h
> 
> diff --git a/segment.c b/segment.c
> new file mode 100644
> index 000..0ef58a1
> --- /dev/null
> +++ b/segment.c
> @@ -0,0 +1,143 @@
> +#include 
> +#include "segment.h"
> +#include 
> +
> +#include 
> +#include 

This and other files lack a license header



> +
> +
> +void save_segment(struct Segment *seg, const char *filename)
> +{
> +FILE *out = fopen(filename, "w");
> +fwrite(seg->buf, seg->size, 1, out);
> +fclose(out);
> +}

probably should use avio from libavformat so as not to limit it to local files


> +
> +void segment_free(struct Segment *seg)
> +{
> +av_log(NULL, AV_LOG_DEBUG, "Freeing segment\n");
> +avformat_free_context(seg->fmt_ctx);
> +av_free(seg->io_ctx->buffer);
> +av_free(seg->io_ctx);
> +free(seg->buf);
> +free(seg->ts);
> +free(seg);

iam not sure mixing free and av_free is a good idea. its a recipe for disaster



> +}
> +
> +void segment_ref(struct Segment *seg)
> +{
> +pthread_mutex_lock(>nb_read_lock);
> +seg->nb_read++;
> +av_log(NULL, AV_LOG_DEBUG, "  ref Readers: %d\n", seg->nb_read);
> +pthread_mutex_unlock(>nb_read_lock);
> +}
> +
> +void segment_unref(struct Segment *seg)
> +{
> +pthread_mutex_lock(>nb_read_lock);
> +seg->nb_read--;
> +pthread_mutex_unlock(>nb_read_lock);
> +av_log(NULL, AV_LOG_DEBUG, "unref Readers: %d\n", seg->nb_read);
> +if (seg->nb_read == 0) {
> +segment_free(seg);
> +}
> +}
> +
> +void segment_ts_append(struct Segment *seg, int64_t dts, int64_t pts)
> +{
> +seg->ts = (int64_t*) realloc(seg->ts, sizeof(int64_t) * 2  * 
> (seg->ts_len + 2));
> +seg->ts[seg->ts_len] = dts;
> +seg->ts[seg->ts_len + 1] = pts;
> +seg->ts_len += 2;
> +return;
> +}
> +
> +int segment_write(void *opaque, unsigned char *buf, int buf_size)
> +{
> +struct Segment *seg = (struct Segment*) opaque;
> +seg->size += buf_size;
> +seg->buf = (char*) realloc(seg->buf, seg->size);
> +memcpy(seg->buf + seg->size - buf_size, buf, buf_size);
> +return buf_size;
> +}
> +
> +int segment_read(void *opaque, unsigned char *buf, int buf_size)
> +{
> +struct SegmentReadInfo *info = (struct SegmentReadInfo*) opaque;
> +buf_size = buf_size < info->left ? buf_size : info->left;
> +
> +/* copy internal buffer data to buf */
> +memcpy(buf, info->buf, buf_size);
> +info->buf  += buf_size;
> +info->left -= buf_size;
> +return buf_size ? buf_size : AVERROR_EOF;
> +}
> +
> +
> +void segment_close(struct Segment *seg)
> +{
> +av_write_trailer(seg->fmt_ctx);
> +}
> +
> +void segment_init(struct Segment **seg_p, AVFormatContext *fmt)
> +{
> +int ret;
> +int i;
> +AVStream *in_stream, *out_stream;
> +AVCodecContext *codec_ctx;
> +struct Segment *seg = (struct Segment*) malloc(sizeof(struct Segment));
> +
> +seg->ifmt = fmt->iformat;
> +seg->fmt_ctx = NULL;
> +seg->nb_read = 0;
> +seg->size = 0;
> +seg->ts = NULL;
> +seg->ts_len = 0;
> +seg->buf = NULL;
> +seg->avio_buffer = (unsigned char*) av_malloc(AV_BUFSIZE);
> +pthread_mutex_init(>nb_read_lock, NULL);
> +seg->io_ctx = avio_alloc_context(seg->avio_buffer, AV_BUFSIZE, 1, seg, 
> NULL, _write, NULL);
> +seg->io_ctx->seekable = 0;
> +avformat_alloc_output_context2(>fmt_ctx, NULL, "matroska", NULL);
> +if ((ret = av_opt_set_int(seg->fmt_ctx, "flush_packets", 1, 
> AV_OPT_SEARCH_CHILDREN)) < 0) {
> +av_log(NULL, AV_LOG_WARNING, "Could not set flush_packets!\n");
> +}
> +
> +seg->fmt_ctx->flags |= AVFMT_FLAG_GENPTS;
> +seg->fmt_ctx->oformat->flags &= AVFMT_NOFILE;
> +

> +av_log(NULL, AV_LOG_DEBUG, "Initializing segment\n");

av_log should not be used with a NULL context, as it will make it hard for
the user/developer to identify where a message came from when things become
more complex than a single thread, single client

thanks

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

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


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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Fri, Apr 13, 2018 at 10:33:32AM -0300, James Almer wrote:
> On 4/13/2018 9:59 AM, Michael Niedermayer wrote:
> > On Thu, Apr 12, 2018 at 10:17:51PM -0300, James Almer wrote:
> >> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
> > [...]
> > 
> >>>
> >>>
>  and apply the fix to the c11 check in configure.
> >>>
> >>> you want me to apply it ?
> >>> or i misunderstand ?
> >>
> >> You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
> >> whichever you prefer, yes.
> > 
> > do you have a link to your patch ?
> 
> I gave you https://pastebin.com/qt6wBHG8 on IRC the other day to test,
> and you also tried a version using foo += bar instead of bar = 0. You
> mentioned both seemed to work, so as i said just push whichever you
> think is better, or just tell me which one to push if you're busy.

iam always busy ;)
push what you prefer, push yours if you still cant decide

thanks!


> 
> > 
> > 
> >>
> >>>
> >>>
> 
>  The kfreebsd failures are for the tests filter-metadata-silencedetect
>  and checkasm-aacpsdsp. After a recent patch silencedetect prints float
>  values with more precision. Paul said to remove the test and forget
>  about it, but no idea if there's a better solution.
> >>>
> >>> of course removing the test is the easy solution.
> >>> there is only 1 test for silencedetect, so that would remove not just
> >>> one silencedetect test but all silencedetect tests
> >>>
> >>> The test currently uses a amrwb test file which is decoded with a
> >>> non bitexact float decoder.
> >>> has someone tried to replace this by bitexact input ?
> >>
> >> Do we have a relatively quiet sample using a bitexact codec like this
> >> amrwb one? Or we could convert it to flac and upload it instead.
> > 
> > random pick based on existing test:
> > ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f 
> > lavfi amovie=fate-suite/lossless-audio/inside.tta,silencedetect=n=-34dB:d=.3
> 
> LGTM, it also generates a shorter output. Thanks.

ok will test what i can locally easiyl before pushing this

thx

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

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

[Łukasz Krzciuk]

Hi,

this change is needed according to OIPF spec: 8.4.2 AVComponent,
audioDescription case:

   1. an audio component with an ISO_639_language_descriptor in the PMT
   with the audio_type field set to 0x03
   2. a supplementary_audio_descriptor with the editorial_classification
   field set to 0x01
   3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
   component_type field with the service_type flags set to Visually Impaired


Regards,

*Łukasz Krzciuk*
Developer

Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
From 12ef5cdd9c443b1601dc98d910feac87233b1040 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?= 
Date: Fri, 13 Apr 2018 14:57:57 +0200
Subject: [PATCH] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF
 cases

1. an audio component with an ISO_639_language_descriptor in the PMT with the
audio_type field set to 0x03
2. a supplementary_audio_descriptor with the editorial_classification field set
to 0x01
3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a component_type field
with the service_type flags set to Visually Impaired
---
 libavformat/mpegts.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 37a6aa8..df2b3aa 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1835,6 +1835,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int stream_type
 break;
 case 0x03:
 st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
+st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
 break;
 }
 }
@@ -1910,6 +1911,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int stream_type
 switch ((flags >> 2) & 0x1F) { /* editorial_classification */
 case 0x01:
 st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
+st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
 break;
 case 0x02:
 st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
@@ -1934,6 +1936,34 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int stream_type
 }
 }
 break;
+case 0x6a: /* ac-3_descriptor */
+{
+int component_type_flag = get8(pp, desc_end) & (1 << 7);
+if (component_type_flag) {
+int component_type = get8(pp, desc_end);
+int service_type_mask = 0x38;  // 0b00111000
+int service_type = ((component_type & service_type_mask) >> 3);
+if (service_type == 0x02 /* 0b010 */) {
+st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
+av_log(ts->stream, AV_LOG_INFO, "New track disposition for id %u: %u\n", st->id, st->disposition);
+}
+}
+}
+break;
+case 0x7a: /* enhanced_ac-3_descriptor */
+{
+int component_type_flag = get8(pp, desc_end) & (1 << 7);
+if (component_type_flag) {
+int component_type = get8(pp, desc_end);
+int service_type_mask = 0x38;  // 0b00111000
+int service_type = ((component_type & service_type_mask) >> 3);
+if (service_type == 0x02 /* 0b010 */) {
+st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
+av_log(ts->stream, AV_LOG_INFO, "New track disposition for id %u: %u\n", st->id, st->disposition);
+}
+}
+}
+break;
 default:
 break;
 }
-- 
2.8.3

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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[James Almer]

On 4/13/2018 9:59 AM, Michael Niedermayer wrote:
> On Thu, Apr 12, 2018 at 10:17:51PM -0300, James Almer wrote:
>> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
> [...]
> 
>>>
>>>
 and apply the fix to the c11 check in configure.
>>>
>>> you want me to apply it ?
>>> or i misunderstand ?
>>
>> You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
>> whichever you prefer, yes.
> 
> do you have a link to your patch ?

I gave you https://pastebin.com/qt6wBHG8 on IRC the other day to test,
and you also tried a version using foo += bar instead of bar = 0. You
mentioned both seemed to work, so as i said just push whichever you
think is better, or just tell me which one to push if you're busy.

> 
> 
>>
>>>
>>>

 The kfreebsd failures are for the tests filter-metadata-silencedetect
 and checkasm-aacpsdsp. After a recent patch silencedetect prints float
 values with more precision. Paul said to remove the test and forget
 about it, but no idea if there's a better solution.
>>>
>>> of course removing the test is the easy solution.
>>> there is only 1 test for silencedetect, so that would remove not just
>>> one silencedetect test but all silencedetect tests
>>>
>>> The test currently uses a amrwb test file which is decoded with a
>>> non bitexact float decoder.
>>> has someone tried to replace this by bitexact input ?
>>
>> Do we have a relatively quiet sample using a bitexact codec like this
>> amrwb one? Or we could convert it to flac and upload it instead.
> 
> random pick based on existing test:
> ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f 
> lavfi amovie=fate-suite/lossless-audio/inside.tta,silencedetect=n=-34dB:d=.3

LGTM, it also generates a shorter output. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 10:17:51PM -0300, James Almer wrote:
> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
[...]

> > 
> > 
> >> and apply the fix to the c11 check in configure.
> > 
> > you want me to apply it ?
> > or i misunderstand ?
> 
> You confirmed it worked ("foo += bar" and "bar = 0" alike), so push
> whichever you prefer, yes.

do you have a link to your patch ?


> 
> > 
> > 
> >>
> >> The kfreebsd failures are for the tests filter-metadata-silencedetect
> >> and checkasm-aacpsdsp. After a recent patch silencedetect prints float
> >> values with more precision. Paul said to remove the test and forget
> >> about it, but no idea if there's a better solution.
> > 
> > of course removing the test is the easy solution.
> > there is only 1 test for silencedetect, so that would remove not just
> > one silencedetect test but all silencedetect tests
> > 
> > The test currently uses a amrwb test file which is decoded with a
> > non bitexact float decoder.
> > has someone tried to replace this by bitexact input ?
> 
> Do we have a relatively quiet sample using a bitexact codec like this
> amrwb one? Or we could convert it to flac and upload it instead.

random pick based on existing test:
ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f 
lavfi amovie=fate-suite/lossless-audio/inside.tta,silencedetect=n=-34dB:d=.3

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove redundant code

[Steven Liu]

2018-04-13 16:19 GMT+08:00 Jun Zhao :
>
>
> On 2018/4/12 16:48, Steven Liu wrote:
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hls.c | 27 +--
>>  1 file changed, 9 insertions(+), 18 deletions(-)
>>
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index ae0545a086..74f0c2ccc5 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -945,14 +945,8 @@ static struct segment *next_segment(struct playlist 
>> *pls)
>>  return pls->segments[n];
>>  }
>>
>> -enum ReadFromURLMode {
>> -READ_NORMAL,
>> -READ_COMPLETE,
>> -};
>> -
>>  static int read_from_url(struct playlist *pls, struct segment *seg,
>> - uint8_t *buf, int buf_size,
>> - enum ReadFromURLMode mode)
>> + uint8_t *buf, int buf_size)
>>  {
>>  int ret;
>>
>> @@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls, struct 
>> segment *seg,
>>  if (seg->size >= 0)
>>  buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
>>
>> -if (mode == READ_COMPLETE) {
>> -ret = avio_read(pls->input, buf, buf_size);
>> -if (ret != buf_size)
>> -av_log(NULL, AV_LOG_ERROR, "Could not read complete 
>> segment.\n");
>> -} else
>> -ret = avio_read(pls->input, buf, buf_size);
>> +ret = avio_read(pls->input, buf, buf_size);
>> +if (ret != buf_size)
>> +av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
>>
>>  if (ret > 0)
>>  pls->cur_seg_offset += ret;
>> @@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls, 
>> uint8_t *buf,
>>  while (1) {
>>  /* see if we can retrieve enough data for ID3 header */
>>  if (*len < ID3v2_HEADER_SIZE && buf_size >= ID3v2_HEADER_SIZE) {
>> -bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
>> *len, READ_COMPLETE);
>> +bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
>> *len);
>>  if (bytes > 0) {
>>
>>  if (bytes == ID3v2_HEADER_SIZE - *len)
>> @@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls, 
>> uint8_t *buf,
>>
>>  if (remaining > 0) {
>>  /* read the rest of the tag in */
>> -if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
>> remaining, READ_COMPLETE) != remaining)
>> +if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
>> remaining) != remaining)
>>  break;
>>  id3_buf_pos += remaining;
>>  av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional %d HLS 
>> ID3 bytes\n", remaining);
>> @@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls, 
>> uint8_t *buf,
>>
>>  /* re-fill buffer for the caller unless EOF */
>>  if (*len >= 0 && (fill_buf || *len == 0)) {
>> -bytes = read_from_url(pls, seg, buf + *len, buf_size - *len, 
>> READ_NORMAL);
>> +bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
>>
>>  /* ignore error if we already had some data */
>>  if (bytes >= 0)
>> @@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist *pls, 
>> struct segment *seg)
>>  av_fast_malloc(>init_sec_buf, >init_sec_buf_size, sec_size);
>>
>>  ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
>> -pls->init_sec_buf_size, READ_COMPLETE);
>> +pls->init_sec_buf_size);
> Didn't care ret < pls->init_sec_buf_size ?
avio_read is full size read, so it will return error, or
init_sec_buf_size, as your question, maybe it will happen then the
read_from_url called avio_read_partiall.
>>  ff_format_io_close(pls->parent, >input);
>>
>>  if (ret < 0)
>> @@ -1506,7 +1497,7 @@ reload:
>>  }
>>
>>  seg = current_segment(v);
>> -ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
>> +ret = read_from_url(v, seg, buf, buf_size);
>>  if (ret > 0) {
>>  if (just_opened && v->is_id3_timestamped != 0) {
>>  /* Intercept ID3 tags here, elementary audio streams are 
>> required
> LGTM except one question.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Thu, Apr 12, 2018 at 10:17:51PM -0300, James Almer wrote:
> On 4/12/2018 9:11 PM, Michael Niedermayer wrote:
> > On Thu, Apr 12, 2018 at 07:59:25PM -0300, James Almer wrote:
> >> On 4/12/2018 7:53 PM, Michael Niedermayer wrote:
> >>> On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
>  Hi
> 
>  Its 4 months since 3.4 was branched so its time for a new major release
> 
>  Is 4.0 or 3.5 preferred ?
>  Any name suggestions ?
> 
>  If there are no objections i will likely make that release in the next 
>  weeks
> >>>
> >>> more time has passed than intended ...
> >>>
> >>> what issues do remain that need to be fixed before the release ?
> >>> I see fate.ffmpeg.org is not looking that well (compared to most
> >>> releases in the past) i remember this being pretty much green longer ago
> >>> do people want these to be fixed before the release ?
> >>>
> >>> Thanks
> >>
> >> I fixed two targets the other day, and another has the patch pending in
> >> the ml (OpenBSD). 
> > 
> >> Then there are your FreeBSD clients that you need to
> >> switch to yasm, 
> > 
> > I can do that, it doesnt feel right though. configure should not pick
> > a nasm that then fails later.
> 
> Do you have a suggestion of what kind of configure check could trigger
> this failure? As is, all the current checks are succeeding. It's only
> failing once it tries to compile the first asm file in the tree.

It seems that freebsd version isnt supported anymore so ive switched
to yasm, lets see what goes wrong with that ;)

Ill probably replace this box by a new and fresh freebsd install
as it seems there are enough issues to justify this
(low diskspace, very odd nasm issue, unsupported version)
but ATM i have too much on my todo thats more important

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [Patch][GSoC] srcnn - a super resolution filter using CNN

[Mina]

Hi,

  I haven't received any feedback regarding this qualification task 
whether it's accepted or not. So, with less than 10 days left for GSoC, 
I thought I was ask for any reviews about my task so that I can fix it 
if anything needs fixing. Thanks in advance.


Best regards,
Mina Sami.


On 03/25/2018 10:27 AM, Mina wrote:

Hi,

  This patch is introduced as a qualification task required by Super 
Resolution project for GSoC. It passes patchcheck and make fate, 
doesn't introduce new warnings and gives expected results for all 
tested images. It's implemented by the help of the mentor: Pedro Arthur.


Best regards,
Mina Sami.



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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Hendrik Leppkes]

On Fri, Apr 13, 2018 at 12:59 AM, James Almer  wrote:
> a bunch of msvc miscompilation failures that Microsoft will  not fix.

A bunch of those are apparently fixed in an upcoming compiler update,
Martin reported those (for VS2017)
What remains we'll have to see afterwards, its no fun to try to find
the reason for a miscompilation when it might be all a similar cause
in the optimizer thats already fixed.

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

[FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement 2.

[Bodecs Bela]

Dear All,

In some cases, mainly working with multiprogram mpeg-ts containers as
input, it would be handy to select sub stream of a specific program by
their metadata.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream metadata.

Examples:
p:601:m:language:hun  will select all sub streams of program with id 601
where sub streams have metadata key named 'language' with value 'hun'.
p:602:m:guide  will select all sub streams of program with id 602 where
sub streams have metadata key named 'guide'.

This syntax enhancement does not interfere in any way with
current/existing syntax or working command lines.

please review this patch.

thank you in advance,

best,

Bela

>From fbec3c0c9b8189b1517f33394548c58c112a48ed Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 13 Apr 2018 12:11:32 +0200
Subject: [PATCH] avformat/utils: Stream specifier enhancement 2.

In some cases, mainly working with multiprogram mpeg-ts containers as
input, it would be handy to select sub stream of a specific program by
their metadata.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream metadata.

Examples:
p:601:m:language:hun  will select all sub streams of program with id 601
where sub streams have metadata key named 'language' with value 'hun'.
p:602:m:guide  will select all sub streams of program with id 602 where
sub streams have metadata key named 'guide'.

Signed-off-by: Bela Bodecs 
---
 doc/fftools-common-opts.texi | 10 --
 libavformat/utils.c  | 28 
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 79feb39..84705c0 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -42,14 +42,20 @@ streams, 'V' only matches video streams which are not 
attached pictures, video
 thumbnails or cover arts.  If @var{stream_index} is given, then it matches
 stream number @var{stream_index} of this type. Otherwise, it matches all
 streams of this type.
-@item p:@var{program_id}[:@var{stream_index}] or 
p:@var{program_id}[:@var{stream_type}[:@var{stream_index}]]
+@item p:@var{program_id}[:@var{stream_index}] or 
p:@var{program_id}[:@var{stream_type}[:@var{stream_index}]] or
+p:@var{program_id}:m:@var{key}[:@var{value}]
 In first version, if @var{stream_index} is given, then it matches the stream 
with number @var{stream_index}
 in the program with the id @var{program_id}. Otherwise, it matches all streams 
in the
-program. In the latter version, @var{stream_type} is one of following: 'v' for 
video, 'a' for audio, 's'
+program. In the second version, @var{stream_type} is one of following: 'v' for 
video, 'a' for audio, 's'
 for subtitle, 'd' for data. If @var{stream_index} is also given, then it 
matches
 stream number @var{stream_index} of this type in the program with the id 
@var{program_id}.
 Otherwise, if only @var{stream_type} is given, it matches all
 streams of this type in the program with the id @var{program_id}.
+In the third version matches streams in the program with the id 
@var{program_id} with the metadata
+tag @var{key} having the specified value. If
+@var{value} is not given, matches streams that contain the given tag with any
+value.
+
 @item #@var{stream_id} or i:@var{stream_id}
 Match the stream by stream id (e.g. PID in MPEG-TS container).
 @item m:@var{key}[:@var{value}]
diff --git a/libavformat/utils.c b/libavformat/utils.c
index cc35998..84b926d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5124,6 +5124,34 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 return 0;
 }
+
+} else if ( *endptr == 'm') { // p::m:
+AVDictionaryEntry *tag;
+char *key, *val;
+int ret = 0;
+
+if (*(++endptr) != ':') {
+av_log(s, AV_LOG_ERROR, "Invalid stream specifier 
syntax, missing ':' sign after :m.\n");
+return AVERROR(EINVAL);
+}
+
+val = strchr(++endptr, ':');
+key = val ? av_strndup(endptr, val - endptr) : 
av_strdup(endptr);
+if (!key)
+return AVERROR(ENOMEM);
+
+for (j = 0; j < s->programs[i]->nb_stream_indexes; j++)
+if (st->index == s->programs[i]->stream_index[j]) {
+tag = av_dict_get(st->metadata, key, NULL, 0);
+if (tag && (!val || !strcmp(tag->value, val + 1)))
+ret = 1;
+
+break;
+}
+
+av_freep();
+return ret;
+
 } else {  // p::
 int stream_idx = 

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

[Bodecs Bela]

2018.04.12. 23:53 keltezéssel, Michael Niedermayer írta:

On Thu, Apr 12, 2018 at 10:23:07AM +0200, Bodecs Bela wrote:


2018.04.12. 0:26 keltezéssel, Michael Niedermayer írta:

On Wed, Apr 11, 2018 at 10:37:41PM +0200, Bodecs Bela wrote:

fate test enclosed


2018.04.04. 10:39 keltezéssel, Bodecs Bela írta:

2018.04.04. 2:37 keltezéssel, Michael Niedermayer írta:

On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:

Dear All,

currently when specifying the program id you can only decide to select
all stream of the specified program (e.g. p:103 will select all streams
of program 103) or narrow the selection to a specific stream sub index
(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
specify like all audio streams of program 145 or 3rd video stream of
program 311.
In some case, mainly working with multiprogram mpeg-ts containers as
input, this feature would be handy.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream type and optionally its
index. Handled types: a, v, s, d.
Examples: p:601:a  will select all audio streams of program 601,
p:603:a:1 will select 2nd audio streams of program 603,
p:604:v:0 will select first video stream of program 604.
This syntax enhancement does not interfere in any way with
current/exiting syntax or working command lines

I think this is a good idea.
Can you also add fate test(s) for this ? (can be in a seperate patch
later of course)


ok, I will try.

bb


thx

[...]



___
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

  mpegts.mak |6 ++
  1 file changed, 6 insertions(+)
da6c059eab100872d0f61d14e40e46012f031bfe  
0002-fate-to-test-program-sub-stream-selection-by-its-typ.patch
 From 093bdb47d1c5093cbd9427fbd2383a1c802464bb Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Wed, 11 Apr 2018 22:33:02 +0200
Subject: [PATCH] fate: to test program sub stream selection by its type in
  mpegts

Signed-off-by: Bela Bodecs 
---
  tests/fate/mpegts.mak | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
index bb0d9d9..2b12849 100644
--- a/tests/fate/mpegts.mak
+++ b/tests/fate/mpegts.mak
@@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-la
  fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
  fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
+
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-program
+fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) -select_streams 
p:769:v:0 -i "$(SRC)"
+
+
  FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)

missing reference file

reference file './tests/ref/fate/mpegts-probe-program' not found
./tests/fate-run.sh: 419: ./tests/fate-run.sh: cannot open 
tests/data/fate/mpegts-probe-program.diff: No such file
Test mpegts-probe-program failed. Look at 
tests/data/fate/mpegts-probe-program.err for details.
make: *** [fate-mpegts-probe-program] Error 1
make: *** Waiting for unfinished jobs

[...]



sorry, ref file was not included. Corrected patch enclosed.

will apply with the related patch

thx

[...]

thank you. I got an idea how to enhance it further. I will send it soon 
in  a new thread.


bb



___
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] avcodec/aac_ac3_parser: account for data already in the parsing buffer

[Paul B Mahol]

On 4/13/18, Hendrik Leppkes  wrote:
> On Wed, Apr 11, 2018 at 1:40 PM, Hendrik Leppkes 
> wrote:
>> If a frame starts very close to a packet boundary, the start code may
>> already have been added to the parsing buffer, indicated by a small
>> negative value of "i", while the header is still being tracked in the
>> "state" variable.
>>
>> Reduce the remaining size accordingly, otherwise trying to find the next
>> frame could skip over the frame header and lump two frames together as
>> one.
>> ---
>>  libavcodec/aac_ac3_parser.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
>> index 019074b0dd..7f20626285 100644
>> --- a/libavcodec/aac_ac3_parser.c
>> +++ b/libavcodec/aac_ac3_parser.c
>> @@ -60,6 +60,8 @@ get_next:
>>  s->remaining_size += i;
>>  goto get_next;
>>  }
>> +else if (i < 0)
>> +s->remaining_size += i;
>>  }
>>  }
>>  }
>> --
>> 2.16.1.windows.4
>>
>
> Ping.
> Note that this is somewhat of a regression in AC3 parsing since the
> recent AC3+EAC3 combined stream support (the bug existed before, but
> that change exposed it).

Please add { } brackets around new code.

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

Re: [FFmpeg-devel] [PATCH] avcodec/aac_ac3_parser: account for data already in the parsing buffer

[Hendrik Leppkes]

On Wed, Apr 11, 2018 at 1:40 PM, Hendrik Leppkes  wrote:
> If a frame starts very close to a packet boundary, the start code may
> already have been added to the parsing buffer, indicated by a small
> negative value of "i", while the header is still being tracked in the
> "state" variable.
>
> Reduce the remaining size accordingly, otherwise trying to find the next
> frame could skip over the frame header and lump two frames together as
> one.
> ---
>  libavcodec/aac_ac3_parser.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> index 019074b0dd..7f20626285 100644
> --- a/libavcodec/aac_ac3_parser.c
> +++ b/libavcodec/aac_ac3_parser.c
> @@ -60,6 +60,8 @@ get_next:
>  s->remaining_size += i;
>  goto get_next;
>  }
> +else if (i < 0)
> +s->remaining_size += i;
>  }
>  }
>  }
> --
> 2.16.1.windows.4
>

Ping.
Note that this is somewhat of a regression in AC3 parsing since the
recent AC3+EAC3 combined stream support (the bug existed before, but
that change exposed it).

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dxva2: add VP9 10-bit Profile2 mode mappings

[Hendrik Leppkes]

On Thu, Apr 12, 2018 at 4:29 PM, wm4  wrote:
> On Wed, 11 Apr 2018 14:06:57 +0200
> Hendrik Leppkes  wrote:
>
>> ---
>>  libavcodec/dxva2.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
>> index 6d831599af..32416112bf 100644
>> --- a/libavcodec/dxva2.c
>> +++ b/libavcodec/dxva2.c
>> @@ -44,6 +44,7 @@ DEFINE_GUID(ff_DXVA2_ModeVC1_D2010,  0x1b81beA4, 
>> 0xa0c7,0x11d3,0xb9,0x84,0x0
>>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main,  0x5b11d51b, 
>> 0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
>>  DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main10,0x107af0e0, 
>> 0xef1a,0x4d19,0xab,0xa8,0x67,0xa1,0x63,0x07,0x3d,0x13);
>>  
>> DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_Profile0,0x463707f8,0xa1d0,0x4585,0x87,0x6d,0x83,0xaa,0x6d,0x60,0xb8,0x9e);
>> +DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_10bit_Profile2,0xa4c749ef,0x6ecf,0x48aa,0x84,0x48,0x50,0xa7,0xa1,0x16,0x5f,0xf7);
>>  DEFINE_GUID(ff_DXVA2_NoEncrypt,  0x1b81beD0, 
>> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
>>  DEFINE_GUID(ff_GUID_NULL,0x, 
>> 0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
>>  DEFINE_GUID(ff_IID_IDirectXVideoDecoderService, 
>> 0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
>> @@ -67,6 +68,10 @@ static const int prof_hevc_main[]= 
>> {FF_PROFILE_HEVC_MAIN,
>>  FF_PROFILE_UNKNOWN};
>>  static const int prof_hevc_main10[]  = {FF_PROFILE_HEVC_MAIN_10,
>>  FF_PROFILE_UNKNOWN};
>> +static const int prof_vp9_profile0[] = {FF_PROFILE_VP9_0,
>> +FF_PROFILE_UNKNOWN};
>> +static const int prof_vp9_profile2[] = {FF_PROFILE_VP9_2,
>> +FF_PROFILE_UNKNOWN};
>>
>>  static const dxva_mode dxva_modes[] = {
>>  /* MPEG-2 */
>> @@ -90,7 +95,8 @@ static const dxva_mode dxva_modes[] = {
>>  { _DXVA2_ModeHEVC_VLD_Main,   AV_CODEC_ID_HEVC, prof_hevc_main },
>>
>>  /* VP8/9 */
>> -{ _DXVA2_ModeVP9_VLD_Profile0,AV_CODEC_ID_VP9 },
>> +{ _DXVA2_ModeVP9_VLD_Profile0,   AV_CODEC_ID_VP9, 
>> prof_vp9_profile0 },
>> +{ _DXVA2_ModeVP9_VLD_10bit_Profile2, AV_CODEC_ID_VP9, 
>> prof_vp9_profile2 },
>>
>>  { NULL,  0 },
>>  };
>
> Both patches LGTM.

Applied this set.

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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Friday, April 13, 2018 1:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type 
> AV_HWDEVICE_TYPE_DXVA2 support
> 

Hi Mark,
I have sent updated patch with my fixes and my comments according on your 
review in the following subject and link, 
could you please review?

Subject : [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support 
implementation by AMF encoder
Archive link: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228214.html

Thanks,
Alexander

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

[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Alexander Kravchenko]

This patch contains DXVA2 textures support implementation by AMF encoder (in 
addition of D3D11 textures)

Samples of usage:
DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i 
input.mp4 -an -c:v h264_amf out.mkv

D3D11va decoder -> d3d11 texture -> AMF Encoder:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i 
input.mp4 -an -c:v h264_amf out.mkv

---
Sending updated patch (Fixes according Mark's review):
> > ---
>^
> (When adding commentary which isn't part of the commit message to an email 
> please place it after this line so that it doesn't end up in the commit 
> message.)
Done here, hopefully correctly

> >  { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> > +{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
> 
> As with D3D11, this isn't necessarily true.  This was ignored before, but do 
> you have any plan for how P010 (and others?) will be handled here?
removed HW types from format map, and added logic reading pixel format from 
avctx->sw_pix_fmt in case if avctx->pix_fmt is HWACCEL type

> +static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
> IDirect3DDevice9 **device, void *avcl) {
> ...
> Might be cleaner using an error return rather than the null device?
Fixed

> Everything using D3D9 types needs to be inside CONFIG_DXVA2
Fixed

> Passing NULL here will make this case succeed in cases where it shouldn't, I 
> think?
Agree, fixed

> Tbh I don't think this fallback case should exist at all, it should just fail.
> Is there any use-case for having it?  The user passed a DXVA2 frames context 
> on a 
> non-AMD device and expects it to work with that hardware input, this fallback 
> makes 
> it kindof work with at least two copies in a way which is likely to be very 
> slow.  
> Even if the user does want to do that, it would be better for them to do it 
> explicitly 
> to ensure that they aware of the problem.  (We don't automatically do this in 
> any other case.)
Agree, fixed

> Spurious whitespace.
Fixed in changed blocks/functions

> Tested on Windows 7, works well.  
> Unlike with D3D11 the OpenCL interop works properly as well, 
> so e.g. -vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1 
> 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' as encoder input 
> works too.
Could you send the samples (or link if they are published, I will add to my 
tests and will check OpenCL interop with D3D11)



 libavcodec/amfenc.c | 158 +---
 1 file changed, 126 insertions(+), 32 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..7cdf17a972 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 #if CONFIG_D3D11VA
 AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_NONE
 };
@@ -68,7 +74,6 @@ static const FormatMap format_map[] =
 { AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
 { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
 { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
-{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
 };
 
 
@@ -152,6 +157,26 @@ static int amf_load_library(AVCodecContext *avctx)
 return 0;
 }
 
+#if CONFIG_DXVA2
+static HRESULT get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(hr = devmgr->lpVtbl->OpenDeviceHandle(devmgr, 
_handle))) {
+if (SUCCEEDED(hr = devmgr->lpVtbl->LockDevice(devmgr, device_handle, 
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for 
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9 
device: %lx.\n", (unsigned long)hr);
+}
+return hr;
+}
+#endif
+
 static int amf_init_context(AVCodecContext *avctx)
 {
 AmfContext *ctx = avctx->priv_data;
@@ -177,34 +202,61 @@ static int amf_init_context(AVCodecContext *avctx)
 res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext() 
failed with error %d\n", res);
 // try to reuse existing DX device
-#if CONFIG_D3D11VA
 if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if 

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove redundant code

[Jun Zhao]

On 2018/4/12 16:48, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hls.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index ae0545a086..74f0c2ccc5 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -945,14 +945,8 @@ static struct segment *next_segment(struct playlist *pls)
>  return pls->segments[n];
>  }
>  
> -enum ReadFromURLMode {
> -READ_NORMAL,
> -READ_COMPLETE,
> -};
> -
>  static int read_from_url(struct playlist *pls, struct segment *seg,
> - uint8_t *buf, int buf_size,
> - enum ReadFromURLMode mode)
> + uint8_t *buf, int buf_size)
>  {
>  int ret;
>  
> @@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls, struct 
> segment *seg,
>  if (seg->size >= 0)
>  buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
>  
> -if (mode == READ_COMPLETE) {
> -ret = avio_read(pls->input, buf, buf_size);
> -if (ret != buf_size)
> -av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
> -} else
> -ret = avio_read(pls->input, buf, buf_size);
> +ret = avio_read(pls->input, buf, buf_size);
> +if (ret != buf_size)
> +av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
>  
>  if (ret > 0)
>  pls->cur_seg_offset += ret;
> @@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
> *buf,
>  while (1) {
>  /* see if we can retrieve enough data for ID3 header */
>  if (*len < ID3v2_HEADER_SIZE && buf_size >= ID3v2_HEADER_SIZE) {
> -bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
> *len, READ_COMPLETE);
> +bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE - 
> *len);
>  if (bytes > 0) {
>  
>  if (bytes == ID3v2_HEADER_SIZE - *len)
> @@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
> *buf,
>  
>  if (remaining > 0) {
>  /* read the rest of the tag in */
> -if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
> remaining, READ_COMPLETE) != remaining)
> +if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos, 
> remaining) != remaining)
>  break;
>  id3_buf_pos += remaining;
>  av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional %d HLS 
> ID3 bytes\n", remaining);
> @@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
> *buf,
>  
>  /* re-fill buffer for the caller unless EOF */
>  if (*len >= 0 && (fill_buf || *len == 0)) {
> -bytes = read_from_url(pls, seg, buf + *len, buf_size - *len, 
> READ_NORMAL);
> +bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
>  
>  /* ignore error if we already had some data */
>  if (bytes >= 0)
> @@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist *pls, 
> struct segment *seg)
>  av_fast_malloc(>init_sec_buf, >init_sec_buf_size, sec_size);
>  
>  ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
> -pls->init_sec_buf_size, READ_COMPLETE);
> +pls->init_sec_buf_size);
Didn't care ret < pls->init_sec_buf_size ?
>  ff_format_io_close(pls->parent, >input);
>  
>  if (ret < 0)
> @@ -1506,7 +1497,7 @@ reload:
>  }
>  
>  seg = current_segment(v);
> -ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
> +ret = read_from_url(v, seg, buf, buf_size);
>  if (ret > 0) {
>  if (just_opened && v->is_id3_timestamped != 0) {
>  /* Intercept ID3 tags here, elementary audio streams are required
LGTM except one question.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: add support for new extended sps/pps flags from SDK 8.1

[Timo Rothenpieler]

> LGTM.
> 
> 
> --phil

applied



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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Hendrik Leppkes]

On Fri, Apr 13, 2018 at 12:24 AM, Carl Eugen Hoyos  wrote:
> 2018-04-13 0:11 GMT+02:00, Alexander Kravchenko :
>>
>>
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>>> Carl Eugen Hoyos
>>> Sent: Friday, April 13, 2018 12:48 AM
>>> To: FFmpeg development discussions and patches 
>>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
>>> implementation by AMF encoder
>>>
>>> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko
>>> :
>>> >
>>> > This patch contains DXVA2 textures support implementation by AMF
>>> > encoder (in addition of D3D11 textures)
>>>
>>> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA
>
> (There is a linebreak in your original and my mail afaict.)
>
>>> > +if (frames_ctx->device_ctx->type ==
>>> > AV_HWDEVICE_TYPE_D3D11VA) {
>>>
>>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
>>>
>>> same below.
>>>
>>
>> Hi Carl, thanks for your feedback
>>
>> Could you explain the reason replacing
>> if (frames_ctx->device_ctx->type ==
>> to
>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==
>
> The code gets more readable / less ugly.
>

The code needs to be under an actual preprocessor check though, as the
types referenced in there may not be valid when D3D11 is not available
on the system.

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