Re: [FFmpeg-devel] Patch for Reproducing Issue 7827

2019-04-03 Thread myp...@gmail.com 
On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner  wrote:
>
> This patch does not improve or fix something instead it is meant for
> easily reproducing issue 7827 (as requested, cf.
> https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
> how to produce a patch by "git format-patch" instead it was made by "git
> diff > muxing.patch".
>
A lot of docs for this type question, this is a refer
https://www.x.org/wiki/Development/Documentation/SubmittingPatches/

You can used the command like:

git format-patch HEAD~1  # create a patch for the last commit

And I think "git diff > muxing.patch"  will drop the commit message,
it's a part of the patch for review, Tks.
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 08da98e574..75766f497b 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -49,6 +49,8 @@
 
 #define SCALE_FLAGS SWS_BICUBIC
 
+#define MUX_MATROSKA_FLAC
+
 // a wrapper around a single output AVStream
 typedef struct OutputStream {
 AVStream *st;
@@ -600,7 +602,12 @@ int main(int argc, char **argv)
 encode_video = 1;
 }
 if (fmt->audio_codec != AV_CODEC_ID_NONE) {
-add_stream(&audio_st, oc, &audio_codec, fmt->audio_codec);
+#if defined (MUX_MATROSKA_FLAC) // [
+  if (!strcmp("matroska",fmt->name))
+add_stream(&audio_st, oc, &audio_codec, AV_CODEC_ID_FLAC);
+  else
+#endif // ]
+  add_stream(&audio_st, oc, &audio_codec, fmt->audio_codec);
 have_audio = 1;
 encode_audio = 1;
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI documentation

2019-04-03 Thread Guo, Yejun 


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 8:18 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI
> documentation
> 
> Clarify and add examples for the behaviour of the quantisation offset,
> and define how multiple ranges should be handled.
> ---
>  libavutil/frame.h | 46 ++
>  1 file changed, 34 insertions(+), 12 deletions(-)

Maybe we can first refine and push the first two patches?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2] lavf/flvdec: Fix AMF NUMBER type to metadata lost precision

2019-04-03 Thread myp...@gmail.com 
On Thu, Apr 4, 2019 at 5:21 AM Michael Niedermayer
 wrote:
>
> On Thu, Mar 28, 2019 at 09:23:29PM +0800, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > Use %.12g replace %.f when save AMF NUMBER(double) type to
> > metadata. And update fate ref.
> >
> > before this fix, we get FLV metadata like:
> >
> >  Metadata:
> > lasttimestamp   : 113
> > lastkeyframetimestamp: 112
> >
> > after this fix:
> >
> >  Metadata:
> > lasttimestamp   : 113.005
> > lastkeyframetimestamp: 111.678
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/flvdec.c  |2 +-
> >  tests/ref/fate/flv-add_keyframe_index |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index 445d58d..12bfd4b 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -649,7 +649,7 @@ static int amf_parse_object(AVFormatContext *s, 
> > AVStream *astream,
> > sizeof(str_val));
> >  av_dict_set(&s->metadata, key, str_val, 0);
> >  } else if (amf_type == AMF_DATA_TYPE_NUMBER) {
> > -snprintf(str_val, sizeof(str_val), "%.f", num_val);
> > +snprintf(str_val, sizeof(str_val), "%.12g", num_val);
> >  av_dict_set(&s->metadata, key, str_val, 0);
> >  } else if (amf_type == AMF_DATA_TYPE_STRING) {
> >  av_dict_set(&s->metadata, key, str_val, 0);
> > diff --git a/tests/ref/fate/flv-add_keyframe_index 
> > b/tests/ref/fate/flv-add_keyframe_index
> > index 1c4da65..ce3809e 100644
> > --- a/tests/ref/fate/flv-add_keyframe_index
> > +++ b/tests/ref/fate/flv-add_keyframe_index
> > @@ -7,6 +7,6 @@ canSeekToEnd=true
> >  datasize=629776
> >  videosize=629381
> >  audiosize=0
> > -lasttimestamp=20
> > +lasttimestamp=19.8571428571
>
> does every platform we support produce the same number here ?
> if not then make fate would break
> its a lot of digits after the decimal point, floats are not exact ...

%g flag characters for snprintf is part of C 90 standand, so  I think
it's ok if the platform with C 90 standand suppoted.

For log digits after the decimal point, how about  change from %.12g
to %.6g? Any other suggestion?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlylI7AACgkQYR7HhwQLD6uA0gCgk2yOM8TwH8T6oLhoU+20CnRT
XbEAnAuIClxs4buySSU6USaIhAxeqNuV
=tDZ7
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Patch for Reproducing Issue 7827

2019-04-03 Thread Peter Belkner 
This patch does not improve or fix something instead it is meant for 
easily reproducing issue 7827 (as requested, cf. 
https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know 
how to produce a patch by "git format-patch" instead it was made by "git 
diff > muxing.patch".


diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 08da98e574..75766f497b 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -49,6 +49,8 @@
 
 #define SCALE_FLAGS SWS_BICUBIC
 
+#define MUX_MATROSKA_FLAC
+
 // a wrapper around a single output AVStream
 typedef struct OutputStream {
 AVStream *st;
@@ -600,7 +602,12 @@ int main(int argc, char **argv)
 encode_video = 1;
 }
 if (fmt->audio_codec != AV_CODEC_ID_NONE) {
-add_stream(&audio_st, oc, &audio_codec, fmt->audio_codec);
+#if defined (MUX_MATROSKA_FLAC) // [
+  if (!strcmp("matroska",fmt->name))
+add_stream(&audio_st, oc, &audio_codec, AV_CODEC_ID_FLAC);
+  else
+#endif // ]
+  add_stream(&audio_st, oc, &audio_codec, fmt->audio_codec);
 have_audio = 1;
 encode_audio = 1;
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

2019-04-03 Thread Fu, Linjie 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Thursday, April 4, 2019 06:38
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC 2/2] lavc/vaapi_decode: find exact
> va_profile for HEVC_REXT
> 
> On Wed, Apr 03, 2019 at 12:10:22PM +0800, Linjie Fu wrote:
> > Use the profile constraint flags to determine the exact va_profile for
> > HEVC_REXT.
> >
> > Directly cast PTLCommon to H265RawProfileTierLevel, and use
> ff_h265_get_profile
> > to get the exact profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: use constraint flags to determine the exact profile, expose the
> > codec-specific stuff at the beginning.
> > [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
> > convenience? The members in PTLCommon should be strictly matched in
> > H265RawProfileTierLevel.
> >
> >  libavcodec/vaapi_decode.c | 74 +++--
> --
> >  1 file changed, 59 insertions(+), 15 deletions(-)
> 
> breaks build:
> 
> CClibavcodec/vaapi_decode.o
> libavcodec/vaapi_decode.c: In function ‘vaapi_decode_find_exact_profile’:
> libavcodec/vaapi_decode.c:421:16: error: ‘VAProfileHEVCMain422_10’
> undeclared (first use in this function)
>  return VAProfileHEVCMain422_10;
> ^
> libavcodec/vaapi_decode.c:421:16: note: each undeclared identifier is
> reported only once for each function it appears in
> libavcodec/vaapi_decode.c:423:16: error: ‘VAProfileHEVCMain444’
> undeclared (first use in this function)
>  return VAProfileHEVCMain444;
> ^
> libavcodec/vaapi_decode.c:425:16: error: ‘VAProfileHEVCMain444_10’
> undeclared (first use in this function)
>  return VAProfileHEVCMain444_10;
> ^
> libavcodec/vaapi_decode.c: At top level:
> libavcodec/vaapi_decode.c:409:18: warning:
> ‘vaapi_decode_find_exact_profile’ defined but not used [-Wunused-
> function]
>  static VAProfile vaapi_decode_find_exact_profile(AVCodecContext *avctx)
>   ^
> make: *** [libavcodec/vaapi_decode.o] Error 1
> make: Target `all' not remade because of errors.
> 
Thanks, will move the VA version check into the 
vaapi_decode_find_exact_profile()
to fix the compile issue and avoid function not used warning.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

2019-04-03 Thread Michael Niedermayer 
On Wed, Apr 03, 2019 at 12:10:22PM +0800, Linjie Fu wrote:
> Use the profile constraint flags to determine the exact va_profile for
> HEVC_REXT.
> 
> Directly cast PTLCommon to H265RawProfileTierLevel, and use 
> ff_h265_get_profile
> to get the exact profile.
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: use constraint flags to determine the exact profile, expose the
> codec-specific stuff at the beginning.
> [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
> convenience? The members in PTLCommon should be strictly matched in
> H265RawProfileTierLevel.
> 
>  libavcodec/vaapi_decode.c | 74 +++
>  1 file changed, 59 insertions(+), 15 deletions(-)

breaks build:

CC  libavcodec/vaapi_decode.o
libavcodec/vaapi_decode.c: In function ‘vaapi_decode_find_exact_profile’:
libavcodec/vaapi_decode.c:421:16: error: ‘VAProfileHEVCMain422_10’ undeclared 
(first use in this function)
 return VAProfileHEVCMain422_10;
^
libavcodec/vaapi_decode.c:421:16: note: each undeclared identifier is reported 
only once for each function it appears in
libavcodec/vaapi_decode.c:423:16: error: ‘VAProfileHEVCMain444’ undeclared 
(first use in this function)
 return VAProfileHEVCMain444;
^
libavcodec/vaapi_decode.c:425:16: error: ‘VAProfileHEVCMain444_10’ undeclared 
(first use in this function)
 return VAProfileHEVCMain444_10;
^
libavcodec/vaapi_decode.c: At top level:
libavcodec/vaapi_decode.c:409:18: warning: ‘vaapi_decode_find_exact_profile’ 
defined but not used [-Wunused-function]
 static VAProfile vaapi_decode_find_exact_profile(AVCodecContext *avctx)
  ^
make: *** [libavcodec/vaapi_decode.o] Error 1
make: Target `all' not remade because of errors.

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] tests: don't include TARGET_PATH in the sample path needlessly

2019-04-03 Thread Hendrik Leppkes 
The transcode() helper function will already prepend the TARGET_PATH to
the sample path, if its a relative path. This avoids an issue on
Windows, where the relative path check could fail.
---
 tests/fate/ffmpeg.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index af7282f9ab..71ab2f1f63 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -95,7 +95,7 @@ fate-copy-trac2211-avi: CMD = transcode "h264 -r 14" 
$(TARGET_SAMPLES)/h264/bbc2
 
 FATE_STREAMCOPY-$(call ENCDEC, APNG, APNG) += fate-copy-apng
 fate-copy-apng: fate-lavf-apng
-fate-copy-apng: CMD = transcode apng 
"$(TARGET_PATH)/tests/data/lavf/lavf.apng" apng "-c:v copy"
+fate-copy-apng: CMD = transcode apng tests/data/lavf/lavf.apng apng "-c:v copy"
 
 FATE_STREAMCOPY-$(call DEMMUX, OGG, OGG) += fate-limited_input_seek 
fate-limited_input_seek-copyts
 fate-limited_input_seek: $(TARGET_SAMPLES)/vorbis/moog_small.ogg
-- 
2.20.1.windows.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2] lavf/flvdec: Fix AMF NUMBER type to metadata lost precision

2019-04-03 Thread Michael Niedermayer 
On Thu, Mar 28, 2019 at 09:23:29PM +0800, Jun Zhao wrote:
> From: Jun Zhao 
> 
> Use %.12g replace %.f when save AMF NUMBER(double) type to
> metadata. And update fate ref.
> 
> before this fix, we get FLV metadata like:
> 
>  Metadata:
> lasttimestamp   : 113
> lastkeyframetimestamp: 112
> 
> after this fix:
> 
>  Metadata:
> lasttimestamp   : 113.005
> lastkeyframetimestamp: 111.678
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/flvdec.c  |2 +-
>  tests/ref/fate/flv-add_keyframe_index |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 445d58d..12bfd4b 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -649,7 +649,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
> *astream,
> sizeof(str_val));
>  av_dict_set(&s->metadata, key, str_val, 0);
>  } else if (amf_type == AMF_DATA_TYPE_NUMBER) {
> -snprintf(str_val, sizeof(str_val), "%.f", num_val);
> +snprintf(str_val, sizeof(str_val), "%.12g", num_val);
>  av_dict_set(&s->metadata, key, str_val, 0);
>  } else if (amf_type == AMF_DATA_TYPE_STRING) {
>  av_dict_set(&s->metadata, key, str_val, 0);
> diff --git a/tests/ref/fate/flv-add_keyframe_index 
> b/tests/ref/fate/flv-add_keyframe_index
> index 1c4da65..ce3809e 100644
> --- a/tests/ref/fate/flv-add_keyframe_index
> +++ b/tests/ref/fate/flv-add_keyframe_index
> @@ -7,6 +7,6 @@ canSeekToEnd=true
>  datasize=629776
>  videosize=629381
>  audiosize=0
> -lasttimestamp=20
> +lasttimestamp=19.8571428571

does every platform we support produce the same number here ?
if not then make fate would break
its a lot of digits after the decimal point, floats are not exact ...


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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/file: add seekable option to disallow seeking

2019-04-03 Thread Marton Balint 



On Wed, 3 Apr 2019, Hendrik Leppkes wrote:


On Wed, Apr 3, 2019 at 10:42 PM Marton Balint  wrote:


Signed-off-by: Marton Balint 
---
 doc/protocols.texi | 9 +
 libavformat/file.c | 5 +
 2 files changed, 14 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index e1caa049a5..34967ff5e2 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -199,6 +199,15 @@ If set to 1, the protocol will retry reading at the end of 
the file, allowing
 reading files that still are being written. In order for this to terminate,
 you either need to use the rw_timeout option, or use the interrupt callback
 (for API users).
+
+@item seekable
+Controls if seekability is advertised on the file. 1 means seekable, 0 means
+non-seekable, -1 means auto (seekable for normal files, non-seekable for named
+pipes).
+
+Many demuxers handle seekable and non-seekable resources differently,
+overriding this might speed up opening certain files at the cost of losing some
+features (e.g. accurate seeking).
 @end table

 @section ftp
diff --git a/libavformat/file.c b/libavformat/file.c
index e613b91010..e46596fed1 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -73,6 +73,7 @@ typedef struct FileContext {
 int trunc;
 int blocksize;
 int follow;
+int seekable;
 #if HAVE_DIRENT_H
 DIR *dir;
 #endif
@@ -82,6 +83,7 @@ static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM },
 { "follow", "Follow a file as it is being written", offsetof(FileContext, 
follow), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
+{ "seekable", "Sets if the file is seekable", offsetof(FileContext, 
seekable), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, AV_OPT_FLAG_DECODING_PARAM | 
AV_OPT_FLAG_ENCODING_PARAM },
 { NULL }
 };

@@ -238,6 +240,9 @@ static int file_open(URLContext *h, const char *filename, 
int flags)
 if (!h->is_streamed && flags & AVIO_FLAG_WRITE)
 h->min_packet_size = h->max_packet_size = 262144;

+if (c->seekable >= 0)
+h->is_streamed = !c->seekable;
+


You should probably not let a user enable seeking if the resource
doesn't allow it.


lseek will fail anyway for those, so I am not sure if we should handle it 
specially. I can change it if you prefer, although in this case using 
-seekable 1 will have no effect, so the parameter maximum should be 
reduced to 0. Let me know what you think.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffmpeg: add -drop_deviant_frames option

2019-04-03 Thread Michael Niedermayer 
On Wed, Mar 27, 2019 at 08:26:36PM +0530, Gyan wrote:
> Weird. Attached corrected patch.
> 
> Thanks.
> 
> On 27-03-2019 08:19 PM, Moritz Barsnick wrote:
> >On Wed, Mar 27, 2019 at 18:05:32 +0530, Gyan wrote:
> >>+@item -drop_deviant_frames (@emph{input,per-stream})
> >>+Allows discarding decoded frames whose parameters differ from initialized
> >>+stream parameters. May be useful in
> >>+
> >It looks like this was truncated.
> >
> >Moritz
> >Cheers,
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >To unsubscribe, visit link above, or email
> >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

>  doc/ffmpeg.texi  |5 +
>  fftools/ffmpeg.c |   47 +--
>  fftools/ffmpeg.h |3 +++
>  fftools/ffmpeg_opt.c |5 +
>  4 files changed, 58 insertions(+), 2 deletions(-)
> 71a87fe4d8f2efa73a3d2d9845e7aabfb75edce5  
> 0001-ffmpeg-add-drop_deviant_frames-option.patch
> From f39e3d44e1cb8108592d2241e2251d8e1506e031 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Mon, 25 Mar 2019 22:01:07 +0530
> Subject: [PATCH] ffmpeg: add -drop_deviant_frames option
> 
> Decoded frames with changed parameters in inputs expected to be uniform
> may indicate malformed/corrupted packets. Demuxer with flag discardcorrupt
> set may not catch all such packets and neither may decoders with err_detect
> flags set.
> 
> Upon parameter change, AVFilterLink of any filters receiving such frames has
> to be reconfigured, destroying existing filter context. In case of a
> change in audio sample rate, timestamps can go haywire, potentially
> leaving the output stream to be "truncated".
> 
> Added option allows users to avoid sending such deviant frames onwards.
> Default behaviour remains unchanged.
> ---
>  doc/ffmpeg.texi  |  5 +
>  fftools/ffmpeg.c | 47 ++--
>  fftools/ffmpeg.h |  3 +++
>  fftools/ffmpeg_opt.c |  5 +
>  4 files changed, 58 insertions(+), 2 deletions(-)

Would it make sense to make this feature available to other applications ?
The awnser here has an effect of the design because
For example if this is implemented in 
libavcodec or libavfilter then other applications could
use such a feature. While if its in ffmpeg then other applications could
not. 

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/file: add seekable option to disallow seeking

2019-04-03 Thread Hendrik Leppkes 
On Wed, Apr 3, 2019 at 10:42 PM Marton Balint  wrote:
>
> Signed-off-by: Marton Balint 
> ---
>  doc/protocols.texi | 9 +
>  libavformat/file.c | 5 +
>  2 files changed, 14 insertions(+)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index e1caa049a5..34967ff5e2 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -199,6 +199,15 @@ If set to 1, the protocol will retry reading at the end 
> of the file, allowing
>  reading files that still are being written. In order for this to terminate,
>  you either need to use the rw_timeout option, or use the interrupt callback
>  (for API users).
> +
> +@item seekable
> +Controls if seekability is advertised on the file. 1 means seekable, 0 means
> +non-seekable, -1 means auto (seekable for normal files, non-seekable for 
> named
> +pipes).
> +
> +Many demuxers handle seekable and non-seekable resources differently,
> +overriding this might speed up opening certain files at the cost of losing 
> some
> +features (e.g. accurate seeking).
>  @end table
>
>  @section ftp
> diff --git a/libavformat/file.c b/libavformat/file.c
> index e613b91010..e46596fed1 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -73,6 +73,7 @@ typedef struct FileContext {
>  int trunc;
>  int blocksize;
>  int follow;
> +int seekable;
>  #if HAVE_DIRENT_H
>  DIR *dir;
>  #endif
> @@ -82,6 +83,7 @@ static const AVOption file_options[] = {
>  { "truncate", "truncate existing files on write", offsetof(FileContext, 
> trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
>  { "blocksize", "set I/O operation maximum block size", 
> offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
> INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
>  { "follow", "Follow a file as it is being written", 
> offsetof(FileContext, follow), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "seekable", "Sets if the file is seekable", offsetof(FileContext, 
> seekable), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, AV_OPT_FLAG_DECODING_PARAM 
> | AV_OPT_FLAG_ENCODING_PARAM },
>  { NULL }
>  };
>
> @@ -238,6 +240,9 @@ static int file_open(URLContext *h, const char *filename, 
> int flags)
>  if (!h->is_streamed && flags & AVIO_FLAG_WRITE)
>  h->min_packet_size = h->max_packet_size = 262144;
>
> +if (c->seekable >= 0)
> +h->is_streamed = !c->seekable;
> +

You should probably not let a user enable seeking if the resource
doesn't allow it.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/file: add seekable option to disallow seeking

2019-04-03 Thread Marton Balint 
Signed-off-by: Marton Balint 
---
 doc/protocols.texi | 9 +
 libavformat/file.c | 5 +
 2 files changed, 14 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index e1caa049a5..34967ff5e2 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -199,6 +199,15 @@ If set to 1, the protocol will retry reading at the end of 
the file, allowing
 reading files that still are being written. In order for this to terminate,
 you either need to use the rw_timeout option, or use the interrupt callback
 (for API users).
+
+@item seekable
+Controls if seekability is advertised on the file. 1 means seekable, 0 means
+non-seekable, -1 means auto (seekable for normal files, non-seekable for named
+pipes).
+
+Many demuxers handle seekable and non-seekable resources differently,
+overriding this might speed up opening certain files at the cost of losing some
+features (e.g. accurate seeking).
 @end table
 
 @section ftp
diff --git a/libavformat/file.c b/libavformat/file.c
index e613b91010..e46596fed1 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -73,6 +73,7 @@ typedef struct FileContext {
 int trunc;
 int blocksize;
 int follow;
+int seekable;
 #if HAVE_DIRENT_H
 DIR *dir;
 #endif
@@ -82,6 +83,7 @@ static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
 { "follow", "Follow a file as it is being written", offsetof(FileContext, 
follow), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
+{ "seekable", "Sets if the file is seekable", offsetof(FileContext, 
seekable), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, AV_OPT_FLAG_DECODING_PARAM | 
AV_OPT_FLAG_ENCODING_PARAM },
 { NULL }
 };
 
@@ -238,6 +240,9 @@ static int file_open(URLContext *h, const char *filename, 
int flags)
 if (!h->is_streamed && flags & AVIO_FLAG_WRITE)
 h->min_packet_size = h->max_packet_size = 262144;
 
+if (c->seekable >= 0)
+h->is_streamed = !c->seekable;
+
 return 0;
 }
 
-- 
2.16.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfdec: export operational pattern UL as file metadata

2019-04-03 Thread Marton Balint 
Can be useful for API users as ffmpeg/libavformat can't properly support some
operational patterns.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c   | 7 +++
 tests/ref/fate/mxf-probe-d10   | 1 +
 tests/ref/fate/mxf-probe-dnxhd | 1 +
 tests/ref/fate/mxf-probe-dv25  | 1 +
 4 files changed, 10 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1ba8ecd4a6..8c65a2bbcf 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -654,6 +654,7 @@ static int mxf_read_primer_pack(void *arg, AVIOContext *pb, 
int tag, int size, U
 static int mxf_read_partition_pack(void *arg, AVIOContext *pb, int tag, int 
size, UID uid, int64_t klv_offset)
 {
 MXFContext *mxf = arg;
+AVFormatContext *s = mxf->fc;
 MXFPartition *partition, *tmp_part;
 UID op;
 uint64_t footer_partition;
@@ -718,6 +719,12 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 }
 nb_essence_containers = avio_rb32(pb);
 
+if (partition->type == Header) {
+char str[36];
+snprintf(str, sizeof(str), "%08x.%08x.%08x.%08x", AV_RB32(&op[0]), 
AV_RB32(&op[4]), AV_RB32(&op[8]), AV_RB32(&op[12]));
+av_dict_set(&s->metadata, "operational_pattern", str, 0);
+}
+
 if (partition->this_partition &&
 partition->previous_partition == partition->this_partition) {
 av_log(mxf->fc, AV_LOG_ERROR,
diff --git a/tests/ref/fate/mxf-probe-d10 b/tests/ref/fate/mxf-probe-d10
index 30ceaaf421..9b8a6a688d 100644
--- a/tests/ref/fate/mxf-probe-d10
+++ b/tests/ref/fate/mxf-probe-d10
@@ -96,6 +96,7 @@ 
TAG:file_package_umid=0x060A2B340101010501010D131300AE86B200913105800800
 format_name=mxf
 duration=0.178375
 bit_rate=56419744
+TAG:operational_pattern=060e2b34.04010101.0d010201.01010900
 TAG:uid=0086b200-9131-0580--080046a54011
 TAG:generation_uid=b486b200-9131-0580--080046a54011
 TAG:company_name=SONY
diff --git a/tests/ref/fate/mxf-probe-dnxhd b/tests/ref/fate/mxf-probe-dnxhd
index c4de291d32..0870270a95 100644
--- a/tests/ref/fate/mxf-probe-dnxhd
+++ b/tests/ref/fate/mxf-probe-dnxhd
@@ -167,6 +167,7 @@ TAG:timecode=01:00:00:00
 format_name=mxf
 duration=0.250250
 bit_rate=25340195
+TAG:operational_pattern=060e2b34.04010102.0d010201.1003
 TAG:project_name=UHD
 TAG:uid=784c8132-ae36-ed4d-b0ff-2edf1f3f2d92
 TAG:generation_uid=b6bcfcab-70ff-7331-c47c-478869de11d2
diff --git a/tests/ref/fate/mxf-probe-dv25 b/tests/ref/fate/mxf-probe-dv25
index 6e02dd9802..a2e39c8057 100644
--- a/tests/ref/fate/mxf-probe-dv25
+++ b/tests/ref/fate/mxf-probe-dv25
@@ -137,6 +137,7 @@ 
TAG:file_package_umid=0x060A2B340101010501010D431300F2E2FCE98722F14F947F08DE
 format_name=mxf
 duration=1.00
 bit_rate=30679040
+TAG:operational_pattern=060e2b34.04010101.0d010201.01010900
 TAG:uid=a741d0c7-244a-bc4a-bd36-3323d04f8954
 TAG:generation_uid=c1d7a0ee-89d6-754d-bd52-cdf42b53de9f
 TAG:company_name=AVID
-- 
2.16.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Nicolas George 
Ulf Zibis (12019-04-03):
> In consideration of his in my judgement impolite 1-line comments it
> seems unlikely to me that rebasing would be worth the effort.

You are right, these comments are completely unacceptable.

But that does not mean you should not strive to improve your patches.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Paul B Mahol 
On 4/3/19, Ulf Zibis  wrote:
>
> Am 03.04.19 um 14:25 schrieb Carl Eugen Hoyos:
>>> vf_fillborders_1.patch
>> As explained, this patch is not ok,
> I would say "determined".
>
>> There are two possibilities:
>> Either you rebase your remaining patchset and wait for a
>> review from Paul.
>
> In consideration of his in my judgement impolite 1-line comments it
> seems unlikely to me that rebasing would be worth the effort.
>
>> Patches are big mess.
>> You showed very little skills.
>> You obviously lack git skills.
> Even your question from 28.03.19, 23:22 CET is still open.
>
>> Or only send the patch that improves the filter performance.
>
> I'll consider that when I'm complete with my investigation with tuning.
> I also could provide a final patch to rework the remaining indentations
> which is much less work.

Do not reindent code, it is waste of my and yours time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Ulf Zibis 

Am 03.04.19 um 14:25 schrieb Carl Eugen Hoyos:
>> vf_fillborders_1.patch
> As explained, this patch is not ok,
I would say "determined".

> There are two possibilities:
> Either you rebase your remaining patchset and wait for a
> review from Paul.

In consideration of his in my judgement impolite 1-line comments it
seems unlikely to me that rebasing would be worth the effort.

> Patches are big mess.
> You showed very little skills.
> You obviously lack git skills.
Even your question from 28.03.19, 23:22 CET is still open.

> Or only send the patch that improves the filter performance.

I'll consider that when I'm complete with my investigation with tuning.
I also could provide a final patch to rework the remaining indentations
which is much less work.

-Ulf

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffmpeg: add -drop_deviant_frames option

2019-04-03 Thread Paul B Mahol 
On 4/3/19, Gyan  wrote:
>
>
> On 02-04-2019 09:56 AM, Gyan wrote:
>>
>>
>> On 01-04-2019 10:23 AM, Gyan wrote:
>>>
>>>
>>> On 27-03-2019 08:26 PM, Gyan wrote:
 Weird. Attached corrected patch.

 Thanks.
>>>
>>> Ping.
>>
>> Plan to push tomorrow evening.
>
> Plan to push in ~2 hours.

Please delay it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread James Almer 
On 4/3/2019 9:25 AM, Baptiste Coudurier wrote:
> Hey Hendrik
> 
>> On Apr 3, 2019, at 11:37 AM, Hendrik Leppkes  wrote:
>>
>> On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
>>  wrote:
>>>
>>> ---
>>> libavcodec/cbs_h2645.c | 28 ++--
>>> libavcodec/extract_extradata_bsf.c |  4 ++--
>>> libavcodec/h2645_parse.c   |  6 +++---
>>> libavcodec/h2645_parse.h   |  6 +++---
>>> libavcodec/h264_parse.c|  4 ++--
>>> libavcodec/h264_parser.c   |  4 ++--
>>> libavcodec/h264_ps.c   |  4 ++--
>>> libavcodec/h264_ps.h   |  4 ++--
>>> libavcodec/h264_slice.c|  2 +-
>>> libavcodec/h264data.c  |  2 +-
>>> libavcodec/h264data.h  |  3 ++-
>>> libavcodec/h264dec.c   | 10 +-
>>> libavcodec/hevc_parse.c|  2 +-
>>> libavcodec/hevc_parser.c   |  4 ++--
>>> libavcodec/hevcdec.c   |  4 ++--
>>> libavcodec/svq3.c  |  2 +-
>>> 16 files changed, 45 insertions(+), 44 deletions(-)
>>>
>>
>> We prefer not to expose huge modules like this as avpriv, as it makes
>> it part of the ABI and as such impossible to change without
>> deprecation cycles.
>> Preferably, avpriv should be avoided entirely where possible, as it
>> has many of the same limitations as actual public API, and just adds
>> confusion.
> 
> Understood. What’s the alternative ?

One usual solution is adding an avpriv_ wrapper for the internal
function, like avpriv_ac3_parse_header() is done for
ff_ac3_parse_header(), which prevents internal structs from being part
of the ABI. But ff_h2645_packet_split() and
ff_h264_decode_seq_parameter_set() don't allow for that, seeing
H264ParamSets, H2645Packet, H2645RBSP and H2645NAL are complex and tend
to get changes every now and then. The last time was only a few months ago.

Other than what you're doing in your patch, the only solution i can
think of is duplicating the functionality. It wouldn't be the first, as
you can see in avc.c, hevc.c, av1.c, where bitstream parsing was
implemented in a reduced form exclusively for muxing purposes.

> 
> Thanks!
> 
> — 
> Baptiste
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffmpeg: add -drop_deviant_frames option

2019-04-03 Thread Gyan 



On 02-04-2019 09:56 AM, Gyan wrote:



On 01-04-2019 10:23 AM, Gyan wrote:



On 27-03-2019 08:26 PM, Gyan wrote:

Weird. Attached corrected patch.

Thanks.


Ping.


Plan to push tomorrow evening.


Plan to push in ~2 hours.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread Hendrik Leppkes 
On Wed, Apr 3, 2019 at 2:28 PM Carl Eugen Hoyos  wrote:
>
> 2019-04-03 11:37 GMT+02:00, Hendrik Leppkes :
>
> > We prefer not to expose huge modules like this as avpriv,
> > as it makes it part of the ABI
>
> (I am sure there are cases that are difficult to avoid,
> we also prefer not to duplicate functions.)
>
> > and as such impossible to change without
> > deprecation cycles.
>
> That does not sound correct to me.
>

You are correct, we don't need deprecation cycles. But we do need a
major bump to change it, so thats typically still a up to 2 year
delay.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/qsvenc: enable hevc gpb option

2019-04-03 Thread Zhong Li 
GPB is the default type, just contains forward references but the
slice_type is B slice with higher encoding efficiency than regular P
slice, but lower performance.

Add an option to allow user to set regular P slice.

Fix ticket#6870

Test data on Intel Kabylake (i7-7567U CPU @ 3.50GHz):
1. ffmpeg -hwaccel qsv -c:v h264_qsv -i bbb_sunflower_1080p_30fps_normal.mp4 
-vsync passthrough
-vframes 1000  -c:v hevc_qsv -gpb 0 -bf 0 -q 25 test_gpb_off_bf0_kbl.mp4

transcoding fps: 85
encoded file size of test_gpb_off_bf0_kbl.mp4: 21960100 (bytes)

2. ffmpeg -hwaccel qsv -c:v h264_qsv -i bbb_sunflower_1080p_30fps_normal.mp4 
-vsync passthrough
-vframes 1000  -c:v hevc_qsv -gpb 1 -bf 0 -q 25 test_gpb_on_bf0_kbl.mp4

transcoding fps: 79
encoded file size oftest_gpb_on_bf0_kbl.mp4:  21211449 (bytes)

In this case, enable gpb can bring about 7% performance drop but 3.4% encoding 
efficiency improvment.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c  | 9 +
 libavcodec/qsvenc.h  | 3 +++
 libavcodec/qsvenc_hevc.c | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 55f1223f02..e59fd96870 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -267,6 +267,11 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
 #endif
 
+#if QSV_HAVE_GPB
+if (avctx->codec_id == AV_CODEC_ID_HEVC)
+av_log(avctx, AV_LOG_VERBOSE,"GPB: %s\n", print_threestate(co3->GPB));
+#endif
+
 if (avctx->codec_id == AV_CODEC_ID_H264) {
 av_log(avctx, AV_LOG_VERBOSE, "Entropy coding: %s; 
MaxDecFrameBuffering: %"PRIu16"\n",
co->CAVLC == MFX_CODINGOPTION_ON ? "CAVLC" : "CABAC", 
co->MaxDecFrameBuffering);
@@ -748,6 +753,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if QSV_HAVE_CO3
 q->extco3.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION3;
 q->extco3.Header.BufferSz  = sizeof(q->extco3);
+#if QSV_HAVE_GPB
+if (avctx->codec_id == AV_CODEC_ID_HEVC)
+q->extco3.GPB  = q->gpb ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_OFF;
+#endif   
 q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)&q->extco3;
 #endif
 }
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index f6d53d44cd..f2f4d38503 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -47,6 +47,8 @@
 #define QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
 #define QSV_HAVE_VDENC  QSV_VERSION_ATLEAST(1, 15)
 
+#define QSV_HAVE_GPBQSV_VERSION_ATLEAST(1, 18)
+
 #if defined(_WIN32) || defined(__CYGWIN__)
 #define QSV_HAVE_AVBR   QSV_VERSION_ATLEAST(1, 3)
 #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 8)
@@ -173,6 +175,7 @@ typedef struct QSVEncContext {
 
 int repeat_pps;
 int low_power;
+int gpb;
 
 int a53_cc;
 
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 4c2592355e..da64b4c21b 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -241,6 +241,8 @@ static const AVOption options[] = {
 { "main10",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAIN10  
}, INT_MIN, INT_MAX, VE, "profile" },
 { "mainsp",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAINSP  
}, INT_MIN, INT_MAX, VE, "profile" },
 
+{ "gpb", "1: GPB (generalized P/B frame); 0: regular P frame", 
OFFSET(qsv.gpb), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE},
+
 { NULL },
 };
 
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread Carl Eugen Hoyos 
2019-04-03 11:37 GMT+02:00, Hendrik Leppkes :

> We prefer not to expose huge modules like this as avpriv,
> as it makes it part of the ABI

(I am sure there are cases that are difficult to avoid,
we also prefer not to duplicate functions.)

> and as such impossible to change without
> deprecation cycles.

That does not sound correct to me.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread Baptiste Coudurier 
Hey Hendrik

> On Apr 3, 2019, at 11:37 AM, Hendrik Leppkes  wrote:
> 
> On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
>  wrote:
>> 
>> ---
>> libavcodec/cbs_h2645.c | 28 ++--
>> libavcodec/extract_extradata_bsf.c |  4 ++--
>> libavcodec/h2645_parse.c   |  6 +++---
>> libavcodec/h2645_parse.h   |  6 +++---
>> libavcodec/h264_parse.c|  4 ++--
>> libavcodec/h264_parser.c   |  4 ++--
>> libavcodec/h264_ps.c   |  4 ++--
>> libavcodec/h264_ps.h   |  4 ++--
>> libavcodec/h264_slice.c|  2 +-
>> libavcodec/h264data.c  |  2 +-
>> libavcodec/h264data.h  |  3 ++-
>> libavcodec/h264dec.c   | 10 +-
>> libavcodec/hevc_parse.c|  2 +-
>> libavcodec/hevc_parser.c   |  4 ++--
>> libavcodec/hevcdec.c   |  4 ++--
>> libavcodec/svq3.c  |  2 +-
>> 16 files changed, 45 insertions(+), 44 deletions(-)
>> 
> 
> We prefer not to expose huge modules like this as avpriv, as it makes
> it part of the ABI and as such impossible to change without
> deprecation cycles.
> Preferably, avpriv should be avoided entirely where possible, as it
> has many of the same limitations as actual public API, and just adds
> confusion.

Understood. What’s the alternative ?

Thanks!

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Carl Eugen Hoyos 
2019-04-03 11:13 GMT+02:00, Ulf Zibis :

> vf_fillborders_1.patch

As explained, this patch is not ok, therefore the patchset
as-is can not be applied.

There are two possibilities:
Either you rebase your remaining patchset and wait for a
review from Paul.
Or only send the patch that improves the filter performance.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/utils: use AVIOContext.read_seek for seeks if available

2019-04-03 Thread Aman Gupta 
From: Aman Gupta 

Currently only flv and asf decoders attempt to use pb->read_seek,
by calling avio_read_seek() expliclity.

This change allows avformat users to specify a custom AVIOContext
with a read_seek callback, and have it be used with any format
whenever av_seek_frame() is invoked.

Signed-off-by: Aman Gupta 
---
 libavformat/utils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d28e6..b38727b3ed 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2487,6 +2487,9 @@ static int seek_frame_internal(AVFormatContext *s, int 
stream_index,
 if (s->iformat->read_seek) {
 ff_read_frame_flush(s);
 ret = s->iformat->read_seek(s, stream_index, timestamp, flags);
+} else if (s->pb->read_seek) {
+ff_read_frame_flush(s);
+ret = s->pb->read_seek(s->pb->opaque, stream_index, timestamp, flags);
 } else
 ret = -1;
 if (ret >= 0)
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/movenc: fix tmcd writing for non-MP4/MOV modes

2019-04-03 Thread Gyan 



On 03-04-2019 03:12 PM, Tomas Härdin wrote:

ons 2019-04-03 klockan 12:17 +0530 skrev Gyan:

On 02-04-2019 05:31 PM, Gyan wrote:


On 01-04-2019 02:54 PM, Tomas Härdin wrote:

sön 2019-03-31 klockan 00:11 +0530 skrev Gyan:

Regression since, I believe, 42cb050a05

Sounds like there should be a test case to go along with it so it
doesn't re-regress in the future :)

Turns out there's already a test. But the command is ineffective :)

Will fix it.

Test corrected.

Looks good to me


Pushed as 8161ac2902836032b6f6684aa48275325f8ca9ef

Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Ulf Zibis 

Am 03.04.19 um 11:13 schrieb Ulf Zibis:
> At my machine  all patches work fine:
>
> ich@T500:~/Projects/ffmpeg/test$ git clone git://source.ffmpeg.org/ffmpeg .
> Klone nach '.' ...
> remote: Counting objects: 565208, done.
> remote: Compressing objects: 100% (117011/117011), done.
> remote: Total 565208 (delta 453761), reused 556701 (delta 447046)
> Empfange Objekte: 100% (565208/565208), 100.39 MiB | 1.04 MiB/s, Fertig.
> Löse Unterschiede auf: 100% (453761/453761), Fertig.
> ich@T500:~/Projects/ffmpeg/test$ git checkout -b vf_fillborders
> Zu neuem Branch 'vf_fillborders' gewechselt
> [.]
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_1.patch
> Wende an: avfilter/fillborders: corrected indentations on
> line-continuation to 8
> [.]

The similar you can do with the benchmark patches:

$ git branch master
$ git checkout -b vf_fillbd_benchmark
$ git am vf_fillbd_benchmark_1.patch
$ git am vf_fillbd_benchmark_2.patch
[.]

-Ulf


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/movenc: fix tmcd writing for non-MP4/MOV modes

2019-04-03 Thread Tomas Härdin 
ons 2019-04-03 klockan 12:17 +0530 skrev Gyan:
> 
> On 02-04-2019 05:31 PM, Gyan wrote:
> > 
> > 
> > On 01-04-2019 02:54 PM, Tomas Härdin wrote:
> > > sön 2019-03-31 klockan 00:11 +0530 skrev Gyan:
> > > > Regression since, I believe, 42cb050a05
> > > 
> > > Sounds like there should be a test case to go along with it so it
> > > doesn't re-regress in the future :)
> > 
> > Turns out there's already a test. But the command is ineffective :)
> > 
> > Will fix it.
> 
> Test corrected.

Looks good to me

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread Hendrik Leppkes 
On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
 wrote:
>
> ---
>  libavcodec/cbs_h2645.c | 28 ++--
>  libavcodec/extract_extradata_bsf.c |  4 ++--
>  libavcodec/h2645_parse.c   |  6 +++---
>  libavcodec/h2645_parse.h   |  6 +++---
>  libavcodec/h264_parse.c|  4 ++--
>  libavcodec/h264_parser.c   |  4 ++--
>  libavcodec/h264_ps.c   |  4 ++--
>  libavcodec/h264_ps.h   |  4 ++--
>  libavcodec/h264_slice.c|  2 +-
>  libavcodec/h264data.c  |  2 +-
>  libavcodec/h264data.h  |  3 ++-
>  libavcodec/h264dec.c   | 10 +-
>  libavcodec/hevc_parse.c|  2 +-
>  libavcodec/hevc_parser.c   |  4 ++--
>  libavcodec/hevcdec.c   |  4 ++--
>  libavcodec/svq3.c  |  2 +-
>  16 files changed, 45 insertions(+), 44 deletions(-)
>

We prefer not to expose huge modules like this as avpriv, as it makes
it part of the ABI and as such impossible to change without
deprecation cycles.
Preferably, avpriv should be avoided entirely where possible, as it
has many of the same limitations as actual public API, and just adds
confusion.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

2019-04-03 Thread Baptiste Coudurier 
Hi Thomas,

> On Apr 1, 2019, at 4:10 PM, Thomas Mundt  wrote:
> 
> Am Sa., 30. März 2019 um 17:52 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com >:
> 
>> Hi Thomas,
>> 
>>> On Mar 29, 2019, at 1:11 PM, Thomas Mundt  wrote:
>>> 
>>> 
>>> […]
>>> 
 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
 }, 568832, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 1080/25p
 +{{
 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
 }, 236544, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100
>> 720/59.94p
 +{{
 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
 }, 284672, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 720/50p
 
>>> 
>>> Maybe i miss something, but doesn´t the setting of the profile for all
>> AVC
>>> Intra codec ULs make the for-loop to always select the last AVC Intra
>>> codec UL (720/50p) for AVC High 422 Intra?
>> 
>> The frame size check prevents that.
>> 
> 
> The frame size check in the first condition of the for-loop works for fixed
> frame size RP2027. However, with free frame size AVC High 422 Intra, the
> second condition in the for-loop only checks for profile and intra-only.
> Since the second condition doesn´t break the for-loop, the last UL with
> matching profile and intra-only flag is set.
> 
> I wanted to test this behavior, so I applied this patch to
> cf81284b1c14ef28d3f94e6d28c46188ba4e82f2, which is the last one that can be
> compiled.
> Unfortunately I was not able to produce any h264 mxf with this patch.
> E.g. the following command works perfect without this patch:
> ffmpeg -f lavfi -i testsrc=size=3840x2160:rate=50 -c:v libx264 -pix_fmt
> yuv422p10 -x264-params keyint=1 -t 1 avc.mxf
> With this patch I get errors: h264 profile not supported, could not get
> h264 profile.
> Same with other formats or long gop.
> RP2027 Class 100 1080/50i shows the following error: frame size does not
> match index unit size, 568832 != 0


Right, a few things have changed in the muxer in the mean time. I updated the 
patch and sent it.

Thanks a lot!

—
Baptiste






signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

2019-04-03 Thread Baptiste Coudurier 
---
 libavcodec/cbs_h2645.c | 28 ++--
 libavcodec/extract_extradata_bsf.c |  4 ++--
 libavcodec/h2645_parse.c   |  6 +++---
 libavcodec/h2645_parse.h   |  6 +++---
 libavcodec/h264_parse.c|  4 ++--
 libavcodec/h264_parser.c   |  4 ++--
 libavcodec/h264_ps.c   |  4 ++--
 libavcodec/h264_ps.h   |  4 ++--
 libavcodec/h264_slice.c|  2 +-
 libavcodec/h264data.c  |  2 +-
 libavcodec/h264data.h  |  3 ++-
 libavcodec/h264dec.c   | 10 +-
 libavcodec/hevc_parse.c|  2 +-
 libavcodec/hevc_parser.c   |  4 ++--
 libavcodec/hevcdec.c   |  4 ++--
 libavcodec/svq3.c  |  2 +-
 16 files changed, 45 insertions(+), 44 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index e74f8dce81..d1f7b2138f 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -599,9 +599,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell(&gbc);
 
-err = ff_h2645_packet_split(&priv->read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 1, 
1);
+err = avpriv_h2645_packet_split(&priv->read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 
1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split AVCC SPS 
array.\n");
 return err;
@@ -623,9 +623,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell(&gbc);
 
-err = ff_h2645_packet_split(&priv->read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 1, 
1);
+err = avpriv_h2645_packet_split(&priv->read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 
1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split AVCC PPS 
array.\n");
 return err;
@@ -677,9 +677,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell(&gbc);
 
-err = ff_h2645_packet_split(&priv->read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_HEVC, 
1, 1);
+err = avpriv_h2645_packet_split(&priv->read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, 
AV_CODEC_ID_HEVC, 1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split "
"HVCC array %d (%d NAL units of type %d).\n",
@@ -694,11 +694,11 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 } else {
 // Annex B, or later MP4 with already-known parameters.
 
-err = ff_h2645_packet_split(&priv->read_packet,
-frag->data, frag->data_size,
-ctx->log_ctx,
-priv->mp4, priv->nal_length_size,
-codec_id, 1, 1);
+err = avpriv_h2645_packet_split(&priv->read_packet,
+frag->data, frag->data_size,
+ctx->log_ctx,
+priv->mp4, priv->nal_length_size,
+codec_id, 1, 1);
 if (err < 0)
 return err;
 
diff --git a/libavcodec/extract_extradata_bsf.c 
b/libavcodec/extract_extradata_bsf.c
index 17e5deb96b..01ef9bed2a 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -156,8 +156,8 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
AVPacket *pkt,
 nb_extradata_nal_types = FF_ARRAY_ELEMS(extradata_nal_types_h264);
 }
 
-ret = ff_h2645_packet_split(&s->h2645_pkt, pkt->data, pkt->size,
-ctx, 0, 0, ctx->par_in->codec_id, 1, 0);
+ret = avpriv_h2645_packet_split(&s->h2645_pkt, pkt->data, pkt->size,
+ctx, 0, 0, ctx->par_in->codec_id, 1, 0);
 if (ret < 0)
 return ret;
 
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 24658b3dfa..a20a262af1 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -385,9 +385,9 @@ fail:
 return;
 }
 
-int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t *buf, int length,
-

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Paul B Mahol 
On 4/3/19, Ulf Zibis  wrote:
>
> Am 03.04.19 um 00:32 schrieb Carl Eugen Hoyos:
>>> So please throw away the old one and use the new
>>> patch 11.
>> That patch does not apply:
> At my machine  all patches work fine:
>
> ich@T500:~/Projects/ffmpeg/test$ git clone git://source.ffmpeg.org/ffmpeg .
> Klone nach '.' ...
> remote: Counting objects: 565208, done.
> remote: Compressing objects: 100% (117011/117011), done.
> remote: Total 565208 (delta 453761), reused 556701 (delta 447046)
> Empfange Objekte: 100% (565208/565208), 100.39 MiB | 1.04 MiB/s, Fertig.
> Löse Unterschiede auf: 100% (453761/453761), Fertig.
> ich@T500:~/Projects/ffmpeg/test$ git checkout -b vf_fillborders
> Zu neuem Branch 'vf_fillborders' gewechselt
> ich@T500:~/Projects/ffmpeg/test$ git status
> Auf Branch vf_fillborders
> Unversionierte Dateien:
>   (benutzen Sie "git add ...", um die Änderungen zum Commit
> vorzumerken)
>
> vf_fillborders_1.patch
> vf_fillborders_10.patch
> vf_fillborders_11.patch
> vf_fillborders_12.patch
> vf_fillborders_2.patch
> vf_fillborders_3.patch
> vf_fillborders_4.patch
> vf_fillborders_5.patch
> vf_fillborders_6.patch
> vf_fillborders_7.patch
> vf_fillborders_8.patch
> vf_fillborders_9.patch
>
> nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien
> (benutzen Sie "git add" zum Versionieren)
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_1.patch
> Wende an: avfilter/fillborders: corrected indentations on
> line-continuation to 8
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_2.patch
> Wende an: avfilter/fillborders: added comments; removed separation in
> commented blocks
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_3.patch
> Wende an: avfilter/fillborders: named more descriptive
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_4.patch
> Wende an: avfilter/fillborders: moved fillborders_options[] more up,
> needed for STOP_TIMER(testcase);
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_5.patch
> Wende an: avfilter/fillborders: removed obsolete includes
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_6.patch
> Wende an: avfilter/fillborders: reduced scope of local variables, also
> saves code lines
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_7.patch
> Wende an: avfilter/fillborders:renamed config_props; avoid needless
> calculations there and order more logical
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_8.patch
> Wende an: avfilter/fillborders: aligned pointer to array addressing style
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_9.patch
> Wende an: avfilter/fillborders: enhanced readability;
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_10.patch
> Wende an: avfilter/fillborders: shortened linesize name to allow more
> 1-line code; removed braces
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_11.patch
> Wende an: avfilter/fillborders: move definitions to their context, also
> to reduce their scope
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_12.patch
> Wende an: avfilter/fillborders: moved multiplication with linesize out
> of for loop for performance;
> ich@T500:~/Projects/ffmpeg/test$
>
>> The patch wants to remove "enum" from line 27, but that is an include in
>> current FFmpeg.
> If you already have applied the old version of vf_fillborders_11.patch
> you may first remove it from the repository with:
> git reset --hard HEAD~1
>
> ... and then apply the new patch again.

You obviously lack git skills.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

2019-04-03 Thread Baptiste Coudurier 
---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 197 ---
 2 files changed, 147 insertions(+), 51 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 4394450dea..f32124f772 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -48,6 +48,7 @@ enum MXFMetadataSetType {
 EssenceGroup,
 TaggedValue,
 TapeDescriptor,
+AVCSubDescriptor,
 };
 
 enum MXFFrameLayout {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 8c6db94865..1f865a0ad1 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -49,7 +49,10 @@
 #include "libavcodec/bytestream.h"
 #include "libavcodec/dnxhddata.h"
 #include "libavcodec/dv_profile.h"
-#include "libavcodec/h264.h"
+#include "libavcodec/golomb.h"
+#include "libavcodec/h264data.h"
+#include "libavcodec/h264_ps.h"
+#include "libavcodec/h2645_parse.h"
 #include "libavcodec/internal.h"
 #include "audiointerleave.h"
 #include "avformat.h"
@@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
 int max_gop; ///< maximum gop size, used by mpeg-2 descriptor
 int b_picture_count; ///< maximum number of consecutive b pictures, 
used in mpeg-2 descriptor
 int low_delay;   ///< low delay, used in mpeg-2 descriptor
+int avc_intra;
 } MXFStreamContext;
 
 typedef struct MXFContainerEssenceEntry {
@@ -167,6 +171,7 @@ static const struct {
 static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
+static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
@@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00 
},
-  mxf_write_mpegvideo_desc },
+  mxf_write_h264_desc },
 // S436M ANC
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00 
},
@@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x8006, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
 /* MaxGOP */
 { 0x8007, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
 /* ProfileAndLevel */
 { 0x8008, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
 /* BPictureCount */
+// Generic Descriptor
+{ 0x8100, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
 /* SubDescriptors */
+// AVC SubDescriptor
+{ 0x8200, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
 /* AVC Decoding Delay */
+{ 0x8201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
 /* AVC Profile */
+{ 0x8202, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
 /* AVC Level */
 // Wave Audio Essence Descriptor
 { 0x3D09, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
 /* Average Bytes Per Second */
 { 0x3D0A, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
 /* Block Align */
@@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,
 static const UID mxf_cdci_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00 
};
 static const UID mxf_generic_sound_descriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00 
};
 
+static const UID mxf_avc_subdescriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00 
};
+
 static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
 {
 switch (trc){
@@ -1317,6 +1330,13 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 avio_w8(pb, sc->field_dominance);
 }
 
+if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
+// write avc sub descriptor ref
+mxf_write_local_tag(pb, 8 + 16, 0x8100);
+mxf_write_refs_count(pb, 1);
+mxf_write_uuid(pb, AVCSubDescriptor, 0);
+}
+
 return pos;
 }
 
@@ -1329,10 +1349,50 @@ static void mxf_update_klv_size(AVIOContext *pb, 
int64_t pos)
 avio_seek(pb, cur_pos, SEEK_SET);
 }
 
+static void

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Ulf Zibis 

Am 03.04.19 um 00:32 schrieb Carl Eugen Hoyos:
>> So please throw away the old one and use the new
>> patch 11.
> That patch does not apply:
At my machine  all patches work fine:

ich@T500:~/Projects/ffmpeg/test$ git clone git://source.ffmpeg.org/ffmpeg .
Klone nach '.' ...
remote: Counting objects: 565208, done.
remote: Compressing objects: 100% (117011/117011), done.
remote: Total 565208 (delta 453761), reused 556701 (delta 447046)
Empfange Objekte: 100% (565208/565208), 100.39 MiB | 1.04 MiB/s, Fertig.
Löse Unterschiede auf: 100% (453761/453761), Fertig.
ich@T500:~/Projects/ffmpeg/test$ git checkout -b vf_fillborders
Zu neuem Branch 'vf_fillborders' gewechselt
ich@T500:~/Projects/ffmpeg/test$ git status
Auf Branch vf_fillborders
Unversionierte Dateien:
  (benutzen Sie "git add ...", um die Änderungen zum Commit
vorzumerken)

    vf_fillborders_1.patch
    vf_fillborders_10.patch
    vf_fillborders_11.patch
    vf_fillborders_12.patch
    vf_fillborders_2.patch
    vf_fillborders_3.patch
    vf_fillborders_4.patch
    vf_fillborders_5.patch
    vf_fillborders_6.patch
    vf_fillborders_7.patch
    vf_fillborders_8.patch
    vf_fillborders_9.patch

nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien
(benutzen Sie "git add" zum Versionieren)
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_1.patch
Wende an: avfilter/fillborders: corrected indentations on
line-continuation to 8
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_2.patch
Wende an: avfilter/fillborders: added comments; removed separation in
commented blocks
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_3.patch
Wende an: avfilter/fillborders: named more descriptive
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_4.patch
Wende an: avfilter/fillborders: moved fillborders_options[] more up,
needed for STOP_TIMER(testcase);
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_5.patch
Wende an: avfilter/fillborders: removed obsolete includes
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_6.patch
Wende an: avfilter/fillborders: reduced scope of local variables, also
saves code lines
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_7.patch
Wende an: avfilter/fillborders:renamed config_props; avoid needless
calculations there and order more logical
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_8.patch
Wende an: avfilter/fillborders: aligned pointer to array addressing style
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_9.patch
Wende an: avfilter/fillborders: enhanced readability;
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_10.patch
Wende an: avfilter/fillborders: shortened linesize name to allow more
1-line code; removed braces
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_11.patch
Wende an: avfilter/fillborders: move definitions to their context, also
to reduce their scope
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_12.patch
Wende an: avfilter/fillborders: moved multiplication with linesize out
of for loop for performance;
ich@T500:~/Projects/ffmpeg/test$

> The patch wants to remove "enum" from line 27, but that is an include in 
> current FFmpeg.
If you already have applied the old version of vf_fillborders_11.patch
you may first remove it from the repository with:
git reset --hard HEAD~1

... and then apply the new patch again.

-Ulf

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/agm: More completely check size before using it

2019-04-03 Thread Paul B Mahol 
On 4/3/19, Michael Niedermayer  wrote:
> Fixes: out of array access
> Fixes:
> 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/agm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index b0e8b80f81..2d209d 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -562,7 +562,8 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
>
>  for (int i = 0; i < 3; i++)
>  s->size[i] = bytestream2_get_le32(gbyte);
> -if (32LL + s->size[0] + s->size[1] + s->size[2] > avpkt->size)
> +if (s->size[0] < 0 || s->size[1] < 0 || s->size[2] < 0 ||
> +32LL + s->size[0] + s->size[1] + s->size[2] > avpkt->size)
>  return AVERROR_INVALIDDATA;
>
>  if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
> --
> 2.21.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V1] doc/examples/metadata: fix the example can't dump FLV metadata

2019-04-03 Thread Jun Zhao 
From: Jun Zhao 

fix the example can't dump FLV metadata.

Signed-off-by: Jun Zhao 
---
 doc/examples/metadata.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/doc/examples/metadata.c b/doc/examples/metadata.c
index e330d07..b6cfa6b 100644
--- a/doc/examples/metadata.c
+++ b/doc/examples/metadata.c
@@ -47,6 +47,11 @@ int main (int argc, char **argv)
 if ((ret = avformat_open_input(&fmt_ctx, argv[1], NULL, NULL)))
 return ret;
 
+if ((ret = avformat_find_stream_info(fmt_ctx, NULL)) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Cannot find stream information\n");
+return ret;
+}
+
 while ((tag = av_dict_get(fmt_ctx->metadata, "", tag, 
AV_DICT_IGNORE_SUFFIX)))
 printf("%s=%s\n", tag->key, tag->value);
 
-- 
1.7.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/packet: initialize payload size to zero

2019-04-03 Thread Ben Hutchinson 
How do I unsubscribe from ffmpeg-devel?

On Tue, Apr 2, 2019 at 8:57 PM Andriy Gelman 
wrote:

> From: Andriy Gelman 
>
> ---
>  libavcodec/avpacket.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 8f0603df78..6ae092ed31 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -44,6 +44,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  pkt->flags= 0;
>  pkt->stream_index = 0;
>  pkt->buf  = NULL;
> +pkt->size = 0;
>  pkt->side_data= NULL;
>  pkt->side_data_elems  = 0;
>  }
> --
> 2.21.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".