Re: [FFmpeg-devel] [PATCH] configure: allow OpenSSL>=3.0.0 with GPL

2020-06-09 Thread Carl Eugen Hoyos


> Am 09.06.2020 um 02:13 schrieb rcombs :
> 
> @@ -1820,6 +1819,7 @@ EXTERNAL_LIBRARY_LIST="
> mediacodec
> openal
> opengl
> +openssl

(Since a release is discussed)

The patch is not ok and should not be pushed as-is, openSSL 3.0 is not 
compatible with the GPL 2.0 afaict.

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] configure: allow OpenSSL>=3.0.0 with GPL

2020-06-09 Thread Hendrik Leppkes
On Tue, Jun 9, 2020 at 9:05 AM Carl Eugen Hoyos  wrote:
>
>
>
> > Am 09.06.2020 um 02:13 schrieb rcombs :
> >
> > @@ -1820,6 +1819,7 @@ EXTERNAL_LIBRARY_LIST="
> > mediacodec
> > openal
> > opengl
> > +openssl
>
> (Since a release is discussed)
>
> The patch is not ok and should not be pushed as-is, openSSL 3.0 is not 
> compatible with the GPL 2.0 afaict.
>

This is correct, Apache v2 is only considered compatible with GPLv3,
so that would need to be augmented.

- 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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

2020-06-09 Thread Linjie Fu
Signed-off-by: Linjie Fu 
---
Should be squashed with:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434

 fftools/ffmpeg.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5859781..8cdd532 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int 
frame_size);
 static BenchmarkTimeStamps get_benchmark_time_stamps(void);
 static int64_t getmaxrss(void);
 static int ifilter_has_all_input_formats(FilterGraph *fg);
+static void flush_encoders(void);
 
 static int run_as_daemon  = 0;
 static int nb_frames_dup = 0;
@@ -1058,11 +1059,21 @@ static void do_video_out(OutputFile *of,
 
 if (next_picture && (enc->width != next_picture->width ||
  enc->height != next_picture->height)) {
+flush_encoders();
+avcodec_flush_buffers(enc);
 if (!(enc->codec->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
 av_log(NULL, AV_LOG_ERROR, "Variable dimension encoding "
 "is not supported by %s.\n", enc->codec->name);
 goto error;
 }
+
+enc->width  = next_picture->width;
+enc->height = next_picture->height;
+
+if (enc->codec->close(enc) < 0)
+goto error;
+if (enc->codec->init(enc) < 0)
+goto error;
 }
 
 if (ost->source_index >= 0)
-- 
2.7.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 5/5] lavc/encoder: declare caps for encoding with variable dimension

2020-06-09 Thread Linjie Fu
Signed-off-by: Linjie Fu 
---
This patch is for RFC:
Did some tests on some of the encoders and find some encoders
not suitable for now, hence didn't declare the caps for them:
1. libx264: seems have frame drop.
2. hardware encoders like vaapi: failed.

Hence before we got all encoders supported, I'd prefer to declare
caps for specific encoder and add the enhancement step by step.

 libavcodec/libopenh264enc.c  | 4 +++-
 libavcodec/libvpxenc.c   | 4 +++-
 libavcodec/libx265.c | 4 +++-
 libavcodec/rawenc.c  | 3 ++-
 libavcodec/wrapped_avframe.c | 3 ++-
 5 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index f63aa52..b86041b 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -438,7 +438,9 @@ AVCodec ff_libopenh264_encoder = {
 .init   = svc_encode_init,
 .encode2= svc_encode_frame,
 .close  = svc_encode_close,
-.capabilities   = AV_CODEC_CAP_AUTO_THREADS,
+.capabilities   = AV_CODEC_CAP_AUTO_THREADS |
+  AV_CODEC_CAP_VARIABLE_DIMENSIONS |
+  AV_CODEC_CAP_ENCODER_FLUSH,
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_INIT_CLEANUP,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_NONE },
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8e0ea42..9faec48 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1789,7 +1789,9 @@ AVCodec ff_libvpx_vp9_encoder = {
 .init   = vp9_init,
 .encode2= vpx_encode,
 .close  = vpx_free,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS |
+  AV_CODEC_CAP_VARIABLE_DIMENSIONS |
+  AV_CODEC_CAP_ENCODER_FLUSH,
 .profiles   = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
 .priv_class = &class_vp9,
 .defaults   = defaults,
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index f560d7f..2a9ec4e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -701,6 +701,8 @@ AVCodec ff_libx265_encoder = {
 .priv_class   = &class,
 .defaults = x265_defaults,
 .capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS |
-AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+AV_CODEC_CAP_VARIABLE_DIMENSIONS |
+AV_CODEC_CAP_ENCODER_FLUSH,
 .wrapper_name = "libx265",
 };
diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index 486c0d7..85298dc 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -92,5 +92,6 @@ AVCodec ff_rawvideo_encoder = {
 .id = AV_CODEC_ID_RAWVIDEO,
 .init   = raw_encode_init,
 .encode2= raw_encode,
-.capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS,
+.capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS |
+  AV_CODEC_CAP_ENCODER_FLUSH,
 };
diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
index ae29328..9af3193 100644
--- a/libavcodec/wrapped_avframe.c
+++ b/libavcodec/wrapped_avframe.c
@@ -116,7 +116,8 @@ AVCodec ff_wrapped_avframe_encoder = {
 .id = AV_CODEC_ID_WRAPPED_AVFRAME,
 .encode2= wrapped_avframe_encode,
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
-.capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS,
+.capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS |
+  AV_CODEC_CAP_ENCODER_FLUSH,
 };
 
 AVCodec ff_wrapped_avframe_decoder = {
-- 
2.7.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 1/3] lavc/avcodec: Add caps for the support of variable dimension encoding

2020-06-09 Thread Fu, Linjie
> From: ffmpeg-devel  On Behalf Of
> Linjie Fu
> Sent: Monday, June 8, 2020 23:11
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/avcodec: Add caps for the
> support of variable dimension encoding
> 
> > From: "Anton Khirnov" 
> > Sent Time: 2020-06-08 18:50:43 (Monday)
> > To: "FFmpeg development discussions and patches"  de...@ffmpeg.org>
> > Cc:
> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/avcodec: Add caps for the
> support   of variable dimension encoding
> >
> > Quoting Linjie Fu (2020-06-08 10:58:03)
> > > And declare AV_CODEC_CAP_VARIABLE_DIMENSIONS for rawvideo and
> > > wrapped_avframe.
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  doc/APIchanges   | 3 +++
> > >  fftools/cmdutils.c   | 2 ++
> > >  libavcodec/avcodec.h | 4 +++-
> > >  libavcodec/codec.h   | 5 +
> > >  libavcodec/rawenc.c  | 1 +
> > >  libavcodec/version.h | 2 +-
> > >  libavcodec/wrapped_avframe.c | 1 +
> > >  7 files changed, 16 insertions(+), 2 deletions(-)
> >
> > During the last iteration, I asked how is this preferable to just making
> > a new encoder instance. Don't think I got a sufficient reply.
> 
> Thanks Anton for the remind, indeed making a new encoder instance would
> be
> more general and suitable for all encoders, with resolution changing in key
> frames.
> 
> In this patch set, I prefer to restrict the implementation/support to
> rawvideo and wrapped_avframe encoders, since they don't need to be
> recreated
> when resolution/dimension changes and are required. at this moment.
> 
> Also as we've discussed about whether it's worthwhile:
> 
> >> Do we get sufficient benefits from having parameter change capability
> inside
> >> encoders over just creating a new encoder instance when needed? Do
> people
> >> really need to change resolution mid-GOP?
> 
> This implementation didn't touch the logic of encoders which supports
> variable
> resolution encoding on inter frames(vp9, av1), since such
> enhancement/requirement
> seems to be rare for now.

Sent the encoder instance recreate patch set for review as a follow-up step, 
please
help to review:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1450

- Linjie
___
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] codec_desc: mark CFHD as intra-only

2020-06-09 Thread Anton Khirnov
Quoting James Almer (2020-06-08 18:30:16)
> On 6/8/2020 10:46 AM, James Almer wrote:
> > On 6/8/2020 7:54 AM, Anton Khirnov wrote:
> >> Quoting Hendrik Leppkes (2020-06-08 12:42:08)
> >>> On Mon, Jun 8, 2020 at 12:22 PM Anton Khirnov  wrote:
> 
>  This stops update_thread_context() from being called with frame
>  threading, which causes races.
>  ---
>   libavcodec/codec_desc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>  index 9f8847544f..5117984c75 100644
>  --- a/libavcodec/codec_desc.c
>  +++ b/libavcodec/codec_desc.c
>  @@ -1520,7 +1520,7 @@ static const AVCodecDescriptor codec_descriptors[] 
>  = {
>   .type  = AVMEDIA_TYPE_VIDEO,
>   .name  = "cfhd",
>   .long_name = NULL_IF_CONFIG_SMALL("Cineform HD"),
>  -.props = AV_CODEC_PROP_LOSSY,
>  +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_INTRA_ONLY,
>   },
>   {
>   .id= AV_CODEC_ID_TRUEMOTION2RT,
>  --
>  2.26.2
> 
> >>>
> >>> A codec property influencing a decoder implementation behavior seems
> >>> iffy at best, doesn't it?
> >>> What if I make an intra-only implementation for a codec that
> >>> theoretically supports more? The information no longer matches.
> >>>
> >>> Flags changing behavior of an implementation should really be on AVCodec.
> >>
> >> I generally agree, but that condition is already there and changing it
> >> to be more robust is not entirely trivial. I am planning to get to that
> >> as a part of some other threading work, but I did not want it to delay
> >> my other set which is blocked by this.
> > 
> > Maybe we could partially revert 13b1bbff0b (the intra only part) and
> > re-purpose the flag to also apply to decoders? Or only decoders,
> > whatever is best.
> > 
> > We still can seeing 4.3 wasn't tagged.
> 
> This is one way it could be implemented (attaching it as a diff since as
> patches it would need to be split in at least two).
> 
> In short, marking all implementations of intra-only codecs as such with
> the relevant codec cap during static init, and then manually do the same
> for all intra only implementations of codecs that could support more.

I don't think this needs to be visible externally, since it's only
meaningful for internal use. I'm wondering if the presence of
update_thread_context() callback won't be sufficient for this.

-- 
Anton Khirnov
___
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 v4 2/4] libavutils: Add parse_r helper for MIPS

2020-06-09 Thread Shiyou Yin
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of
>jiaxun.y...@flygoat.com
>Sent: Tuesday, June 9, 2020 1:59 PM
>To: Shiyou Yin; 'FFmpeg development discussions and patches'
>Subject: Re: [FFmpeg-devel] [PATCH v4 2/4] libavutils: Add parse_r helper for 
>MIPS
>
>
>
>于 2020年6月9日 GMT+08:00 下午1:43:58, Shiyou Yin  写到:
>>>-Original Message-
>>>From: jiaxun.y...@flygoat.com [mailto:jiaxun.y...@flygoat.com]
>>>Sent: Tuesday, June 9, 2020 2:03 AM
>>>To: FFmpeg development discussions and patches; Shiyou Yin; 'FFmpeg 
>>>development discussions and
>>>patches'
>>>Subject: Re: [FFmpeg-devel] [PATCH v4 2/4] libavutils: Add parse_r helper 
>>>for MIPS
>>>
>>>
>>>
>>>于 2020年6月8日 GMT+08:00 下午4:38:58, Shiyou Yin  写到:
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org 
>[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>Jiaxun Yang
>Sent: Monday, June 8, 2020 11:30 AM
>To: ffmpeg-devel@ffmpeg.org
>Cc: yinshi...@loongson.cn; Jiaxun Yang
>Subject: [FFmpeg-devel] [PATCH v4 2/4] libavutils: Add parse_r helper for 
>MIPS
>
>>>
>>>[...]
>>>
In inline assembler, we can add asmSymbolicName in Input/ Output Operands, 
format:
[ [asmSymbolicName] ] constraint (cExpression)
[ [asmSymbolicName] ] constraint (cVariableName)
>>>
>>>Could you expand it?
>>>I'm not really sure how that related to our case.
>>>
>>>I'm trying to use raw opcode in inline assembly and I need
>>>this helper to deal with oprands in raw opcode.
>>>
>>>Thanks!
>>>
>>
>>For the raw opcode case, another proposal for your reference.
>>static uint32_t read_cpucfg_2(uint32_t reg)
>>{
>>register uint32_t input __asm__ ("t0") = reg;
>>register uint32_t __res __asm__ ("t1") = 0;
>>__asm__ volatile(
>>".insn \n\t"
>>".word (0xc9084918) \n\t"
>>);
>>return __res;
>
>Actually this is not always safe.
>t0 and t1 might be clobbered by compiler optimization.
>
>>}
>
>I need this helper to ensure the register usage is guarded by
>compiler's allocation system.
>

Got it, than LGTM.

>--
>Jiaxun Yang
>___
>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 1/3] lavc/avcodec: Add caps for the support of variable dimension encoding

2020-06-09 Thread Nicolas George
Anton Khirnov (12020-06-08):
> During the last iteration, I asked how is this preferable to just making
> a new encoder instance. Don't think I got a sufficient reply.

How do we know that we can just put the packets of the new instance
after the packets of the old instance and it will work?

It will work for image codecs, of course.

It will not work for raw video codecs, since the frame size and
characteristics are global.

It may work for some codecs.

It may work if we generate side data to renew the extra data.

Clearly, making a new encoder instance is not an universal solution.

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] release/4.3

2020-06-09 Thread Nicolas George
Michael Niedermayer (12020-06-08):
> ive branched release/4.3, will make the 4.3 release from its HEAD in a
> few days (maybe a week depending on comments from other developers or
> any major issues)
> 
> If theres any issue remaining which you want to work on and fix+backport
> now is your last chance to get it into 4.3

Can you include this commit:

commit a45be55d5b54827220ed9097932c9e2141488526 (HEAD -> michael, 
michael/master, michael-ssh/master)
Author: Nicolas George 
Date:   2020-06-02 20:55:30 +0200

lavf/tee: pass options to protocol.

Fix trac ticket #8705.

? Or shall I do it myself? I don't want to push while you are working.

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] pthread_frame: change the way delay is set

2020-06-09 Thread Anton Khirnov
confirmed to work by jdarnley on IRC and pushed

-- 
Anton Khirnov
___
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] release/4.3

2020-06-09 Thread Hendrik Leppkes
On Tue, Jun 9, 2020 at 12:53 PM Nicolas George  wrote:
>
> Michael Niedermayer (12020-06-08):
> > ive branched release/4.3, will make the 4.3 release from its HEAD in a
> > few days (maybe a week depending on comments from other developers or
> > any major issues)
> >
> > If theres any issue remaining which you want to work on and fix+backport
> > now is your last chance to get it into 4.3
>
> Can you include this commit:
>
> commit a45be55d5b54827220ed9097932c9e2141488526 (HEAD -> michael, 
> michael/master, michael-ssh/master)
> Author: Nicolas George 
> Date:   2020-06-02 20:55:30 +0200
>
> lavf/tee: pass options to protocol.
>
> Fix trac ticket #8705.
>
> ? Or shall I do it myself? I don't want to push while you are working.
>

