Re: [FFmpeg-devel] [PATCH] swscale/output: VSX-optimize nbps yuv2plane1

[Lauri Kasanen]

On Thu, 6 Dec 2018 22:36:01 +0100
Carl Eugen Hoyos  wrote:

> 2018-11-27 14:26 GMT+01:00, Lauri Kasanen :
> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > yuv420p9le \
> > -f null -vframes 100 -v error -nostats -
> >
> > Speedups:
> > yuv2plane1_9BE_vsx  11.2042
> > yuv2plane1_9LE_vsx  11.156
> > yuv2plane1_10BE_vsx 9.89428
> > yuv2plane1_10LE_vsx 10.3637
> > yuv2plane1_12BE_vsx 9.71923
> > yuv2plane1_12LE_vsx 11.0404
> > yuv2plane1_14BE_vsx 10.1763
> > yuv2plane1_14LE_vsx 11.2728
> >
> > Fate passes, each format tested with an image to video conversion.
> >
> > Depends on "swscale/ppc: Move VSX-using code to its own file".
> 
> > Only tested on LE.
> 
> This patch breaks output on BE, tested with fate-v410enc and:
> $ ffmpeg -i fate-suite/lena.pnm -pix_fmt yuv420p10 -vcodec ffv1 out.nut

Just checking, was that with the !BE guards removed? Otherwise I don't
see how it could affect BE?

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

[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc : Added an option to ignore IO errors

[Karthick J]

Useful for long duration runs with network output
---
 doc/muxers.texi  |  3 +++
 libavformat/hlsenc.c | 41 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index ca10741900..8eefcf1e82 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1018,6 +1018,9 @@ Use persistent HTTP connections. Applicable only for HTTP 
output.
 @item timeout
 Set timeout for socket I/O operations. Applicable only for HTTP output.
 
+@item -ignore_io_errors
+Ignore IO errors during open, write and delete. Useful for long-duration runs 
with network output.
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 42adcfbab1..bdd2a113bd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -227,6 +227,7 @@ typedef struct HLSContext {
 AVIOContext *m3u8_out;
 AVIOContext *sub_m3u8_out;
 int64_t timeout;
+int ignore_io_errors;
 } HLSContext;
 
 static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
@@ -496,8 +497,11 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 proto = avio_find_protocol_name(s->url);
 if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
 av_dict_set(, "method", "DELETE", 0);
-if ((ret = vs->avf->io_open(vs->avf, , path, AVIO_FLAG_WRITE, 
)) < 0)
+if ((ret = vs->avf->io_open(vs->avf, , path, AVIO_FLAG_WRITE, 
)) < 0) {
+if (hls->ignore_io_errors)
+ret = 0;
 goto fail;
+}
 ff_format_io_close(vs->avf, );
 } else if (unlink(path) < 0) {
 av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
@@ -525,6 +529,8 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
 av_dict_set(, "method", "DELETE", 0);
 if ((ret = vs->vtt_avf->io_open(vs->vtt_avf, , sub_path, 
AVIO_FLAG_WRITE, )) < 0) {
+if (hls->ignore_io_errors)
+ret = 0;
 av_free(sub_path);
 goto fail;
 }
@@ -1380,8 +1386,11 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 
 set_http_options(s, , hls);
 snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" : 
"%s", vs->m3u8_name);
-if ((ret = hlsenc_io_open(s, >m3u8_out, temp_filename, )) < 0)
+if ((ret = hlsenc_io_open(s, >m3u8_out, temp_filename, )) < 
0) {
+if (hls->ignore_io_errors)
+ret = 0;
 goto fail;
+}
 
 for (en = vs->segments; en; en = en->next) {
 if (target_duration <= en->duration)
@@ -1428,8 +1437,11 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 ff_hls_write_end_list(hls->m3u8_out);
 
 if( vs->vtt_m3u8_name ) {
-if ((ret = hlsenc_io_open(s, >sub_m3u8_out, vs->vtt_m3u8_name, 
)) < 0)
+if ((ret = hlsenc_io_open(s, >sub_m3u8_out, vs->vtt_m3u8_name, 
)) < 0) {
+if (hls->ignore_io_errors)
+ret = 0;
 goto fail;
+}
 ff_hls_write_playlist_header(hls->sub_m3u8_out, hls->version, 
hls->allowcache,
  target_duration, sequence, 
PLAYLIST_TYPE_NONE);
 for (en = vs->segments; en; en = en->next) {
@@ -1452,7 +1464,6 @@ fail:
 hlsenc_io_close(s, >sub_m3u8_out, vs->vtt_m3u8_name);
 if (use_temp_file)
 ff_rename(temp_filename, vs->m3u8_name, s);
-
 if (ret >= 0 && hls->master_pl_name)
 if (create_master_playlist(s, vs) < 0)
 av_log(s, AV_LOG_WARNING, "Master playlist creation failed\n");
@@ -1611,13 +1622,19 @@ static int hls_start(AVFormatContext *s, VariantStream 
*vs)
 if (err < 0)
 return err;
 } else if (c->segment_type != SEGMENT_TYPE_FMP4) {
-if ((err = hlsenc_io_open(s, >pb, oc->url, )) < 0)
+if ((err = hlsenc_io_open(s, >pb, oc->url, )) < 0) {
+if (c->ignore_io_errors)
+err = 0;
 goto fail;
+}
 }
 if (vs->vtt_basename) {
 set_http_options(s, , c);
-if ((err = hlsenc_io_open(s, _oc->pb, vtt_oc->url, )) < 0)
+if ((err = hlsenc_io_open(s, _oc->pb, vtt_oc->url, )) < 0) 
{
+if (c->ignore_io_errors)
+err = 0;
 goto fail;
+}
 }
 av_dict_free();
 
@@ -2257,9 +2274,9 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 set_http_options(s, , hls);
 ret = hlsenc_io_open(s, >out, vs->avf->url, );
 if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
-   vs->avf->url);
-return ret;
+

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: Handled error from ff_http_do_new_request() function

[Karthick J]

This patch fixes the segmentation fault issues due to unhandled errors from 
ff_http_do_new_request function.
---
 libavformat/hlsenc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 31ef0237ae..42adcfbab1 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -241,6 +241,9 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 URLContext *http_url_context = ffio_geturlcontext(*pb);
 av_assert0(http_url_context);
 err = ff_http_do_new_request(http_url_context, filename);
+if (err < 0)
+ff_format_io_close(s, pb);
+
 #endif
 }
 return err;
@@ -249,6 +252,8 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
 HLSContext *hls = s->priv_data;
 int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
+if (!*pb)
+return;
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
 #if CONFIG_HTTP_PROTOCOL
@@ -2329,7 +2334,8 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 
 vs->packets_written++;
-ret = ff_write_chained(oc, stream_index, pkt, s, 0);
+if (oc->pb)
+ret = ff_write_chained(oc, stream_index, pkt, s, 0);
 
 return ret;
 }
-- 
2.17.1 (Apple Git-112)

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

Re: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with error return

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, December 6, 2018 20:30
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with
> error return
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Thursday, December 6, 2018 7:19 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with error
> > return
> >
> > bs->FrameType is not set in MSDK in some cases (mjpeg encode for
> > bs->example),
> > and assert on a value coming from an external library is not proper.
> >
> > Add default type check for bs->FrameType, and return invalid data error in
> > function ff_qsv_encode to avoid using uninitialized value.
> >
> > Fix #7593.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: Add default bs->FrameType check.
> >
> >  libavcodec/qsvenc.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 7f4592f878..917344b60c 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1337,8 +1337,10 @@ int ff_qsv_encode(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  pict_type = AV_PICTURE_TYPE_P;
> >  else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType
> > & MFX_FRAMETYPE_xB)
> >  pict_type = AV_PICTURE_TYPE_B;
> > +else if (bs->FrameType == MFX_FRAMETYPE_UNKNOWN)
> 
> Unknown frame type has potential risk and would better give a waring log
> message here.

Thanks, will add. 

> 
> > +pict_type = AV_PICTURE_TYPE_NONE;
> >  else
> > -av_assert0(!"Uninitialized pict_type!");
> > +return AVERROR_INVALIDDATA;
> 
> If frame type is MFX_FRAMETYPE_IDR or MFX_FRAMETYPE_xIDR, will go
> here but this is not invalid data.
> So pict_tpye should be set to AV_PICTURE_TYPE_I in this case I believe.

It seems that  Frame types such as MFX_FRAMETYPE_IDR and 
MFX_FRAMETYPE_xIDR will be set along with MFX_FRAMETYPE_I in MSDK. 
But frame type which only contains IDR or xIDR should also be set to type I.

Will also add an log message to report an error.

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found

[Michael Niedermayer]

On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
> This recovers state with #7374 linked sample.
> 
> Work funded by Open Broadcast Systems.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/h264_refs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index eaf965e43d..5645a203a7 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
>  }
>  break;
>  case MMCO_RESET:
> +default:
>  while (h->short_ref_count) {
>  remove_short(h, h->short_ref[0]->frame_num, 0);
>  }
> @@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
>  for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>  h->last_pocs[j] = INT_MIN;
>  break;
> -default: assert(0);
>  }
>  }

mmco[i].opcode should not be invalid, its checked around the point where this
array is filled. 
unless there is something iam missing

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH]configure: Default to clang for Android

[Carl Eugen Hoyos]

Hi!

I believe the Android documentation indicates that gcc will be removed
from ndk. Attached patch changes the default to "clang" for
--target-os=android.

Now with patch.

Please comment, Carl Eugen
From 9c63579a1c0538f3c5f3dd8189eaedf28e87ce49 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 7 Dec 2018 00:11:17 +0100
Subject: [PATCH] configure: Use "clang" as cc_default for Android.

---
 configure |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 642c13d..6488c63 100755
--- a/configure
+++ b/configure
@@ -4129,6 +4129,11 @@ if test -n "$cross_prefix"; then
 enable cross_compile
 fi
 
+set_default target_os
+if test "$target_os" = android; then
+cc_default="clang"
+fi
+
 ar_default="${cross_prefix}${ar_default}"
 cc_default="${cross_prefix}${cc_default}"
 cxx_default="${cross_prefix}${cxx_default}"
@@ -4145,7 +4150,7 @@ windres_default="${cross_prefix}${windres_default}"
 sysinclude_default="${sysroot}/usr/include"
 
 set_default arch cc cxx doxygen pkg_config ranlib strip sysinclude \
-target_exec target_os x86asmexe nvcc
+target_exec x86asmexe nvcc
 enabled cross_compile || host_cc_default=$cc
 set_default host_cc
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1

[James Almer]

On 12/6/2018 8:29 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch silences an ugly clang warning.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavc-cbs_vp9-Avoid-an-implicit-conversion-from-255-t.patch
> 
> From 20a643259b8e382bdfd759af78c36c3442c0affc Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 7 Dec 2018 00:26:40 +0100
> Subject: [PATCH] lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1.
> 
> Silences a warning with clang:
> libavcodec/cbs_vp9_syntax_template.c:220:17: warning: implicit conversion 
> from 'int' to 'int8_t' (aka 'signed char')
>   changes value from 255 to -1
> ---
>  libavcodec/cbs_vp9.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
> index c03ce98..95d147d 100644
> --- a/libavcodec/cbs_vp9.c
> +++ b/libavcodec/cbs_vp9.c
> @@ -310,7 +310,7 @@ static int cbs_vp9_write_le(CodedBitstreamContext *ctx, 
> PutBitContext *pbc,
>  if (prob_coded) \
>  xf(8, name.prob, prob, subs, __VA_ARGS__); \
>  else \
> -prob = 255; \
> +prob = -1; \

I think it may be better to make prob uint8_t instead, but Mark knows
best, so wait for him to comment.

>  current->name = prob; \
>  } while (0)
>  
> -- 1.7.10.4
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb

[Michael Niedermayer]

On Thu, Dec 06, 2018 at 10:42:24PM +0100, Carl Eugen Hoyos wrote:
> 2018-12-06 22:41 GMT+01:00, Carl Eugen Hoyos :
> > 2018-12-06 22:19 GMT+01:00, Michael Niedermayer :
> >> Fixes: test failure on powerpc
> >>
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  tests/fate/filter-video.mak | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> >> index 8bbdc04896..1042e96e54 100644
> >> --- a/tests/fate/filter-video.mak
> >> +++ b/tests/fate/filter-video.mak
> >> @@ -782,7 +782,7 @@ fate-filter-meta-4560-rotate0: CMD = framecrc -flags
> >> +bitexact -c:a aac_fixed -i
> >>  REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER
> >> METADATA_FILTER
> >>
> >>  FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) +=
> >> fate-filter-refcmp-psnr-rgb
> >> -fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.001
> >> +fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.002
> >
> > This is not needed on any ppc system where I tested recently including
> > Power7 Linux BE and Power8 Linux LE and aix BE.
> 
> This is of course not meant to stop this patch, I am just wondering how
> to reproduce.

