Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread wm4
On Mon, 12 Mar 2018 17:05:30 +0100
Paul B Mahol  wrote:

> On 3/12/18, Nicolas George  wrote:
> > Paul B Mahol (2018-03-12):  
> >> > What are these avfilter limitations you speak of?  
> >  
> >> Sure.  
> >
> > Is "sure" supposed to be an answer to that question?  
> 
> Look at thread for stereo3d video filter patch.

Right, it can't know the output format until it sees an AVFrame with
the side data. But in libavfilter it needs to report the output format
before any frame is input. Fixing it requires either adding side data
to the input/output filter pad configuration, or dynamic
reconfiguration at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/4] lavf/movenc: keep eac3_priv around; fixes eac3 in DASH

2018-03-12 Thread Rodger Combs
DASH muxing sometimes calls mov_write_eac3_tag multiple times on the same 
stream.
We need to keep this data around so it's available in the second call, else we
won't write the data QuickTime needs.
---
 libavformat/movenc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 353a42ae2c..d4bc4e8995 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -554,7 +554,6 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack 
*track)
 
 end:
 av_packet_unref(>pkt);
-av_freep(>eac3_priv);
 
 return size;
 }
-- 
2.16.2

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


[FFmpeg-devel] [PATCH 4/4] lavf/dashenc: don't call flush_init_segment before avformat_write_header

2018-03-12 Thread Rodger Combs
Fixes crash when muxing MKV-in-DASH
---
 libavformat/dashenc.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5689aef811..63ff827583 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -985,13 +985,6 @@ static int dash_init(AVFormatContext *s)
 
 av_log(s, AV_LOG_VERBOSE, "Representation %d init segment will be 
written to: %s\n", i, filename);
 
-// Flush init segment
-// except for mp4, since delay_moov is set and the init segment
-// is then flushed after the first packets
-if (strcmp(os->format_name, "mp4")) {
-flush_init_segment(s, os);
-}
-
 s->streams[i]->time_base = st->time_base;
 // If the muxer wants to shift timestamps, request to have them shifted
 // already before being handed to this muxer, so we don't have 
mismatches
@@ -1032,6 +1025,9 @@ static int dash_write_header(AVFormatContext *s)
 OutputStream *os = >streams[i];
 if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
 return ret;
+
+if ((ret = flush_init_segment(s, os)) < 0)
+return ret;
 }
 ret = write_manifest(s, 0);
 if (!ret)
-- 
2.16.2

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


[FFmpeg-devel] [PATCH 1/4] lavf/movenc: fix leak of eac3_priv

2018-03-12 Thread Rodger Combs
This could previously happen in error or early-exit cases. The next commit
would make it happen in all cases.
---
 libavformat/movenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5b1e66c897..353a42ae2c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5772,6 +5772,7 @@ static void mov_free(AVFormatContext *s)
 av_freep(>tracks[i].par);
 av_freep(>tracks[i].cluster);
 av_freep(>tracks[i].frag_info);
+av_freep(>tracks[i].eac3_priv);
 
 if (mov->tracks[i].vos_len)
 av_freep(>tracks[i].vos_data);
-- 
2.16.2

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


[FFmpeg-devel] [PATCH 3/4] lavf/dashenc: remove unneeded call to dash_free

2018-03-12 Thread Rodger Combs
---
 libavformat/dashenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 79d63e52d4..5689aef811 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1030,10 +1030,8 @@ static int dash_write_header(AVFormatContext *s)
 int i, ret;
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
-if ((ret = avformat_write_header(os->ctx, NULL)) < 0) {
-dash_free(s);
+if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
 return ret;
-}
 }
 ret = write_manifest(s, 0);
 if (!ret)
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: fix for zero EXTINFtag duration

2018-03-12 Thread Dixit, Vishwanath


On 3/12/18, 8:55 PM, "刘歧"  wrote:

>> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
>> 
>> From: Vishwanath Dixit 
>> 
>> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
>> ---
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 08fe0aa..7d9512b 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2501,7 +2501,7 @@ static int hls_init(AVFormatContext *s)
>> /* Get one video stream to reference for split segments
>>  * so use the first video stream index. */
>> if ((vs->has_video == 1) && 
>> (vs->streams[j]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)) {
>> -vs->reference_stream_index = j;
>> +vs->reference_stream_index = vs->streams[j]->index;
>> }
>> vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
>> AVMEDIA_TYPE_SUBTITLE;
>> }
>> -- 
>> 1.9.1
>> 
>
>LGTM
>
>Thanks
>Steven
>
>
>
>pushed
Thank you Steven…

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


Re: [FFmpeg-devel] [PATCH 2/2] lavf/vaapi_encode: fix to set the default max bitrate for AVC VBR

2018-03-12 Thread Qu, Pengfei


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Monday, March 12, 2018 8:54 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavf/vaapi_encode: fix to set the 
default max bitrate for AVC VBR

On 12/03/18 05:38, Pengfei Qu wrote:
> And for VBR mode, generally the max bit rate is bigger than the taraget
> bitrate. For CBR mode, the max bitrate is same as the target bitrate.
>  when there is no specfic setting for the max bit rate parameter,
> here the default value 95% is used to caculate the default max bitrate 
> accordingly.
> 
> Signed-off-by: Pengfei Qu 
> ---
>  libavcodec/vaapi_encode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c 
> index 78347d4..47110cf 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1164,8 +1164,8 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  } else {
>  if (avctx->rc_max_rate < avctx->bit_rate) {
>  // Max rate is unset or invalid, just use the normal bitrate.
> -rc_bits_per_second   = avctx->bit_rate;
> -rc_target_percentage = 100;
> +rc_target_percentage = 95;
> +rc_bits_per_second   = (unsigned long)(avctx->bit_rate * 100.0 / 
> rc_target_percentage);
>  } else {
>  rc_bits_per_second   = avctx->rc_max_rate;
>  rc_target_percentage = (unsigned long)(avctx->bit_rate * 
> 100) / rc_bits_per_second;
> 

Can you give more detail about the motivation for this change?

In particular:
* You say you are fixing something - what is the issue?
* Where has the 95% number come from?
* Do you want this to apply to all codecs?  (The commit message says AVC.)

[Pengfei] 

The current RC(CBR/VBR) mode in ffmpeg-vaapi depends on the target bitrate and 
max bitrate. CBR when target bitrate equal to max bitrate, or VBR. 

Here is the background to have this solution. One issue I saw when doing 
transcoding Mpeg2(interlace)->AVC on VBR mode, the real output bitrate go away 
too much compared to target bitrate when there is no max bitrate parameter in 
the command line. It work well when set the correct max bitrate parameter in 
the command line.

For this situation, the value rc_max_rate will be zero if there is not 
specified parameter for max bitrate in the command line. And then the execution 
fall into this condition" if (avctx->rc_max_rate < avctx->bit_rate) ", here the 
default max bitrate same as the target bitrate as the rc_target_percentage=100. 
The value "95" is also the experienced value and i give an initial max bitrate 
closer to the target bitrate and avoid bigger fluctuation in the default "max 
bitrate" mode. 

I think it is common rule to all codecs.

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


Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: fix the caculation overflow

2018-03-12 Thread Qu, Pengfei


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Tuesday, March 13, 2018 6:54 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: fix the caculation 
overflow

On 12/03/18 05:38, Pengfei Qu wrote:
> this fix the overflow during the caculation before value assignment.
> 
> Signed-off-by: Pengfei Qu 
> ---
>  libavcodec/vaapi_encode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c 
> index 36c85a3..78347d4 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1168,9 +1168,9 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  rc_target_percentage = 100;
>  } else {
>  rc_bits_per_second   = avctx->rc_max_rate;
> -rc_target_percentage = (avctx->bit_rate * 100) / 
> rc_bits_per_second;
> +rc_target_percentage = (unsigned long)(avctx->bit_rate * 
> + 100) / rc_bits_per_second;

What is the problem here?  All this will do is truncate the 64-bit value on 
platforms with 32-bit long.
[Pengfei] same as the below.
>  }
> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
> +rc_window_size = (unsigned long)(hrd_buffer_size * 1000) / 
> + avctx->bit_rate;

Perhaps you want to ensure that the multiplication doesn't overflow rather than 
truncating the result after it has overflowed.
[Pengfei] Yes.
>  }
>  
>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/7] hwcontext_vaapi: Add support for legacy DRM mapping

2018-03-12 Thread Rostislav Pehlivanov
On 12 March 2018 at 22:46, Mark Thompson  wrote:

> On 12/03/18 17:40, Rostislav Pehlivanov wrote:
> > On 12 March 2018 at 00:23, Mark Thompson  wrote:
> >
> >> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
> >>> On 11 March 2018 at 22:41, Mark Thompson  wrote:
> >>>
>  The old vaAcquireBufferHandle() API works in fewer cases and provides
>  less information than the current vaExportSurfaceHandle(), but it
> exists
>  on older versions and is already used by the OpenCL code.  This
> probably
>  doesn't have much use directly, but it will be used to replace the
> >> ad-hoc
>  OpenCL code in a following patch.
>  ---
>   libavutil/hwcontext_vaapi.c | 191 ++
>  +++---
>   1 file changed, 179 insertions(+), 12 deletions(-)
> 
>  ...
> >>>
> >>> Why? libva 1.1.0 is 6 years old now. It doesn't make sense to have 2
> >> pieces
> >>> of code to do the same thing.
> >>
> >> VAAPI 1.1.0 != libva 1.1.0.  VAAPI 1.1.0 is in libva 2.1.0, released
> last
> >> month.
> >>
> >> (This is not confusing at all.)
> >>
> >
> > ABH seems pretty much worse than ESH, and considering you can't get the
> > format modifiers makes it useless for Vulkan. I don't see why we need to
> > support it in addition to ESH.
>
> It's what it currently used by the Beignet/OpenCL interop (since it was
> the only thing which existed when that was written, and the format modifier
> isn't needed), and I don't want to break that.
>
> Since it was only released a few weeks ago it will probably be a while
> before it lands in all distributions, and it isn't implemented at all by
> the Intel ex-blob driver yet.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
>
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

In this case wouldn't it be better if the ABH mapping function is moved to
hwcontext_opencl? Then hwcontext_vaapi can be trusted to always produce
completely mapped to DRM frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] vc2enc: properly promote operations to 64 bits

2018-03-12 Thread Rostislav Pehlivanov
On 12 March 2018 at 23:36, Rostislav Pehlivanov  wrote:

> On Windows machines, the UL suffix still means 32 bits.
> The only parts that need 64 bits are (1ULL << (m + 32)) and
> (t*qf + qf). Hence, use the proper ULL suffix for the former
> and just increase the type of the qf constant for the latter.
> No overflows can happen as long as these are done in 64 bits and
> the quantization table doesn't change.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/vc2enc.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
> index 2e480ba8d0..d0101e01e4 100644
> --- a/libavcodec/vc2enc.c
> +++ b/libavcodec/vc2enc.c
> @@ -1163,14 +1163,14 @@ static av_cold int vc2_encode_init(AVCodecContext
> *avctx)
>  goto alloc_fail;
>
>  for (i = 0; i < 116; i++) {
> -const uint32_t qf = ff_dirac_qscale_tab[i];
> -const int m = av_log2(qf);
> -const uint32_t t = (1UL << (m + 32)) / qf;
> -const uint32_t r = (t*qf + qf) & ((1UL << 32) - 1);
> +const uint64_t qf = ff_dirac_qscale_tab[i];
> +const uint32_t m = av_log2(qf);
> +const uint32_t t = (1ULL << (m + 32)) / qf;
> +const uint32_t r = (t*qf + qf) & UINT32_MAX;
>  if (!(qf & (qf - 1))) {
>  s->qmagic_lut[i][0] = 0x;
>  s->qmagic_lut[i][1] = 0x;
> -} else if (r <= 1UL << m) {
> +} else if (r <= 1 << m) {
>  s->qmagic_lut[i][0] = t + 1;
>  s->qmagic_lut[i][1] = 0;
>  } else {
> --
> 2.16.2
>
>
Fixes what its meant to fix, pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-12 Thread Aman Gupta
From: Aman Gupta 

---
 libavcodec/h264_slice.c|  5 +++--
 libavcodec/mpeg12dec.c | 12 +++-
 libavcodec/mpegvideo_enc.c |  3 ++-
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 90e05ed8f1..b381397b4d 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -2762,7 +2762,7 @@ int ff_h264_execute_decode_slices(H264Context *h)
 
 sl = >slice_ctx[i];
 if (CONFIG_ERROR_RESILIENCE) {
-sl->er.error_count = 0;
+sl->er.error_count = ATOMIC_VAR_INIT(0);
 }
 
 /* make sure none of those slices overlap */
@@ -2786,7 +2786,8 @@ int ff_h264_execute_decode_slices(H264Context *h)
 h->mb_y  = sl->mb_y;
 if (CONFIG_ERROR_RESILIENCE) {
 for (i = 1; i < context_count; i++)
-h->slice_ctx[0].er.error_count += 
h->slice_ctx[i].er.error_count;
+atomic_fetch_add(>slice_ctx[0].er.error_count,
+ atomic_load(>slice_ctx[i].er.error_count));
 }
 
 if (h->postpone_filter) {
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 9e076e89da..5a8570672c 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1992,7 +1992,7 @@ static int slice_decode_thread(AVCodecContext *c, void 
*arg)
 int mb_y= s->start_mb_y;
 const int field_pic = s->picture_structure != PICT_FRAME;
 
-s->er.error_count = (3 * (s->end_mb_y - s->start_mb_y) * s->mb_width) >> 
field_pic;
+s->er.error_count = ATOMIC_VAR_INIT((3 * (s->end_mb_y - s->start_mb_y) * 
s->mb_width) >> field_pic);
 
 for (;;) {
 uint32_t start_code;
@@ -2002,7 +2002,7 @@ static int slice_decode_thread(AVCodecContext *c, void 
*arg)
 emms_c();
 ff_dlog(c, "ret:%d resync:%d/%d mb:%d/%d ts:%d/%d ec:%d\n",
 ret, s->resync_mb_x, s->resync_mb_y, s->mb_x, s->mb_y,
-s->start_mb_y, s->end_mb_y, s->er.error_count);
+s->start_mb_y, s->end_mb_y, atomic_load(>er.error_count));
 if (ret < 0) {
 if (c->err_recognition & AV_EF_EXPLODE)
 return ret;
@@ -2485,7 +2485,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
>thread_context[0], NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count += 
s2->thread_context[i]->er.error_count;
+atomic_fetch_add(>er.error_count,
+ 
atomic_load(>thread_context[i]->er.error_count));
 }
 
 ret = slice_end(avctx, picture);
@@ -2499,7 +2500,7 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
 }
 s2->pict_type = 0;
 
-if (avctx->err_recognition & AV_EF_EXPLODE && s2->er.error_count)
+if (avctx->err_recognition & AV_EF_EXPLODE && 
atomic_load(>er.error_count))
 return AVERROR_INVALIDDATA;
 
 return FFMAX(0, buf_ptr - buf - s2->parse_context.last_index);
@@ -2553,7 +2554,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
s2->thread_context, NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count += 
s2->thread_context[i]->er.error_count;
+atomic_fetch_add(>er.error_count,
+ 
atomic_load(>thread_context[i]->er.error_count));
 s->slice_count = 0;
 }
 if (last_code == 0 || last_code == SLICE_MIN_START_CODE) {
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 979e138b88..3447c5e87a 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3595,7 +3595,8 @@ static void merge_context_after_encode(MpegEncContext 
*dst, MpegEncContext *src)
 MERGE(b_count);
 MERGE(skip_count);
 MERGE(misc_bits);
-MERGE(er.error_count);
+atomic_fetch_add(>er.error_count, atomic_load(>er.error_count));
+atomic_store(>er.error_count, 0);
 MERGE(padding_bug_score);
 MERGE(current_picture.encoding_error[0]);
 MERGE(current_picture.encoding_error[1]);
-- 
2.14.2

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


Re: [FFmpeg-devel] [PATCH v5] avformat/pcm: decrease delay when reading PCM streams.

2018-03-12 Thread Michael Niedermayer
On Sat, Mar 10, 2018 at 03:55:06PM +0100, Paul B Mahol wrote:
> On 3/10/18, Philipp M. Scholl  wrote:
> >   Thanks for the discussion. Here's the next version, now with /25 and
> > removed
> > ff_log2().
> >
> >   The blocksize of the PCM decoder is hard-coded. This creates
> > unnecessary delay when reading low-rate (<100Hz) streams. This creates
> > issues when multiplexing multiple streams, since other inputs are only
> > opened/read after a low-rate input block was completely read.
> >
> >  This patch decreases the blocksize for low-rate inputs, so
> > approximately a block is read every 40ms. This decreases the startup
> > delay when multiplexing inputs with different rates.
> >
> > Signed-off-by: Philipp M. Scholl 
> > ---
> >  libavformat/pcm.c | 13 ++---
> >  tests/ref/seek/lavf-alaw  | 42 +-
> >  tests/ref/seek/lavf-mulaw | 42 +-
> >  3 files changed, 52 insertions(+), 45 deletions(-)
> >
> 
> OK

will apply

thx

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

It is what and why we do it that matters, not just one of them.


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


Re: [FFmpeg-devel] [PATCH 5/8] h264_metadata: Update documentation

2018-03-12 Thread Michael Niedermayer
On Sun, Mar 11, 2018 at 06:30:18PM +, Mark Thompson wrote:
> Improve documentation for the delete_filler option, and add the
> display_orientation and a53_cc options.
> ---
>  doc/bitstream_filters.texi | 50 
> +-
>  1 file changed, 49 insertions(+), 1 deletion(-)

overall LGTM (english not reviewed, thats not my area ;)

thx

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

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


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


Re: [FFmpeg-devel] [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

2018-03-12 Thread Jun Zhao


On 2018/3/12 22:23, James Almer wrote:
> On 3/11/2018 10:23 PM, Jun Zhao wrote:
>> V2: update opt fate test ref file
> Unrelated to this patch, but can you please make sure to the patchsets
> you send are contained in a single thread? Every email in a set after
> the first should be a reply to it.
Now I working in a unfriendly network environment for open source
development/
patches submit, so I can't use git send-mail, I use a thunderbird GUI
mail client send
the patch with the attached file, this is the reason I can't send the
patchsets
in a single thread.
> ___
> 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] h264_mp4toannexb_bsf: Fix start code size of parameter sets.

2018-03-12 Thread Michael Niedermayer
On Sun, Mar 11, 2018 at 11:56:46PM +0900, Yusuke Nakamura wrote:
> 2018-02-13 1:45 GMT+09:00 Yusuke Nakamura :
> 
> > Any parameter set shall have start code of at least 4 byte size.
> > ---
> >  libavcodec/h264_mp4toannexb_bsf.c| 22 +++---
> >  tests/ref/fate/h264-bsf-mp4toannexb  |  2 +-
> >  tests/ref/fate/h264_mp4toannexb_ticket2991   | 22 +++---
> >  tests/ref/fate/h264_mp4toannexb_ticket5927   | 10 +-
> >  tests/ref/fate/h264_mp4toannexb_ticket5927_2 | 10 +-
> >  tests/ref/fate/segment-mp4-to-ts |  4 ++--
> >  6 files changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/libavcodec/h264_mp4toannexb_bsf.c
> > b/libavcodec/h264_mp4toannexb_bsf.c
> > index 163d0f5..292d106 100644
> > --- a/libavcodec/h264_mp4toannexb_bsf.c
> > +++ b/libavcodec/h264_mp4toannexb_bsf.c
> > @@ -39,21 +39,21 @@ typedef struct H264BSFContext {
> >
> >  static int alloc_and_copy(AVPacket *out,
> >const uint8_t *sps_pps, uint32_t sps_pps_size,
> > -  const uint8_t *in, uint32_t in_size)
> > +  const uint8_t *in, uint32_t in_size, int ps)
> >  {
> >  uint32_t offset = out->size;
> > -uint8_t nal_header_size = offset ? 3 : 4;
> > +uint8_t start_code_size = offset == 0 || ps ? 4 : 3;
> >  int err;
> >
> > -err = av_grow_packet(out, sps_pps_size + in_size + nal_header_size);
> > +err = av_grow_packet(out, sps_pps_size + in_size + start_code_size);
> >  if (err < 0)
> >  return err;
> >
> >  if (sps_pps)
> >  memcpy(out->data + offset, sps_pps, sps_pps_size);
> > -memcpy(out->data + sps_pps_size + nal_header_size + offset, in,
> > in_size);
> > -if (!offset) {
> > -AV_WB32(out->data + sps_pps_size, 1);
> > +memcpy(out->data + sps_pps_size + start_code_size + offset, in,
> > in_size);
> > +if (start_code_size == 4) {
> > +AV_WB32(out->data + offset + sps_pps_size, 1);
> >  } else {
> >  (out->data + offset + sps_pps_size)[0] =
> >  (out->data + offset + sps_pps_size)[1] = 0;
> > @@ -221,7 +221,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> > AVPacket *out)
> >  if ((ret = alloc_and_copy(out,
> >   ctx->par_out->extradata +
> > s->sps_offset,
> >   s->pps_offset != -1 ?
> > s->pps_offset : ctx->par_out->extradata_size - s->sps_offset,
> > - buf, nal_size)) < 0)
> > + buf, nal_size, 1)) < 0)
> >  goto fail;
> >  s->idr_sps_seen = 1;
> >  goto next_nal;
> > @@ -239,21 +239,21 @@ static int h264_mp4toannexb_filter(AVBSFContext
> > *ctx, AVPacket *out)
> >  if (s->new_idr && unit_type == 5 && !s->idr_sps_seen &&
> > !s->idr_pps_seen) {
> >  if ((ret=alloc_and_copy(out,
> > ctx->par_out->extradata,
> > ctx->par_out->extradata_size,
> > -   buf, nal_size)) < 0)
> > +   buf, nal_size, 1)) < 0)
> >  goto fail;
> >  s->new_idr = 0;
> >  /* if only SPS has been seen, also insert PPS */
> >  } else if (s->new_idr && unit_type == 5 && s->idr_sps_seen &&
> > !s->idr_pps_seen) {
> >  if (s->pps_offset == -1) {
> >  av_log(ctx, AV_LOG_WARNING, "PPS not present in the
> > stream, nor in AVCC, stream may be unreadable\n");
> > -if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size)) <
> > 0)
> > +if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size,
> > 0)) < 0)
> >  goto fail;
> >  } else if ((ret = alloc_and_copy(out,
> >  ctx->par_out->extradata +
> > s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
> > -buf, nal_size)) < 0)
> > +buf, nal_size, 1)) < 0)
> >  goto fail;
> >  } else {
> > -if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size)) < 0)
> > +if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size,
> > unit_type == 7 || unit_type == 8)) < 0)
> >  goto fail;
> >  if (!s->new_idr && unit_type == 1) {
> >  s->new_idr = 1;
> > diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
> > b/tests/ref/fate/h264-bsf-mp4toannexb
> > index 2049f39..7cd086a 100644
> > --- a/tests/ref/fate/h264-bsf-mp4toannexb
> > +++ b/tests/ref/fate/h264-bsf-mp4toannexb
> > @@ -1 +1 @@
> > -5f04c27cc6ee8625fe2405fb0f7da9a3
> > +f340e7ca9a46d437af4e96f6c8de221c
> > diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
> > 

Re: [FFmpeg-devel] [PATCH 2/8] cbs_h265: Use helper macro for maximum values of fixed-width elements

2018-03-12 Thread Jun Zhao


On 2018/3/12 20:47, Mark Thompson wrote:
> On 12/03/18 00:41, Jun Zhao wrote:
>> On 2018/3/12 2:30, Mark Thompson wrote:
>>> Apply the same logic as the previous patch to H.265.  There are no cases
>>> which currently overflow here, but this is still more consistent.
>>> ---
>>>  libavcodec/cbs_h265_syntax_template.c | 16 
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/libavcodec/cbs_h265_syntax_template.c 
>>> b/libavcodec/cbs_h265_syntax_template.c
>>> index dae7f2dd46..140c827c9d 100644
>>> --- a/libavcodec/cbs_h265_syntax_template.c
>>> +++ b/libavcodec/cbs_h265_syntax_template.c
>>> @@ -665,7 +665,7 @@ static int 
>>> FUNC(sps_scc_extension)(CodedBitstreamContext *ctx, RWContext *rw,
>>>: 
>>> current->bit_depth_chroma_minus8 + 8;
>>>  for (i = 0; i <= 
>>> current->sps_num_palette_predictor_initializer_minus1; i++)
>>>  u(bit_depth, 
>>> sps_palette_predictor_initializers[comp][i],
>>> -  0, (1 << bit_depth) - 1);
>>> +  0, MAX_UINT_BITS(bit_depth));
>>>  }
>>>  }
>>>  }
>>> @@ -827,7 +827,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
>>> RWContext *rw,
>>>  for (i = 0; i < current->num_long_term_ref_pics_sps; i++) {
>>>  u(current->log2_max_pic_order_cnt_lsb_minus4 + 4,
>>>lt_ref_pic_poc_lsb_sps[i],
>>> -  0, (1 << (current->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 
>>> 1);
>>> +  0, MAX_UINT_BITS(current->log2_max_pic_order_cnt_lsb_minus4 
>>> + 4));
>>>  flag(used_by_curr_pic_lt_sps_flag[i]);
>>>  }
>>>  }
>>> @@ -845,7 +845,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
>>> RWContext *rw,
>>>  flag(sps_multilayer_extension_flag);
>>>  flag(sps_3d_extension_flag);
>>>  flag(sps_scc_extension_flag);
>>> -u(4, sps_extension_4bits, 0, (1 << 4) - 1);
>>> +u(4, sps_extension_4bits, 0, MAX_UINT_BITS(4));
>>>  }
>>>  
>>>  if (current->sps_range_extension_flag)
>>> @@ -925,7 +925,7 @@ static int 
>>> FUNC(pps_scc_extension)(CodedBitstreamContext *ctx, RWContext *rw,
>>>: 
>>> current->chroma_bit_depth_entry_minus8 + 8;
>>>  for (i = 0; i < 
>>> current->pps_num_palette_predictor_initializer; i++)
>>>  u(bit_depth, 
>>> pps_palette_predictor_initializers[comp][i],
>>> -  0, (1 << bit_depth) - 1);
>>> +  0, MAX_UINT_BITS(bit_depth));
>>>  }
>>>  }
>>>  }
>>> @@ -1038,7 +1038,7 @@ static int FUNC(pps)(CodedBitstreamContext *ctx, 
>>> RWContext *rw,
>>>  flag(pps_multilayer_extension_flag);
>>>  flag(pps_3d_extension_flag);
>>>  flag(pps_scc_extension_flag);
>>> -u(4, pps_extension_4bits, 0, (1 << 4) - 1);
>>> +u(4, pps_extension_4bits, 0, MAX_UINT_BITS(4));
>>>  }
>>>  if (current->pps_range_extension_flag)
>>>  CHECK(FUNC(pps_range_extension)(ctx, rw, current));
>>> @@ -1274,7 +1274,7 @@ static int 
>>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>>  const H265RawSTRefPicSet *rps;
>>>  
>>>  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4, 
>>> slice_pic_order_cnt_lsb,
>>> -  0, (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1);
>>> +  0, MAX_UINT_BITS(sps->log2_max_pic_order_cnt_lsb_minus4 + 
>>> 4));
>>>  
>>>  flag(short_term_ref_pic_set_sps_flag);
>>>  if (!current->short_term_ref_pic_set_sps_flag) {
>>> @@ -1321,7 +1321,7 @@ static int 
>>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>>  ++num_pic_total_curr;
>>>  } else {
>>>  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4, 
>>> poc_lsb_lt[i],
>>> -  0, (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 
>>> + 4)) - 1);
>>> +  0, 
>>> MAX_UINT_BITS(sps->log2_max_pic_order_cnt_lsb_minus4 + 4));
>>>  flag(used_by_curr_pic_lt_flag[i]);
>>>  if (current->used_by_curr_pic_lt_flag[i])
>>>  ++num_pic_total_curr;
>>> @@ -1487,7 +1487,7 @@ static int 
>>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>>  ue(offset_len_minus1, 0, 31);
>>>  for (i = 0; i < current->num_entry_point_offsets; i++)
>>>  u(current->offset_len_minus1 + 1, 
>>> entry_point_offset_minus1[i],
>>> -  0, (1 << (current->offset_len_minus1 + 1)) - 1);
>>> +  0, MAX_UINT_BITS(current->offset_len_minus1 + 1));
>>>  }
>>>  }
>>>  
>> Other thing about cbs_265, now cbs_264 can support SEI, but cbs_265 not,
>> is it will support SEI in cbs_265?
> 

[FFmpeg-devel] [PATCH] vc2enc: properly promote operations to 64 bits

2018-03-12 Thread Rostislav Pehlivanov
On Windows machines, the UL suffix still means 32 bits.
The only parts that need 64 bits are (1ULL << (m + 32)) and
(t*qf + qf). Hence, use the proper ULL suffix for the former
and just increase the type of the qf constant for the latter.
No overflows can happen as long as these are done in 64 bits and
the quantization table doesn't change.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 2e480ba8d0..d0101e01e4 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1163,14 +1163,14 @@ static av_cold int vc2_encode_init(AVCodecContext 
*avctx)
 goto alloc_fail;
 
 for (i = 0; i < 116; i++) {
-const uint32_t qf = ff_dirac_qscale_tab[i];
-const int m = av_log2(qf);
-const uint32_t t = (1UL << (m + 32)) / qf;
-const uint32_t r = (t*qf + qf) & ((1UL << 32) - 1);
+const uint64_t qf = ff_dirac_qscale_tab[i];
+const uint32_t m = av_log2(qf);
+const uint32_t t = (1ULL << (m + 32)) / qf;
+const uint32_t r = (t*qf + qf) & UINT32_MAX;
 if (!(qf & (qf - 1))) {
 s->qmagic_lut[i][0] = 0x;
 s->qmagic_lut[i][1] = 0x;
-} else if (r <= 1UL << m) {
+} else if (r <= 1 << m) {
 s->qmagic_lut[i][0] = t + 1;
 s->qmagic_lut[i][1] = 0;
 } else {
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: fix the caculation overflow

2018-03-12 Thread Mark Thompson
On 12/03/18 05:38, Pengfei Qu wrote:
> this fix the overflow during the caculation before value assignment.
> 
> Signed-off-by: Pengfei Qu 
> ---
>  libavcodec/vaapi_encode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 36c85a3..78347d4 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1168,9 +1168,9 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  rc_target_percentage = 100;
>  } else {
>  rc_bits_per_second   = avctx->rc_max_rate;
> -rc_target_percentage = (avctx->bit_rate * 100) / 
> rc_bits_per_second;
> +rc_target_percentage = (unsigned long)(avctx->bit_rate * 100) / 
> rc_bits_per_second;

What is the problem here?  All this will do is truncate the 64-bit value on 
platforms with 32-bit long.

>  }
> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
> +rc_window_size = (unsigned long)(hrd_buffer_size * 1000) / 
> avctx->bit_rate;

Perhaps you want to ensure that the multiplication doesn't overflow rather than 
truncating the result after it has overflowed.

>  }
>  
>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/7] hwcontext_vaapi: Add support for legacy DRM mapping

2018-03-12 Thread Mark Thompson
On 12/03/18 17:40, Rostislav Pehlivanov wrote:
> On 12 March 2018 at 00:23, Mark Thompson  wrote:
> 
>> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
>>> On 11 March 2018 at 22:41, Mark Thompson  wrote:
>>>
 The old vaAcquireBufferHandle() API works in fewer cases and provides
 less information than the current vaExportSurfaceHandle(), but it exists
 on older versions and is already used by the OpenCL code.  This probably
 doesn't have much use directly, but it will be used to replace the
>> ad-hoc
 OpenCL code in a following patch.
 ---
  libavutil/hwcontext_vaapi.c | 191 ++
 +++---
  1 file changed, 179 insertions(+), 12 deletions(-)

 ...
>>>
>>> Why? libva 1.1.0 is 6 years old now. It doesn't make sense to have 2
>> pieces
>>> of code to do the same thing.
>>
>> VAAPI 1.1.0 != libva 1.1.0.  VAAPI 1.1.0 is in libva 2.1.0, released last
>> month.
>>
>> (This is not confusing at all.)
>>
> 
> ABH seems pretty much worse than ESH, and considering you can't get the
> format modifiers makes it useless for Vulkan. I don't see why we need to
> support it in addition to ESH.

It's what it currently used by the Beignet/OpenCL interop (since it was the 
only thing which existed when that was written, and the format modifier isn't 
needed), and I don't want to break that.

Since it was only released a few weeks ago it will probably be a while before 
it lands in all distributions, and it isn't implemented at all by the Intel 
ex-blob driver yet.

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


Re: [FFmpeg-devel] [PATCH] add convolution_opencl

2018-03-12 Thread Mark Thompson
On 11/03/18 20:19, Danil Iashchenko wrote:
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/opencl/convolution.cl   |  42 
>  libavfilter/opencl_source.h |   3 +
>  libavfilter/vf_convolution_opencl.c | 464 
> 
>  6 files changed, 512 insertions(+)
>  create mode 100644 libavfilter/opencl/convolution.cl
>  create mode 100644 libavfilter/vf_convolution_opencl.c

The commit title should have a tag for the library, and maybe say a little more 
about what it does.

E.g. something like:
"""
lavfi: Add OpenCL convolution filter

Behaves like the existing convolution filter, except working on OpenCL
hardware frames.  Takes exactly the same options.
"""


When applying, git gives the warning:

Applying: add convolution_opencl
.git/rebase-apply/patch:578: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

> diff --git a/configure b/configure
> index 6916b45..7c79e20 100755
> --- a/configure
> +++ b/configure
> @@ -3212,6 +3212,7 @@ bs2b_filter_deps="libbs2b"
>  colormatrix_filter_deps="gpl"
>  convolve_filter_deps="avcodec"
>  convolve_filter_select="fft"
> +convolution_opencl_filter_deps="opencl"

These should be in alphabetical order.