4.3 was branched from master last night, any commits from before that
are already included - including this one indeed.

- 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 1/2] codec_desc: drop the INTRA_ONLY property from TAK

2020-06-09 Thread Anton Khirnov
It has key frames and non-key frames, so it is not intra-only.
---
 libavcodec/codec_desc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9f8847544f..f0f71e1074 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2897,7 +2897,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .type  = AVMEDIA_TYPE_AUDIO,
 .name  = "tak",
 .long_name = NULL_IF_CONFIG_SMALL("TAK (Tom's lossless Audio 
Kompressor)"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSLESS,
 },
 {
 .id= AV_CODEC_ID_METASOUND,
-- 
2.26.2

___
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] pthread_frame: change the criterium for updating thread contexts

2020-06-09 Thread Anton Khirnov
Currently the next thread's context is updated from the previous one's
if the codec descriptor is not marked as intra-only. That is not
entirely correct, since that property does not necessarily imply
anything about how a specific decoder implementation behaves.

Instead, use the presence of the update_thread_context() callback to
decide whether an update should be performed. Fixes races in CFHD,
should cause no behaviour change in any other decoders.
---
 libavcodec/pthread_frame.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 601f170447..3255aa9337 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -246,7 +246,7 @@ static int update_context_from_thread(AVCodecContext *dst, 
AVCodecContext *src,
 {
 int err = 0;
 
-if (dst != src && (for_user || !(src->codec_descriptor->props & 
AV_CODEC_PROP_INTRA_ONLY))) {
+if (dst != src && (for_user || src->codec->update_thread_context)) {
 dst->time_base = src->time_base;
 dst->framerate = src->framerate;
 dst->width = src->width;
-- 
2.26.2

___
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] configure: allow OpenSSL>=3.0.0 with GPLv3

2020-06-09 Thread rcombs
---
 configure | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 8569a60bf8..a525611cc8 100755
--- a/configure
+++ b/configure
@@ -1731,7 +1731,6 @@ EXTERNAL_LIBRARY_GPL_LIST="
 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
 libfdk_aac
-openssl
 libtls
 "
 
@@ -1820,6 +1819,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+openssl
 pocketsphinx
 vapoursynth
 "
@@ -6469,6 +6469,9 @@ enabled openssl   && { check_pkg_config openssl 
openssl openssl/ssl.h OP
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl32 -leay32 ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
+enabled openssl && enabled gpl && { test_cpp_condition "openssl/opensslv.h" 
"defined(OPENSSL_VERSION_MAJOR) && OPENSSL_VERSION_MAJOR >= 3" &&
+{ ! enabled gplv3 && die "OpenSSL is not 
compatible with gpl version 2 and --enable-version3 is not specified." || true; 
} ||
+{ ! enabled nonfree && die "OpenSSL 
versions prior to 3.0.0 are incompatible with the gpl and --enable-nonfree is 
not specified."; } ; }
 enabled pocketsphinx  && require_pkg_config pocketsphinx pocketsphinx 
pocketsphinx/pocketsphinx.h ps_init
 enabled rkmpp && { require_pkg_config rkmpp rockchip_mpp  
rockchip/rk_mpi.h mpp_create &&
require_pkg_config rockchip_mpp "rockchip_mpp 
>= 1.3.7" rockchip/rk_mpi.h mpp_create &&
-- 
2.26.2

___
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] codec_desc: drop the INTRA_ONLY property from TAK

2020-06-09 Thread Paul B Mahol
Not correct at all decoder is intra only it just have weird container,
this also makes it single threaded and much slower.

On 6/9/20, Anton Khirnov  wrote:
> It has key frames and non-key frames, so it is not intra-only.
> ---
>  libavcodec/codec_desc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 9f8847544f..f0f71e1074 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2897,7 +2897,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .type  = AVMEDIA_TYPE_AUDIO,
>  .name  = "tak",
>  .long_name = NULL_IF_CONFIG_SMALL("TAK (Tom's lossless Audio
> Kompressor)"),
> -.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +.props = AV_CODEC_PROP_LOSSLESS,
>  },
>  {
>  .id= AV_CODEC_ID_METASOUND,
> --
> 2.26.2
>
> ___
> 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 v4 3/4] libavutil: Detect MMI and MSA flags for MIPS

2020-06-09 Thread Shiyou Yin
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of
>Jiaxun Yang
>Sent: Monday, June 8, 2020 11:32 AM
>To: ffmpeg-devel@ffmpeg.org
>Cc: yinshi...@loongson.cn; Jiaxun Yang
>Subject: [FFmpeg-devel] [PATCH v4 3/4] libavutil: Detect MMI and MSA flags for 
>MIPS
>
>Add MMI & MSA runtime detection for MIPS.
>
>Basically there are two code pathes. For systems that
>natively support CPUCFG instruction or kernel emulated
>that instruction, we'll sense this feature from HWCAP and
>report the flags according to values grab from CPUCFG. For
>systems that have no CPUCFG (or not export it in HWCAP),
>we'll parse /proc/cpuinfo instead.
>
>Signed-off-by: Jiaxun Yang 
>---
>v2: Implement CPUCFG code path as CPUCFG emulation and HWCAP
>   have accepted by Linux Kernel upstream.
>---
> libavutil/cpu.c   |  10 +++
> libavutil/cpu.h   |   3 +
> libavutil/cpu_internal.h  |   2 +
> libavutil/mips/Makefile   |   2 +-
> libavutil/mips/cpu.c  | 134 ++
> libavutil/mips/cpu.h  |  28 
> libavutil/tests/cpu.c |   3 +
> tests/checkasm/checkasm.c |   3 +
> 8 files changed, 184 insertions(+), 1 deletion(-)
> create mode 100644 libavutil/mips/cpu.c
> create mode 100644 libavutil/mips/cpu.h
>
>diff --git a/libavutil/mips/cpu.c b/libavutil/mips/cpu.c
>new file mode 100644
>index 00..e9e291a45a
>--- /dev/null
>+++ b/libavutil/mips/cpu.c
>@@ -0,0 +1,134 @@
>+/*
>+ * 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 "libavutil/cpu.h"
>+#include "libavutil/cpu_internal.h"
>+#include "config.h"
>+#if defined __linux__ || defined __ANDROID__
>+#include 
>+#include 
>+#include 
>+#include 
>+#include "asmdefs.h"
>+#include "libavutil/avstring.h"
>+#endif
>+
>+#if defined __linux__ || defined __ANDROID__
>+
>+#define HWCAP_LOONGSON_CPUCFG (1 << 14)
>+
>+static int cpucfg_available(void)
>+{
>+return getauxval(AT_HWCAP) & HWCAP_LOONGSON_CPUCFG;
>+}
>+
>+/* Most toolchains have no CPUCFG support yet */
>+static uint32_t read_cpucfg(uint32_t reg)
>+{
>+  uint32_t __res;
>+
>+  __asm__ __volatile__(
>+  "parse_r __res,%0\n\t"
>+  "parse_r reg,%1\n\t"
>+  ".insn \n\t"
>+  ".word (0xc8080118 | (reg << 21) | (__res << 11))\n\t"
>+  :"=r"(__res)
>+  :"r"(reg)
>+  :
>+  );
>+  return __res;
>+}
>+
>+#define LOONGSON_CFG1 0x1
>+
>+#define LOONGSON_CFG1_MMI (1 << 4)
>+#define LOONGSON_CFG1_MSA1(1 << 5)
>+
>+static int cpu_flags_cpucfg(void)
>+{
>+int flags = 0;
>+uint32_t cfg1 = read_cpucfg(LOONGSON_CFG1);
>+
>+if (cfg1 & LOONGSON_CFG1_MMI)
>+flags |= AV_CPU_FLAG_MMI;
>+
>+if (cfg1 & LOONGSON_CFG1_MMI)
>+flags |= AV_CPU_FLAG_MSA;

Should be LOONGSON_CFG1_MSA1.

>+
>+return flags;
>+}
>+

___
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] codec_desc: drop the INTRA_ONLY property from TAK

2020-06-09 Thread Anton Khirnov
Quoting Paul B Mahol (2020-06-09 13:34:21)
> Not correct at all decoder is intra only it just have weird container,

If it's intra only then why does the parser mark only some frames as
keyframes? And why does it need update_thread_context().

> this also makes it single threaded and much slower.

No it doesn't. It's just as multithreaded as before.

-- 
Anton Khirnov
___
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] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-06-09 Thread gautamramk
From: Gautam Ramakrishnan 

This patch makes selection of pix_fmt similar to
that in the native decoder. This makes samples such
as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
---
 libavcodec/libopenjpegdec.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 344c5ba5a3..f5f208784e 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -272,11 +272,11 @@ static inline void libopenjpeg_copyto8(AVFrame *picture, 
opj_image_t *image) {
 int *comp_data;
 uint8_t *img_ptr;
 int index, x, y;
-
 for (index = 0; index < image->numcomps; index++) {
+int plane = index?index-1:image->numcomps-1;
 comp_data = image->comps[index].data;
 for (y = 0; y < image->comps[index].h; y++) {
-img_ptr = picture->data[index] + y * picture->linesize[index];
+img_ptr = picture->data[plane] + y * picture->linesize[plane];
 for (x = 0; x < image->comps[index].w; x++) {
 *img_ptr = 0x80 * image->comps[index].sgnd + *comp_data;
 img_ptr++;
@@ -408,6 +408,23 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 if (avctx->pix_fmt == AV_PIX_FMT_NONE)
 avctx->pix_fmt = libopenjpeg_guess_pix_fmt(image);
 
+if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
+if (image->numcomps == 4 &&
+image->comps[0].dx == 1 && image->comps[0].dy == 1 &&
+image->comps[1].dx == 1 && image->comps[1].dy == 1 &&
+image->comps[2].dx == image->comps[3].dx &&
+image->comps[2].dy == image->comps[3].dy) {
+int maxprec = 0;
+for (int i = 0; i < 4; i++)
+maxprec = FFMAX(maxprec, image->comps[i].prec);
+if (maxprec == 8 &&
+image->comps[2].dx == 2 &&
+image->comps[2].dy == 2) {
+avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
+}
+}
+}
+
 if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
 av_log(avctx, AV_LOG_ERROR, "Unable to determine pixel format.\n");
 ret = AVERROR_UNKNOWN;
-- 
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] release/4.3

2020-06-09 Thread Michael Niedermayer
On Mon, Jun 08, 2020 at 11:55:15PM +0100, Kieran O Leary wrote:
> hi
> 
> On Mon, Jun 8, 2020 at 10:17 PM Michael Niedermayer 
> wrote:
> 
> > Hi
> >
> > ive branched release/4.3, will make the 4.3 release from its HEAD in a
> > few days (maybe a week depending on comments from other developers or
> > any major issues)
> >
> > If theres any issue remaining which you want to work on and fix+backport
> > now is your last chance to get it into 4.3
> >
> > Is there any chance that the naming system could be changed for this one
> release so it's 4:3 instead?

thats a funny idea but we would be causing pain with that to anyone trying
to grep or sort releases

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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] Error while using libopenjpeg

2020-06-09 Thread Gautam Ramakrishnan
On Mon, Jun 8, 2020 at 1:25 AM Michael Niedermayer
 wrote:
>
> On Sun, Jun 07, 2020 at 10:36:38PM +0530, Gautam Ramakrishnan wrote:
> > Hi,
> >
> > I am trying to decode the p1_03.j2k reference file. However, while
> > trying to use libopenjpeg instead of the native decoder, I get the
> > following error,
> > [libopenjpeg @ 0x55f249d7e180] Unable to determine pixel format.
> > The exact command run was:
> > ffmpeg  -vcodec libopenjpeg -i p1_03.j2k  -f framecrc p13
> > However this does not happen with all files. For example,
> > p0_01.j2k decodes properly. How could I decode p1_o3.j2k with libopenjpeg?
>
> try opj_decompress
>
> also if it works for you (it seems here but i do not know if the output
> is correct of course) then you can try to fix ffmpeg + libopenjpeg if
> you like
I have sent a patch to fix ffmpeg + libopenjpeg
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Never trust a computer, one day, it may think you are the virus. -- Compn
> ___
> 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".



-- 
-
Gautam |
___
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] codec_desc: mark CFHD as intra-only

2020-06-09 Thread James Almer
On 6/9/2020 6:06 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-06-08 18:30:16)
>> On 6/8/2020 10:46 AM, James Almer wrote:
>>> On 6/8/2020 7:54 AM, Anton Khirnov wrote:
 Quoting Hendrik Leppkes (2020-06-08 12:42:08)
> On Mon, Jun 8, 2020 at 12:22 PM Anton Khirnov  wrote:
>>
>> This stops update_thread_context() from being called with frame
>> threading, which causes races.
>> ---
>>  libavcodec/codec_desc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 9f8847544f..5117984c75 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -1520,7 +1520,7 @@ static const AVCodecDescriptor codec_descriptors[] 
>> = {
>>  .type  = AVMEDIA_TYPE_VIDEO,
>>  .name  = "cfhd",
>>  .long_name = NULL_IF_CONFIG_SMALL("Cineform HD"),
>> -.props = AV_CODEC_PROP_LOSSY,
>> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_INTRA_ONLY,
>>  },
>>  {
>>  .id= AV_CODEC_ID_TRUEMOTION2RT,
>> --
>> 2.26.2
>>
>
> A codec property influencing a decoder implementation behavior seems
> iffy at best, doesn't it?
> What if I make an intra-only implementation for a codec that
> theoretically supports more? The information no longer matches.
>
> Flags changing behavior of an implementation should really be on AVCodec.

 I generally agree, but that condition is already there and changing it
 to be more robust is not entirely trivial. I am planning to get to that
 as a part of some other threading work, but I did not want it to delay
 my other set which is blocked by this.
>>>
>>> Maybe we could partially revert 13b1bbff0b (the intra only part) and
>>> re-purpose the flag to also apply to decoders? Or only decoders,
>>> whatever is best.
>>>
>>> We still can seeing 4.3 wasn't tagged.
>>
>> This is one way it could be implemented (attaching it as a diff since as
>> patches it would need to be split in at least two).
>>
>> In short, marking all implementations of intra-only codecs as such with
>> the relevant codec cap during static init, and then manually do the same
>> for all intra only implementations of codecs that could support more.
> 
> I don't think this needs to be visible externally, since it's only
> meaningful for internal use. I'm wondering if the presence of
> update_thread_context() callback won't be sufficient for this.

True, it could be a caps_internal. But take for example the possibility
of an external library with a fully featured decoder getting a wrapper,
this being a public capability would let the user choose it over the
internal one, same as how it can choose a stable decoder over an
experimental one, or a software one over an hybrid/hw one.

The cap is there and has been for some time, so silently undoing the
deprecation and finally give it some good use is a good approach to
solve this.
___
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] avdevice/decklink_dec: extracting and outputing klv from vanc

2020-06-09 Thread Zivkovic, Milos
Hello,

I've attached a patch that adds support for extraction of KLV data from SDI
VANC.
Code is enabled with a special *output_klv* option and is otherwise unused.

This was tested with an off the shelf UDP -> SDI decoder that preserves KLV
and inserts them in VANC, following the guidelines in MISB ST 0605.

I'm working on another patch that will enable *avdevice/decklink_enc* to do
that as well, and it will also require *output_klv* option to be used.


0001-avdevice-decklink_dec-extracting-and-outputing-klv.patch
Description: Binary data
___
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 v4 4/4] libavcodec: Enable runtime detection for MIPS MMI & MSA

2020-06-09 Thread Shiyou Yin
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of
>Jiaxun Yang
>Sent: Monday, June 8, 2020 11:32 AM
>To: ffmpeg-devel@ffmpeg.org
>Cc: yinshi...@loongson.cn; Jiaxun Yang
>Subject: [FFmpeg-devel] [PATCH v4 4/4] libavcodec: Enable runtime detection 
>for MIPS MMI & MSA
>
>Apply optimized functions according to cpuflags.
>MSA is always put after MMI as it's usually faster than MMI.
>
>Signed-off-by: Jiaxun Yang 
>---
> libavcodec/mips/blockdsp_init_mips.c| 22 +-
> libavcodec/mips/cabac.h |  2 +-
> libavcodec/mips/h263dsp_init_mips.c | 12 +++---
> libavcodec/mips/h264chroma_init_mips.c  | 22 +-
> libavcodec/mips/h264dsp_init_mips.c | 25 -
> libavcodec/mips/h264pred_init_mips.c| 25 -
> libavcodec/mips/h264qpel_init_mips.c| 22 +-
> libavcodec/mips/hevcdsp_init_mips.c | 24 +++-
> libavcodec/mips/hevcpred_init_mips.c| 12 +++---
> libavcodec/mips/hpeldsp_init_mips.c | 22 +-
> libavcodec/mips/idctdsp_init_mips.c | 24 +++-
> libavcodec/mips/me_cmp_init_mips.c  | 12 +++---
> libavcodec/mips/mpegvideo_init_mips.c   | 22 +-
> libavcodec/mips/mpegvideoencdsp_init_mips.c | 13 ---
> libavcodec/mips/pixblockdsp_init_mips.c | 25 -
> libavcodec/mips/qpeldsp_init_mips.c | 12 +++---
> libavcodec/mips/vc1dsp_init_mips.c  | 22 +-
> libavcodec/mips/videodsp_init.c | 12 +++---
> libavcodec/mips/vp3dsp_init_mips.c  | 22 +-
> libavcodec/mips/vp8dsp_init_mips.c  | 22 +-
> libavcodec/mips/vp9dsp_init_mips.c  | 22 +-
> libavcodec/mips/wmv2dsp_init_mips.c | 12 +++---
> libavcodec/mips/xvididct_init_mips.c| 13 ---
> 23 files changed, 312 insertions(+), 109 deletions(-)
>
>diff --git a/libavcodec/mips/blockdsp_init_mips.c 
>b/libavcodec/mips/blockdsp_init_mips.c
>index 55ac1c3e99..47170c17ef 100644
>--- a/libavcodec/mips/blockdsp_init_mips.c
>+++ b/libavcodec/mips/blockdsp_init_mips.c
>@@ -19,6 +19,7 @@
>  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>  */
>
>+#include "libavutil/mips/cpu.h"
> #include "blockdsp_mips.h"
>
> #if HAVE_MSA
>@@ -30,6 +31,10 @@ static av_cold void blockdsp_init_msa(BlockDSPContext *c)
> c->fill_block_tab[0] = ff_fill_block16_msa;
> c->fill_block_tab[1] = ff_fill_block8_msa;
> }
>+#else
>+static av_cold void blockdsp_init_msa(BlockDSPContext *c)
>+{
>+}
> #endif  // #if HAVE_MSA
>
> #if HAVE_MMI
>@@ -41,14 +46,19 @@ static av_cold void blockdsp_init_mmi(BlockDSPContext *c)
> c->fill_block_tab[0] = ff_fill_block16_mmi;
> c->fill_block_tab[1] = ff_fill_block8_mmi;
> }
>+#else
>+static av_cold void blockdsp_init_mmi(BlockDSPContext *c)
>+{
>+}
> #endif /* HAVE_MMI */
>