Yes, let me start from mostly the begin

configure --assert-level=2 
--target-exec='qemu-201812/build/ppc64abi32-linux-user/qemu-ppc64abi32 -L 
/usr/powerpc-linux-gnu/' --cpu=power8 --samples=fate-suite/ --enable-gpl 
--cross-prefix=/usr/powerpc-linux-gnu/bin/ --cc='ccache 
powerpc-linux-gnu-gcc-4.8' --arch=ppc --target-os=linux --enable-cross-compile 
--disable-iconv --disable-pthreads

make -k  -j12  fate-filter-pp2 fate-filter-pp3 fate-wavpack-cuesheet  
fate-lossless-monkeysaudio-399 fate-eval fate-parseutils 
make: *** [fate-parseutils] Error 1
make: *** [fate-eval] Error 1
make: *** [fate-wavpack-cuesheet] Error 1
make: *** [fate-filter-pp3] Error 1
make: *** [fate-filter-pp2] Error 1

(fate-lossless-monkeysaudio-399 seems to have stoped failing, maybe because 
 --cpu is different than when i tested this previously)

Oddly adding --extra-cflags=-funsafe-math-optimizations
fixes 3 of these, only these remain
make: *** [fate-parseutils] Error 1
make: *** [fate-eval] Error 1
And not just that but the failures in fate-eval are significantly fewer

but it added these failures:
make: *** [fate-filter-tremolo] Error 1
make: *** [fate-filter-refcmp-psnr-rgb] Error 1

and slightly increasing the fuzz factor eliminated the second which is
what the patch does
I think the patch makes sense independant of this long story as it allows
one fate test to pass with some compiler flags

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

[FFmpeg-devel] [PATCH]lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1

[Carl Eugen Hoyos]

Hi!

Attached patch silences an ugly clang warning.

Please comment, Carl Eugen
From 20a643259b8e382bdfd759af78c36c3442c0affc Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 7 Dec 2018 00:26:40 +0100
Subject: [PATCH] lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1.

Silences a warning with clang:
libavcodec/cbs_vp9_syntax_template.c:220:17: warning: implicit conversion from 'int' to 'int8_t' (aka 'signed char')
  changes value from 255 to -1
---
 libavcodec/cbs_vp9.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index c03ce98..95d147d 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -310,7 +310,7 @@ static int cbs_vp9_write_le(CodedBitstreamContext *ctx, PutBitContext *pbc,
 if (prob_coded) \
 xf(8, name.prob, prob, subs, __VA_ARGS__); \
 else \
-prob = 255; \
+prob = -1; \
 current->name = prob; \
 } while (0)
 
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]configure: Default to clang for Android

[Carl Eugen Hoyos]

Hi!

I believe the Android documentation indicates that gcc will be removed
from ndk. Attached patch changes the default to "clang" for
--target-os=android.

Please comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavd/v4l2: Use ioctl(..., "int request" ) on Android

[Carl Eugen Hoyos]

Hi!

Attached patch fixes building with new Android toolchain, used to be a warning.

Please comment, Carl Eugen
From d366c948af086520bfb2a4048e76f8d117690776 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 6 Dec 2018 23:34:54 +0100
Subject: [PATCH] lavd/v4l2: Use "int request" as second parameter for ioctl()
 on Android.

Fixes build with new Android toolchain.
---
 libavdevice/v4l2.c |4 
 1 file changed, 4 insertions(+)

diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 10a0ff0..aa7c052 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -95,7 +95,11 @@ struct video_data {
 int (*open_f)(const char *file, int oflag, ...);
 int (*close_f)(int fd);
 int (*dup_f)(int fd);
+#ifdef __ANDROID__
+int (*ioctl_f)(int fd, int request, ...);
+#else
 int (*ioctl_f)(int fd, unsigned long int request, ...);
+#endif
 ssize_t (*read_f)(int fd, void *buffer, size_t n);
 void *(*mmap_f)(void *start, size_t length, int prot, int flags, int fd, int64_t offset);
 int (*munmap_f)(void *_start, size_t length);
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavc/decode: Initialize a return value on get_format() error

[Carl Eugen Hoyos]

Hi!

Attached patch silences a clang warning, please comment.

Carl Eugen
From 3b5fc2473235410920ca89c7d84654e2ce8fb29d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 6 Dec 2018 23:17:13 +0100
Subject: [PATCH] lavc/decode: Initialize return value for get_format()
 failure.

Silences a warning:
libavcodec/decode.c:1378:13: warning: variable 'ret' is used uninitialized whenever 'if' condition is true
---
 libavcodec/decode.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index c89c77c..a32ff2f 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1378,6 +1378,7 @@ int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
 if (i == n) {
 av_log(avctx, AV_LOG_ERROR, "Invalid return from get_format(): "
"%s not in possible list.\n", desc->name);
+ret = AV_PIX_FMT_NONE;
 break;
 }
 
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavf/matroskadec: Do not use strncat() to limit copying a one-char constant

[Carl Eugen Hoyos]

Hi!

Attached patch silences a new gcc warning, alternative would be to
disable the warning.

Please comment, Carl Eugen
From dd49cddc6fad136222d4a168301059d55fea4a4c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 6 Dec 2018 23:23:12 +0100
Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
 one-char constant.

Silences a warning:
libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1 equals source length [-Wstringop-overflow=]
 strncat(buf, ",", 1);
 ^~~~
---
 libavformat/matroskadec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2daa1db..df820b4 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3944,7 +3944,7 @@ static int webm_dash_manifest_cues(AVFormatContext *s, int64_t init_range)
 }
 end += ret;
 if (i != s->streams[0]->nb_index_entries - 1) {
-strncat(buf, ",", 1);
+strcat(buf, ",");
 end++;
 }
 }
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb

[Carl Eugen Hoyos]

2018-12-06 22:41 GMT+01:00, Carl Eugen Hoyos :
> 2018-12-06 22:19 GMT+01:00, Michael Niedermayer :
>> Fixes: test failure on powerpc
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  tests/fate/filter-video.mak | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
>> index 8bbdc04896..1042e96e54 100644
>> --- a/tests/fate/filter-video.mak
>> +++ b/tests/fate/filter-video.mak
>> @@ -782,7 +782,7 @@ fate-filter-meta-4560-rotate0: CMD = framecrc -flags
>> +bitexact -c:a aac_fixed -i
>>  REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER
>> METADATA_FILTER
>>
>>  FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) +=
>> fate-filter-refcmp-psnr-rgb
>> -fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.001
>> +fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.002
>
> This is not needed on any ppc system where I tested recently including
> Power7 Linux BE and Power8 Linux LE and aix BE.

This is of course not meant to stop this patch, I am just wondering how
to reproduce.

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

Re: [FFmpeg-devel] [PATCH] tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb

[Carl Eugen Hoyos]

2018-12-06 22:19 GMT+01:00, Michael Niedermayer :
> Fixes: test failure on powerpc
>
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/filter-video.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> index 8bbdc04896..1042e96e54 100644
> --- a/tests/fate/filter-video.mak
> +++ b/tests/fate/filter-video.mak
> @@ -782,7 +782,7 @@ fate-filter-meta-4560-rotate0: CMD = framecrc -flags
> +bitexact -c:a aac_fixed -i
>  REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER
> METADATA_FILTER
>
>  FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) +=
> fate-filter-refcmp-psnr-rgb
> -fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.001
> +fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.002

This is not needed on any ppc system where I tested recently including
Power7 Linux BE and Power8 Linux LE and aix BE.
I cannot test Apple G3 Linux atm.

The aix systems all only fail with afade:
--- tests/ref/fate/filter-afade-qsin2018-11-21 11:34:44.481910412 +
+++ tests/data/fate/filter-afade-qsin   2018-12-04 17:21:25.941910623 +
@@ -32,7 +32,7 @@
 0,  25600,  25600, 1024, 4096, 0x0c991178
 0,  26624,  26624, 1024, 4096, 0x7e69f3db
 0,  27648,  27648, 1024, 4096, 0x1c72f871
-0,  28672,  28672, 1024, 4096, 0xb51af385
+0,  28672,  28672, 1024, 4096, 0xabdcf383
 0,  29696,  29696, 1024, 4096, 0xc8cb0038
 0,  30720,  30720, 1024, 4096, 0xc3760a10
 0,  31744,  31744, 1024, 4096, 0x77baef51

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

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Carl Eugen Hoyos]

2018-11-26 13:24 GMT+01:00, Lauri Kasanen :
> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation"
> applied). Can anyone test BE?

> diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
> new file mode 100644
> index 000..853b587
> --- /dev/null
> +++ b/libswscale/ppc/swscale_vsx.c
> @@ -0,0 +1,164 @@
> +/*
> + * AltiVec-enhanced yuv2yuvX
> + *
> + * Copyright (C) 2004 Romain Dolbeau 
> + * based on the equivalent C code in swscale.c
> + *
> + * 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
> + */
> +
> +#include 
> +
> +#include "config.h"
> +#include "libswscale/swscale.h"
> +#include "libswscale/swscale_internal.h"
> +#include "libavutil/attributes.h"
> +#include "libavutil/cpu.h"
> +#include "yuv2rgb_altivec.h"
> +#include "libavutil/ppc/util_altivec.h"
> +

> +#if HAVE_VSX
> +#define vzero vec_splat_s32(0)
> +
> +#if !HAVE_BIGENDIAN

I changed these two if's and the ones on the bottom of the file into "if 1"
and tested on Power7 Linux BE, fate passes (and fails if I break the
function).
Problem is that HAVE_VSX is 0 on that system. How can this be fixed?

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

Re: [FFmpeg-devel] [PATCH] swscale/output: VSX-optimize nbps yuv2plane1

[Carl Eugen Hoyos]

2018-11-27 14:26 GMT+01:00, Lauri Kasanen :
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p9le \
> -f null -vframes 100 -v error -nostats -
>
> Speedups:
> yuv2plane1_9BE_vsx11.2042
> yuv2plane1_9LE_vsx11.156
> yuv2plane1_10BE_vsx   9.89428
> yuv2plane1_10LE_vsx   10.3637
> yuv2plane1_12BE_vsx   9.71923
> yuv2plane1_12LE_vsx   11.0404
> yuv2plane1_14BE_vsx   10.1763
> yuv2plane1_14LE_vsx   11.2728
>
> Fate passes, each format tested with an image to video conversion.
>
> Depends on "swscale/ppc: Move VSX-using code to its own file".

> Only tested on LE.

This patch breaks output on BE, tested with fate-v410enc and:
$ ffmpeg -i fate-suite/lena.pnm -pix_fmt yuv420p10 -vcodec ffv1 out.nut

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264dec: get field_order for typical frames

[Michael Niedermayer]

On Wed, Dec 05, 2018 at 08:38:41PM +0100, Paul B Mahol wrote:
> On 12/5/18, Michael Niedermayer  wrote:
> > On Wed, Dec 05, 2018 at 12:42:39PM +0100, Paul B Mahol wrote:
> >> This is normally set by parser but parsing is not always enabled.
> >>
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavcodec/h264dec.c | 18 ++
> >>  1 file changed, 18 insertions(+)
> >
> > breaks: fate-api-h264-slice
> > make: *** [fate-api-h264-slice] Error 139
> 
> How so? Do you know why?

thats what valgrind says:

==16920== Invalid read of size 4
==16920==at 0x51ED49: h264_decode_frame (h264dec.c:1022)
==16920==by 0x473A1C: decode_simple_internal (decode.c:433)
==16920==by 0x4746A3: decode_simple_receive_frame (decode.c:629)
==16920==by 0x47476E: decode_receive_frame_internal (decode.c:647)
==16920==by 0x4749C9: avcodec_send_packet (decode.c:705)
==16920==by 0x408ACA: decode (api-h264-slice-test.c:57)
==16920==by 0x409268: main (api-h264-slice-test.c:211)
==16920==  Address 0x488 is not stack'd, malloc'd or (recently) free'd
==16920== 
==16920== 
==16920== Process terminating with default action of signal 11 (SIGSEGV)
==16920==  Access not within mapped region at address 0x488
==16920==at 0x51ED49: h264_decode_frame (h264dec.c:1022)
==16920==by 0x473A1C: decode_simple_internal (decode.c:433)
==16920==by 0x4746A3: decode_simple_receive_frame (decode.c:629)
==16920==by 0x47476E: decode_receive_frame_internal (decode.c:647)
==16920==by 0x4749C9: avcodec_send_packet (decode.c:705)
==16920==by 0x408ACA: decode (api-h264-slice-test.c:57)
==16920==by 0x409268: main (api-h264-slice-test.c:211)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

[FFmpeg-devel] [PATCH] tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb

[Michael Niedermayer]

Fixes: test failure on powerpc

Signed-off-by: Michael Niedermayer 
---
 tests/fate/filter-video.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 8bbdc04896..1042e96e54 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -782,7 +782,7 @@ fate-filter-meta-4560-rotate0: CMD = framecrc -flags 
+bitexact -c:a aac_fixed -i
 REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
-fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.001
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.002
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
 fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p 0.0015
-- 
2.19.2

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

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Thilo Borgmann]

Hi again,

> I'm very sorry that it took me so long to send this to the list, finally.
> Since this is an everlasting topic for years, I wanted to deal
> thoroughly with it to have a chance to actually influence the situation.
> 
> Like in many previous years/sessions about FFmpeg development, the topic of
> hostility at the ML and IRC channel was discussed yet another time. There
> have been several voices at this year's session that are still unhappy
> with the current hostility in the FFmpeg community. So this point has been
> discussed in the audience for a while. However, there has also been a voice
> claiming that the current situation and regulation by our CoC is ok and 
> working.
> 
> According to my experience, these discussions lead to two ends. First,
> is considering the FFmpeg community to be a hostile environment shared by a
> majority of the community so that any further thoughts to try to change this 
> are
> valid or not? Second, assuming it is a majority that dislikes current 
> hostility,
> what to do about it to improve the situation?
> 
> Long ago, JB made a proposal to overcome this by getting a community committee
> to act upon hostile behavior in our environment and sanction the respective
> authors. This proposal has been brought up again regarding the question of how
> to proceed and like in the previous years, this proposal raised no rejections
> from anybody present (this and in the previous years).
> 
> In the end, the outcome of this VDDs FFmpeg session has been that I bring this
> proposal to the mailing list, finally. Therefore, I took the time to talk to
> several people not only about the proposal itself but also about the 
> experience
> of other communities having such a committee driven mechanism of dealing with
> CoC conflicts. From that the idea emerged to get an overview of the actual 
> community
> opinion of things is to conduct a simple survey about this question. So this 
> is
> exactly what I'd like to do next to giving the mere proposal.
> 
> The proposal of a community committee summarized:
> 
> - A committee is to be created consisting of community members that are voted
> into it
> - This committee can (upon request) sanction violations of our CoC by its 
> given
> powers
> - The committee is object to reelection every year
> 
> A more detailed possible implementation of the proposal is attached as a 
> patch to
> our developers documentation. The survey is done to get an idea of what the 
> community
> thinks about that matter and its proposed solution.
> 
> The survey shall be conducted for everyone to participate freely, so a simple
> thread on the mailing list would hardly be suitable and will most likely end 
> in
> endless discussions. To help with that, we've set up a survey that can be 
> done completely
> anonymously by sending out private tokens to all possible participants. Even 
> the survey
> admins cannot map given survey answers to a person/token.
> 
> Please note that this survey is _not_ meant to be a vote about the proposal. 
> It is to
> determine if we should actually have a refinement/vote on instantiating such a
> community committee - depending on the community's point of view.
> 
> I will start this survey and sending out tokens directly to every subscriber 
> of
> the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to
> participate in the survey, you can send me a private mail before that data to
> exclude your mail address from the participants lists. Afterwards you can 
> click
> the link in the mails to opt out of the survey yourself. The survey will end 
> on
> Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the 
> results
> of the survey here in this thread. 
> 
> I'd really appreciate participation in the survey from everyone. I'd like to 
> ask to file
> just one survey for every mail address you might have registered here - you 
> can opt-out
> or just ignore additional mails. I'm sorry for spam for everyone not reading 
> this thread.
> Many thanks to the KDE community and Lydia in particular for discussion and 
> supporting us
> with the survey infrastructure.


the survey ended on Monday, results are given below.

It has been criticized that the survey does not cover more detailed questions 
about the folks who do not think that the community is currently hostile. 
Several people thought about the survey design and yet that part was not 
covered. We might go for another survey on that part if people really want it - 
I guess we can run another one on the KDE infrastructure. Not to perceive the 
community to be hostile does not mean to reject a community committee (or 
changes to the CoC or other related actions), though. Also, that Q2 to Q4 only 
appeared if the previous answer was yes (in the sense of a hostile environment) 
has been criticized. Well, the assumption was that if you feel no to be your 
answer to a question, all follow-ups would not fit into that - why to ask if 

Re: [FFmpeg-devel] [PATCH] [HLS] Add LANGUAGE attribute to #EXT-X-MEDIA tag for audio-only variant streams.

[Philippe Symons]

Hello everyone,

I was hoping I could get some new feedback on my patch, so I have rebased
it to the latest commit on master.

Could someone take a look at it?

Thanks!

Kind regards,

Philippe Symons
From 210be575ae324b89f940ff62e2dc11eb0f4e02e3 Mon Sep 17 00:00:00 2001
From: Philippe Symons 
Date: Thu, 6 Dec 2018 21:57:24 +0100
Subject: [PATCH] avformat/hls,dash: add LANGUAGE attribute to #EXT-X-MEDIA tag
 for audio-only variant streams

Signed-off-by: Philippe Symons 
---
 libavformat/dashenc.c |  2 +-
 libavformat/hlsenc.c  | 23 ---
 libavformat/hlsplaylist.c |  6 +-
 libavformat/hlsplaylist.h |  2 +-
 4 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4d9b564a94..d121f6b04b 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -964,7 +964,7 @@ static int write_manifest(AVFormatContext *s, int final)
 if (os->segment_type != SEGMENT_TYPE_MP4)
 continue;
 get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, i);
-ff_hls_write_audio_rendition(c->m3u8_out, (char *)audio_group,
+ff_hls_write_audio_rendition(c->m3u8_out, (char *)audio_group, NULL,
  playlist_file, i, is_default);
 max_audio_bitrate = FFMAX(st->codecpar->bit_rate +
   os->muxer_overhead, max_audio_bitrate);
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 31ef0237ae..af7fe54aea 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1185,10 +1185,12 @@ static int create_master_playlist(AVFormatContext *s,
 HLSContext *hls = s->priv_data;
 VariantStream *vs, *temp_vs;
 AVStream *vid_st, *aud_st;
-AVDictionary *options = NULL;
+AVFormatContext *var_context;
+AVDictionary *options = NULL, *meta_dict = NULL;
+AVDictionaryEntry *lang_entry;
 unsigned int i, j;
 int m3u8_name_size, ret, bandwidth;
-char *m3u8_rel_name, *ccgroup;
+char *m3u8_rel_name, *ccgroup, *language;
 ClosedCaptionsStream *ccs;
 
 input_vs->m3u8_created = 1;
@@ -1228,11 +1230,26 @@ static int create_master_playlist(AVFormatContext *s,
 
 /* For audio only variant streams add #EXT-X-MEDIA tag with attributes*/
 for (i = 0; i < hls->nb_varstreams; i++) {
+var_context = vs->avf;
 vs = &(hls->var_streams[i]);
+language = NULL;
 
 if (vs->has_video || vs->has_subtitle || !vs->agroup)
 continue;
 
+/*
+ * Try to obtain the language code of the audio stream.
+ * -if available- it will be used to write the LANGUAGE
+ * attribute in the #EXT-X-MEDIA tag
+ */
+if (var_context && var_context->nb_streams > 0) {
+meta_dict = vs->streams[0]->metadata;
+lang_entry = av_dict_get(meta_dict, "language", NULL, 0);
+
+if (lang_entry)
+language = lang_entry->value;
+}
+
 m3u8_name_size = strlen(vs->m3u8_name) + 1;
 m3u8_rel_name = av_malloc(m3u8_name_size);
 if (!m3u8_rel_name) {
@@ -1247,7 +1264,7 @@ static int create_master_playlist(AVFormatContext *s,
 goto fail;
 }
 
-ff_hls_write_audio_rendition(hls->m3u8_out, vs->agroup, m3u8_rel_name, 0, 1);
+ff_hls_write_audio_rendition(hls->m3u8_out, vs->agroup, language, m3u8_rel_name, 0, 1);
 
 av_freep(_rel_name);
 }
diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index efcbff0009..ef2abedc83 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplaylist.c
@@ -35,12 +35,16 @@ void ff_hls_write_playlist_version(AVIOContext *out, int version) {
 avio_printf(out, "#EXT-X-VERSION:%d\n", version);
 }
 
-void ff_hls_write_audio_rendition(AVIOContext *out, char *agroup,
+void ff_hls_write_audio_rendition(AVIOContext *out, char *agroup, char* language,
   char *filename, int name_id, int is_default) {
 if (!out || !agroup || !filename)
 return;
 
 avio_printf(out, "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=\"group_%s\"", agroup);
+
+if (language)
+avio_printf(out, ",LANGUAGE=\"%s\"", language);
+
 avio_printf(out, ",NAME=\"audio_%d\",DEFAULT=%s,URI=\"%s\"\n", name_id,
  is_default ? "YES" : "NO", filename);
 }
diff --git a/libavformat/hlsplaylist.h b/libavformat/hlsplaylist.h
index 5054b01c8f..360ca0ae53 100644
--- a/libavformat/hlsplaylist.h
+++ b/libavformat/hlsplaylist.h
@@ -37,7 +37,7 @@ typedef enum {
 } PlaylistType;
 
 void ff_hls_write_playlist_version(AVIOContext *out, int version);
-void ff_hls_write_audio_rendition(AVIOContext *out, char *agroup,
+void ff_hls_write_audio_rendition(AVIOContext *out, char *agroup, char *language,
   char *filename, int name_id, int is_default);
 void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
 

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Paul B Mahol]

On 12/6/18, Baptiste Coudurier  wrote:
> On Thu, Dec 6, 2018 at 7:45 AM Paul B Mahol  wrote:
>
>> On 12/6/18, Baptiste Coudurier  wrote:
>> > Hi Paul,
>> >
>> > On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:
>> >
>> >> On 12/6/18, Baptiste Coudurier  wrote:
>> >> > Hi Paul
>> >> >
>> >> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
>> >> >
>> >> >> Signed-off-by: Paul B Mahol 
>> >> >> ---
>> >> >>  libavformat/mxfenc.c | 49
>> 
>> >> >>  1 file changed, 49 insertions(+)
>> >> >>
>> >> >> [...]
>> >> >>
>> >> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
>> >> >> AVPacket *pkt)
>> >> >> +{
>> >> >> +MXFContext *mxf = s->priv_data;
>> >> >> +MXFStreamContext *sc = st->priv_data;
>> >> >> +int i, profile;
>> >> >> +
>> >> >> +if (mxf->header_written)
>> >> >> +return 1;
>> >> >> +
>> >> >> +sc->codec_ul = NULL;
>> >> >> +profile = st->codecpar->profile;
>> >> >>
>> >> >
>> >> > We should fetch the profile from the bitstream.
>> >> >
>> >>
>> >> AFAIK profile is not stored in it.
>> >>
>> >
>> > Right. My thinking is how would this work going from MOV to MXF ? Or
>> would
>> > it work when encoding ?
>>
>> It works when encoding and stream copying, last time I tried.
>>
>
> After looking at the code, it seems like it would work assuming essence
> comes from MXF or MOV,
> raw would not work though but we can accept that.
>
> So I think the patch is fine, as well as the demuxer one, could you please
> apply the demuxer one first ?

It is listed before muxer anyway, muxer patch is last one.
Or there is something I'm missing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Michael Niedermayer]

On Tue, Dec 04, 2018 at 02:27:22PM +0100, Michael Niedermayer wrote:
> On Tue, Dec 04, 2018 at 11:00:34AM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Tuesday, 04 December 2018 at 08:10, Lauri Kasanen wrote:
> > > On Tue, 4 Dec 2018 03:21:30 +0100
> > > Michael Niedermayer  wrote:
> > > 
> > > > On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > > > > Also ping on "swscale/output: VSX-optimize
> > > > > nbps yuv2plane1".
> > > > 
> > > > This IIUC has not been tested on BE yet
> > > > 
> > > > my ppc emulation setup is a bit broken and my ppc hw ive not tried using
> > > > since years and it was not in good shape last i used it.
> > > > So i cant just quickly test this ...
> > > 
> > > Raptor offers free POWER9 VMs to open source projects. Since you're the
> > > leader of ffmpeg, if you asked, I'm sure they'd give one or two for
> > > ffmpeg build and fate testing.
> > > 
> > > Ref
> > > https://mobile.twitter.com/RaptorCompSys/status/1067018060777832449?p=v
> > > https://mobile.twitter.com/RaptorCompSys/status/1067029086273486848?p=v
> > > 
> > > "We offer free access to cloud VPS for libre software projects in
> > > partnership with @Integricloud, would that help?"
> > > 
> > > "Contact sa...@integricloud.com and tell them what you want to use a
> > > VPS or two for. They will generally grant access to the resources."
> > > 
> > > (I'm developing on a POWER8 VM intended for devs, but ordered a
> > > Blackbird from the cyber monday sale ;))
> > 
> > Red Hat also offers Power 8 VMs, both BE and LE, to open source projects:
> > http://research.redhat.com/powerlinux-openpower-development-hosting/
> 
> these are more suggestions than i expected :)
> but i just got cross build working again and i also just eliminated a
> mysterious ld.so related segfault
> ATM iam re rerunning fate with a freshly rebuilt qemu
> (the past one had an issue with altivec)

i have cross build with ppc and qemu partly working
but it appears gcc or something is just buggy
for example this:
#include 

main() {
float f = 0.0/0.0;
printf("%f\n", floor(f));
}

produces:
510423550381407695195061911147652317184.00

but if build with -O1 it produces this:
nan

thats with powerpc-linux-gnu-gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4

also
gcc -O1 behaves different from litterally listing all the options that -O1
is documented to turn on

the remaining issues are:
make: *** [fate-eval] Error 1
make: *** [fate-filter-tremolo] Error 1
make: *** [fate-filter-refcmp-psnr-rgb] Error 1
make: *** [fate-parseutils] Error 1

where eval and parseutils appear to be issues with non finite numbers
not sure iam missing something ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc.c: don't allow motion estimation out of range.

[Tomas Härdin]

ons 2018-12-05 klockan 21:21 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley 
> 
> The maximum allowable range for ZMBV motion estimation is [-64..63], since
> the dx,dy values are each stored in the upper 7 bits of a signed char.
> 
> (Previously, the range was capped in the code to 127, resulting in an
> effective range of [-127..126])
> 
> Also fix a range error in the zmbv_me() for-loops ('<' instead of '<='),
> which made the limit asymmetrical [-N..N-1], and also prevented it from
> reaching the blocks touching the bottom/right edges.
> The range is now more symmetrical [-N..N], although this requires separate
> range caps of 64 and 63 for negative and positive dx,dy.
> 
> Practically, this patch fixes graphical glitches e.g. when reencoding the
> Commander Keen sample video with me_range 65 or higher:
> 
> ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi

I'd expect this problem to pop up with -me_range 64 too, no?

I went over the patch, and it looks fine. But what's up with the xored
logic? It seems like it would compute xored always from the bottom-
right-most MV. The loop in zmbv_me() should probably have a temporary
xored and only output to *xored in if(tv < bv)..

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

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: Add general API for IO buffer synchronization.

[Andrey Semashev]

On 12/6/18 10:34 PM, Nicolas George wrote:

Andrey Semashev (2018-12-06):

Could you provide an example where ENOTSUP (i.e. the error code) would make
more sense for a sync operation, as opposed to AVIO_SYNC_NOT_SUPPORTED (i.e.
the success code)?


It is not a matter making more sense, both are semantically equivalent.
It is a matter of better matching the rest of the API.


I have used this API internally in an application for a few years, and I
never wanted to distinguish the "not supported" case from "success", let
alone specifically handle it as an error.


If you do not care that the sync was not done, then you did not need to
sync in the first place. Syncing is about guaranteeing the user that the
data is safe; if you ignore the information that it was not done, then
you are not guaranteeing it.


I do need sync - when it is supported by the underlying resource (e.g. a 
file). In that case, I care about it and I check for errors.


I do not care for the sync result if the underlying resource does not 
support the concept of syncing. In that case, I want to see a success 
code and treat the operation as a no-op.


With ENOTSUP, every call to avio_sync & co. I have would have to 
explicitly check for ENOTSUP and ignore it. I just don't see any benefit 
of this.

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

[FFmpeg-devel] [PATCH 7/7] avcodec/dpx: fix spotted code style issues

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index cb7a93473f..b1833ed9ef 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -69,8 +69,8 @@ static uint16_t read10in32_gray(const uint8_t **ptr, uint32_t 
*lbuf,
 return temp;
 }
 
-static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
-  int * n_datum, int is_big, int shift)
+static uint16_t read10in32(const uint8_t **ptr, uint32_t *lbuf,
+   int *n_datum, int is_big, int shift)
 {
 if (*n_datum)
 (*n_datum)--;
@@ -84,8 +84,8 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t * 
lbuf,
 return *lbuf & 0x3FF;
 }
 
-static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf,
-  int * n_datum, int is_big)
+static uint16_t read12in32(const uint8_t **ptr, uint32_t *lbuf,
+   int *n_datum, int is_big)
 {
 if (*n_datum)
 (*n_datum)--;
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 5/7] avcodec/dpx: improve decoding of 10 bit gray images

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index cfe601..ed17bf3858 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -51,6 +51,24 @@ static unsigned int read32(const uint8_t **ptr, int is_big)
 return temp;
 }
 