>  coreimage_filter_deps="coreimage appkit"
>  coreimage_filter_extralibs="-framework OpenGL"
>  coreimagesrc_filter_deps="coreimage appkit"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6a60836..d005934 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -156,6 +156,7 @@ OBJS-$(CONFIG_COLORLEVELS_FILTER)+= 
> vf_colorlevels.o
>  OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
>  OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o 
> colorspacedsp.o
>  OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
> +OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o 
> opencl.o opencl/convolution.o
>  OBJS-$(CONFIG_CONVOLVE_FILTER)   += vf_convolve.o framesync.o
>  OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
>  OBJS-$(CONFIG_COREIMAGE_FILTER)  += vf_coreimage.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 9adb109..f2dc55e 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -166,6 +166,7 @@ static void register_all(void)
>  REGISTER_FILTER(COLORMATRIX,colormatrix,vf);
>  REGISTER_FILTER(COLORSPACE, colorspace, vf);
>  REGISTER_FILTER(CONVOLUTION,convolution,vf);
> +REGISTER_FILTER(CONVOLUTION_OPENCL, convolution_opencl, vf);
>  REGISTER_FILTER(CONVOLVE,   convolve,   vf);
>  REGISTER_FILTER(COPY,   copy,   vf);
>  REGISTER_FILTER(COREIMAGE,  coreimage,  vf);
> diff --git a/libavfilter/opencl/convolution.cl 
> b/libavfilter/opencl/convolution.cl
> new file mode 100644
> index 000..d074d98
> --- /dev/null
> +++ b/libavfilter/opencl/convolution.cl
> @@ -0,0 +1,42 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +__kernel void convolution_global(__write_only image2d_t dst,
> + __read_only  image2d_t src,
> + __constant int *coef_matrix_size,
> + __constant float *coef_matrix,
> + __constant float *div,
> + __constant float *bias)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE | 
> CLK_FILTER_NEAREST);
> +
> +int2 loc = (int2)(get_global_id(0), get_global_id(1));
> +
> +float4 convPix = (float4)(0.0f, 0.0f, 0.0f, 0.0f);
> +for (int i = 0; i < 4; i++) {
> +for (int conv_i = -(coef_matrix_size[i] / 2); conv_i <= 
> (coef_matrix_size[i] / 2); conv_i++) {
> +for (int conv_j = -(coef_matrix_size[i] / 2); conv_j <= 
> (coef_matrix_size[i] / 2); conv_j++) {
> +float4 px = read_imagef(src, sampler, loc + (int2)(conv_j, 
> conv_i));
> +convPix[i] += px[i] * 
> coef_matrix[(coef_matrix_size[i]*coef_matrix_size[i]*i)
> +

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Lou Logan
On Mon, Mar 12, 2018, at 1:46 PM, Valery Kot wrote:
> Got it. Do I have to post an updated patch as a reply to this thread?

Whatever you prefer, but adding a version to the subject can be helpful for us 
to keep track. You can do that with the "-v" option in "git format-patch". If 
you want to keep it within the thread use the "--in-reply-to" option (view the 
raw email message or message headers to get the in-reply-to value).

But you don't necessarily need to make a new patch to address the minor 
whitespace issue. You can wait for other comments and include it with any other 
requested changes.

Please try to avoid top-posting on the mailing list: it makes it harder to 
follow the replies. Lastly, if you can fix the reply quoting in your email 
message that would be helpful as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Valery Kot
Got it. Do I have to post an updated patch as a reply to this thread?

Valery
_
From: Lou Logan 
Sent: Monday, March 12, 2018 10:20 PM
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame 
in response to I frame pict_type
To: 


On Mon, 5 Mar 2018 15:01:16 +0100
Valery Kot  wrote:

> From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001
> From: vkot 
> Date: Mon, 5 Mar 2018 13:51:51 +0100
> Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to
> I frame pict_type
>
> ---
> libavcodec/libopenh264enc.c | 4 
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index fdadb101f5..12e9ad49ed 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -245,6 +245,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
> }
> sp.iPicWidth = avctx->width;
> sp.iPicHeight = avctx->height;
> +

The above line has trailing whitespace which should be avoided. You can
use tools/patcheck to check, and git should provide a warning when
applying the patch.
___
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/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Lou Logan
On Mon, 5 Mar 2018 15:01:16 +0100
Valery Kot  wrote:

> From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001
> From: vkot 
> Date: Mon, 5 Mar 2018 13:51:51 +0100
> Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to
>  I frame pict_type
> 
> ---
>  libavcodec/libopenh264enc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index fdadb101f5..12e9ad49ed 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -245,6 +245,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  }
>  sp.iPicWidth  = avctx->width;
>  sp.iPicHeight = avctx->height;
> +

The above line has trailing whitespace which should be avoided. You can
use tools/patcheck to check, and git should provide a warning when
applying the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Valery Kot

_
From: Derek Buitenhuis 
Sent: Monday, March 12, 2018 6:54 PM
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame 
in response to I frame pict_type
To: 


On 3/12/2018 6:58 AM, Valery Kot wrote:
>> Could somebody please take a look into my patch? Or is it somehow invisible
>> / badly formatted?
>>
>> It allows for inducing key frames at proper moments by e.g.
>> -force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
>> license, which is important for us.

>Hi,

>> + if (frame->pict_type==AV_PICTURE_TYPE_I) {
>> + (*s->encoder)->ForceIntraFrame(s->encoder, true);
>> + }

> Does openh264 differentiate between I and IDR frames in its API, like libx264
> and libx265 do?

> - Derek

Hey, somebody is seeing my mails. Cool!

As far as I see, ForceIntraFrame() is the only API to set type for a particular 
frame. And (confusingly) description says that it will be an IDR frame. Fair 
enough: if there is only one possible type they allow, then IDR is the most 
user-wanted type.

API EncodeFrame() returns  pBsInf->eFrameType, which can be IDR, I, or P frame 
flag. So apparently internally openH264 makes a distinction between I frames 
and IDR. But this is an output parameter, and it’s original value set by user 
is ignored.

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


Re: [FFmpeg-devel] [PATCH] ffprobe: fix infinite loop in subtitle decoding

2018-03-12 Thread Marton Balint



On Mon, 12 Mar 2018, wm4 wrote:


On Sun, 11 Mar 2018 18:12:05 +0100
Marton Balint  wrote:


Fixes a regression since 2a88ebd096f3c748a2d99ed1b60b22879b3c567c which caused
an infinite loop in the subtitle decoding.

Fixes ticket #6796.

Signed-off-by: Marton Balint 
---
 fftools/ffprobe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 967adbe30c..d8032bfddf 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2275,7 +2275,8 @@ static av_always_inline int process_frame(WriterContext 
*w,
 break;

 case AVMEDIA_TYPE_SUBTITLE:
-ret = avcodec_decode_subtitle2(dec_ctx, , _frame, pkt);
+if (*packet_new || !pkt->data)
+ret = avcodec_decode_subtitle2(dec_ctx, , _frame, pkt);
 *packet_new = 0;
 break;
 default:


LGTM, but not sure why the "!pkt->data" check would be needed. The
flush packet sent at the end will have *packet_new==1.


You're right, pushed without the !pkt->data check.

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


Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Derek Buitenhuis
On 3/12/2018 6:58 AM, Valery Kot wrote:
> Could somebody please take a look into my patch? Or is it somehow invisible
> / badly formatted?
> 
> It allows for inducing key frames at proper moments by e.g.
> -force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
> license, which is important for us.

Hi,

> +if (frame->pict_type==AV_PICTURE_TYPE_I) {
> +(*s->encoder)->ForceIntraFrame(s->encoder, true);
> +}

Does openh264 differentiate between I and IDR frames in its API, like libx264
and libx265 do?

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


Re: [FFmpeg-devel] [PATCH 2/7] hwcontext_vaapi: Add support for legacy DRM mapping

2018-03-12 Thread Rostislav Pehlivanov
On 12 March 2018 at 00:23, Mark Thompson  wrote:

> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
> > On 11 March 2018 at 22:41, Mark Thompson  wrote:
> >
> >> The old vaAcquireBufferHandle() API works in fewer cases and provides
> >> less information than the current vaExportSurfaceHandle(), but it exists
> >> on older versions and is already used by the OpenCL code.  This probably
> >> doesn't have much use directly, but it will be used to replace the
> ad-hoc
> >> OpenCL code in a following patch.
> >> ---
> >>  libavutil/hwcontext_vaapi.c | 191 ++
> >> +++---
> >>  1 file changed, 179 insertions(+), 12 deletions(-)
> >>
> >> ...
> >
> > Why? libva 1.1.0 is 6 years old now. It doesn't make sense to have 2
> pieces
> > of code to do the same thing.
>
> VAAPI 1.1.0 != libva 1.1.0.  VAAPI 1.1.0 is in libva 2.1.0, released last
> month.
>
> (This is not confusing at all.)
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

ABH seems pretty much worse than ESH, and considering you can't get the
format modifiers makes it useless for Vulkan. I don't see why we need to
support it in addition to ESH.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/7] hwcontext_opencl: Add support for mapping DRM objects to Beignet

2018-03-12 Thread Rostislav Pehlivanov
On 12 March 2018 at 12:30, Mark Thompson  wrote:

> On 12/03/18 00:22, Mark Thompson wrote:
> > On 11/03/18 23:59, Rostislav Pehlivanov wrote:
> >> On 11 March 2018 at 22:41, Mark Thompson  wrote:
> >>
> >>> Also use that to support mapping VAAPI to Beignet.
> >>> ---
> >>>  configure|  16 +--
> >>>  libavutil/hwcontext_opencl.c | 264 +-
> >>> -
> >>>  2 files changed, 138 insertions(+), 142 deletions(-)
> >>>
> >>> ...
> >>>
> >>
> >> Doesn't seem to work, at least on my machine:
> >> DRM frame layer 0 plane 0 is not representable in OpenCL: -22
> >
> > What driver and input/output formats are you using?  What are the
> versions of all the relevant components, so I can maybe try to reproduce
> it?  (beignet, i965, libva, mesa, libdrm, .. others?)
>
> Fixed in discussion on IRC - BGR0 from kmsgrab is not a valid format for
> OpenCL because of the padding, using BGRA instead works.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, Hazem Ashmawy  wrote:
> On 3/12/18, Paul B Mahol  wrote:
>> On 3/12/18, Hazem Ashmawy  wrote:
>>> Sorry about that! Here is github branch
>>>
>>> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
>>
>> Good, now can you look at how to use bilinear instead of nearest
>> interpolation
>> for cubemap to equirectangular conversion.
>>
>> Nearest is extremly ugly.
>>
> Sure, will look into that. Just to take that into my consideration,
> why didn't you use it at the first place? Were there any obstacles?

It was non-trivial to do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Hazem Ashmawy
On 3/12/18, Paul B Mahol  wrote:
> On 3/12/18, Hazem Ashmawy  wrote:
>> Sorry about that! Here is github branch
>>
>> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
>
> Good, now can you look at how to use bilinear instead of nearest
> interpolation
> for cubemap to equirectangular conversion.
>
> Nearest is extremly ugly.
>
Sure, will look into that. Just to take that into my consideration,
why didn't you use it at the first place? Were there any obstacles?

>>
>> On 3/12/18, Paul B Mahol  wrote:
>>> On 3/12/18, wm4  wrote:
 On Mon, 12 Mar 2018 11:26:26 +0100
 Paul B Mahol  wrote:

> On 3/12/18, Hazem Ashmawy  wrote:
> > Specifications can be found here:
> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
> >
> > Signed-off-by: Hazem Ashmawy 
> > ---
> >  libavfilter/vf_panorama.c | 32 
> >  1 file changed, 16 insertions(+), 16 deletions(-)
> >
>
> Please post whole patch, not just recent changes.
>
> Or just link to github branch.

 Also, in comment on this whole issue: this is why it should use the
 libavutil spherical metadata, because then we have something rigorously
 defined. Just saying.
>>>
>>> I already wrote that can not be used, similar to stereo3d frame side
>>> data for another filter.
>>> ___
>>> 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Mark Thompson
On 12/03/18 15:10, Hendrik Leppkes wrote:
> On Mon, Mar 12, 2018 at 2:38 PM, Mark Thompson  wrote:
>> On 12/03/18 09:54, Hendrik Leppkes wrote:
>>> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson  wrote:
 ---
  libavcodec/h264_metadata_bsf.c | 121 
 +
  1 file changed, 121 insertions(+)

 diff --git a/libavcodec/h264_metadata_bsf.c 
 b/libavcodec/h264_metadata_bsf.c
 index 36047887ca..d340c55990 100644
 --- a/libavcodec/h264_metadata_bsf.c
 +++ b/libavcodec/h264_metadata_bsf.c
 @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
  int display_orientation;
  double rotate;
  int flip;
 +
 +int a53_cc;
  } H264MetadataContext;


 @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
 AVPacket *out)
  int err, i, j, has_sps;
  uint8_t *displaymatrix_side_data = NULL;
  size_t displaymatrix_side_data_size = 0;
 +uint8_t *a53_side_data = NULL;
 +size_t a53_side_data_size = 0;

  err = ff_bsf_get_packet(bsf, );
  if (err < 0)
 @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
 AVPacket *out)
  }
  }

 +if (ctx->a53_cc == INSERT) {
 +uint8_t *data;
 +int size;
 +
 +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
 +if (data) {
 +H264RawSEIPayload payload = {
 +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
 +};
 +H264RawSEIUserDataRegistered *udr =
 +_data_registered;
 +
 +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n", 
 size);
 +
 +udr->data_length = size + 10;
 +udr->data_ref= av_buffer_alloc(udr->data_length);
 +if (!udr->data_ref) {
 +err = AVERROR(ENOMEM);
 +goto fail;
 +}
 +udr->data = udr->data_ref->data;
 +
 +udr->itu_t_t35_country_code = 181;
 +udr->data[0] = 0;
 +udr->data[1] = 49;
 +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
 +udr->data[6] = 3;
 +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
 +udr->data[8] = 0;
 +memcpy(udr->data + 9, data, size);
 +udr->data[size + 9] = 0xff;
 +
 +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
 +if (err < 0) {
 +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
 +   "message to access unit.\n");
 +av_buffer_unref(>data_ref);
 +goto fail;
 +}
 +}
 +
 +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
 +for (i = 0; i < au->nb_units; i++) {
 +H264RawSEI *sei;
 +if (au->units[i].type != H264_NAL_SEI)
 +continue;
 +sei = au->units[i].content;
 +
 +for (j = 0; j < sei->payload_count; j++) {
 +H264RawSEIUserDataRegistered *udr;
 +uint32_t tag;
 +uint8_t type_code, count;
 +
 +if (sei->payload[j].payload_type !=
 +H264_SEI_TYPE_USER_DATA_REGISTERED)
 +continue;
 +udr = >payload[j].payload.user_data_registered;
 +tag = AV_RB32(udr->data + 2);
 +type_code = udr->data[6];
 +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
 +continue;
 +
 +if (ctx->a53_cc == REMOVE) {
 +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
 + >units[i], 
 j);
 +if (err < 0) {
 +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
 +   "A53 CC SEI message.\n");
 +goto fail;
 +}
 +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
 +
 +--i;
 +break;
 +}
 +
 +// Extract.
 +count = udr->data[7] & 0x1f;
 +if (3 * count + 10 > udr->data_length) {
 +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed 
 caption "
 +   "data: count %d overflows length %zu.\n",
 +   count, udr->data_length);
 +continue;
 +

Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, Nicolas George  wrote:
> Paul B Mahol (2018-03-12):
>> > What are these avfilter limitations you speak of?
>
>> Sure.
>
> Is "sure" supposed to be an answer to that question?

Look at thread for stereo3d video filter patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Nicolas George
Paul B Mahol (2018-03-12):
> > What are these avfilter limitations you speak of?

> Sure.

Is "sure" supposed to be an answer to that question?

Regards,

-- 
  Nicolas George


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


Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: fix for zero EXTINFtag duration

2018-03-12 Thread 刘歧
> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 08fe0aa..7d9512b 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2501,7 +2501,7 @@ static int hls_init(AVFormatContext *s)
> /* Get one video stream to reference for split segments
>  * so use the first video stream index. */
> if ((vs->has_video == 1) && (vs->streams[j]->codecpar->codec_type 
> == AVMEDIA_TYPE_VIDEO)) {
> -vs->reference_stream_index = j;
> +vs->reference_stream_index = vs->streams[j]->index;
> }
> vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_SUBTITLE;
> }
> -- 
> 1.9.1
> 

LGTM

Thanks
Steven