Move "#if HAVE_MSA " into the init function (Same in other init functions). 
static av_cold void blockdsp_init_msa(BlockDSPContext *c)
{
#if HAVE_MSA
c->clear_block = ff_clear_block_msa;
c->clear_blocks = ff_clear_blocks_msa;

c->fill_block_tab[0] = ff_fill_block16_msa;
c->fill_block_tab[1] = ff_fill_block8_msa;
#endif  // #if HAVE_MSA
}


___
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] release/4.3

2020-06-09 Thread Kieran O Leary
On Tue 9 Jun 2020, 13:21 Michael Niedermayer, 
wrote:

> On Mon, Jun 08, 2020 at 11:55:15PM +0100, Kieran O Leary wrote:
> > hi
> >
> > On Mon, Jun 8, 2020 at 10:17 PM Michael Niedermayer
> 
> > wrote:
> >
> > > Hi
> > >
> > > ive branched release/4.3, will make the 4.3 release from its HEAD in a
> > > few days (maybe a week depending on comments from other developers or
> > > any major issues)
> > >
> > > If theres any issue remaining which you want to work on and
> fix+backport
> > > now is your last chance to get it into 4.3
> > >
> > > Is there any chance that the naming system could be changed for this
> one
> > release so it's 4:3 instead?
>
> thats a funny idea but we would be causing pain with that to anyone trying
> to grep or sort releases
>

Haha yeah, it was just a joke more than anything. Thank you for all your
amazing work on this!

Best,

Kieran O'Leary
Irish Film Institute
___
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] release/4.3

2020-06-09 Thread Reto Kromer
Michael Niedermayer wrote:

>>Is there any chance that the naming system could be changed
>>for this one release so it's 4:3 instead?
>
>thats a funny idea but we would be causing pain with that to
>anyone trying to grep or sort releases

You could have the release 4.3 named "4:3" rather than a
person's name.

Best regards, Reto

___
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] added sei side data

2020-06-09 Thread Andreas Rheinhardt
Daniel Loman:
> Added seperate side data field to allow adding per packet side data
> message to support MISB 604 encoding
> ---
>  libavcodec/avpacket.c  |   1 +
>  libavcodec/h264_metadata_bsf.c | 116 +++--

The changes to h264_metadata should be in a separate commit after the
addition of the new packet side data type. Furthermore, the commit
adding the new packet side data type needs to update the version and add
a changelog entry.

>  libavcodec/packet.h|   5 ++
>  3 files changed, 72 insertions(+), 50 deletions(-)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 033f2d8f26..a530dc6779 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
> AVPacketSideDataType type)
>  case AV_PKT_DATA_A53_CC: return "A53 Closed 
> Captions";
>  case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
> initialization data";
>  case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
> +case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
> data";
>  case AV_PKT_DATA_AFD:return "Active Format 
> Description data";
>  case AV_PKT_DATA_PRFT:   return "Producer Reference 
> Time";
>  case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 99017653d0..e90b82793b 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -276,6 +276,65 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>  return 0;
>  }
>  
> +static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
> size)
> +{
> +H264MetadataContext *ctx = bsf->priv_data;
> +CodedBitstreamFragment *au = &ctx->access_unit;
> +int err = 0, i, j;
> +
> +H264RawSEIPayload payload = {
> +.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
> +};
> +H264RawSEIUserDataUnregistered *udu =
> +&payload.payload.user_data_unregistered;
> +
> +for (i = j = 0; j < 32 && data[i]; i++) {
> +int c, v;
> +c = data[i];
> +if (c == '-') {
> +continue;
> +} else if (av_isxdigit(c)) {
> +c = av_tolower(c);
> +v = (c <= '9' ? c - '0' : c - 'a' + 10);
> +} else {
> +goto invalid_user_data;
> +}
> +if (i & 1)
> +udu->uuid_iso_iec_11578[j / 2] |= v;
> +else
> +udu->uuid_iso_iec_11578[j / 2] = v << 4;
> +++j;
> +}
> +if (j == 32 && data[i] == '+') {
> +size_t len = size - i - 1;
> +
> +udu->data_ref = av_buffer_alloc(len + 1);
> +if (!udu->data_ref) {
> +err = AVERROR(ENOMEM);
> +return err;

Simply return AVERROR(ENOMEM) directly.

> +}
> +
> +udu->data= udu->data_ref->data;
> +udu->data_length = len + 1;
> +memcpy(udu->data, data + i + 1, len + 1);
> +
> +err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
> +   "message to access unit.\n");
> +return err;
> +}
> +
> +} else {
> +invalid_user_data:
> +av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
> +   "must be \"UUID+string\".\n");
> +err = AVERROR(EINVAL);
> +return err;

Simply return AVERROR(EINVAL) directly.

> +}
> +return err;

