Re: [FFmpeg-devel] [PATCH v2] ffmpeg: delay first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 09:52 pm, Gyan Doshi wrote:

Plan to push tomorrow morning.


Pushed as 9a0f5e412ad42a1c1a959d582e4fe2021b9ceda6




On 23-12-2020 04:53 pm, Gyan Doshi wrote:

Wait for all output files to be initialized before printing first stats.

Avoids breaking output file dump report.
---
  fftools/ffmpeg.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2c0820aacf..84a60f944a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -136,6 +136,7 @@ static int nb_frames_dup = 0;
  static unsigned dup_warning = 1000;
  static int nb_frames_drop = 0;
  static int64_t decode_error_stat[2];
+static unsigned nb_output_dumped = 0;
    static int want_sdp = 1;
  @@ -1699,7 +1700,8 @@ static void print_report(int is_last_report, 
int64_t timer_start, int64_t cur_ti

  if (last_time == -1) {
  last_time = cur_time;
  }
-    if ((cur_time - last_time) < stats_period && !first_report)
+    if (((cur_time - last_time) < stats_period && !first_report) ||
+    (first_report && nb_output_dumped < nb_output_files))
  return;
  last_time = cur_time;
  }
@@ -3017,6 +3019,7 @@ static int check_init_output_file(OutputFile 
*of, int file_index)

  of->header_written = 1;
    av_dump_format(of->ctx, file_index, of->ctx->url, 1);
+    nb_output_dumped++;
    if (sdp_filename || want_sdp)
  print_sdp();


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

[FFmpeg-devel] [PATCH] libswscale: avoid UB nullptr-with-offset.

2020-12-23 Thread Jeremy Leconte
Great news that the patch is accepted.
Just updated the author is this version.
Thanks!
---
 libswscale/slice.c| 12 
 libswscale/swscale_unscaled.c |  4 +---
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/libswscale/slice.c b/libswscale/slice.c
index 7849b70f4d..d96db13364 100644
--- a/libswscale/slice.c
+++ b/libswscale/slice.c
@@ -158,14 +158,10 @@ int ff_init_slice_from_src(SwsSlice * s, uint8_t *src[4], 
int stride[4], int src
 chrY + chrH,
 lumY + lumH};
 
-uint8_t *const src_[4] = {src[0] + (relative ? 0 : start[0]) * stride[0],
-  src[1] + (relative ? 0 : start[1]) * stride[1],
-  src[2] + (relative ? 0 : start[2]) * stride[2],
-  src[3] + (relative ? 0 : start[3]) * stride[3]};
-
 s->width = srcW;
 