pushed


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


Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Hendrik Leppkes
On Mon, Mar 12, 2018 at 2:38 PM, Mark Thompson  wrote:
> On 12/03/18 09:54, Hendrik Leppkes wrote:
>> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson  wrote:
>>> ---
>>>  libavcodec/h264_metadata_bsf.c | 121 
>>> +
>>>  1 file changed, 121 insertions(+)
>>>
>>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
>>> index 36047887ca..d340c55990 100644
>>> --- a/libavcodec/h264_metadata_bsf.c
>>> +++ b/libavcodec/h264_metadata_bsf.c
>>> @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
>>>  int display_orientation;
>>>  double rotate;
>>>  int flip;
>>> +
>>> +int a53_cc;
>>>  } H264MetadataContext;
>>>
>>>
>>> @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>>> AVPacket *out)
>>>  int err, i, j, has_sps;
>>>  uint8_t *displaymatrix_side_data = NULL;
>>>  size_t displaymatrix_side_data_size = 0;
>>> +uint8_t *a53_side_data = NULL;
>>> +size_t a53_side_data_size = 0;
>>>
>>>  err = ff_bsf_get_packet(bsf, );
>>>  if (err < 0)
>>> @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>>> AVPacket *out)
>>>  }
>>>  }
>>>
>>> +if (ctx->a53_cc == INSERT) {
>>> +uint8_t *data;
>>> +int size;
>>> +
>>> +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
>>> +if (data) {
>>> +H264RawSEIPayload payload = {
>>> +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
>>> +};
>>> +H264RawSEIUserDataRegistered *udr =
>>> +_data_registered;
>>> +
>>> +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n", 
>>> size);
>>> +
>>> +udr->data_length = size + 10;
>>> +udr->data_ref= av_buffer_alloc(udr->data_length);
>>> +if (!udr->data_ref) {
>>> +err = AVERROR(ENOMEM);
>>> +goto fail;
>>> +}
>>> +udr->data = udr->data_ref->data;
>>> +
>>> +udr->itu_t_t35_country_code = 181;
>>> +udr->data[0] = 0;
>>> +udr->data[1] = 49;
>>> +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
>>> +udr->data[6] = 3;
>>> +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
>>> +udr->data[8] = 0;
>>> +memcpy(udr->data + 9, data, size);
>>> +udr->data[size + 9] = 0xff;
>>> +
>>> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
>>> +if (err < 0) {
>>> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
>>> +   "message to access unit.\n");
>>> +av_buffer_unref(>data_ref);
>>> +goto fail;
>>> +}
>>> +}
>>> +
>>> +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
>>> +for (i = 0; i < au->nb_units; i++) {
>>> +H264RawSEI *sei;
>>> +if (au->units[i].type != H264_NAL_SEI)
>>> +continue;
>>> +sei = au->units[i].content;
>>> +
>>> +for (j = 0; j < sei->payload_count; j++) {
>>> +H264RawSEIUserDataRegistered *udr;
>>> +uint32_t tag;
>>> +uint8_t type_code, count;
>>> +
>>> +if (sei->payload[j].payload_type !=
>>> +H264_SEI_TYPE_USER_DATA_REGISTERED)
>>> +continue;
>>> +udr = >payload[j].payload.user_data_registered;
>>> +tag = AV_RB32(udr->data + 2);
>>> +type_code = udr->data[6];
>>> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
>>> +continue;
>>> +
>>> +if (ctx->a53_cc == REMOVE) {
>>> +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
>>> + >units[i], j);
>>> +if (err < 0) {
>>> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
>>> +   "A53 CC SEI message.\n");
>>> +goto fail;
>>> +}
>>> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
>>> +
>>> +--i;
>>> +break;
>>> +}
>>> +
>>> +// Extract.
>>> +count = udr->data[7] & 0x1f;
>>> +if (3 * count + 10 > udr->data_length) {
>>> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed caption 
>>> "
>>> +   "data: count %d overflows length %zu.\n",
>>> +   count, udr->data_length);
>>> +continue;
>>> +}
>>> +
>>> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu 
>>> bytes.\n", udr->data_length);
>>> +
>>> +err = av_reallocp(_side_data,
>>> +  

Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, James Almer  wrote:
> On 3/12/2018 7:48 AM, Paul B Mahol wrote:
>> On 3/12/18, wm4  wrote:
>>> On Mon, 12 Mar 2018 11:26:26 +0100
>>> Paul B Mahol  wrote:
>>>
 On 3/12/18, Hazem Ashmawy  wrote:
> Specifications can be found here:
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>
> Signed-off-by: Hazem Ashmawy 
> ---
>  libavfilter/vf_panorama.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
>

 Please post whole patch, not just recent changes.

 Or just link to github branch.
>>>
>>> Also, in comment on this whole issue: this is why it should use the
>>> libavutil spherical metadata, because then we have something rigorously
>>> defined. Just saying.
>>
>> I already wrote that can not be used, similar to stereo3d frame side
>> data for another filter.
>
> What are these avfilter limitations you speak of?
>
> The API for that matter follows the Google spec to the letter for
> Cubemap and Equirectangular projections. If they came up with some new
> projection definition not currently in the spec then they should be
> asked to make it official in said document, so we can implement it. Case
> in point the contents of this "ytmp" box in recent spherical mp4 streams
> they seem to be serving.
>
> In any case, please add a big TODO message to make sure this filter and
> the framework are eventually adapted to use the frame side data when
> available.

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


Re: [FFmpeg-devel] [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

2018-03-12 Thread James Almer
On 3/11/2018 10:23 PM, Jun Zhao wrote:
> V2: update opt fate test ref file

Unrelated to this patch, but can you please make sure to the patchsets
you send are contained in a single thread? Every email in a set after
the first should be a reply to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/5] avformat/hlsenc: fix write wrong init file URI string problem

2018-03-12 Thread James Almer
On 3/12/2018 3:34 AM, Steven Liu wrote:
> fmp4_init_filename should append after base_output_dirname
> 
> Signed-off-by: Steven Liu 

I'll ask you the same thing i asked Jun Zhao. Please configure git
send-email properly to send patchsets as a single thread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread James Almer
On 3/12/2018 7:48 AM, Paul B Mahol wrote:
> On 3/12/18, wm4  wrote:
>> On Mon, 12 Mar 2018 11:26:26 +0100
>> Paul B Mahol  wrote:
>>
>>> On 3/12/18, Hazem Ashmawy  wrote:
 Specifications can be found here:
 https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md

 Signed-off-by: Hazem Ashmawy 
 ---
  libavfilter/vf_panorama.c | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

>>>
>>> Please post whole patch, not just recent changes.
>>>
>>> Or just link to github branch.
>>
>> Also, in comment on this whole issue: this is why it should use the
>> libavutil spherical metadata, because then we have something rigorously
>> defined. Just saying.
> 
> I already wrote that can not be used, similar to stereo3d frame side
> data for another filter.

What are these avfilter limitations you speak of?

The API for that matter follows the Google spec to the letter for
Cubemap and Equirectangular projections. If they came up with some new
projection definition not currently in the spec then they should be
asked to make it official in said document, so we can implement it. Case
in point the contents of this "ytmp" box in recent spherical mp4 streams
they seem to be serving.

In any case, please add a big TODO message to make sure this filter and
the framework are eventually adapted to use the frame side data when
available.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Mark Thompson
On 12/03/18 09:54, Hendrik Leppkes wrote:
> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson  wrote:
>> ---
>>  libavcodec/h264_metadata_bsf.c | 121 
>> +
>>  1 file changed, 121 insertions(+)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
>> index 36047887ca..d340c55990 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
>>  int display_orientation;
>>  double rotate;
>>  int flip;
>> +
>> +int a53_cc;
>>  } H264MetadataContext;
>>
>>
>> @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>> AVPacket *out)
>>  int err, i, j, has_sps;
>>  uint8_t *displaymatrix_side_data = NULL;
>>  size_t displaymatrix_side_data_size = 0;
>> +uint8_t *a53_side_data = NULL;
>> +size_t a53_side_data_size = 0;
>>
>>  err = ff_bsf_get_packet(bsf, );
>>  if (err < 0)
>> @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>> AVPacket *out)
>>  }
>>  }
>>
>> +if (ctx->a53_cc == INSERT) {
>> +uint8_t *data;
>> +int size;
>> +
>> +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
>> +if (data) {
>> +H264RawSEIPayload payload = {
>> +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
>> +};
>> +H264RawSEIUserDataRegistered *udr =
>> +_data_registered;
>> +
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n", size);
>> +
>> +udr->data_length = size + 10;
>> +udr->data_ref= av_buffer_alloc(udr->data_length);
>> +if (!udr->data_ref) {
>> +err = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>> +udr->data = udr->data_ref->data;
>> +
>> +udr->itu_t_t35_country_code = 181;
>> +udr->data[0] = 0;
>> +udr->data[1] = 49;
>> +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
>> +udr->data[6] = 3;
>> +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
>> +udr->data[8] = 0;
>> +memcpy(udr->data + 9, data, size);
>> +udr->data[size + 9] = 0xff;
>> +
>> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
>> +if (err < 0) {
>> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
>> +   "message to access unit.\n");
>> +av_buffer_unref(>data_ref);
>> +goto fail;
>> +}
>> +}
>> +
>> +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
>> +for (i = 0; i < au->nb_units; i++) {
>> +H264RawSEI *sei;
>> +if (au->units[i].type != H264_NAL_SEI)
>> +continue;
>> +sei = au->units[i].content;
>> +
>> +for (j = 0; j < sei->payload_count; j++) {
>> +H264RawSEIUserDataRegistered *udr;
>> +uint32_t tag;
>> +uint8_t type_code, count;
>> +
>> +if (sei->payload[j].payload_type !=
>> +H264_SEI_TYPE_USER_DATA_REGISTERED)
>> +continue;
>> +udr = >payload[j].payload.user_data_registered;
>> +tag = AV_RB32(udr->data + 2);
>> +type_code = udr->data[6];
>> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
>> +continue;
>> +
>> +if (ctx->a53_cc == REMOVE) {
>> +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
>> + >units[i], j);
>> +if (err < 0) {
>> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
>> +   "A53 CC SEI message.\n");
>> +goto fail;
>> +}
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
>> +
>> +--i;
>> +break;
>> +}
>> +
>> +// Extract.
>> +count = udr->data[7] & 0x1f;
>> +if (3 * count + 10 > udr->data_length) {
>> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed caption "
>> +   "data: count %d overflows length %zu.\n",
>> +   count, udr->data_length);
>> +continue;
>> +}
>> +
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu bytes.\n", 
>> udr->data_length);
>> +
>> +err = av_reallocp(_side_data,
>> +  a53_side_data_size + 3 * count);
>> +if (err)
>> +goto fail;
>> +memcpy(a53_side_data + a53_side_data_size,
>> +   

Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Mark Thompson
On 12/03/18 07:19, Aman Gupta wrote:
> On Sun, Mar 11, 2018 at 11:30 AM, Mark Thompson  wrote:
> 
>> ---
>>  libavcodec/h264_metadata_bsf.c | 121 ++
>> +++
>>  1 file changed, 121 insertions(+)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_
>> bsf.c
>> index 36047887ca..d340c55990 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
>>  int display_orientation;
>>  double rotate;
>>  int flip;
>> +
>> +int a53_cc;
>>  } H264MetadataContext;
>>
>>
>> @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
>> AVPacket *out)
>>  int err, i, j, has_sps;
>>  uint8_t *displaymatrix_side_data = NULL;
>>  size_t displaymatrix_side_data_size = 0;
>> +uint8_t *a53_side_data = NULL;
>> +size_t a53_side_data_size = 0;
>>
>>  err = ff_bsf_get_packet(bsf, );
>>  if (err < 0)
>> @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf,
>> AVPacket *out)
>>  }
>>  }
>>
>> +if (ctx->a53_cc == INSERT) {
>> +uint8_t *data;
>> +int size;
>> +
>> +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
>> +if (data) {
>> +H264RawSEIPayload payload = {
>> +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
>> +};
>> +H264RawSEIUserDataRegistered *udr =
>> +_data_registered;
>> +
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n",
>> size);
>> +
>> +udr->data_length = size + 10;
>> +udr->data_ref= av_buffer_alloc(udr->data_length);
>> +if (!udr->data_ref) {
>> +err = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>> +udr->data = udr->data_ref->data;
>> +
>> +udr->itu_t_t35_country_code = 181;
>> +udr->data[0] = 0;
>> +udr->data[1] = 49;
>> +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
>> +udr->data[6] = 3;
>> +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
>> +udr->data[8] = 0;
>> +memcpy(udr->data + 9, data, size);
>> +udr->data[size + 9] = 0xff;
>> +
>> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
>> +if (err < 0) {
>> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
>> +   "message to access unit.\n");
>> +av_buffer_unref(>data_ref);
>> +goto fail;
>> +}
>> +}
>> +
>> +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
>> +for (i = 0; i < au->nb_units; i++) {
>> +H264RawSEI *sei;
>> +if (au->units[i].type != H264_NAL_SEI)
>> +continue;
>> +sei = au->units[i].content;
>> +
>> +for (j = 0; j < sei->payload_count; j++) {
>> +H264RawSEIUserDataRegistered *udr;
>> +uint32_t tag;
>> +uint8_t type_code, count;
>> +
>> +if (sei->payload[j].payload_type !=
>> +H264_SEI_TYPE_USER_DATA_REGISTERED)
>> +continue;
>> +udr = >payload[j].payload.user_data_registered;
>> +tag = AV_RB32(udr->data + 2);
>> +type_code = udr->data[6];
>> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
>> +continue;
>> +
>> +if (ctx->a53_cc == REMOVE) {
>> +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
>> + >units[i],
>> j);
>> +if (err < 0) {
>> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
>> +   "A53 CC SEI message.\n");
>> +goto fail;
>> +}
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
> 
> +
>> +--i;
>> +break;
>> +}
>> +
>> +// Extract.
>> +count = udr->data[7] & 0x1f;
>> +if (3 * count + 10 > udr->data_length) {
>> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed
>> caption "
>> +   "data: count %d overflows length %zu.\n",
>> +   count, udr->data_length);
>> +continue;
>> +}
>> +
>> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu
>> bytes.\n", udr->data_length);
>>
> 
> I assume these are WARNINGs from testing? Seems like TRACE or DEBUG would
> be fine.

Oops, yeah.  Removed this one and others.

(The filter probably does want some more logging to explain what it's doing (at 
VERBOSE or DEBUG?), but not like 

Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, Hazem Ashmawy  wrote:
> Sorry about that! Here is github branch
>
> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube

Good, now can you look at how to use bilinear instead of nearest interpolation
for cubemap to equirectangular conversion.

Nearest is extremly ugly.

>
> On 3/12/18, Paul B Mahol  wrote:
>> On 3/12/18, wm4  wrote:
>>> On Mon, 12 Mar 2018 11:26:26 +0100
>>> Paul B Mahol  wrote:
>>>
 On 3/12/18, Hazem Ashmawy  wrote:
 > Specifications can be found here:
 > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
 >
 > Signed-off-by: Hazem Ashmawy 
 > ---
 >  libavfilter/vf_panorama.c | 32 
 >  1 file changed, 16 insertions(+), 16 deletions(-)
 >

 Please post whole patch, not just recent changes.

 Or just link to github branch.
>>>
>>> Also, in comment on this whole issue: this is why it should use the
>>> libavutil spherical metadata, because then we have something rigorously
>>> defined. Just saying.
>>
>> I already wrote that can not be used, similar to stereo3d frame side
>> data for another filter.
>> ___
>> 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] fix mem-leak

2018-03-12 Thread Mark Thompson
On 12/03/18 06:30, Danil Iashchenko wrote:
> ---
>  libavfilter/vf_convolution_opencl.c | 39 
> ++---
>  1 file changed, 15 insertions(+), 24 deletions(-)
> 
> diff --git a/libavfilter/vf_convolution_opencl.c 
> b/libavfilter/vf_convolution_opencl.c
> index 60e2d1f..a14005b 100644
> --- a/libavfilter/vf_convolution_opencl.c
> +++ b/libavfilter/vf_convolution_opencl.c
> @@ -139,7 +139,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  matrix = av_malloc(matrix_bytes);
>  if (!matrix) {
>  err = AVERROR(ENOMEM);
> -goto fail;
> +goto fail_matrix;
>  }
>  cnt = 0;
>  for (i = 0; i < 4; i++) {
> @@ -157,7 +157,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "Failed to create matrix buffer: "
> "%d.\n", cle);
>  err = AVERROR(EIO);
> -goto fail;
> +goto fail_matrix;
>  }
>  ctx->matrix = buffer;
>  
> @@ -166,8 +166,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  matrix_rdiv = av_malloc(matrix_bytes);
>  if (!matrix_rdiv) {
>  err = AVERROR(ENOMEM);
> -av_freep(_rdiv);
> -goto fail;
> +goto fail_rdiv;
>  }
>  
>  for (j = 0; j < 4; j++) {
> @@ -182,8 +181,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "Failed to create rdiv buffer: "
> "%d.\n", cle);
>  err = AVERROR(EIO);
> -av_freep(_rdiv);
> -goto fail;
> +goto fail_rdiv;
>  }
>  ctx->rdiv_buffer = buffer_rdiv;
>  
> @@ -192,9 +190,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  matrix_bias = av_malloc(matrix_bytes);
>  if (!matrix_bias) {
>  err = AVERROR(ENOMEM);
> -av_freep(_rdiv);
> -av_freep(_bias);
> -goto fail;
> +goto fail_bias;
>  }
>  
>  for (j = 0; j < 4; j++) {
> @@ -209,9 +205,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "Failed to create bias buffer: "
> "%d.\n", cle);
>  err = AVERROR(EIO);
> -av_freep(_rdiv);
> -av_freep(_bias);
> -goto fail;
> +goto fail_bias;
>  }
>  ctx->bias_buffer = buffer_bias;
>  
> @@ -219,10 +213,7 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  matrix_size = av_malloc(matrix_bytes);
>  if (!matrix_size) {
>  err = AVERROR(ENOMEM);
> -av_freep(_rdiv);
> -av_freep(_bias);
> -av_freep(_size);
> -goto fail;
> +goto fail_size;
>  }
>  
>  for (j = 0; j < 4; j++) {
> @@ -237,18 +228,18 @@ static int 
> convolution_opencl_make_filter_params(AVFilterContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "Failed to create bias buffer: "
> "%d.\n", cle);
>  err = AVERROR(EIO);
> -av_freep(_rdiv);
> -av_freep(_bias);
> -av_freep(_size);
> -goto fail;
> +goto fail_size;
>  }
>  ctx->size_buffer = buffer_size;
>  
> -
> -
> -
>  err = 0;
> -fail:
> +fail_size:
> +av_freep(_size);
> +fail_bias:
> +av_freep(_bias);
> +fail_rdiv:
> +av_freep(_rdiv);
> +fail_matrix:
>  av_freep();
>  return err;
>  }
> 

av_freep() is a no-op if pointer is NULL (just like normal free()).  As 
such, if you initialise these matrix values to NULL at the start of the 
function then you can call av_freep() on them unconditionally and avoid having 
the separate fail_foo labels.

Also, I think it is preferred to send the whole patch again with changes like 
this squashed into it (maybe with a -v N to distinguish successive versions) 
rather than sending patches on top of the patch.