+static uint16_t read10in32_gray(const uint8_t **ptr, uint32_t *lbuf,
+int *n_datum, int is_big, int shift)
+{
+uint16_t temp;
+
+if (*n_datum)
+(*n_datum)--;
+else {
+*lbuf = read32(ptr, is_big);
+*n_datum = 2;
+}
+
+temp = *lbuf >> shift & 0x3FF;
+*lbuf = *lbuf >> 10;
+
+return temp;
+}
+
 static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
   int * n_datum, int is_big, int shift)
 {
@@ -385,13 +403,17 @@ static int decode_frame(AVCodecContext *avctx,
 (uint16_t*)ptr[1],
 (uint16_t*)ptr[2],
 (uint16_t*)ptr[3]};
-int shift = packing == 1 ? 22 : 20;
+int shift = elements > 1 ? packing == 1 ? 22 : 20 : packing == 1 ? 
2 : 0;
 for (y = 0; y < avctx->width; y++) {
 if (elements >= 3)
 *dst[2]++ = read10in32(, ,
_datum, endian, shift);
-*dst[0]++ = read10in32(, ,
-   _datum, endian, shift);
+if (elements == 1)
+*dst[0]++ = read10in32_gray(, ,
+_datum, endian, shift);
+else
+*dst[0]++ = read10in32(, ,
+   _datum, endian, shift);
 if (elements >= 2)
 *dst[1]++ = read10in32(, ,
_datum, endian, shift);
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 6/7] avcodec/dpx: add support for special encoding

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index ed17bf3858..cb7a93473f 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -422,7 +422,8 @@ static int decode_frame(AVCodecContext *avctx,
 read10in32(, ,
_datum, endian, shift);
 }
-n_datum = 0;
+if (memcmp(input_device, "Scanity", 7))
+n_datum = 0;
 for (i = 0; i < elements; i++)
 ptr[i] += p->linesize[i];
 }
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 2/7] avcodec/dpx: parse image creator

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 0297287938..bc1115b6ba 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -19,6 +19,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avstring.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/intfloat.h"
 #include "libavutil/imgutils.h"
@@ -107,6 +108,7 @@ static int decode_frame(AVCodecContext *avctx,
 AVFrame *const p = data;
 uint8_t *ptr[AV_NUM_DATA_POINTERS];
 uint32_t header_version, version = 0;
+char creator[101];
 
 unsigned int offset;
 int magic_num, endian;
@@ -360,6 +362,10 @@ static int decode_frame(AVCodecContext *avctx,
 if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
 return ret;
 
+av_strlcpy(creator, avpkt->data + 160, 100);
+creator[100] = '\0';
+av_dict_set(>metadata, "Creator", creator, 0);
+
 // Move pointer to offset from start of file
 buf =  avpkt->data + offset;
 
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 3/7] avcodec/dpx: parse input device name

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index bc1115b6ba..31d8331068 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -109,6 +109,7 @@ static int decode_frame(AVCodecContext *avctx,
 uint8_t *ptr[AV_NUM_DATA_POINTERS];
 uint32_t header_version, version = 0;
 char creator[101];
+char input_device[33];
 
 unsigned int offset;
 int magic_num, endian;
@@ -366,6 +367,10 @@ static int decode_frame(AVCodecContext *avctx,
 creator[100] = '\0';
 av_dict_set(>metadata, "Creator", creator, 0);
 
+av_strlcpy(input_device, avpkt->data + 1556, 32);
+input_device[32] = '\0';
+av_dict_set(>metadata, "Input Device", input_device, 0);
+
 // Move pointer to offset from start of file
 buf =  avpkt->data + offset;
 
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 4/7] avcodec/dpx: add support for another gray10 variant

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 31d8331068..cfe601 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -323,6 +323,7 @@ static int decode_frame(AVCodecContext *avctx,
 case 51121:
 avctx->pix_fmt = AV_PIX_FMT_GBRAP12;
 break;
+case 6100:
 case 6101:
 avctx->pix_fmt = AV_PIX_FMT_GRAY10;
 break;
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/7] avcodec/dpx: check version of format header too

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 538a1b9943..0297287938 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -106,6 +106,7 @@ static int decode_frame(AVCodecContext *avctx,
 int buf_size   = avpkt->size;
 AVFrame *const p = data;
 uint8_t *ptr[AV_NUM_DATA_POINTERS];
+uint32_t header_version, version = 0;
 
 unsigned int offset;
 int magic_num, endian;
@@ -141,6 +142,15 @@ static int decode_frame(AVCodecContext *avctx,
 return AVERROR_INVALIDDATA;
 }
 
+header_version = read32(, 0);
+if (header_version == MKTAG('V','1','.','0'))
+version = 1;
+if (header_version == MKTAG('V','2','.','0'))
+version = 2;
+if (!version)
+av_log(avctx, AV_LOG_WARNING, "Unknown header format version %s.\n",
+   av_fourcc2str(header_version));
+
 // Check encryption
 buf = avpkt->data + 660;
 ret = read32(, endian);
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: Add general API for IO buffer synchronization.

[Nicolas George]

Andrey Semashev (2018-12-06):
> Could you provide an example where ENOTSUP (i.e. the error code) would make
> more sense for a sync operation, as opposed to AVIO_SYNC_NOT_SUPPORTED (i.e.
> the success code)?

It is not a matter making more sense, both are semantically equivalent.
It is a matter of better matching the rest of the API.

> I have used this API internally in an application for a few years, and I
> never wanted to distinguish the "not supported" case from "success", let
> alone specifically handle it as an error.

If you do not care that the sync was not done, then you did not need to
sync in the first place. Syncing is about guaranteeing the user that the
data is safe; if you ignore the information that it was not done, then
you are not guaranteeing it.

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 v2 1/2] lavf: Add general API for IO buffer synchronization.

[Andrey Semashev]

On 12/6/18 9:29 PM, Nicolas George wrote:

Andrey Semashev (2018-12-04):

This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.

The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op.
Users can distinguish this case from the successful completion by the result
code AVIO_SYNC_NOT_SUPPORTED, which is also considered a successful result
(i.e. >0).
---
  libavformat/avio.c|  7 +++
  libavformat/avio.h| 33 +
  libavformat/aviobuf.c | 17 +
  libavformat/url.h | 13 +
  4 files changed, 70 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..662d4ed971 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
  return size;
  }
  
+int ffurl_sync(URLContext *h)

+{
+if (h->prot->url_sync)
+return h->prot->url_sync(h);
+return AVIO_SYNC_NOT_SUPPORTED;
+}
+
  int ffurl_get_file_handle(URLContext *h)
  {
  if (!h || !h->prot || !h->prot->url_get_file_handle)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..403ee0fc7b 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -349,6 +349,15 @@ typedef struct AVIOContext {
   * Try to buffer at least this amount of data before flushing it
   */
  int min_packet_size;
+
+/**
+ * A callback for synchronizing buffers with the media state.
+ *
+ * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
+ * the operation is not supported and ignored, an AVERROR < 0
+ * on error.
+ */
+int (*sync)(void *opaque);
  } AVIOContext;
  
  /**

@@ -586,6 +595,30 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
av_printf_format(2, 3);
   */
  void avio_flush(AVIOContext *s);
  



+/**
+ * Indicates that the sync operation has been carried out successfully
+ */
+#define AVIO_SYNC_SUCCESS 0
+
+/**
+ * Indicates that the sync operation is not supported by the underlying
+ * resource and has been ignored
+ */
+#define AVIO_SYNC_NOT_SUPPORTED 1


I must say, I really do not like this version at all. ENOTSUP feels like
a much more consistent solution.


Could you provide an example where ENOTSUP (i.e. the error code) would 
make more sense for a sync operation, as opposed to 
AVIO_SYNC_NOT_SUPPORTED (i.e. the success code)?


I have used this API internally in an application for a few years, and I 
never wanted to distinguish the "not supported" case from "success", let 
alone specifically handle it as an error. I have further patches to 
extend this functionality in ffmpeg and the intention there is similar - 
in no case I want the "not supported" case to be an error.

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

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

[Baptiste Coudurier]

On Wed, Dec 5, 2018 at 3:17 PM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul
> >
> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/mxfdec.c | 12 
> >>  1 file changed, 12 insertions(+)
> >>
> >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >> index f49890e140..abb030b1a4 100644
> >> --- a/libavformat/mxfdec.c
> >> +++ b/libavformat/mxfdec.c
> >> @@ -2432,6 +2432,18 @@ static int
> mxf_parse_structural_metadata(MXFContext
> >> *mxf)
> >>  default:
> >>  av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout
> >> type: %d\n", descriptor->frame_layout);
> >>  }
> >> +
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
> >> +switch (descriptor->essence_codec_ul[14]) {
> >> +case 1: st->codecpar->profile =
> FF_PROFILE_PRORES_PROXY;
> >>   break;
> >> +case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;
> >>break;
> >> +case 3: st->codecpar->profile =
> >> FF_PROFILE_PRORES_STANDARD; break;
> >> +case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;
> >>break;
> >> +case 5: st->codecpar->profile = FF_PROFILE_PRORES_;
> >>break;
> >> +case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;
> >>break;
> >> +}
> >> +}
> >> +
> >
> >
> >  I'm not sure about that, we don't do it for any other codec. IMHO it
> > should be in the decoder/parser.
>
> profile is not stored in bitstream AFAIK so only way it is set is via
> demuxer via codec_tag.
> MXF does not use codec_tags. So only this way is available.
>