Simply return 0 directly (also you don't need to initialize err any more).

> +}
> +
>  static int h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
>  {
>  H264MetadataContext *ctx = bsf->priv_data;
> @@ -412,56 +471,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
> AVPacket *pkt)
>  // Only insert the SEI in access units containing SPSs, and also
>  // unconditionally in the first access unit we ever see.
>  if (ctx->sei_user_data && (has_sps || !ctx->done_first_au)) {
> -H264RawSEIPayload payload = {
> -.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
> -};
> -H264RawSEIUserDataUnregistered *udu =
> -&payload.payload.user_data_unregistered;
> -
> -for (i = j = 0; j < 32 && ctx->sei_user_data[i]; i++) {
> -int c, v;
> -c = ctx->sei_user_data[i];
> -if (c == '-') {
> -continue;
> -} else if (av_isxdigit(c)) {
> -c = av_tolower(c);
> -v = (c <= '9' ? c - '0' : c - 'a' + 10);
> -} else {
> -goto invalid_user_data;
> -}
> -if (j & 1)
> -udu->uuid_iso_iec_11578[j / 2] |= v;
> -else
> -udu->uuid_iso_iec_11578[j / 2] = v <

Re: [FFmpeg-devel] [PATCH] added sei side data

2020-06-09 Thread Limin Wang
On Tue, Jun 09, 2020 at 02:39:14PM +1000, Brad Hards wrote:
> >> --git a/libavcodec/packet.h b/libavcodec/packet.h index 
> >> 41485f4527..48e0ccbaf0 100644
> >> --- a/libavcodec/packet.h
> >> +++ b/libavcodec/packet.h
> >> @@ -282,6 +282,11 @@ enum AVPacketSideDataType {
> >>   */
> >>  AV_PKT_DATA_DOVI_CONF,
> >>  
> >> +/**
> >> + * This side data contains SEI unregistered Data.
> >> + */
> >> +AV_PKT_DATA_SEI_USER,
> >> +
> >
> >it's public header
> 
> I don't understand this comment. What are you expecting as the change here?

It's API change for public header, so I think it's necessary to update 
doc/APIchanges 
and bump version. 
Also SEI unregisted data is h264 and h265 codec SEI data, I haven't clear why 
it's packet side
data yet. I add the SEI user data for frame level before, maybe you can check 
it:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200317105409.2795-1-lance.lmw...@gmail.com/

> 
> Brad
> 

-- 
Thanks,
Limin Wang
___
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] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-06-09 Thread Michael Bradshaw
On Tue, Jun 9, 2020 at 6:07 AM  wrote:

> From: Gautam Ramakrishnan 
>
> This patch makes selection of pix_fmt similar to
> that in the native decoder. This makes samples such
> as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
> ---
>  libavcodec/libopenjpegdec.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 344c5ba5a3..f5f208784e 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -272,11 +272,11 @@ static inline void libopenjpeg_copyto8(AVFrame
> *picture, opj_image_t *image) {
>  int *comp_data;
>  uint8_t *img_ptr;
>  int index, x, y;
> -
>  for (index = 0; index < image->numcomps; index++) {
> +int plane = index?index-1:image->numcomps-1;
>

Won't this break things for other pictures (e.g., RGB, YUV, etc.)?

 comp_data = image->comps[index].data;
>  for (y = 0; y < image->comps[index].h; y++) {
> -img_ptr = picture->data[index] + y * picture->linesize[index];
> +img_ptr = picture->data[plane] + y * picture->linesize[plane];
>  for (x = 0; x < image->comps[index].w; x++) {
>  *img_ptr = 0x80 * image->comps[index].sgnd + *comp_data;
>  img_ptr++;
> @@ -408,6 +408,23 @@ static int libopenjpeg_decode_frame(AVCodecContext
> *avctx,
>  if (avctx->pix_fmt == AV_PIX_FMT_NONE)
>  avctx->pix_fmt = libopenjpeg_guess_pix_fmt(image);
>
> +if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
> +if (image->numcomps == 4 &&
> +image->comps[0].dx == 1 && image->comps[0].dy == 1 &&
> +image->comps[1].dx == 1 && image->comps[1].dy == 1 &&
> +image->comps[2].dx == image->comps[3].dx &&
> +image->comps[2].dy == image->comps[3].dy) {
> +int maxprec = 0;
> +for (int i = 0; i < 4; i++)
> +maxprec = FFMAX(maxprec, image->comps[i].prec);
> +if (maxprec == 8 &&
> +image->comps[2].dx == 2 &&
> +image->comps[2].dy == 2) {
> +avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> +}
> +}
> +}
> +
>

Please move this up to libopenjpeg_guess_pix_fmt.

Also, are the planes stored in this image stored in AYUV order?
___
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] lavu/internal: Fix comment for avpriv_dict_set_timestamp

2020-06-09 Thread Jun Zhao
From: Jun Zhao 

Fix comment for avpriv_dict_set_timestamp from b72a7b96f84

Signed-off-by: Jun Zhao 
---
 libavutil/internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 4acbcf5..50ba73d 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -353,7 +353,8 @@ void ff_check_pixfmt_descriptors(void);
 /**
  * Set a dictionary value to an ISO-8601 compliant timestamp string.
  *
- * @param s AVFormatContext
+ * @param dict pointer to a pointer to a dictionary struct. If *dict is NULL
+ * a dictionary struct is allocated and put in *dict.
  * @param key metadata key
  * @param timestamp unix timestamp in microseconds
  * @return <0 on error
-- 
2.7.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 2/2] lavf/prompeg: prompeg_write() must report data all was written

2020-06-09 Thread Jun Zhao
From: David Holroyd 

Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created.  Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).

This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).

fix #7683

Signed-off-by: David Holroyd 
---
 libavformat/prompeg.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 7b2e5e8..59faa82 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -387,7 +387,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 PrompegFec *fec_tmp;
 uint8_t *bitstring = NULL;
 int col_idx, col_out_idx, row_idx;
-int ret, written = 0;
+int ret = 0;
 
 if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
 goto end;
@@ -403,7 +403,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 if (!s->first || s->packet_idx > 0) {
 if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 0)
 goto end;
-written += ret;
 }
 memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
 s->fec_row->sn = AV_RB16(buf + 2);
@@ -434,7 +433,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 col_out_idx = s->packet_idx / s->d;
 if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx], 
PROMPEG_FEC_COL)) < 0)
 goto end;
-written += ret;
 }
 
 if (++s->packet_idx >= s->packet_idx_max) {
@@ -443,7 +441,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 s->first = 0;
 }
 
-ret = written;
+ret = size;
 
 end:
 av_free(bitstring);
-- 
2.7.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 2/2] lavf/prompeg: prompeg_write() must report data all was written

2020-06-09 Thread Jun Zhao
From: David Holroyd 

Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created.  Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).

This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).

fix #7863

Signed-off-by: David Holroyd 
---
 libavformat/prompeg.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 7b2e5e8..59faa82 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -387,7 +387,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 PrompegFec *fec_tmp;
 uint8_t *bitstring = NULL;
 int col_idx, col_out_idx, row_idx;
-int ret, written = 0;
+int ret = 0;
 
 if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
 goto end;
@@ -403,7 +403,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 if (!s->first || s->packet_idx > 0) {
 if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 0)
 goto end;
-written += ret;
 }
 memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
 s->fec_row->sn = AV_RB16(buf + 2);
@@ -434,7 +433,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 col_out_idx = s->packet_idx / s->d;
 if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx], 
PROMPEG_FEC_COL)) < 0)
 goto end;
-written += ret;
 }
 
 if (++s->packet_idx >= s->packet_idx_max) {
@@ -443,7 +441,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 s->first = 0;
 }
 
-ret = written;
+ret = size;
 
 end:
 av_free(bitstring);
-- 
2.7.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 v9 4/4] avcodec/h264: create user data unregistered SEI side data for H.264

2020-06-09 Thread lance . lmwang
On Wed, Mar 18, 2020 at 11:12:03AM -0300, James Almer wrote:
> On 3/18/2020 10:29 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-03-17 17:36:01)
> >> On 3/17/2020 1:05 PM, Kieran Kunhya wrote:
> >>> On Tue, 17 Mar 2020 at 11:25,  wrote:
> >>>
>  From: Limin Wang 
> 
>  Signed-off-by: Limin Wang 
> 
> >>>
> >>> I've seen whole planes (e.g Alpha) taking up 10s or 100s of KB put in SEI,
> >>> do we really want to export this all as side data?
> >>
> >> Frame side data is reference counted, so it shouldn't be an issue.
> > 
> > Since this is unlikely to be useful generically - you have to know
> > exactly what's in there - perhaps we should export it only if the caller
> > requests it through some AV_CODEC_EXPORT_DATA flag.
> 
> Yes, assuming this is approved in general, that's should definitely be done.

If nobody have object to push the patchset, I'll rebasing the patchset 
for update.

> ___
> 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".

-- 
Thanks,
Limin Wang
___
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] added sei side data

2020-06-09 Thread Kieran Kunhya
On Mon, 1 Jun 2020 at 22:23, Daniel Loman  wrote:

> Added seperate side data field to allow adding per packet side data
> message to support MISB 604 encoding
>

Are you aware that this is not going to be frame accurate for the non-SPS
frame because of reordering?

Kieran
___
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] lavu/internal: Fix comment for avpriv_dict_set_timestamp

2020-06-09 Thread Jun Zhao
From: Jun Zhao 

Fix comment for avpriv_dict_set_timestamp from b72a7b96f84

Signed-off-by: Jun Zhao 
---
 libavutil/internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 4acbcf5..50ba73d 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -353,7 +353,8 @@ void ff_check_pixfmt_descriptors(void);
 /**
  * Set a dictionary value to an ISO-8601 compliant timestamp string.
  *
- * @param s AVFormatContext
+ * @param dict pointer to a pointer to a dictionary struct. If *dict is NULL
+ * a dictionary struct is allocated and put in *dict.
  * @param key metadata key
  * @param timestamp unix timestamp in microseconds
  * @return <0 on error
-- 
2.7.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 1/2] lavu/internal: Fix comment for avpriv_dict_set_timestamp

2020-06-09 Thread James Almer
On 6/9/2020 10:48 AM, Jun Zhao wrote:
> From: Jun Zhao 
> 
> Fix comment for avpriv_dict_set_timestamp from b72a7b96f84
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/internal.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 4acbcf5..50ba73d 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -353,7 +353,8 @@ void ff_check_pixfmt_descriptors(void);
>  /**
>   * Set a dictionary value to an ISO-8601 compliant timestamp string.
>   *
> - * @param s AVFormatContext
> + * @param dict pointer to a pointer to a dictionary struct. If *dict is NULL
> + * a dictionary struct is allocated and put in *dict.

Vertical alignment if you use more than one line. this line should start
where "pointer" is.

>   * @param key metadata key
>   * @param timestamp unix timestamp in microseconds
>   * @return <0 on error
> 

___
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 v2 2/2] lavf/prompeg: prompeg_write() must report data all was written

2020-06-09 Thread Jun Zhao
From: David Holroyd 

Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created.  Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).

This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).

fix #7863

Signed-off-by: David Holroyd 
---
 libavformat/prompeg.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 7b2e5e8..59faa82 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -387,7 +387,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 PrompegFec *fec_tmp;
 uint8_t *bitstring = NULL;
 int col_idx, col_out_idx, row_idx;
-int ret, written = 0;
+int ret = 0;
 
 if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
 goto end;
@@ -403,7 +403,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 if (!s->first || s->packet_idx > 0) {
 if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 0)
 goto end;
-written += ret;
 }
 memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
 s->fec_row->sn = AV_RB16(buf + 2);
@@ -434,7 +433,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 col_out_idx = s->packet_idx / s->d;
 if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx], 
PROMPEG_FEC_COL)) < 0)
 goto end;
-written += ret;
 }
 
 if (++s->packet_idx >= s->packet_idx_max) {
@@ -443,7 +441,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf, 
int size) {
 s->first = 0;
 }
 
-ret = written;
+ret = size;
 
 end:
 av_free(bitstring);
-- 
2.7.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 v2 1/2] lavu/internal: Fix comment for avpriv_dict_set_timestamp

2020-06-09 Thread Jun Zhao
From: Jun Zhao 

Fix comment for avpriv_dict_set_timestamp from b72a7b96f84

Signed-off-by: Jun Zhao 
---
 libavutil/internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 4acbcf5..373a662 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -353,7 +353,8 @@ void ff_check_pixfmt_descriptors(void);
 /**
  * Set a dictionary value to an ISO-8601 compliant timestamp string.
  *
- * @param s AVFormatContext
+ * @param dict pointer to a pointer to a dictionary struct. If *dict is NULL
+ * a dictionary struct is allocated and put in *dict.
  * @param key metadata key
  * @param timestamp unix timestamp in microseconds
  * @return <0 on error
-- 
2.7.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] avcodec/encode: restructure the core encoding code

2020-06-09 Thread James Almer
On 5/26/2020 11:35 AM, James Almer wrote:
> This commit follows the same logic as 061a0c14bb, but for the encode API: The
> new public encoding API will no longer be a wrapper around the old deprecated
> one, and the internal API used by the encoders now consists of a single
> receive_packet() callback that pulls frames as required.
> 
> amf encoders adapted by James Almer
> librav1e encoder adapted by James Almer
> nvidia encoders adapted by James Almer
> MediaFoundation encoders adapted by James Almer
> vaapi encoders adapted by Linjie Fu
> v4l2_m2m encoders adapted by Andriy Gelman
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/amfenc.c |  43 ++---
>  libavcodec/amfenc.h |   2 -
>  libavcodec/amfenc_h264.c|   1 -
>  libavcodec/amfenc_hevc.c|   1 -
>  libavcodec/avcodec.h|  12 +-
>  libavcodec/encode.c | 286 
>  libavcodec/encode.h |  39 +
>  libavcodec/internal.h   |   7 +-
>  libavcodec/librav1e.c   |  51 --
>  libavcodec/mfenc.c  |  58 ---
>  libavcodec/nvenc.c  |  72 
>  libavcodec/nvenc.h  |   9 +-
>  libavcodec/nvenc_h264.c |   6 -
>  libavcodec/nvenc_hevc.c |   4 -
>  libavcodec/utils.c  |  10 +-
>  libavcodec/v4l2_m2m.c   |   8 +
>  libavcodec/v4l2_m2m.h   |   3 +
>  libavcodec/v4l2_m2m_enc.c   |  15 +-
>  libavcodec/vaapi_encode.c   |  26 ++-
>  libavcodec/vaapi_encode.h   |   3 +-
>  libavcodec/vaapi_encode_h264.c  |   1 -
>  libavcodec/vaapi_encode_h265.c  |   1 -
>  libavcodec/vaapi_encode_mjpeg.c |   1 -
>  libavcodec/vaapi_encode_mpeg2.c |   1 -
>  libavcodec/vaapi_encode_vp8.c   |   1 -
>  libavcodec/vaapi_encode_vp9.c   |   1 -
>  26 files changed, 442 insertions(+), 220 deletions(-)
>  create mode 100644 libavcodec/encode.h

Will apply soon now that 4.3 branch was created.
___
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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

2020-06-09 Thread Devin Heitmueller
On Tue, Jun 9, 2020 at 4:53 AM Linjie Fu  wrote:
>
> Signed-off-by: Linjie Fu 
> ---
> Should be squashed with:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434
>
>  fftools/ffmpeg.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 5859781..8cdd532 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int 
> frame_size);
>  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
>  static int64_t getmaxrss(void);
>  static int ifilter_has_all_input_formats(FilterGraph *fg);
> +static void flush_encoders(void);
>
>  static int run_as_daemon  = 0;
>  static int nb_frames_dup = 0;
> @@ -1058,11 +1059,21 @@ static void do_video_out(OutputFile *of,
>
>  if (next_picture && (enc->width != next_picture->width ||
>   enc->height != next_picture->height)) {
> +flush_encoders();
> +avcodec_flush_buffers(enc);
>  if (!(enc->codec->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
>  av_log(NULL, AV_LOG_ERROR, "Variable dimension encoding "
>  "is not supported by %s.\n", enc->codec->name);
>  goto error;
>  }
> +
> +enc->width  = next_picture->width;
> +enc->height = next_picture->height;

Perhaps from a workflow standpoint it makes more sense to move the
code which changes the encoder parameters to after where you close the
existing encoder (i.e. between the close and init calls).  I can't
think of a specific case where this might break a downstream encoder,
but it seems like a good practice to only have the parameters applied
to the new encoder instance.

> +
> +if (enc->codec->close(enc) < 0)
> +goto error;
> +if (enc->codec->init(enc) < 0)
> +goto error;
>  }
>
>  if (ost->source_index >= 0)

In general do we really think this is a safe thing to do?  Does
something also need to be propagated to the output as well?  I know
that this would break use cases like the decklink output where the
frame resolution suddenly changes in the middle of the stream without
calling the output's write_header() routine.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
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] libavutil: add clean aperture (CLAP) side data.

2020-06-09 Thread Neil Birkbeck
On Mon, Jun 8, 2020 at 7:19 AM Tobias Rapp  wrote:

> On 30.05.2020 12:41, Kieran O Leary wrote:
> > Hi,
> >
> > On Fri 29 May 2020, 22:47 Neil Birkbeck, 
> wrote:
> >
> >> [...]
> >> I've changed the side data to be PixelCrop (instead of CleanAperture)
> given
> >> the intent to reuse as cropping elsewhere.
> >> -For now, I've kept the rational representation--although CLAP seems to
> be
> >> the only required case of it. Maybe Kieran could comment on the
> requirement
> >> of having maintaining the rationals for CLAP (only works on mov to mov
> >> transmuxing).
> >>
> > I'm no expert, but I think a lot of this just comes from video standards
> > that stipulate those rational numbers? I've cc'd tobias Rapp and
> Christoph
> > Gerstbauer of NOA just to bring this to their attention, as I'm pretty
> sure
> > that they use cropping values in AVI, so perhaps all of this could be
> > useful to them in some way.
> >
>
> Hi Kieran,
>
> when digitizing SD video carriers we indeed store some offset
> information in case VBI is preverved (i.e. PAL 720x608). But these
> offset values are currently not stored in the AVI container itself. The
> OpenDML "vprp" chunk defines some offset values but for the purpose of
> compressed image data where the codec implies some multiple-of-N
> height/width dimension on the data. So it did not seem to match our
> use-case.
>
> Besides AVI and the mentioned MKV and MOV formats I remember some
> display offset/cropping information being stored in MXF with the Display
> X/Y-Offset values.
>
> Regardless whether the frame crop/offset values are stored as frame
> fields or side data: how would this information be affected by filters
> like "crop" or "scale"?
>

Thanks for the additional info, Kieran and Tobias.

AVFrame already has cropping fields (AVFrame::crop_{top, bottom, left,
right}), and James Almer's suggestion was that this representation could
replace those. At the moment, when AVCodecContext::apply_cropping is true,
these offsets get applied (and zerod) in libavcodec/decode.c. Currently,
vf_crop adjusts these offsets for HWACCEL pix fmts, and vf_scale_vulkan
also respects (vf_scale doesn't).

Any additional reviewer thoughts on the SideData representation (e.g., crop
fields, currently rational to fully support the mov mux case)?
___
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] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-06-09 Thread Carl Eugen Hoyos
Am Di., 9. Juni 2020 um 14:07 Uhr schrieb :
>
> From: Gautam Ramakrishnan 
>
> This patch makes selection of pix_fmt similar to
> that in the native decoder. This makes samples such
> as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.

Since both files are not YUVA420P, I am not sure if this
patch is a good idea, in any case, the commit message
mentioning the two files as reasons for this patch is wrong.

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] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-06-09 Thread Gautam Ramakrishnan
On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos  wrote:
>
> Am Di., 9. Juni 2020 um 14:07 Uhr schrieb :
> >
> > From: Gautam Ramakrishnan 
> >
> > This patch makes selection of pix_fmt similar to
> > that in the native decoder. This makes samples such
> > as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
>
> Since both files are not YUVA420P, I am not sure if this
> patch is a good idea, in any case, the commit message
> mentioning the two files as reasons for this patch is wrong.
>
I am not sure what file format this is then. In the native decoder,
it was getting recognized as YUVA420P. The native decoder
will also have to be modified to account for that then.
> 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".



-- 
-
Gautam |
___
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] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-06-09 Thread Carl Eugen Hoyos
Am Di., 9. Juni 2020 um 19:12 Uhr schrieb Gautam Ramakrishnan
:
>
> On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos  wrote:
> >
> > Am Di., 9. Juni 2020 um 14:07 Uhr schrieb :
> > >
> > > From: Gautam Ramakrishnan 
> > >
> > > This patch makes selection of pix_fmt similar to
> > > that in the native decoder. This makes samples such
> > > as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
> >
> > Since both files are not YUVA420P, I am not sure if this
> > patch is a good idea, in any case, the commit message
> > mentioning the two files as reasons for this patch is wrong.
> >
> I am not sure what file format this is then.

I failed to find out so far, possibly Bayer, CMYK seems less
likely 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".

[FFmpeg-devel] [PATCH 1/2] added sei side data field

2020-06-09 Thread Daniel Loman
---
 Changelog | 1 +
 libavcodec/avpacket.c | 1 +
 libavcodec/packet.h   | 6 ++
 libavcodec/version.h  | 2 +-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 711c843b99..631958015a 100644
--- a/Changelog
+++ b/Changelog
@@ -75,6 +75,7 @@ version :
 - PFM decoder
 - dblur video filter
 - Real War KVAG muxer
+- added sei side data field to AVPacket 
 
 
 version 4.2:
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..a530dc6779 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
+case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
data";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
 case AV_PKT_DATA_PRFT:   return "Producer Reference 
Time";
 case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 41485f4527..8c62c467dc 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -282,6 +282,12 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_DOVI_CONF,
 
+/**
+ * This side data contains SEI unregistered Data.
+ * first 17 bytes are UID and + the rest are non zero terminated fixed 
length bytes
+ */
+AV_PKT_DATA_SEI_USER,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 524fbc3b11..4e2cc5db92 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  90
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.17.1


From 136f7ef45be4b76b49038b5914f12d0ba0005cfd Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:28:18 -0700
Subject: [PATCH 2/2] moved sei side data writing code into seperate function
 for reuse
To: ffmpeg-devel@ffmpeg.org

---
 libavcodec/h264_metadata_bsf.c | 114 ++---
 1 file changed, 64 insertions(+), 50 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 99017653d0..24404832e8 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -276,6 +276,63 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }
 
+static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
size)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+int err = 0, i, j;
+
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H264RawSEIUserDataUnregistered *udu =
+&payload.payload.user_data_unregistered;
+
+for (i = j = 0; j < 32 && data[i]; i++) {
+int c, v;
+c = data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && data[i] == '+') {
+size_t len = size - i - 1;
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+return AVERROR(ENOMEM);
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, data + i + 1, len + 1);
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
+   "message to access unit.\n");
+return err;
+}
+
+} else {
+invalid_user_data:
+av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
+   "must be \"UUID+string\".\n");
+return AVERROR(EINVAL);
+}
+return 0;
+}
+
 static int h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
 {
 H264MetadataContext *ctx = bsf->priv_data;
@@ -412,56 +469,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
AVPacket *pkt)
 // Only insert the SEI in access units containing SPSs, and also
 // unconditionally in the first access unit we ever see.
 if (ctx->sei_us

Re: [FFmpeg-devel] [PATCH 1/2] added sei side data field

2020-06-09 Thread Daniel Loman
It looks like this created a new patchwork post instead of updateding the 
previous one. I dont know how to respond to the previous patchwork comments

From: Daniel Loman 
Sent: Tuesday, June 9, 2020 11:37 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Daniel Loman
Subject: [PATCH 1/2] added sei side data field

---
 Changelog | 1 +
 libavcodec/avpacket.c | 1 +
 libavcodec/packet.h   | 6 ++
 libavcodec/version.h  | 2 +-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 711c843b99..631958015a 100644
--- a/Changelog
+++ b/Changelog
@@ -75,6 +75,7 @@ version :
 - PFM decoder
 - dblur video filter
 - Real War KVAG muxer
+- added sei side data field to AVPacket


 version 4.2:
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..a530dc6779 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
+case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
data";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
 case AV_PKT_DATA_PRFT:   return "Producer Reference 
Time";
 case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 41485f4527..8c62c467dc 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -282,6 +282,12 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_DOVI_CONF,

+/**
+ * This side data contains SEI unregistered Data.
+ * first 17 bytes are UID and + the rest are non zero terminated fixed 
length bytes
+ */
+AV_PKT_DATA_SEI_USER,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 524fbc3b11..4e2cc5db92 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@

 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  90
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101

 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.17.1


From 136f7ef45be4b76b49038b5914f12d0ba0005cfd Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:28:18 -0700
Subject: [PATCH 2/2] moved sei side data writing code into seperate function
 for reuse
To: ffmpeg-devel@ffmpeg.org

---
 libavcodec/h264_metadata_bsf.c | 114 ++---
 1 file changed, 64 insertions(+), 50 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 99017653d0..24404832e8 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -276,6 +276,63 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }

+static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
size)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+int err = 0, i, j;
+
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H264RawSEIUserDataUnregistered *udu =
+&payload.payload.user_data_unregistered;
+
+for (i = j = 0; j < 32 && data[i]; i++) {
+int c, v;
+c = data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && data[i] == '+') {
+size_t len = size - i - 1;
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+return AVERROR(ENOMEM);
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, data + i + 1, len + 1);
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
+   "message to access unit.\n");
+return err;
+}
+
+} else {
+invalid_user_data:
+av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
+   "must be \"UUID+string\".\n");
+return AVERROR(EINVAL);
+}
+return 0;
+}
+
 static int h264_metadata_update_s

Re: [FFmpeg-devel] release/4.3

2020-06-09 Thread Lou Logan
On Mon, Jun 8, 2020, at 1:17 PM, Michael Niedermayer wrote:
> Hi
> 
> ive branched release/4.3, will make the 4.3 release from its HEAD in a
> few days (maybe a week depending on comments from other developers or
> any major issues)
> 
> If theres any issue remaining which you want to work on and fix+backport
> now is your last chance to get it into 4.3

Since we basically skipped a release cycle by taking so long we should
consider making informative release notes this time like we did for 2.6 and
2.5:




If we come up with a list of interesting changes and updates I can try
to compile something assuming the weather here will be bad (the summer
here is relatively short and the rare nice days shouldn't be spent in
computerland). Instead of me just parsing git log I would prefer
suggestions by the community.
___
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] added sei side data

2020-06-09 Thread Daniel Loman
From 35034aee293cfd644ce628d3fd932ab7a0efbc10 Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:10:12 -0700
Subject: [PATCH 1/2] added sei side data field
To: ffmpeg-devel@ffmpeg.org

---
 Changelog | 1 +
 libavcodec/avpacket.c | 1 +
 libavcodec/packet.h   | 6 ++
 libavcodec/version.h  | 2 +-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 711c843b99..631958015a 100644
--- a/Changelog
+++ b/Changelog
@@ -75,6 +75,7 @@ version :
 - PFM decoder
 - dblur video filter
 - Real War KVAG muxer
+- added sei side data field to AVPacket 
 
 
 version 4.2:
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..a530dc6779 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
+case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
data";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
 case AV_PKT_DATA_PRFT:   return "Producer Reference 
Time";
 case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 41485f4527..8c62c467dc 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -282,6 +282,12 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_DOVI_CONF,
 
+/**
+ * This side data contains SEI unregistered Data.
+ * first 17 bytes are UID and + the rest are non zero terminated fixed 
length bytes
+ */
+AV_PKT_DATA_SEI_USER,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 524fbc3b11..4e2cc5db92 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  90
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.17.1


From 136f7ef45be4b76b49038b5914f12d0ba0005cfd Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:28:18 -0700
Subject: [PATCH 2/2] moved sei side data writing code into seperate function
 for reuse
To: ffmpeg-devel@ffmpeg.org

---
 libavcodec/h264_metadata_bsf.c | 114 ++---
 1 file changed, 64 insertions(+), 50 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 99017653d0..24404832e8 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -276,6 +276,63 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }
 
+static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
size)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+int err = 0, i, j;
+
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H264RawSEIUserDataUnregistered *udu =
+&payload.payload.user_data_unregistered;
+
+for (i = j = 0; j < 32 && data[i]; i++) {
+int c, v;
+c = data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && data[i] == '+') {
+size_t len = size - i - 1;
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+return AVERROR(ENOMEM);
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, data + i + 1, len + 1);
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
+   "message to access unit.\n");
+return err;
+}
+
+} else {
+invalid_user_data:
+av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
+   "must be \"UUID+string\".\n");
+return AVERROR(EINVAL);
+}
+return 0;
+}
+
 static int h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
 {
 H264MetadataContext *ctx = bsf->priv_data;
@@ -412,56 +469,7 @@ static int h264

[FFmpeg-devel] [PATCH 3/3] avcodec/loco: Fix signed integer overflow in loco_get_rice()

2020-06-09 Thread Michael Niedermayer
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 
'int'
Fixes: 
22975/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5658160970072064

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/loco.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/loco.c b/libavcodec/loco.c
index e891d83ece..d0cedf577d 100644
--- a/libavcodec/loco.c
+++ b/libavcodec/loco.c
@@ -82,7 +82,7 @@ static inline void loco_update_rice_param(RICEContext *r, int 
val)
 
 static inline int loco_get_rice(RICEContext *r)
 {
-int v;
+unsigned v;
 if (r->run > 0) { /* we have zero run */
 r->run--;
 loco_update_rice_param(r, 0);
-- 
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] release/4.3

2020-06-09 Thread Michael Niedermayer
On Tue, Jun 09, 2020 at 03:14:13PM +0200, Reto Kromer wrote:
> Michael Niedermayer wrote:
> 
> >>Is there any chance that the naming system could be changed
> >>for this one release so it's 4:3 instead?
> >
> >thats a funny idea but we would be causing pain with that to
> >anyone trying to grep or sort releases
> 
> You could have the release 4.3 named "4:3" rather than a
> person's name.

iam fine with that, anyone else has comments or a strong oppinion
on that ?

Thanks


[...]
-- 
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
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] release/4.3

2020-06-09 Thread Paul B Mahol
On 6/9/20, Michael Niedermayer  wrote:
> On Tue, Jun 09, 2020 at 03:14:13PM +0200, Reto Kromer wrote:
>> Michael Niedermayer wrote:
>>
>> >>Is there any chance that the naming system could be changed
>> >>for this one release so it's 4:3 instead?
>> >
>> >thats a funny idea but we would be causing pain with that to
>> >anyone trying to grep or sort releases
>>
>> You could have the release 4.3 named "4:3" rather than a
>> person's name.
>
> iam fine with that, anyone else has comments or a strong oppinion
> on that ?

Against, release name as always should be George or Carl.

>
> Thanks
>
>
> [...]
> --
> 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
> ..."
>
___
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/3] RELEASE: We are after the 4.3 branch point, update for that

2020-06-09 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 RELEASE | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/RELEASE b/RELEASE
index f4ec7e28b1..a9c2406240 100644
--- a/RELEASE
+++ b/RELEASE
@@ -1 +1 @@
-4.2.git
+4.3.git
-- 
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".

[FFmpeg-devel] [PATCH 2/3] avcodec/wmalosslessdec: Check block_align maximum

2020-06-09 Thread Michael Niedermayer
Fixes: Assertion failure
Fixes: 
22737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-595839681920

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wmalosslessdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index cfdd9e9a85..62d5fadf5d 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -184,7 +184,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 unsigned int channel_mask;
 int i, log2_max_num_subframes;
 
-if (avctx->block_align <= 0) {
+if (avctx->block_align <= 0 || avctx->block_align > (1<<21)) {
 av_log(avctx, AV_LOG_ERROR, "block_align is not set or invalid\n");
 return AVERROR(EINVAL);
 }
-- 
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/3] RELEASE: We are after the 4.3 branch point, update for that

2020-06-09 Thread James Almer
On 6/9/2020 5:55 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  RELEASE | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/RELEASE b/RELEASE
> index f4ec7e28b1..a9c2406240 100644
> --- a/RELEASE
> +++ b/RELEASE
> @@ -1 +1 @@
> -4.2.git
> +4.3.git

LGTM, this really doesn't need a patch since it's standard release
procedure.
___
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/3] RELEASE: We are after the 4.3 branch point, update for that

2020-06-09 Thread Michael Niedermayer
On Tue, Jun 09, 2020 at 06:15:11PM -0300, James Almer wrote:
> On 6/9/2020 5:55 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  RELEASE | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/RELEASE b/RELEASE
> > index f4ec7e28b1..a9c2406240 100644
> > --- a/RELEASE
> > +++ b/RELEASE
> > @@ -1 +1 @@
> > -4.2.git
> > +4.3.git
> 
> LGTM, this really doesn't need a patch since it's standard release
> procedure.

yes i just had it locally when submitting the others so i did this
one too without thinking much about it
will apply

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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] added sei side data

2020-06-09 Thread Daniel Loman
KK>>Are you aware that this is not going to be frame accurate for the non-SPS
KK>>frame because of reordering?

reordering of the frame in terms of pts versus dts?

these are attached to the AVPackets not AVFrame. They data should correspond 
with the pts of the packet. unless i am confused with what youre saying  

From: ffmpeg-devel  on behalf of Daniel Loman 

Sent: Tuesday, June 9, 2020 1:52 PM
To: 'FFmpeg development discussions and patches'
Subject: Re: [FFmpeg-devel] [PATCH] added sei side data

From 35034aee293cfd644ce628d3fd932ab7a0efbc10 Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:10:12 -0700
Subject: [PATCH 1/2] added sei side data field
To: ffmpeg-devel@ffmpeg.org

---
 Changelog | 1 +
 libavcodec/avpacket.c | 1 +
 libavcodec/packet.h   | 6 ++
 libavcodec/version.h  | 2 +-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 711c843b99..631958015a 100644
--- a/Changelog
+++ b/Changelog
@@ -75,6 +75,7 @@ version :
 - PFM decoder
 - dblur video filter
 - Real War KVAG muxer
+- added sei side data field to AVPacket


 version 4.2:
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..a530dc6779 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
+case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
data";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
 case AV_PKT_DATA_PRFT:   return "Producer Reference 
Time";
 case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 41485f4527..8c62c467dc 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -282,6 +282,12 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_DOVI_CONF,

+/**
+ * This side data contains SEI unregistered Data.
+ * first 17 bytes are UID and + the rest are non zero terminated fixed 
length bytes
+ */
+AV_PKT_DATA_SEI_USER,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 524fbc3b11..4e2cc5db92 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@

 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  90
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101

 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.17.1


From 136f7ef45be4b76b49038b5914f12d0ba0005cfd Mon Sep 17 00:00:00 2001
From: Daniel Loman 
Date: Tue, 9 Jun 2020 11:28:18 -0700
Subject: [PATCH 2/2] moved sei side data writing code into seperate function
 for reuse
To: ffmpeg-devel@ffmpeg.org

---
 libavcodec/h264_metadata_bsf.c | 114 ++---
 1 file changed, 64 insertions(+), 50 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 99017653d0..24404832e8 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -276,6 +276,63 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }

+static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
size)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+int err = 0, i, j;
+
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H264RawSEIUserDataUnregistered *udu =
+&payload.payload.user_data_unregistered;
+
+for (i = j = 0; j < 32 && data[i]; i++) {
+int c, v;
+c = data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && data[i] == '+') {
+size_t len = size - i - 1;
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+return AVERROR(ENOMEM);
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, data + i + 1, len + 1);
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
+   

Re: [FFmpeg-devel] [PATCH] avcodec/encode: restructure the core encoding code