(I'll look at the whole thing properly later today.)

Thanks,

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


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Hazem Ashmawy
Sorry about that! Here is github branch

https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube

On 3/12/18, Paul B Mahol  wrote:
> On 3/12/18, wm4  wrote:
>> On Mon, 12 Mar 2018 11:26:26 +0100
>> Paul B Mahol  wrote:
>>
>>> On 3/12/18, Hazem Ashmawy  wrote:
>>> > Specifications can be found here:
>>> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>>> >
>>> > Signed-off-by: Hazem Ashmawy 
>>> > ---
>>> >  libavfilter/vf_panorama.c | 32 
>>> >  1 file changed, 16 insertions(+), 16 deletions(-)
>>> >
>>>
>>> Please post whole patch, not just recent changes.
>>>
>>> Or just link to github branch.
>>
>> Also, in comment on this whole issue: this is why it should use the
>> libavutil spherical metadata, because then we have something rigorously
>> defined. Just saying.
>
> I already wrote that can not be used, similar to stereo3d frame side
> data for another filter.
> ___
> 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 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Devin Heitmueller

> Does extracting really make sense? Doesn't the data end up out of
> order and basically unusable?

For what it’s worth, I’ve got a video filter which extracts the A53 side data 
and saves it into an MCC file (Telestream MacCaption format).  If people think 
that’s something that would be useful, I’ll see about getting it upstreamed.

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


Re: [FFmpeg-devel] [PATCH 2/2] lavf/vaapi_encode: fix to set the default max bitrate for AVC VBR

2018-03-12 Thread Mark Thompson
On 12/03/18 05:38, Pengfei Qu wrote:
> And for VBR mode, generally the max bit rate is bigger than the taraget
> bitrate. For CBR mode, the max bitrate is same as the target bitrate.
>  when there is no specfic setting for the max bit rate parameter,
> here the default value 95% is used to caculate the default max bitrate 
> accordingly.
> 
> Signed-off-by: Pengfei Qu 
> ---
>  libavcodec/vaapi_encode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 78347d4..47110cf 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1164,8 +1164,8 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  } else {
>  if (avctx->rc_max_rate < avctx->bit_rate) {
>  // Max rate is unset or invalid, just use the normal bitrate.
> -rc_bits_per_second   = avctx->bit_rate;
> -rc_target_percentage = 100;
> +rc_target_percentage = 95;
> +rc_bits_per_second   = (unsigned long)(avctx->bit_rate * 100.0 / 
> rc_target_percentage);
>  } else {
>  rc_bits_per_second   = avctx->rc_max_rate;
>  rc_target_percentage = (unsigned long)(avctx->bit_rate * 100) / 
> rc_bits_per_second;
> 

Can you give more detail about the motivation for this change?

In particular:
* You say you are fixing something - what is the issue?
* Where has the 95% number come from?
* Do you want this to apply to all codecs?  (The commit message says AVC.)

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


Re: [FFmpeg-devel] [PATCH 2/8] cbs_h265: Use helper macro for maximum values of fixed-width elements

2018-03-12 Thread Mark Thompson
On 12/03/18 00:41, Jun Zhao wrote:
> On 2018/3/12 2:30, Mark Thompson wrote:
>> Apply the same logic as the previous patch to H.265.  There are no cases
>> which currently overflow here, but this is still more consistent.
>> ---
>>  libavcodec/cbs_h265_syntax_template.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/libavcodec/cbs_h265_syntax_template.c 
>> b/libavcodec/cbs_h265_syntax_template.c
>> index dae7f2dd46..140c827c9d 100644
>> --- a/libavcodec/cbs_h265_syntax_template.c
>> +++ b/libavcodec/cbs_h265_syntax_template.c
>> @@ -665,7 +665,7 @@ static int FUNC(sps_scc_extension)(CodedBitstreamContext 
>> *ctx, RWContext *rw,
>>: 
>> current->bit_depth_chroma_minus8 + 8;
>>  for (i = 0; i <= 
>> current->sps_num_palette_predictor_initializer_minus1; i++)
>>  u(bit_depth, 
>> sps_palette_predictor_initializers[comp][i],
>> -  0, (1 << bit_depth) - 1);
>> +  0, MAX_UINT_BITS(bit_depth));
>>  }
>>  }
>>  }
>> @@ -827,7 +827,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
>> RWContext *rw,
>>  for (i = 0; i < current->num_long_term_ref_pics_sps; i++) {
>>  u(current->log2_max_pic_order_cnt_lsb_minus4 + 4,
>>lt_ref_pic_poc_lsb_sps[i],
>> -  0, (1 << (current->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 
>> 1);
>> +  0, MAX_UINT_BITS(current->log2_max_pic_order_cnt_lsb_minus4 + 
>> 4));
>>  flag(used_by_curr_pic_lt_sps_flag[i]);
>>  }
>>  }
>> @@ -845,7 +845,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
>> RWContext *rw,
>>  flag(sps_multilayer_extension_flag);
>>  flag(sps_3d_extension_flag);
>>  flag(sps_scc_extension_flag);
>> -u(4, sps_extension_4bits, 0, (1 << 4) - 1);
>> +u(4, sps_extension_4bits, 0, MAX_UINT_BITS(4));
>>  }
>>  
>>  if (current->sps_range_extension_flag)
>> @@ -925,7 +925,7 @@ static int FUNC(pps_scc_extension)(CodedBitstreamContext 
>> *ctx, RWContext *rw,
>>: 
>> current->chroma_bit_depth_entry_minus8 + 8;
>>  for (i = 0; i < 
>> current->pps_num_palette_predictor_initializer; i++)
>>  u(bit_depth, 
>> pps_palette_predictor_initializers[comp][i],
>> -  0, (1 << bit_depth) - 1);
>> +  0, MAX_UINT_BITS(bit_depth));
>>  }
>>  }
>>  }
>> @@ -1038,7 +1038,7 @@ static int FUNC(pps)(CodedBitstreamContext *ctx, 
>> RWContext *rw,
>>  flag(pps_multilayer_extension_flag);
>>  flag(pps_3d_extension_flag);
>>  flag(pps_scc_extension_flag);
>> -u(4, pps_extension_4bits, 0, (1 << 4) - 1);
>> +u(4, pps_extension_4bits, 0, MAX_UINT_BITS(4));
>>  }
>>  if (current->pps_range_extension_flag)
>>  CHECK(FUNC(pps_range_extension)(ctx, rw, current));
>> @@ -1274,7 +1274,7 @@ static int 
>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>  const H265RawSTRefPicSet *rps;
>>  
>>  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4, 
>> slice_pic_order_cnt_lsb,
>> -  0, (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1);
>> +  0, MAX_UINT_BITS(sps->log2_max_pic_order_cnt_lsb_minus4 + 4));
>>  
>>  flag(short_term_ref_pic_set_sps_flag);
>>  if (!current->short_term_ref_pic_set_sps_flag) {
>> @@ -1321,7 +1321,7 @@ static int 
>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>  ++num_pic_total_curr;
>>  } else {
>>  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4, 
>> poc_lsb_lt[i],
>> -  0, (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 
>> + 4)) - 1);
>> +  0, 
>> MAX_UINT_BITS(sps->log2_max_pic_order_cnt_lsb_minus4 + 4));
>>  flag(used_by_curr_pic_lt_flag[i]);
>>  if (current->used_by_curr_pic_lt_flag[i])
>>  ++num_pic_total_curr;
>> @@ -1487,7 +1487,7 @@ static int 
>> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>>  ue(offset_len_minus1, 0, 31);
>>  for (i = 0; i < current->num_entry_point_offsets; i++)
>>  u(current->offset_len_minus1 + 1, 
>> entry_point_offset_minus1[i],
>> -  0, (1 << (current->offset_len_minus1 + 1)) - 1);
>> +  0, MAX_UINT_BITS(current->offset_len_minus1 + 1));
>>  }
>>  }
>>  
> Other thing about cbs_265, now cbs_264 can support SEI, but cbs_265 not,
> is it will support SEI in cbs_265?

It's on my list of stuff which should be done at some point, but not a priority 
due to lack of any immediate use-case.  Do you have some reason for wanting 

Re: [FFmpeg-devel] [PATCH 7/7] doc/indevs: Add example using cropping to capture part of a plane

2018-03-12 Thread Mark Thompson
On 12/03/18 00:03, Rostislav Pehlivanov wrote:
> On 11 March 2018 at 22:41, Mark Thompson  wrote:
> 
>> ---
>>  doc/indevs.texi | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/doc/indevs.texi b/doc/indevs.texi
>> index 6951940a93..02d1cb3d86 100644
>> --- a/doc/indevs.texi
>> +++ b/doc/indevs.texi
>> @@ -462,6 +462,14 @@ Capture from CRTC ID 42 at 60fps, map the result to
>> VAAPI, convert to NV12 and e
>>  ffmpeg -crtc_id 42 -framerate 60 -f kmsgrab -i - -vf
>> 'hwmap=derive_device=vaapi,scale_vaapi=w=1920:h=1080:format=nv12' -c:v
>> h264_vaapi output.mp4
>>  @end example
>>
>> +@item
>> +To capture only part of a plane the output can be cropped - this can be
>> used to capture
>> +a single window, as long as it has a known absolute position.  For
>> example, to capture
>> +and encode the middle quarter of a 1920x1080 plane:
>> +@example
>> +ffmpeg -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi,
>> crop=960:540:480:270,scale_vaapi=format=nv12' -c:v h264_vaapi output.mp4
>> +@end example
>> +
>>  @end itemize
>>
>>  @section libndi_newtek
>> --
>> 2.16.1
>>
> 
> On a related note, deriving a vaapi device from kms has never worked for me:
> libva: va_getDriverName() failed with operation failed,driver_name=i965
libva doesn't like being created with a non-render fd which isn't the DRM 
master, which is what you're doing in this case when you are using 
CAP_SYS_ADMIN to subvert the security model trying to stop processes from 
capturing screens they don't own.  It does work if you are the DRM master (e.g. 
you are capturing from a VT framebuffer without any display server running).  
Relevant code: 
.

Not sure what, if anything, should be done about that.  As you've observed it's 
easy to work around by making a separate render device and mapping to that 
instead.

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


Re: [FFmpeg-devel] [PATCH 4/7] hwcontext_opencl: Add support for mapping DRM objects to Beignet

2018-03-12 Thread Mark Thompson
On 12/03/18 00:22, Mark Thompson wrote:
> On 11/03/18 23:59, Rostislav Pehlivanov wrote:
>> On 11 March 2018 at 22:41, Mark Thompson  wrote:
>>
>>> Also use that to support mapping VAAPI to Beignet.
>>> ---
>>>  configure|  16 +--
>>>  libavutil/hwcontext_opencl.c | 264 +-
>>> -
>>>  2 files changed, 138 insertions(+), 142 deletions(-)
>>>
>>> ...
>>>
>>
>> Doesn't seem to work, at least on my machine:
>> DRM frame layer 0 plane 0 is not representable in OpenCL: -22
> 
> What driver and input/output formats are you using?  What are the versions of 
> all the relevant components, so I can maybe try to reproduce it?  (beignet, 
> i965, libva, mesa, libdrm, .. others?)

Fixed in discussion on IRC - BGR0 from kmsgrab is not a valid format for OpenCL 
because of the padding, using BGRA instead works.

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


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, wm4  wrote:
> On Mon, 12 Mar 2018 11:26:26 +0100
> Paul B Mahol  wrote:
>
>> On 3/12/18, Hazem Ashmawy  wrote:
>> > Specifications can be found here:
>> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>> >
>> > Signed-off-by: Hazem Ashmawy 
>> > ---
>> >  libavfilter/vf_panorama.c | 32 
>> >  1 file changed, 16 insertions(+), 16 deletions(-)
>> >
>>
>> Please post whole patch, not just recent changes.
>>
>> Or just link to github branch.
>
> Also, in comment on this whole issue: this is why it should use the
> libavutil spherical metadata, because then we have something rigorously
> defined. Just saying.

I already wrote that can not be used, similar to stereo3d frame side
data for another filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: fix for zero EXTINF tag duration

2018-03-12 Thread Steven Liu


> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 08fe0aa..7d9512b 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2501,7 +2501,7 @@ static int hls_init(AVFormatContext *s)
> /* Get one video stream to reference for split segments
>  * so use the first video stream index. */
> if ((vs->has_video == 1) && (vs->streams[j]->codecpar->codec_type 
> == AVMEDIA_TYPE_VIDEO)) {
> -vs->reference_stream_index = j;
> +vs->reference_stream_index = vs->streams[j]->index;
> }
> vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_SUBTITLE;
> }
> -- 
> 1.9.1
> 

LGTM

Thanks
Steven





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


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread wm4
On Mon, 12 Mar 2018 11:26:26 +0100
Paul B Mahol  wrote:

> On 3/12/18, Hazem Ashmawy  wrote:
> > Specifications can be found here:
> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
> >
> > Signed-off-by: Hazem Ashmawy 
> > ---
> >  libavfilter/vf_panorama.c | 32 
> >  1 file changed, 16 insertions(+), 16 deletions(-)
> >  
> 
> Please post whole patch, not just recent changes.
> 
> Or just link to github branch.

Also, in comment on this whole issue: this is why it should use the
libavutil spherical metadata, because then we have something rigorously
defined. Just saying.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Paul B Mahol
On 3/12/18, Hazem Ashmawy  wrote:
> Specifications can be found here:
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>
> Signed-off-by: Hazem Ashmawy 
> ---
>  libavfilter/vf_panorama.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
>

Please post whole patch, not just recent changes.

Or just link to github branch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2] Change cube faces order to match Youtube's

2018-03-12 Thread Hazem Ashmawy
Specifications can be found here:
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md

Signed-off-by: Hazem Ashmawy 
---
 libavfilter/vf_panorama.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
index de08ef4..2fb30a1 100644
--- a/libavfilter/vf_panorama.c
+++ b/libavfilter/vf_panorama.c
@@ -34,12 +34,12 @@ enum Projections {
 };
 
 enum Faces {
-LEFT,
-FRONT,
 RIGHT,
+LEFT,
 TOP,
-BACK,
 DOWN,
+FRONT,
+BACK,
 };
 
 struct XYRemap {
@@ -152,27 +152,27 @@ static void to_cube3x2_xyz(int i, int j, int face, double 
ew, double eh,
 
 if (face == BACK) {
 *x = -1 ;
-*y =  3. - a;
+*y =  5. - a;
 *z =  3. - b;
 } else if (face == LEFT) {
-*x =  a  - 1;
+*x =  a  - 3;
 *y = -1 ;
 *z =  1. - b;
 } else if (face == FRONT) {
 *x =  1 ;
 *y =  a  - 3;
-*z =  1. - b;
+*z =  3. - b;
 } else if (face == RIGHT) {
-*x =  5. - a;
+*x =  1. - a;
 *y =  1 ;
 *z =  1. - b;
 } else if (face == TOP) {
-*x =  b  - 3;
-*y =  a  - 1;
+*x =  b  - 1;
+*y =  a  - 5;
 *z =  1 ;
 } else if (face == DOWN) {
 *x = -b  + 3;
-*y =  a  - 5;
+*y =  a  - 1;
 *z = -1 ;
 }
 }
@@ -185,27 +185,27 @@ static void to_cube6x1_xyz(int i, int j, int face, double 
ew, double eh,
 
 if (face == BACK) {
 *x = -1 ;
-*y =  9. - a;
+*y = 11. - a;
 *z =  1. - b;
 } else if (face == LEFT) {
-*x =  a  - 1;
+*x =  a  - 3;
 *y = -1 ;
 *z =  1. - b;
 } else if (face == FRONT) {
 *x =  1 ;
-*y =  a  - 3;
+*y =  a  - 9;
 *z =  1. - b;
 } else if (face == RIGHT) {
-*x =  5. - a;
+*x =  1. - a;
 *y =  1 ;
 *z =  1. - b;
 } else if (face == TOP) {
 *x =  b  - 1;
-*y =  a  - 7;
+*y =  a  - 5;
 *z =  1 ;
 } else if (face == DOWN) {
 *x = -b  + 1;
-*y =  a  - 11;
+*y =  a  - 7;
 *z = -1 ;
 }
 }
-- 
2.7.4

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


Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Hendrik Leppkes
On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson  wrote:
> ---
>  libavcodec/h264_metadata_bsf.c | 121 
> +
>  1 file changed, 121 insertions(+)
>
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 36047887ca..d340c55990 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
>  int display_orientation;
>  double rotate;
>  int flip;
> +
> +int a53_cc;
>  } H264MetadataContext;
>
>
> @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
> AVPacket *out)
>  int err, i, j, has_sps;
>  uint8_t *displaymatrix_side_data = NULL;
>  size_t displaymatrix_side_data_size = 0;
> +uint8_t *a53_side_data = NULL;
> +size_t a53_side_data_size = 0;
>
>  err = ff_bsf_get_packet(bsf, );
>  if (err < 0)
> @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
> AVPacket *out)
>  }
>  }
>
> +if (ctx->a53_cc == INSERT) {
> +uint8_t *data;
> +int size;
> +
> +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
> +if (data) {
> +H264RawSEIPayload payload = {
> +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
> +};
> +H264RawSEIUserDataRegistered *udr =
> +_data_registered;
> +
> +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n", size);
> +
> +udr->data_length = size + 10;
> +udr->data_ref= av_buffer_alloc(udr->data_length);
> +if (!udr->data_ref) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +udr->data = udr->data_ref->data;
> +
> +udr->itu_t_t35_country_code = 181;
> +udr->data[0] = 0;
> +udr->data[1] = 49;
> +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
> +udr->data[6] = 3;
> +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
> +udr->data[8] = 0;
> +memcpy(udr->data + 9, data, size);
> +udr->data[size + 9] = 0xff;
> +
> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
> +   "message to access unit.\n");
> +av_buffer_unref(>data_ref);
> +goto fail;
> +}
> +}
> +
> +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
> +for (i = 0; i < au->nb_units; i++) {
> +H264RawSEI *sei;
> +if (au->units[i].type != H264_NAL_SEI)
> +continue;
> +sei = au->units[i].content;
> +
> +for (j = 0; j < sei->payload_count; j++) {
> +H264RawSEIUserDataRegistered *udr;
> +uint32_t tag;
> +uint8_t type_code, count;
> +
> +if (sei->payload[j].payload_type !=
> +H264_SEI_TYPE_USER_DATA_REGISTERED)
> +continue;
> +udr = >payload[j].payload.user_data_registered;
> +tag = AV_RB32(udr->data + 2);
> +type_code = udr->data[6];
> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
> +continue;
> +
> +if (ctx->a53_cc == REMOVE) {
> +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
> + >units[i], j);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> +   "A53 CC SEI message.\n");
> +goto fail;
> +}
> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
> +
> +--i;
> +break;
> +}
> +
> +// Extract.
> +count = udr->data[7] & 0x1f;
> +if (3 * count + 10 > udr->data_length) {
> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed caption "
> +   "data: count %d overflows length %zu.\n",
> +   count, udr->data_length);
> +continue;
> +}
> +
> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu bytes.\n", 
> udr->data_length);
> +
> +err = av_reallocp(_side_data,
> +  a53_side_data_size + 3 * count);
> +if (err)
> +goto fail;
> +memcpy(a53_side_data + a53_side_data_size,
> +   udr->data + 9, 3 * count);
> +a53_side_data_size += 3 * count;
> +}
> +}
> +}
> +
>  err = 

[FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: fix for zero EXTINF tag duration

2018-03-12 Thread vdixit
From: Vishwanath Dixit 

This is the fix for bug https://trac.ffmpeg.org/ticket/7073
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 08fe0aa..7d9512b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2501,7 +2501,7 @@ static int hls_init(AVFormatContext *s)
 /* Get one video stream to reference for split segments
  * so use the first video stream index. */
 if ((vs->has_video == 1) && (vs->streams[j]->codecpar->codec_type 
== AVMEDIA_TYPE_VIDEO)) {
-vs->reference_stream_index = j;
+vs->reference_stream_index = vs->streams[j]->index;
 }
 vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
AVMEDIA_TYPE_SUBTITLE;
 }
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec_common: make INFO_TRY_AGAIN trace messages more consistent

2018-03-12 Thread Matthieu Bouron
On Mon, Mar 12, 2018 at 01:24:02AM -0700, Aman Gupta wrote:
> On Mon, Mar 12, 2018 at 1:16 AM, Matthieu Bouron 
> wrote:
> 
> > ---
> >  libavcodec/mediacodecdec_common.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/mediacodecdec_common.c b/libavcodec/mediacodecdec_
> > common.c
> > index 5064809cf6..058825a1a2 100644
> > --- a/libavcodec/mediacodecdec_common.c
> > +++ b/libavcodec/mediacodecdec_common.c
> > @@ -568,7 +568,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx,
> > MediaCodecDecContext *s,
> >
> >  index = ff_AMediaCodec_dequeueInputBuffer(codec,
> > input_dequeue_timeout_us);
> >  if (ff_AMediaCodec_infoTryAgainLater(codec, index)) {
> > -av_log(avctx, AV_LOG_TRACE, "Failed to dequeue input buffer,
> > try again later..\n");
> > +av_log(avctx, AV_LOG_TRACE, "No input buffer available, try
> > again later\n");
> >  break;
> >  }
> >
> > @@ -732,7 +732,7 @@ int ff_mediacodec_dec_receive(AVCodecContext *avctx,
> > MediaCodecDecContext *s,
> >  "while draining remaining frames,
> > output will probably lack frames\n",
> >  output_dequeue_timeout_us / 1000);
> >  } else {
> > -av_log(avctx, AV_LOG_DEBUG, "No output buffer available, try
> > again later\n");
> > +av_log(avctx, AV_LOG_TRACE, "No output buffer available, try
> > again later\n");
> >  }
> >  } else {
> >  av_log(avctx, AV_LOG_ERROR, "Failed to dequeue output buffer
> > (status=%zd)\n", index);
> >
> 
> LGTM

Applied. Thanks.

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


Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

2018-03-12 Thread Paul B Mahol
On 3/12/18, Hazem Ashmawy  wrote:
> On 3/12/18, Paul B Mahol  wrote:
>> On 3/12/18, Hazem Ashmawy  wrote:
>>> So, I spend few hours trying to incorporate the partial change.
>>>
>>> I'm not sure that the video sent by  earlier follows the
>>> faces order here
>>> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3
>>>
>>> Because when I made this change, I got a reasonable equirectangular
>>> ouput:
>>> https://imgur.com/a/BEN00
>>>
>>> comparing to the changes sent earlier.
>>> https://imgur.com/a/vaIvW
>>>
>>> diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
>>> index de08ef4..5383d57 100644
>>> --- a/libavfilter/vf_panorama.c
>>> +++ b/libavfilter/vf_panorama.c
>>> @@ -34,12 +34,12 @@ enum Projections {
>>>  };
>>>
>>>  enum Faces {
>>> +DOWN,
>>>  LEFT,
>>> +TOP,
>>>  FRONT,
>>>  RIGHT,
>>> -TOP,
>>>  BACK,
>>> -DOWN,
>>>  };
>>>
>>>  struct XYRemap {
>>> @@ -403,7 +403,7 @@ static int config_output(AVFilterLink *outlink)
>>>
>>>  switch (face) {
>>>  case LEFT:
>>> -locate(z, x, y, M_PI,   rw, rh, , );
>>> +locate(z, x, y, -M_PI_2,   rw, rh, , );
>>>  break;
>>>  case FRONT:
>>>  locate(x, z, y, 0., rw, rh, , );
>>> @@ -418,7 +418,7 @@ static int config_output(AVFilterLink *outlink)
>>>  locate(x, y, z,-M_PI_2, rw, rh, , );
>>>  break;
>>>  case DOWN:
>>> -locate(y, x, z,-M_PI_2, rw, rh, , );
>>> +locate(y, x, z, M_PI_2, rw, rh, , );
>>>  break;
>>>  }
>>>
>>> What I'm saying is: when I changed face order to this (which video
>>> sample seems to follow), I got a reasonable output.
>>> down | left | top
>>> front | right | back
>>>
>>> Comparing to Google's:
>>> right | left | top
>>> down | front | back
>>
>> The video linked here does not have name of faces, so you can not know
>> what is front and what is back.
>>
>> Just add support for typical cubemap layout currently used.
> You mean In the video linked?
> Or the Google's specification and ignore the linked video?
> Or current layout order originally used in the patch?

Just use what currently cubemap layout is used by youtube.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

2018-03-12 Thread Hazem Ashmawy
On 3/12/18, Paul B Mahol  wrote:
> On 3/12/18, Hazem Ashmawy  wrote:
>> So, I spend few hours trying to incorporate the partial change.
>>
>> I'm not sure that the video sent by  earlier follows the
>> faces order here
>> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3
>>
>> Because when I made this change, I got a reasonable equirectangular ouput:
>> https://imgur.com/a/BEN00
>>
>> comparing to the changes sent earlier.
>> https://imgur.com/a/vaIvW
>>
>> diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
>> index de08ef4..5383d57 100644
>> --- a/libavfilter/vf_panorama.c
>> +++ b/libavfilter/vf_panorama.c
>> @@ -34,12 +34,12 @@ enum Projections {
>>  };
>>
>>  enum Faces {
>> +DOWN,
>>  LEFT,
>> +TOP,
>>  FRONT,
>>  RIGHT,
>> -TOP,
>>  BACK,
>> -DOWN,
>>  };
>>
>>  struct XYRemap {
>> @@ -403,7 +403,7 @@ static int config_output(AVFilterLink *outlink)
>>
>>  switch (face) {
>>  case LEFT:
>> -locate(z, x, y, M_PI,   rw, rh, , );
>> +locate(z, x, y, -M_PI_2,   rw, rh, , );
>>  break;
>>  case FRONT:
>>  locate(x, z, y, 0., rw, rh, , );
>> @@ -418,7 +418,7 @@ static int config_output(AVFilterLink *outlink)
>>  locate(x, y, z,-M_PI_2, rw, rh, , );
>>  break;
>>  case DOWN:
>> -locate(y, x, z,-M_PI_2, rw, rh, , );
>> +locate(y, x, z, M_PI_2, rw, rh, , );
>>  break;
>>  }
>>
>> What I'm saying is: when I changed face order to this (which video
>> sample seems to follow), I got a reasonable output.
>> down | left | top
>> front | right | back
>>
>> Comparing to Google's:
>> right | left | top
>> down | front | back
>
> The video linked here does not have name of faces, so you can not know
> what is front and what is back.
>
> Just add support for typical cubemap layout currently used.
You mean In the video linked?
Or the Google's specification and ignore the linked video?
Or current layout order originally used in the patch?
> ___
> 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/mediacodecdec: add debug logging around hw buffer lifecycle

2018-03-12 Thread Aman Gupta
On Sat, Mar 10, 2018 at 11:48 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> Some Android devices are very finicky about how quicky output buffers
> are returned back to the decoder, especially when they are associated
> with a Surface.
>
> This commit adds a new counter that keeps track of exactly how many hw
> output buffers are being retained by the user, along with DEBUG level
> logging that makes it easy to track the lifecycle of these buffers.
> ---
>  libavcodec/mediacodec.c   |  7 ---
>  libavcodec/mediacodecdec_common.c | 11 +++
>  libavcodec/mediacodecdec_common.h |  1 +
>  3 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
> index 3ddd303c97..25491a01ec 100644
> --- a/libavcodec/mediacodec.c
> +++ b/libavcodec/mediacodec.c
> @@ -92,9 +92,10 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer
> *buffer, int render)
>  int released = atomic_fetch_add(>released, 1);
>
>  if (!released && (ctx->delay_flush || buffer->serial ==
> atomic_load(>serial))) {
> -av_log(ctx->avctx, AV_LOG_TRACE,
> -   "Releasing output buffer %zd ts=%"PRId64" render=%d\n",
> -   buffer->index, buffer->pts, render);
> +atomic_fetch_sub(>hw_buffers, 1);
> +av_log(ctx->avctx, AV_LOG_DEBUG,
> +   "Releasing output buffer %zd (%p) ts=%"PRId64" with
> render=%d [%d pending]\n",
> +   buffer->index, buffer, buffer->pts, render,
> atomic_load(>hw_buffers));
>  return ff_AMediaCodec_releaseOutputBuffer(ctx->codec,
> buffer->index, render);
>  }
>
> diff --git a/libavcodec/mediacodecdec_common.c b/libavcodec/mediacodecdec_
> common.c
> index 5064809cf6..f699609186 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -179,6 +179,10 @@ static void mediacodec_buffer_release(void *opaque,
> uint8_t *data)
>  int released = atomic_load(>released);
>
>  if (!released && (ctx->delay_flush || buffer->serial ==
> atomic_load(>serial))) {
> +atomic_fetch_sub(>hw_buffers, 1);
> +av_log(ctx->avctx, AV_LOG_DEBUG,
> +   "Releasing output buffer %zd (%p) ts=%"PRId64" on free()
> [%d pending]\n",
> +   buffer->index, buffer, buffer->pts,
> atomic_load(>hw_buffers));
>  ff_AMediaCodec_releaseOutputBuffer(ctx->codec, buffer->index, 0);
>  }
>
> @@ -246,6 +250,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
>  frame->data[3] = (uint8_t *)buffer;
>
> +atomic_fetch_add(>hw_buffers, 1);
> +av_log(avctx, AV_LOG_DEBUG,
> +"Wrapping output buffer %zd (%p) ts=%"PRId64" [%d pending]\n",
> +buffer->index, buffer, buffer->pts,
> atomic_load(>hw_buffers));
> +
>  return 0;
>  fail:
>  av_freep(buffer);
> @@ -429,6 +438,7 @@ static int mediacodec_dec_flush_codec(AVCodecContext
> *avctx, MediaCodecDecContex
>  s->flushing = 0;
>  s->eos = 0;
>  atomic_fetch_add(>serial, 1);
> +atomic_init(>hw_buffers, 0);
>
>  status = ff_AMediaCodec_flush(codec);
>  if (status < 0) {
> @@ -454,6 +464,7 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx,
> MediaCodecDecContext *s,
>
>  s->avctx = avctx;
>  atomic_init(>refcount, 1);
> +atomic_init(>hw_buffers, 0);
>  atomic_init(>serial, 1);
>
>  pix_fmt = ff_get_format(avctx, pix_fmts);
> diff --git a/libavcodec/mediacodecdec_common.h b/libavcodec/mediacodecdec_
> common.h
> index 3fd2412a65..8bfc67942d 100644
> --- a/libavcodec/mediacodecdec_common.h
> +++ b/libavcodec/mediacodecdec_common.h
> @@ -38,6 +38,7 @@ typedef struct MediaCodecDecContext {
>
>  AVCodecContext *avctx;
>  atomic_int refcount;
> +atomic_int hw_buffers;
>
>  char *codec_name;
>

Applied to master with s/hw_buffers/hw_buffer_count/g


>
> --
> 2.14.3 (Apple Git-98)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec_common: make INFO_TRY_AGAIN trace messages more consistent

2018-03-12 Thread Aman Gupta
On Mon, Mar 12, 2018 at 1:16 AM, Matthieu Bouron 
wrote:

> ---
>  libavcodec/mediacodecdec_common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec_common.c b/libavcodec/mediacodecdec_
> common.c
> index 5064809cf6..058825a1a2 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -568,7 +568,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx,
> MediaCodecDecContext *s,
>
>  index = ff_AMediaCodec_dequeueInputBuffer(codec,
> input_dequeue_timeout_us);
>  if (ff_AMediaCodec_infoTryAgainLater(codec, index)) {
> -av_log(avctx, AV_LOG_TRACE, "Failed to dequeue input buffer,
> try again later..\n");
> +av_log(avctx, AV_LOG_TRACE, "No input buffer available, try
> again later\n");
>  break;
>  }
>
> @@ -732,7 +732,7 @@ int ff_mediacodec_dec_receive(AVCodecContext *avctx,
> MediaCodecDecContext *s,
>  "while draining remaining frames,
> output will probably lack frames\n",
>  output_dequeue_timeout_us / 1000);
>  } else {
> -av_log(avctx, AV_LOG_DEBUG, "No output buffer available, try
> again later\n");
> +av_log(avctx, AV_LOG_TRACE, "No output buffer available, try
> again later\n");
>  }
>  } else {
>  av_log(avctx, AV_LOG_ERROR, "Failed to dequeue output buffer
> (status=%zd)\n", index);
>

LGTM



> --
> 2.16.2
>
> ___
> 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] avcodec/mediacodecdec_common: make INFO_TRY_AGAIN trace messages more consistent

2018-03-12 Thread Matthieu Bouron
---
 libavcodec/mediacodecdec_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 5064809cf6..058825a1a2 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -568,7 +568,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 
 index = ff_AMediaCodec_dequeueInputBuffer(codec, 
input_dequeue_timeout_us);
 if (ff_AMediaCodec_infoTryAgainLater(codec, index)) {
-av_log(avctx, AV_LOG_TRACE, "Failed to dequeue input buffer, try 
again later..\n");
+av_log(avctx, AV_LOG_TRACE, "No input buffer available, try again 
later\n");
 break;
 }
 
@@ -732,7 +732,7 @@ int ff_mediacodec_dec_receive(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 "while draining remaining frames, 
output will probably lack frames\n",
 output_dequeue_timeout_us / 1000);
 } else {
-av_log(avctx, AV_LOG_DEBUG, "No output buffer available, try again 
later\n");
+av_log(avctx, AV_LOG_TRACE, "No output buffer available, try again 
later\n");
 }
 } else {
 av_log(avctx, AV_LOG_ERROR, "Failed to dequeue output buffer 
(status=%zd)\n", index);
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

2018-03-12 Thread Paul B Mahol
On 3/12/18, Hazem Ashmawy  wrote:
> So, I spend few hours trying to incorporate the partial change.
>
> I'm not sure that the video sent by  earlier follows the
> faces order here
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3
>
> Because when I made this change, I got a reasonable equirectangular ouput:
> https://imgur.com/a/BEN00
>
> comparing to the changes sent earlier.
> https://imgur.com/a/vaIvW
>
> diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
> index de08ef4..5383d57 100644
> --- a/libavfilter/vf_panorama.c
> +++ b/libavfilter/vf_panorama.c
> @@ -34,12 +34,12 @@ enum Projections {
>  };
>
>  enum Faces {
> +DOWN,
>  LEFT,
> +TOP,
>  FRONT,
>  RIGHT,
> -TOP,
>  BACK,
> -DOWN,
>  };
>
>  struct XYRemap {
> @@ -403,7 +403,7 @@ static int config_output(AVFilterLink *outlink)
>
>  switch (face) {
>  case LEFT:
> -locate(z, x, y, M_PI,   rw, rh, , );
> +locate(z, x, y, -M_PI_2,   rw, rh, , );
>  break;
>  case FRONT:
>  locate(x, z, y, 0., rw, rh, , );
> @@ -418,7 +418,7 @@ static int config_output(AVFilterLink *outlink)
>  locate(x, y, z,-M_PI_2, rw, rh, , );
>  break;
>  case DOWN:
> -locate(y, x, z,-M_PI_2, rw, rh, , );
> +locate(y, x, z, M_PI_2, rw, rh, , );
>  break;
>  }
>
> What I'm saying is: when I changed face order to this (which video
> sample seems to follow), I got a reasonable output.
> down | left | top
> front | right | back
>
> Comparing to Google's:
> right | left | top
> down | front | back

The video linked here does not have name of faces, so you can not know
what is front and what is back.

Just add support for typical cubemap layout currently used.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] mpeg2_metadata: Add support for A/53 caption extraction and removal

2018-03-12 Thread Aman Gupta
On Mon, Mar 12, 2018 at 12:24 AM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> ---
>  doc/bitstream_filters.texi  | 12 +++
>  libavcodec/mpeg2_metadata_bsf.c | 79 ++
> ++-
>  2 files changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index b7ea549322..c0b48e62dc 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -362,6 +362,18 @@ table 6-6).
>  Set the colour description in the stream (see H.262 section 6.3.6
>  and tables 6-7, 6-8 and 6-9).
>
> +@item a53_cc
> +Modify A/53 closed caption data in user data messages.
> +
> +@table @samp
> +@item remove
> +Remove all closed caption data from the stream.
> +
> +@item extract
> +Extract closed captions from the stream so that they are available as
> +as packet side data.
> +@end table
> +
>  @end table
>
>  @section mpeg4_unpack_bframes
> diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_
> bsf.c
> index 3bb6c1d549..0728ca4e09 100644
> --- a/libavcodec/mpeg2_metadata_bsf.c
> +++ b/libavcodec/mpeg2_metadata_bsf.c
> @@ -25,6 +25,12 @@
>  #include "cbs_mpeg2.h"
>  #include "mpeg12.h"
>
> +enum {
> +PASS,
> +REMOVE,
> +EXTRACT,
> +};
> +
>  typedef struct MPEG2MetadataContext {
>  const AVClass *class;
>
> @@ -43,6 +49,7 @@ typedef struct MPEG2MetadataContext {
>  int matrix_coefficients;
>
>  int mpeg1_warned;
> +int a53_cc;
>  } MPEG2MetadataContext;
>
>
> @@ -184,7 +191,9 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  MPEG2MetadataContext *ctx = bsf->priv_data;
>  AVPacket *in = NULL;
>  CodedBitstreamFragment *frag = >fragment;
> -int err;
> +int err, i;
> +uint8_t *a53_side_data = NULL;
> +size_t a53_side_data_size = 0;
>
>  err = ff_bsf_get_packet(bsf, );
>  if (err < 0)
> @@ -202,6 +211,55 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  goto fail;
>  }
>
> +if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
> +for (i = 0; i < frag->nb_units; i++) {
> +MPEG2RawUserData *ud = NULL;
> +uint32_t tag;
> +uint8_t type_code, count;
> +
> +if (frag->units[i].type != MPEG2_START_USER_DATA)
> +continue;
> +ud = frag->units[i].content;
> +if (ud->user_data_length < 6)
> +continue;
> +tag = AV_RB32(ud->user_data);
> +type_code = ud->user_data[4];
> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
> +continue;
> +
> +if (ctx->a53_cc == REMOVE) {
> +err = ff_cbs_delete_unit(ctx->cbc, frag, i);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> +   "A53 CC USER_DATA message.\n");
> +goto fail;
> +}
> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
>

I changed these to TRACE locally, but I'll mimic whatever happens in the
h264_metadata version of the patch.


> +
> +--i;
> +break;
> +}
> +
> +// Extract.
> +count = ud->user_data[5] & 0x1f;
> +if (3 * count + 8 > ud->user_data_length) {
> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed caption "
> +   "data: count %d overflows length %zu.\n",
> +   count, ud->user_data_length);
> +continue;
> +}
> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu bytes.\n",
> ud->user_data_length);
> +
> +err = av_reallocp(_side_data,
> +  a53_side_data_size + 3 * count);
> +if (err)
> +goto fail;
> +memcpy(a53_side_data + a53_side_data_size,
> +   ud->user_data + 9, 3 * count);
>

This should be ud->user_data + 7. Fixed locally.


> +a53_side_data_size += 3 * count;
> +}
> +}
> +
>  err = ff_cbs_write_packet(ctx->cbc, out, frag);
>  if (err < 0) {
>  av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
> @@ -214,9 +272,21 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  goto fail;
>  }
>
> +if (a53_side_data) {
> +err = av_packet_add_side_data(out, AV_PKT_DATA_A53_CC,
> +  a53_side_data, a53_side_data_size);
> +if (err) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to attach extracted A/53 "
> +   "side data to packet.\n");
> +goto fail;
> +}
> +a53_side_data = NULL;
> +}
> +
>  err = 0;
>  fail:
>  ff_cbs_fragment_uninit(ctx->cbc, frag);
> +av_freep(_side_data);
>
>  av_packet_free();
>
> @@ -288,6 

[FFmpeg-devel] [PATCH v2] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-12 Thread Aman Gupta
From: Aman Gupta 

---
 libavcodec/h264_slice.c|  5 +++--
 libavcodec/mpeg12dec.c | 14 +-
 libavcodec/mpegvideo_enc.c |  3 ++-
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 90e05ed8f1..b381397b4d 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -2762,7 +2762,7 @@ int ff_h264_execute_decode_slices(H264Context *h)
 
 sl = >slice_ctx[i];
 if (CONFIG_ERROR_RESILIENCE) {
-sl->er.error_count = 0;
+sl->er.error_count = ATOMIC_VAR_INIT(0);
 }
 
 /* make sure none of those slices overlap */
@@ -2786,7 +2786,8 @@ int ff_h264_execute_decode_slices(H264Context *h)
 h->mb_y  = sl->mb_y;
 if (CONFIG_ERROR_RESILIENCE) {
 for (i = 1; i < context_count; i++)
-h->slice_ctx[0].er.error_count += 
h->slice_ctx[i].er.error_count;
+atomic_fetch_add(>slice_ctx[0].er.error_count,
+ atomic_load(>slice_ctx[i].er.error_count));
 }
 
 if (h->postpone_filter) {
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 9e076e89da..ad2586dc07 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1992,7 +1992,8 @@ static int slice_decode_thread(AVCodecContext *c, void 
*arg)
 int mb_y= s->start_mb_y;
 const int field_pic = s->picture_structure != PICT_FRAME;
 
-s->er.error_count = (3 * (s->end_mb_y - s->start_mb_y) * s->mb_width) >> 
field_pic;
+s->er.error_count = ATOMIC_VAR_INIT(
+(3 * (s->end_mb_y - s->start_mb_y) * s->mb_width) >> field_pic);
 
 for (;;) {
 uint32_t start_code;
@@ -2002,7 +2003,7 @@ static int slice_decode_thread(AVCodecContext *c, void 
*arg)
 emms_c();
 ff_dlog(c, "ret:%d resync:%d/%d mb:%d/%d ts:%d/%d ec:%d\n",
 ret, s->resync_mb_x, s->resync_mb_y, s->mb_x, s->mb_y,
-s->start_mb_y, s->end_mb_y, s->er.error_count);
+s->start_mb_y, s->end_mb_y, atomic_load(>er.error_count));
 if (ret < 0) {
 if (c->err_recognition & AV_EF_EXPLODE)
 return ret;
@@ -2485,7 +2486,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
>thread_context[0], NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count += 
s2->thread_context[i]->er.error_count;
+atomic_fetch_add(>er.error_count,
+
atomic_load(>thread_context[i]->er.error_count));
 }
 
 ret = slice_end(avctx, picture);
@@ -2499,7 +2501,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
 }
 s2->pict_type = 0;
 
-if (avctx->err_recognition & AV_EF_EXPLODE && s2->er.error_count)
+if (avctx->err_recognition & AV_EF_EXPLODE &&
+atomic_load(>er.error_count))
 return AVERROR_INVALIDDATA;
 
 return FFMAX(0, buf_ptr - buf - s2->parse_context.last_index);
@@ -2553,7 +2556,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
s2->thread_context, NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count += 
s2->thread_context[i]->er.error_count;
+atomic_fetch_add(>er.error_count,
+atomic_load(>thread_context[i]->er.error_count));
 s->slice_count = 0;
 }
 if (last_code == 0 || last_code == SLICE_MIN_START_CODE) {
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 979e138b88..b69e0e1727 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3595,7 +3595,8 @@ static void merge_context_after_encode(MpegEncContext 
*dst, MpegEncContext *src)
 MERGE(b_count);
 MERGE(skip_count);
 MERGE(misc_bits);
-MERGE(er.error_count);
+atomic_fetch_add(>er.error_count, atomic_load(>er.error_count));
+src->er.error_count = ATOMIC_VAR_INIT(0);
 MERGE(padding_bug_score);
 MERGE(current_picture.encoding_error[0]);
 MERGE(current_picture.encoding_error[1]);
-- 
2.14.2

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


Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

2018-03-12 Thread Hazem Ashmawy
So, I spend few hours trying to incorporate the partial change.

I'm not sure that the video sent by  earlier follows the
faces order here
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3

Because when I made this change, I got a reasonable equirectangular ouput:
https://imgur.com/a/BEN00

comparing to the changes sent earlier.
https://imgur.com/a/vaIvW

diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
index de08ef4..5383d57 100644
--- a/libavfilter/vf_panorama.c
+++ b/libavfilter/vf_panorama.c
@@ -34,12 +34,12 @@ enum Projections {
 };

 enum Faces {
+DOWN,
 LEFT,
+TOP,
 FRONT,
 RIGHT,
-TOP,
 BACK,
-DOWN,
 };

 struct XYRemap {
@@ -403,7 +403,7 @@ static int config_output(AVFilterLink *outlink)

 switch (face) {
 case LEFT:
-locate(z, x, y, M_PI,   rw, rh, , );
+locate(z, x, y, -M_PI_2,   rw, rh, , );
 break;
 case FRONT:
 locate(x, z, y, 0., rw, rh, , );
@@ -418,7 +418,7 @@ static int config_output(AVFilterLink *outlink)
 locate(x, y, z,-M_PI_2, rw, rh, , );
 break;
 case DOWN:
-locate(y, x, z,-M_PI_2, rw, rh, , );
+locate(y, x, z, M_PI_2, rw, rh, , );
 break;
 }

What I'm saying is: when I changed face order to this (which video
sample seems to follow), I got a reasonable output.
down | left | top
front | right | back

Comparing to Google's:
right | left | top
down | front | back
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] mpeg2_metadata: Add support for A/53 caption extraction and removal

2018-03-12 Thread Aman Gupta
From: Aman Gupta 

---
 doc/bitstream_filters.texi  | 12 +++
 libavcodec/mpeg2_metadata_bsf.c | 79 -
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index b7ea549322..c0b48e62dc 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -362,6 +362,18 @@ table 6-6).
 Set the colour description in the stream (see H.262 section 6.3.6
 and tables 6-7, 6-8 and 6-9).
 
+@item a53_cc
+Modify A/53 closed caption data in user data messages.
+
+@table @samp
+@item remove
+Remove all closed caption data from the stream.
+
+@item extract
+Extract closed captions from the stream so that they are available as
+as packet side data.
+@end table
+
 @end table
 
 @section mpeg4_unpack_bframes
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 3bb6c1d549..0728ca4e09 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -25,6 +25,12 @@
 #include "cbs_mpeg2.h"
 #include "mpeg12.h"
 
+enum {
+PASS,
+REMOVE,
+EXTRACT,
+};
+
 typedef struct MPEG2MetadataContext {
 const AVClass *class;
 
@@ -43,6 +49,7 @@ typedef struct MPEG2MetadataContext {
 int matrix_coefficients;
 
 int mpeg1_warned;
+int a53_cc;
 } MPEG2MetadataContext;
 
 
@@ -184,7 +191,9 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf, 
AVPacket *out)
 MPEG2MetadataContext *ctx = bsf->priv_data;
 AVPacket *in = NULL;
 CodedBitstreamFragment *frag = >fragment;
-int err;
+int err, i;
+uint8_t *a53_side_data = NULL;
+size_t a53_side_data_size = 0;
 
 err = ff_bsf_get_packet(bsf, );
 if (err < 0)
@@ -202,6 +211,55 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf, 
AVPacket *out)
 goto fail;
 }
 