Seems like decoder sets it from MOV fourcc, so I think it should be fine.

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Baptiste Coudurier]

On Thu, Dec 6, 2018 at 7:45 AM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul,
> >
> > On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:
> >
> >> On 12/6/18, Baptiste Coudurier  wrote:
> >> > Hi Paul
> >> >
> >> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >> >
> >> >> Signed-off-by: Paul B Mahol 
> >> >> ---
> >> >>  libavformat/mxfenc.c | 49
> 
> >> >>  1 file changed, 49 insertions(+)
> >> >>
> >> >> [...]
> >> >>
> >> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> >> >> AVPacket *pkt)
> >> >> +{
> >> >> +MXFContext *mxf = s->priv_data;
> >> >> +MXFStreamContext *sc = st->priv_data;
> >> >> +int i, profile;
> >> >> +
> >> >> +if (mxf->header_written)
> >> >> +return 1;
> >> >> +
> >> >> +sc->codec_ul = NULL;
> >> >> +profile = st->codecpar->profile;
> >> >>
> >> >
> >> > We should fetch the profile from the bitstream.
> >> >
> >>
> >> AFAIK profile is not stored in it.
> >>
> >
> > Right. My thinking is how would this work going from MOV to MXF ? Or
> would
> > it work when encoding ?
>
> It works when encoding and stream copying, last time I tried.
>

After looking at the code, it seems like it would work assuming essence
comes from MXF or MOV,
raw would not work though but we can accept that.

So I think the patch is fine, as well as the demuxer one, could you please
apply the demuxer one first ?

Thanks!

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

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

[Carl Eugen Hoyos]

2018-12-06 10:33 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 22:56 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 22:42 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
> Fixes #4409.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dpx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 538a1b9943..04b55ffadf 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext
> *avctx,
>  read10in32(, ,
> _datum, endian, shift);
>  }
> -n_datum = 0;
> +if (packing != 2)
> +n_datum = 0;
>  for (i = 0; i < elements; i++)
>  ptr[i] += p->linesize[i];
>  }

 This breaks decoding the output of the following command:
 $ gm convert converted_image_gets_skewed.dpx -define
 dpx:packing-method=b out.dpx
>>>
>>> I do not trust that app, its full of bugs.
>>
>> What is the reference for dpx in your opinion?
>
> ImageTragick certainly not.

 That's not ImageMagick above.
>>>
>>> Then what is it?
>>
>> GraphicsMagick which claims to be the dpx reference (afaiu).
>>
 The sample in question looks better with attached poc, breaks
 four component sample, also attaching other samples that
 show the difference.
>>>
>>> Attacking crappy patches and non-compliant files that
>>
>> Do you know of a 10bit gray dpx sample that does not look
>> better with my "crappy" patch?
>>
>>> conflict and do not follow specification is not productive.
>>
>> GraphicsMagick claims differently.
>
> How sample from ticket #4409 looks with that tool?

 It fails differently than with your patch.

>>>
>>> I have dpx specification,
>>
>>> and my patch above show correct output for that file.
>>
>> I am not so sure: Look at the right border with and without my change.
>>
>>> So I do not know what we are discussing about.
>>>
>>> Find actual program that correctly displays sample from above
>>> ticket and that we can talk again.
>>
>> It displays correctly with my change, I am not sure if the file
>> conforms to the dpx specification.
>
> The files you posted does not conform

What is wrong about them?

> B files looks like using no-packing mode.

The only difference between "B" and "L" files is the endianness.
Two files are lsb-padded, two are msb-padded ("a" and "b").

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

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: Add general API for IO buffer synchronization.

[Nicolas George]

