Re: [FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[James Almer]

On 4/5/2018 5:02 PM, Paul B Mahol wrote:
> On 4/3/18, Bodecs Bela  wrote:
>> Dear All,
>>
>> I added some more information about default value of bind_address option
>> and its abbreviated
>> version (b). I modified the example to have named instanced filter and
>> to show
>> its use.
>>
>> please review this patch.
>>
>> thanky you in advance,
>>
>> best regards,
>>
>> Bela Bodecs
>>
>>
> 
> anybody, please apply this.

You're more than qualified to do it yourself...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[Lou Logan]

On Thu, Apr 5, 2018, at 12:04 PM, Lou Logan wrote:
>
> It needs some minor work. I will plan to fix and apply later today.

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

Re: [FFmpeg-devel] [PATCH] [RFC]doc/examples: alternative input handler

[wm4]

On Fri, 30 Mar 2018 14:47:25 +0200
Bodecs Bela  wrote:

> Hi All,
> 
> regularly, on different forums and mailing lists a requirement popups 
> for a feature to automatically failover switching between main input and a
> secondary input in case of main input unavailability.
> 
> The base motivation: let's say you have a unreliable live stream source 
> and you
> want to transcode its video and audio streams in realtime but you
> want to survive the ocasions when the source is unavailable. So use a
> secondary live source but the transition should occur seamlessly without
> breaking/re-starting the transcoding processs.
> 
> Some days ago there was a discussion on devel-irc about this topic and 
> we concluded that this feature is not feasible inside ffmpeg without 
> "hacking", but a separate client app could do this.
> 
> So I created this example app to handle two separate input sources and 
> switching realtime between them. I am not sure wheter it should be 
> inside the tools subdir.
> 
> The detailed description is available in the header section of the 
> source file.
> 
> I will appretiate your suggestions about it.
> 
> Thank you in advance.
> 
> best,
> 
> Bela Bodecs
> 
> 

Does this really quality as example? It's way too complex and seems to
be about a specific use case in place of ffmpeg.c, rather than
demonstrating API use in an educational way (what code examples are
supposed to do).

If someone wants to merge this, at least add it as top level program,
and not under the examples directory.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] display: Add AVDisplayOrientation API

[Michael Niedermayer]

On Thu, Apr 05, 2018 at 01:51:10PM +0200, Vittorio Giovara wrote:
> ---
> > On Wed, Apr 04, 2018 at 05:30:24PM +0200, Vittorio Giovara wrote:
> > >  libavutil/display.c | 92 
> > > +
> > >  libavutil/display.h | 53 ++
> > >  2 files changed, 145 insertions(+)
> 
> > It might be more usefull to fully factorize the matrix than these 
> > special cases
> > 
> > for example the matrix can be described by these 4 scalars
> > 1. rotation
> > 2. horizontal scale
> > 3. vertical scale
> > 4. shear
> 
> With the proposed API the matrix is already factorized: a mask is returned
> containing a set of  operation. Special cases such as custom rotation is
> already factorized, as in you need to call an additional function on the
> same matrix to know more about the rotation angle. On the other hand the
> most common cases are already ready to be used right away.

no, the proposed API is not equivalent if thats what you mean.

What i suggest gives a single unique factorization represented by 4 scalar 
values

The API proposed prior does not gurantee a unique result. Instead a single
matrix can be represented by a almost infinite number of operations
In practice this means you cannot test the factorization by a simple
equality check as a single matrix can be factored in many different ways.

Also the prior API has a issue with order of operations. These operations
are not commutative, the order of flip and rotate makes a big difference.
And at this point i do not see what it can even be used for.
The rotation angle is different for example depending on what other operations
are done before and after the rotation for a matrix.


[...]
> 
> > (there are more parameters like translation and z specific changes but 
> > IIUC
> >   these have no meaning ?)
> 
> Correct given that video right now is a 2d surface we can ignore anything
> related to the depth axis.
> 
> > Note fliping in above would be a negative scale value
> > shear could be specified as the angle between the x/y basis vectors
> > 
> > The reason i suggest this is that these 4 values are easier to 
> > understand
> > for a human and should allow reconstructing an equivalent transform 
> > matrix.
> > While at the same time not limiting things to a subset of special cases
> > 
> 
> The "special cases" are also the most common operations that every player
> implements so I think it makes sense to have them readily available, with
> as few calls as possible.

With what i suggest, not sure i explained it well enough
there would be a single call to provide a struct or array of 4 scalars
a 90 degree to the right rotation would for example have a
{90, 1, 1, 0} and could be checked for by memcmp() or a more specialized
function that returns a scalar "difference"
so testing for these common operations should be very simple and compact.
Testing for another angle of rotation or other transform would be similarly
simple.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] [RFC]doc/examples: alternative input handler

[Michael Niedermayer]

On Fri, Mar 30, 2018 at 02:47:25PM +0200, Bodecs Bela wrote:
> Hi All,
> 
> regularly, on different forums and mailing lists a requirement popups for a
> feature to automatically failover switching between main input and a
> secondary input in case of main input unavailability.
> 
> The base motivation: let's say you have a unreliable live stream source and
> you
> want to transcode its video and audio streams in realtime but you
> want to survive the ocasions when the source is unavailable. So use a
> secondary live source but the transition should occur seamlessly without
> breaking/re-starting the transcoding processs.
> 
> Some days ago there was a discussion on devel-irc about this topic and we
> concluded that this feature is not feasible inside ffmpeg without "hacking",
> but a separate client app could do this.
> 
> So I created this example app to handle two separate input sources and
> switching realtime between them. I am not sure wheter it should be inside
> the tools subdir.
> 
> The detailed description is available in the header section of the source
> file.
> 
> I will appretiate your suggestions about it.
> 
> Thank you in advance.
> 
> best,
> 
> Bela Bodecs
> 
> 

>  configure|2 
>  doc/examples/Makefile|1 
>  doc/examples/Makefile.example|1 
>  doc/examples/alternative_input.c | 1233 
> +++

You may want to add yourself to MAINTAINERS, so it is not unmaintained
I think this is complex enough that it needs a maintainer


[...]

> +static int open_single_input(int input_index)
> +{
> +int ret, i;
> +AVInputFormat *input_format = NULL;
> +AVDictionary * input_options = NULL;
> +AVFormatContext * input_fmt_ctx = NULL;
> +
> +if (app_ctx.input_format_names[input_index]) {
> +if (!(input_format = 
> av_find_input_format(app_ctx.input_format_names[input_index]))) {
> +timed_log(AV_LOG_ERROR, "Input #%d Unknown input format: 
> '%s'\n", input_index,
> +  app_ctx.input_format_names[input_index]);
> +return EINVAL;
> +}
> +}
> +
> +av_dict_set(_options, "rw_timeout", "200", 0);
> +av_dict_set(_options, "timeout", "2000", 0);

> +if ((app_ctx.input_fmt_ctx[input_index] = avformat_alloc_context()) < 0)
> +return AVERROR(ENOMEM);

i guess this was intended to be "!= NULL"

also you are mixing EINVAL with AVERROR(ENOMEM) these arent compatible. 
Either all should be AVERROR or none

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Stricter heuristic for auto-detection.

[Carl Eugen Hoyos]

2018-04-05 20:08 GMT+02:00, Michael Niedermayer :
> On Thu, Apr 05, 2018 at 12:45:18AM +0200, Carl Eugen Hoyos wrote:

>>  amr.c |   10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>> 64ad2690251aff3bf4ce981e2b09e5102df0ba44
>> 0001-lavf-amr-Stricter-heuristic-for-auto-detection.patch
>> From 26712381d7dc3d3dfc623a77a80a697ffcd54124 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Thu, 5 Apr 2018 00:41:55 +0200
>> Subject: [PATCH] lavf/amr: Stricter heuristic for auto-detection.
>>
>> Fixes ticket #7125.
>
> probably ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] lavfi, lavd: add gitignore for generated static component lists