+if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
+for (i = 0; i < frag->nb_units; i++) {
+MPEG2RawUserData *ud = NULL;
+uint32_t tag;
+uint8_t type_code, count;
+
+if (frag->units[i].type != MPEG2_START_USER_DATA)
+continue;
+ud = frag->units[i].content;
+if (ud->user_data_length < 6)
+continue;
+tag = AV_RB32(ud->user_data);
+type_code = ud->user_data[4];
+if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
+continue;
+
+if (ctx->a53_cc == REMOVE) {
+err = ff_cbs_delete_unit(ctx->cbc, frag, i);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to delete "
+   "A53 CC USER_DATA message.\n");
+goto fail;
+}
+av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");
+
+--i;
+break;
+}
+
+// Extract.
+count = ud->user_data[5] & 0x1f;
+if (3 * count + 8 > ud->user_data_length) {
+av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed caption "
+   "data: count %d overflows length %zu.\n",
+   count, ud->user_data_length);
+continue;
+}
+av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu bytes.\n", 
ud->user_data_length);
+
+err = av_reallocp(_side_data,
+  a53_side_data_size + 3 * count);
+if (err)
+goto fail;
+memcpy(a53_side_data + a53_side_data_size,
+   ud->user_data + 9, 3 * count);
+a53_side_data_size += 3 * count;
+}
+}
+
 err = ff_cbs_write_packet(ctx->cbc, out, frag);
 if (err < 0) {
 av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
@@ -214,9 +272,21 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf, 
AVPacket *out)
 goto fail;
 }
 
+if (a53_side_data) {
+err = av_packet_add_side_data(out, AV_PKT_DATA_A53_CC,
+  a53_side_data, a53_side_data_size);
+if (err) {
+av_log(bsf, AV_LOG_ERROR, "Failed to attach extracted A/53 "
+   "side data to packet.\n");
+goto fail;
+}
+a53_side_data = NULL;
+}
+
 err = 0;
 fail:
 ff_cbs_fragment_uninit(ctx->cbc, frag);
+av_freep(_side_data);
 
 av_packet_free();
 
@@ -288,6 +358,13 @@ static const AVOption mpeg2_metadata_options[] = {
 OFFSET(matrix_coefficients), AV_OPT_TYPE_INT,
 { .i64 = -1 }, -1, 255 },
 
+{ "a53_cc", "A/53 Closed Captions in SEI NAL units",
+OFFSET(a53_cc), AV_OPT_TYPE_INT,
+{ .i64 = PASS }, PASS, EXTRACT, 0, "a53_cc" },
+{ "pass",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PASS}, .unit = 
"a53_cc" },
+{ "remove",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE  }, .unit = 
"a53_cc" },
+{ "extract", NULL, 0, 

Re: [FFmpeg-devel] [PATCH 4/8] h264_metadata: Add support for A/53 closed captions

2018-03-12 Thread Aman Gupta
On Sun, Mar 11, 2018 at 11:30 AM, Mark Thompson  wrote:

> ---
>  libavcodec/h264_metadata_bsf.c | 121 ++
> +++
>  1 file changed, 121 insertions(+)
>
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_
> bsf.c
> index 36047887ca..d340c55990 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -77,6 +77,8 @@ typedef struct H264MetadataContext {
>  int display_orientation;
>  double rotate;
>  int flip;
> +
> +int a53_cc;
>  } H264MetadataContext;
>
>
> @@ -225,6 +227,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  int err, i, j, has_sps;
>  uint8_t *displaymatrix_side_data = NULL;
>  size_t displaymatrix_side_data_size = 0;
> +uint8_t *a53_side_data = NULL;
> +size_t a53_side_data_size = 0;
>
>  err = ff_bsf_get_packet(bsf, );
>  if (err < 0)
> @@ -514,6 +518,104 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  }
>  }
>
> +if (ctx->a53_cc == INSERT) {
> +uint8_t *data;
> +int size;
> +
> +data = av_packet_get_side_data(in, AV_PKT_DATA_A53_CC, );
> +if (data) {
> +H264RawSEIPayload payload = {
> +.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
> +};
> +H264RawSEIUserDataRegistered *udr =
> +_data_registered;
> +
> +av_log(bsf, AV_LOG_WARNING, "A53 CC insert: %d bytes.\n",
> size);
> +
> +udr->data_length = size + 10;
> +udr->data_ref= av_buffer_alloc(udr->data_length);
> +if (!udr->data_ref) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +udr->data = udr->data_ref->data;
> +
> +udr->itu_t_t35_country_code = 181;
> +udr->data[0] = 0;
> +udr->data[1] = 49;
> +AV_WB32(udr->data + 2, MKBETAG('G', 'A', '9', '4'));
> +udr->data[6] = 3;
> +udr->data[7] = ((size / 3) & 0x1f) | 0x40;
> +udr->data[8] = 0;
> +memcpy(udr->data + 9, data, size);
> +udr->data[size + 9] = 0xff;
> +
> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
> +   "message to access unit.\n");
> +av_buffer_unref(>data_ref);
> +goto fail;
> +}
> +}
> +
> +} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
> +for (i = 0; i < au->nb_units; i++) {
> +H264RawSEI *sei;
> +if (au->units[i].type != H264_NAL_SEI)
> +continue;
> +sei = au->units[i].content;
> +
> +for (j = 0; j < sei->payload_count; j++) {
> +H264RawSEIUserDataRegistered *udr;
> +uint32_t tag;
> +uint8_t type_code, count;
> +
> +if (sei->payload[j].payload_type !=
> +H264_SEI_TYPE_USER_DATA_REGISTERED)
> +continue;
> +udr = >payload[j].payload.user_data_registered;
> +tag = AV_RB32(udr->data + 2);
> +type_code = udr->data[6];
> +if (tag != MKBETAG('G', 'A', '9', '4') || type_code != 3)
> +continue;
> +
> +if (ctx->a53_cc == REMOVE) {
> +err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
> + >units[i],
> j);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> +   "A53 CC SEI message.\n");
> +goto fail;
> +}
> +av_log(bsf, AV_LOG_WARNING, "A53 CC remove!.\n");

+
> +--i;
> +break;
> +}
> +
> +// Extract.
> +count = udr->data[7] & 0x1f;
> +if (3 * count + 10 > udr->data_length) {
> +av_log(bsf, AV_LOG_ERROR, "Invalid A/53 closed
> caption "
> +   "data: count %d overflows length %zu.\n",
> +   count, udr->data_length);
> +continue;
> +}
> +
> +av_log(bsf, AV_LOG_WARNING, "A53 CC extract: %zu
> bytes.\n", udr->data_length);
>

I assume these are WARNINGs from testing? Seems like TRACE or DEBUG would
be fine.


> +
> +err = av_reallocp(_side_data,
> +  a53_side_data_size + 3 * count);
> +if (err)
> +goto fail;
> +memcpy(a53_side_data + a53_side_data_size,
> +   udr->data + 9, 3 * count);
> +

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Valery Kot
Gents,

Could somebody please take a look into my patch? Or is it somehow invisible
/ badly formatted?

It allows for inducing key frames at proper moments by e.g.
-force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
license, which is important for us.

Valery

On Monday, March 5, 2018, Valery Kot  wrote:

> libx264 encoder uses AVFrame.pict_type (if provided by user) to use this
> frame as key frame.
>
> For openh264 encoder this functionality is missing, pict_type simply being
> ignored.
>
> Attached patch fixes it.
>
> Valery
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 4/5] avformat/hlsenc: fix fmp4 single init file problem

2018-03-12 Thread Steven Liu
fix ticket: #7021

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 66 +++-
 1 file changed, 50 insertions(+), 16 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ad9f4d3394..196632d066 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -763,7 +763,11 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 if ((ret = avio_open_dyn_buf(>pb)) < 0)
 return ret;
 
-ret = hlsenc_io_open(s, >out, vs->base_output_dirname, );
+if (byterange_mode) {
+ret = hlsenc_io_open(s, >out, vs->basename, );
+} else {
+ret = hlsenc_io_open(s, >out, vs->base_output_dirname, 
);
+}
 av_dict_free();
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n", 
vs->fmp4_init_filename);
@@ -1395,8 +1399,8 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 }
 
 if ((hls->segment_type == SEGMENT_TYPE_FMP4) && (en == vs->segments)) {
-ff_hls_write_init_file(hls->m3u8_out, vs->fmp4_init_filename,
-   hls->flags & HLS_SINGLE_FILE, en->size, 
en->pos);
+ff_hls_write_init_file(hls->m3u8_out, (hls->flags & 
HLS_SINGLE_FILE) ? en->filename : vs->fmp4_init_filename,
+   hls->flags & HLS_SINGLE_FILE, 
vs->init_range_length, 0);
 }
 
 ret = ff_hls_write_file_entry(hls->m3u8_out, en->discont, 
byterange_mode,
@@ -2175,9 +2179,12 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 av_write_frame(vs->avf, NULL); /* Flush any buffered data */
 
 new_start_pos = avio_tell(vs->avf->pb);
-vs->size = new_start_pos - vs->start_pos;
+if (hls->segment_type != SEGMENT_TYPE_FMP4) {
+vs->size = new_start_pos - vs->start_pos;
+} else {
+vs->size = new_start_pos;
+}
 
-if (!byterange_mode) {
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (!vs->init_range_length) {
 avio_flush(oc->pb);
@@ -2186,16 +2193,22 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 vs->init_range_length = range_length;
 avio_open_dyn_buf(>pb);
 vs->packets_written = 0;
-ff_format_io_close(s, >out);
-hlsenc_io_close(s, >out, vs->base_output_dirname);
+vs->start_pos = range_length;
+if (!byterange_mode) {
+ff_format_io_close(s, >out);
+hlsenc_io_close(s, >out, vs->base_output_dirname);
+}
 }
 } else {
+if (!byterange_mode) {
 hlsenc_io_close(s, >pb, oc->url);
+}
 }
+if (!byterange_mode) {
 if (vs->vtt_avf) {
 hlsenc_io_close(s, >vtt_avf->pb, vs->vtt_avf->url);
 }
-}
+}
 if ((hls->flags & HLS_TEMP_FILE) && oc->url[0]) {
 if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <= 0))
 if ((vs->avf->oformat->priv_class && vs->avf->priv_data) && 
hls->segment_type != SEGMENT_TYPE_FMP4)
@@ -2208,6 +2221,14 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
+if (hls->flags & HLS_SINGLE_FILE) {
+ret = flush_dynbuf(vs, _length);
+if (ret < 0) {
+av_free(old_filename);
+return ret;
+}
+vs->size = range_length;
+} else {
 ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Failed to open file '%s'\n",
@@ -2220,6 +2241,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return ret;
 }
 ff_format_io_close(s, >out);
+}
 }
 
 old_filename = av_strdup(vs->avf->url);
@@ -2227,15 +2249,21 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 return AVERROR(ENOMEM);
 }
 
-ret = hls_append_segment(s, hls, vs, vs->duration, vs->start_pos, 
vs->size);
-vs->start_pos = new_start_pos;
-if (ret < 0) {
-av_free(old_filename);
-return ret;
+if (vs->start_pos || hls->segment_type != SEGMENT_TYPE_FMP4) {
+ret = hls_append_segment(s, hls, vs, vs->duration, vs->start_pos, 
vs->size);
+vs->end_pts = pkt->pts;
+vs->duration = 0;
+if (ret < 0) {
+av_free(old_filename);
+return ret;
+}
 }
 
-vs->end_pts = 

[FFmpeg-devel] [PATCH 1/5] avformat/hlsenc: fix write wrong init file URI string problem

2018-03-12 Thread Steven Liu
fmp4_init_filename should append after base_output_dirname

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 08fe0aa7a0..9c5798b557 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2581,21 +2581,6 @@ static int hls_init(AVFormatContext *s)
 }
 av_strlcpy(vs->fmp4_init_filename, hls->fmp4_init_filename,
fmp4_init_filename_len);
-
-if (av_strcasecmp(hls->fmp4_init_filename, "init.mp4")) {
-ret = format_name(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
-if (ret < 0)
-goto fail;
-
-fmp4_init_filename_len = strlen(vs->fmp4_init_filename) + 1;
-vs->base_output_dirname = av_malloc(fmp4_init_filename_len);
-if (!vs->base_output_dirname) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
-   fmp4_init_filename_len);
-} else {
 if (hls->nb_varstreams > 1) {
 ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
 if (ret < 0)
@@ -2622,7 +2607,6 @@ static int hls_init(AVFormatContext *s)
 av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
fmp4_init_filename_len);
 }
-}
 }
 
 if (!hls->use_localtime) {
-- 
2.15.1



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


[FFmpeg-devel] [PATCH 3/5] avformat/hlsenc: fix memleak problem about fmp4_init_filename

2018-03-12 Thread Steven Liu
move fmp4_init_filename init in if else for first fmp4_init_filename set
value operation.

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7ca4099e7e..ad9f4d3394 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2574,6 +2574,13 @@ static int hls_init(AVFormatContext *s)
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->nb_varstreams > 1)
 fmp4_init_filename_len += strlen(POSTFIX_PATTERN);
+if (hls->flags & HLS_SINGLE_FILE) {
+vs->fmp4_init_filename  = av_strdup(vs->basename);
+if (!vs->fmp4_init_filename) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+} else {
 vs->fmp4_init_filename = av_malloc(fmp4_init_filename_len);
 if (!vs->fmp4_init_filename ) {
 ret = AVERROR(ENOMEM);
@@ -2607,6 +2614,7 @@ static int hls_init(AVFormatContext *s)
 av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
fmp4_init_filename_len);
 }
+}
 }
 
 if (!hls->use_localtime) {
@@ -2661,13 +2669,6 @@ static int hls_init(AVFormatContext *s)
 }
 }
 
-if ((hls->flags & HLS_SINGLE_FILE) && (hls->segment_type == 
SEGMENT_TYPE_FMP4)) {
-vs->fmp4_init_filename  = av_strdup(vs->basename);
-if (!vs->fmp4_init_filename) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-}
 if ((ret = hls_mux_init(s, vs)) < 0)
 goto fail;
 
-- 
2.15.1



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


[FFmpeg-devel] [PATCH 5/5] avformat/hlsenc: reindent after previous commits

2018-03-12 Thread Steven Liu
Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 250 +--
 1 file changed, 125 insertions(+), 125 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 196632d066..d319cba764 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2171,7 +2171,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 
 if (vs->packets_written && can_split && av_compare_ts(pkt->pts - 
vs->start_pts, st->time_base,
-   end_pts, AV_TIME_BASE_Q) >= 0) {
+  end_pts, 
AV_TIME_BASE_Q) >= 0) {
 int64_t new_start_pos;
 char *old_filename = NULL;
 int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || 
(hls->max_seg_size > 0);
@@ -2185,30 +2185,30 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 vs->size = new_start_pos;
 }
 
-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
-if (!vs->init_range_length) {
-avio_flush(oc->pb);
-range_length = avio_close_dyn_buf(oc->pb, );
-avio_write(vs->out, buffer, range_length);
-vs->init_range_length = range_length;
-avio_open_dyn_buf(>pb);
-vs->packets_written = 0;
-vs->start_pos = range_length;
-if (!byterange_mode) {
-ff_format_io_close(s, >out);
-hlsenc_io_close(s, >out, vs->base_output_dirname);
-}
-}
-} else {
+if (hls->segment_type == SEGMENT_TYPE_FMP4) {
+if (!vs->init_range_length) {
+avio_flush(oc->pb);
+range_length = avio_close_dyn_buf(oc->pb, );
+avio_write(vs->out, buffer, range_length);
+vs->init_range_length = range_length;
+avio_open_dyn_buf(>pb);
+vs->packets_written = 0;
+vs->start_pos = range_length;
 if (!byterange_mode) {
-hlsenc_io_close(s, >pb, oc->url);
+ff_format_io_close(s, >out);
+hlsenc_io_close(s, >out, vs->base_output_dirname);
 }
 }
+} else {
 if (!byterange_mode) {
+hlsenc_io_close(s, >pb, oc->url);
+}
+}
+if (!byterange_mode) {
 if (vs->vtt_avf) {
 hlsenc_io_close(s, >vtt_avf->pb, vs->vtt_avf->url);
 }
-}
+}
 if ((hls->flags & HLS_TEMP_FILE) && oc->url[0]) {
 if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <= 0))
 if ((vs->avf->oformat->priv_class && vs->avf->priv_data) && 
hls->segment_type != SEGMENT_TYPE_FMP4)
@@ -2229,18 +2229,18 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 vs->size = range_length;
 } else {
-ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
-if (ret < 0) {
-av_log(NULL, AV_LOG_ERROR, "Failed to open file '%s'\n",
-vs->avf->url);
-return ret;
-}
-write_styp(vs->out);
-ret = flush_dynbuf(vs, _length);
-if (ret < 0) {
-return ret;
-}
-ff_format_io_close(s, >out);
+ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
+   vs->avf->url);
+return ret;
+}
+write_styp(vs->out);
+ret = flush_dynbuf(vs, _length);
+if (ret < 0) {
+return ret;
+}
+ff_format_io_close(s, >out);
 }
 }
 
@@ -2314,85 +2314,85 @@ static int hls_write_trailer(struct AVFormatContext *s)
 for (i = 0; i < hls->nb_varstreams; i++) {
 vs = >var_streams[i];
 
-oc = vs->avf;
-vtt_oc = vs->vtt_avf;
-old_filename = av_strdup(vs->avf->url);
+oc = vs->avf;
+vtt_oc = vs->vtt_avf;
+old_filename = av_strdup(vs->avf->url);
 
-if (!old_filename) {
-return AVERROR(ENOMEM);
-}
-if ( hls->segment_type == SEGMENT_TYPE_FMP4) {
-int range_length = 0;
-if (!(hls->flags & HLS_SINGLE_FILE)) {
-ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
-if (ret < 0) {
-av_log(NULL, AV_LOG_ERROR, "Failed to open file '%s'\n", 
vs->avf->url);
-goto failed;
-}
-write_styp(vs->out);
+if (!old_filename) {
+return AVERROR(ENOMEM);
 }
-ret = flush_dynbuf(vs, _length);
- 

[FFmpeg-devel] [PATCH 2/5] avformat/hlsenc: reindent after previous commits

2018-03-12 Thread Steven Liu
Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9c5798b557..7ca4099e7e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2581,32 +2581,32 @@ static int hls_init(AVFormatContext *s)
 }
 av_strlcpy(vs->fmp4_init_filename, hls->fmp4_init_filename,
fmp4_init_filename_len);
-if (hls->nb_varstreams > 1) {
-ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
-if (ret < 0)
- goto fail;
-}
+if (hls->nb_varstreams > 1) {
+ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
+if (ret < 0)
+goto fail;
+}
 
-fmp4_init_filename_len = strlen(vs->m3u8_name) +
-strlen(vs->fmp4_init_filename) + 1;
+fmp4_init_filename_len = strlen(vs->m3u8_name) +
+strlen(vs->fmp4_init_filename) + 1;
 
-vs->base_output_dirname = av_malloc(fmp4_init_filename_len);
-if (!vs->base_output_dirname) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
+vs->base_output_dirname = av_malloc(fmp4_init_filename_len);
+if (!vs->base_output_dirname) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 
-av_strlcpy(vs->base_output_dirname, vs->m3u8_name,
+av_strlcpy(vs->base_output_dirname, vs->m3u8_name,
+   fmp4_init_filename_len);
+p = strrchr(vs->base_output_dirname, '/');
+if (p) {
+*(p + 1) = '\0';
+av_strlcat(vs->base_output_dirname, vs->fmp4_init_filename,
fmp4_init_filename_len);
-p = strrchr(vs->base_output_dirname, '/');
-if (p) {
-*(p + 1) = '\0';
-av_strlcat(vs->base_output_dirname, vs->fmp4_init_filename,
-   fmp4_init_filename_len);
-} else {
-av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
-   fmp4_init_filename_len);
-}
+} else {
+av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
+   fmp4_init_filename_len);
+}
 }
 
 if (!hls->use_localtime) {
-- 
2.15.1



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


[FFmpeg-devel] [PATCH] fix mem-leak

2018-03-12 Thread Danil Iashchenko
---
 libavfilter/vf_convolution_opencl.c | 39 ++---
 1 file changed, 15 insertions(+), 24 deletions(-)

diff --git a/libavfilter/vf_convolution_opencl.c 
b/libavfilter/vf_convolution_opencl.c
index 60e2d1f..a14005b 100644
--- a/libavfilter/vf_convolution_opencl.c
+++ b/libavfilter/vf_convolution_opencl.c
@@ -139,7 +139,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 matrix = av_malloc(matrix_bytes);
 if (!matrix) {
 err = AVERROR(ENOMEM);
-goto fail;
+goto fail_matrix;
 }
 cnt = 0;
 for (i = 0; i < 4; i++) {
@@ -157,7 +157,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Failed to create matrix buffer: "
"%d.\n", cle);
 err = AVERROR(EIO);
-goto fail;
+goto fail_matrix;
 }
 ctx->matrix = buffer;
 
@@ -166,8 +166,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 matrix_rdiv = av_malloc(matrix_bytes);
 if (!matrix_rdiv) {
 err = AVERROR(ENOMEM);
-av_freep(_rdiv);
-goto fail;
+goto fail_rdiv;
 }
 
 for (j = 0; j < 4; j++) {
@@ -182,8 +181,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Failed to create rdiv buffer: "
"%d.\n", cle);
 err = AVERROR(EIO);
-av_freep(_rdiv);
-goto fail;
+goto fail_rdiv;
 }
 ctx->rdiv_buffer = buffer_rdiv;
 
@@ -192,9 +190,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 matrix_bias = av_malloc(matrix_bytes);
 if (!matrix_bias) {
 err = AVERROR(ENOMEM);
-av_freep(_rdiv);
-av_freep(_bias);
-goto fail;
+goto fail_bias;
 }
 
 for (j = 0; j < 4; j++) {
@@ -209,9 +205,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Failed to create bias buffer: "
"%d.\n", cle);
 err = AVERROR(EIO);
-av_freep(_rdiv);
-av_freep(_bias);
-goto fail;
+goto fail_bias;
 }
 ctx->bias_buffer = buffer_bias;
 
@@ -219,10 +213,7 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 matrix_size = av_malloc(matrix_bytes);
 if (!matrix_size) {
 err = AVERROR(ENOMEM);
-av_freep(_rdiv);
-av_freep(_bias);
-av_freep(_size);
-goto fail;
+goto fail_size;
 }
 
 for (j = 0; j < 4; j++) {
@@ -237,18 +228,18 @@ static int 
convolution_opencl_make_filter_params(AVFilterContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Failed to create bias buffer: "
"%d.\n", cle);
 err = AVERROR(EIO);
-av_freep(_rdiv);
-av_freep(_bias);
-av_freep(_size);
-goto fail;
+goto fail_size;
 }
 ctx->size_buffer = buffer_size;
 
-
-
-
 err = 0;
-fail:
+fail_size:
+av_freep(_size);
+fail_bias:
+av_freep(_bias);
+fail_rdiv:
+av_freep(_rdiv);
+fail_matrix:
 av_freep();
 return err;
 }
-- 
2.7.4

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