Andrey Semashev (2018-12-04):
> This commit adds a new set of functions to avio and url subsystems, which
> allow users to invoke IO buffer synchronization with the underlying media.
> The most obvious target for this extension if the filesystem streams. Invoking
> IO synchronization allows user applications to ensure that all written content
> has reached the filesystem on the media and can be observed by other 
> processes.
> 
> The public API for this is avio_sync() function, which can be called on
> AVIOContext. The internal, lower layer API is ffurl_sync(), which works
> directly on the underlying URLContext. URLContext backends can add support for
> this new API by setting the sync handler to the new url_sync member of
> URLProtocol. When no handler is set then the sync operation is a no-op.
> Users can distinguish this case from the successful completion by the result
> code AVIO_SYNC_NOT_SUPPORTED, which is also considered a successful result
> (i.e. >0).
> ---
>  libavformat/avio.c|  7 +++
>  libavformat/avio.h| 33 +
>  libavformat/aviobuf.c | 17 +
>  libavformat/url.h | 13 +
>  4 files changed, 70 insertions(+)
> 
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 663789ec02..662d4ed971 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
>  return size;
>  }
>  
> +int ffurl_sync(URLContext *h)
> +{
> +if (h->prot->url_sync)
> +return h->prot->url_sync(h);
> +return AVIO_SYNC_NOT_SUPPORTED;
> +}
> +
>  int ffurl_get_file_handle(URLContext *h)
>  {
>  if (!h || !h->prot || !h->prot->url_get_file_handle)
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 75912ce6be..403ee0fc7b 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -349,6 +349,15 @@ typedef struct AVIOContext {
>   * Try to buffer at least this amount of data before flushing it
>   */
>  int min_packet_size;
> +
> +/**
> + * A callback for synchronizing buffers with the media state.
> + *
> + * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
> + * the operation is not supported and ignored, an AVERROR < 0
> + * on error.
> + */
> +int (*sync)(void *opaque);
>  } AVIOContext;
>  
>  /**
> @@ -586,6 +595,30 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
> av_printf_format(2, 3);
>   */
>  void avio_flush(AVIOContext *s);
>  

> +/**
> + * Indicates that the sync operation has been carried out successfully
> + */
> +#define AVIO_SYNC_SUCCESS 0
> +
> +/**
> + * Indicates that the sync operation is not supported by the underlying
> + * resource and has been ignored
> + */
> +#define AVIO_SYNC_NOT_SUPPORTED 1

I must say, I really do not like this version at all. ENOTSUP feels like
a much more consistent solution.

> +
> +/**
> + * Flush internal buffers and ensure the synchronized state of the
> + * resource associated with the context s. This call may be expensive.
> + * Not all resources support syncing, this operation is a no-op
> + * if sync is not supported or needed.
> + * This function can only be used if s was opened by avio_open().
> + *
> + * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
> + * the operation is a not supported and ignored, an AVERROR < 0
> + * on error.
> + */
> +int avio_sync(AVIOContext *s);
> +
>  /**
>   * Read size bytes from AVIOContext into buf.
>   * @return number of bytes read or AVERROR
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 5a33f82950..c2aca7c6af 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -243,6 +243,14 @@ void avio_flush(AVIOContext *s)
>  avio_seek(s, seekback, SEEK_CUR);
>  }
>  
> +int avio_sync(AVIOContext *s)
> +{
> +avio_flush(s);
> +if (s->sync)
> +return s->sync(s->opaque);
> +return AVIO_SYNC_NOT_SUPPORTED;
> +}
> +
>  int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
>  {
>  int64_t offset1;
> @@ -978,6 +986,12 @@ static int64_t io_read_seek(void *opaque, int 
> stream_index, int64_t timestamp, i
>  return internal->h->prot->url_read_seek(internal->h, stream_index, 
> timestamp, flags);
>  }
>  
> +static int io_sync(void *opaque)
> +{
> +AVIOInternal *internal = opaque;
> +return ffurl_sync(internal->h);
> +}
> +
>  int ffio_fdopen(AVIOContext **s, URLContext *h)
>  {
>  AVIOInternal *internal = NULL;
> @@ -1026,6 +1040,9 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
>  
>  if (h->prot->url_read_seek)
>  (*s)->seekable |= AVIO_SEEKABLE_TIME;
> +
> +if (h->prot->url_sync)
> +(*s)->sync = io_sync;
>  }
>  (*s)->short_seek_get = io_short_seek;
>  (*s)->av_class = _avio_class;
> diff --git a/libavformat/url.h b/libavformat/url.h
> index 4750bfff82..d032b45b65 100644
> --- a/libavformat/url.h
> +++ 

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dpx: improve decoding support for 10 bit depth

[Carl Eugen Hoyos]

2018-12-06 11:56 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dpx.c | 36 
>  1 file changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 0297287938..84894abda5 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -50,6 +50,24 @@ static unsigned int read32(const uint8_t **ptr, int
> is_big)
>  return temp;
>  }
>
> +static uint16_t read10in32_gray(const uint8_t **ptr, uint32_t *lbuf,
> +int *n_datum, int is_big, int shift)
> +{
> +uint16_t temp;
> +
> +if (*n_datum)
> +(*n_datum)--;
> +else {
> +*lbuf = read32(ptr, is_big);
> +*n_datum = 2;
> +}
> +

> +temp = *lbuf >> shift & 0x3FF;
> +*lbuf = *lbuf >> 10;
> +
> +return temp;

Isn't my code simpler?
One variable less, same number of operations iirc.


> +}
> +
>  static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
>int * n_datum, int is_big, int shift)
>  {
> @@ -107,6 +125,7 @@ static int decode_frame(AVCodecContext *avctx,
>  AVFrame *const p = data;
>  uint8_t *ptr[AV_NUM_DATA_POINTERS];
>  uint32_t header_version, version = 0;
> +const uint8_t *creator;
>
>  unsigned int offset;
>  int magic_num, endian;
> @@ -151,6 +170,9 @@ static int decode_frame(AVCodecContext *avctx,
>  av_log(avctx, AV_LOG_WARNING, "Unknown header format version
> %s.\n",
> av_fourcc2str(header_version));
>

> +buf = avpkt->data + 160;
> +creator = buf;

I wonder why you split the version but not the creator
and why the metadata isn't set.

> +
>  // Check encryption
>  buf = avpkt->data + 660;
>  ret = read32(, endian);
> @@ -320,6 +342,7 @@ static int decode_frame(AVCodecContext *avctx,
>  case 51121:
>  avctx->pix_fmt = AV_PIX_FMT_GBRAP12;

>  break;
> +case 6100:

Looks unrelated.

>  case 6101:
>  avctx->pix_fmt = AV_PIX_FMT_GRAY10;
>  break;
> @@ -373,13 +396,17 @@ static int decode_frame(AVCodecContext *avctx,
>  (uint16_t*)ptr[1],
>  (uint16_t*)ptr[2],
>  (uint16_t*)ptr[3]};
> -int shift = packing == 1 ? 22 : 20;
> +int shift = elements > 1 ? packing == 1 ? 22 : 20 : packing ==
> 1 ? 2 : 0;

Wouldn't it be simpler to add "20" in read10in32()?

>  for (y = 0; y < avctx->width; y++) {
>  if (elements >= 3)
>  *dst[2]++ = read10in32(, ,
> _datum, endian, shift);
> -*dst[0]++ = read10in32(, ,
> -   _datum, endian, shift);
> +if (elements == 1)
> +*dst[0]++ = read10in32_gray(, ,
> +_datum, endian, shift);
> +else
> +*dst[0]++ = read10in32(, ,
> +   _datum, endian, shift);
>  if (elements >= 2)
>  *dst[1]++ = read10in32(, ,
> _datum, endian, shift);
> @@ -388,7 +415,8 @@ static int decode_frame(AVCodecContext *avctx,
>  read10in32(, ,
> _datum, endian, shift);
>  }

> -n_datum = 0;
> +if (version != 2 || !memcmp(creator, "GraphicsMagick", 14))

This looks wrong to me:
Where in the specification does it say that this depends on the version?

> +n_datum = 0;
>  for (i = 0; i < elements; i++)
>  ptr[i] += p->linesize[i];
>  }

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/xpmdec: Allow more colours per character

[Carl Eugen Hoyos]

Hi!

Attached patch fixes decoding the files attached to ticket #6234.

Please comment, Carl Eugen
From b0a5a2d675e1fa054a9297bcdb0e46239573cd9d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 6 Dec 2018 19:09:56 +0100
Subject: [PATCH] lavc/xpmdec: Allow more colours per character.

Fixes ticket #6234.
---
 libavcodec/xpmdec.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 03172e4..1aa40c0 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -290,10 +290,10 @@ static int ascii2index(const uint8_t *cpixel, int cpp)
 int n = 0, m = 1, i;
 
 for (i = 0; i < cpp; i++) {
-if (*p < ' ' || *p > '~')
+if (*p < ' ' || *p > 0xfe)
 return AVERROR_INVALIDDATA;
 n += (*p++ - ' ') * m;
-m *= 95;
+m *= 220;
 }
 return n;
 }
@@ -346,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext *avctx, void *data,
 
 size = 1;
 for (i = 0; i < cpp; i++)
-size *= 95;
+size *= 220;
 
 if (ncolors <= 0 || ncolors > size) {
 av_log(avctx, AV_LOG_ERROR, "invalid number of colors: %d\n", ncolors);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Vasile Toncu]

Hi,

Since this patch is passing all the current tests, all the modification
required by Thomas were implemented and from our point of view it satisfies
all requirements for adding the double license to the filter, please
approve this patch for integration. Also, there are two more patches
blocked at the moment. This two patches add new features and improvements
for the filter.

Thank you. Regards.

On Tue, Oct 16, 2018 at 6:40 PM Vasile Toncu 
wrote:

> Hello,
>
> Still Baptiste Coudurier and Michael Zucchi could not be reached, however
> since the old GPL tinterlace was replaced with a new LGPL implementation
> aren't we on the second course of action recommended by Nicolas George? And
> by that means can we change the license of this implementation without the
> approval of the original contributors whose code was removed?
> Maybe someone else can have a look at the new implementation and provide
> the necessary feedback in order to merge this patch and unblock the
> development of the patches with new functionalities.
>
> Thank you.
> Best regards.
>
>
>
> On Mon, Sep 17, 2018 at 8:28 AM, Vasile Toncu 
> wrote:
>
>> Hello,
>>
>> Thank you Thomas for the reviews and support!
>>
>> The proposed actions, by Nicolas George in
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/223072.html,
>> were taken.
>>
>> >* Can one simply change the tinterlace from GPL to LGPL?
>> *
>> Of course not. There are two non-simple courses of action to achieve it:
>>
>> - Get the approval of all copyright holders. It has been done in the
>>   past for other filters.
>>
>> - Remove the GPL tinterlace and at the same time add a new LGPL filter
>>   that does the same thing and is also called tinterlace.
>>
>>
>> Only two contributors approved until now, Thomas Mundt and Stefano
>> Sebatini, while Baptiste Coudurier and Michael Zucchi could not be reached.
>> Also, the new implementation supports all the features from the old
>> tinterlace and conditionally (at compile time) the same ASM optimizations
>> are used, but only if CONFIG_GPL is defined.
>>
>> Is there any way we can proceed with this patch?
>>
>> Best regards.
>>
>>
>> On Fri, Aug 17, 2018 at 5:24 PM, Thomas Mundt  wrote:
>>
>>> Hi,
>>>
>>> 2018-08-16 13:56 GMT+02:00 Vasile Toncu :
>>>
>>> > Hi,
>>> >
>>> > Thank you for the additional testing effort.
>>> > Fixed the issue.
>>> >
>>> >
>>> thanks, the patch looks good to me as far as I can judge.
>>> It´s up to more experienced developers now to permit the license change.
>>> Can anybody please have a look at this.
>>>
>>> Regards,
>>> Thomas
>>> ___
>>> 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/4] avformat/mxfenc: allow muxing prores

[Paul B Mahol]

On 12/6/18, Baptiste Coudurier  wrote:
> Hi Paul,
>
> On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:
>
>> On 12/6/18, Baptiste Coudurier  wrote:
>> > Hi Paul
>> >
>> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
>> >
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavformat/mxfenc.c | 49 
>> >>  1 file changed, 49 insertions(+)
>> >>
>> >> [...]
>> >>
>> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
>> >> AVPacket *pkt)
>> >> +{
>> >> +MXFContext *mxf = s->priv_data;
>> >> +MXFStreamContext *sc = st->priv_data;
>> >> +int i, profile;
>> >> +
>> >> +if (mxf->header_written)
>> >> +return 1;
>> >> +
>> >> +sc->codec_ul = NULL;
>> >> +profile = st->codecpar->profile;
>> >>
>> >
>> > We should fetch the profile from the bitstream.
>> >
>>
>> AFAIK profile is not stored in it.
>>
>
> Right. My thinking is how would this work going from MOV to MXF ? Or would
> it work when encoding ?

It works when encoding and stream copying, last time I tried.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Baptiste Coudurier]

Hi Paul,

On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul
> >
> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/mxfenc.c | 49 
> >>  1 file changed, 49 insertions(+)
> >>
> >> [...]
> >>
> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> >> AVPacket *pkt)
> >> +{
> >> +MXFContext *mxf = s->priv_data;
> >> +MXFStreamContext *sc = st->priv_data;
> >> +int i, profile;
> >> +
> >> +if (mxf->header_written)
> >> +return 1;
> >> +
> >> +sc->codec_ul = NULL;
> >> +profile = st->codecpar->profile;
> >>
> >
> > We should fetch the profile from the bitstream.
> >
>
> AFAIK profile is not stored in it.
>

Right. My thinking is how would this work going from MOV to MXF ? Or would
it work when encoding ?

Thanks!

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

[FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found

[Paul B Mahol]

This recovers state with #7374 linked sample.

Work funded by Open Broadcast Systems.

Signed-off-by: Paul B Mahol 
---
 libavcodec/h264_refs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index eaf965e43d..5645a203a7 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
 }
 break;
 case MMCO_RESET:
+default:
 while (h->short_ref_count) {
 remove_short(h, h->short_ref[0]->frame_num, 0);
 }
@@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
 for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
 h->last_pocs[j] = INT_MIN;
 break;
-default: assert(0);
 }
 }
 
-- 
2.17.1

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

[FFmpeg-devel] [PATCH] avformat/avio: don't download data twice

[Adrian Trzciński]

Like I wrote in #7592 in case of data muxed in a way, that video and audio
packets for the same ptses are more than 1 sec distant (so when
ff_configure_buffers_for_index changes size of AVIOContext buffers to 2 *
biggest_distance_between_data_for_1_sec_pts) FFmpeg fetches the same data
twice from the server. This is because in fill_buffer in aviobuf.c when we
need data audio from pts x that we don't currently have in buffer, we drop
the whole buffer and download new range. But afterward, we need video from
pts x, which was in buffer already (before seek caused by audio), so we
drop buffer again and seek to this position.

The patch changes the mechanism of data reading in aviobuf.c/fill_buffer.
If data aren't in buffer new mechanism still leaves one time_unit of data
in a buffer for further seeks to the same pts but in a different stream (it
needs to be within one time_unit, it is calculated in
ff_configure_buffers_for_index).

-- 

Pozdrawiam / Regards
Adrian Trzciński
From 71cadd60a2f71d2d39bd7999e080c206291b55da Mon Sep 17 00:00:00 2001
From: Adrian Trzcinski 
Date: Tue, 4 Dec 2018 19:00:22 +0100
Subject: [PATCH] avformat/avio: fill_buffer drops less data

Signed-off-by: Adrian Trzcinski 
---
 libavformat/avio.h|  1 +
 libavformat/aviobuf.c | 21 -
 libavformat/utils.c   |  1 +
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..c44e1c7e9c 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -225,6 +225,7 @@ typedef struct AVIOContext {
  */
 unsigned char *buffer;  /**< Start of the buffer. */
 int buffer_size;/**< Maximum buffer size */
+int time_units_in_buffer; /**< Number of time units in buffer */
 unsigned char *buf_ptr; /**< Current position in the buffer */
 unsigned char *buf_end; /**< End of the data, may be less than
  buffer+buffer_size if the read function returned
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..afccc61491 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -92,6 +92,7 @@ int ffio_init_context(AVIOContext *s,
 s->buffer  = buffer;
 s->orig_buffer_size =
 s->buffer_size = buffer_size;
+s->time_units_in_buffer = 0;
 s->buf_ptr = buffer;
 s->buf_ptr_max = buffer;
 s->opaque  = opaque;
@@ -550,9 +551,19 @@ static void fill_buffer(AVIOContext *s)
 {
 int max_buffer_size = s->max_packet_size ?
   s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size < s->buffer_size ?
-  s->buf_end : s->buffer;
-int len = s->buffer_size - (dst - s->buffer);
+int need_erase = !(s->buf_end - s->buffer + max_buffer_size < s->buffer_size);
+uint8_t *dst = need_erase ? s->buffer : s->buf_end;
+int len;
+
+if (need_erase && s->time_units_in_buffer > 1) {
+const int bytes_in_time_unit = (s->buf_end - s->buffer) / s->time_units_in_buffer;
+const int offset = bytes_in_time_unit * (s->time_units_in_buffer - 1);
+memcpy(s->buffer, s->buffer + offset, bytes_in_time_unit);
+dst = s->buf_end = s->buffer + bytes_in_time_unit;
+s->buf_ptr = s->buf_ptr - s->buffer < offset ? s->buffer : s->buf_ptr - offset;
+}
+
+len = s->buffer_size - (dst - s->buffer);
 
 /* can't fill the buffer without read_packet, just set EOF if appropriate */
 if (!s->read_packet && s->buf_ptr >= s->buf_end)
@@ -562,7 +573,7 @@ static void fill_buffer(AVIOContext *s)
 if (s->eof_reached)
 return;
 
-if (s->update_checksum && dst == s->buffer) {
+if (s->update_checksum && need_erase) {
 if (s->buf_end > s->checksum_ptr)
 s->checksum = s->update_checksum(s->checksum, s->checksum_ptr,
  s->buf_end - s->checksum_ptr);
@@ -571,7 +582,7 @@ static void fill_buffer(AVIOContext *s)
 
 /* make buffer smaller in case it ended up large after probing */
 if (s->read_packet && s->orig_buffer_size && s->buffer_size > s->orig_buffer_size) {
-if (dst == s->buffer && s->buf_ptr != dst) {
+if (need_erase  && s->buf_ptr != dst) {
 int ret = ffio_set_buf_size(s, s->orig_buffer_size);
 if (ret < 0)
 av_log(s, AV_LOG_WARNING, "Failed to decrease buffer size\n");
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 93e588ee1e..62deaa710b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2138,6 +2138,7 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance)
 av_log(s, AV_LOG_VERBOSE, "Reconfiguring buffers to size %"PRId64"\n", pos_delta);
 ffio_set_buf_size(s->pb, pos_delta);
 s->pb->short_seek_threshold = FFMAX(s->pb->short_seek_threshold, pos_delta/2);
+s->pb->time_units_in_buffer = 2;
 }
 
 if 

Re: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with error return

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Thursday, December 6, 2018 7:19 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with error
> return
> 
> bs->FrameType is not set in MSDK in some cases (mjpeg encode for
> bs->example),
> and assert on a value coming from an external library is not proper.
> 
> Add default type check for bs->FrameType, and return invalid data error in
> function ff_qsv_encode to avoid using uninitialized value.
> 
> Fix #7593.
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: Add default bs->FrameType check.
> 
>  libavcodec/qsvenc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 7f4592f878..917344b60c 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1337,8 +1337,10 @@ int ff_qsv_encode(AVCodecContext *avctx,
> QSVEncContext *q,
>  pict_type = AV_PICTURE_TYPE_P;
>  else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType
> & MFX_FRAMETYPE_xB)
>  pict_type = AV_PICTURE_TYPE_B;
> +else if (bs->FrameType == MFX_FRAMETYPE_UNKNOWN)

Unknown frame type has potential risk and would better give a waring log 
message here.

> +pict_type = AV_PICTURE_TYPE_NONE;
>  else
> -av_assert0(!"Uninitialized pict_type!");
> +return AVERROR_INVALIDDATA;

If frame type is MFX_FRAMETYPE_IDR or MFX_FRAMETYPE_xIDR, will go here but this 
is not invalid data.
So pict_tpye should be set to AV_PICTURE_TYPE_I in this case I believe.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH, v2] lavc/qsvenc: replace assert with error return

[Linjie Fu]

bs->FrameType is not set in MSDK in some cases (mjpeg encode for example),
and assert on a value coming from an external library is not proper.

Add default type check for bs->FrameType, and return invalid data error in 
function
ff_qsv_encode to avoid using uninitialized value.

Fix #7593.

Signed-off-by: Linjie Fu 
---
[v2]: Add default bs->FrameType check.

 libavcodec/qsvenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7f4592f878..917344b60c 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1337,8 +1337,10 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
*q,
 pict_type = AV_PICTURE_TYPE_P;
 else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType & 
MFX_FRAMETYPE_xB)
 pict_type = AV_PICTURE_TYPE_B;
+else if (bs->FrameType == MFX_FRAMETYPE_UNKNOWN)
+pict_type = AV_PICTURE_TYPE_NONE;
 else
-av_assert0(!"Uninitialized pict_type!");
+return AVERROR_INVALIDDATA;
 
 #if FF_API_CODED_FRAME
 FF_DISABLE_DEPRECATION_WARNINGS
-- 
2.17.1

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

Re: [FFmpeg-devel] Patch to add avcintra-flavor option from x264

[Steinar Apalnes]

You're right. I tested the avcintra-flavor option a while ago in ffmpeg
with latests x264 (which included the avcintra-flavor option) and it did
not work. I'm not sure why that was but now it does work. So, ignore this
patch. Thanks! :-)

-steinar

Den tor. 6. des. 2018 kl. 11:37 skrev Gyan Doshi :

> On 06-12-2018 02:26 PM, Steinar Apalnes wrote:
> > This patch adds the new "avcintra-flavor" to the -x264opts. The
> > avcintra-flavor option in x264 adds the possibility to create the Sony
> XAVC
> > flavor of avcintra. Default is Panasonic.
> >
> > Tested OK.
> >
> > -steinar
>
> Why is this needed? All key=value pairs added through -x264opts and
> -x264-params are evaluated by x264 and not ffmpeg. Indeed, I just tested
> it with avcintra-flavour=sony and x264 accepts it - x264 complains if I
> mangle the key or value string.
>
> Also, your patch adds an AVOption and a new member to the wrapper's
> context struct but does not convey the value to x4->params. I don't see
> how it has any effect.
>
>
> Gyan
> ___
> 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 2/2] avcodec/dpx: improve decoding support for 10 bit depth

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 0297287938..84894abda5 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -50,6 +50,24 @@ static unsigned int read32(const uint8_t **ptr, int is_big)
 return temp;
 }
 