2020-06-09 Thread Michael Niedermayer
On Tue, May 26, 2020 at 11:35:39AM -0300, James Almer wrote:
> This commit follows the same logic as 061a0c14bb, but for the encode API: The
> new public encoding API will no longer be a wrapper around the old deprecated
> one, and the internal API used by the encoders now consists of a single
> receive_packet() callback that pulls frames as required.
> 
> amf encoders adapted by James Almer
> librav1e encoder adapted by James Almer
> nvidia encoders adapted by James Almer
> MediaFoundation encoders adapted by James Almer
> vaapi encoders adapted by Linjie Fu
> v4l2_m2m encoders adapted by Andriy Gelman
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/amfenc.c |  43 ++---
>  libavcodec/amfenc.h |   2 -
>  libavcodec/amfenc_h264.c|   1 -
>  libavcodec/amfenc_hevc.c|   1 -
>  libavcodec/avcodec.h|  12 +-
>  libavcodec/encode.c | 286 
>  libavcodec/encode.h |  39 +
>  libavcodec/internal.h   |   7 +-
>  libavcodec/librav1e.c   |  51 --
>  libavcodec/mfenc.c  |  58 ---
>  libavcodec/nvenc.c  |  72 
>  libavcodec/nvenc.h  |   9 +-
>  libavcodec/nvenc_h264.c |   6 -
>  libavcodec/nvenc_hevc.c |   4 -
>  libavcodec/utils.c  |  10 +-
>  libavcodec/v4l2_m2m.c   |   8 +
>  libavcodec/v4l2_m2m.h   |   3 +
>  libavcodec/v4l2_m2m_enc.c   |  15 +-
>  libavcodec/vaapi_encode.c   |  26 ++-
>  libavcodec/vaapi_encode.h   |   3 +-
>  libavcodec/vaapi_encode_h264.c  |   1 -
>  libavcodec/vaapi_encode_h265.c  |   1 -
>  libavcodec/vaapi_encode_mjpeg.c |   1 -
>  libavcodec/vaapi_encode_mpeg2.c |   1 -
>  libavcodec/vaapi_encode_vp8.c   |   1 -
>  libavcodec/vaapi_encode_vp9.c   |   1 -
>  26 files changed, 442 insertions(+), 220 deletions(-)
>  create mode 100644 libavcodec/encode.h

this doesnt apply (anymore) automatically

Applying: This commit follows the same logic as 061a0c14bb, but for the encode 
API: The
Using index info to reconstruct a base tree...
M   libavcodec/avcodec.h
M   libavcodec/encode.c
M   libavcodec/internal.h
M   libavcodec/mfenc.c
M   libavcodec/nvenc.c
M   libavcodec/utils.c
M   libavcodec/v4l2_m2m_enc.c
Falling back to patching base and 3-way merge...
Auto-merging libavcodec/v4l2_m2m_enc.c
Auto-merging libavcodec/utils.c
Auto-merging libavcodec/nvenc.c
Auto-merging libavcodec/mfenc.c
Auto-merging libavcodec/internal.h
Auto-merging libavcodec/encode.c
Auto-merging libavcodec/avcodec.h
CONFLICT (content): Merge conflict in libavcodec/avcodec.h

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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] avcodec/encode: restructure the core encoding code

2020-06-09 Thread James Almer
On 6/9/2020 6:33 PM, Michael Niedermayer wrote:
> On Tue, May 26, 2020 at 11:35:39AM -0300, James Almer wrote:
>> This commit follows the same logic as 061a0c14bb, but for the encode API: The
>> new public encoding API will no longer be a wrapper around the old deprecated
>> one, and the internal API used by the encoders now consists of a single
>> receive_packet() callback that pulls frames as required.
>>
>> amf encoders adapted by James Almer
>> librav1e encoder adapted by James Almer
>> nvidia encoders adapted by James Almer
>> MediaFoundation encoders adapted by James Almer
>> vaapi encoders adapted by Linjie Fu
>> v4l2_m2m encoders adapted by Andriy Gelman
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/amfenc.c |  43 ++---
>>  libavcodec/amfenc.h |   2 -
>>  libavcodec/amfenc_h264.c|   1 -
>>  libavcodec/amfenc_hevc.c|   1 -
>>  libavcodec/avcodec.h|  12 +-
>>  libavcodec/encode.c | 286 
>>  libavcodec/encode.h |  39 +
>>  libavcodec/internal.h   |   7 +-
>>  libavcodec/librav1e.c   |  51 --
>>  libavcodec/mfenc.c  |  58 ---
>>  libavcodec/nvenc.c  |  72 
>>  libavcodec/nvenc.h  |   9 +-
>>  libavcodec/nvenc_h264.c |   6 -
>>  libavcodec/nvenc_hevc.c |   4 -
>>  libavcodec/utils.c  |  10 +-
>>  libavcodec/v4l2_m2m.c   |   8 +
>>  libavcodec/v4l2_m2m.h   |   3 +
>>  libavcodec/v4l2_m2m_enc.c   |  15 +-
>>  libavcodec/vaapi_encode.c   |  26 ++-
>>  libavcodec/vaapi_encode.h   |   3 +-
>>  libavcodec/vaapi_encode_h264.c  |   1 -
>>  libavcodec/vaapi_encode_h265.c  |   1 -
>>  libavcodec/vaapi_encode_mjpeg.c |   1 -
>>  libavcodec/vaapi_encode_mpeg2.c |   1 -
>>  libavcodec/vaapi_encode_vp8.c   |   1 -
>>  libavcodec/vaapi_encode_vp9.c   |   1 -
>>  26 files changed, 442 insertions(+), 220 deletions(-)
>>  create mode 100644 libavcodec/encode.h
> 
> this doesnt apply (anymore) automatically
> 
> Applying: This commit follows the same logic as 061a0c14bb, but for the 
> encode API: The
> Using index info to reconstruct a base tree...
> M libavcodec/avcodec.h
> M libavcodec/encode.c
> M libavcodec/internal.h
> M libavcodec/mfenc.c
> M libavcodec/nvenc.c
> M libavcodec/utils.c
> M libavcodec/v4l2_m2m_enc.c
> Falling back to patching base and 3-way merge...
> Auto-merging libavcodec/v4l2_m2m_enc.c
> Auto-merging libavcodec/utils.c
> Auto-merging libavcodec/nvenc.c
> Auto-merging libavcodec/mfenc.c
> Auto-merging libavcodec/internal.h
> Auto-merging libavcodec/encode.c
> Auto-merging libavcodec/avcodec.h
> CONFLICT (content): Merge conflict in libavcodec/avcodec.h

Yeah, Anton moved AVCodec to codec.h, so i need to rebase. Will send an
updated version soon.
___
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 v5] avcodec/encode: restructure the old encode API

2020-06-09 Thread James Almer
Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.

Signed-off-by: James Almer 
---
 libavcodec/encode.c   | 370 +-
 libavcodec/internal.h |   1 +
 libavcodec/utils.c|   8 +-
 3 files changed, 116 insertions(+), 263 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 83602ca45b..8bc10c4abb 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -32,43 +32,28 @@
 
 int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
int64_t min_size)
 {
-if (avpkt->size < 0) {
-av_log(avctx, AV_LOG_ERROR, "Invalid negative user packet size %d\n", 
avpkt->size);
-return AVERROR(EINVAL);
-}
 if (size < 0 || size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
 av_log(avctx, AV_LOG_ERROR, "Invalid minimum required packet size 
%"PRId64" (max allowed is %d)\n",
size, INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE);
 return AVERROR(EINVAL);
 }
 
+av_assert0(!avpkt->data);
+
 if (avctx && 2*min_size < size) { // FIXME The factor needs to be finetuned
-av_assert0(!avpkt->data || avpkt->data != 
avctx->internal->byte_buffer);
-if (!avpkt->data || avpkt->size < size) {
-av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
-avpkt->data = avctx->internal->byte_buffer;
-avpkt->size = avctx->internal->byte_buffer_size;
-}
+av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
+avpkt->data = avctx->internal->byte_buffer;
+avpkt->size = size;
 }
 
-if (avpkt->data) {
-AVBufferRef *buf = avpkt->buf;
-
-if (avpkt->size < size) {
-av_log(avctx, AV_LOG_ERROR, "User packet is too small (%d < 
%"PRId64")\n", avpkt->size, size);
-return AVERROR(EINVAL);
-}
-
-av_init_packet(avpkt);
-avpkt->buf  = buf;
-avpkt->size = size;
-return 0;
-} else {
+if (!avpkt->data) {
 int ret = av_new_packet(avpkt, size);
 if (ret < 0)
 av_log(avctx, AV_LOG_ERROR, "Failed to allocate packet of size 
%"PRId64"\n", size);
 return ret;
 }
+
+return 0;
 }
 
 /**
@@ -105,244 +90,6 @@ fail:
 return ret;
 }
 
-int attribute_align_arg avcodec_encode_audio2(AVCodecContext *avctx,
-  AVPacket *avpkt,
-  const AVFrame *frame,
-  int *got_packet_ptr)
-{
-AVFrame *extended_frame = NULL;
-AVFrame *padded_frame = NULL;
-int ret;
-AVPacket user_pkt = *avpkt;
-int needs_realloc = !user_pkt.data;
-
-*got_packet_ptr = 0;
-
-if (!avctx->codec->encode2) {
-av_log(avctx, AV_LOG_ERROR, "This encoder requires using the 
avcodec_send_frame() API.\n");
-return AVERROR(ENOSYS);
-}
-
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY) && !frame) {
-av_packet_unref(avpkt);
-return 0;
-}
-
-/* ensure that extended_data is properly set */
-if (frame && !frame->extended_data) {
-if (av_sample_fmt_is_planar(avctx->sample_fmt) &&
-avctx->channels > AV_NUM_DATA_POINTERS) {
-av_log(avctx, AV_LOG_ERROR, "Encoding to a planar sample format, "
-"with more than %d channels, but 
extended_data is not set.\n",
-   AV_NUM_DATA_POINTERS);
-return AVERROR(EINVAL);
-}
-av_log(avctx, AV_LOG_WARNING, "extended_data is not set.\n");
-
-extended_frame = av_frame_alloc();
-if (!extended_frame)
-return AVERROR(ENOMEM);
-
-memcpy(extended_frame, frame, sizeof(AVFrame));
-extended_frame->extended_data = extended_frame->data;
-frame = extended_frame;
-}
-
-/* extract audio service type metadata */
-if (frame) {
-AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
-if (sd && sd->size >= sizeof(enum AVAudioServiceType))
-avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
-}
-
-/* check for valid frame size */
-if (frame) {
-if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
-if (frame->nb_samples > avctx->frame_size) {
-av_log(avctx, AV_LOG_ERROR, "more samples than frame size 
(avcodec_encode_audio2)\n");
-ret = AVERROR(EINVAL);
-goto end;
-}
-} else if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
-/* if we already got an undersized frame, that must have been the 
last */
-if (avctx->internal->last_audio_frame) {
-av_log(avctx, AV_LOG_ERROR, "frame_siz

[FFmpeg-devel] [PATCH 1/2 v5] avcodec/encode: restructure the core encoding code

2020-06-09 Thread James Almer
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.

amf encoders adapted by James Almer
librav1e encoder adapted by James Almer
nvidia encoders adapted by James Almer
MediaFoundation encoders adapted by James Almer
vaapi encoders adapted by Linjie Fu
v4l2_m2m encoders adapted by Andriy Gelman

Signed-off-by: James Almer 
---
Rebased once again.

 libavcodec/amfenc.c |  43 ++---
 libavcodec/amfenc.h |   2 -
 libavcodec/amfenc_h264.c|   1 -
 libavcodec/amfenc_hevc.c|   1 -
 libavcodec/codec.h  |  10 +-
 libavcodec/encode.c | 286 
 libavcodec/encode.h |  39 +
 libavcodec/internal.h   |   7 +-
 libavcodec/librav1e.c   |  51 --
 libavcodec/mfenc.c  |  58 ---
 libavcodec/nvenc.c  |  72 
 libavcodec/nvenc.h  |   9 +-
 libavcodec/nvenc_h264.c |   6 -
 libavcodec/nvenc_hevc.c |   4 -
 libavcodec/utils.c  |  10 +-
 libavcodec/v4l2_m2m.c   |   8 +
 libavcodec/v4l2_m2m.h   |   3 +
 libavcodec/v4l2_m2m_enc.c   |  15 +-
 libavcodec/vaapi_encode.c   |  26 ++-
 libavcodec/vaapi_encode.h   |   3 +-
 libavcodec/vaapi_encode_h264.c  |   1 -
 libavcodec/vaapi_encode_h265.c  |   1 -
 libavcodec/vaapi_encode_mjpeg.c |   1 -
 libavcodec/vaapi_encode_mpeg2.c |   1 -
 libavcodec/vaapi_encode_vp8.c   |   1 -
 libavcodec/vaapi_encode_vp9.c   |   1 -
 26 files changed, 441 insertions(+), 219 deletions(-)
 create mode 100644 libavcodec/encode.h

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 876fddd2b6..da0652943d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -33,6 +33,7 @@
 #include "libavutil/time.h"
 
 #include "amfenc.h"
+#include "encode.h"
 #include "internal.h"
 
 #if CONFIG_D3D11VA
@@ -588,17 +589,27 @@ static void amf_release_buffer_with_frame_ref(AMFBuffer 
*frame_ref_storage_buffe
 frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
 }
 
-int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
 {
 AmfContext *ctx = avctx->priv_data;
 AMFSurface *surface;
 AMF_RESULT  res;
 int ret;
+AMF_RESULT  res_query;
+AMFData*data = NULL;
+AVFrame*frame = ctx->delayed_frame;
+int block_and_wait;
 
 if (!ctx->encoder)
 return AVERROR(EINVAL);
 
-if (!frame) { // submit drain
+if (!frame->buf[0]) {
+ret = ff_encode_get_frame(avctx, frame);
+if (ret < 0 && ret != AVERROR_EOF)
+return ret;
+}
+
+if (!frame->buf[0]) { // submit drain
 if (!ctx->eof) { // submit drain one time only
 if (ctx->delayed_surface != NULL) {
 ctx->delayed_drain = 1; // input queue is full: resubmit 
Drain() in ff_amf_receive_packet
@@ -613,15 +624,10 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
"Drain() failed with error %d\n", res);
 }
 }
-} else{
-return AVERROR_EOF;
 }
-} else { // submit frame
+} else if (!ctx->delayed_surface) { // submit frame
 int hw_surface = 0;
 
-if (ctx->delayed_surface != NULL) {
-return AVERROR(EAGAIN); // should not happen when called from 
ffmpeg, other clients may resubmit
-}
 // prepare surface from frame
 switch (frame->format) {
 #if CONFIG_D3D11VA
@@ -693,38 +699,23 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 break;
 }
 
-
 // submit surface
 res = ctx->encoder->pVtbl->SubmitInput(ctx->encoder, 
(AMFData*)surface);
 if (res == AMF_INPUT_FULL) { // handle full queue
 //store surface for later submission
 ctx->delayed_surface = surface;
-if (surface->pVtbl->GetMemoryType(surface) == AMF_MEMORY_DX11) {
-av_frame_ref(ctx->delayed_frame, frame);
-}
 } else {
+int64_t pts = frame->pts;
 surface->pVtbl->Release(surface);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
"SubmitInput() failed with error %d\n", res);
 
-if ((ret = timestamp_queue_enqueue(avctx, frame->pts)) < 0) {
+av_frame_unref(frame);
+if ((ret = timestamp_queue_enqueue(avctx, pts)) < 0) {
 return ret;
 }
-
 }
 }
-return 0;
-}
-int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
-{
-int ret;
-AMF_RESULT  res;
-AMF_

[FFmpeg-devel] [PATCH v10 2/4] avcodec/hevc_sei: add support for user data unregistered SEI message

2020-06-09 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/hevc_sei.c   | 31 +++
 libavcodec/hevc_sei.h   |  6 ++
 libavcodec/hevcdec.c| 14 ++
 tests/ref/fate/hevc-monochrome-crop |  3 +++
 4 files changed, 54 insertions(+)

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 6057069..e3d6bc9 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -213,6 +213,30 @@ static int 
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
 return 0;
 }
 
+static int decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s, 
GetBitContext *gb,
+  int size)
+{
+AVBufferRef *buf_ref, **tmp;
+
+if (size < 16)
+   return AVERROR(EINVAL);
+
+tmp = av_realloc_array(s->buf_ref, s->nb_buf_ref + 1, sizeof(*s->buf_ref));
+if (!tmp)
+return AVERROR(ENOMEM);
+s->buf_ref = tmp;
+
+buf_ref = av_buffer_alloc(size);
+if (!buf_ref)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < size; i++)
+buf_ref->data[i] = get_bits(gb, 8);
+s->buf_ref[s->nb_buf_ref++] = buf_ref;
+
+return 0;
+}
+
 static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, 
GetBitContext *gb,
  int size)
 {
@@ -300,6 +324,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb, void 
*logctx, HEVCSEI *s,
 return decode_nal_sei_active_parameter_sets(s, gb, logctx);
 case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
 return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
+case HEVC_SEI_TYPE_USER_DATA_UNREGISTERED:
+return decode_nal_sei_user_data_unregistered(&s->unregistered, gb, 
size);
 case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
 return decode_nal_sei_alternative_transfer(&s->alternative_transfer, 
gb);
 default:
@@ -371,4 +397,9 @@ int ff_hevc_decode_nal_sei(GetBitContext *gb, void *logctx, 
HEVCSEI *s,
 void ff_hevc_reset_sei(HEVCSEI *s)
 {
 av_buffer_unref(&s->a53_caption.buf_ref);
+
+for (int i = 0; i < s->unregistered.nb_buf_ref; i++)
+av_buffer_unref(&s->unregistered.buf_ref[i]);
+s->unregistered.nb_buf_ref = 0;
+av_freep(&s->unregistered.buf_ref);
 }
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index a44ccca..3618d16 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -91,6 +91,11 @@ typedef struct HEVCSEIA53Caption {
 AVBufferRef *buf_ref;
 } HEVCSEIA53Caption;
 
+typedef struct HEVCSEIUnregistered {
+AVBufferRef **buf_ref;
+int nb_buf_ref;
+} HEVCSEIUnregistered;
+
 typedef struct HEVCSEIMasteringDisplay {
 int present;
 uint16_t display_primaries[3][2];
@@ -116,6 +121,7 @@ typedef struct HEVCSEI {
 HEVCSEIDisplayOrientation display_orientation;
 HEVCSEIPictureTiming picture_timing;
 HEVCSEIA53Caption a53_caption;
+HEVCSEIUnregistered unregistered;
 HEVCSEIMasteringDisplay mastering_display;
 HEVCSEIContentLight content_light;
 int active_seq_parameter_set_id;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 0772608..c9e28f5 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2794,6 +2794,20 @@ static int set_side_data(HEVCContext *s)
 s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+for (int i = 0; i < s->sei.unregistered.nb_buf_ref; i++) {
+HEVCSEIUnregistered *unreg = &s->sei.unregistered;
+
+if (unreg->buf_ref[i]) {
+AVFrameSideData *sd = av_frame_new_side_data_from_buf(out,
+AV_FRAME_DATA_SEI_UNREGISTERED,
+unreg->buf_ref[i]);
+if (!sd)
+av_buffer_unref(&unreg->buf_ref[i]);
+unreg->buf_ref[i] = NULL;
+}
+}
+s->sei.unregistered.nb_buf_ref = 0;
+
 return 0;
 }
 
diff --git a/tests/ref/fate/hevc-monochrome-crop 
b/tests/ref/fate/hevc-monochrome-crop
index 4e45412..384404d 100644
--- a/tests/ref/fate/hevc-monochrome-crop
+++ b/tests/ref/fate/hevc-monochrome-crop
@@ -1,6 +1,9 @@
 [FRAME]
 width=384
 height=240
+[SIDE_DATA]
+side_data_type=H.26[45] User Data Unregistered SEI message
+[/SIDE_DATA]
 [/FRAME]
 [STREAM]
 width=384
-- 
1.8.3.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".

[FFmpeg-devel] [PATCH v10 3/4] avcodec/hevc_sei: add support for user data unregistered SEI message

2020-06-09 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/vf_showinfo.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 5d4aee4..9eaf8ff 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -23,6 +23,7 @@
  */
 
 #include 
+#include 
 
 #include "libavutil/bswap.h"
 #include "libavutil/adler32.h"
@@ -190,6 +191,39 @@ static void dump_video_enc_params(AVFilterContext *ctx, 
AVFrameSideData *sd)
 av_log(ctx, AV_LOG_INFO, "%u blocks; ", par->nb_blocks);
 }
 
+static int string_is_print(const uint8_t *str)
+{
+while (isprint(*str)) str++;
+return !*str;
+}
+
+static void dump_sei_unregistered_metadata(AVFilterContext *ctx, 
AVFrameSideData *sd)
+{
+const int uuid_size = 16;
+uint8_t *user_data = sd->data;
+
+if (sd->size < uuid_size) {
+av_log(ctx, AV_LOG_ERROR, "invalid data(%d < UUID(%d-bytes))", 
sd->size, uuid_size);
+return;
+}
+
+av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
+av_log(ctx, AV_LOG_INFO, "UUID=");
+for (int i = 0; i < uuid_size; i++) {
+av_log(ctx, AV_LOG_INFO, "%02x", user_data[i]);
+if (i == 3 || i == 5 || i == 7 || i == 9)
+av_log(ctx, AV_LOG_INFO, "-");
+}
+av_log(ctx, AV_LOG_INFO, "\n");
+
+user_data += uuid_size;
+/* Only print the user data details if it's string */
+if (string_is_print(user_data)) {
+av_log(ctx, AV_LOG_INFO, "User Data=");
+av_log(ctx, AV_LOG_INFO, "%s", user_data);
+}
+}
+
 static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
 {
 const char *color_range_str = av_color_range_name(frame->color_range);
@@ -375,6 +409,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 case AV_FRAME_DATA_VIDEO_ENC_PARAMS:
 dump_video_enc_params(ctx, sd);
 break;
+case AV_FRAME_DATA_SEI_UNREGISTERED:
+dump_sei_unregistered_metadata(ctx, sd);
+break;
 default:
 av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
sd->type, sd->size);
-- 
1.8.3.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".

[FFmpeg-devel] [PATCH v10 4/4] avcodec/h264: create user data unregistered SEI side data for H.264

2020-06-09 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/h264_sei.c |  30 +--
 libavcodec/h264_sei.h |   2 +
 libavcodec/h264_slice.c   |  14 
 tests/ref/fate/mov-zombie | 195 ++
 4 files changed, 171 insertions(+), 70 deletions(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 870dd90..0d96fcb 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -24,6 +24,7 @@
  * H.264 / AVC / MPEG-4 part10 SEI decoding.
  * @author Michael Niedermayer 
  */
+#include 
 
 #include "avcodec.h"
 #include "get_bits.h"
@@ -52,6 +53,10 @@ void ff_h264_sei_uninit(H264SEIContext *h)
 h->afd.present =  0;
 
 av_buffer_unref(&h->a53_caption.buf_ref);
+for (int i = 0; i < h->unregistered.nb_buf_ref; i++)
+av_buffer_unref(&h->unregistered.buf_ref[i]);
+h->unregistered.nb_buf_ref = 0;
+av_freep(&h->unregistered.buf_ref);
 }
 
 int ff_h264_sei_process_picture_timing(H264SEIPictureTiming *h, const SPS *sps,
@@ -255,30 +260,45 @@ static int decode_registered_user_data(H264SEIContext *h, 
GetBitContext *gb,
 return 0;
 }
 
+static int string_is_print(const uint8_t *str)
+{
+while (isprint(*str)) str++;
+return !*str;
+}
+
 static int decode_unregistered_user_data(H264SEIUnregistered *h, GetBitContext 
*gb,
  void *logctx, int size)
 {
 uint8_t *user_data;
 int e, build, i;
+AVBufferRef *buf_ref, **tmp;
 
-if (size < 16 || size >= INT_MAX - 1)
+if (size < 16)
 return AVERROR_INVALIDDATA;
 
-user_data = av_malloc(size + 1);
-if (!user_data)
+tmp = av_realloc_array(h->buf_ref, h->nb_buf_ref + 1, sizeof(*h->buf_ref));
+if (!tmp)
 return AVERROR(ENOMEM);
+h->buf_ref = tmp;
+
+buf_ref = av_buffer_alloc(size);
+if (!buf_ref)
+return AVERROR(ENOMEM);
+user_data = buf_ref->data;
 
 for (i = 0; i < size; i++)
 user_data[i] = get_bits(gb, 8);
+h->buf_ref[h->nb_buf_ref++] = buf_ref;
+
+if (!string_is_print(user_data + 16))
+return 0;
 
-user_data[i] = 0;
 e = sscanf(user_data + 16, "x264 - core %d", &build);
 if (e == 1 && build > 0)
 h->x264_build = build;
 if (e == 1 && build == 1 && !strncmp(user_data+16, "x264 - core ", 16))
 h->x264_build = 67;
 
-av_free(user_data);
 return 0;
 }
 
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index f07a505..4fdcf4e 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -126,6 +126,8 @@ typedef struct H264SEIA53Caption {
 
 typedef struct H264SEIUnregistered {
 int x264_build;
+AVBufferRef **buf_ref;
+int nb_buf_ref;
 } H264SEIUnregistered;
 
 typedef struct H264SEIRecoveryPoint {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 7139537..47f3917 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1289,6 +1289,20 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+for (int i = 0; i < h->sei.unregistered.nb_buf_ref; i++) {
+H264SEIUnregistered *unreg = &h->sei.unregistered;
+
+if (unreg->buf_ref[i]) {
+AVFrameSideData *sd = av_frame_new_side_data_from_buf(cur->f,
+AV_FRAME_DATA_SEI_UNREGISTERED,
+unreg->buf_ref[i]);
+if (!sd)
+av_buffer_unref(&unreg->buf_ref[i]);
+unreg->buf_ref[i] = NULL;
+}
+}
+h->sei.unregistered.nb_buf_ref = 0;
+
 if (h->sei.picture_timing.timecode_cnt > 0) {
 uint32_t tc = 0;
 uint32_t *tc_sd;
diff --git a/tests/ref/fate/mov-zombie b/tests/ref/fate/mov-zombie
index 445f921..1a6625b 100644
--- a/tests/ref/fate/mov-zombie
+++ b/tests/ref/fate/mov-zombie
@@ -1,133 +1,198 @@
 
packet|codec_type=video|stream_index=0|pts=0|pts_time=0.00|dts=-3004|dts_time=-0.033378|duration=3003|duration_time=0.033367|convergence_duration=N/A|convergence_duration_time=N/A|size=4133|pos=11309|flags=K_
 
packet|codec_type=video|stream_index=0|pts=5440|pts_time=0.060444|dts=-567|dts_time=-0.006300|duration=3003|duration_time=0.033367|convergence_duration=N/A|convergence_duration_time=N/A|size=1077|pos=15442|flags=__
-frame|media_type=video|stream_index=0|key_frame=1|pkt_pts=0|pkt_pts_time=0.00|pkt_dts=-567|pkt_dts_time=-0.006300|best_effort_timestamp=0|best_effort_timestamp_time=0.00|pkt_duration=3003|pkt_duration_time=0.033367|pkt_pos=11309|pkt_size=4133|width=160|height=240|pix_fmt=yuv420p|sample_aspect_ratio=2:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=tv|color_space=smpte170m|color_primaries=smpte170m|color_transfer=bt709|chroma_location=topleft
+frame|media_type=video|stream_index=0|key_frame=1|pkt_pts=0|pkt_pts_time=0.00|pkt_dts=-567|pkt_dts_time=-0.006300|best_effort_timestamp=0|b

[FFmpeg-devel] [PATCH v10 1/4] avutil: add AV_FRAME_DATA_SEI_UNREGISTERED side data type

2020-06-09 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
rebase with master only, I'll apply the patchset in two days if no objection.

 doc/APIchanges  | 3 +++
 libavutil/frame.c   | 1 +
 libavutil/frame.h   | 8 
 libavutil/version.h | 2 +-
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 70579df..08cdbda 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-06-xx - xx - lavu 56.53.100 - frame.h
+  Add AV_FRAME_DATA_SEI_UNREGISTERED.
+
 2020-06-05 - ec39c2276a - lavu 56.50.100 - buffer.h
   Passing NULL as alloc argument to av_buffer_pool_init2() is now allowed.
 
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 2e952ed..9884eae 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -851,6 +851,7 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata 
SMPTE2094-40 (HDR10+)";
 case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
 case AV_FRAME_DATA_VIDEO_ENC_PARAMS:return "Video encoding 
parameters";
+case AV_FRAME_DATA_SEI_UNREGISTERED:return "H.26[45] User Data 
Unregistered SEI message";
 }
 return NULL;
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index fc67db0..3fb8c56 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -184,6 +184,14 @@ enum AVFrameSideDataType {
  * Encoding parameters for a video frame, as described by AVVideoEncParams.
  */
 AV_FRAME_DATA_VIDEO_ENC_PARAMS,
+
+/**
+ * User data unregistered metadata associated with a video frame.
+ * This is the H.26[45] UDU SEI message, and shouldn't be used for any 
other purpose
+ * The data is stored as uint8_t in AVFrameSideData.data which is 16 bytes 
of
+ * uuid_iso_iec_11578 followed by AVFrameSideData.size - 16 bytes of 
user_data_payload_byte.
+ */
+AV_FRAME_DATA_SEI_UNREGISTERED,
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 652e1e9..e75e625 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  52
+#define LIBAVUTIL_VERSION_MINOR  53
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
1.8.3.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".

[FFmpeg-devel] [PATCH] avisynth: more intelligent RGB flipping

2020-06-09 Thread Stephen Hutchinson
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available since 2.6. This means that
GetProcAddress doesn't have to run on every frame.
---
Also should probably be applied to the 4.3 branch as well.

 libavformat/avisynth.c | 27 +--
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 2c08ace8db..f029a0e842 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -57,6 +57,7 @@ typedef struct AviSynthLibrary {
 AVSC_DECLARE_FUNC(avs_get_version);
 AVSC_DECLARE_FUNC(avs_get_video_info);
 AVSC_DECLARE_FUNC(avs_invoke);
+AVSC_DECLARE_FUNC(avs_is_color_space);
 AVSC_DECLARE_FUNC(avs_release_clip);
 AVSC_DECLARE_FUNC(avs_release_value);
 AVSC_DECLARE_FUNC(avs_release_video_frame);
@@ -133,6 +134,7 @@ static av_cold int avisynth_load_library(void)
 LOAD_AVS_FUNC(avs_get_version, 0);
 LOAD_AVS_FUNC(avs_get_video_info, 0);
 LOAD_AVS_FUNC(avs_invoke, 0);
+LOAD_AVS_FUNC(avs_is_color_space, 0);
 LOAD_AVS_FUNC(avs_release_clip, 0);
 LOAD_AVS_FUNC(avs_release_value, 0);
 LOAD_AVS_FUNC(avs_release_video_frame, 0);
@@ -628,7 +630,6 @@ static int avisynth_read_packet_video(AVFormatContext *s, 
AVPacket *pkt,
 const unsigned char *src_p;
 int n, i, plane, rowsize, planeheight, pitch, bits, ret;
 const char *error;
-int avsplus av_unused;
 
 if (avs->curr_frame >= avs->vi->num_frames)
 return AVERROR_EOF;
@@ -638,19 +639,6 @@ static int avisynth_read_packet_video(AVFormatContext *s, 
AVPacket *pkt,
 if (discard)
 return 0;
 
-#ifdef _WIN32
-/* Detect whether we're using AviSynth 2.6 or AviSynth+ by
- * looking for whether avs_is_planar_rgb exists. */
-if (GetProcAddress(avs_library.library, "avs_is_planar_rgb") == NULL)
-avsplus = 0;
-else
-avsplus = 1;
-#else
-/* AviSynth+ is now the only variant of AviSynth we support
- * on Linux and macOS. */
-avsplus = 1;
-#endif
-
 bits = avs_library.avs_bits_per_pixel(avs->vi);
 
 /* Without the cast to int64_t, calculation overflows at about 9k x 9k
@@ -687,14 +675,9 @@ static int avisynth_read_packet_video(AVFormatContext *s, 
AVPacket *pkt,
 planeheight = avs_library.avs_get_height_p(frame, plane);
 
 /* Flip RGB video. */
-if (avs_is_rgb24(avs->vi) || avs_is_rgb(avs->vi)) {
-src_p = src_p + (planeheight - 1) * pitch;
-pitch = -pitch;
-}
-
-/* Flip Planar RGB video */
-if (avsplus && (avs_library.avs_is_planar_rgb(avs->vi) ||
-avs_library.avs_is_planar_rgba(avs->vi))) {
+if (avs_library.avs_is_color_space(avs->vi, AVS_CS_BGR)   ||
+avs_library.avs_is_color_space(avs->vi, AVS_CS_BGR48) ||
+avs_library.avs_is_color_space(avs->vi, AVS_CS_BGR64)) {
 src_p = src_p + (planeheight - 1) * pitch;
 pitch = -pitch;
 }
-- 
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 1/5] avformat/aviobuf: Don't check for overflow after it happened

2020-06-09 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> If adding two ints overflows, it doesn't matter whether the result will
> be stored in an unsigned or not; and checking afterwards does not make it
> retroactively defined.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/aviobuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index eb0387bdf7..33c2d6f037 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -1275,7 +1275,7 @@ static int dyn_buf_write(void *opaque, uint8_t *buf, 
> int buf_size)
>  unsigned new_size, new_allocated_size;
>  
>  /* reallocate buffer if needed */
> -new_size = d->pos + buf_size;
> +new_size = (unsigned)d->pos + buf_size;
>  new_allocated_size = d->allocated_size;
>  if (new_size < d->pos || new_size > INT_MAX/2)
>  return -1;
> 
Will apply this patchset tomorrow unless there are objections.

- Andreas
___
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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

2020-06-09 Thread Fu, Linjie
> From: Devin Heitmueller 
> Sent: Tuesday, June 9, 2020 23:47
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] fftools/ffmpeg: flush and recreate
> encoder instance if resolution changes
> 
> On Tue, Jun 9, 2020 at 4:53 AM Linjie Fu  wrote:
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > Should be squashed with:
> > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434
> >
> >  fftools/ffmpeg.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 5859781..8cdd532 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int
> frame_size);
> >  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
> >  static int64_t getmaxrss(void);
> >  static int ifilter_has_all_input_formats(FilterGraph *fg);
> > +static void flush_encoders(void);
> >
> >  static int run_as_daemon  = 0;
> >  static int nb_frames_dup = 0;
> > @@ -1058,11 +1059,21 @@ static void do_video_out(OutputFile *of,
> >
> >  if (next_picture && (enc->width != next_picture->width ||
> >   enc->height != next_picture->height)) {
> > +flush_encoders();
> > +avcodec_flush_buffers(enc);
> >  if (!(enc->codec->capabilities &
> AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
> >  av_log(NULL, AV_LOG_ERROR, "Variable dimension encoding "
> >  "is not supported by %s.\n", enc->codec->name);
> >  goto error;
> >  }
> > +
> > +enc->width  = next_picture->width;
> > +enc->height = next_picture->height;
> 
> Perhaps from a workflow standpoint it makes more sense to move the
> code which changes the encoder parameters to after where you close the
> existing encoder (i.e. between the close and init calls).  I can't
> think of a specific case where this might break a downstream encoder,
That's the reason I simply set the width/height ahead.
> but it seems like a good practice to only have the parameters applied
> to the new encoder instance.
Indeed, fixed locally.

> > +
> > +if (enc->codec->close(enc) < 0)
> > +goto error;
> > +if (enc->codec->init(enc) < 0)
> > +goto error;
> >  }
> >
> >  if (ost->source_index >= 0)
> 
> In general do we really think this is a safe thing to do?  Does
> something also need to be propagated to the output as well?  I know
> that this would break use cases like the decklink output where the
> frame resolution suddenly changes in the middle of the stream without
> calling the output's write_header() routine.

Yes, noticed the constraints in sequence header and container.

Since resolution changing is allowed in single bitstream, one global header is 
not
enough anymore as Nicolas has pointed out in [1].

Hence as to the container level,  for the formats with AVFMT_GLOBALHEADER flag,
we should place sps/pps information in key frame instead of in extradata.
(e.g. disable AV_CODEC_FLAG_GLOBAL_HEADER)

-if (oc->oformat->flags & AVFMT_GLOBALHEADER)
+if (oc->oformat->flags & AVFMT_GLOBALHEADER && ost->autoscale)
 ost->enc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER; 

Verified this works, at least for containers like mp4.

- Linjie

[1] 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1591606685-4450-1-git-send-email-linjie...@intel.com/#55293

___
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 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

2020-06-09 Thread James Almer
On 6/9/2020 5:48 AM, Linjie Fu wrote:
> Signed-off-by: Linjie Fu 
> ---
> Should be squashed with:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434
> 
>  fftools/ffmpeg.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 5859781..8cdd532 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int 
> frame_size);
>  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
>  static int64_t getmaxrss(void);
>  static int ifilter_has_all_input_formats(FilterGraph *fg);
> +static void flush_encoders(void);
>  
>  static int run_as_daemon  = 0;
>  static int nb_frames_dup = 0;
> @@ -1058,11 +1059,21 @@ static void do_video_out(OutputFile *of,
>  
>  if (next_picture && (enc->width != next_picture->width ||
>   enc->height != next_picture->height)) {
> +flush_encoders();
> +avcodec_flush_buffers(enc);

This only works for a limited amount of encoders that set the
AV_CODEC_CAP_ENCODER_FLUSH codec capability, and it's a no-op after
emitting a warning otherwise.

>  if (!(enc->codec->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
>  av_log(NULL, AV_LOG_ERROR, "Variable dimension encoding "
>  "is not supported by %s.\n", enc->codec->name);
>  goto error;
>  }
> +
> +enc->width  = next_picture->width;
> +enc->height = next_picture->height;
> +
> +if (enc->codec->close(enc) < 0)
> +goto error;
> +if (enc->codec->init(enc) < 0)
> +goto error;
>  }
>  
>  if (ost->source_index >= 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".

Re: [FFmpeg-devel] [Please Ignore] send test

2020-06-09 Thread 黄思远
___
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] [Please Ignore] reply test

2020-06-09 Thread Siyuan Huang
Just test how reply in Pipermail 0.09 (Mailman edition).

Please ignore it . 

Sorry to bother you 

___
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] [Please Ignore] reply test

2020-06-09 Thread Siyuan Huang
Reply test

 

From: Siyuan Huang  
Sent: 2020年6月10日 12:56
To: 'ffmpeg-devel@ffmpeg.org' 
Subject: [FFmpeg-devel] [Please Ignore] reply test

 

Just test how reply in Pipermail 0.09 (Mailman edition).

Please ignore it . 

Sorry to bother you 

___
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] [Please Ignore] reply test

2020-06-09 Thread Siyuan Huang
Reply test level 2

 

From: Siyuan Huang  
Sent: 2020年6月10日 12:58
To: 'ffmpeg-devel@ffmpeg.org' 
Subject: RE: [FFmpeg-devel] [Please Ignore] reply test

 

Reply test

 

From: Siyuan Huang mailto:saber.hu...@samsung.com>
> 
Sent: 2020年6月10日 12:56
To: 'ffmpeg-devel@ffmpeg.org' mailto:ffmpeg-devel@ffmpeg.org> >
Subject: [FFmpeg-devel] [Please Ignore] reply test

 

Just test how reply in Pipermail 0.09 (Mailman edition).

Please ignore it . 

Sorry to bother you 

___
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] [Please Ignore] reply test

2020-06-09 Thread Siyuan Huang
Reply in level2 child 

 

From: Siyuan Huang  
Sent: 2020年6月10日 12:58
To: 'ffmpeg-devel@ffmpeg.org' 
Subject: RE: [FFmpeg-devel] [Please Ignore] reply test

 

Reply test

 

From: Siyuan Huang mailto:saber.hu...@samsung.com>
> 
Sent: 2020年6月10日 12:56
To: 'ffmpeg-devel@ffmpeg.org' mailto:ffmpeg-devel@ffmpeg.org> >
Subject: [FFmpeg-devel] [Please Ignore] reply test

 

Just test how reply in Pipermail 0.09 (Mailman edition).

Please ignore it . 

Sorry to bother you 

___
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] libavformat/dashenc.c:add support to change mpd update interval

2020-06-09 Thread Siyuan Huang
Hello Mr. Moritz

 

I update docs . and here is the latest patch .

 

 

Ps: when I test doc file , muxers.texi

It show some warning by 

root@saber:/ffmpeg# makeinfo --html --no-split -o muext.html doc/muxers.texi

doc/muxers.texi:1948: @ref reference to nonexistent node `concat'

doc/muxers.texi:2357: @ref reference to nonexistent node `Format

stream specifiers

 

look the doc have some issue before add my patch, please info related guys
update  it .

 

B.R

Huang Siyuan

 



0001-libavformat-dashenc.c-add-support-to-change-mpd-upda.patch
Description: Binary data
___
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] libavformat/dashenc.c:add support to change mpd update interval

2020-06-09 Thread Siyuan Huang
Hello Mr. Moritz

 

I update docs . and here is the latest patch .

 

 

Ps: when I test doc file , muxers.texi

It show some warning by 

root@saber:/ffmpeg# makeinfo --html --no-split -o muext.html doc/muxers.texi

doc/muxers.texi:1948: @ref reference to nonexistent node `concat'

doc/muxers.texi:2357: @ref reference to nonexistent node `Format

stream specifiers

 

look the doc have some issue before add my patch, please info related guys
update  it .

 

B.R

Huang Siyuan

 



0001-libavformat-dashenc.c-add-support-to-change-mpd-upda.patch
Description: Binary data
___
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] OS/2:Support linking against libcx

2020-06-09 Thread Dave Yeo
Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build 
break in libavformat/ip.c (implicit declaration of function 
'getaddrinfo') and also need the prototype.

Thanks,
Dave
From f9fbdaaf6cdb6f886cbdf31c1983e452567cd857 Mon Sep 17 00:00:00 2001
From: Dave Yeo 
Date: Tue, 9 Jun 2020 22:51:53 -0700
Subject: [PATCH] OS/2:Support linking against libcx

Libcx contains extensions to libc such as getaddrinfo(), mmap() and poll(). While recommended to link against, it is optional

Signed-off-by: Dave Yeo 
---
 configure| 1 +
 libavformat/os_support.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/configure b/configure
index 8569a60bf8..24ad990b52 100755
--- a/configure
+++ b/configure
@@ -5997,6 +5997,7 @@ if ! disabled network; then
 check_func inet_aton $network_extralibs
 
 check_type netdb.h "struct addrinfo"
+check_type libcx/net.h "struct addrinfo"
 check_type netinet/in.h "struct group_source_req" -D_BSD_SOURCE
 check_type netinet/in.h "struct ip_mreq_source" -D_BSD_SOURCE
 check_type netinet/in.h "struct ipv6_mreq" -D_DARWIN_C_SOURCE
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 5e6b32d2dc..1904fc8d5d 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -56,6 +56,9 @@
 #  define fstat(f,s) _fstati64((f), (s))
 #endif /* defined(_WIN32) */
 
+#if defined (__OS2__) && defined (HAVE_GETADDRINFO)
+#include 
+#endif
 
 #ifdef __ANDROID__
 #  if HAVE_UNISTD_H
-- 
2.11.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".

Re: [FFmpeg-devel] [PATCH 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

2020-06-09 Thread Fu, Linjie
> From: ffmpeg-devel  On Behalf Of
> James Almer
> Sent: Wednesday, June 10, 2020 12:22
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] fftools/ffmpeg: flush and recreate
> encoder instance if resolution changes
> 
> On 6/9/2020 5:48 AM, Linjie Fu wrote:
> > Signed-off-by: Linjie Fu 
> > ---
> > Should be squashed with:
> > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434
> >
> >  fftools/ffmpeg.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 5859781..8cdd532 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int
> frame_size);
> >  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
> >  static int64_t getmaxrss(void);
> >  static int ifilter_has_all_input_formats(FilterGraph *fg);
> > +static void flush_encoders(void);
> >
> >  static int run_as_daemon  = 0;
> >  static int nb_frames_dup = 0;
> > @@ -1058,11 +1059,21 @@ static void do_video_out(OutputFile *of,
> >
> >  if (next_picture && (enc->width != next_picture->width ||
> >   enc->height != next_picture->height)) {
> > +flush_encoders();
> > +avcodec_flush_buffers(enc);
> 
> This only works for a limited amount of encoders that set the
> AV_CODEC_CAP_ENCODER_FLUSH codec capability, and it's a no-op after
> emitting a warning otherwise.

Yes, hence would like to declare VARIABLE_DIMENSIONS and ENCODER_FLUSH
capability for encoders as well:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1591692568-19385-1-git-send-email-linjie...@intel.com/

 - Linjie
___
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] Reply-To: RE: [Please Ignore] reply test

2020-06-09 Thread Siyuan Huang
Reply test

___
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] libavformat/dashenc.c:add support to change mpd update interval

2020-06-09 Thread 黄思远


0001-libavformat-dashenc.c-add-support-to-change-mpd-upda.patch
Description: Binary data
___
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] libavformat/dashenc.c:add support to change mpd update interval

2020-06-09 Thread Siyuan Huang
I have trouble with mailman email system . 

My company email client can reply email . but looks mailman can not read out
text content . and it will add a warning picture automatically .

And third part email client such as outlook , though it works with text
content without warning pitcture. but It can not reply to specific mail loop
..

 

I'm trying make all works . But if you can give some suggestion for mailman
client . it's much better 

___
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] libavformat/dashenc.c:add support to change mpd update interval

2020-06-09 Thread 黄思远


0001-libavformat-dashenc.c-add-support-to-change-mpd-upda.patch
Description: Binary data
___
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".