[Josh de Kock]

On 2018/04/05 22:34, Hendrik Leppkes wrote:

On Thu, Apr 5, 2018 at 11:09 PM, Josh de Kock  wrote:

Signed-off-by: Josh de Kock 
---
  libavdevice/.gitignore | 2 ++
  libavfilter/.gitignore | 1 +
  2 files changed, 3 insertions(+)
  create mode 100644 libavdevice/.gitignore
  create mode 100644 libavfilter/.gitignore

diff --git a/libavdevice/.gitignore b/libavdevice/.gitignore
new file mode 100644
index 00..08ac3eb86a
--- /dev/null
+++ b/libavdevice/.gitignore
@@ -0,0 +1,2 @@
+/indev_list.c
+/outdev_list.c
diff --git a/libavfilter/.gitignore b/libavfilter/.gitignore
new file mode 100644
index 00..26bddebc93
--- /dev/null
+++ b/libavfilter/.gitignore
@@ -0,0 +1 @@
+/filter_list.c
--


LGTM, thanks.


Pushed.

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

Re: [FFmpeg-devel] [PATCH] lavfi, lavd: add gitignore for generated static component lists

[Hendrik Leppkes]

On Thu, Apr 5, 2018 at 11:09 PM, Josh de Kock  wrote:
> Signed-off-by: Josh de Kock 
> ---
>  libavdevice/.gitignore | 2 ++
>  libavfilter/.gitignore | 1 +
>  2 files changed, 3 insertions(+)
>  create mode 100644 libavdevice/.gitignore
>  create mode 100644 libavfilter/.gitignore
>
> diff --git a/libavdevice/.gitignore b/libavdevice/.gitignore
> new file mode 100644
> index 00..08ac3eb86a
> --- /dev/null
> +++ b/libavdevice/.gitignore
> @@ -0,0 +1,2 @@
> +/indev_list.c
> +/outdev_list.c
> diff --git a/libavfilter/.gitignore b/libavfilter/.gitignore
> new file mode 100644
> index 00..26bddebc93
> --- /dev/null
> +++ b/libavfilter/.gitignore
> @@ -0,0 +1 @@
> +/filter_list.c
> --

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

[FFmpeg-devel] [PATCH] lavfi, lavd: add gitignore for generated static component lists

[Josh de Kock]

Signed-off-by: Josh de Kock 
---
 libavdevice/.gitignore | 2 ++
 libavfilter/.gitignore | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 libavdevice/.gitignore
 create mode 100644 libavfilter/.gitignore

diff --git a/libavdevice/.gitignore b/libavdevice/.gitignore
new file mode 100644
index 00..08ac3eb86a
--- /dev/null
+++ b/libavdevice/.gitignore
@@ -0,0 +1,2 @@
+/indev_list.c
+/outdev_list.c
diff --git a/libavfilter/.gitignore b/libavfilter/.gitignore
new file mode 100644
index 00..26bddebc93
--- /dev/null
+++ b/libavfilter/.gitignore
@@ -0,0 +1 @@
+/filter_list.c
-- 
2.14.3 (Apple Git-98)

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

Re: [FFmpeg-devel] [PATCH 1/1] Add Sega FILM muxer

[Josh de Kock]

On 2018/04/02 18:53, mi...@brew.sh wrote:

segafilm muxer


Thanks, pushed. I also clarified with wm4 on IRC that while he was 
against it he wasn't blocking the muxer if someone else pushes it.


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

Re: [FFmpeg-devel] [PATCH] avcodec: v4l2_m2m: reduce the minimum amount of buffers

[Maxime Jourdan]

The AMLogic meson V4L2 M2M I'm developping (https://github.com/Elyotna/linux)
can fare with only one OUTPUT buffer for data input.

Granted, only 1 CAPTURE buffer is probably not going to cut it, but still,
I don't see the reason behind restricting the FFmpeg user to try with 1 (in
the end the driver will adjust the min/max buffers anyway).

2018-04-05 22:14 GMT+02:00 Jorge Ramirez-Ortiz :

> On 04/05/2018 06:42 PM, Maxime Jourdan wrote:
>
>> Reduce the minimum amount of CAPTURE and OUTPUT buffers to 1.
>>
>
> makes sense to me if that is indeed the case.
> could you provide a real life use case?
>
>
>
>> There are drivers that may work with such drastic settings,
>> and FFmpeg doesn't complain.
>> ---
>>  libavcodec/v4l2_m2m.h | 2 +-
>>  libavcodec/v4l2_m2m_dec.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/v4l2_m2m.h b/libavcodec/v4l2_m2m.h
>> index 452bf0d9bc..68e4e5d6c6 100644
>> --- a/libavcodec/v4l2_m2m.h
>> +++ b/libavcodec/v4l2_m2m.h
>> @@ -38,7 +38,7 @@
>>  #define V4L_M2M_DEFAULT_OPTS \
>>  { "num_output_buffers", "Number of buffers in the output context",\
>> -OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 6,
>> INT_MAX, FLAGS }
>> +OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 1,
>> INT_MAX, FLAGS }
>>  typedef struct V4L2m2mContext {
>>  char devname[PATH_MAX];
>> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
>> index bca45be148..5196680bbb 100644
>> --- a/libavcodec/v4l2_m2m_dec.c
>> +++ b/libavcodec/v4l2_m2m_dec.c
>> @@ -198,7 +198,7 @@ static av_cold int v4l2_decode_init(AVCodecContext
>> *avctx)
>>  static const AVOption options[] = {
>>  V4L_M2M_DEFAULT_OPTS,
>>  { "num_capture_buffers", "Number of buffers in the capture context",
>> -OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 20,
>> INT_MAX, FLAGS },
>> +OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 1,
>> INT_MAX, FLAGS },
>>  { NULL},
>>  };
>> --
>> 2.16.2
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: v4l2_m2m: reduce the minimum amount of buffers

[Jorge Ramirez-Ortiz]

On 04/05/2018 06:42 PM, Maxime Jourdan wrote:

Reduce the minimum amount of CAPTURE and OUTPUT buffers to 1.


makes sense to me if that is indeed the case.
could you provide a real life use case?



There are drivers that may work with such drastic settings,
and FFmpeg doesn't complain.
---
 libavcodec/v4l2_m2m.h     | 2 +-
 libavcodec/v4l2_m2m_dec.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/v4l2_m2m.h b/libavcodec/v4l2_m2m.h
index 452bf0d9bc..68e4e5d6c6 100644
--- a/libavcodec/v4l2_m2m.h
+++ b/libavcodec/v4l2_m2m.h
@@ -38,7 +38,7 @@
 #define V4L_M2M_DEFAULT_OPTS \
     { "num_output_buffers", "Number of buffers in the output context",\
-        OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 
6, INT_MAX, FLAGS }
+        OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 
1, INT_MAX, FLAGS }

 typedef struct V4L2m2mContext {
     char devname[PATH_MAX];
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index bca45be148..5196680bbb 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -198,7 +198,7 @@ static av_cold int v4l2_decode_init(AVCodecContext 
*avctx)

 static const AVOption options[] = {
     V4L_M2M_DEFAULT_OPTS,
     { "num_capture_buffers", "Number of buffers in the capture context",
-        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 
20, INT_MAX, FLAGS },
+        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 1, 
INT_MAX, FLAGS },

     { NULL},
 };
--
2.16.2


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