-for (i = 0; i < 4; ++i) {
+for (i = 0; i < 4 && src[i] != NULL; ++i) {
+uint8_t *const src_i = src[i] + (relative ? 0 : start[i]) * stride[i];
 int j;
 int first = s->plane[i].sliceY;
 int n = s->plane[i].available_lines;
@@ -175,13 +171,13 @@ int ff_init_slice_from_src(SwsSlice * s, uint8_t *src[4], 
int stride[4], int src
 if (start[i] >= first && n >= tot_lines) {
 s->plane[i].sliceH = FFMAX(tot_lines, s->plane[i].sliceH);
 for (j = 0; j < lines; j+= 1)
-s->plane[i].line[start[i] - first + j] = src_[i] +  j * 
stride[i];
+s->plane[i].line[start[i] - first + j] = src_i +  j * 
stride[i];
 } else {
 s->plane[i].sliceY = start[i];
 lines = lines > n ? n : lines;
 s->plane[i].sliceH = lines;
 for (j = 0; j < lines; j+= 1)
-s->plane[i].line[j] = src_[i] +  j * stride[i];
+s->plane[i].line[j] = src_i +  j * stride[i];
 }
 
 }
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 563de39696..7e92f3fafc 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1805,7 +1805,7 @@ static int planarCopyWrapper(SwsContext *c, const uint8_t 
*src[],
 const AVPixFmtDescriptor *desc_src = av_pix_fmt_desc_get(c->srcFormat);
 const AVPixFmtDescriptor *desc_dst = av_pix_fmt_desc_get(c->dstFormat);
 int plane, i, j;
-for (plane = 0; plane < 4; plane++) {
+for (plane = 0; plane < 4 && dst[plane] != NULL; plane++) {
 int length = (plane == 0 || plane == 3) ? c->srcW  : 
AV_CEIL_RSHIFT(c->srcW,   c->chrDstHSubSample);
 int y =  (plane == 0 || plane == 3) ? srcSliceY: 
AV_CEIL_RSHIFT(srcSliceY, c->chrDstVSubSample);
 int height = (plane == 0 || plane == 3) ? srcSliceH: 
AV_CEIL_RSHIFT(srcSliceH, c->chrDstVSubSample);
@@ -1813,8 +1813,6 @@ static int planarCopyWrapper(SwsContext *c, const uint8_t 
*src[],
 uint8_t *dstPtr = dst[plane] + dstStride[plane] * y;
 int shiftonly = plane == 1 || plane == 2 || (!c->srcRange && plane == 
0);
 
-if (!dst[plane])
-continue;
 // ignore palette for GRAY8
 if (plane == 1 && !dst[2]) continue;
 if (!src[plane] || (plane == 1 && !src[2])) {
-- 
2.29.2.729.g45daf8777d-goog

___
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] libswscale: avoid UB nullptr-with-offset.

2020-12-23 Thread Jeremy Leconte
On Wed, Dec 23, 2020 at 10:14 PM Michael Niedermayer 
wrote:

> patch should be ok, is the author intended to be like this:
> Author: jleconte 
> I mean theres no full name in there
>

That's great news!
If it's ok on your side, I'm good with the author being 'jleconte'.
___
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: add librist protocol

2020-12-23 Thread James Almer

On 12/23/2020 8:53 PM, James Almer wrote:

On 12/23/2020 8:32 PM, Paul B Mahol wrote:

+static int librist_close(URLContext *h)
+{
+    RISTContext *s = h->priv_data;
+    int ret = 0;
+
+    s->peer = NULL;
+
+    if (s->rist_ctx)
+    ret = rist_destroy(s->rist_ctx);
+    if (ret < 0)
+    return risterr2ret(ret);
+    s->rist_ctx = NULL;
+
+    if (s->peer_config)
+    free((void *)s->peer_config);
+    s->peer_config = NULL;
+
+    if (s->logging_settings)
+    free((void *)s->logging_settings);


This is not a good idea. Afaik there could be more than one c library at 
play, the one linked by librist, and the one linked by libavformat.

This is why most libraries always end up adding custom free functions.

I see that rist_logging_set(), or anything in logging.h from this 
library for that matter, is undocumented, but reading the source code it 
seems it accepts your own allocated rist_logging_settings struct.
So IMO first consider asking for some doxy addition to the functions in 
order to make that officially supported, and then allocate it yourself 
in librist_open() with av_malloc(sizeof(*s->logging_settings)). 
Alternatively, they could provide a new rist_logging_free() function of 
sorts.


I guess you could also just keep it in heap instead of allocating it. No 
need to free it that way since it'll be part of RISTContext.




And same for peer_config above, except that rist_parse_address() does 
not accept your own allocated rist_peer_config struct. It only accepts 
an already initialized one from a previous call, so either that's 
changed, or a custom free() or a reset_to_defaults() function is added.


Not so much this one, for the same reason you can't pass a freshly 
allocated one.





+    s->logging_settings = NULL;
+
+    return 0;
+}
+
+static int librist_open(URLContext *h, const char *uri, int flags)
+{
+    RISTContext *s = h->priv_data;
+    int ret;
+
+    ret = rist_logging_set(>logging_settings, s->log_level, 
log_cb, h, NULL, stderr);

+    if (ret < 0)
+    return risterr2ret(ret);




___
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: add librist protocol

2020-12-23 Thread James Almer

On 12/23/2020 8:32 PM, Paul B Mahol wrote:

+static int librist_close(URLContext *h)
+{
+RISTContext *s = h->priv_data;
+int ret = 0;
+
+s->peer = NULL;
+
+if (s->rist_ctx)
+ret = rist_destroy(s->rist_ctx);
+if (ret < 0)
+return risterr2ret(ret);
+s->rist_ctx = NULL;
+
+if (s->peer_config)
+free((void *)s->peer_config);
+s->peer_config = NULL;
+
+if (s->logging_settings)
+free((void *)s->logging_settings);


This is not a good idea. Afaik there could be more than one c library at 
play, the one linked by librist, and the one linked by libavformat.

This is why most libraries always end up adding custom free functions.

I see that rist_logging_set(), or anything in logging.h from this 
library for that matter, is undocumented, but reading the source code it 
seems it accepts your own allocated rist_logging_settings struct.
So IMO first consider asking for some doxy addition to the functions in 
order to make that officially supported, and then allocate it yourself 
in librist_open() with av_malloc(sizeof(*s->logging_settings)). 
Alternatively, they could provide a new rist_logging_free() function of 
sorts.


And same for peer_config above, except that rist_parse_address() does 
not accept your own allocated rist_peer_config struct. It only accepts 
an already initialized one from a previous call, so either that's 
changed, or a custom free() or a reset_to_defaults() function is added.



+s->logging_settings = NULL;
+
+return 0;
+}
+
+static int librist_open(URLContext *h, const char *uri, int flags)
+{
+RISTContext *s = h->priv_data;
+int ret;
+
+ret = rist_logging_set(>logging_settings, s->log_level, log_cb, h, 
NULL, stderr);
+if (ret < 0)
+return risterr2ret(ret);


___
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] libavformat: add librist protocol

2020-12-23 Thread Paul B Mahol
This work is sponsored by Open Broadcast Systems.

Signed-off-by: Paul B Mahol 
---
 configure   |   5 +
 doc/protocols.texi  |  32 ++
 libavformat/Makefile|   1 +
 libavformat/librist.c   | 233 
 libavformat/protocols.c |   1 +
 5 files changed, 272 insertions(+)
 create mode 100644 libavformat/librist.c

diff --git a/configure b/configure
index 90914752f1..462f2dcf64 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
   --enable-libpulseenable Pulseaudio input via libpulse [no]
   --enable-librabbitmq enable RabbitMQ library [no]
   --enable-librav1eenable AV1 encoding via rav1e [no]
+  --enable-librist enable RIST via librist [no]
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librabbitmq
 librav1e
+librist
 librsvg
 librtmp
 libshine
@@ -3488,6 +3490,8 @@ unix_protocol_select="network"
 # external library protocols
 libamqp_protocol_deps="librabbitmq"
 libamqp_protocol_select="network"
+librist_protocol_deps="librist"
+librist_protocol_select="network"
 librtmp_protocol_deps="librtmp"
 librtmpe_protocol_deps="librtmp"
 librtmps_protocol_deps="librtmp"
@@ -6404,6 +6408,7 @@ enabled libopus   && {
 enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
 enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
 enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
+enabled librist   && require_pkg_config librist "librist >= 0.2" 
librist/librist.h rist_receiver_create
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index de377a9546..aa682f1586 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -673,6 +673,38 @@ Example usage:
 -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
 @end example
 
+@section rist
+
+Reliable Internet Streaming Transport protocol
+
+The accepted options are:
+@table @option
+@item rist_profile
+Supported values:
+@table @samp
+@item simple
+@item main
+This one is default.
+@item advanced
+@end table
+
+@item buffer_size
+Set internal RIST buffer size for retransmission of data.
+
+@item pkt_size
+Set internal RIST buffer size for receiving and sending data.
+
+@item log_level
+Set loglevel for RIST logging messages.
+
+@item secret
+Set override of encryption secret, by default is unset.
+
+@item encryption
+Set encryption type, by default is disabled.
+Acceptable values are 128 and 256.
+@end table
+
 @section rtmp
 
 Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 97d868081b..799e16c59e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
 
 # external library protocols
 OBJS-$(CONFIG_LIBAMQP_PROTOCOL)  += libamqp.o
+OBJS-$(CONFIG_LIBRIST_PROTOCOL)  += librist.o
 OBJS-$(CONFIG_LIBRTMP_PROTOCOL)  += librtmp.o
 OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
 OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
diff --git a/libavformat/librist.c b/libavformat/librist.c
new file mode 100644
index 00..dacdd4a859
--- /dev/null
+++ b/libavformat/librist.c
@@ -0,0 +1,233 @@
+/*
+ * 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
+ */
+
+/**
+ * @file
+ * Reliable Internet Streaming Transport protocol
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/time.h"
+
+#include "avformat.h"
+#include 

Re: [FFmpeg-devel] [PATCH] libavformat: add librist protocol

2020-12-23 Thread Marton Balint



On Wed, 23 Dec 2020, Paul B Mahol wrote:


On Wed, Dec 23, 2020 at 10:30 PM Marton Balint  wrote:





INT_MAX for pkt_size is probably not a good default. pkt_size is used (at
least in other protocols) to determine the maximum allowed packet size for
output, and the maximum supported packet size for input. I am not sure
what you can pump into RIST (mpegts most likely?) but probably it should
be determined for that usage. e.g. 1316?

Also the URLContext->max_packet_size should be set based on the
packet_size.

> +{ "log_level",   "set loglevel",OFFSET(log_level),
 AV_OPT_TYPE_INT,   {.i64=-1},   -1, INT_MAX, .flags = D|E
},
> +{ "secret", "set encryption secret",OFFSET(secret),
AV_OPT_TYPE_STRING,{.str=""},0, 0,   .flags = D|E },

default should rather be NULL, no?



Same thing.


Surely there is no significant difference, I just feel that it cleaner to 
use NULL as unspecified default.


[...]


> +static int librist_open(URLContext *h, const char *uri, int flags)
> +{
> +RISTContext *s = h->priv_data;
> +int ret;
> +
> +s->fd = rist_flow_id_create();
> +
> +ret = rist_logging_set(>logging_settings, s->log_level, log_cb,
h, NULL, stderr);

stderr should not be given, because we are using our own log callback.



Not used, thus not really relevant.


OK, but it still confused me that stderr may be used for anything. So 
yet again I believe it is cleaner to use NULL.


[...]


Some error handling should be done, e.g. reject encryption sizes not
supported, reject encryption without secret given, etc.



That is already handled.


As far as I see invalid encryption sizes are not rejected but silently 
ignored.



> +static int librist_get_file_handle(URLContext *h)
> +{
> +RISTContext *s = h->priv_data;
> +
> +return s->fd;
> +}

I don't think this is right, s->fd is a flow id, not an ordinary file
descriptor. You probably don't need this callback anyway.



Are you really sure it is not needed?


Nicolas already explained the use case for this callback, so yes, I think 
it is not needed.


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

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

Re: [FFmpeg-devel] [PATCH] libavformat: add librist protocol

2020-12-23 Thread Nicolas George
Paul B Mahol (12020-12-23):
> I nowhere see proof that this cause any bugs.

get_file_handle() returns a file descriptor for use with select() or
poll(). If you give it a random number (fd is a random number), the
application will poll it as if it were a file descriptor. At best, it
causes EBADFD. At worse the application starts polling an existing and
unrelated file descriptor, causing random behaviors.

> This is fortunately completely false statement. It works just fine.

It works fine because this part of the code is completely not tested by
any of the fftools.

-- 
  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] libavformat: add librist protocol

2020-12-23 Thread Nicolas George
Paul B Mahol (12020-12-23):
> This work is sponsored by Open Broadcast Systems.

Thanks for the disclosure.

> 
> Signed-off-by: Paul B Mahol 
> ---
>  configure   |   5 +
>  doc/protocols.texi  |  29 +
>  libavformat/Makefile|   1 +
>  libavformat/librist.c   | 227 
>  libavformat/protocols.c |   1 +
>  5 files changed, 263 insertions(+)
>  create mode 100644 libavformat/librist.c
> 
> diff --git a/configure b/configure
> index 90914752f1..462f2dcf64 100755
> --- a/configure
> +++ b/configure
> @@ -259,6 +259,7 @@ External library support:
>--enable-libpulseenable Pulseaudio input via libpulse [no]
>--enable-librabbitmq enable RabbitMQ library [no]
>--enable-librav1eenable AV1 encoding via rav1e [no]
> +  --enable-librist enable RIST via librist [no]
>--enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband   enable rubberband needed for rubberband filter 
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
> @@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
>  libpulse
>  librabbitmq
>  librav1e
> +librist
>  librsvg
>  librtmp
>  libshine
> @@ -3488,6 +3490,8 @@ unix_protocol_select="network"
>  # external library protocols
>  libamqp_protocol_deps="librabbitmq"
>  libamqp_protocol_select="network"
> +librist_protocol_deps="librist"
> +librist_protocol_select="network"
>  librtmp_protocol_deps="librtmp"
>  librtmpe_protocol_deps="librtmp"
>  librtmps_protocol_deps="librtmp"
> @@ -6404,6 +6408,7 @@ enabled libopus   && {
>  enabled libpulse  && require_pkg_config libpulse libpulse 
> pulse/pulseaudio.h pa_context_new
>  enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
> 0.7.1" amqp.h amqp_new_connection
>  enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
> rav1e.h rav1e_context_new
> +enabled librist   && require_pkg_config librist "librist >= 0.2" 
> librist/librist.h rist_receiver_create
>  enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
>  enabled librtmp   && require_pkg_config librtmp librtmp 
> librtmp/rtmp.h RTMP_Socket
>  enabled librubberband && require_pkg_config librubberband "rubberband >= 
> 1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
> librubberband_extralibs "-lstdc++"
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index de377a9546..58627040f5 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -673,6 +673,35 @@ Example usage:
>  -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
>  @end example
>  
> +@section rist
> +
> +Reliable Internet Streaming Transport protocol
> +
> +The accepted options are:
> +@table @option
> +@item rist_profile
> +Supported values:
> +@table @samp
> +@item simple
> +@item main
> +This one is default.
> +@item advanced
> +@end table
> +
> +@item buffer_size
> +Set internal RIST buffer size for receiving and sending data.
> +
> +@item log_level
> +Set loglevel for RIST logging messages.
> +
> +@item secret
> +Set override of encryption secret, by default is unset.
> +
> +@item encryption
> +Set encryption type, by default is disabled.
> +Acceptable values are 128 and 256.
> +@end table
> +
>  @section rtmp
>  
>  Real-Time Messaging Protocol.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 97d868081b..799e16c59e 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
>  
>  # external library protocols
>  OBJS-$(CONFIG_LIBAMQP_PROTOCOL)  += libamqp.o
> +OBJS-$(CONFIG_LIBRIST_PROTOCOL)  += librist.o
>  OBJS-$(CONFIG_LIBRTMP_PROTOCOL)  += librtmp.o
>  OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
>  OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
> diff --git a/libavformat/librist.c b/libavformat/librist.c
> new file mode 100644
> index 00..dbffb5cdc1
> --- /dev/null
> +++ b/libavformat/librist.c
> @@ -0,0 +1,227 @@
> +/*
> + * 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 

Re: [FFmpeg-devel] [PATCH] libavformat: add librist protocol

2020-12-23 Thread Paul B Mahol
On Wed, Dec 23, 2020 at 11:29 PM Nicolas George  wrote:

> Marton Balint (12020-12-23):
> > > +static int librist_get_file_handle(URLContext *h)
> > > +{
> > > +RISTContext *s = h->priv_data;
> > > +
> > > +return s->fd;
> > > +}
> >
> > I don't think this is right, s->fd is a flow id, not an ordinary file
> > descriptor. You probably don't need this callback anyway.
>
> It is indeed not a file descriptor at all, returning it like that would
> cause very serious bugs.
>
>
I nowhere see proof that this cause any bugs.


> It seems this library does not make its file descriptors at all. It
> means it cannot be used by FFmpeg in non-blocking mode, nor by any
> application with a standard Unix event loop


This is fortunately completely false statement. It works just fine.

.
>
> Regards,
>
> --
>   Nicolas George
> ___
> 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] libavformat: add librist protocol

2020-12-23 Thread Nicolas George
Marton Balint (12020-12-23):
> > +static int librist_get_file_handle(URLContext *h)
> > +{
> > +RISTContext *s = h->priv_data;
> > +
> > +return s->fd;
> > +}
> 
> I don't think this is right, s->fd is a flow id, not an ordinary file
> descriptor. You probably don't need this callback anyway.

It is indeed not a file descriptor at all, returning it like that would
cause very serious bugs.

It seems this library does not make its file descriptors at all. It
means it cannot be used by FFmpeg in non-blocking mode, nor by any
application with a standard Unix event loop.

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] libavformat: add librist protocol

2020-12-23 Thread Paul B Mahol
On Wed, Dec 23, 2020 at 10:30 PM Marton Balint  wrote:

>
>
> On Wed, 23 Dec 2020, Paul B Mahol wrote:
>
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol 
> > ---
> > configure   |   5 +
> > doc/protocols.texi  |  29 +
> > libavformat/Makefile|   1 +
> > libavformat/librist.c   | 227 
> > libavformat/protocols.c |   1 +
> > 5 files changed, 263 insertions(+)
> > create mode 100644 libavformat/librist.c
> >
> > diff --git a/configure b/configure
> > index 90914752f1..462f2dcf64 100755
> > --- a/configure
> > +++ b/configure
> > @@ -259,6 +259,7 @@ External library support:
> >   --enable-libpulseenable Pulseaudio input via libpulse [no]
> >   --enable-librabbitmq enable RabbitMQ library [no]
> >   --enable-librav1eenable AV1 encoding via rav1e [no]
> > +  --enable-librist enable RIST via librist [no]
> >   --enable-librsvg enable SVG rasterization via librsvg [no]
> >   --enable-librubberband   enable rubberband needed for rubberband
> filter [no]
> >   --enable-librtmp enable RTMP[E] support via librtmp [no]
> > @@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
> > libpulse
> > librabbitmq
> > librav1e
> > +librist
> > librsvg
> > librtmp
> > libshine
> > @@ -3488,6 +3490,8 @@ unix_protocol_select="network"
> > # external library protocols
> > libamqp_protocol_deps="librabbitmq"
> > libamqp_protocol_select="network"
> > +librist_protocol_deps="librist"
> > +librist_protocol_select="network"
> > librtmp_protocol_deps="librtmp"
> > librtmpe_protocol_deps="librtmp"
> > librtmps_protocol_deps="librtmp"
> > @@ -6404,6 +6408,7 @@ enabled libopus   && {
> > enabled libpulse  && require_pkg_config libpulse libpulse
> pulse/pulseaudio.h pa_context_new
> > enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq
> >= 0.7.1" amqp.h amqp_new_connection
> > enabled librav1e  && require_pkg_config librav1e "rav1e >=
> 0.1.0" rav1e.h rav1e_context_new
> > +enabled librist   && require_pkg_config librist "librist >=
> 0.2" librist/librist.h rist_receiver_create
> > enabled librsvg   && require_pkg_config librsvg librsvg-2.0
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
> > enabled librtmp   && require_pkg_config librtmp librtmp
> librtmp/rtmp.h RTMP_Socket
> > enabled librubberband && require_pkg_config librubberband
> "rubberband >= 1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ &&
> append librubberband_extralibs "-lstdc++"
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index de377a9546..58627040f5 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -673,6 +673,35 @@ Example usage:
> > -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
> > @end example
> >
> > +@section rist
> > +
> > +Reliable Internet Streaming Transport protocol
> > +
> > +The accepted options are:
> > +@table @option
> > +@item rist_profile
> > +Supported values:
> > +@table @samp
> > +@item simple
> > +@item main
> > +This one is default.
> > +@item advanced
> > +@end table
> > +
> > +@item buffer_size
> > +Set internal RIST buffer size for receiving and sending data.
> > +
> > +@item log_level
> > +Set loglevel for RIST logging messages.
> > +
> > +@item secret
> > +Set override of encryption secret, by default is unset.
> > +
> > +@item encryption
> > +Set encryption type, by default is disabled.
> > +Acceptable values are 128 and 256.
>
> What about 192?
>

 Unofficial.


>
> > +@end table
>
> Missing docs for pkt_size.
>
> Some usage examples could be useful.
>
> > +
> > @section rtmp
> >
> > Real-Time Messaging Protocol.
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 97d868081b..799e16c59e 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
> >
> > # external library protocols
> > OBJS-$(CONFIG_LIBAMQP_PROTOCOL)  += libamqp.o
> > +OBJS-$(CONFIG_LIBRIST_PROTOCOL)  += librist.o
> > OBJS-$(CONFIG_LIBRTMP_PROTOCOL)  += librtmp.o
> > OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
> > OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
> > diff --git a/libavformat/librist.c b/libavformat/librist.c
> > new file mode 100644
> > index 00..dbffb5cdc1
> > --- /dev/null
> > +++ b/libavformat/librist.c
> > @@ -0,0 +1,227 @@
> > +/*
> > + * 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
> > + * 

[FFmpeg-devel] [PATCH v3] avcodec/libvpxenc: add a way to set VP9E_SET_SVC_REF_FRAME_CONFIG

2020-12-23 Thread Wonkap Jang
In order to fine-control referencing schemes in VP9 encoding, there
is a need to use VP9E_SET_SVC_REF_FRAME_CONFIG method. This commit
provides a way to use the API through frame metadata.
---
 doc/encoders.texi  | 32 +
 libavcodec/libvpxenc.c | 81 ++
 2 files changed, 113 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 0b1c69e982..2a10bc0608 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2129,6 +2129,38 @@ midpoint is passed in rather than calculated for a 
specific clip or chunk.
 The valid range is [0, 1]. 0 (default) uses standard VBR.
 @item enable-tpl @var{boolean}
 Enable temporal dependency model.
+@item ref-frame-config
+Using per-frame metadata, set members of the structure 
@code{vpx_svc_ref_frame_config_t} in @code{vpx/vp8cx.h} to fine-control 
referencing schemes and frame buffer management.
+@*Use a :-separated list of key=value pairs.
+For example,
+@example
+av_dict_set(_frame->metadata, "ref-frame-config", \
+"rfc_update_buffer_slot=7:rfc_lst_fb_idx=0:rfc_gld_fb_idx=1:rfc_alt_fb_idx=2:rfc_reference_last=0:rfc_reference_golden=0:rfc_reference_alt_ref=0");}
+@end example
+@table @option
+@item rfc_update_buffer_slot
+Indicates the buffer slot number to update
+@item rfc_update_last
+Indicates whether to update the LAST frame
+@item rfc_update_golden
+Indicates whether to update GOLDEN frame
+@item rfc_update_alt_ref
+Indicates whether to update ALT_REF frame
+@item rfc_lst_fb_idx
+LAST frame buffer index
+@item rfc_gld_fb_idx
+GOLDEN frame buffer index
+@item rfc_alt_fb_idx
+ALT_REF frame buffer index
+@item rfc_reference_last
+Indicates whetehr to reference LAST frame
+@item rfc_reference_golden
+Indicates whether to reference GOLDEN frame
+@item rfc_reference_alt_ref
+Indicates whether to reference ALT_REF frame
+@item rfc_reference_duration
+Indicates frame duration
+@end table
 @end table
 
 @end table
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index a7c76eb835..4943a9e32c 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -125,6 +125,10 @@ typedef struct VPxEncoderContext {
  * encounter a frame with ROI side data.
  */
 int roi_warned;
+#if CONFIG_LIBVPX_VP9_ENCODER && defined 
(VPX_CTRL_VP9E_SET_MAX_INTER_BITRATE_PCT)
+vpx_svc_ref_frame_config_t ref_frame_config;
+AVDictionary *vpx_ref_frame_config;
+#endif
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -152,6 +156,7 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_SVC_LAYER_ID]= "VP9E_SET_SVC_LAYER_ID",
 #if VPX_ENCODER_ABI_VERSION >= 12
 [VP9E_SET_SVC_PARAMETERS]  = "VP9E_SET_SVC_PARAMETERS",
+[VP9E_SET_SVC_REF_FRAME_CONFIG]= "VP9E_SET_SVC_REF_FRAME_CONFIG",
 #endif
 [VP9E_SET_SVC] = "VP9E_SET_SVC",
 #if VPX_ENCODER_ABI_VERSION >= 11
@@ -394,6 +399,21 @@ static void vp8_ts_parse_int_array(int *dest, char *value, 
size_t value_len, int
 }
 }
 
+#if CONFIG_LIBVPX_VP9_ENCODER && defined 
(VPX_CTRL_VP9E_SET_MAX_INTER_BITRATE_PCT)
+static void vp8_ts_parse_int64_array(int64_t *dest, char *value, size_t 
value_len, int max_entries)
+{
+int dest_idx = 0;
+char *saveptr = NULL;
+char *token = av_strtok(value, ",", );
+
+while (token && dest_idx < max_entries) {
+dest[dest_idx++] = strtoul(token, NULL, 10);
+token = av_strtok(NULL, ",", );
+}
+}
+
+#endif
+
 static void set_temporal_layer_pattern(int layering_mode, vpx_codec_enc_cfg_t 
*cfg,
int *layer_flags, int *flag_periodicity)
 {
@@ -541,6 +561,49 @@ static int vpx_ts_param_parse(VPxContext *ctx, struct 
vpx_codec_enc_cfg *enccfg,
 return 0;
 }
 
+#if CONFIG_LIBVPX_VP9_ENCODER && defined 
(VPX_CTRL_VP9E_SET_MAX_INTER_BITRATE_PCT)
+static int vpx_ref_frame_config_parse(VPxContext *ctx, const struct 
vpx_codec_enc_cfg *enccfg,
+  char *key, char *value, enum AVCodecID codec_id)
+{
+size_t value_len = strlen(value);
+int ss_number_layers = enccfg->ss_number_layers;
+vpx_svc_ref_frame_config_t *ref_frame_config = >ref_frame_config;
+
+if (!value_len)
+return -1;
+
+if (codec_id != AV_CODEC_ID_VP9)
+return -1;
+
+if (!strcmp(key, "rfc_update_buffer_slot")) {
+vp8_ts_parse_int_array(ref_frame_config->update_buffer_slot, value, 
value_len, ss_number_layers);
+} else if (!strcmp(key, "rfc_update_last")) {
+vp8_ts_parse_int_array(ref_frame_config->update_last, value, 
value_len, ss_number_layers);
+} else if (!strcmp(key, "rfc_update_golden")) {
+vp8_ts_parse_int_array(ref_frame_config->update_golden, value, 
value_len, ss_number_layers);
+} else if (!strcmp(key, "rfc_update_alt_ref")) {
+vp8_ts_parse_int_array(ref_frame_config->update_alt_ref, value, 
value_len, ss_number_layers);
+} else if (!strcmp(key, "rfc_lst_fb_idx")) {
+

Re: [FFmpeg-devel] [PATCH] libavformat: add librist protocol

2020-12-23 Thread Marton Balint



On Wed, 23 Dec 2020, Paul B Mahol wrote:


This work is sponsored by Open Broadcast Systems.

Signed-off-by: Paul B Mahol 
---
configure   |   5 +
doc/protocols.texi  |  29 +
libavformat/Makefile|   1 +
libavformat/librist.c   | 227 
libavformat/protocols.c |   1 +
5 files changed, 263 insertions(+)
create mode 100644 libavformat/librist.c

diff --git a/configure b/configure
index 90914752f1..462f2dcf64 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
  --enable-libpulseenable Pulseaudio input via libpulse [no]
  --enable-librabbitmq enable RabbitMQ library [no]
  --enable-librav1eenable AV1 encoding via rav1e [no]
+  --enable-librist enable RIST via librist [no]
  --enable-librsvg enable SVG rasterization via librsvg [no]
  --enable-librubberband   enable rubberband needed for rubberband filter [no]
  --enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
libpulse
librabbitmq
librav1e
+librist
librsvg
librtmp
libshine
@@ -3488,6 +3490,8 @@ unix_protocol_select="network"
# external library protocols
libamqp_protocol_deps="librabbitmq"
libamqp_protocol_select="network"
+librist_protocol_deps="librist"
+librist_protocol_select="network"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
@@ -6404,6 +6408,7 @@ enabled libopus   && {
enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
+enabled librist   && require_pkg_config librist "librist >= 0.2" 
librist/librist.h rist_receiver_create
enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
enabled librubberband && require_pkg_config librubberband "rubberband >= 1.8.1" 
rubberband/rubberband-c.h rubberband_new -lstdc++ && append librubberband_extralibs "-lstdc++"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index de377a9546..58627040f5 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -673,6 +673,35 @@ Example usage:
-f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
@end example

+@section rist
+
+Reliable Internet Streaming Transport protocol
+
+The accepted options are:
+@table @option
+@item rist_profile
+Supported values:
+@table @samp
+@item simple
+@item main
+This one is default.
+@item advanced
+@end table
+
+@item buffer_size
+Set internal RIST buffer size for receiving and sending data.
+
+@item log_level
+Set loglevel for RIST logging messages.
+
+@item secret
+Set override of encryption secret, by default is unset.
+
+@item encryption
+Set encryption type, by default is disabled.
+Acceptable values are 128 and 256.


What about 192?


+@end table


Missing docs for pkt_size.

Some usage examples could be useful.


+
@section rtmp

Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 97d868081b..799e16c59e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o

# external library protocols
OBJS-$(CONFIG_LIBAMQP_PROTOCOL)  += libamqp.o
+OBJS-$(CONFIG_LIBRIST_PROTOCOL)  += librist.o
OBJS-$(CONFIG_LIBRTMP_PROTOCOL)  += librtmp.o
OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
diff --git a/libavformat/librist.c b/libavformat/librist.c
new file mode 100644
index 00..dbffb5cdc1
--- /dev/null
+++ b/libavformat/librist.c
@@ -0,0 +1,227 @@
+/*
+ * 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
+ */
+
+/**
+ * @file
+ * Reliable Internet Streaming Transport protocol
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/time.h"
+
+#include 

Re: [FFmpeg-devel] [PATCH] libswscale: avoid UB nullptr-with-offset.

2020-12-23 Thread Michael Niedermayer
On Tue, Dec 22, 2020 at 09:39:38AM +, jleconte wrote:
> Thanks for the feedback.
> It's not easy to work with -Wdeclaration-after-statement.

patch should be ok, is the author intended to be like this:
Author: jleconte 
I mean theres no full name in there 
Iam asking as this cannot be changed after applying the patch

thx

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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 2/2] avcodec/cfhd: properly handle midstream size changes for transform type 2

2020-12-23 Thread Michael Niedermayer
On Wed, Dec 23, 2020 at 05:01:44PM +0100, Paul B Mahol wrote:
> On Wed, Dec 23, 2020 at 4:07 PM Michael Niedermayer 
> wrote:
> 
> > On Wed, Dec 23, 2020 at 12:35:39PM +0100, Paul B Mahol wrote:
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavcodec/cfhd.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> > > index a4f4cb4b3c..ae0d4b9496 100644
> > > --- a/libavcodec/cfhd.c
> > > +++ b/libavcodec/cfhd.c
> > > @@ -1372,6 +1372,9 @@ static int update_thread_context(AVCodecContext
> > *dst, const AVCodecContext *src)
> > >  if (dst == src || psrc->transform_type == 0)
> > >  return 0;
> > >
> > > +if (pdst->plane[0].idwt_size != psrc->plane[0].idwt_size)
> > > +free_buffers(pdst);
> >
> > What if idwt_size is the same but the dimensions that is
> > width and height are not ?
> >
> 
> Yes, I will also check that.

then the change looks fine to me

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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] lavu: use address-of operator checking clock_gettime

2020-12-23 Thread Marvin Scholz
Ping.

On 8 Dec 2020, at 23:18, Marvin Scholz wrote:

> When targeting a recent enough macOS/iOS version that has clock_gettime
> it won't be a weak symbol, in which case clang warns for this check
> as it's always true:
>
>   warning: address of function 'clock_gettime' will always
>   evaluate to 'true'
>
> This warning is silenced by using the address-of operator to make
> the intent explicit.
> ---
>  libavutil/time.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/time.c b/libavutil/time.c
> index afa6658aa6..740afc4785 100644
> --- a/libavutil/time.c
> +++ b/libavutil/time.c
> @@ -57,7 +57,7 @@ int64_t av_gettime_relative(void)
>  {
>  #if HAVE_CLOCK_GETTIME && defined(CLOCK_MONOTONIC)
>  #ifdef __APPLE__
> -if (clock_gettime)
> +if (_gettime)
>  #endif
>  {
>  struct timespec ts;
> @@ -72,7 +72,7 @@ int av_gettime_relative_is_monotonic(void)
>  {
>  #if HAVE_CLOCK_GETTIME && defined(CLOCK_MONOTONIC)
>  #ifdef __APPLE__
> -if (!clock_gettime)
> +if (!_gettime)
>  return 0;
>  #endif
>  return 1;
> -- 
> 2.24.3 (Apple Git-128)
___
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] FW: [PATCH] http: support retry on connection error

2020-12-23 Thread Eran Kornblau
Pinging again... hope this can be merged...

-Original Message-
From: Eran Kornblau 
Sent: Wednesday, December 16, 2020 9:18 PM
To: FFmpeg development discussions and patches 
Subject: FW: [FFmpeg-devel] [PATCH] http: support retry on connection error

Ping...

-Original Message-
From: Eran Kornblau
Sent: Thursday, December 10, 2020 8:25 AM
To: FFmpeg development discussions and patches 
Subject: RE: [FFmpeg-devel] [PATCH] http: support retry on connection error

Resending...

-Original Message-
From: Eran Kornblau
Sent: Thursday, December 3, 2020 10:52 AM
To: FFmpeg development discussions and patches 
Subject: RE: [FFmpeg-devel] [PATCH] http: support retry on connection error

Hi Marton,

Thank you for the feedback, and sorry for my late reply :) Please see my 
responses inline, updated patch attached.

Thanks
Eran

> -Original Message-
> From: ffmpeg-devel  On Behalf Of 
> Marton Balint
> Sent: Wednesday, November 18, 2020 10:46 PM
> To: FFmpeg development discussions and patches 
> 
> Subject: Re: [FFmpeg-devel] [PATCH] http: support retry on connection 
> error
> 
> 
> > - reconnect_on_status - a list of http status codes that should be
> > retried. the list can contain explicit status codes / the strings
> > 4xx/5xx.
> 
> Maybe better name this option reconnect_on_http_error. Also this is a 
> flags-like option, so use AV_OPT_TYPE_FLAGS with 4xx and 5xx as flags.
> 
Rename - done.

Flags - the patch supports both explicit status codes (e.g. 503) and status 
groups (e.g. 4xx).
For example, it is possible to specify -reconnect_on_http_error '4xx,503'.

In my understanding, AV_OPT_TYPE_FLAGS is a simple int, so the only to support 
what I wrote above, is to assign bits to specific status codes, and I don't 
think we want to go there... (because every time someone will want to retry on 
a new status code, we will need to update the code)

> 
> > - reconnect_on_err - reconnects on arbitrary errors during connect, e.g.
> > ECONNRESET/ETIMEDOUT
> 
> Maybe reconnect_on_network_error better reflects that this reconnects 
> on underlying protocol (TCP/TLS) error.
> 
> Anyhow, the new options should be added to docs/protocols.texi.
> 
Rename & docs - done.

> > 
> > +{ "reconnect_on_err", "auto reconnect in case of tcp/tls error during 
> > connect", OFFSET(reconnect_on_err), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D 
> > },
> > +{ "reconnect_on_status", "list of http status codes to 
> > + reconnect on. the list can include specific status codes / 4xx / 
> > + 5xx", OFFSET(reconnect_on_status), AV_OPT_TYPE_STRING, { .str = 
> > + NULL }, 0, 0, D },
> 
> AV_OPT_TYPE_FLAGS, as I explained above.
> 
Replied above

> > 
> >  location_changed = http_open_cnx_internal(h, options);
> 
> Are you sure you get AVERROR_HTTP_* here? Also if you follow the code 
> there is special handling of 401/407, that should be done first before 
> your checks, no?
> 
1. Yes, I tested the change before submitting, used some test PHP server to 
simulate errors.
This is the call stack that propagates the AVERROR_HTTP_* codes -
http_open_cnx_internal
http_connect
http_read_header
process_line
check_http_code

2. In case of 401/407, check_http_code returns 0, and therefore 
http_open_cnx_internal return 0 as well (assuming there is no other error...). 
So, it doesn't enter 'if (location_changed < 0)' and it behaves the same 
way it did before my changes.

> 
> Another comment is that if you want to reconnect based on errors 
> classified as 4xx or 5xx, then probably you should revisit 
> ff_http_averror(400, xxx) calls and check if they are indeed caused by 
> client behaviour. Because if the server is violating the protocol, 
> then they should be ff_http_averror(500, xxx) IMHO.
> 
Checked the code, I see 2 cases of ff_http_averror(400, xxx) - 1. HTTP server 
received an unexpected http method (would have been more correct to use 405, 
but don't think it matters...) 2. HTTP server received an invalid http version 
string So, I think it's fine.


> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmp
> eg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=04%7C01%7Ceran.kor
> nblau%40kaltura.com%7C590db1ef6c4d484bb34508d88c030453%7C0c503748de3f4
> e2597e26819d53a42b6%7C0%7C0%7C637413291875784243%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000sdata=hemm499pmQQQEDOc4FXeq1EThvOT7FyfjWRsylFvdm0%3Dre
> served=0
> 
> To unsubscribe, visit link above, or email 
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>


0001-http-support-retry-on-connection-error.patch
Description: 0001-http-support-retry-on-connection-error.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] libavformat: add librist protocol

2020-12-23 Thread Paul B Mahol
This work is sponsored by Open Broadcast Systems.

Signed-off-by: Paul B Mahol 
---
 configure   |   5 +
 doc/protocols.texi  |  29 +
 libavformat/Makefile|   1 +
 libavformat/librist.c   | 227 
 libavformat/protocols.c |   1 +
 5 files changed, 263 insertions(+)
 create mode 100644 libavformat/librist.c

diff --git a/configure b/configure
index 90914752f1..462f2dcf64 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
   --enable-libpulseenable Pulseaudio input via libpulse [no]
   --enable-librabbitmq enable RabbitMQ library [no]
   --enable-librav1eenable AV1 encoding via rav1e [no]
+  --enable-librist enable RIST via librist [no]
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1797,6 +1798,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librabbitmq
 librav1e
+librist
 librsvg
 librtmp
 libshine
@@ -3488,6 +3490,8 @@ unix_protocol_select="network"
 # external library protocols
 libamqp_protocol_deps="librabbitmq"
 libamqp_protocol_select="network"
+librist_protocol_deps="librist"
+librist_protocol_select="network"
 librtmp_protocol_deps="librtmp"
 librtmpe_protocol_deps="librtmp"
 librtmps_protocol_deps="librtmp"
@@ -6404,6 +6408,7 @@ enabled libopus   && {
 enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
 enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
 enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
+enabled librist   && require_pkg_config librist "librist >= 0.2" 
librist/librist.h rist_receiver_create
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index de377a9546..58627040f5 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -673,6 +673,35 @@ Example usage:
 -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
 @end example
 
+@section rist
+
+Reliable Internet Streaming Transport protocol
+
+The accepted options are:
+@table @option
+@item rist_profile
+Supported values:
+@table @samp
+@item simple
+@item main
+This one is default.
+@item advanced
+@end table
+
+@item buffer_size
+Set internal RIST buffer size for receiving and sending data.
+
+@item log_level
+Set loglevel for RIST logging messages.
+
+@item secret
+Set override of encryption secret, by default is unset.
+
+@item encryption
+Set encryption type, by default is disabled.
+Acceptable values are 128 and 256.
+@end table
+
 @section rtmp
 
 Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 97d868081b..799e16c59e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -652,6 +652,7 @@ OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
 
 # external library protocols
 OBJS-$(CONFIG_LIBAMQP_PROTOCOL)  += libamqp.o
+OBJS-$(CONFIG_LIBRIST_PROTOCOL)  += librist.o
 OBJS-$(CONFIG_LIBRTMP_PROTOCOL)  += librtmp.o
 OBJS-$(CONFIG_LIBRTMPE_PROTOCOL) += librtmp.o
 OBJS-$(CONFIG_LIBRTMPS_PROTOCOL) += librtmp.o
diff --git a/libavformat/librist.c b/libavformat/librist.c
new file mode 100644
index 00..dbffb5cdc1
--- /dev/null
+++ b/libavformat/librist.c
@@ -0,0 +1,227 @@
+/*
+ * 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
+ */
+
+/**
+ * @file
+ * Reliable Internet Streaming Transport protocol
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/time.h"
+
+#include "avformat.h"
+#include "internal.h"
+#include "network.h"
+#include "os_support.h"
+#include "url.h"

Re: [FFmpeg-devel] [PATCH 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread Nuo Mi
sure, thanks all for the suggestions.

On Thu, Dec 24, 2020 at 12:24 AM Lynne  wrote:

> Dec 23, 2020, 16:48 by jamr...@gmail.com:
>
> > On 12/23/2020 12:38 PM, Nuo Mi wrote:
> >
> >> On Wed, Dec 23, 2020 at 10:00 PM Lynne  wrote:
> >>
> >>> Dec 23, 2020, 14:07 by nuomi2...@gmail.com:
> >>>
>  Hi Lynne & James,
>  Do not worry about the dav1d things that happened on vvcdec. It just a
>  reference code like libaom.
> 
> >>>
> >>> libaom does encoding and decoding. And most people only use
> >>> it for encoding, as its not a very fast decoder. As-is, this patch
> >>> only does decoding.
> >>>
> >> how about we replace vvdec with vtm. I guess it's not faster than vvdec,
> >> but it has an encoder.
> >>
> >
> > Lets focus on getting the public defines, CBS module, parser and raw
> bitstream demuxer in first. Then we can see if an external decoder library
> should be added, and which one.
> >
>
> +1
> This patch can be pinged or resubmitted later on.
> (as an aside, I'd rather not have the reference implementation, the MPEG
> ones like HM or JM have never ever been packaged by any distribution,
> and with good reason, they're very unusable)
> ___
> 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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread Lynne
Dec 23, 2020, 16:48 by jamr...@gmail.com:

> On 12/23/2020 12:38 PM, Nuo Mi wrote:
>
>> On Wed, Dec 23, 2020 at 10:00 PM Lynne  wrote:
>>
>>> Dec 23, 2020, 14:07 by nuomi2...@gmail.com:
>>>
 Hi Lynne & James,
 Do not worry about the dav1d things that happened on vvcdec. It just a
 reference code like libaom.

>>>
>>> libaom does encoding and decoding. And most people only use
>>> it for encoding, as its not a very fast decoder. As-is, this patch
>>> only does decoding.
>>>
>> how about we replace vvdec with vtm. I guess it's not faster than vvdec,
>> but it has an encoder.
>>
>
> Lets focus on getting the public defines, CBS module, parser and raw 
> bitstream demuxer in first. Then we can see if an external decoder library 
> should be added, and which one.
>

+1
This patch can be pinged or resubmitted later on.
(as an aside, I'd rather not have the reference implementation, the MPEG
ones like HM or JM have never ever been packaged by any distribution,
and with good reason, they're very unusable)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] ffmpeg: delay first stats

2020-12-23 Thread Gyan Doshi

Plan to push tomorrow morning.

On 23-12-2020 04:53 pm, Gyan Doshi wrote:

Wait for all output files to be initialized before printing first stats.

Avoids breaking output file dump report.
---
  fftools/ffmpeg.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2c0820aacf..84a60f944a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -136,6 +136,7 @@ static int nb_frames_dup = 0;
  static unsigned dup_warning = 1000;
  static int nb_frames_drop = 0;
  static int64_t decode_error_stat[2];
+static unsigned nb_output_dumped = 0;
  
  static int want_sdp = 1;
  
@@ -1699,7 +1700,8 @@ static void print_report(int is_last_report, int64_t timer_start, int64_t cur_ti

  if (last_time == -1) {
  last_time = cur_time;
  }
-if ((cur_time - last_time) < stats_period && !first_report)
+if (((cur_time - last_time) < stats_period && !first_report) ||
+(first_report && nb_output_dumped < nb_output_files))
  return;
  last_time = cur_time;
  }
@@ -3017,6 +3019,7 @@ static int check_init_output_file(OutputFile *of, int 
file_index)
  of->header_written = 1;
  
  av_dump_format(of->ctx, file_index, of->ctx->url, 1);

+nb_output_dumped++;
  
  if (sdp_filename || want_sdp)

  print_sdp();


___
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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread James Almer

On 12/23/2020 12:38 PM, Nuo Mi wrote:

On Wed, Dec 23, 2020 at 10:00 PM Lynne  wrote:


Dec 23, 2020, 14:07 by nuomi2...@gmail.com:


Hi Lynne & James,
Do not worry about the dav1d things that happened on vvcdec. It just a
reference code like libaom.



libaom does encoding and decoding. And most people only use
it for encoding, as its not a very fast decoder. As-is, this patch
only does decoding.


how about we replace vvdec with vtm. I guess it's not faster than vvdec,
but it has an encoder.


Lets focus on getting the public defines, CBS module, parser and raw 
bitstream demuxer in first. Then we can see if an external decoder 
library should be added, and which one.


Thanks.
___
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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread chen



At 2020-12-23 23:38:18, "Nuo Mi"  wrote:
>On Wed, Dec 23, 2020 at 10:00 PM Lynne  wrote:
>
>> Dec 23, 2020, 14:07 by nuomi2...@gmail.com:
>>
>> > Hi Lynne & James,
>> > Do not worry about the dav1d things that happened on vvcdec. It just a
>> > reference code like libaom.
>> >
>>
>> libaom does encoding and decoding. And most people only use
>> it for encoding, as its not a very fast decoder. As-is, this patch
>> only does decoding.
>>
>how about we replace vvdec with vtm. I guess it's not faster than vvdec,
>but it has an encoder.

>
there have project vvenc for encoder, it is a subset of vtm
___
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 2/2] avcodec/cfhd: properly handle midstream size changes for transform type 2

2020-12-23 Thread Paul B Mahol
On Wed, Dec 23, 2020 at 4:07 PM Michael Niedermayer 
wrote:

> On Wed, Dec 23, 2020 at 12:35:39PM +0100, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/cfhd.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> > index a4f4cb4b3c..ae0d4b9496 100644
> > --- a/libavcodec/cfhd.c
> > +++ b/libavcodec/cfhd.c
> > @@ -1372,6 +1372,9 @@ static int update_thread_context(AVCodecContext
> *dst, const AVCodecContext *src)
> >  if (dst == src || psrc->transform_type == 0)
> >  return 0;
> >
> > +if (pdst->plane[0].idwt_size != psrc->plane[0].idwt_size)
> > +free_buffers(pdst);
>
> What if idwt_size is the same but the dimensions that is
> width and height are not ?
>

Yes, I will also check that.


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
> ___
> 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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread Nuo Mi
On Wed, Dec 23, 2020 at 10:00 PM Lynne  wrote:

> Dec 23, 2020, 14:07 by nuomi2...@gmail.com:
>
> > Hi Lynne & James,
> > Do not worry about the dav1d things that happened on vvcdec. It just a
> > reference code like libaom.
> >
>
> libaom does encoding and decoding. And most people only use
> it for encoding, as its not a very fast decoder. As-is, this patch
> only does decoding.
>
how about we replace vvdec with vtm. I guess it's not faster than vvdec,
but it has an encoder.


>
>
> > We will not have a useable native vvc decoder in 0.5~1 years.
> >
>
> Then why merge this if its not usable and won't stick once a usable
> decoder is written?
>
decoder just one block, to make vvc usable, we still work on other things.
Have a workable decoder will speed up the work.


>
> > During this
> > time, the wrapper can help us build many things, like container demuxer,
> > hls/dash/rtsp network streaming...
> > How about we flag the decoder as experimental, and declare we will retire
> > it after the native codec is ready.
> >
>
> We don't do experimental decoders in general.
>
>
> > Hi Marton,
> > Fully agree with you, all codecs are created equal, only the market can
> > decide which one is the winner.
> >
>
> I don't believe Matron said anything like this.
> Also did you steal this line from the Bible or something :)
>
yeah, from a famous American bible. :)


> ___
> 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 2/2] avcodec/cfhd: properly handle midstream size changes for transform type 2

2020-12-23 Thread Michael Niedermayer
On Wed, Dec 23, 2020 at 12:35:39PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/cfhd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index a4f4cb4b3c..ae0d4b9496 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -1372,6 +1372,9 @@ static int update_thread_context(AVCodecContext *dst, 
> const AVCodecContext *src)
>  if (dst == src || psrc->transform_type == 0)
>  return 0;
>  
> +if (pdst->plane[0].idwt_size != psrc->plane[0].idwt_size)
> +free_buffers(pdst);

What if idwt_size is the same but the dimensions that is 
width and height are not ?

thx

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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 1/2] avcodec/cfhd: only increase s->level if transform is known

2020-12-23 Thread Michael Niedermayer
On Wed, Dec 23, 2020 at 12:35:38PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/cfhd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index a2b9c7c76a..a4f4cb4b3c 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -436,7 +436,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
> int *got_frame,
>  }
>  init_plane_defaults(s);
>  } else if (tag == SubbandNumber) {
> -if (s->subband_num != 0 && data == 1)  // hack
> +if (s->subband_num != 0 && data == 1 && s->transform_type >= 0)  
> // hack
>  s->level++;
>  av_log(avctx, AV_LOG_DEBUG, "Subband number %"PRIu16"\n", data);
>  s->subband_num = data;

What about all the other places which use transform_type ?
If its allowed never to set transform_type or to set it between several uses 
of transform_type. 
Is that always safe ?

Iam asking because that should not be possible with enforced order and a 
mandatory
transform_type element. But that is not enforced with your solution.

Thanks

[...]
-- 
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
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 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Paul B Mahol
On Wed, Dec 23, 2020 at 3:59 PM Michael Niedermayer 
wrote:

> On Wed, Dec 23, 2020 at 10:52:03AM +0100, Paul B Mahol wrote:
> > On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer
> 
> > wrote:
> >
> > > On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote:
> > > > Unacceptable, please share privately sample that allows to reproduce
> > > this.
> > >
> > > shared the ones which reproduce.
> > >
> > > Please explain why this patch is unacceptable to you.
> > >
> > > the CFHD decoder decodes header elements in the order in which they are
> > > stored. The problem is that many have interdependancies yet there are
> > > no checks for these. And where there are checks theres no protection
> > > against changing dependancies after they have been used.
> > > Basically CFHD allows an attacker to do absolutely anything
> > >
> > > To pick a random example:
> > > the code reading the SubbandNumber adjusts the level and then
> > > checks its range based on transform_type. Yet transform_type
> > > may be not set yet or may be subsequently changed.
> > > That is issue 27872
> > >
> > > One surely can try to add specific checks for all this but i doubt that
> > > will
> > > result in secure code anytime soon. Its IMO better to fundamentally
> > > fix this and not allow anything to occur in any multiplicity and order.
> > > My posted patch is one way of many possible alternatives to move in
> that
> > > direction
> > >
> > >
> > Well, you forgot that when you check for order of tags, you basically
> still
> > allow
> > crash to happen, just this time crashing code path needs to follow
> correct
> > parsing order.
>
> I dont see how that would be possible
>
> with the correct order of tags
> transform_type is set and checked and can after that only be 0 or 2
> the crash required it to be -1. As transform_type is marked as a mandatory
> element in the table and -1 is not a possible value after it i dont see
> how that could work.
> But maybe iam missing something
>

Transform type is always set, so that one can always be checked that it is
set to correct value.
But above code is too complex for my alternative fix.
___
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 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Michael Niedermayer
On Wed, Dec 23, 2020 at 10:52:03AM +0100, Paul B Mahol wrote:
> On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer 
> wrote:
> 
> > On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote:
> > > Unacceptable, please share privately sample that allows to reproduce
> > this.
> >
> > shared the ones which reproduce.
> >
> > Please explain why this patch is unacceptable to you.
> >
> > the CFHD decoder decodes header elements in the order in which they are
> > stored. The problem is that many have interdependancies yet there are
> > no checks for these. And where there are checks theres no protection
> > against changing dependancies after they have been used.
> > Basically CFHD allows an attacker to do absolutely anything
> >
> > To pick a random example:
> > the code reading the SubbandNumber adjusts the level and then
> > checks its range based on transform_type. Yet transform_type
> > may be not set yet or may be subsequently changed.
> > That is issue 27872
> >
> > One surely can try to add specific checks for all this but i doubt that
> > will
> > result in secure code anytime soon. Its IMO better to fundamentally
> > fix this and not allow anything to occur in any multiplicity and order.
> > My posted patch is one way of many possible alternatives to move in that
> > direction
> >
> >
> Well, you forgot that when you check for order of tags, you basically still
> allow
> crash to happen, just this time crashing code path needs to follow correct
> parsing order.

I dont see how that would be possible

with the correct order of tags
transform_type is set and checked and can after that only be 0 or 2
the crash required it to be -1. As transform_type is marked as a mandatory
element in the table and -1 is not a possible value after it i dont see
how that could work.
But maybe iam missing something

thx

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread Lynne
Dec 23, 2020, 14:07 by nuomi2...@gmail.com:

> Hi Lynne & James,
> Do not worry about the dav1d things that happened on vvcdec. It just a
> reference code like libaom.
>

libaom does encoding and decoding. And most people only use
it for encoding, as its not a very fast decoder. As-is, this patch
only does decoding.


> We will not have a useable native vvc decoder in 0.5~1 years.
>

Then why merge this if its not usable and won't stick once a usable
decoder is written?


> During this
> time, the wrapper can help us build many things, like container demuxer,
> hls/dash/rtsp network streaming...
> How about we flag the decoder as experimental, and declare we will retire
> it after the native codec is ready.
>

We don't do experimental decoders in general.


> Hi Marton,
> Fully agree with you, all codecs are created equal, only the market can
> decide which one is the winner.
>

I don't believe Matron said anything like this.
Also did you steal this line from the Bible or something :)
___
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 6/6] avcodec: add vvdec H.266/VVC decoder

2020-12-23 Thread Nuo Mi
Hi Lynne & James,
Do not worry about the dav1d things that happened on vvcdec. It just a
reference code like libaom.
We will not have a useable native vvc decoder in 0.5~1 years. During this
time, the wrapper can help us build many things, like container demuxer,
hls/dash/rtsp network streaming...
How about we flag the decoder as experimental, and declare we will retire
it after the native codec is ready.

Hi Marton,
Fully agree with you, all codecs are created equal, only the market can
decide which one is the winner.

Regards.




On Wed, Dec 23, 2020 at 4:14 AM Lynne  wrote:

> Dec 22, 2020, 19:24 by c...@passwd.hu:
>
> >
> >
> > On Tue, 22 Dec 2020, Lynne wrote:
> >
> >> Dec 21, 2020, 07:07 by nuomi2...@gmail.com:
> >>
> >>> you can download test clips here:
> >>>
> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/
> >>>
> >>
> >> Honestly, I'm not sure about this patch. Its an external library
> decoder, which
> >> doesn't help us very much, and its for a codec competing with another
> codec
> >> (AV1) for which we don't really have a native decoder for yet. Not to
> mention
> >> some of us were involved with the effort to standardize and/or write a
> decoder
> >> for AV1, so there's also a personal element to not wanting VVC to have
> any
> >> success.
> >>
> >
> > I don't think it is a good idea to reject features in the project based
> on personal preference against a codec/format/company.
> >
>
> That was an insignificant part of my argument against it. I wouldn't even
> have mentioned this if I was the only one who was involved with AV1.
> Also its no so much "personal" as it is "political".
>
> My main point is accepting this wrapper doesn't help the project directly,
> instead it would result in a yet-another-libdav1d which might for real
> never
> actually get merged as VVC doesn't reach anywhere near the ubiquity the
> companies involved would have liked it to.
> We already have a dozen I-can't-believe-its-not-H264 library-only decoders.
>
> ___
> 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".

[FFmpeg-devel] [PATCH 2/2] avcodec/cfhd: properly handle midstream size changes for transform type 2

2020-12-23 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/cfhd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index a4f4cb4b3c..ae0d4b9496 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -1372,6 +1372,9 @@ static int update_thread_context(AVCodecContext *dst, 
const AVCodecContext *src)
 if (dst == src || psrc->transform_type == 0)
 return 0;
 
+if (pdst->plane[0].idwt_size != psrc->plane[0].idwt_size)
+free_buffers(pdst);
+
 pdst->a_format = psrc->a_format;
 pdst->a_width  = psrc->a_width;
 pdst->a_height = psrc->a_height;
-- 
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 1/2] avcodec/cfhd: only increase s->level if transform is known

2020-12-23 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/cfhd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index a2b9c7c76a..a4f4cb4b3c 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -436,7 +436,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 }
 init_plane_defaults(s);
 } else if (tag == SubbandNumber) {
-if (s->subband_num != 0 && data == 1)  // hack
+if (s->subband_num != 0 && data == 1 && s->transform_type >= 0)  
// hack
 s->level++;
 av_log(avctx, AV_LOG_DEBUG, "Subband number %"PRIu16"\n", data);
 s->subband_num = data;
-- 
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 v2] ffmpeg: delay first stats

2020-12-23 Thread Gyan Doshi
Wait for all output files to be initialized before printing first stats.

Avoids breaking output file dump report.
---
 fftools/ffmpeg.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2c0820aacf..84a60f944a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -136,6 +136,7 @@ static int nb_frames_dup = 0;
 static unsigned dup_warning = 1000;
 static int nb_frames_drop = 0;
 static int64_t decode_error_stat[2];
+static unsigned nb_output_dumped = 0;
 
 static int want_sdp = 1;
 
@@ -1699,7 +1700,8 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 if (last_time == -1) {
 last_time = cur_time;
 }
-if ((cur_time - last_time) < stats_period && !first_report)
+if (((cur_time - last_time) < stats_period && !first_report) ||
+(first_report && nb_output_dumped < nb_output_files))
 return;
 last_time = cur_time;
 }
@@ -3017,6 +3019,7 @@ static int check_init_output_file(OutputFile *of, int 
file_index)
 of->header_written = 1;
 
 av_dump_format(of->ctx, file_index, of->ctx->url, 1);
+nb_output_dumped++;
 
 if (sdp_filename || want_sdp)
 print_sdp();
-- 
2.27.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] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 04:03 pm, Nicolas George wrote:

Gyan Doshi (12020-12-23):

It's    void av_dump_format(...)

Seems too trivial to change it , or add + initialize yet another global
variable just for this.

Exactly. Dumping the output is a global affair, it can warrant a global
variable. Something like this:

 of->header_written = 1;

 av_dump_format(of->ctx, file_index, of->ctx->url, 1);
+   output_dumped++;

...

+   if (output_dumped >= nb_output_files) {
 ...
+   }

That way, the initial stat is printed as early as possible, but will not
mangle the dump. And if the dump is very late, it is acceptable to have
the 500ms timeout too:

+   if (output_dumped >= nb_output_files || blah >= 50) {


Ok. Will work on this.

But I still think I should post an immediate fix that handles it for 90% 
of cases.


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Nicolas George
Gyan Doshi (12020-12-23):
> It's    void av_dump_format(...)
> 
> Seems too trivial to change it , or add + initialize yet another global
> variable just for this.

Exactly. Dumping the output is a global affair, it can warrant a global
variable. Something like this:

of->header_written = 1;

av_dump_format(of->ctx, file_index, of->ctx->url, 1);
+   output_dumped++;

...

+   if (output_dumped >= nb_output_files) {
...
+   }

That way, the initial stat is printed as early as possible, but will not
mangle the dump. And if the dump is very late, it is acceptable to have
the 500ms timeout too:

+   if (output_dumped >= nb_output_files || blah >= 50) {

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] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 03:53 pm, Nicolas George wrote:

Gyan Doshi (12020-12-23):

That's not the issue. It's the mangled line - the output from lavf/dump.c.
mangled with stats line

AV_NOPTS_VALUE is an acceptable value and already checked for at line 1815.
As is <=0 output size.

Indicating to the user that ffmpeg processing has stalled at the beginning
is a valid and acceptable outcome, even a necessary one.
The delay here is just to avoid the mangling. Some hardcoded value is the
best that I see we can do, but if you have an analytical solution, I'm all
ears.

Ah, I see. But in that case, the proper solution seems obvious: set a
flag when av_dump_format() has returned, and delay the printing until
that flag is set. Or am I still missing something?


It's    void av_dump_format(...)

Seems too trivial to change it , or add + initialize yet another global 
variable just for this.


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Nicolas George
Gyan Doshi (12020-12-23):
> That's not the issue. It's the mangled line - the output from lavf/dump.c.
> mangled with stats line
> 
> AV_NOPTS_VALUE is an acceptable value and already checked for at line 1815.
> As is <=0 output size.
> 
> Indicating to the user that ffmpeg processing has stalled at the beginning
> is a valid and acceptable outcome, even a necessary one.
> The delay here is just to avoid the mangling. Some hardcoded value is the
> best that I see we can do, but if you have an analytical solution, I'm all
> ears.

Ah, I see. But in that case, the proper solution seems obvious: set a
flag when av_dump_format() has returned, and delay the printing until
that flag is set. Or am I still missing something?

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] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 03:35 pm, Nicolas George wrote:

Gyan Doshi (12020-12-23):

Which piece of info or object would indicate that? At the stage of this
check, I don't see any available.

Read Michael's mail:

Output #0, avi, to 'file.avi':=   0kB time=-577014:32:22.77 bitrate= 
-0.0kbits/s speed=N/A

The problem is obviously the time. The large negative number looks like
it was converted from AV_NOPTS_VALUE, so test if the PTS being printed
is AV_NOPTS_VALUE or not.


That's not the issue. It's the mangled line - the output from 
lavf/dump.c. mangled with stats line


AV_NOPTS_VALUE is an acceptable value and already checked for at line 
1815. As is <=0 output size.


Indicating to the user that ffmpeg processing has stalled at the 
beginning is a valid and acceptable outcome, even a necessary one.
The delay here is just to avoid the mangling. Some hardcoded value is 
the best that I see we can do, but if you have an analytical solution, 
I'm all ears.


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Nicolas George
Gyan Doshi (12020-12-23):
> Which piece of info or object would indicate that? At the stage of this
> check, I don't see any available.

Read Michael's mail:

Output #0, avi, to 'file.avi':=   0kB time=-577014:32:22.77 bitrate= 
-0.0kbits/s speed=N/A

The problem is obviously the time. The large negative number looks like
it was converted from AV_NOPTS_VALUE, so test if the PTS being printed
is AV_NOPTS_VALUE or not.

> Earlier, it was hardcoded to 500 ms. I chose something more apt for 2020,
> but 500 ms is fine as well.

If you fix it, fix it properly, please.

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] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 03:12 pm, Nicolas George wrote:

Gyan Doshi (12020-12-23):

Avoids breaking output file dump report.
---
  fftools/ffmpeg.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

This looks broken. Why 100ms? Because on your setup, 80ms is not enough
but 100ms is? On a slower system, it would need to be 120 or 200.

Test if the info to be printed is already valid.


Which piece of info or object would indicate that? At the stage of this 
check, I don't see any available.


Earlier, it was hardcoded to 500 ms. I chose something more apt for 
2020, but 500 ms is fine as well.


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

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Paul B Mahol
On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer 
wrote:

> On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote:
> > Unacceptable, please share privately sample that allows to reproduce
> this.
>
> shared the ones which reproduce.
>
> Please explain why this patch is unacceptable to you.
>
> the CFHD decoder decodes header elements in the order in which they are
> stored. The problem is that many have interdependancies yet there are
> no checks for these. And where there are checks theres no protection
> against changing dependancies after they have been used.
> Basically CFHD allows an attacker to do absolutely anything
>
> To pick a random example:
> the code reading the SubbandNumber adjusts the level and then
> checks its range based on transform_type. Yet transform_type
> may be not set yet or may be subsequently changed.
> That is issue 27872
>
> One surely can try to add specific checks for all this but i doubt that
> will
> result in secure code anytime soon. Its IMO better to fundamentally
> fix this and not allow anything to occur in any multiplicity and order.
> My posted patch is one way of many possible alternatives to move in that
> direction
>
>
Well, you forgot that when you check for order of tags, you basically still
allow
crash to happen, just this time crashing code path needs to follow correct
parsing order.


> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> There will always be a question for which you do not know the correct
> answer.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Nicolas George
Gyan Doshi (12020-12-23):
> Avoids breaking output file dump report.
> ---
>  fftools/ffmpeg.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

This looks broken. Why 100ms? Because on your setup, 80ms is not enough
but 100ms is? On a slower system, it would need to be 120 or 200.

Test if the info to be printed is already valid.

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

[FFmpeg-devel] [PATCH 2/2] avformat/hlsproto: update comment of file description

2020-12-23 Thread liuqi05
reference link to rfc8216

Signed-off-by: liuqi05 
---
 libavformat/hlsproto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsproto.c b/libavformat/hlsproto.c
index de45f771d6..9aa211f648 100644
--- a/libavformat/hlsproto.c
+++ b/libavformat/hlsproto.c
@@ -22,7 +22,7 @@
 /**
  * @file
  * Apple HTTP Live Streaming Protocol Handler
- * http://tools.ietf.org/html/draft-pantos-http-live-streaming
+ * https://tools.ietf.org/html/rfc8216
  */
 
 #include "libavutil/avstring.h"
-- 
2.25.0



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

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

[FFmpeg-devel] [PATCH 1/2] avformat/hls: update comment of file description

2020-12-23 Thread liuqi05
reference link to rfc8216

Signed-off-by: liuqi05 
---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 0a522a4595..a987996810 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -23,7 +23,7 @@
 /**
  * @file
  * Apple HTTP Live Streaming demuxer
- * http://tools.ietf.org/html/draft-pantos-http-live-streaming
+ * https://tools.ietf.org/html/rfc8216
  */
 
 #include "libavformat/http.h"
-- 
2.25.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] ffmpeg: add 100ms delay for first stats

2020-12-23 Thread Gyan Doshi



On 23-12-2020 10:28 am, Gyan Doshi wrote:

Avoids breaking output file dump report.
---
  fftools/ffmpeg.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2c0820aacf..449da484d9 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1699,7 +1699,8 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
  if (last_time == -1) {
  last_time = cur_time;
  }
-if ((cur_time - last_time) < stats_period && !first_report)
+if (((cur_time - last_time) < stats_period && !first_report) ||
+((cur_time - last_time) < 10 && first_report))
  return;
  last_time = cur_time;
  }


Looks fixed here. Can anyone else do a quick check?

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

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