+static uint16_t read10in32_gray(const uint8_t **ptr, uint32_t *lbuf,
+int *n_datum, int is_big, int shift)
+{
+uint16_t temp;
+
+if (*n_datum)
+(*n_datum)--;
+else {
+*lbuf = read32(ptr, is_big);
+*n_datum = 2;
+}
+
+temp = *lbuf >> shift & 0x3FF;
+*lbuf = *lbuf >> 10;
+
+return temp;
+}
+
 static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
   int * n_datum, int is_big, int shift)
 {
@@ -107,6 +125,7 @@ static int decode_frame(AVCodecContext *avctx,
 AVFrame *const p = data;
 uint8_t *ptr[AV_NUM_DATA_POINTERS];
 uint32_t header_version, version = 0;
+const uint8_t *creator;
 
 unsigned int offset;
 int magic_num, endian;
@@ -151,6 +170,9 @@ static int decode_frame(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_WARNING, "Unknown header format version %s.\n",
av_fourcc2str(header_version));
 
+buf = avpkt->data + 160;
+creator = buf;
+
 // Check encryption
 buf = avpkt->data + 660;
 ret = read32(, endian);
@@ -320,6 +342,7 @@ static int decode_frame(AVCodecContext *avctx,
 case 51121:
 avctx->pix_fmt = AV_PIX_FMT_GBRAP12;
 break;
+case 6100:
 case 6101:
 avctx->pix_fmt = AV_PIX_FMT_GRAY10;
 break;
@@ -373,13 +396,17 @@ static int decode_frame(AVCodecContext *avctx,
 (uint16_t*)ptr[1],
 (uint16_t*)ptr[2],
 (uint16_t*)ptr[3]};
-int shift = packing == 1 ? 22 : 20;
+int shift = elements > 1 ? packing == 1 ? 22 : 20 : packing == 1 ? 
2 : 0;
 for (y = 0; y < avctx->width; y++) {
 if (elements >= 3)
 *dst[2]++ = read10in32(, ,
_datum, endian, shift);
-*dst[0]++ = read10in32(, ,
-   _datum, endian, shift);
+if (elements == 1)
+*dst[0]++ = read10in32_gray(, ,
+_datum, endian, shift);
+else
+*dst[0]++ = read10in32(, ,
+   _datum, endian, shift);
 if (elements >= 2)
 *dst[1]++ = read10in32(, ,
_datum, endian, shift);
@@ -388,7 +415,8 @@ static int decode_frame(AVCodecContext *avctx,
 read10in32(, ,
_datum, endian, shift);
 }
-n_datum = 0;
+if (version != 2 || !memcmp(creator, "GraphicsMagick", 14))
+n_datum = 0;
 for (i = 0; i < elements; i++)
 ptr[i] += p->linesize[i];
 }
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/dpx: check version of format header too

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 538a1b9943..0297287938 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -106,6 +106,7 @@ static int decode_frame(AVCodecContext *avctx,
 int buf_size   = avpkt->size;
 AVFrame *const p = data;
 uint8_t *ptr[AV_NUM_DATA_POINTERS];
+uint32_t header_version, version = 0;
 
 unsigned int offset;
 int magic_num, endian;
@@ -141,6 +142,15 @@ static int decode_frame(AVCodecContext *avctx,
 return AVERROR_INVALIDDATA;
 }
 
+header_version = read32(, 0);
+if (header_version == MKTAG('V','1','.','0'))
+version = 1;
+if (header_version == MKTAG('V','2','.','0'))
+version = 2;
+if (!version)
+av_log(avctx, AV_LOG_WARNING, "Unknown header format version %s.\n",
+   av_fourcc2str(header_version));
+
 // Check encryption
 buf = avpkt->data + 660;
 ret = read32(, endian);
-- 
2.17.1

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

[FFmpeg-devel] [PATCH V1 0/2] VA-API misc change

[Jun Zhao]

V1: - Fix slices number warning message dump when setting > driver constraints
- Add mode option to scale_vaapi

Jun Zhao (2):
  lavfi/vf_scale_vaapi: add scaling mode setting support.
  lavc/vaapi_encode: fix slices number check.

 libavcodec/vaapi_encode.c|2 +-
 libavfilter/vf_scale_vaapi.c |   33 ++---
 2 files changed, 31 insertions(+), 4 deletions(-)

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

[FFmpeg-devel] [PATCH V1 1/2] lavfi/vf_scale_vaapi: add scaling mode setting support.

[Jun Zhao]

before this change, scale_vaapi hard coding the scaling mode, add a
new option "mode" to setting the scaling mode, it can be use to change
scaling algorithm for performance/quality trade off.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_scale_vaapi.c |   33 ++---
 1 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index d6529d5..ad222e6 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -35,10 +35,26 @@ typedef struct ScaleVAAPIContext {
 
 char *output_format_string;
 
+int   mode;
+
 char *w_expr;  // width expression string
 char *h_expr;  // height expression string
 } ScaleVAAPIContext;
 
+static const char *scale_vaapi_mode_name(int mode)
+{
+switch (mode) {
+#define D(name) case VA_FILTER_SCALING_ ## name: return #name
+D(DEFAULT);
+D(FAST);
+D(HQ);
+#undef D
+default:
+return "Invalid";
+}
+}
+
+
 static int scale_vaapi_config_output(AVFilterLink *outlink)
 {
 AVFilterLink *inlink = outlink->src->inputs[0];
@@ -70,6 +86,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 AVFilterContext *avctx   = inlink->dst;
 AVFilterLink *outlink= avctx->outputs[0];
 VAAPIVPPContext *vpp_ctx = avctx->priv;
+ScaleVAAPIContext *ctx   = avctx->priv;
 AVFrame *output_frame= NULL;
 VASurfaceID input_surface, output_surface;
 VAProcPipelineParameterBuffer params;
@@ -119,7 +136,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 params.output_color_standard = params.surface_color_standard;
 
 params.pipeline_flags = 0;
-params.filter_flags = VA_FILTER_SCALING_HQ;
+params.filter_flags |= ctx->mode;
 
 err = ff_vaapi_vpp_render_picture(avctx, , output_surface);
 if (err < 0)
@@ -131,9 +148,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 
 av_frame_free(_frame);
 
-av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
+av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64"), mode: 
%s.\n",
av_get_pix_fmt_name(output_frame->format),
-   output_frame->width, output_frame->height, output_frame->pts);
+   output_frame->width, output_frame->height, output_frame->pts,
+   scale_vaapi_mode_name(ctx->mode));
 
 return ff_filter_frame(outlink, output_frame);
 
@@ -174,6 +192,15 @@ static const AVOption scale_vaapi_options[] = {
   OFFSET(h_expr), AV_OPT_TYPE_STRING, {.str = "ih"}, .flags = FLAGS },
 { "format", "Output video format (software format of hardware frames)",
   OFFSET(output_format_string), AV_OPT_TYPE_STRING, .flags = FLAGS },
+{ "mode", "Scaling mode",
+  OFFSET(mode), AV_OPT_TYPE_INT, { .i64 = VA_FILTER_SCALING_HQ },
+  0, VA_FILTER_SCALING_NL_ANAMORPHIC, FLAGS, "mode" },
+{ "default", "Use the default (depend on the driver) scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_DEFAULT }, 0, 0, FLAGS, 
"mode" },
+{ "fast", "Use fast scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_FAST }, 0, 0, FLAGS, 
"mode" },
+{ "hq", "Use high quality scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_HQ }, 0, 0, FLAGS,  
"mode" },
 { NULL },
 };
 
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V1 2/2] lavc/vaapi_encode: fix slices number check.

[Jun Zhao]

Fix slice number check logic. Only when the user setting slices
number more than the driver constraints dump the rounded up warning
message.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index eda8a36..3c8a33d 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1572,7 +1572,7 @@ static av_cold int 
vaapi_encode_init_slice_structure(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-if (ctx->nb_slices > avctx->slices) {
+if (ctx->nb_slices < avctx->slices) {
 av_log(avctx, AV_LOG_WARNING, "Slice count rounded up to "
"%d (from %d) due to driver constraints on slice "
"structure.\n", ctx->nb_slices, avctx->slices);
-- 
1.7.1

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

Re: [FFmpeg-devel] Patch to add avcintra-flavor option from x264

[Gyan Doshi]

On 06-12-2018 02:26 PM, Steinar Apalnes wrote:

This patch adds the new "avcintra-flavor" to the -x264opts. The
avcintra-flavor option in x264 adds the possibility to create the Sony XAVC
flavor of avcintra. Default is Panasonic.

Tested OK.

-steinar


Why is this needed? All key=value pairs added through -x264opts and 
-x264-params are evaluated by x264 and not ffmpeg. Indeed, I just tested 
it with avcintra-flavour=sony and x264 accepts it - x264 complains if I 
mangle the key or value string.


Also, your patch adds an AVOption and a new member to the wrapper's 
context struct but does not convey the value to x4->params. I don't see 
how it has any effect.



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

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func

[Sun, Jing A]

Hi Mark,

This patch is not trying to support VFR. Some frames, after which are just 
produced, could be considered as not needed by theirs producer and will get 
skipped in the encoding process. And in my opinion the existing timing 
information is not sufficient to support the case.

Regards,
SUN, Jing


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Wednesday, December 5, 2018 7:50 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip 
func

On 04/12/2018 01:46, Sun, Jing A wrote:
> Hi Mark,
> 
> Is there any issue that I need to fix for this patch please? 

See comments in the message you quoted below?  I think the most important point 
is that the existing timing information appears to contain all the information 
you want for VFR, so you probably shouldn't need the ad-hoc side-data type.

- Mark


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
> Of Sun, Jing A
> Sent: Friday, November 23, 2018 5:37 PM
> To: FFmpeg development discussions and patches 
> 
> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add 
> frame-skip func
> 
> Hi Mark,
> 
> In some cases, that is useful. For example, an online content distributer, 
> who keeps encoding the captured video frames by ffmpeg and sending them out. 
> At times, there is no update of source, which makes one or several captured 
> source frames are exactly the same as the last one, and the distributer wants 
> to just skip such frames, without stopping the encoding process.
> 
> Regards,
> SUN, Jing
> 
> 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
> Of Mark Thompson
> Sent: Tuesday, November 20, 2018 4:07 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add 
> frame-skip func
> 
> On 19/11/18 09:04, Jing SUN wrote:
>> frame-skip is required to implement network bandwidth self-adaptive 
>> vaapi encoding.
>> To make a frame skipped, allocate its frame side data of 
>> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.
> 
> So if I'm reading this correctly the idea is to implement partial VFR by 
> having a special new side-data type which indicates where frames would have 
> been had the input actually matched the configured CFR behaviour?
> 
> Why is the user meant to create these special frames?  It seems to me that 
> the existing method of looking at the timestamps would be a better way to 
> find any gaps.
> 
> (Or, even better, add timestamps to VAAPI so that it can support VFR 
> in a sensible way rather than adding hacks like this to allow partial 
> VFR with weird constraints.)
> 
>> Signed-off-by: Jing SUN 
>> ---
>>  libavcodec/vaapi_encode.c | 142 
>> --
>>  libavcodec/vaapi_encode.h |   5 ++
>>  libavutil/frame.c |   1 +
>>  libavutil/frame.h |   5 ++
>>  4 files changed, 149 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c 
>> index 2fe8501..a401d61 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -23,6 +23,7 @@
>>  #include "libavutil/common.h"
>>  #include "libavutil/log.h"
>>  #include "libavutil/pixdesc.h"
>> +#include "libavutil/intreadwrite.h"
>>  
>>  #include "vaapi_encode.h"
>>  #include "avcodec.h"
>> @@ -103,6 +104,47 @@ static int 
>> vaapi_encode_make_param_buffer(AVCodecContext *avctx,
>>  return 0;
>>  }
>>  
>> +static int vaapi_encode_check_if_skip(AVCodecContext *avctx,
>> +  VAAPIEncodePicture *pic) {
>> +AVFrameSideData *fside = NULL;
>> +VAAPIEncodeContext *ctx = avctx->priv_data;
>> +VAAPIEncodePicture *cur = NULL;
>> +int i = 0;
>> +
>> +if (!pic || !pic->input_image)
>> +return AVERROR(EINVAL);
>> +
>> +fside = av_frame_get_side_data(pic->input_image, 
>> AV_FRAME_DATA_SKIP_FRAME);
>> +if (fside)
>> +pic->skipped_flag = AV_RL8(fside->data);
>> +else
>> +pic->skipped_flag = 0;
>> +
>> +if (0 == pic->skipped_flag)
>> +return 0;
>> +
>> +if ((pic->type == PICTURE_TYPE_IDR) || (pic->type == PICTURE_TYPE_I)) {
>> +av_log(avctx, AV_LOG_INFO, "Can't skip IDR/I pic 
>> %"PRId64"/%"PRId64".\n",
>> +   pic->display_order, pic->encode_order);
>> +pic->skipped_flag = 0;
>> +return 0;
>> +}
>> +
>> +for (cur = ctx->pic_start; cur; cur = cur->next) {
>> +for (i=0; i < cur->nb_refs; ++i) {
>> +if (cur->refs[i] == pic) {
>> +av_log(avctx, AV_LOG_INFO, "Can't skip ref pic 
>> %"PRId64"/%"PRId64".\n",
>> +   pic->display_order, pic->encode_order);
>> +pic->skipped_flag = 0;
>> +return 0;
>> +}
>> +}
>> +}
>> +
>> +return 

Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

[Tobias Rapp]

On 06.12.2018 08:28, Karthick J wrote:

---
  doc/muxers.texi  |  4 
  libavformat/movenc.c | 12 ++--
  libavformat/movenc.h |  1 +
  3 files changed, 15 insertions(+), 2 deletions(-)
  
[...]


Looks OK now, no more comments from my side.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

[Paul B Mahol]

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 22:56 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
 Fixes #4409.

 Signed-off-by: Paul B Mahol 
 ---
  libavcodec/dpx.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
 index 538a1b9943..04b55ffadf 100644
 --- a/libavcodec/dpx.c
 +++ b/libavcodec/dpx.c
 @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext
 *avctx,
  read10in32(, ,
 _datum, endian, shift);
  }
 -n_datum = 0;
 +if (packing != 2)
 +n_datum = 0;
  for (i = 0; i < elements; i++)
  ptr[i] += p->linesize[i];
  }
>>>
>>> This breaks decoding the output of the following command:
>>> $ gm convert converted_image_gets_skewed.dpx -define
>>> dpx:packing-method=b out.dpx
>>
>> I do not trust that app, its full of bugs.
>
> What is the reference for dpx in your opinion?

 ImageTragick certainly not.
>>>
>>> That's not ImageMagick above.
>>
>> Then what is it?
>
> GraphicsMagick which claims to be the dpx reference (afaiu).
>
>>> The sample in question looks better with attached poc, breaks
>>> four component sample, also attaching other samples that
>>> show the difference.
>>
>> Attacking crappy patches and non-compliant files that
>
> Do you know of a 10bit gray dpx sample that does not look
> better with my "crappy" patch?
>
>> conflict and do not follow specification is not productive.
>
> GraphicsMagick claims differently.

 How sample from ticket #4409 looks with that tool?
>>>
>>> It fails differently than with your patch.
>>>
>>
>> I have dpx specification,
>
>> and my patch above show correct output for that file.
>
> I am not so sure: Look at the right border with and without my change.
>
>> So I do not know what we are discussing about.
>>
>> Find actual program that correctly displays sample from above
>> ticket and that we can talk again.
>
> It displays correctly with my change, I am not sure if the file
> conforms to the dpx specification.

The files you posted does not conform, B files looks like using no-packing mode.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/movenc: Added an option to disable SIDX atom

[Andrey Semashev]

On 12/6/18 8:07 AM, Karthick J wrote:

---
  doc/muxers.texi  |  4 
  libavformat/movenc.c | 12 ++--
  libavformat/movenc.h |  1 +
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
  pair for each track, making it easier to separate tracks.
  
  This option is implicitly set when writing ismv (Smooth Streaming) files.

+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored.
  @item -movflags faststart
  Run a second pass moving the index (moov atom) to the beginning of the file.
  This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..2f7755bf69 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
  { "frag_discont", "Signal that the next fragment is discontinuous from earlier 
ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "delay_moov", "Delay writing the initial moov until the first fragment is cut, or 
until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
+{ "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "write_colr", "Write colr atom (Experimental, may be renamed or changed, do not use 
from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "use_metadata_tags", "Use mdta atom for metadata.", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
  mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
  moof_size = ffio_close_null_buf(avio_buf);
  
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & FF_MOV_FLAG_GLOBAL_SIDX))

+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_SKIP_SIDX)))
  mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
  
  if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)