Re: [FFmpeg-devel] avcodec/prores_ks : do not call estimate_alpha at each quantification step

[Martin Vignali]

>
> I will wait few days, if someone have other comments, before pushing.
>
> Martin
>
>
>
Mention the quality improvment in the commit msg, and pushed

Thanks

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

Re: [FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[Lou Logan]

On Thu, Apr 5, 2018, at 12:02 PM, Paul B Mahol wrote:
>
> anybody, please apply this.

It needs some minor work. I will plan to fix and apply later today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[Paul B Mahol]

On 4/3/18, Bodecs Bela  wrote:
> Dear All,
>
> I added some more information about default value of bind_address option
> and its abbreviated
> version (b). I modified the example to have named instanced filter and
> to show
> its use.
>
> please review this patch.
>
> thanky you in advance,
>
> best regards,
>
> Bela Bodecs
>
>

anybody, please apply this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[Bodecs Bela]

ping


2018.04.03. 16:23 keltezéssel, Bodecs Bela írta:

Dear All,

I added some more information about default value of bind_address 
option and its abbreviated
version (b). I modified the example to have named instanced filter and 
to show

its use.

please review this patch.

thanky you in advance,

best regards,

Bela Bodecs



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


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

Re: [FFmpeg-devel] [PATCH] doc: update loglevel option documentation

[Lou Logan]

On Tue, Apr 3, 2018, at 12:30 AM, Tobias Rapp wrote:
> Updates documentation after the changes to loglevel flag prefix parsing
> in 4b736bc921ed96ad6d312ce0cbe0de29b9e3fe81.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  doc/fftools-common-opts.texi | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
[..]
> +Flags can also be used alone by adding a '+'/'-' prefix to set/reset a
> +single flag without affecting other flags or changing the log level. When
> +setting both, flags and level, a '+' separator is expected between last
> +flag and before level.

Confusing. We have the  "-loglevel" option itself, the "level" flag to add the 
current loglevel prefix to the message line (I would have preferred if it were 
named "prefix"), the "loglevel" value, and we also use the generic phrase "log 
level" in the docs.

Also potentially confusing is that the "-/+" prefix is used to set/reset 
individual flags, but "+" is also used as the separator between flags and 
loglevel.

Your quoted paragraph above is unclear to me. Correct me if I'm wrong, but I'm 
thinking it should be worded something like:

Flags can also be used alone by adding a '+'/'-' prefix to set/reset a
single flag without affecting other @var{flags} or changing @var{loglevel}. When
setting both @var{flags} and @var{loglevel}, a '+' separator is expected 
between the last
@var{flags} value and before @var{loglevel}.

Lastly, an example utilizing all flags and loglevel will make usage much more 
clear for general users.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_blend : add SIMD for more 16 bit blending mode

[Martin Vignali]

2018-03-17 19:44 GMT+01:00 Martin Vignali :

> Hello
>
> Patch in attach add SIMD for 16 bit version of
> grainextract
> grainmerge
> average
> extremity
> negation
>
> 003 : modify DIFFERENCE macro to reduce line duplication
> 004 : add SIMD for grainextract, grainmerge, average, extremity, negation
> 005 : add checkasm test for grainextract, grainmerge, average, extremity,
> negation
>
>
>
> Checkasm result :
> grainextract_16_c: 11639.2
> grainextract_16_sse4: 1047.2
> grainextract_16_avx2: 546.4
>
> grainmerge_16_c: 11719.9
> grainmerge_16_sse4: 1045.7
> grainmerge_16_avx2: 548.7
>
> average_16_c: 7062.4
> average_16_sse2: 479.6
> average_16_avx2: 285.9
>
> extremity_16_c: 8678.4
> extremity_16_sse4: 1142.6
> extremity_16_avx2: 536.4
>
> negation_16_c: 8731.4
> negation_16_sse4: 1280.4
> negation_16_avx2: 587.6
>
>
>
>
> Martin
>
>
>
Pushed

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 4/5/2018 8:14 PM, Rostislav Pehlivanov wrote:
> I think it makes sense to have it in AVStream rather than as side data.
> I don't have an opinion on whether codec switches should be indicated. It
> would be nice for them to be a separate segment if that's possible and
> reliable, since it would allow users to init all they would at startup. If
> not then they can just handle them as they come like a stream and reinit if
> they have to.

The consensus so far seems to be AVStream members, so I will switch to that
approach.

For codec changes, not all formats indicate codec changes up front, such as
MPEG-TS which we may be streaming, so I think it has to be handled as it comes
anyway.

> After all this API only concerns complete files rather than
> streams.

'Streaming' should actually be possible in the same sense you can stream a
progressive MP4 of Matroska file, since this data is located in the same place
as the index, which will be upfront (or at least, all in one place).

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Rostislav Pehlivanov]

On 5 April 2018 at 16:26, Derek Buitenhuis 
wrote:

> On 4/3/2018 5:26 PM, wm4 wrote:
> > Uh no idea. One angle:
> >
> > The idea with AVStream side data is that it can be attached as AVPacket
> > side data. So if an API user is fine with treating all kinds of side
> > data per AVPacket, it can call av_format_inject_global_side_data() and
> > ignore AVStream side data. Basically, you could ask the question
> > whether this kind of side data makes sense as per-AVPacket, and if not,
> > then it should be AVStream side data. Maybe.
>
> It doesn't make sense as per-packet side-data.
>
> > Another angle is that the API better because side data would not add
> > yet another AVStream field. It makes the API more discoverable: the API
> > user can easily detect an unsupported side data type and handle it as
> > soon as he has a sample, instead of having to go over every AVStream
> > field during the initial implementation, and wondering what the hell it
> > does (and things going wrong when not handling explicitly). I probably
> > didn't word that too well, but I hope you get what I mean.
>
> I got what you mean. I still don't have an opinion one way or another.
> It's a trade-off between Yet Another AVStream Field vs a more complex
> API and implementation as side data. I may be slightly erring towards
> an AVStream field.
>
> I would be interested to hear others' opinions on this if they have
> a stronger one.
>
>
I think it makes sense to have it in AVStream rather than as side data.
I don't have an opinion on whether codec switches should be indicated. It
would be nice for them to be a separate segment if that's possible and
reliable, since it would allow users to init all they would at startup. If
not then they can just handle them as they come like a stream and reinit if
they have to. After all this API only concerns complete files rather than
streams.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[Alexander Kravchenko]

> 
> This breaks the testcase described in
> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> one you described in this patch.
> 
> I get the following spammed repeatedly:
> 
> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
> [mpeg2video @ 02f8d400] get_buffer() failed
> [mpeg2video @ 02f8d400] thread_get_buffer() failed
> [mpeg2video @ 02f8d400] get_buffer() failed (-12 )
> Error while decoding stream #0:1: Operation not permitted

Hi,
I have checked the test, it causes such error because dxva decoder allocates 
small pool size for input of AV_CODEC_ID_MPEG2VIDEO

Option  "-extra_hw_frames 16" solves this problem.

I have checked test using the following command line. Result video looks ok 
comparing to original video.
./ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 12 -i 
matrixbench_mpeg2.mpg -an -c:v h264_amf out.mkv

I have found the logic in dxva.c which sets initial pool size
/* add surfaces based on number of possible refs */
if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id == 
AV_CODEC_ID_HEVC)
num_surfaces += 16;
else if (avctx->codec_id == AV_CODEC_ID_VP9)
num_surfaces += 8;
else
num_surfaces += 2;
...
frames_ctx->initial_pool_size = num_surfaces;

There is alternative way to solve this problem, such as using copy surface 
before submitting to encoder, but this scenario will spend additional resources.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[wm4]

On Thu, 5 Apr 2018 19:51:49 +0100
Derek Buitenhuis  wrote:

> Hi,
> 
> If you wish to address me, please do so publicly in the future. Nobody
> benefits from this stuff happening in private. CCing ffmpeg-devel where
> this belongs.
> 
> On 4/5/2018 7:44 PM, Nicolas George wrote:
> > This remark would have more weight if you also made it to people who
> > actually deserve it, like the person you were just discussing with, and
> > who have attacked and insulted, in the past, not only me but also
> > Michael, Carl Eugen and others, including in this very thread.  

It would be better if the person who wrote this weren't the same who
called me "troll" in the past, consistently ignores my post in the most
respectless manner, is generally without any civility if someone
disagrees with him, and didn't list at least 1 person who aggressively
attacked me in the past as someone who is supposedly a "victim" of me.

I'm really sick of this savagely behavior and I suggest we actually
enforce the CoC.

(I'm ready to accept that Michael's behavior in the past was without
any actual ill intent.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 4/5/2018 3:25 PM, Lou Logan wrote:
> On Sun, Mar 25, 2018, at 10:51 PM, Valery Kot wrote:
>>
>> Just wondering: is there an active maintainer for avcodec/libopenh264?
> 
> Doesn't appear to be so.
> 
>> If yes - can he or she please review my patch. If no - how does
>> maintenance works for "orphaned" modules?
> 
> Any developer simply decides to review, approve, and/or push it. Sorry for 
> the wait, but I recommend pinging this thread once a week until so.
> 
> If it has been a while make sure your patch still applies cleanly to the git 
> master branch before pinging. Otherwise please provide an updated patch.

Pushed it. It's been a month and with no maintainer and apparently no
devs using this module it's clear nobody is going to look at it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

Hi,

If you wish to address me, please do so publicly in the future. Nobody
benefits from this stuff happening in private. CCing ffmpeg-devel where
this belongs.

On 4/5/2018 7:44 PM, Nicolas George wrote:
> This remark would have more weight if you also made it to people who
> actually deserve it, like the person you were just discussing with, and
> who have attacked and insulted, in the past, not only me but also
> Michael, Carl Eugen and others, including in this very thread.

I don't condone it from anyone, I merely replied to a direct reply to myself.
I don't necessarily read every mail on the list, specifically for this reason
(petty fighting), so I don't know what history you guys all have and who
"actually" deserves to be called out. Everyone who acts like a butt deserves
to be called out, myself included (though, I don't think I have this time.)

> I guess it is easier to stand up to people who try to be decent but do
> not mince their words than to bullies.

What? That is an entirely subjective. There are LOTS of times you, and all you
listed have been bullies, IMO. Cut out the holier-than-thou stuff, please.
This list has a serious jerk problem on all "sides", and why I largely avoid
it unless I think I have something of value to contribute. I've tried to keep
my replies here professional. Please do not accuse me of some kind if conspiracy
or favoritism.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 4/5/2018 7:35 PM, Nicolas George wrote:
> A completely braindead API versus using a data structure the way it is
> supposed to be used, by adding fields when necessary? You call this a
> trade-off?

You could have voiced your opinion without being a jackass about it. Cut
it out.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Nicolas George]

Derek Buitenhuis (2018-04-05):
> I got what you mean. I still don't have an opinion one way or another.
> It's a trade-off between Yet Another AVStream Field vs a more complex
> API and implementation as side data. I may be slightly erring towards
> an AVStream field.
> 
> I would be interested to hear others' opinions on this if they have
> a stronger one.

A completely braindead API versus using a data structure the way it is
supposed to be used, by adding fields when necessary? You call this a
trade-off?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avcodec: v4l2_m2m: reduce the minimum amount of buffers

[Maxime Jourdan]

Reduce the minimum amount of CAPTURE and OUTPUT buffers to 1.

There are drivers that may work with such drastic settings,
and FFmpeg doesn't complain.
---
 libavcodec/v4l2_m2m.h | 2 +-
 libavcodec/v4l2_m2m_dec.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/v4l2_m2m.h b/libavcodec/v4l2_m2m.h
index 452bf0d9bc..68e4e5d6c6 100644
--- a/libavcodec/v4l2_m2m.h
+++ b/libavcodec/v4l2_m2m.h
@@ -38,7 +38,7 @@

 #define V4L_M2M_DEFAULT_OPTS \
 { "num_output_buffers", "Number of buffers in the output context",\
-OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 6,
INT_MAX, FLAGS }
+OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 1,
INT_MAX, FLAGS }

 typedef struct V4L2m2mContext {
 char devname[PATH_MAX];
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index bca45be148..5196680bbb 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -198,7 +198,7 @@ static av_cold int v4l2_decode_init(AVCodecContext
*avctx)
 static const AVOption options[] = {
 V4L_M2M_DEFAULT_OPTS,
 { "num_capture_buffers", "Number of buffers in the capture context",
-OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 20,
INT_MAX, FLAGS },
+OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 1,
INT_MAX, FLAGS },
 { NULL},
 };

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

Re: [FFmpeg-devel] [PATCH] doc/developer: remove merge request method of contributing

[wm4]

On Thu,  5 Apr 2018 10:17:30 -0800
Lou Logan  wrote:

> This seems to confuse Github users into thinking that we may accept pull
> requests. We do not accept pull requests.
> 
> Sending patches to the ffmpeg-devel mailing list is our preferred method
> for users to contribute code.
> 
> Signed-off-by: Lou Logan 
> ---
>  doc/developer.texi | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 0fc9c3f21c..a0eeefe242 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -30,13 +30,11 @@ consult @url{https://ffmpeg.org/legal.html}.
>  
>  @chapter Contributing
>  
> -There are 3 ways by which code gets into FFmpeg.
> +There are 2 ways by which code gets into FFmpeg:
>  @itemize @bullet
> -@item Submitting patches to the main developer mailing list.
> +@item Submitting patches to the ffmpeg-devel mailing list.
>See @ref{Submitting patches} for details.
>  @item Directly committing changes to the main tree.
> -@item Committing changes to a git clone, for example on github.com or
> -  gitorious.org. And asking us to merge these changes.
>  @end itemize
>  
>  Whichever way, changes should be reviewed by the maintainer of the code

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

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

[Lou Logan]

On Sun, Mar 25, 2018, at 10:51 PM, Valery Kot wrote:
>
> Just wondering: is there an active maintainer for avcodec/libopenh264?

Doesn't appear to be so.

> If yes - can he or she please review my patch. If no - how does
> maintenance works for "orphaned" modules?

Any developer simply decides to review, approve, and/or push it. Sorry for the 
wait, but I recommend pinging this thread once a week until so.

If it has been a while make sure your patch still applies cleanly to the git 
master branch before pinging. Otherwise please provide an updated patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: Fix parsing of tfdt when using sample descriptors.

[Michael Niedermayer]

On Wed, Apr 04, 2018 at 12:30:56PM -0700, Jacob Trimble wrote:
> Signed-off-by: Jacob Trimble 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thx

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

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


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

[FFmpeg-devel] [PATCH] doc/developer: remove merge request method of contributing

[Lou Logan]

This seems to confuse Github users into thinking that we may accept pull
requests. We do not accept pull requests.

Sending patches to the ffmpeg-devel mailing list is our preferred method
for users to contribute code.

Signed-off-by: Lou Logan 
---
 doc/developer.texi | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 0fc9c3f21c..a0eeefe242 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -30,13 +30,11 @@ consult @url{https://ffmpeg.org/legal.html}.
 
 @chapter Contributing
 
-There are 3 ways by which code gets into FFmpeg.
+There are 2 ways by which code gets into FFmpeg:
 @itemize @bullet
-@item Submitting patches to the main developer mailing list.
+@item Submitting patches to the ffmpeg-devel mailing list.
   See @ref{Submitting patches} for details.
 @item Directly committing changes to the main tree.
-@item Committing changes to a git clone, for example on github.com or
-  gitorious.org. And asking us to merge these changes.
 @end itemize
 
 Whichever way, changes should be reviewed by the maintainer of the code
-- 
2.16.3

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Stricter heuristic for auto-detection.

[Michael Niedermayer]

On Thu, Apr 05, 2018 at 12:45:18AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #7125, the jpg file in question contains a
> repeated pattern up to PROBE_SIZE that plays as amr_nb:
> 000d3290  05 14 51 40 05 14 51 40  05 14 51 40 05 14 51 40  |..Q@..Q@..Q@..Q@|
> *
> 00112900  1f ff d9  |...|
> 
> Please comment, Carl Eugen

>  amr.c |   10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 64ad2690251aff3bf4ce981e2b09e5102df0ba44  
> 0001-lavf-amr-Stricter-heuristic-for-auto-detection.patch
> From 26712381d7dc3d3dfc623a77a80a697ffcd54124 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Thu, 5 Apr 2018 00:41:55 +0200
> Subject: [PATCH] lavf/amr: Stricter heuristic for auto-detection.
> 
> Fixes ticket #7125.

probably ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[James Almer]

On 4/5/2018 12:23 PM, Alexander Kravchenko wrote:
> 
> This fixes frame corruption issue when decoder started reusing frames while 
> they are still in use of encoding process
> Issue with frame corruption  was reproduced using:
> ffmpeg.exe -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i input.h264  
> -an -c:v h264_amf output.mkv
> 
> Previous questions and answers
>> How many frames can end up queued inside the encoder here?
> 16
> 
>> Is there always an exact 1->1 correspondence between input frames and output 
>> packets?  That is, is it guaranteed that no frames
> are
>> ever dropped, even in the low-latency modes?
> yes
> 
>> These look even more like they should be functions rather than macros now?  
>> In particular, the returns in them interact badly with
> the code below.
> Macroses were used because they works with different types. I have removed 
> returns from them (sorry, I missed this comment).
> 
> ---
>  libavcodec/amfenc.c | 89 
> +
>  1 file changed, 89 insertions(+)
> 
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 89a10ff253..084b06e56d 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -443,6 +443,73 @@ int ff_amf_encode_init(AVCodecContext *avctx)
>  return ret;
>  }
>  
> +#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
> +{ \
> +AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
> +res = from->pVtbl->QueryInterface(from, _##InterfaceTypeTo, 
> (void**)); \
> +}
> +
> +#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
> +{ \
> +AMFInterface *amf_interface; \
> +AMFVariantStruct var; \
> +res = AMFVariantInit(); \
> +if (res == AMF_OK) { \
> +AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
> +if (res == AMF_OK) { \
> +res = AMFVariantAssignInterface(, amf_interface); \
> +amf_interface->pVtbl->Release(amf_interface); \
> +} \
> +if (res == AMF_OK) { \
> +res = pThis->pVtbl->SetProperty(pThis, name, var); \
> +} \
> +AMFVariantClear(); \
> +}\
> +}
> +
> +#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
> +{ \
> +AMFVariantStruct var; \
> +res = AMFVariantInit(); \
> +if (res == AMF_OK) { \
> +res = pThis->pVtbl->GetProperty(pThis, name, ); \
> +if (res == AMF_OK) { \
> +if (var.type == AMF_VARIANT_INTERFACE && 
> AMFVariantInterface()) { \
> +AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
> TargetType, val); \
> +} else { \
> +res = AMF_INVALID_DATA_TYPE; \
> +} \
> +} \
> +AMFVariantClear(); \
> +}\
> +}
> +
> +static AMFBuffer* amf_create_buffer_with_frame_ref(const AVFrame* frame, 
> AMFContext *context)
> +{
> +AVFrame *frame_ref;
> +AMFBuffer *frame_ref_storage_buffer = NULL;
> +AMF_RESULT res;
> +
> +res = context->pVtbl->AllocBuffer(context, AMF_MEMORY_HOST, 
> sizeof(frame_ref), _ref_storage_buffer);
> +if (res == AMF_OK) {
> +frame_ref = av_frame_clone(frame);
> +if (frame_ref) {
> +
> memcpy(frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
> _ref, sizeof(frame_ref));
> +} else {
> +
> frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
> +frame_ref_storage_buffer = NULL;
> +}
> +}
> +return frame_ref_storage_buffer;
> +}
> +
> +static void amf_release_buffer_with_frame_ref(AMFBuffer 
> *frame_ref_storage_buffer)
> +{
> +AVFrame *av_frame_ref;
> +memcpy(_frame_ref, 
> frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
> sizeof(av_frame_ref));
> +av_frame_free(_frame_ref);
> +frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
> +} 
>  
>  int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
>  {
> @@ -484,6 +551,7 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
> AVFrame *frame)
>  (ctx->hw_device_ctx && 
> ((AVHWFramesContext*)frame->hw_frames_ctx->data)->device_ctx ==
>  (AVHWDeviceContext*)ctx->hw_device_ctx->data)
>  )) {
> +AMFBuffer *frame_ref_storage_buffer;
>  #if CONFIG_D3D11VA
>  static const GUID AMFTextureArrayIndexGUID = { 0x28115527, 
> 0xe7c3, 0x4b66, { 0x99, 0xd3, 0x4f, 0x2a, 0xe6, 0xb4, 0x7f,
> 0xaf } };
>  ID3D11Texture2D *texture = (ID3D11Texture2D*)frame->data[0]; // 
> actual texture
> @@ -496,6 +564,16 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
> AVFrame *frame)
>  // input HW surfaces can be vertically aligned by 16; tell AMF 
> the real size
>  surface->pVtbl->SetCrop(surface, 0, 0, frame->width, 
> 

[FFmpeg-devel] [PATCH 3/3 v2] avformat/matroskadec: reference the existing data buffer when creating packets

[James Almer]

Newly allocated data buffers (wavpack, prores, compressed buffers)
are padded to meet the requirements of AVPacket.

About 10x speed up in matroska_parse_frame().

Signed-off-by: James Almer 
---
Rebased after the prores fix in Patch 2/3 v2.

 libavformat/matroskadec.c | 45 +++--
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 30f0da5bee..1ded431b80 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1367,7 +1367,7 @@ static int matroska_decode_buffer(uint8_t **buf, int 
*buf_size,
 return 0;
 
 pkt_size = isize + header_size;
-pkt_data = av_malloc(pkt_size);
+pkt_data = av_malloc(pkt_size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!pkt_data)
 return AVERROR(ENOMEM);
 
@@ -1379,7 +1379,8 @@ static int matroska_decode_buffer(uint8_t **buf, int 
*buf_size,
 case MATROSKA_TRACK_ENCODING_COMP_LZO:
 do {
 olen   = pkt_size *= 3;
-newpktdata = av_realloc(pkt_data, pkt_size + 
AV_LZO_OUTPUT_PADDING);
+newpktdata = av_realloc(pkt_data, pkt_size + AV_LZO_OUTPUT_PADDING
+   + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!newpktdata) {
 result = AVERROR(ENOMEM);
 goto failed;
@@ -1404,7 +1405,7 @@ static int matroska_decode_buffer(uint8_t **buf, int 
*buf_size,
 zstream.avail_in = isize;
 do {
 pkt_size  *= 3;
-newpktdata = av_realloc(pkt_data, pkt_size);
+newpktdata = av_realloc(pkt_data, pkt_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!newpktdata) {
 inflateEnd();
 result = AVERROR(ENOMEM);
@@ -1437,7 +1438,7 @@ static int matroska_decode_buffer(uint8_t **buf, int 
*buf_size,
 bzstream.avail_in = isize;
 do {
 pkt_size  *= 3;
-newpktdata = av_realloc(pkt_data, pkt_size);
+newpktdata = av_realloc(pkt_data, pkt_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!newpktdata) {
 BZ2_bzDecompressEnd();
 result = AVERROR(ENOMEM);
@@ -1464,6 +1465,8 @@ static int matroska_decode_buffer(uint8_t **buf, int 
*buf_size,
 return AVERROR_INVALIDDATA;
 }
 
+memset(pkt_data + pkt_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
 *buf  = pkt_data;
 *buf_size = pkt_size;
 return 0;
@@ -3001,7 +3004,7 @@ static int matroska_parse_wavpack(MatroskaTrack *track, 
uint8_t *src,
 goto fail;
 }
 
-tmp = av_realloc(dst, dstlen + blocksize + 32);
+tmp = av_realloc(dst, dstlen + blocksize + 32 + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!tmp) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -3025,6 +3028,8 @@ static int matroska_parse_wavpack(MatroskaTrack *track, 
uint8_t *src,
 offset += blocksize + 32;
 }
 
+memset(dst + dstlen, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
 *pdst = dst;
 *size = dstlen;
 
@@ -3042,13 +3047,14 @@ static int matroska_parse_prores(MatroskaTrack *track, 
uint8_t *src,
 int dstlen = *size;
 
 if (AV_RB32([4]) != MKBETAG('i', 'c', 'p', 'f')) {
-dst = av_malloc(dstlen + 8);
+dst = av_malloc(dstlen + 8 + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!dst)
 return AVERROR(ENOMEM);
 
 AV_WB32(dst, dstlen);
 AV_WB32(dst + 4, MKBETAG('i', 'c', 'p', 'f'));
 memcpy(dst + 8, src, dstlen);
+memset(dst + 8 + dstlen, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 dstlen += 8;
 }
 
@@ -3175,7 +3181,7 @@ static int matroska_parse_webvtt(MatroskaDemuxContext 
*matroska,
 
 static int matroska_parse_frame(MatroskaDemuxContext *matroska,
 MatroskaTrack *track, AVStream *st,
-uint8_t *data, int pkt_size,
+AVBufferRef *buf, uint8_t *data, int pkt_size,
 uint64_t timecode, uint64_t lace_duration,
 int64_t pos, int is_keyframe,
 uint8_t *additional, uint64_t additional_id, 
int additional_size,
@@ -3218,17 +3224,20 @@ static int matroska_parse_frame(MatroskaDemuxContext 
*matroska,
 pkt_data = pr_data;
 }
 
-/* XXX: prevent data copy... */
-if (av_new_packet(pkt, pkt_size) < 0) {
+av_init_packet(pkt);
+if (pkt_data != data)
+pkt->buf = av_buffer_create(pkt_data, pkt_size + 
AV_INPUT_BUFFER_PADDING_SIZE,
+NULL, NULL, 0);
+else
+pkt->buf = av_buffer_ref(buf);
+
+if (!pkt->buf) {
 res = AVERROR(ENOMEM);
 goto fail;
 }
 
-memcpy(pkt->data, pkt_data, pkt_size);
-
-if (pkt_data != data)
-av_freep(_data);
-
+pkt->data = pkt_data;
+   

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 4/3/2018 5:26 PM, wm4 wrote:
> Uh no idea. One angle:
> 
> The idea with AVStream side data is that it can be attached as AVPacket
> side data. So if an API user is fine with treating all kinds of side
> data per AVPacket, it can call av_format_inject_global_side_data() and
> ignore AVStream side data. Basically, you could ask the question
> whether this kind of side data makes sense as per-AVPacket, and if not,
> then it should be AVStream side data. Maybe.

It doesn't make sense as per-packet side-data. 

> Another angle is that the API better because side data would not add
> yet another AVStream field. It makes the API more discoverable: the API
> user can easily detect an unsupported side data type and handle it as
> soon as he has a sample, instead of having to go over every AVStream
> field during the initial implementation, and wondering what the hell it
> does (and things going wrong when not handling explicitly). I probably
> didn't word that too well, but I hope you get what I mean.

I got what you mean. I still don't have an opinion one way or another.
It's a trade-off between Yet Another AVStream Field vs a more complex
API and implementation as side data. I may be slightly erring towards
an AVStream field.

I would be interested to hear others' opinions on this if they have
a stronger one.

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

[FFmpeg-devel] [PATCH 2/3 v2] avformat/matroskadec: factor the prores packet parsing code out

[James Almer]

Simplifies code in matroska_parse_frame(). This is in preparation for
the following patch.

Signed-off-by: James Almer 
---
Not overloading dst this time...

 libavformat/matroskadec.c | 50 +++
 1 file changed, 38 insertions(+), 12 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 029929a1cb..30f0da5bee 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3035,6 +3035,29 @@ fail:
 return ret;
 }
 
+static int matroska_parse_prores(MatroskaTrack *track, uint8_t *src,
+ uint8_t **pdst, int *size)
+{
+uint8_t *dst = src;
+int dstlen = *size;
+
+if (AV_RB32([4]) != MKBETAG('i', 'c', 'p', 'f')) {
+dst = av_malloc(dstlen + 8);
+if (!dst)
+return AVERROR(ENOMEM);
+
+AV_WB32(dst, dstlen);
+AV_WB32(dst + 4, MKBETAG('i', 'c', 'p', 'f'));
+memcpy(dst + 8, src, dstlen);
+dstlen += 8;
+}
+
+*pdst = dst;
+*size = dstlen;
+
+return 0;
+}
+
 static int matroska_parse_webvtt(MatroskaDemuxContext *matroska,
  MatroskaTrack *track,
  AVStream *st,
@@ -3160,7 +3183,7 @@ static int matroska_parse_frame(MatroskaDemuxContext 
*matroska,
 {
 MatroskaTrackEncoding *encodings = track->encodings.elem;
 uint8_t *pkt_data = data;
-int offset = 0, res;
+int res;
 AVPacket pktl, *pkt = 
 
 if (encodings && !encodings->type && encodings->scope & 1) {
@@ -3182,23 +3205,26 @@ static int matroska_parse_frame(MatroskaDemuxContext 
*matroska,
 pkt_data = wv_data;
 }
 
-if (st->codecpar->codec_id == AV_CODEC_ID_PRORES &&
-AV_RB32([4]) != MKBETAG('i', 'c', 'p', 'f'))
-offset = 8;
+if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
+uint8_t *pr_data;
+res = matroska_parse_prores(track, pkt_data, _data, _size);
+if (res < 0) {
+av_log(matroska->ctx, AV_LOG_ERROR,
+   "Error parsing a prores block.\n");
+goto fail;
+}
+if (pkt_data != data)
+av_freep(_data);
+pkt_data = pr_data;
+}
 
 /* XXX: prevent data copy... */
-if (av_new_packet(pkt, pkt_size + offset) < 0) {
+if (av_new_packet(pkt, pkt_size) < 0) {
 res = AVERROR(ENOMEM);
 goto fail;
 }
 
-if (st->codecpar->codec_id == AV_CODEC_ID_PRORES && offset == 8) {
-uint8_t *buf = pkt->data;
-bytestream_put_be32(, pkt_size);
-bytestream_put_be32(, MKBETAG('i', 'c', 'p', 'f'));
-}
-
-memcpy(pkt->data + offset, pkt_data, pkt_size);
+memcpy(pkt->data, pkt_data, pkt_size);
 
 if (pkt_data != data)
 av_freep(_data);
-- 
2.16.2

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

[FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[Alexander Kravchenko]

This fixes frame corruption issue when decoder started reusing frames while 
they are still in use of encoding process
Issue with frame corruption  was reproduced using:
ffmpeg.exe -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i input.h264  -an 
-c:v h264_amf output.mkv

Previous questions and answers
> How many frames can end up queued inside the encoder here?
16

> Is there always an exact 1->1 correspondence between input frames and output 
> packets?  That is, is it guaranteed that no frames
are
> ever dropped, even in the low-latency modes?
yes

> These look even more like they should be functions rather than macros now?  
> In particular, the returns in them interact badly with
the code below.
Macroses were used because they works with different types. I have removed 
returns from them (sorry, I missed this comment).

---
 libavcodec/amfenc.c | 89 +
 1 file changed, 89 insertions(+)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 89a10ff253..084b06e56d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -443,6 +443,73 @@ int ff_amf_encode_init(AVCodecContext *avctx)
 return ret;
 }
 
+#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
+{ \
+AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
+res = from->pVtbl->QueryInterface(from, _##InterfaceTypeTo, 
(void**)); \
+}
+
+#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
+{ \
+AMFInterface *amf_interface; \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res == AMF_OK) { \
+AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
+if (res == AMF_OK) { \
+res = AMFVariantAssignInterface(, amf_interface); \
+amf_interface->pVtbl->Release(amf_interface); \
+} \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->SetProperty(pThis, name, var); \
+} \
+AMFVariantClear(); \
+}\
+}
+
+#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
+{ \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->GetProperty(pThis, name, ); \
+if (res == AMF_OK) { \
+if (var.type == AMF_VARIANT_INTERFACE && 
AMFVariantInterface()) { \
+AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
TargetType, val); \
+} else { \
+res = AMF_INVALID_DATA_TYPE; \
+} \
+} \
+AMFVariantClear(); \
+}\
+}
+
+static AMFBuffer* amf_create_buffer_with_frame_ref(const AVFrame* frame, 
AMFContext *context)
+{
+AVFrame *frame_ref;
+AMFBuffer *frame_ref_storage_buffer = NULL;
+AMF_RESULT res;
+
+res = context->pVtbl->AllocBuffer(context, AMF_MEMORY_HOST, 
sizeof(frame_ref), _ref_storage_buffer);
+if (res == AMF_OK) {
+frame_ref = av_frame_clone(frame);
+if (frame_ref) {
+
memcpy(frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
_ref, sizeof(frame_ref));
+} else {
+frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
+frame_ref_storage_buffer = NULL;
+}
+}
+return frame_ref_storage_buffer;
+}
+
+static void amf_release_buffer_with_frame_ref(AMFBuffer 
*frame_ref_storage_buffer)
+{
+AVFrame *av_frame_ref;
+memcpy(_frame_ref, 
frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
sizeof(av_frame_ref));
+av_frame_free(_frame_ref);
+frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
+} 
 
 int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
 {
@@ -484,6 +551,7 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 (ctx->hw_device_ctx && 
((AVHWFramesContext*)frame->hw_frames_ctx->data)->device_ctx ==
 (AVHWDeviceContext*)ctx->hw_device_ctx->data)
 )) {
+AMFBuffer *frame_ref_storage_buffer;
 #if CONFIG_D3D11VA
 static const GUID AMFTextureArrayIndexGUID = { 0x28115527, 0xe7c3, 
0x4b66, { 0x99, 0xd3, 0x4f, 0x2a, 0xe6, 0xb4, 0x7f,
0xaf } };
 ID3D11Texture2D *texture = (ID3D11Texture2D*)frame->data[0]; // 
actual texture
@@ -496,6 +564,16 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 // input HW surfaces can be vertically aligned by 16; tell AMF the 
real size
 surface->pVtbl->SetCrop(surface, 0, 0, frame->width, 
frame->height);
 #endif
+
+frame_ref_storage_buffer = amf_create_buffer_with_frame_ref(frame, 
ctx->context);
+AMF_RETURN_IF_FALSE(ctx, frame_ref_storage_buffer != NULL, 
AVERROR(ENOMEM), "create_buffer_with_frame_ref() returned
NULL\n");
+
+AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, 

Re: [FFmpeg-devel] [PATCH] avcodec/decode: fix warning when decoding pseudo paletted formats

[wm4]

On Wed, 4 Apr 2018 21:42:31 +0200
Michael Niedermayer  wrote:

> On Wed, Apr 04, 2018 at 06:07:20PM +0200, wm4 wrote:
> > The pseudo palette allocation is optional now. But if it's still
> > allocated (like the internal get_buffer2 implementation does, for
> > compatibility), it shouldn't print a warning.
> > ---
> >  libavcodec/decode.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index d883a5f9fc..421a8f1a35 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1779,6 +1779,8 @@ static void 
> > validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame)
> >  int flags = desc ? desc->flags : 0;
> >  if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL))
> >  num_planes = 2;
> > +if ((flags & FF_PSEUDOPAL) && frame->data[1])
> > +num_planes = 2;
> >  for (i = 0; i < num_planes; i++) {
> >  av_assert0(frame->data[i]);
> >  }  
> 
> LGTM
> 
> thx
> 
> 
> [...]

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/matroskadec: factor the prores packet parsing code out

[Michael Niedermayer]

On Wed, Apr 04, 2018 at 08:43:33PM -0300, James Almer wrote:
> Simplifies code in matroska_parse_frame(). This is in preparation for
> the following patch.
> 
> Signed-off-by: James Almer 
> ---
> Prores specific stuff untested, as FATE doesn't cover it.
> 
>  libavformat/matroskadec.c | 50 
> +++
>  1 file changed, 38 insertions(+), 12 deletions(-)

This breaks:
./ffmpeg -i matrixbench_mpeg2.mpg -vcodec prores -vframes 3  -an file-prores.mkv
./ffmpeg -i file-prores.mkv -vcodec prores -vframes 3 -an file-prores2.mkv


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

[FFmpeg-devel] Patch for seg fault in swr_convert_internal() -> sum2_float during dithering

[Hendrik Schreiber]

Hey there,

I have recently switched to using FFmpeg for conversions of 24bit stereo WAV to 
16bit stereo WAV (with dithering).

For some very large files, I occasionally encountered a segmentation fault in 
_sum2_float. Unfortunately, I was not able to reproduce the issue in a small 
test setting, but only in a quite large environment.

Debugging showed that the issue was caused in function swr_convert_internal() 
in swresample.c, specifically in line 681

s->mix_2_1_f(
conv_src->ch[ch] + off, // out array
preout->ch[ch] + off,   // in1 array
s->dither.noise.ch[ch] + s->dither.noise.bps * s->dither.noise_pos + off + 
len1, // in2 array
s->native_one,  // coefficients
0,  // coefficient index 1
0,  // coefficient index 2
out_count - len1// length
);

(https://github.com/FFmpeg/FFmpeg/blob/53688b62ca96ad9a3b0e7d201caca61c79a68648/libswresample/swresample.c#L681)

where dithering is applied. Here, s->mix_2_1_f() is the same as sum2_float(). 
The in2 array pointer is too large.

I was able to log values before one of the crashs and found:

out_count=682
len1=672
(out_count - len1)=10
off=2688
s->dither.noise.bps  =4
s->dither.noise_pos  =130262
s->dither.noise.count=131072
s->dither.noise.bps * s->dither.noise_pos + off + len1 = 524408 // in2 start 
address offset greater than buffer size!!!

The buffer count has a total size of s->dither.noise.count * 
s->dither.noise.bps = 524288
Therefore the start address for the in2 array (3rd argument for mix_2_1_f(...)) 
is already outside of the buffer.

I was not able to find a reason for the “+len1” in “s->dither.noise.bps * 
s->dither.noise_pos + off + len1”. It looks out of place to me. Without it the 
buffer overrun does not occur.

“make fate” worked like a charm.

-hendrik

tagtraum industries incorporated
724 Nash Drive
Raleigh, NC 27608
USA
+1 (919) 809-7797
http://www.tagtraum.com/
http://www.beatunes.com/

From ef79e9286c4b8b694715e978f48abe1601956c0e Mon Sep 17 00:00:00 2001
From: Hendrik Schreiber 
Date: Thu, 5 Apr 2018 13:58:37 +0200
Subject: [PATCH] Fix for seg fault in swr_convert_internal() -> sum2_float
 during dithering. Removed +len1 in call to s->mix_2_1_f() as I found no
 logical explanation for it. After removal, problem was gone.

Signed-off-by: Hendrik Schreiber 
---
 libswresample/swresample.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index f076b6c8cf..5bd39caac4 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -678,7 +678,7 @@ static int swr_convert_internal(struct SwrContext *s, 
AudioData *out, int out_co
 s->mix_2_1_simd(conv_src->ch[ch], preout->ch[ch], 
s->dither.noise.ch[ch] + s->dither.noise.bps * s->dither.noise_pos, 
s->native_simd_one, 0, 0, len1);
 if(out_count != len1)
 for(ch=0; chch_count; ch++)
-s->mix_2_1_f(conv_src->ch[ch] + off, 
preout->ch[ch] + off, s->dither.noise.ch[ch] + s->dither.noise.bps * 
s->dither.noise_pos + off + len1, s->native_one, 0, 0, out_count - len1);
+s->mix_2_1_f(conv_src->ch[ch] + off, 
preout->ch[ch] + off, s->dither.noise.ch[ch] + s->dither.noise.bps * 
s->dither.noise_pos + off, s->native_one, 0, 0, out_count - len1);
 } else {
 for(ch=0; chch_count; ch++)
 s->mix_2_1_f(conv_src->ch[ch], preout->ch[ch], 
s->dither.noise.ch[ch] + s->dither.noise.bps * s->dither.noise_pos, 
s->native_one, 0, 0, out_count);
-- 
2.15.1 (Apple Git-101)


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

Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

[Michael Fritscher]

Good day,

were the technical things (changes into standard network code) resolved in the 
mean time? I've the feeling that it is looking at the patch.

On https://github.com/Haivision/srt/pull/140, there is at least a PR to make a 
debian package for it.

I think the name is a minor problem which is solveable - this shouldn't be a blocker. 
What about "osrt" - adding the o for open? ;-)

Regarding the usage: Is there any other option with pure ffmpeg to stream videos over a lossy packet-based network (like the Internet) with 
UDP+fault tolerance without having the hassles of TCP, which is unusable for at least "real" live transmissions? A 1:1 solution would be enough.


Best regards,
Michael Fritscher

Am 22.03.2018 um 16:02 schrieb Nicolas George:

Sven Dueking (2018-03-16):

Ping !?!?


I think I am actually expected to reply.

I think that by reviewing the patch I gave the impression that I was
promising to accept the patch in FFmpeg. It was not so, and I apologize
if it was taken that way. The original patch contained significant
changes in the standard network code that made it much more complex, I
wanted to avoid that, that is the reason I reviewed, it was purely
technical. The decision to accept a patch in FFmpeg is not purely
technical, it also involves balancing the cost of maintenance with the
benefit for users.

In this instance, the recent discussion on libav-dev seems to indicate
that the API and ABI of this library could be not very stable, making
the cost of maintenance relatively high, a fact that is worsened by the
library not being integrated in major Linux distros. As for the benefit
for users, are there public servers serving interesting content
accessible with this protocol? Are there situations where this protocol
would allow several instances of ffmpeg to communicate significantly
better than other protocols? I am not aware of any.

That, plus the poor choice of name (seriously, who dabs in multimedia
and does not know that SRT has been a subtitle format for more than
fifteen years? and there is the SRTP profile too) makes me doubtful
about integrating this in FFmpeg.

But it is not my choice only.

Regards,



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




--
ZfT - Zentrum für Telematik e.V.
Michael Fritscher
Magdalene-Schoch-Straße 5
97074 Würzburg
Tel: +49 (931) 615 633 - 57
Fax: +49 (931) 615 633 - 11
Email: michael.fritsc...@telematik-zentrum.de
Web: http://www.telematik-zentrum.de

Vorstand:
Prof. Dr. Klaus Schilling, Prof. Dr. Andreas Nüchter,  Hans-Joachim Leistner
Sitz: Gerbrunn
USt.-ID Nr.: DE 257 244 580, Steuer-Nr.:  257/111/70203
Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] display: Add AVDisplayOrientation API

[Vittorio Giovara]

---
> On Wed, Apr 04, 2018 at 05:30:24PM +0200, Vittorio Giovara wrote:
> >  libavutil/display.c | 92 
> > +
> >  libavutil/display.h | 53 ++
> >  2 files changed, 145 insertions(+)

> It might be more usefull to fully factorize the matrix than these special 
> cases
> 
> for example the matrix can be described by these 4 scalars
> 1. rotation
> 2. horizontal scale
> 3. vertical scale
> 4. shear

With the proposed API the matrix is already factorized: a mask is returned
containing a set of  operation. Special cases such as custom rotation is
already factorized, as in you need to call an additional function on the
same matrix to know more about the rotation angle. On the other hand the
most common cases are already ready to be used right away.

Do you think it should just expose the fact that it is a rotation and always
require the user to inspect the matrix again? Note that hflip and vflip can't
be described with pure rotation angles. I feel like this would complicate
the API.

For any missing operation, such as transpose, shear, and scaling, this API
should be extensible enoughe, so that if anybody wants to add enum values
and functions to retrieve the desired operation, it can be done.

> (there are more parameters like translation and z specific changes but 
> IIUC
>   these have no meaning ?)

Correct given that video right now is a 2d surface we can ignore anything
related to the depth axis.

> Note fliping in above would be a negative scale value
> shear could be specified as the angle between the x/y basis vectors
> 
> The reason i suggest this is that these 4 values are easier to understand
> for a human and should allow reconstructing an equivalent transform 
> matrix.
> While at the same time not limiting things to a subset of special cases
> 

The "special cases" are also the most common operations that every player
implements so I think it makes sense to have them readily available, with
as few calls as possible.

> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

(I'm trying something different wrt my mail client, I hope it doesn't botch
 the threaded reply again).
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [RFC]doc/examples: alternative input handler

[Bodecs Bela]

ping


2018.03.30. 14:47 keltezéssel, Bodecs Bela írta:

Hi All,

regularly, on different forums and mailing lists a requirement popups 
for a feature to automatically failover switching between main input 
and a

secondary input in case of main input unavailability.

The base motivation: let's say you have a unreliable live stream 
source and you

want to transcode its video and audio streams in realtime but you
want to survive the ocasions when the source is unavailable. So use a
secondary live source but the transition should occur seamlessly without
breaking/re-starting the transcoding processs.

Some days ago there was a discussion on devel-irc about this topic and 
we concluded that this feature is not feasible inside ffmpeg without 
"hacking", but a separate client app could do this.


So I created this example app to handle two separate input sources and 
switching realtime between them. I am not sure wheter it should be 
inside the tools subdir.


The detailed description is available in the header section of the 
source file.


I will appretiate your suggestions about it.

Thank you in advance.

best,

Bela Bodecs




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


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