@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
   * the next fragment. This means the cts of the first sample must
   * be the same in all fragments, unless end_pts was updated by
   * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||
  mov->mode == MODE_ISM)
  pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
  } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
  s->flags &= ~AVFMT_FLAG_AUTO_BSF;
  }
  
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & FF_MOV_FLAG_SKIP_SIDX) {


s->flags here should be mov->flags as well.


+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+mov->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+
  if (mov->flags & FF_MOV_FLAG_FASTSTART) {
  mov->reserved_moov_size = -1;
  }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
  #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
  #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
  #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
  
  int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
  



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

Re: [FFmpeg-devel] [PATCH v3] avformat/movenc: Added an option to disable SIDX atom

[Andrey Semashev]

On 12/6/18 12:20 PM, Andrey Semashev wrote:

On 12/6/18 8:07 AM, Karthick J wrote:

---
  doc/muxers.texi  |  4 
  libavformat/movenc.c | 12 ++--
  libavformat/movenc.h |  1 +
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the 
muxer writes one moof/mdat

  pair for each track, making it easier to separate tracks.
  This option is implicitly set when writing ismv (Smooth Streaming) 
files.

+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is 
high,

+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored.
  @item -movflags faststart
  Run a second pass moving the index (moov atom) to the beginning of 
the file.
  This operation can take a while, and will not work in various 
situations such

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..2f7755bf69 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
  { "frag_discont", "Signal that the next fragment is 
discontinuous from earlier ones", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_FRAG_DISCONT}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "delay_moov", "Delay writing the initial moov until the first 
fragment is cut, or until the first fragment flush", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "global_sidx", "Write a global sidx index at the start of the 
file", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+    { "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, 
{.i64 = FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "write_colr", "Write colr atom (Experimental, may be renamed 
or changed, do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
  { "write_gama", "Write deprecated gama atom", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,

  mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
  moof_size = ffio_close_null_buf(avio_buf);
-    if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))

+    if (mov->flags & FF_MOV_FLAG_DASH &&
+    !(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX)))
  mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + 
mdat_size);
  if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < 
MOV_PRFT_NB)
@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, 
AVPacket *pkt)
   * the next fragment. This means the cts of the first 
sample must
   * be the same in all fragments, unless end_pts was 
updated by

   * the packet causing the fragment to be written. */
-    if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||

+    if ((mov->flags & FF_MOV_FLAG_DASH &&
+    !(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||

  mov->mode == MODE_ISM)
  pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;

  } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
  s->flags &= ~AVFMT_FLAG_AUTO_BSF;
  }
+    if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & 
FF_MOV_FLAG_SKIP_SIDX) {


s->flags here should be mov->flags as well.


Sorry, didn't read the later messages.

+    av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring 
skip_sidx option\n");

+    mov->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+    }
+
  if (mov->flags & FF_MOV_FLAG_FASTSTART) {
  mov->reserved_moov_size = -1;
  }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
  #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
  #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
  #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
  int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] Patch to add avcintra-flavor option from x264

[Steinar Apalnes]

This patch adds the new "avcintra-flavor" to the -x264opts. The
avcintra-flavor option in x264 adds the possibility to create the Sony XAVC
flavor of avcintra. Default is Panasonic.

Tested OK.

-steinar


0001-add avcintra-flavor option.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel