Re: [FFmpeg-devel] [PATCH] Don't send teardown if rtsp_hd_out is null

[Ross Nicholson]

Wrong commit message/subject. Please ignore. Will send new patch shortly.

On Sun, 4 Aug 2019 at 22:41, Ross Nicholson  wrote:

> Example stream that does not work: rtsp://
> 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>
> Extending the condition allows the stream to be processed correctly.
>
> On Sun, 4 Aug 2019 at 22:39, Ross Nicholson  wrote:
>
>> From: phunkyfish 
>>
>> ---
>>  libavformat/rtspdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
>> index 32dff2319c..3a79d1b175 100644
>> --- a/libavformat/rtspdec.c
>> +++ b/libavformat/rtspdec.c
>> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>>  {
>>  RTSPState *rt = s->priv_data;
>>
>> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
>> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>>  ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>>
>>  ff_rtsp_close_streams(s);
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
___
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/rtspdec: Don't send teardown if rtsp_hd_out is null

[Ross Nicholson]

From: phunkyfish 

---
 libavformat/rtspdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 32dff2319c..3a79d1b175 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
 {
 RTSPState *rt = s->priv_data;
 
-if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
 ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
 
 ff_rtsp_close_streams(s);
-- 
2.20.1 (Apple Git-117)

___
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/rtspdec: Don't send teardown if rtsp_hd_out is null

[Ross Nicholson]

Example stream that does not work: rtsp://
184.72.239.149/vod/mp4:BigBuckBunny_115k.mov

Extending the condition allows the stream to be processed correctly.

On Mon, 5 Aug 2019 at 08:17, Ross Nicholson  wrote:

> From: phunkyfish 
>
> ---
>  libavformat/rtspdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index 32dff2319c..3a79d1b175 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
>  {
>  RTSPState *rt = s->priv_data;
>
> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
>  ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>
>  ff_rtsp_close_streams(s);
> --
> 2.20.1 (Apple Git-117)
>
>
___
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] [PATCHv2 1/4] avformat/mpegtsenc: fix incorrect PCR selection with multiple programs

[Andreas Håkon]

Hi Marton,


‐‐‐ Original Message ‐‐‐
On Sunday, 4 de August de 2019 22:25, Marton Balint  wrote:

> On Sun, 4 Aug 2019, Andreas Håkon wrote:
>
> > Hi Marton,
> > ‐‐‐ Original Message ‐‐‐
> >
> > > v2: a video is stream is preferred if there are no programs, just like 
> > > before
> > > the patch.
> >
> > Thank you for your effort!
> > However, something is wrong with this patch regarding PCR intervals.
> > First, try this example (using the file shared by Michael
> > https://trac.ffmpeg.org/raw-attachment/ticket/3714/FFmpeg Sample_cut.ts ):
> > % ffmpeg -loglevel info -y -i Sample_cut.ts \
> > -map '0:v:0' -c:v:0 copy \
> > -map '0:v:0' -c:v:1 copy \
> > -map '0:a:0' -c:a:0 copy \
> > -pat_period 1 \
> > -program st=0,1,2 \
> > -program st=0,2 \
> > -program st=1,2 \
> > -program st=3 \
> > -sdt_period 1 \
> > this_was_less_than_256-marton.ts
>
> This command line does not seem correct, there is no stream 3, also in
> order to specify multiple streams per program you have to use this syntax:
> -program st=0:st=2.

Sorry, a lot of typos... corrected example:

[...]
 -program st=0:st=1:st=2 \
 -program st=0:st=2 \
 -program st=1:st=2 \
 -program st=2 \
[...]

The idea with this example is quite simple: Share identical streams over
multiple services to check the correctness of the process.

> > Then you get:
> > [mpegts @ 0x3046880] service 1 using PCR in pid=256
> > [mpegts @ 0x3046880] service 2 using PCR in pid=256
> > [mpegts @ 0x3046880] service 3 using PCR in pid=257
> > [mpegts @ 0x3046880] service 4 using PCR in pid=258
> > Until here all seems correct.

But this is right anyway!

> > However, if you analyze the PCR intervals:
> >
> > -   256: PCR_count: 0x3 (3) => repetition rate: 0,299 seconds
> > -   257: PCR_count: 0x3 (3) => repetition rate: 0,305 seconds
> > -   258: PCR_count: 0x4 (4) => repetition rate: 0,139 seconds
> >
> > (You can check it with the DVB Inspector tool or any other)
> > And regular repetition rate are 0,450 seconds (with ffmpeg).
>
> 450m PCR seems wrong. ISO/IEC13818-1 specifies
> an interval of 100 ms, while DVB recommends 40 ms PCR-s.

Sorry, sorry! Another typo: 0,045 seconds is the regular value
from ffmpeg (without patches).

> What was the PCR interval before the patch? 450 ms seems like the
> keyframe interval of your video, because for keyframes you always get
> a PCR with the current code.

0,045 seconds

> Keep in mind that according to this
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192040.html
> PCR in VBR streams never worked correctly.

OK.

> CBR with multiple programs was also problematic, because instead of
> counting all packets the counter only counted the packets of a service.

And this is wrong. For MPTS-CBR the PCR interval needs to be calculated
individually for each PCR pid and count all packets.
So, I agree with you.

> The way I see it PCR generation needs a serious rework, I will post a
> patch for that, you will have to apply it on top of this series.

OK. I'll try https://patchwork.ffmpeg.org/patch/14233/


> > Why you remove the "pcr_packet_period" from services?
> > I know that the value can be the same for all services inside the
> > same TS, but the PCR interval is per service, and not per TS.
>
> It is per PID now instead of per service.

OK.

[...]

> > In this way, with multiple services (the reason for this patch) you're 
> > generating a
> > Transport Stream with PCR streams sharing the interval period. That's a new 
> > serious BUG!
>
> No, ts_st is different for each stream (each PID).
>
> > For each service it's one PCR. And the interval of each PCR for one stream 
> > is
> > computed from the last PCR of the same stream. It can't be calculated from 
> > the last
> > PCR of any other stream.
>
> ts_st is different for each stream, it is not common.

That's right. That's right. I assumed that the wrong intervals are for this. 
Excuse me!


Regards.
A.H.

---

___
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 v16 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Jing Sun]

Signed-off-by: Zhengxu Huang 
Signed-off-by: Hassene Tmar 
Signed-off-by: Jun Zhao 
Signed-off-by: Jing Sun 
---
 configure|   4 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/libsvt_hevc.c | 500 +++
 libavcodec/version.h |   2 +-
 5 files changed, 507 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index 5a4f507..3a6cab7 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1788,6 +1789,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3183,6 +3185,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6230,6 +6233,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc EbApi.h 
EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fb..d39f568 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -991,6 +991,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39..d8788a7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -707,6 +707,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..59a155f
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,500 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2019 Intel Corporation
+*
+* 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 this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+
+typedef enum eos_status {
+EOS_NOT_REACHED = 0,
+EOS_SENT,
+EOS_RECEIVED
+}EOS_STATUS;
+
+typedef struct SvtContext {
+AVClass *class;
+
+EB_H265_ENC_CONFIGURATION enc_params;
+EB_COMPONENTTYPE *svt_handle;
+EB_BUFFERHEADERTYPE in_buf;
+EOS_STATUS eos_flag;
+

Re: [FFmpeg-devel] [PATCH v16 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Sun, Jing A]

This update corrected the rc_mode assignment position. It should get assigned 
before the if().

264a265,269
> +if (param->rateControlMode) {
> +param->maxQpAllowed = avctx->qmax;
> +param->minQpAllowed = avctx->qmin;
> +}
> +
277,281d281
< +if (param->rateControlMode) {
< +param->maxQpAllowed = avctx->qmax;
< +param->minQpAllowed = avctx->qmin;
< +}
< + 
___
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] avcodec: add msrle encoder

[Paul B Mahol]

Hi,

Patch attached.


0001-avcodec-add-msrle-encoder.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [REQUEST] ffmpeg-security subscription

[Paul B Mahol]

Hi,

I here hereby request from lead FFmpeg entity to give me subscription to
ffmpeg-security mailing list.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/hnm4video: Optimize postprocess_current_frame()

[Tomas Härdin]

lör 2019-08-03 klockan 18:57 +0200 skrev Michael Niedermayer:
> On Sat, Aug 03, 2019 at 04:07:22PM +0200, Tomas Härdin wrote:
> > lör 2019-08-03 klockan 01:49 +0200 skrev Michael Niedermayer:
> > > -uint32_t x, y, src_x, src_y;
> > > +uint32_t x, y, src_y;
> > > +int width = hnm->width;
> > >  
> > >  for (y = 0; y < hnm->height; y++) {
> > > +uint8_t *dst = hnm->processed + y * width;
> > > +const uint8_t *src = hnm->current;
> > >  src_y = y - (y % 2);
> > > -src_x = src_y * hnm->width + (y % 2);
> > > -for (x = 0; x < hnm->width; x++) {
> > > -hnm->processed[(y * hnm->width) + x] = hnm-
> > > > current[src_x];
> > > -src_x += 2;
> > > +src += src_y * width + (y % 2);
> > > +for (x = 0; x < width; x++) {
> > > +dst[x] = *src;
> > > +src += 2;
> > 
> > Looks OK. Maybe telling the compiler that src and dst don't alias
> > would
> > be worthwhile?
> 
> i can add restrict keywords if you want:
> ?
> 
> diff --git a/libavcodec/hnm4video.c b/libavcodec/hnm4video.c
> index 68d0baef6d..1c2501afab 100644
> --- a/libavcodec/hnm4video.c
> +++ b/libavcodec/hnm4video.c
> @@ -121,8 +121,8 @@ static void
> postprocess_current_frame(AVCodecContext *avctx)
>  int width = hnm->width;
>  
>  for (y = 0; y < hnm->height; y++) {
> -uint8_t *dst = hnm->processed + y * width;
> -const uint8_t *src = hnm->current;
> +uint8_t * restrict dst = hnm->processed + y * width;
> +const uint8_t * restrict src = hnm->current;

Does it improve performance? Else there's little point

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH] compat/cuda: Change inclusion guards

[Timo Rothenpieler]

On 05/08/2019 03:09, Andreas Rheinhardt wrote:

cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion
guards with an AV_ prefix, although these files are not in an libav*/
path. So change the inclusion guards and adapt the ref file of the
source fate test accordingly.

Signed-off-by: Andreas Rheinhardt 


applied.

Thanks!



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

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

Re: [FFmpeg-devel] [PATCH] avcodec: add msrle encoder

[Tomas Härdin]

mån 2019-08-05 klockan 10:39 +0200 skrev Paul B Mahol:
> Hi,
> 
> Patch attached.

> +static av_cold int msrle_encode_init(AVCodecContext *avctx)
> +{
> +MsrleEncContext *s = avctx->priv_data;
> +
> +if (av_image_check_size(avctx->width, avctx->height, 0, avctx) < 0)
> +return AVERROR(EINVAL);

Maybe this check should be further up in lavc? It's done for quite a
few codecs. Doesn't need to hold this patch up tho

> +if (avctx->gop_size == 0 || (avctx->frame_number % avctx->gop_size) == 
> 0) {
> +/* I-Frame */
> +s->key_frame = 1;
> +} else {
> +/* P-Frame */
> +s->key_frame = 0;
> +}

Explicitly comparing I vs P would yield a better encoder

Patch looks OK enough, but that's mostly based on the quick glance I
gave the msrle spec on Mike's site

/Tomas


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

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

[FFmpeg-devel] [PATCH V2 1/2] lavf/showinfo: support mastering display sidedata

[Jun Zhao]

From: Jun Zhao 

support mastering display sidedata.

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

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index f6f8f49..d5c444e 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -34,6 +34,7 @@
 #include "libavutil/stereo3d.h"
 #include "libavutil/timestamp.h"
 #include "libavutil/timecode.h"
+#include "libavutil/mastering_display_metadata.h"
 
 #include "avfilter.h"
 #include "internal.h"
@@ -133,6 +134,32 @@ static void dump_roi(AVFilterContext *ctx, AVFrameSideData 
*sd)
 }
 }
 
+static void dump_mastering_display(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+AVMasteringDisplayMetadata *mastering_display;
+
+av_log(ctx, AV_LOG_INFO, "mastering display: ");
+if (sd->size < sizeof(*mastering_display)) {
+av_log(ctx, AV_LOG_ERROR, "invalid data");
+return;
+}
+
+mastering_display = (AVMasteringDisplayMetadata *)sd->data;
+
+av_log(ctx, AV_LOG_INFO, "has_primaries:%d has_luminance:%d "
+   "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
+   "min_luminance=%f, max_luminance=%f",
+   mastering_display->has_primaries, mastering_display->has_luminance,
+   av_q2d(mastering_display->display_primaries[0][0]),
+   av_q2d(mastering_display->display_primaries[0][1]),
+   av_q2d(mastering_display->display_primaries[1][0]),
+   av_q2d(mastering_display->display_primaries[1][1]),
+   av_q2d(mastering_display->display_primaries[2][0]),
+   av_q2d(mastering_display->display_primaries[2][1]),
+   av_q2d(mastering_display->white_point[0]), 
av_q2d(mastering_display->white_point[1]),
+   av_q2d(mastering_display->min_luminance), 
av_q2d(mastering_display->max_luminance));
+}
+
 static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
 {
 const char *color_range_str = av_color_range_name(frame->color_range);
@@ -271,6 +298,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 case AV_FRAME_DATA_REGIONS_OF_INTEREST:
 dump_roi(ctx, sd);
 break;
+case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
+dump_mastering_display(ctx, sd);
+break;
 default:
 av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
sd->type, sd->size);
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V2 2/2] lavf/showinfo: use error level when get invalid sidedata

[Jun Zhao]

From: Jun Zhao 

Use error level when get invalid sidedata, and remove a unnecessary
newline in error message.

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

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index d5c444e..9fa322e 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -62,7 +62,7 @@ static void dump_spherical(AVFilterContext *ctx, AVFrame 
*frame, AVFrameSideData
 
 av_log(ctx, AV_LOG_INFO, "spherical information: ");
 if (sd->size < sizeof(*spherical)) {
-av_log(ctx, AV_LOG_INFO, "invalid data");
+av_log(ctx, AV_LOG_ERROR, "invalid data");
 return;
 }
 
@@ -100,7 +100,7 @@ static void dump_stereo3d(AVFilterContext *ctx, 
AVFrameSideData *sd)
 
 av_log(ctx, AV_LOG_INFO, "stereoscopic information: ");
 if (sd->size < sizeof(*stereo)) {
-av_log(ctx, AV_LOG_INFO, "invalid data");
+av_log(ctx, AV_LOG_ERROR, "invalid data");
 return;
 }
 
@@ -121,7 +121,7 @@ static void dump_roi(AVFilterContext *ctx, AVFrameSideData 
*sd)
 roi = (const AVRegionOfInterest *)sd->data;
 roi_size = roi->self_size;
 if (!roi_size || sd->size % roi_size != 0) {
-av_log(ctx, AV_LOG_ERROR, "Invalid AVRegionOfInterest.self_size.\n");
+av_log(ctx, AV_LOG_ERROR, "Invalid AVRegionOfInterest.self_size.");
 return;
 }
 nb_rois = sd->size / roi_size;
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V2 0/2] Add Mastering Display support in showinfo

[Jun Zhao]

V2: - change the level from info to error when get invalid side data

Jun Zhao (2):
  lavf/showinfo: support mastering display sidedata
  lavf/showinfo: use error level when get invalid sidedata

 libavfilter/vf_showinfo.c |   36 +---
 1 files changed, 33 insertions(+), 3 deletions(-)

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

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

[FFmpeg-devel] [PATCH V1] examples/encode_video: only add sequence end code for mpeg1/2 video

[Jun Zhao]

From: Jun Zhao 

Only add sequence end code for mpeg1/mpeg2 video, or else use the encoder
libx264 or libx265 in this sample, decoding the output file will get
unknow NALU type error.

Signed-off-by: Jun Zhao 
---
 doc/examples/encode_video.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/doc/examples/encode_video.c b/doc/examples/encode_video.c
index 6731b2a..d9ab409 100644
--- a/doc/examples/encode_video.c
+++ b/doc/examples/encode_video.c
@@ -186,7 +186,8 @@ int main(int argc, char **argv)
 encode(c, NULL, pkt, f);
 
 /* add sequence end code to have a real MPEG file */
-fwrite(endcode, 1, sizeof(endcode), f);
+if (codec->id == AV_CODEC_ID_MPEG1VIDEO || codec->id == 
AV_CODEC_ID_MPEG2VIDEO)
+fwrite(endcode, 1, sizeof(endcode), f);
 fclose(f);
 
 avcodec_free_context(&c);
-- 
1.7.1

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

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale: Ensure scaled video is divisible by n

[Lars Kiesow]

Hi everyone,
this is now open for nearly a month with no more comments or change
requests. Anything else I should do to get this merged?
Best regards,
Lars


On Mon,  8 Jul 2019 17:43:40 +0200
Lars Kiesow  wrote:

> This patch adds a new option to the scale filter which ensures that
> the output resolution is divisible by the given integer when used
> together with `force_original_aspect_ratio`. This works similar to
> using `-n` in the `w` and `h` options.
> 
> This option respects the value set for `force_original_aspect_ratio`,
> increasing or decreasing the resolution accordingly.
> 
> The use case for this is to set a fixed target resolution using `w`
> and `h`, to use the `force_original_aspect_ratio` option to make sure
> that the video always fits in the defined bounding box regardless of
> aspect ratio, but to also make sure that the calculated output
> resolution is divisible by n so in can be encoded with certain
> encoders/options if that is required.
> 
> Signed-off-by: Lars Kiesow 
> ---
>  doc/filters.texi   | 12 
>  libavfilter/vf_scale.c | 13 -
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index ee6a93ffbf..2de71d9820 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -15231,6 +15231,18 @@ Please note that this is a different thing
> than specifying -1 for @option{w} or @option{h}, you still need to
> specify the output resolution for this option to work.
>  
> +@item force_divisible_by Ensures that the output resolution is
> divisible by the +given integer when used together with
> @option{force_original_aspect_ratio}. This +works similar to using -n
> in the @option{w} and @option{h} options. +
> +This option respects the value set for
> @option{force_original_aspect_ratio}, +increasing or decreasing the
> resolution accordingly. This may slightly modify +the video's aspect
> ration. +
> +This can be handy, for example, if you want to have a video fit
> within a defined +resolution using the
> @option{force_original_aspect_ratio} option but have +encoder
> restrictions when it comes to width or height. +
>  @end table
>  
>  The values of the @option{w} and @option{h} options are expressions
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 7aebf56ad8..3ce6cdd1d5 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -86,6 +86,7 @@ typedef struct ScaleContext {
>  int in_v_chr_pos;
>  
>  int force_original_aspect_ratio;
> +int force_divisible_by;
>  
>  int nb_slices;
>  
> @@ -237,7 +238,8 @@ static int config_props(AVFilterLink *outlink)
>  goto fail;
>  
>  /* Note that force_original_aspect_ratio may overwrite the
> previous set
> - * dimensions so that it is not divisible by the set factors
> anymore. */
> + * dimensions so that it is not divisible by the set factors
> anymore
> + * unless force_divisible_by is defined as well */
>  if (scale->force_original_aspect_ratio) {
>  int tmp_w = av_rescale(h, inlink->w, inlink->h);
>  int tmp_h = av_rescale(w, inlink->h, inlink->w);
> @@ -245,9 +247,17 @@ static int config_props(AVFilterLink *outlink)
>  if (scale->force_original_aspect_ratio == 1) {
>   w = FFMIN(tmp_w, w);
>   h = FFMIN(tmp_h, h);
> + if (scale->force_divisible_by > 1) {
> + w = w / scale->force_divisible_by *
> scale->force_divisible_by;
> + h = h / scale->force_divisible_by *
> scale->force_divisible_by;
> + }
>  } else {
>   w = FFMAX(tmp_w, w);
>   h = FFMAX(tmp_h, h);
> + if (scale->force_divisible_by > 1) {
> + w = ceil(w / (float)scale->force_divisible_by) *
> scale->force_divisible_by;
> + h = ceil(h / (float)scale->force_divisible_by) *
> scale->force_divisible_by;
> + }
>  }
>  }
>  
> @@ -600,6 +610,7 @@ static const AVOption scale_options[] = {
>  { "disable",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 0 }, 0, 0,
> FLAGS, "force_oar" }, { "decrease", NULL, 0, AV_OPT_TYPE_CONST, {.i64
> = 1 }, 0, 0, FLAGS, "force_oar" }, { "increase", NULL, 0,
> AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, "force_oar" },
> +{ "force_divisible_by", "enforce that the output resolution is
> divisible by a defined integer when force_original_aspect_ratio is
> used", OFFSET(force_divisible_by), AV_OPT_TYPE_INT, { .i64 = 1}, 1,
> 256, FLAGS }, { "param0", "Scaler param 0",
> OFFSET(param[0]),  AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  },
> INT_MIN, INT_MAX, FLAGS }, { "param1", "Scaler param 1",
> OFFSET(param[1]),  AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  },
> INT_MIN, INT_MAX, FLAGS }, { "nb_slices", "set the number of slices
> (debug purpose only)", OFFSET(nb_slices), AV_OPT_TYPE_INT, { .i64 =
> 0 }, 0, INT_MAX, FLAGS },

___
ffmpeg-devel 

Re: [FFmpeg-devel] [PATCH] avcodec: add msrle encoder

[Lynne]

Aug 5, 2019, 9:39 AM by one...@gmail.com:

> Hi,
>
> Patch attached.
>

> int run = FFMIN(255, copy);

Just replace all FFMIN(255 with av_clip_uint8, should be faster, in theory, on 
some platforms.


> +switch (s->pixel_size) {> +case 3:> +
> bytestream2_put_le24(&s->pb, AV_RL24(src));> +break;> +
> case 1:> +bytestream2_put_byte(&s->pb, src[0]);> +
> break;> +}

Just replace all those switches with something line:
if (s->pixel_size == 3)
    bytestream2_put_le24(&s->pb, AV_RL24(src));
else
    bytestream2_put_byte(&s->pb, src[0]);

4 vs 8 lines.


Also, how do you signal that compression was worse than encoding the frame 
directly? In the code you just jump to memcpying the frame to the packet. Does 
the decoder just assume if the packet size is the max packet size its 
uncompressed?
If so you should check that the compressed stream isn't that same size by some 
chance, unless its impossible (e.g. compressed stream is always an odd amount 
of bytes or something).

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

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

Re: [FFmpeg-devel] [PATCH] avcodec: add msrle encoder

[Paul B Mahol]

On Mon, Aug 5, 2019 at 2:05 PM Lynne  wrote:

> Aug 5, 2019, 9:39 AM by one...@gmail.com:
>
> > Hi,
> >
> > Patch attached.
> >
>
> > int run = FFMIN(255, copy);
>
> Just replace all FFMIN(255 with av_clip_uint8, should be faster, in
> theory, on some platforms.
>
>
> > +switch (s->pixel_size) {> +case 3:> +
> bytestream2_put_le24(&s->pb, AV_RL24(src));> +break;> +
> case 1:> +bytestream2_put_byte(&s->pb, src[0]);> +
> break;> +}
>
> Just replace all those switches with something line:
> if (s->pixel_size == 3)
> bytestream2_put_le24(&s->pb, AV_RL24(src));
> else
> bytestream2_put_byte(&s->pb, src[0]);
>
> 4 vs 8 lines.
>
>
> Also, how do you signal that compression was worse than encoding the frame
> directly? In the code you just jump to memcpying the frame to the packet.
> Does the decoder just assume if the packet size is the max packet size its
> uncompressed?
> If so you should check that the compressed stream isn't that same size by
> some chance, unless its impossible (e.g. compressed stream is always an odd
> amount of bytes or something).
>

It is that way handled in decoder. Also output of encoder works under WMP
if you use custom tag: 0x0001


>
> Rest looks fine.
> ___
> 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] libavfilter/vf_scale: Ensure scaled video is divisible by n

[Paul B Mahol]

On Mon, Aug 5, 2019 at 1:31 PM Lars Kiesow  wrote:

> Hi everyone,
> this is now open for nearly a month with no more comments or change
> requests. Anything else I should do to get this merged?
> Best regards,
>

Yes, ping it more frequently, until its merged.
Waiting for months will not help as people are busy.


> Lars
>
>
> On Mon,  8 Jul 2019 17:43:40 +0200
> Lars Kiesow  wrote:
>
> > This patch adds a new option to the scale filter which ensures that
> > the output resolution is divisible by the given integer when used
> > together with `force_original_aspect_ratio`. This works similar to
> > using `-n` in the `w` and `h` options.
> >
> > This option respects the value set for `force_original_aspect_ratio`,
> > increasing or decreasing the resolution accordingly.
> >
> > The use case for this is to set a fixed target resolution using `w`
> > and `h`, to use the `force_original_aspect_ratio` option to make sure
> > that the video always fits in the defined bounding box regardless of
> > aspect ratio, but to also make sure that the calculated output
> > resolution is divisible by n so in can be encoded with certain
> > encoders/options if that is required.
> >
> > Signed-off-by: Lars Kiesow 
> > ---
> >  doc/filters.texi   | 12 
> >  libavfilter/vf_scale.c | 13 -
> >  2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index ee6a93ffbf..2de71d9820 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -15231,6 +15231,18 @@ Please note that this is a different thing
> > than specifying -1 for @option{w} or @option{h}, you still need to
> > specify the output resolution for this option to work.
> >
> > +@item force_divisible_by Ensures that the output resolution is
> > divisible by the +given integer when used together with
> > @option{force_original_aspect_ratio}. This +works similar to using -n
> > in the @option{w} and @option{h} options. +
> > +This option respects the value set for
> > @option{force_original_aspect_ratio}, +increasing or decreasing the
> > resolution accordingly. This may slightly modify +the video's aspect
> > ration. +
> > +This can be handy, for example, if you want to have a video fit
> > within a defined +resolution using the
> > @option{force_original_aspect_ratio} option but have +encoder
> > restrictions when it comes to width or height. +
> >  @end table
> >
> >  The values of the @option{w} and @option{h} options are expressions
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index 7aebf56ad8..3ce6cdd1d5 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -86,6 +86,7 @@ typedef struct ScaleContext {
> >  int in_v_chr_pos;
> >
> >  int force_original_aspect_ratio;
> > +int force_divisible_by;
> >
> >  int nb_slices;
> >
> > @@ -237,7 +238,8 @@ static int config_props(AVFilterLink *outlink)
> >  goto fail;
> >
> >  /* Note that force_original_aspect_ratio may overwrite the
> > previous set
> > - * dimensions so that it is not divisible by the set factors
> > anymore. */
> > + * dimensions so that it is not divisible by the set factors
> > anymore
> > + * unless force_divisible_by is defined as well */
> >  if (scale->force_original_aspect_ratio) {
> >  int tmp_w = av_rescale(h, inlink->w, inlink->h);
> >  int tmp_h = av_rescale(w, inlink->h, inlink->w);
> > @@ -245,9 +247,17 @@ static int config_props(AVFilterLink *outlink)
> >  if (scale->force_original_aspect_ratio == 1) {
> >   w = FFMIN(tmp_w, w);
> >   h = FFMIN(tmp_h, h);
> > + if (scale->force_divisible_by > 1) {
> > + w = w / scale->force_divisible_by *
> > scale->force_divisible_by;
> > + h = h / scale->force_divisible_by *
> > scale->force_divisible_by;
> > + }
> >  } else {
> >   w = FFMAX(tmp_w, w);
> >   h = FFMAX(tmp_h, h);
> > + if (scale->force_divisible_by > 1) {
> > + w = ceil(w / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;
> > + h = ceil(h / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;
> > + }
> >  }
> >  }
> >
> > @@ -600,6 +610,7 @@ static const AVOption scale_options[] = {
> >  { "disable",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 0 }, 0, 0,
> > FLAGS, "force_oar" }, { "decrease", NULL, 0, AV_OPT_TYPE_CONST, {.i64
> > = 1 }, 0, 0, FLAGS, "force_oar" }, { "increase", NULL, 0,
> > AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, "force_oar" },
> > +{ "force_divisible_by", "enforce that the output resolution is
> > divisible by a defined integer when force_original_aspect_ratio is
> > used", OFFSET(force_divisible_by), AV_OPT_TYPE_INT, { .i64 = 1}, 1,
> > 256, FLAGS }, { "param0", "Scaler param 0",
> > OFFSET(param[0]),  AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  },
> 

[FFmpeg-devel] [RFC] How to become release maintainer

[Paul B Mahol]

Hi,

Is there some official way how to become release maintainer?
Expecially creating new releases once in a while.
I'm not happy with current release management in FFmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] How to become release maintainer

[Gyan]

On 05-08-2019 06:05 PM, Paul B Mahol wrote:

Hi,

Is there some official way how to become release maintainer?
Expecially creating new releases once in a while.
I'm not happy with current release management in FFmpeg.


Yes, release intervals look to be erratic. What would help is a 
suggested schedule, something like


master nb_commits % 1500 == 0.

This is self-pacing - rapid/slow development -> rapid/slow release. 
Since the marker indication is known in advance, developers can guess by 
when their patches should be pushed to make it in a release. The exact 
cut point can be relaxed a bit to allow for important backports.


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] [RFC] How to become release maintainer

[James Almer]

On 8/5/2019 10:13 AM, Gyan wrote:
> 
> 
> On 05-08-2019 06:05 PM, Paul B Mahol wrote:
>> Hi,
>>
>> Is there some official way how to become release maintainer?
>> Expecially creating new releases once in a while.
>> I'm not happy with current release management in FFmpeg.
> 
> Yes, release intervals look to be erratic. What would help is a
> suggested schedule, something like
> 
> master nb_commits % 1500 == 0.

Commit amount means nothing. You could get a whole new decoder in one,
or a fix for a single issue split across seven.

And if you make the cut as strict as you suggest, you'll surely get
broken releases.

> 
> This is self-pacing - rapid/slow development -> rapid/slow release.
> Since the marker indication is known in advance, developers can guess by
> when their patches should be pushed to make it in a release. The exact
> cut point can be relaxed a bit to allow for important backports.
> 
> 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".

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

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

Re: [FFmpeg-devel] [RFC] How to become release maintainer

[Reto Kromer]

James Almer wrote:

>>> master nb_commits % 1500 == 0.

>And if you make the cut as strict as you suggest, you'll surely
>get broken releases.

I fully agree that such an orthodoxy would result in broken
releases.

Seen this from a user of releases perspective, a good compromise
between availability of new features and deployment of a new
version would be a few months, such as one release per season.
Hope this input is useful for the discussion.

Best regards, Reto

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

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

[FFmpeg-devel] [PATCH 1/7] x86inc: Fix VEX -> EVEX instruction conversion

[James Darnley]

From: Henrik Gramner 

There's an edge case that wasn't properly handled.
---
 libavutil/x86/x86inc.asm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 5044ee86f0..bc370a6186 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1662,6 +1662,11 @@ FMA4_INSTR fnmsub,   pd, ps, sd, ss
 %assign %%evex_required 1
 %endif
 %endif
+%ifnum regnumof%3
+%if regnumof%3 >= 16 || sizeof%3 > 32
+%assign %%evex_required 1
+%endif
+%endif
 %if %%evex_required
 %6 %%args
 %else
-- 
2.22.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 4/7] x86inc: Turn 'movsxd' into 'movifnidn' on x86-32

[James Darnley]

From: Henrik Gramner 

---
 libavutil/x86/x86inc.asm | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 10b7711637..04dbb6b785 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -293,6 +293,10 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
 %endif
 %endmacro
 
+%if ARCH_X86_64 == 0
+%define movsxd movifnidn
+%endif
+
 %macro movsxdifnidn 2
 %ifnidn %1, %2
 movsxd %1, %2
-- 
2.22.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 5/7] x86inc: Make 'non-adjacent' default in the TAIL_CALL macro

[James Darnley]

From: Henrik Gramner 

---
 libavutil/x86/x86inc.asm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 04dbb6b785..af35fe1e4d 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -685,7 +685,7 @@ DECLARE_ARG 7, 8, 9, 10, 11, 12, 13, 14
 
 BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg, jge, jng, jnge, ja, 
jae, jna, jnae, jb, jbe, jnb, jnbe, jc, jnc, js, jns, jo, jno, jp, jnp
 
-%macro TAIL_CALL 2 ; callee, is_nonadjacent
+%macro TAIL_CALL 1-2 1 ; callee, is_nonadjacent
 %if has_epilogue
 call %1
 RET
-- 
2.22.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] libavcodec/iff: Use unsigned to avoid undefined behaviour

[Paul B Mahol]

LGTM
___
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 6/7] x86inc: Improve warnings for use of unsupported instructions

[James Darnley]

From: Henrik Gramner 

Warn when the following are used without the appropriate cpuflag:
 * YMM and ZMM registers
 * 'pextrw' with a memory operand
 * GPR instruction set extensions
---
 libavutil/x86/x86inc.asm | 120 +++
 1 file changed, 83 insertions(+), 37 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index af35fe1e4d..d1b4c982fc 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1216,8 +1216,22 @@ INIT_XMM
 %ifdef cpuname
 %if notcpuflag(%2)
 %error use of ``%1'' %2 instruction in cpuname function: 
current_function
-%elif cpuflags_%2 < cpuflags_sse && notcpuflag(sse2) && 
__sizeofreg > 8
+%elif %3 == 0 && __sizeofreg == 16 && notcpuflag(sse2)
 %error use of ``%1'' sse2 instruction in cpuname function: 
current_function
+%elif %3 == 0 && __sizeofreg == 32 && notcpuflag(avx2)
+%error use of ``%1'' avx2 instruction in cpuname function: 
current_function
+%elif __sizeofreg == 16 && notcpuflag(sse)
+%error use of ``%1'' sse instruction in cpuname function: 
current_function
+%elif __sizeofreg == 32 && notcpuflag(avx)
+%error use of ``%1'' avx instruction in cpuname function: 
current_function
+%elif __sizeofreg == 64 && notcpuflag(avx512)
+%error use of ``%1'' avx512 instruction in cpuname function: 
current_function
+%elifidn %1, pextrw ; special case because the base instruction is 
mmx2,
+%ifnid %6   ; but sse4 is required for memory operands
+%if notcpuflag(sse4)
+%error use of ``%1'' sse4 instruction in cpuname 
function: current_function
+%endif
+%endif
 %endif
 %endif
 %endif
@@ -1379,38 +1393,38 @@ AVX_INSTR cmpunordpd, sse2, 1, 0, 1
 AVX_INSTR cmpunordps, sse, 1, 0, 1
 AVX_INSTR cmpunordsd, sse2, 1, 0, 0
 AVX_INSTR cmpunordss, sse, 1, 0, 0
-AVX_INSTR comisd, sse2
-AVX_INSTR comiss, sse
-AVX_INSTR cvtdq2pd, sse2
-AVX_INSTR cvtdq2ps, sse2
-AVX_INSTR cvtpd2dq, sse2
-AVX_INSTR cvtpd2ps, sse2
-AVX_INSTR cvtps2dq, sse2
-AVX_INSTR cvtps2pd, sse2
-AVX_INSTR cvtsd2si, sse2
+AVX_INSTR comisd, sse2, 1
+AVX_INSTR comiss, sse, 1
+AVX_INSTR cvtdq2pd, sse2, 1
+AVX_INSTR cvtdq2ps, sse2, 1
+AVX_INSTR cvtpd2dq, sse2, 1
+AVX_INSTR cvtpd2ps, sse2, 1
+AVX_INSTR cvtps2dq, sse2, 1
+AVX_INSTR cvtps2pd, sse2, 1
+AVX_INSTR cvtsd2si, sse2, 1
 AVX_INSTR cvtsd2ss, sse2, 1, 0, 0
 AVX_INSTR cvtsi2sd, sse2, 1, 0, 0
 AVX_INSTR cvtsi2ss, sse, 1, 0, 0
 AVX_INSTR cvtss2sd, sse2, 1, 0, 0
-AVX_INSTR cvtss2si, sse
-AVX_INSTR cvttpd2dq, sse2
-AVX_INSTR cvttps2dq, sse2
-AVX_INSTR cvttsd2si, sse2
-AVX_INSTR cvttss2si, sse
+AVX_INSTR cvtss2si, sse, 1
+AVX_INSTR cvttpd2dq, sse2, 1
+AVX_INSTR cvttps2dq, sse2, 1
+AVX_INSTR cvttsd2si, sse2, 1
+AVX_INSTR cvttss2si, sse, 1
 AVX_INSTR divpd, sse2, 1, 0, 0
 AVX_INSTR divps, sse, 1, 0, 0
 AVX_INSTR divsd, sse2, 1, 0, 0
 AVX_INSTR divss, sse, 1, 0, 0
 AVX_INSTR dppd, sse4, 1, 1, 0
 AVX_INSTR dpps, sse4, 1, 1, 0
-AVX_INSTR extractps, sse4
+AVX_INSTR extractps, sse4, 1
 AVX_INSTR haddpd, sse3, 1, 0, 0
 AVX_INSTR haddps, sse3, 1, 0, 0
 AVX_INSTR hsubpd, sse3, 1, 0, 0
 AVX_INSTR hsubps, sse3, 1, 0, 0
 AVX_INSTR insertps, sse4, 1, 1, 0
 AVX_INSTR lddqu, sse3
-AVX_INSTR ldmxcsr, sse
+AVX_INSTR ldmxcsr, sse, 1
 AVX_INSTR maskmovdqu, sse2
 AVX_INSTR maxpd, sse2, 1, 0, 1
 AVX_INSTR maxps, sse, 1, 0, 1
@@ -1420,10 +1434,10 @@ AVX_INSTR minpd, sse2, 1, 0, 1
 AVX_INSTR minps, sse, 1, 0, 1
 AVX_INSTR minsd, sse2, 1, 0, 0
 AVX_INSTR minss, sse, 1, 0, 0
-AVX_INSTR movapd, sse2
-AVX_INSTR movaps, sse
+AVX_INSTR movapd, sse2, 1
+AVX_INSTR movaps, sse, 1
 AVX_INSTR movd, mmx
-AVX_INSTR movddup, sse3
+AVX_INSTR movddup, sse3, 1
 AVX_INSTR movdqa, sse2
 AVX_INSTR movdqu, sse2
 AVX_INSTR movhlps, sse, 1, 0, 0
@@ -1432,19 +1446,19 @@ AVX_INSTR movhps, sse, 1, 0, 0
 AVX_INSTR movlhps, sse, 1, 0, 0
 AVX_INSTR movlpd, sse2, 1, 0, 0
 AVX_INSTR movlps, sse, 1, 0, 0
-AVX_INSTR movmskpd, sse2
-AVX_INSTR movmskps, sse
+AVX_INSTR movmskpd, sse2, 1
+AVX_INSTR movmskps, sse, 1
 AVX_INSTR movntdq, sse2
 AVX_INSTR movntdqa, sse4
-AVX_INSTR movntpd, sse2
-AVX_INSTR movntps, sse
+AVX_INSTR movntpd, sse2, 1
+AVX_INSTR movntps, sse, 1
 AVX_INSTR movq, mmx
 AVX_INSTR movsd, sse2, 1, 0, 0
-AVX_INSTR movshdup, sse3
-AVX_INSTR movsldup, sse3
+AVX_INSTR movshdup, sse3, 1
+AVX_INSTR movsldup, sse3, 1
 AVX_INSTR movss, sse, 1, 0, 0
-AVX_INSTR movupd, sse2
-AVX_INSTR movups, sse
+AVX_INSTR movupd, sse2, 1
+AVX_INSTR movups, sse, 1
 AVX_INSTR mpsadbw, sse4, 0, 1, 0
 AVX_INSTR mulpd, sse2, 1, 0, 1
 AVX_INSTR mulps, sse, 1, 0, 1
@@ -1577,27 +1591,27 @@ AVX_INSTR punpcklwd, mmx, 0, 0, 0
 AVX_INSTR punpckldq, mmx, 0, 0, 0
 AVX_INSTR punpcklqdq, sse2, 0, 0, 0
 AVX_INSTR pxor, mmx, 0, 0, 1
-AVX_INSTR rcpps, sse
+AVX_INSTR rcpps, sse, 1
 AVX_INST

[FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from x264

[James Darnley]

Here are a few easy-to-import patches from x264.  These are all after x264
commit 4a158b00 "x86inc: Correctly set mmreg variables" which FFmpeg already
has (commit eb5f063e7c).

It does not include the following commits:
* 82721eae "x86inc: Add x86-32 PIC support macros"
* 101bd27d "x86inc: Support N_PEXT bit on Mach-O"

They would not apply cleanly because of existing differences between x264 and
FFmpeg.  The PIC one has a change to configure which would need remaking.

Henrik Gramner (7):
  x86inc: Fix VEX -> EVEX instruction conversion
  x86inc: Optimize VEX instruction encoding
  x86inc: Improve SAVE/LOAD_MM_PERMUTATION macros
  x86inc: Turn 'movsxd' into 'movifnidn' on x86-32
  x86inc: Make 'non-adjacent' default in the TAIL_CALL macro
  x86inc: Improve warnings for use of unsupported instructions
  x86inc: Add support for GFNI instructions

 libavutil/x86/x86inc.asm | 219 ---
 1 file changed, 161 insertions(+), 58 deletions(-)

-- 
2.22.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 2/7] x86inc: Optimize VEX instruction encoding

[James Darnley]

From: Henrik Gramner 

Most VEX-encoded instructions require an additional byte to encode when src2
is a high register (e.g. x|ymm8..15). If the instruction is commutative we
can swap src1 and src2 when doing so reduces the instruction length, e.g.

vpaddw xmm0, xmm0, xmm8 -> vpaddw xmm0, xmm8, xmm0
---
 libavutil/x86/x86inc.asm | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index bc370a6186..39cba5db09 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1244,9 +1244,40 @@ INIT_XMM
 %elif %0 >= 9
 __instr %6, %7, %8, %9
 %elif %0 == 8
-__instr %6, %7, %8
+%if avx_enabled && %5
+%xdefine __src1 %7
+%xdefine __src2 %8
+%ifnum regnumof%7
+%ifnum regnumof%8
+%if regnumof%7 < 8 && regnumof%8 >= 8 && regnumof%8 < 16 
&& sizeof%8 <= 32
+; Most VEX-encoded instructions require an additional 
byte to encode when
+; src2 is a high register (e.g. m8..15). If the 
instruction is commutative
+; we can swap src1 and src2 when doing so reduces the 
instruction length.
+%xdefine __src1 %8
+%xdefine __src2 %7
+%endif
+%endif
+%endif
+__instr %6, __src1, __src2
+%else
+__instr %6, %7, %8
+%endif
 %elif %0 == 7
-__instr %6, %7
+%if avx_enabled && %5
+%xdefine __src1 %6
+%xdefine __src2 %7
+%ifnum regnumof%6
+%ifnum regnumof%7
+%if regnumof%6 < 8 && regnumof%7 >= 8 && regnumof%7 < 16 
&& sizeof%7 <= 32
+%xdefine __src1 %7
+%xdefine __src2 %6
+%endif
+%endif
+%endif
+__instr %6, __src1, __src2
+%else
+__instr %6, %7
+%endif
 %else
 __instr %6
 %endif
-- 
2.22.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 7/7] x86inc: Add support for GFNI instructions

[James Darnley]

From: Henrik Gramner 

---
 libavutil/x86/x86inc.asm | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index d1b4c982fc..8c8cc97e0c 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -820,19 +820,20 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg, 
jge, jng, jnge, ja, jae,
 %assign cpuflags_sse4 (1<<10)| cpuflags_ssse3
 %assign cpuflags_sse42(1<<11)| cpuflags_sse4
 %assign cpuflags_aesni(1<<12)| cpuflags_sse42
-%assign cpuflags_avx  (1<<13)| cpuflags_sse42
-%assign cpuflags_xop  (1<<14)| cpuflags_avx
-%assign cpuflags_fma4 (1<<15)| cpuflags_avx
-%assign cpuflags_fma3 (1<<16)| cpuflags_avx
-%assign cpuflags_bmi1 (1<<17)| cpuflags_avx|cpuflags_lzcnt
-%assign cpuflags_bmi2 (1<<18)| cpuflags_bmi1
-%assign cpuflags_avx2 (1<<19)| cpuflags_fma3|cpuflags_bmi2
-%assign cpuflags_avx512   (1<<20)| cpuflags_avx2 ; F, CD, BW, DQ, VL
-
-%assign cpuflags_cache32  (1<<21)
-%assign cpuflags_cache64  (1<<22)
-%assign cpuflags_aligned  (1<<23) ; not a cpu feature, but a function variant
-%assign cpuflags_atom (1<<24)
+%assign cpuflags_gfni (1<<13)| cpuflags_sse42
+%assign cpuflags_avx  (1<<14)| cpuflags_sse42
+%assign cpuflags_xop  (1<<15)| cpuflags_avx
+%assign cpuflags_fma4 (1<<16)| cpuflags_avx
+%assign cpuflags_fma3 (1<<17)| cpuflags_avx
+%assign cpuflags_bmi1 (1<<18)| cpuflags_avx|cpuflags_lzcnt
+%assign cpuflags_bmi2 (1<<19)| cpuflags_bmi1
+%assign cpuflags_avx2 (1<<20)| cpuflags_fma3|cpuflags_bmi2
+%assign cpuflags_avx512   (1<<21)| cpuflags_avx2 ; F, CD, BW, DQ, VL
+
+%assign cpuflags_cache32  (1<<22)
+%assign cpuflags_cache64  (1<<23)
+%assign cpuflags_aligned  (1<<24) ; not a cpu feature, but a function variant
+%assign cpuflags_atom (1<<25)
 
 ; Returns a boolean value expressing whether or not the specified cpuflag is 
enabled.
 %definecpuflag(x) (cpuflags & (cpuflags_ %+ x)) ^ (cpuflags_ %+ x)) - 
1) >> 31) & 1)
@@ -1418,6 +1419,9 @@ AVX_INSTR divss, sse, 1, 0, 0
 AVX_INSTR dppd, sse4, 1, 1, 0
 AVX_INSTR dpps, sse4, 1, 1, 0
 AVX_INSTR extractps, sse4, 1
+AVX_INSTR gf2p8affineinvqb, gfni, 0, 1, 0
+AVX_INSTR gf2p8affineqb, gfni, 0, 1, 0
+AVX_INSTR gf2p8mulb, gfni, 0, 0, 0
 AVX_INSTR haddpd, sse3, 1, 0, 0
 AVX_INSTR haddps, sse3, 1, 0, 0
 AVX_INSTR hsubpd, sse3, 1, 0, 0
-- 
2.22.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 3/7] x86inc: Improve SAVE/LOAD_MM_PERMUTATION macros

[James Darnley]

From: Henrik Gramner 

Use register numbers instead of copying the full register names. This makes it
possible to change register widths in the middle of a function and keep the
mmreg permutations intact which can be useful for code that only needs larger
vectors for parts of the function in combination with macros etc.

Also change the LOAD_MM_PERMUTATION macro to use the same default name as the
SAVE macro. This simplifies swapping from ymm to xmm registers or vice versa:

SAVE_MM_PERMUTATION
INIT_XMM 
LOAD_MM_PERMUTATION
---
 libavutil/x86/x86inc.asm | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 39cba5db09..10b7711637 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1081,19 +1081,32 @@ INIT_XMM
 %endif
 %assign %%i 0
 %rep num_mmregs
-CAT_XDEFINE %%f, %%i, m %+ %%i
+%xdefine %%tmp m %+ %%i
+CAT_XDEFINE %%f, %%i, regnumof %+ %%tmp
 %assign %%i %%i+1
 %endrep
 %endmacro
 
-%macro LOAD_MM_PERMUTATION 1 ; name to load from
-%ifdef %1_m0
+%macro LOAD_MM_PERMUTATION 0-1 ; name to load from
+%if %0
+%xdefine %%f %1_m
+%else
+%xdefine %%f current_function %+ _m
+%endif
+%xdefine %%tmp %%f %+ 0
+%ifnum %%tmp
+RESET_MM_PERMUTATION
 %assign %%i 0
 %rep num_mmregs
-CAT_XDEFINE m, %%i, %1_m %+ %%i
-CAT_XDEFINE nn, m %+ %%i, %%i
+%xdefine %%tmp %%f %+ %%i
+CAT_XDEFINE %%m, %%i, m %+ %%tmp
 %assign %%i %%i+1
 %endrep
+%rep num_mmregs
+%assign %%i %%i-1
+CAT_XDEFINE m, %%i, %%m %+ %%i
+CAT_XDEFINE nn, m %+ %%i, %%i
+%endrep
 %endif
 %endmacro
 
-- 
2.22.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] [RFC] How to become release maintainer

[James Almer]

On 8/5/2019 10:35 AM, Reto Kromer wrote:
> James Almer wrote:
> 
 master nb_commits % 1500 == 0.
> 
>> And if you make the cut as strict as you suggest, you'll surely
>> get broken releases.
> 
> I fully agree that such an orthodoxy would result in broken
> releases.
> 
> Seen this from a user of releases perspective, a good compromise
> between availability of new features and deployment of a new
> version would be a few months, such as one release per season.
> Hope this input is useful for the discussion.
> 
> Best regards, Reto

That is the current schedule. It used to be one every three months, give
or take a month, then changed to six months once that stopped being true.
The issue is that 4.2 is being delayed way too much, fast approaching a
year now, apparently because Michael (Who handles releases) is dealing
with a constant influx of new issues reported by fuzzers, most of which
he considers a security concern.

I agree with him that they should be dealt with, but it should be
limited to those considered severe and must be addressed immediately
(AKA, blocking issues, with proven effects).
We have always made a point release about a week or two after the
original, with all the required backported fixes included. I don't see
why that's apparently no longer being taken into account.

Fuzzer reported issues will not stop or slow down, so unless we get
laxer with the assigned severity to such issues and leave a bunch for
the point releases, 4.2 may not see the light.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] How to become release maintainer

[Gyan]

On 05-08-2019 06:48 PM, James Almer wrote:

On 8/5/2019 10:13 AM, Gyan wrote:


On 05-08-2019 06:05 PM, Paul B Mahol wrote:

Hi,

Is there some official way how to become release maintainer?
Expecially creating new releases once in a while.
I'm not happy with current release management in FFmpeg.

Yes, release intervals look to be erratic. What would help is a
suggested schedule, something like

master nb_commits % 1500 == 0.

Commit amount means nothing. You could get a whole new decoder in one,
or a fix for a single issue split across seven.


Across a small number of commits, yes, this would have an impact. Once 
you go large, the number of consolidated/piecemeal commits has to even out.



And if you make the cut as strict as you suggest, you'll surely get
broken releases.
My suggestion is for a marker, not an exact cut point, which would be 
pragmatically decided by the release maintainer to avoid partial 
patchsets or security fixes.


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] avcodec/dirac_parser: Fix overflow in dts

[Paul B Mahol]

lgtm

On Sat, Aug 3, 2019 at 1:17 PM Michael Niedermayer 
wrote:

> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> type 'int'
> Fixes:
> 15568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5634719611355136
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/dirac_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dirac_parser.c b/libavcodec/dirac_parser.c
> index 1ade44a438..fbc7414c79 100644
> --- a/libavcodec/dirac_parser.c
> +++ b/libavcodec/dirac_parser.c
> @@ -212,7 +212,7 @@ static int dirac_combine_frame(AVCodecParserContext
> *s, AVCodecContext *avctx,
>  if (parse_timing_info && pu1.prev_pu_offset >= 13) {
>  uint8_t *cur_pu = pc->buffer +
>pc->index - 13 - pu1.prev_pu_offset;
> -int pts = AV_RB32(cur_pu + 13);
> +int64_t pts = AV_RB32(cur_pu + 13);
>  if (s->last_pts == 0 && s->last_dts == 0)
>  s->dts = pts - 1;
>  else
> --
> 2.22.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] How to become release maintainer

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 10:47:56AM -0300, James Almer wrote:
> On 8/5/2019 10:35 AM, Reto Kromer wrote:
> > James Almer wrote:
> > 
>  master nb_commits % 1500 == 0.
> > 
> >> And if you make the cut as strict as you suggest, you'll surely
> >> get broken releases.
> > 
> > I fully agree that such an orthodoxy would result in broken
> > releases.
> > 
> > Seen this from a user of releases perspective, a good compromise
> > between availability of new features and deployment of a new
> > version would be a few months, such as one release per season.
> > Hope this input is useful for the discussion.
> > 
> > Best regards, Reto
> 
> That is the current schedule. It used to be one every three months, give
> or take a month, then changed to six months once that stopped being true.
> The issue is that 4.2 is being delayed way too much, fast approaching a
> year now, apparently because Michael (Who handles releases) is dealing
> with a constant influx of new issues reported by fuzzers, most of which
> he considers a security concern.

with releases every 3 months several people complained that there are
too many releases. 

I agree that 4.2 is delayed too much, ill make that release soon, just
wanted to give the latest sec fixes a ~day on the ML for reviews.

It does seem judging from the unhappyness with a 3months shedule and
the now unhappyness with a almost 9? month that 6 month is the sweet spot.
So ill aim towards maybe 5months in the future and with unexpected delays
we will then achieve a 6 months release cycle.

About paul doing the releases, i think the work on codecs and filters
and all the surroundings that he is doing currently is more valuable.

I appologize for the 4.2 release being late

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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/tx: don't compile double precision transforms on CONFIG_SMALL

[Paul B Mahol]

On Fri, Aug 2, 2019 at 6:01 PM Lynne  wrote:

> They'll likely only be used in not so small filters, so for embedded users
> it makes sense to not compile them in.
>

I think, CONFIG_SMALL should be removed.


>
> ___
> 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/6] avcodec/loco: Check for end of input in pixel decode

[Paul B Mahol]

lgtm

On Sat, Aug 3, 2019 at 1:51 AM Michael Niedermayer 
wrote:

> Fixes: Timeout (100sec -> 5sec)
> Fixes:
> 15509/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5724297261219840
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/loco.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/loco.c b/libavcodec/loco.c
> index e8c62b8178..5fb414b411 100644
> --- a/libavcodec/loco.c
> +++ b/libavcodec/loco.c
> @@ -88,6 +88,8 @@ static inline int loco_get_rice(RICEContext *r)
>  loco_update_rice_param(r, 0);
>  return 0;
>  }
> +if (get_bits_left(&r->gb) < 1)
> +return INT_MIN;
>  v = get_ur_golomb_jpegls(&r->gb, loco_get_rice_param(r), INT_MAX, 0);
>  loco_update_rice_param(r, (v + 1) >> 1);
>  if (!v) {
> @@ -163,6 +165,8 @@ static int loco_decode_plane(LOCOContext *l, uint8_t
> *data, int width, int heigh
>  /* restore all other pixels */
>  for (i = 1; i < width; i++) {
>  val = loco_get_rice(&rc);
> +if (val == INT_MIN)
> +return -1;
>  data[i] = loco_predict(&data[i], stride) + val;
>  }
>  data += stride;
> --
> 2.22.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/dirac_parser: Fix overflow in dts

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 04:57:49PM +0200, Paul B Mahol wrote:
> lgtm

will apply

thx

[...]
-- 
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
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/atrac9dec: Check grad_range[1] more tightly

[Michael Niedermayer]

On Sun, Aug 04, 2019 at 02:18:19AM +0200, Lynne wrote:
> Aug 4, 2019, 12:16 AM by mich...@niedermayer.cc:
> 
> > Alternatively the array could be made bigger but the extra values
> > would not be read without other changes.
> >
> > Fixes: Out of array access
> > Fixes: 
> > 15658/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ATRAC9_fuzzer-5738260074070016
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/atrac9dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
> > index 491e889788..e503e36dbf 100644
> > --- a/libavcodec/atrac9dec.c
> > +++ b/libavcodec/atrac9dec.c
> > @@ -121,7 +121,7 @@ static inline int parse_gradient(ATRAC9Context *s, 
> > ATRAC9BlockData *b,
> >  }
> >  b->grad_boundary = get_bits(gb, 4);
> >  
> > -if (grad_range[0] >= grad_range[1] || grad_range[1] > 47)
> > +if (grad_range[0] >= grad_range[1] || grad_range[1] > 31)
> >  return AVERROR_INVALIDDATA; 
> >
> 
> Looked into it, lgtm.

will apply

thx

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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/mss1: check for overread and forward errors

[Paul B Mahol]

looks fine to me
___
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/3] avcodec/atrac9dec: Replace impossible conditions by assert

[Michael Niedermayer]

On Sun, Aug 04, 2019 at 01:41:48AM +0200, Lynne wrote:
> Aug 4, 2019, 12:16 AM by mich...@niedermayer.cc:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/atrac9dec.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
> > index 2e23ea44e8..491e889788 100644
> > --- a/libavcodec/atrac9dec.c
> > +++ b/libavcodec/atrac9dec.c
> > @@ -124,8 +124,7 @@ static inline int parse_gradient(ATRAC9Context *s, 
> > ATRAC9BlockData *b,
> >  if (grad_range[0] >= grad_range[1] || grad_range[1] > 47)
> >  return AVERROR_INVALIDDATA;
> >  
> > -if (grad_value[0] > 31 || grad_value[1] > 31)
> > -return AVERROR_INVALIDDATA;
> > +av_assert0(grad_value[0] <= 31 && grad_value[1] <= 31);
> >
> 
> Its impossible so just remove it.

will do

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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/3] avcodec/bink: Add many end of input checks

[Michael Niedermayer]

On Sun, Aug 04, 2019 at 01:16:06AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (83sec -> 15sec)
> Fixes: 
> 15595/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5689153263501312
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/bink.c | 52 +++
>  1 file changed, 43 insertions(+), 9 deletions(-)

will apply

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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/7] avformat/av1: add color config values to AV1SequenceParameters

[Paul B Mahol]

lgtm

On Tue, Jul 30, 2019 at 10:22 PM James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavformat/av1.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/av1.c b/libavformat/av1.c
> index 5fde8df97e..bd23891d26 100644
> --- a/libavformat/av1.c
> +++ b/libavformat/av1.c
> @@ -86,6 +86,11 @@ typedef struct AV1SequenceParameters {
>  uint8_t chroma_subsampling_x;
>  uint8_t chroma_subsampling_y;
>  uint8_t chroma_sample_position;
> +uint8_t color_description_present_flag;
> +uint8_t color_primaries;
> +uint8_t transfer_characteristics;
> +uint8_t matrix_coefficients;
> +uint8_t color_range;
>  } AV1SequenceParameters;
>
>  static inline void uvlc(GetBitContext *gb)
> @@ -106,8 +111,6 @@ static inline void uvlc(GetBitContext *gb)
>
>  static int parse_color_config(AV1SequenceParameters *seq_params,
> GetBitContext *gb)
>  {
> -int color_primaries, transfer_characteristics, matrix_coefficients;
> -
>  seq_params->high_bitdepth = get_bits1(gb);
>  if (seq_params->seq_profile == FF_PROFILE_AV1_PROFESSIONAL &&
> seq_params->high_bitdepth)
>  seq_params->twelve_bit = get_bits1(gb);
> @@ -117,29 +120,30 @@ static int parse_color_config(AV1SequenceParameters
> *seq_params, GetBitContext *
>  else
>  seq_params->monochrome = get_bits1(gb);
>
> -if (get_bits1(gb)) { // color_description_present_flag
> -color_primaries  = get_bits(gb, 8);
> -transfer_characteristics = get_bits(gb, 8);
> -matrix_coefficients  = get_bits(gb, 8);
> +seq_params->color_description_present_flag = get_bits1(gb);
> +if (seq_params->color_description_present_flag) {
> +seq_params->color_primaries  = get_bits(gb, 8);
> +seq_params->transfer_characteristics = get_bits(gb, 8);
> +seq_params->matrix_coefficients  = get_bits(gb, 8);
>  } else {
> -color_primaries  = AVCOL_PRI_UNSPECIFIED;
> -transfer_characteristics = AVCOL_TRC_UNSPECIFIED;
> -matrix_coefficients  = AVCOL_SPC_UNSPECIFIED;
> +seq_params->color_primaries  = AVCOL_PRI_UNSPECIFIED;
> +seq_params->transfer_characteristics = AVCOL_TRC_UNSPECIFIED;
> +seq_params->matrix_coefficients  = AVCOL_SPC_UNSPECIFIED;
>  }
>
>  if (seq_params->monochrome) {
> -skip_bits1(gb); // color_range
> +seq_params->color_range = get_bits1(gb);
>  seq_params->chroma_subsampling_x = 1;
>  seq_params->chroma_subsampling_y = 1;
>  seq_params->chroma_sample_position = 0;
>  return 0;
> -} else if (color_primaries  == AVCOL_PRI_BT709 &&
> -   transfer_characteristics == AVCOL_TRC_IEC61966_2_1 &&
> -   matrix_coefficients  == AVCOL_SPC_RGB) {
> +} else if (seq_params->color_primaries  == AVCOL_PRI_BT709 &&
> +   seq_params->transfer_characteristics ==
> AVCOL_TRC_IEC61966_2_1 &&
> +   seq_params->matrix_coefficients  == AVCOL_SPC_RGB) {
>  seq_params->chroma_subsampling_x = 0;
>  seq_params->chroma_subsampling_y = 0;
>  } else {
> -skip_bits1(gb); // color_range
> +seq_params->color_range = get_bits1(gb);
>
>  if (seq_params->seq_profile == FF_PROFILE_AV1_MAIN) {
>  seq_params->chroma_subsampling_x = 1;
> --
> 2.22.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 01/13] avcodec/apedec: Do not partially clear data array

[Michael Niedermayer]

On Sun, Aug 04, 2019 at 06:44:04PM +0200, Michael Niedermayer wrote:
> Fixes: Assertion failure and memleak
> Fixes: 
> 15709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5182435093905408
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/apedec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

will apply patchset and backport to release/4.2 soon

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

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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/6] avcodec/loco: Check for end of input in pixel decode

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 05:00:08PM +0200, Paul B Mahol wrote:
> lgtm

will apply

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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/mss1: check for overread and forward errors

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 05:03:53PM +0200, Paul B Mahol wrote:
> looks fine to me

will apply

thx

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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] libavcodec/iff: Use unsigned to avoid undefined behaviour

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 03:43:23PM +0200, Paul B Mahol wrote:
> LGTM

will apply

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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] [RFC] How to become release maintainer

[James Almer]

On 8/5/2019 11:58 AM, Michael Niedermayer wrote:
> On Mon, Aug 05, 2019 at 10:47:56AM -0300, James Almer wrote:
>> On 8/5/2019 10:35 AM, Reto Kromer wrote:
>>> James Almer wrote:
>>>
>> master nb_commits % 1500 == 0.
>>>
 And if you make the cut as strict as you suggest, you'll surely
 get broken releases.
>>>
>>> I fully agree that such an orthodoxy would result in broken
>>> releases.
>>>
>>> Seen this from a user of releases perspective, a good compromise
>>> between availability of new features and deployment of a new
>>> version would be a few months, such as one release per season.
>>> Hope this input is useful for the discussion.
>>>
>>> Best regards, Reto
>>
>> That is the current schedule. It used to be one every three months, give
>> or take a month, then changed to six months once that stopped being true.
>> The issue is that 4.2 is being delayed way too much, fast approaching a
>> year now, apparently because Michael (Who handles releases) is dealing
>> with a constant influx of new issues reported by fuzzers, most of which
>> he considers a security concern.
> 
> with releases every 3 months several people complained that there are
> too many releases. 

Yes. On top of increasing maintenance work (mostly from you) by having
more releases that potentially required backported commits in point
releases.

> 
> I agree that 4.2 is delayed too much, ill make that release soon, just
> wanted to give the latest sec fixes a ~day on the ML for reviews.
> 
> It does seem judging from the unhappyness with a 3months shedule and
> the now unhappyness with a almost 9? month that 6 month is the sweet spot.
> So ill aim towards maybe 5months in the future and with unexpected delays
> we will then achieve a 6 months release cycle.

Six months is a sweet spot, yeah. Ideally, we'd bump major once a year
to clean structs and remove deprecated API, and only worry about ABI
compatibility between two releases.

> 
> About paul doing the releases, i think the work on codecs and filters
> and all the surroundings that he is doing currently is more valuable.
> 
> I appologize for the 4.2 release being late

Please take my suggestion into consideration. Every fuzzer reported
issue can't possibly be considered a blocker. A first point release
being made a week or two after the original should be enough to
implement fixes for the less important ones and prevent further delays
for the release proper.

Thanks for your work with the releases.
___
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 v5] avfilter/avf_aphasemeter: Add out-of-phase and mono detection

[Paul B Mahol]

This should be applied with sdtbool.h  include removed.

On Mon, Jul 8, 2019 at 2:01 PM Romane Lafon  wrote:

> This patch extends aphasemeter to detect out of phase or mono sequences in
> stereo streams, with its associated documentation.
> ___
> 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 05/13] avcodec/cbs_av1_syntax_template: Check ref_frame_idx before use

[James Almer]

On 8/4/2019 1:44 PM, Michael Niedermayer wrote:
> Fixes: index -1 out of bounds for type 'AV1ReferenceFrameState [8]'
> Fixes: 
> 16079/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5758807440883712
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cbs_av1_syntax_template.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/cbs_av1_syntax_template.c 
> b/libavcodec/cbs_av1_syntax_template.c
> index b04cd51d55..806b302de6 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -419,16 +419,17 @@ static int 
> FUNC(frame_size_with_refs)(CodedBitstreamContext *ctx, RWContext *rw,
>  for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
>  flags(found_ref[i], 1, i);
>  if (current->found_ref[i]) {
> -AV1ReferenceFrameState *ref =
> -&priv->ref[current->ref_frame_idx[i]];
> +AV1ReferenceFrameState *ref;
>  
> -if (!ref->valid) {
> +if (current->ref_frame_idx[i] < 0 ||
> +!priv->ref[current->ref_frame_idx[i]].valid) {
>  av_log(ctx->log_ctx, AV_LOG_ERROR,
> "Missing reference frame needed for frame size "
> "(ref = %d, ref_frame_idx = %d).\n",
> i, current->ref_frame_idx[i]);
>  return AVERROR_INVALIDDATA;
>  }
> +ref = &priv->ref[current->ref_frame_idx[i]];
>  
>  priv->upscaled_width = ref->upscaled_width;
>  priv->frame_width= ref->frame_width;

This actually revealed a bug when setting ref_frame_idx[i] in the
frame_refs_short_signaling == true code path. It's incomplete given that
the -1 is a placeholder meant to be replaced further into the process.

This change is ok to prevent the out of bounds issue for now, but valid
files are in theory being rejected, and that should be fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Michael Niedermayer
> > Sent: Monday, August 5, 2019 3:45 AM
> > To: FFmpeg development discussions and patches
> > 
> > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > 
> > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > 
> > > wrote:
> > >
> > > > Hi all
> > > >
> > > > It seems we do not have a list of people volunteering to do uploads
> > > > to samples. And no place to send such requests to except here, where
> > > > they sometimes get ignored.
> > > >
> > >
> > > Just give everyone with push access right to upload.
> > 
> > Upload currently requires an account on the server, giving everyone an
> > account is a security risk.
> > It also doesnt really make sense to give someone access who doesnt need
> > access.
> > If someone wants to take care of uploads (s)he can have access.
> > 
> > Of course if theres a majority wanting everyone with push access to have an
> > account on the server, sure we will do that but i dont think its a good 
> > idea.
> > IMHO its always better (aka more secure) if access is kept at a minimum.
> > 
> > besides, it would be a bit of work to keep the list of who has push access 
> > and
> > who has sampeles access synchronized. Its different servers and different
> > types of "accounts"
> > and the whole point from my point of view is that id like to spend my time 
> > on
> > other areas on FFmpeg While keeping accounts synchronized would be
> > probably more work than doing the uploads myself
> > 
> > Thanks
> 

> My suggestions would be:
> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him how to 
> apply and update the FATE MAINTAINERS list.

Iam not sure if there is someone, but if so (s)he should send an email to 
root or to ffmpeg-devel (again in case he did long ago already)


> 2. If there is anyone with push access has a requirement to upload a fate 
> sample, reply him to please apply fate access and update the FATE MAINTAINERS 
> list.
> 
> Then there will be several or a dozen of people with fate access in the 
> future, they can help to take the requirements from someone who have no both 
> push access and FATE account, this will be not a big burden for everyone.

i agree, this sounds reasonable, also for people with push access if they only
need 1 upload ever, its easier if someone with access handles it than adding
another account

Thanks


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

Those who are best at talking, realize last or never when they are wrong.


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] [RFC] samples.ffmpeg.org

[Paul B Mahol]

On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer 
wrote:

> On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > Of Michael Niedermayer
> > > Sent: Monday, August 5, 2019 3:45 AM
> > > To: FFmpeg development discussions and patches
> > > 
> > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > >
> > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > > 
> > > > wrote:
> > > >
> > > > > Hi all
> > > > >
> > > > > It seems we do not have a list of people volunteering to do uploads
> > > > > to samples. And no place to send such requests to except here,
> where
> > > > > they sometimes get ignored.
> > > > >
> > > >
> > > > Just give everyone with push access right to upload.
> > >
> > > Upload currently requires an account on the server, giving everyone an
> > > account is a security risk.
> > > It also doesnt really make sense to give someone access who doesnt need
> > > access.
> > > If someone wants to take care of uploads (s)he can have access.
> > >
> > > Of course if theres a majority wanting everyone with push access to
> have an
> > > account on the server, sure we will do that but i dont think its a
> good idea.
> > > IMHO its always better (aka more secure) if access is kept at a
> minimum.
> > >
> > > besides, it would be a bit of work to keep the list of who has push
> access and
> > > who has sampeles access synchronized. Its different servers and
> different
> > > types of "accounts"
> > > and the whole point from my point of view is that id like to spend my
> time on
> > > other areas on FFmpeg While keeping accounts synchronized would be
> > > probably more work than doing the uploads myself
> > >
> > > Thanks
> >
>
> > My suggestions would be:
> > 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
> how to apply and update the FATE MAINTAINERS list.
>
> Iam not sure if there is someone, but if so (s)he should send an email to
> root or to ffmpeg-devel (again in case he did long ago already)
>

You are not sure that you gave someone upload access to fate samples?
Perhaps you forgot?


>
>
> > 2. If there is anyone with push access has a requirement to upload a
> fate sample, reply him to please apply fate access and update the FATE
> MAINTAINERS list.
> >
> > Then there will be several or a dozen of people with fate access in the
> future, they can help to take the requirements from someone who have no
> both push access and FATE account, this will be not a big burden for
> everyone.
>
> i agree, this sounds reasonable, also for people with push access if they
> only
> need 1 upload ever, its easier if someone with access handles it than
> adding
> another account
>
> Thanks
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> 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] libavcodec: add timer bitstream filter [v2]

[Moritz Barsnick]

Hi Andreas,

On Fri, Aug 02, 2019 at 13:03:03 +, Andreas Håkon wrote:

While trying to figure out how to add features I'd like to see into
this ;-), some remarks:

> +Apply an offset to the PTS/DTS timestamps.
> +
> +@table @option
> +@item offset
> +The offset value to apply to the PTS/DTS timestamps.

For the unknowing, it might be useful to point out what sort of
increments this is (i.e. not an actual "time" stamp or seconds).

> +// TODO: Control time wrapping
[...]
> +int offset;
[...]
> +{ "offset", NULL, OFFSET(offset), AV_OPT_TYPE_INT, { .i64 = 0 }, 
> INT_MIN, INT_MAX, FLAGS },

Considering PTS/DTS is int64, wouldn't it be useful for the offset also
being int64 (and using limits INT64_MIN, INT64_MAX)?

> +// TODO: Instead of using absolute timestamp offsets, use frame numbers

Alternatively? Or perhaps also AV_OPT_TYPE_DURATION? TODO is for later,
anyway...

> +if (!s->first_debug_done) {
> +av_log(ctx, AV_LOG_DEBUG, "Updated PTS/DTS (%"PRId64"/%"PRId64" : 
> %"PRId64"/%"PRId64") with offset:%d\n",
> +pkt->pts, pkt->dts, opts, odts, s->offset );
> +}
> +s->first_debug_done = 1;

You should set the variable inside the if() block. otherwise it gets
assigned on every packet.

> +static const AVClass timer_class = {
> +.class_name = "timer",

In about half of the existing BSFs, this would be called "timer_bsf". I
don't care, I just look at other existing code. ;-)

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

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

Re: [FFmpeg-devel] [PATCH] avformat/assenc: Don't truncate lines to 4095 characters

[Paul B Mahol]

Please send such patch.

On Sun, Aug 4, 2019 at 5:41 PM Marton Balint  wrote:

>
>
> On Sun, 4 Aug 2019, Paul B Mahol wrote:
>
> > On Sun, Aug 4, 2019 at 2:58 PM Marton Balint  wrote:
> >
> >>
> >>
> >> On Sun, 4 Aug 2019, Paul B Mahol wrote:
> >>
> >> > On Sun, Aug 4, 2019 at 12:54 PM Marton Balint  wrote:
> >> >
> >> >>
> >> >>
> >> >> On Sat, 3 Aug 2019, Tellow Krinkle wrote:
> >> >>
> >> >> > Fixes #6390
> >> >> >
> >> >> > Sample file for new test:
> >> >>
> >>
> https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass
> >> >> >
> >> >> > Signed-off-by: Tellow Krinkle 
> >> >> > ---
> >> >> > libavformat/assenc.c | 4 +++-
> >> >> > tests/fate/subtitles.mak | 4 
> >> >> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >> >> >
> >> >> > diff --git a/libavformat/assenc.c b/libavformat/assenc.c
> >> >> > index d50f18feb1..9b44b16597 100644
> >> >> > --- a/libavformat/assenc.c
> >> >> > +++ b/libavformat/assenc.c
> >> >> > @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s,
> int
> >> >> force)
> >> >> >ass->expected_readorder, dialogue->readorder);
> >> >> > ass->expected_readorder = dialogue->readorder;
> >> >> > }
> >> >> > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line);
> >> >> > +avio_write(s->pb, "Dialogue: ", 10);
> >> >> > +avio_write(s->pb, dialogue->line, strlen(dialogue->line));
> >> >> > +avio_write(s->pb, "\r\n", 2);
> >> >>
> >> >> IMHO avio_printf should be fixed instead to use an AVBPrint buffer,
> this
> >> >> should remove the 4k limit from it.
> >> >>
> >> >
> >> > That is unrelated issue. Using avio_printf in this specific case is
> >> > overkill.
> >>
> >> Using 3 avio_writes instead is a useless micro optimalization which also
> >> reduces readblity, but feel free to apply if you feel stong about it.
> >>
> >
> > I doubt so, make actual benchmark to prove your claims.
> > Allocation + memcpy is slower than direct writing.
>
> And considering the size of ASS files (a few hundred KB) it will not be
> measureable overall, only if you benchmark the actual function.
>
> If you are really concerened, we could add a function like this:
>
> int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
> {
>  va_list ap;
>  int ret = 0;
>
>  va_start(ap, nb_strings);
>  for (int i = 0; i < nb_strings; i++) {
>  const char *str = va_arg(ap, const char *);
>  int len = strlen(str);
>  avio_write(s, (const unsigned char *)str, len);
>  ret += len;
>  }
>  va_end(ap);
>
>  return ret;
> }
>
> /**
>   * Write nb_strings number of strings (const char *) to the context.
>   */
> #define avio_print(s, ...) avio_print_n_strings(s, sizeof((const
> char*[]){__VA_ARGS__}) / sizeof(const char*), __VA_ARGS__);
>
> So from ASSenc you could use:
>
> avio_print(s->pb, "Dialogue: ", dialogue->line, "\r\n");
>
> 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".
___
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 05/13] avcodec/cbs_av1_syntax_template: Check ref_frame_idx before use

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 12:19:24PM -0300, James Almer wrote:
> On 8/4/2019 1:44 PM, Michael Niedermayer wrote:
> > Fixes: index -1 out of bounds for type 'AV1ReferenceFrameState [8]'
> > Fixes: 
> > 16079/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5758807440883712
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/cbs_av1_syntax_template.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/cbs_av1_syntax_template.c 
> > b/libavcodec/cbs_av1_syntax_template.c
> > index b04cd51d55..806b302de6 100644
> > --- a/libavcodec/cbs_av1_syntax_template.c
> > +++ b/libavcodec/cbs_av1_syntax_template.c
> > @@ -419,16 +419,17 @@ static int 
> > FUNC(frame_size_with_refs)(CodedBitstreamContext *ctx, RWContext *rw,
> >  for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
> >  flags(found_ref[i], 1, i);
> >  if (current->found_ref[i]) {
> > -AV1ReferenceFrameState *ref =
> > -&priv->ref[current->ref_frame_idx[i]];
> > +AV1ReferenceFrameState *ref;
> >  
> > -if (!ref->valid) {
> > +if (current->ref_frame_idx[i] < 0 ||
> > +!priv->ref[current->ref_frame_idx[i]].valid) {
> >  av_log(ctx->log_ctx, AV_LOG_ERROR,
> > "Missing reference frame needed for frame size "
> > "(ref = %d, ref_frame_idx = %d).\n",
> > i, current->ref_frame_idx[i]);
> >  return AVERROR_INVALIDDATA;
> >  }
> > +ref = &priv->ref[current->ref_frame_idx[i]];
> >  
> >  priv->upscaled_width = ref->upscaled_width;
> >  priv->frame_width= ref->frame_width;
> 
> This actually revealed a bug when setting ref_frame_idx[i] in the
> frame_refs_short_signaling == true code path. It's incomplete given that
> the -1 is a placeholder meant to be replaced further into the process.
> 
> This change is ok to prevent the out of bounds issue for now, but valid
> files are in theory being rejected, and that should be fixed.

ok, will apply then.

Thanks

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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/7] avformat/dashenc: add missing padding to the updated extradata

[Paul B Mahol]

On Fri, Aug 2, 2019 at 5:07 PM James Almer  wrote:

> On 8/2/2019 11:46 AM, Andreas Rheinhardt wrote:
> > James Almer:
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavformat/dashenc.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >> index bded260806..50eba370d9 100644
> >> --- a/libavformat/dashenc.c
> >> +++ b/libavformat/dashenc.c
> >> @@ -1476,12 +1476,13 @@ static int
> update_stream_extradata(AVFormatContext *s, OutputStream *os,
> >>  if (!extradata_size)
> >>  return 0;
> >>
> >> -new_extradata = av_malloc(extradata_size);
> >> +new_extradata = av_malloc(extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> >>
> >>  if (!new_extradata)
> >>  return AVERROR(ENOMEM);
> >>
> >>  memcpy(new_extradata, extradata, extradata_size);
> >> +memset(new_extradata + extradata_size, 0,
> AV_INPUT_BUFFER_PADDING_SIZE);
> >>
> >>  os->ctx->streams[0]->codecpar->extradata = new_extradata;
> >>  os->ctx->streams[0]->codecpar->extradata_size = extradata_size;
> >>
> > Is there a reason you are not using ff_alloc_extradata?
> >
> > - Andreas
>
> Not really. I can replace this patch with one implementing
> ff_alloc_extradata().
>

Please do so, less code :)


> ___
> 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/7] avformat/dashenc: add missing padding to the updated extradata

[James Almer]

On 8/5/2019 12:42 PM, Paul B Mahol wrote:
> On Fri, Aug 2, 2019 at 5:07 PM James Almer  wrote:
> 
>> On 8/2/2019 11:46 AM, Andreas Rheinhardt wrote:
>>> James Almer:
 Signed-off-by: James Almer 
 ---
  libavformat/dashenc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
 index bded260806..50eba370d9 100644
 --- a/libavformat/dashenc.c
 +++ b/libavformat/dashenc.c
 @@ -1476,12 +1476,13 @@ static int
>> update_stream_extradata(AVFormatContext *s, OutputStream *os,
  if (!extradata_size)
  return 0;

 -new_extradata = av_malloc(extradata_size);
 +new_extradata = av_malloc(extradata_size +
>> AV_INPUT_BUFFER_PADDING_SIZE);

  if (!new_extradata)
  return AVERROR(ENOMEM);

  memcpy(new_extradata, extradata, extradata_size);
 +memset(new_extradata + extradata_size, 0,
>> AV_INPUT_BUFFER_PADDING_SIZE);

  os->ctx->streams[0]->codecpar->extradata = new_extradata;
  os->ctx->streams[0]->codecpar->extradata_size = extradata_size;

>>> Is there a reason you are not using ff_alloc_extradata?
>>>
>>> - Andreas
>>
>> Not really. I can replace this patch with one implementing
>> ff_alloc_extradata().
>>
> 
> Please do so, less code :)

Already did and pushed it last Saturday :p
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer 
> wrote:
> 
> > On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > > Of Michael Niedermayer
> > > > Sent: Monday, August 5, 2019 3:45 AM
> > > > To: FFmpeg development discussions and patches
> > > > 
> > > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > > >
> > > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > Hi all
> > > > > >
> > > > > > It seems we do not have a list of people volunteering to do uploads
> > > > > > to samples. And no place to send such requests to except here,
> > where
> > > > > > they sometimes get ignored.
> > > > > >
> > > > >
> > > > > Just give everyone with push access right to upload.
> > > >
> > > > Upload currently requires an account on the server, giving everyone an
> > > > account is a security risk.
> > > > It also doesnt really make sense to give someone access who doesnt need
> > > > access.
> > > > If someone wants to take care of uploads (s)he can have access.
> > > >
> > > > Of course if theres a majority wanting everyone with push access to
> > have an
> > > > account on the server, sure we will do that but i dont think its a
> > good idea.
> > > > IMHO its always better (aka more secure) if access is kept at a
> > minimum.
> > > >
> > > > besides, it would be a bit of work to keep the list of who has push
> > access and
> > > > who has sampeles access synchronized. Its different servers and
> > different
> > > > types of "accounts"
> > > > and the whole point from my point of view is that id like to spend my
> > time on
> > > > other areas on FFmpeg While keeping accounts synchronized would be
> > > > probably more work than doing the uploads myself
> > > >
> > > > Thanks
> > >
> >
> > > My suggestions would be:
> > > 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
> > how to apply and update the FATE MAINTAINERS list.
> >
> > Iam not sure if there is someone, but if so (s)he should send an email to
> > root or to ffmpeg-devel (again in case he did long ago already)
> >
> 
> You are not sure that you gave someone upload access to fate samples?
> Perhaps you forgot?

iam not sure if someone volunteered and did not receive access as at a
similar time other people suggested that the existing people with access
could handle it and no new uploaders where needed.

So yeah, short form: i forgot the name from an email months or years ago.


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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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/7] avformat/dashenc: add missing padding to the updated extradata

[Andreas Rheinhardt]

Paul B Mahol:
> On Fri, Aug 2, 2019 at 5:07 PM James Almer  wrote:
> 
>> On 8/2/2019 11:46 AM, Andreas Rheinhardt wrote:
>>> James Almer:
 Signed-off-by: James Almer 
 ---
  libavformat/dashenc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
 index bded260806..50eba370d9 100644
 --- a/libavformat/dashenc.c
 +++ b/libavformat/dashenc.c
 @@ -1476,12 +1476,13 @@ static int
>> update_stream_extradata(AVFormatContext *s, OutputStream *os,
  if (!extradata_size)
  return 0;

 -new_extradata = av_malloc(extradata_size);
 +new_extradata = av_malloc(extradata_size +
>> AV_INPUT_BUFFER_PADDING_SIZE);

  if (!new_extradata)
  return AVERROR(ENOMEM);

  memcpy(new_extradata, extradata, extradata_size);
 +memset(new_extradata + extradata_size, 0,
>> AV_INPUT_BUFFER_PADDING_SIZE);

  os->ctx->streams[0]->codecpar->extradata = new_extradata;
  os->ctx->streams[0]->codecpar->extradata_size = extradata_size;

>>> Is there a reason you are not using ff_alloc_extradata?
>>>
>>> - Andreas
>>
>> Not really. I can replace this patch with one implementing
>> ff_alloc_extradata().
>>
> 
> Please do so, less code :)
> 
> 
He already did. The whole patchset has been merged already.

- Andreas

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

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Paul B Mahol]

On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
wrote:

> On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> > On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
> 
> > wrote:
> >
> > > On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > > > Of Michael Niedermayer
> > > > > Sent: Monday, August 5, 2019 3:45 AM
> > > > > To: FFmpeg development discussions and patches
> > > > > 
> > > > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > > > >
> > > > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > > > > 
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all
> > > > > > >
> > > > > > > It seems we do not have a list of people volunteering to do
> uploads
> > > > > > > to samples. And no place to send such requests to except here,
> > > where
> > > > > > > they sometimes get ignored.
> > > > > > >
> > > > > >
> > > > > > Just give everyone with push access right to upload.
> > > > >
> > > > > Upload currently requires an account on the server, giving
> everyone an
> > > > > account is a security risk.
> > > > > It also doesnt really make sense to give someone access who doesnt
> need
> > > > > access.
> > > > > If someone wants to take care of uploads (s)he can have access.
> > > > >
> > > > > Of course if theres a majority wanting everyone with push access to
> > > have an
> > > > > account on the server, sure we will do that but i dont think its a
> > > good idea.
> > > > > IMHO its always better (aka more secure) if access is kept at a
> > > minimum.
> > > > >
> > > > > besides, it would be a bit of work to keep the list of who has push
> > > access and
> > > > > who has sampeles access synchronized. Its different servers and
> > > different
> > > > > types of "accounts"
> > > > > and the whole point from my point of view is that id like to spend
> my
> > > time on
> > > > > other areas on FFmpeg While keeping accounts synchronized would be
> > > > > probably more work than doing the uploads myself
> > > > >
> > > > > Thanks
> > > >
> > >
> > > > My suggestions would be:
> > > > 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
> > > how to apply and update the FATE MAINTAINERS list.
> > >
> > > Iam not sure if there is someone, but if so (s)he should send an email
> to
> > > root or to ffmpeg-devel (again in case he did long ago already)
> > >
> >
> > You are not sure that you gave someone upload access to fate samples?
> > Perhaps you forgot?
>
> iam not sure if someone volunteered and did not receive access as at a
> similar time other people suggested that the existing people with access
> could handle it and no new uploaders where needed.
>
> So yeah, short form: i forgot the name from an email months or years ago.
>
>
Can you check now who have access?


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death your
> right to say it. -- Voltaire
> ___
> 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 v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation

[Michael Niedermayer]

On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote:
> The previous calculation code did not account for the fact that the
> copy_offset for the start of the frame array is at index 0, yet the
> scan line number from the rfc4175 RTP header starts at 1.
> This caused 2 issues to appear:
> - The first scan line was being copied into the array where the second
>   scan line should be. This caused the resulting video to have a green
>   line at the top of it.
> - Since the packet containing the last scan line would fail the
>   calculation, the packet with the RTP marker would not be processed
>   which caused a log message saying "Missed previous RTP marker" to be
>   outputted for each frame.
> 
> Signed-off-by: Jacob Siddall 
> ---
> Changes in v2:
>   - Don't handle packet if the line number is less than 1
> 
> Section 12 in the VSF technical recommendation TR-03 specifies that the
> video scan line numbers should start at 1.
> http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
> 
> Changes in v3:
>   - Changed the commit hash abbreviation in the patch file diff to be 10
> characters in length rather than 7. This was causing the patch file
> to fail when it was applied. 
> 
>  libavformat/rtpdec_rfc4175.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

will apply

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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/sanm: Check extradata_size before allocations

[Michael Niedermayer]

On Tue, Jul 16, 2019 at 08:47:26PM +0200, Michael Niedermayer wrote:
> On Tue, Jul 16, 2019 at 08:27:43AM +0200, Reimar Döffinger wrote:
> > On 16.07.2019, at 00:50, Michael Niedermayer  wrote:
> > 
> > > Fixes: Leaks
> > > Fixes: 
> > > 15349/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5102530557640704
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > > libavcodec/sanm.c | 9 -
> > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
> > > index 25aee7220f..60e2f4c624 100644
> > > --- a/libavcodec/sanm.c
> > > +++ b/libavcodec/sanm.c
> > > @@ -491,6 +491,10 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > 
> > > ctx->avctx   = avctx;
> > > ctx->version = !avctx->extradata_size;
> > > +if (!ctx->version && avctx->extradata_size < 1026) {
> > > +av_log(avctx, AV_LOG_ERROR, "Not enough extradata.\n");
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > > 
> > > avctx->pix_fmt = ctx->version ? AV_PIX_FMT_RGB565 : AV_PIX_FMT_PAL8;
> > > 
> > > @@ -506,11 +510,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > if (!ctx->version) {
> > > int i;
> > > 
> > > -if (avctx->extradata_size < 1026) {
> > > -av_log(avctx, AV_LOG_ERROR, "Not enough extradata.\n");
> > > -return AVERROR_INVALIDDATA;
> > > -}
> > 
> > This seems quite a bit less obvious.
> 
> > Is that the only error return case, and is adding the cleanup code complex 
> > enough that this is the better choice?
> 
> there are 2 error cases, this one and a check for the allocations.
> It seemd logic to me to do the check in the order of minimizing cleanup
> but i can add the cleanup call if people prefer or do some other
> solution ?
> 
> 
> > Either way I'd recommend a comment like
> > // early sanity check before allocations to avoid need for deallocation 
> > code.
> 
> will add

will apply with this change

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] avcodec/vqavideo: Set video size

[Michael Niedermayer]

On Fri, Jul 26, 2019 at 01:52:19AM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 
> 15919/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-5657368257363968
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vqavideo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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/5] avcodec/alsdec: Check for block_length <= 0 in read_var_block_data()

[Michael Niedermayer]

On Fri, Jul 26, 2019 at 06:26:06PM +0200, Michael Niedermayer wrote:
> Fixes: left shift of negative value -1
> Fixes: 
> 15719/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5685731105701888
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/alsdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
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
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] doc/fate: Document how to request samples upload access

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/fate.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/fate.texi b/doc/fate.texi
index 2be61d639c..e04fbfbe43 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -157,6 +157,9 @@ practice generally do not replace, remove or overwrite 
files as it likely would
 break older checkouts or releases.
 Also all needed samples for a commit should be uploaded, ideally 24
 hours, before the push.
+If you need an account for frequently uploading samples or you wish to help
+others do so send mail to ffmpeg-devel. Also please state if you are available
+to help others upload samples if you request access.
 
 @example
 #First update your local samples copy:
-- 
2.22.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 v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation

[Kieran Kunhya]

On Mon, 5 Aug 2019 at 17:10, Michael Niedermayer 
wrote:

> On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote:
> > The previous calculation code did not account for the fact that the
> > copy_offset for the start of the frame array is at index 0, yet the
> > scan line number from the rfc4175 RTP header starts at 1.
> > This caused 2 issues to appear:
> > - The first scan line was being copied into the array where the second
> >   scan line should be. This caused the resulting video to have a green
> >   line at the top of it.
> > - Since the packet containing the last scan line would fail the
> >   calculation, the packet with the RTP marker would not be processed
> >   which caused a log message saying "Missed previous RTP marker" to be
> >   outputted for each frame.
> >
> > Signed-off-by: Jacob Siddall 
> > ---
> > Changes in v2:
> >   - Don't handle packet if the line number is less than 1
> >
> > Section 12 in the VSF technical recommendation TR-03 specifies that the
> > video scan line numbers should start at 1.
> >
> http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
>
>
SMPTE 2110-20 says line numbers start at 0. (Yes there are 3 different
"standards" for handling the line number because of the geniuses in the
broadcast industry).

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

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

Re: [FFmpeg-devel] libavcodec: add timer bitstream filter [v2]

[Andreas Håkon]

Hi Moritz,


‐‐‐ Original Message ‐‐‐
On Monday, 5 de August de 2019 17:31, Moritz Barsnick  wrote:

> Hi Andreas,
>
> While trying to figure out how to add features I'd like to see into
> this ;-), some remarks:
>
> > +Apply an offset to the PTS/DTS timestamps.
> > +
> > +@table @option
> > +@item offset
> > +The offset value to apply to the PTS/DTS timestamps.
>
> For the unknowing, it might be useful to point out what sort of
> increments this is (i.e. not an actual "time" stamp or seconds).

The value are native PTS/DTS ticks, so a resolution of 90kHz.
So, you agree with something like this?

@item offset
"The absolute offset value to apply to the PTS/DTS timestamps
with a 90kHz resolution."


> [...]
> > +   { "offset", NULL, OFFSET(offset), AV_OPT_TYPE_INT, { .i64 = 0 }, 
> > INT_MIN, INT_MAX, FLAGS },
>
> Considering PTS/DTS is int64, wouldn't it be useful for the offset also
> being int64 (and using limits INT64_MIN, INT64_MAX)?

Aah, I feel you like then to full cover all the possible values.
Then two changes are required:

1. Use int64 types.
2. Limit offset values from -((2^33)-1) to +((2^33)-1)

You agree with this?


> > +// TODO: Instead of using absolute timestamp offsets, use frame numbers
>
> Alternatively? Or perhaps also AV_OPT_TYPE_DURATION? TODO is for later,
> anyway...

Perhaps I'll remove the TODO comments. The reason to appear is because some
other developers in the mailing-list have pointed some interesting ideas for
this plugin in the future. I'm not sure to remove it or not.


> > +   if (!s->first_debug_done) {
> > +  av_log(ctx, AV_LOG_DEBUG, "Updated PTS/DTS (%"PRId64"/%"PRId64" 
> > : %"PRId64"/%"PRId64") with offset:%d\\n",
> > +  pkt->pts, pkt->dts, opts, odts, s->offset );
> > +   }
> > +   s->first_debug_done = 1;
>
> You should set the variable inside the if() block. otherwise it gets
> assigned on every packet.

Yes, a small optimization.


> > +static const AVClass timer_class = {
> > +   .class_name = "timer",
>
> In about half of the existing BSFs, this would be called "timer_bsf". I
> don't care, I just look at other existing code. ;-)
>

Good point! Other bitstream filters have this. I'll update it.
Thank you!


Regards.
A.H.

---

___
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 v3] avcodec/vaapi_encode_h264: add support for a/53 closed caption sei

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/vaapi_encode_h264.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f4965d8b09..280bd4752b 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -39,6 +39,7 @@ enum {
 SEI_TIMING = 0x01,
 SEI_IDENTIFIER = 0x02,
 SEI_RECOVERY_POINT = 0x04,
+SEI_A53_CC = 0x08,
 };
 
 // Random (version 4) ISO 11578 UUID.
@@ -72,6 +73,7 @@ typedef struct VAAPIEncodeH264Context {
 int sei;
 int profile;
 int level;
+bool enable_a53_cc;
 
 // Derived settings.
 int mb_width;
@@ -98,6 +100,8 @@ typedef struct VAAPIEncodeH264Context {
 H264RawSEIRecoveryPointsei_recovery_point;
 H264RawSEIUserDataUnregistered sei_identifier;
 char  *sei_identifier_string;
+H264RawSEIUserDataRegistered   sei_a53cc;
+void  *sei_a53cc_data;
 
 int aud_needed;
 int sei_needed;
@@ -251,6 +255,11 @@ static int 
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
 sei->payload[i].payload.recovery_point = priv->sei_recovery_point;
 ++i;
 }
+if (priv->sei_needed & SEI_A53_CC) {
+sei->payload[i].payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED;
+sei->payload[i].payload.user_data_registered = priv->sei_a53cc;
+++i;
+}
 
 sei->payload_count = i;
 av_assert0(sei->payload_count > 0);
@@ -626,7 +635,8 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 VAAPIEncodePicture  *prev = pic->prev;
 VAAPIEncodeH264Picture *hprev = prev ? prev->priv_data : NULL;
 VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
-int i;
+int i, err;
+size_t sei_a53cc_len;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -700,6 +710,21 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 priv->sei_needed |= SEI_RECOVERY_POINT;
 }
 
+if (priv->enable_a53_cc) {
+av_freep(&priv->sei_a53cc_data);
+err = ff_alloc_a53_sei(pic->input_image, 0, &priv->sei_a53cc_data, 
&sei_a53cc_len);
+if (err < 0)
+return err;
+
+if (priv->sei_a53cc_data) {
+priv->sei_a53cc.itu_t_t35_country_code = 181;
+priv->sei_a53cc.data = (uint8_t *)priv->sei_a53cc_data + 1;
+priv->sei_a53cc.data_length = sei_a53cc_len - 1;
+
+priv->sei_needed |= SEI_A53_CC;
+}
+}
+
 vpic->CurrPic = (VAPictureH264) {
 .picture_id  = pic->recon_surface,
 .frame_idx   = hpic->frame_num,
@@ -1245,6 +1270,7 @@ static av_cold int vaapi_encode_h264_close(AVCodecContext 
*avctx)
 ff_cbs_fragment_free(priv->cbc, &priv->current_access_unit);
 ff_cbs_close(&priv->cbc);
 av_freep(&priv->sei_identifier_string);
+av_freep(&priv->sei_a53cc_data);
 
 return ff_vaapi_encode_close(avctx);
 }
@@ -1321,6 +1347,8 @@ static const AVOption vaapi_encode_h264_options[] = {
 { LEVEL("6.2", 62) },
 #undef LEVEL
 
+{ "a53cc", "Use A53 Closed Captions (if available)", 
OFFSET(enable_a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+
 { NULL },
 };
 
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: fix PCR generation intervals

[Andreas Håkon]

Hi Marton,


‐‐‐ Original Message ‐‐‐
On Sunday, 4 de August de 2019 22:30, Marton Balint  wrote:

> PCR generation was based on counting packets for both CBR and VBR streams.
> Couting packets might have worked for CBR streams (when muxrate was specified)
> but it only took into account the packets of a service (or the packets of the
> PCR stream lately), so even that was problematic for multi program streams.
>
> The new code works on actual PCR for CBR and packet DTS values for VBR 
> streams,
> so the default 20ms PCR retransmission time is now respected for both CBR and
> VBR.
>

I do some tests with this patch and the previous 
https://patchwork.ffmpeg.org/patch/14210/

And the result is that the repetition rate of PCR is inconsistent: it's never
constant and varies between different PCR streams.

But fortunately I have an idea...


> Signed-off-by: Marton Balint c...@passwd.hu
>
> libavformat/mpegtsenc.c | 60 +++--
> tests/ref/lavf/ts | 2 +-
> 2 files changed, 19 insertions(+), 43 deletions(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c

[...]

> @@ -1194,18 +1168,24 @@  static void mpegts_write_pes(AVFormatContext *s, 
> AVStream *st,
>
>  is_start = 1;
>  while (payload_size > 0) {
> +int64_t pcr = -1; /* avoid warning */
> +
>  retransmit_si_info(s, force_pat, dts);
>  force_pat = 0;
>
>  write_pcr = 0;
> -if (ts_st->pcr_packet_period) {
> -if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
> frames
> -ts_st->pcr_packet_count++;
> -if (ts_st->pcr_packet_count >=
> -ts_st->pcr_packet_period) {
> -ts_st->pcr_packet_count = 0;
> -write_pcr = 1;
> +if (ts_st->pcr_period) {
> +if (ts->mux_rate > 1) {
> +pcr = get_pcr(ts, s->pb);
> +if (pcr - ts_st->last_pcr >= ts_st->pcr_period)
> +write_pcr = 1;
> +} else if (dts != AV_NOPTS_VALUE) {
> +pcr = (dts - delay) * 300;
> +if (pcr - ts_st->last_pcr >= ts_st->pcr_period && is_start)
> +write_pcr = 1;
>  }
> +if (write_pcr)
> +ts_st->last_pcr = FFMAX(pcr - ts_st->pcr_period, 
> ts_st->last_pcr + ts_st->pcr_period);
>  }

IMHO, here you return to make the same mistake of the previous code:
only consider one PCR stream. Instead of the "if (ts_st->pcr_period)" it's
required to iterate over all PCR streams and do the corresponding checks.
And if some PCR stream has exceeded the pcr_period limit then enforce to
write an empty TS packet with a PCR mark.

In fact, the root cause is the sequential PES writing on the MPEG-TS muxer.
And this is the reason for my interleaving mux patch:
https://patchwork.ffmpeg.org/patch/13745/

However, until I rebase your code for the interleave mux mode, the PCR
generation of this patch needs to be fixed.

[...]


Regards.
A.H.

---
___
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 v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 06:05:29PM +0100, Kieran Kunhya wrote:
> On Mon, 5 Aug 2019 at 17:10, Michael Niedermayer 
> wrote:
> 
> > On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote:
> > > The previous calculation code did not account for the fact that the
> > > copy_offset for the start of the frame array is at index 0, yet the
> > > scan line number from the rfc4175 RTP header starts at 1.
> > > This caused 2 issues to appear:
> > > - The first scan line was being copied into the array where the second
> > >   scan line should be. This caused the resulting video to have a green
> > >   line at the top of it.
> > > - Since the packet containing the last scan line would fail the
> > >   calculation, the packet with the RTP marker would not be processed
> > >   which caused a log message saying "Missed previous RTP marker" to be
> > >   outputted for each frame.
> > >
> > > Signed-off-by: Jacob Siddall 
> > > ---
> > > Changes in v2:
> > >   - Don't handle packet if the line number is less than 1
> > >
> > > Section 12 in the VSF technical recommendation TR-03 specifies that the
> > > video scan line numbers should start at 1.
> > >
> > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
> >
> >
> SMPTE 2110-20 says line numbers start at 0. (Yes there are 3 different
> "standards" for handling the line number because of the geniuses in the
> broadcast industry).

Jacob, can you look into this ?

should i revert until this is fixed?

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] [RFC] samples.ffmpeg.org

[Thilo Borgmann]

Am 05.08.19 um 17:57 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
> wrote:
> 
>> On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
>>> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
>> 
>>> wrote:
>>>
 On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> Of Michael Niedermayer
>> Sent: Monday, August 5, 2019 3:45 AM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
>>
>> On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
>>> On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
>>> 
>>> wrote:
>>>
 Hi all

 It seems we do not have a list of people volunteering to do
>> uploads
 to samples. And no place to send such requests to except here,
 where
 they sometimes get ignored.

>>>
>>> Just give everyone with push access right to upload.
>>
>> Upload currently requires an account on the server, giving
>> everyone an
>> account is a security risk.
>> It also doesnt really make sense to give someone access who doesnt
>> need
>> access.
>> If someone wants to take care of uploads (s)he can have access.
>>
>> Of course if theres a majority wanting everyone with push access to
 have an
>> account on the server, sure we will do that but i dont think its a
 good idea.
>> IMHO its always better (aka more secure) if access is kept at a
 minimum.
>>
>> besides, it would be a bit of work to keep the list of who has push
 access and
>> who has sampeles access synchronized. Its different servers and
 different
>> types of "accounts"
>> and the whole point from my point of view is that id like to spend
>> my
 time on
>> other areas on FFmpeg While keeping accounts synchronized would be
>> probably more work than doing the uploads myself
>>
>> Thanks
>

> My suggestions would be:
> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
 how to apply and update the FATE MAINTAINERS list.

 Iam not sure if there is someone, but if so (s)he should send an email
>> to
 root or to ffmpeg-devel (again in case he did long ago already)

>>>
>>> You are not sure that you gave someone upload access to fate samples?
>>> Perhaps you forgot?
>>
>> iam not sure if someone volunteered and did not receive access as at a
>> similar time other people suggested that the existing people with access
>> could handle it and no new uploaders where needed.
>>
>> So yeah, short form: i forgot the name from an email months or years ago.
>>
>>
> Can you check now who have access?

Would it make sense to create a samp...@ffmpeg.org address and put the people 
in charge behind that address?

How much work does one expect from that? Do we upload several a day?

I would volunteer to take at least part of the burden.

-Thilo
___
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] avfilter: add vr360 filter

[Eugene Lyapustin]

Signed-off-by: Eugene Lyapustin 
---
 doc/filters.texi |  137 +++
 libavfilter/Makefile |1 +
 libavfilter/allfilters.c |1 +
 libavfilter/vf_vr360.c   | 1847 ++
 4 files changed, 1986 insertions(+)
 create mode 100644 libavfilter/vf_vr360.c

diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc7bc..14890209ab 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18457,6 +18457,143 @@ is computed.
 ffmpeg -i ref.mpg -lavfi vmafmotion -f null -
 @end example
 
+@section vr360
+
+Convert 360 videos between various formats.
+
+The filter accepts the following options:
+
+@table @option
+
+@item input
+@item output
+Set format of the input/output video.
+
+Available formats:
+
+@table @samp
+
+@item e
+Equirectangular projection.
+
+@item c3x2
+@item c6x1
+Cubemap with 3x2/6x1 layout.
+
+Format specific options:
+
+@table @option
+@item in_forder
+@item out_forder
+Set order of faces for the input/output cubemap. Choose one direction for each 
position.
+
+Designation of directions:
+@table @samp
+@item r
+right
+@item l
+left
+@item u
+up
+@item d
+down
+@item f
+forward
+@item b
+back
+@end table
+
+Default value is @b{@samp{rludfb}}.
+
+@item in_frot
+@item out_frot
+Set rotation of faces for the input/output cubemap. Choose one angle for each 
position.
+
+Designation of angles:
+@table @samp
+@item 0
+0 degrees clockwise
+@item 1
+90 degrees clockwise
+@item 2
+180 degrees clockwise
+@item 4
+270 degrees clockwise
+@end table
+
+Default value is @b{@samp{00}}.
+@end table
+
+@item eac
+Equi-Angular Cubemap.
+
+@item flat
+Regular video. @i{(output only)}
+
+Format specific options:
+@table @option
+@item h_fov
+@item v_fov
+Set horizontal/vertical field of view. Values in degrees.
+@end table
+@end table
+
+@item interp
+Set interpolation method.@*
+@i{Note: more complex interpolation methods require much more memory to run.}
+
+Available methods:
+
+@table @samp
+@item near
+@item nearest
+Nearest neighbour.
+@item line
+@item linear
+Bilinear interpolation.
+@item cube
+@item cubic
+Bicubic interpolation.
+@item lanc
+@item lanczos
+Lanczos interpolation.
+@end table
+
+Default value is @b{@samp{line}}.
+
+@item w
+@item h
+Set the output video resolution.
+
+Default resolution depends on formats.
+
+@item yaw
+@item pitch
+@item roll
+Set rotation for the output video. Values in degrees.
+
+@item hflip
+@item vflip
+@item dflip
+Flip the output video horizontally/vertically/in-depth. Boolean values.
+
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Convert equirectangular video to cubemap with 3x2 layout using bicubic 
interpolation:
+@example
+ffmpeg -i input.mkv -vf vr360=e:c3x2:cubic output.mkv
+@end example
+@item
+Extract back view of Equi-Angular Cubemap:
+@example
+ffmpeg -i input.mkv -vf vr360=eac:flat:yaw=180 output.mkv
+@end example
+@end itemize
+
 @section vstack
 Stack input videos vertically.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index efc7bbb153..87323920ba 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -420,6 +420,7 @@ OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += 
vidstabutils.o vf_vidstabtransfo
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
 OBJS-$(CONFIG_VMAFMOTION_FILTER) += vf_vmafmotion.o framesync.o
 OBJS-$(CONFIG_VPP_QSV_FILTER)+= vf_vpp_qsv.o
+OBJS-$(CONFIG_VR360_FILTER)  += vf_vr360.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index abd726d616..5d34416430 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -400,6 +400,7 @@ extern AVFilter ff_vf_vidstabtransform;
 extern AVFilter ff_vf_vignette;
 extern AVFilter ff_vf_vmafmotion;
 extern AVFilter ff_vf_vpp_qsv;
+extern AVFilter ff_vf_vr360;
 extern AVFilter ff_vf_vstack;
 extern AVFilter ff_vf_w3fdif;
 extern AVFilter ff_vf_waveform;
diff --git a/libavfilter/vf_vr360.c b/libavfilter/vf_vr360.c
new file mode 100644
index 00..32dadf5a79
--- /dev/null
+++ b/libavfilter/vf_vr360.c
@@ -0,0 +1,1847 @@
+/*
+ * Copyright (c) 2019 Eugene Lyapustin
+ *
+ * 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 

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 05:57:47PM +0200, Paul B Mahol wrote:
> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
> wrote:
> 
> > On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> > > On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
> > 
> > > wrote:
> > >
> > > > On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > > > > Of Michael Niedermayer
> > > > > > Sent: Monday, August 5, 2019 3:45 AM
> > > > > > To: FFmpeg development discussions and patches
> > > > > > 
> > > > > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > > > > >
> > > > > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > > > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > > > > > 
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all
> > > > > > > >
> > > > > > > > It seems we do not have a list of people volunteering to do
> > uploads
> > > > > > > > to samples. And no place to send such requests to except here,
> > > > where
> > > > > > > > they sometimes get ignored.
> > > > > > > >
> > > > > > >
> > > > > > > Just give everyone with push access right to upload.
> > > > > >
> > > > > > Upload currently requires an account on the server, giving
> > everyone an
> > > > > > account is a security risk.
> > > > > > It also doesnt really make sense to give someone access who doesnt
> > need
> > > > > > access.
> > > > > > If someone wants to take care of uploads (s)he can have access.
> > > > > >
> > > > > > Of course if theres a majority wanting everyone with push access to
> > > > have an
> > > > > > account on the server, sure we will do that but i dont think its a
> > > > good idea.
> > > > > > IMHO its always better (aka more secure) if access is kept at a
> > > > minimum.
> > > > > >
> > > > > > besides, it would be a bit of work to keep the list of who has push
> > > > access and
> > > > > > who has sampeles access synchronized. Its different servers and
> > > > different
> > > > > > types of "accounts"
> > > > > > and the whole point from my point of view is that id like to spend
> > my
> > > > time on
> > > > > > other areas on FFmpeg While keeping accounts synchronized would be
> > > > > > probably more work than doing the uploads myself
> > > > > >
> > > > > > Thanks
> > > > >
> > > >
> > > > > My suggestions would be:
> > > > > 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
> > > > how to apply and update the FATE MAINTAINERS list.
> > > >
> > > > Iam not sure if there is someone, but if so (s)he should send an email
> > to
> > > > root or to ffmpeg-devel (again in case he did long ago already)
> > > >
> > >
> > > You are not sure that you gave someone upload access to fate samples?
> > > Perhaps you forgot?
> >
> > iam not sure if someone volunteered and did not receive access as at a
> > similar time other people suggested that the existing people with access
> > could handle it and no new uploaders where needed.
> >
> > So yeah, short form: i forgot the name from an email months or years ago.
> >
> >
> Can you check now who have access?

Yes, 

compn 
carl
reimar
beastd,
lou 
ubitux
paul
hendrik
derek,
james almer
martin vignali
thilo
atomnuker
peter ross

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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] avfilter: add vr360 filter

[Thilo Borgmann]

Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> Signed-off-by: Eugene Lyapustin 
> ---
>  doc/filters.texi |  137 +++
>  libavfilter/Makefile |1 +
>  libavfilter/allfilters.c |1 +
>  libavfilter/vf_vr360.c   | 1847 ++


> +AVFilter ff_vf_vr360 = {
> +.name  = "vr360",
> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of 
> video."),

"vr360" does not make any sense to me. VR and 360 degree are two different 
things.

And since VR-related filters may very well emerge in the future, we should be 
as clear as possible about these.

-Thilo
___
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] avfilter: add vr360 filter

[Paul B Mahol]

On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
wrote:

> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> > Signed-off-by: Eugene Lyapustin 
> > ---
> >  doc/filters.texi |  137 +++
> >  libavfilter/Makefile |1 +
> >  libavfilter/allfilters.c |1 +
> >  libavfilter/vf_vr360.c   | 1847 ++
>
>
> > +AVFilter ff_vf_vr360 = {
> > +.name  = "vr360",
> > +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
> video."),
>
> "vr360" does not make any sense to me. VR and 360 degree are two different
> things.
>
> And since VR-related filters may very well emerge in the future, we should
> be as clear as possible about these.
>

Isnt VR just 360 but for each eye?
___
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] avfilter: add vr360 filter

[Thilo Borgmann]

Am 05.08.19 um 21:00 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
>>> Signed-off-by: Eugene Lyapustin 
>>> ---
>>>  doc/filters.texi |  137 +++
>>>  libavfilter/Makefile |1 +
>>>  libavfilter/allfilters.c |1 +
>>>  libavfilter/vf_vr360.c   | 1847 ++
>>
>>
>>> +AVFilter ff_vf_vr360 = {
>>> +.name  = "vr360",
>>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>> video."),
>>
>> "vr360" does not make any sense to me. VR and 360 degree are two different
>> things.
>>
>> And since VR-related filters may very well emerge in the future, we should
>> be as clear as possible about these.
>>
> 
> Isnt VR just 360 but for each eye?

That would be stereoscopic 360.

What makes it VR is that the camera can move within space, not only change 
viewing direction.

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

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Paul B Mahol]

On Mon, Aug 5, 2019 at 8:55 PM Michael Niedermayer 
wrote:

> On Mon, Aug 05, 2019 at 05:57:47PM +0200, Paul B Mahol wrote:
> > On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer
> 
> > wrote:
> >
> > > On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> > > > On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
> > > 
> > > > wrote:
> > > >
> > > > > On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > > > > > Of Michael Niedermayer
> > > > > > > Sent: Monday, August 5, 2019 3:45 AM
> > > > > > > To: FFmpeg development discussions and patches
> > > > > > > 
> > > > > > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> > > > > > >
> > > > > > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > > > > > > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all
> > > > > > > > >
> > > > > > > > > It seems we do not have a list of people volunteering to do
> > > uploads
> > > > > > > > > to samples. And no place to send such requests to except
> here,
> > > > > where
> > > > > > > > > they sometimes get ignored.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Just give everyone with push access right to upload.
> > > > > > >
> > > > > > > Upload currently requires an account on the server, giving
> > > everyone an
> > > > > > > account is a security risk.
> > > > > > > It also doesnt really make sense to give someone access who
> doesnt
> > > need
> > > > > > > access.
> > > > > > > If someone wants to take care of uploads (s)he can have access.
> > > > > > >
> > > > > > > Of course if theres a majority wanting everyone with push
> access to
> > > > > have an
> > > > > > > account on the server, sure we will do that but i dont think
> its a
> > > > > good idea.
> > > > > > > IMHO its always better (aka more secure) if access is kept at a
> > > > > minimum.
> > > > > > >
> > > > > > > besides, it would be a bit of work to keep the list of who has
> push
> > > > > access and
> > > > > > > who has sampeles access synchronized. Its different servers and
> > > > > different
> > > > > > > types of "accounts"
> > > > > > > and the whole point from my point of view is that id like to
> spend
> > > my
> > > > > time on
> > > > > > > other areas on FFmpeg While keeping accounts synchronized
> would be
> > > > > > > probably more work than doing the uploads myself
> > > > > > >
> > > > > > > Thanks
> > > > > >
> > > > >
> > > > > > My suggestions would be:
> > > > > > 1. If there is any volunteer to be fate-samples MAINTAINERS,
> tell him
> > > > > how to apply and update the FATE MAINTAINERS list.
> > > > >
> > > > > Iam not sure if there is someone, but if so (s)he should send an
> email
> > > to
> > > > > root or to ffmpeg-devel (again in case he did long ago already)
> > > > >
> > > >
> > > > You are not sure that you gave someone upload access to fate samples?
> > > > Perhaps you forgot?
> > >
> > > iam not sure if someone volunteered and did not receive access as at a
> > > similar time other people suggested that the existing people with
> access
> > > could handle it and no new uploaders where needed.
> > >
> > > So yeah, short form: i forgot the name from an email months or years
> ago.
> > >
> > >
> > Can you check now who have access?
>
> Yes,
>
> compn
> carl
> reimar
> beastd,
> lou
> ubitux
> paul
> hendrik
> derek,
> james almer
> martin vignali
> thilo
> atomnuker
> peter ross


Great.

Rule 777. of security: do not expose all people which can be used to break
security.

I did not wanted to list all, just to confirm its me on that list.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 08:48:03PM +0200, Thilo Borgmann wrote:
> Am 05.08.19 um 17:57 schrieb Paul B Mahol:
> > On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
> > wrote:
> > 
> >> On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> >>> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
> >> 
> >>> wrote:
> >>>
>  On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >> Of Michael Niedermayer
> >> Sent: Monday, August 5, 2019 3:45 AM
> >> To: FFmpeg development discussions and patches
> >> 
> >> Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> >>
> >> On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> >>> On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> >>> 
> >>> wrote:
> >>>
>  Hi all
> 
>  It seems we do not have a list of people volunteering to do
> >> uploads
>  to samples. And no place to send such requests to except here,
>  where
>  they sometimes get ignored.
> 
> >>>
> >>> Just give everyone with push access right to upload.
> >>
> >> Upload currently requires an account on the server, giving
> >> everyone an
> >> account is a security risk.
> >> It also doesnt really make sense to give someone access who doesnt
> >> need
> >> access.
> >> If someone wants to take care of uploads (s)he can have access.
> >>
> >> Of course if theres a majority wanting everyone with push access to
>  have an
> >> account on the server, sure we will do that but i dont think its a
>  good idea.
> >> IMHO its always better (aka more secure) if access is kept at a
>  minimum.
> >>
> >> besides, it would be a bit of work to keep the list of who has push
>  access and
> >> who has sampeles access synchronized. Its different servers and
>  different
> >> types of "accounts"
> >> and the whole point from my point of view is that id like to spend
> >> my
>  time on
> >> other areas on FFmpeg While keeping accounts synchronized would be
> >> probably more work than doing the uploads myself
> >>
> >> Thanks
> >
> 
> > My suggestions would be:
> > 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
>  how to apply and update the FATE MAINTAINERS list.
> 
>  Iam not sure if there is someone, but if so (s)he should send an email
> >> to
>  root or to ffmpeg-devel (again in case he did long ago already)
> 
> >>>
> >>> You are not sure that you gave someone upload access to fate samples?
> >>> Perhaps you forgot?
> >>
> >> iam not sure if someone volunteered and did not receive access as at a
> >> similar time other people suggested that the existing people with access
> >> could handle it and no new uploaders where needed.
> >>
> >> So yeah, short form: i forgot the name from an email months or years ago.
> >>
> >>
> > Can you check now who have access?
> 
> Would it make sense to create a samp...@ffmpeg.org address and put the people 
> in charge behind that address?

samp...@ffmpeg.org already exists and some daily debug messages from cronjobs
end there. I am reluctant to just add people to this as they have not
agreed to receive such cronjob "spam"
but i can trivially add anyone who wants to be added
or create a different alias with everyone who has currently access

> 
> How much work does one expect from that? Do we upload several a day?

uploads to fate are relativly rare counting them "per month" would make
more sense than per day


> 
> I would volunteer to take at least part of the burden.

thanks


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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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] avfilter: add vr360 filter

[Paul B Mahol]

On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
wrote:

> Am 05.08.19 um 21:00 schrieb Paul B Mahol:
> > On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
> > wrote:
> >
> >> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> >>> Signed-off-by: Eugene Lyapustin 
> >>> ---
> >>>  doc/filters.texi |  137 +++
> >>>  libavfilter/Makefile |1 +
> >>>  libavfilter/allfilters.c |1 +
> >>>  libavfilter/vf_vr360.c   | 1847 ++
> >>
> >>
> >>> +AVFilter ff_vf_vr360 = {
> >>> +.name  = "vr360",
> >>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
> >> video."),
> >>
> >> "vr360" does not make any sense to me. VR and 360 degree are two
> different
> >> things.
> >>
> >> And since VR-related filters may very well emerge in the future, we
> should
> >> be as clear as possible about these.
> >>
> >
> > Isnt VR just 360 but for each eye?
>
> That would be stereoscopic 360.
>
> What makes it VR is that the camera can move within space, not only change
> viewing direction.
>

Ah, than vr360 stands for Video processoR 360.
What name should be instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Thilo Borgmann]

Am 05.08.19 um 21:02 schrieb Michael Niedermayer:
> On Mon, Aug 05, 2019 at 08:48:03PM +0200, Thilo Borgmann wrote:
>> Am 05.08.19 um 17:57 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
>>> wrote:
>>>
 On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
 
> wrote:
>
>> On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
 From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
 Behalf
 Of Michael Niedermayer
 Sent: Monday, August 5, 2019 3:45 AM
 To: FFmpeg development discussions and patches
 
 Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

 On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> 
> wrote:
>
>> Hi all
>>
>> It seems we do not have a list of people volunteering to do
 uploads
>> to samples. And no place to send such requests to except here,
>> where
>> they sometimes get ignored.
>>
>
> Just give everyone with push access right to upload.

 Upload currently requires an account on the server, giving
 everyone an
 account is a security risk.
 It also doesnt really make sense to give someone access who doesnt
 need
 access.
 If someone wants to take care of uploads (s)he can have access.

 Of course if theres a majority wanting everyone with push access to
>> have an
 account on the server, sure we will do that but i dont think its a
>> good idea.
 IMHO its always better (aka more secure) if access is kept at a
>> minimum.

 besides, it would be a bit of work to keep the list of who has push
>> access and
 who has sampeles access synchronized. Its different servers and
>> different
 types of "accounts"
 and the whole point from my point of view is that id like to spend
 my
>> time on
 other areas on FFmpeg While keeping accounts synchronized would be
 probably more work than doing the uploads myself

 Thanks
>>>
>>
>>> My suggestions would be:
>>> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
>> how to apply and update the FATE MAINTAINERS list.
>>
>> Iam not sure if there is someone, but if so (s)he should send an email
 to
>> root or to ffmpeg-devel (again in case he did long ago already)
>>
>
> You are not sure that you gave someone upload access to fate samples?
> Perhaps you forgot?

 iam not sure if someone volunteered and did not receive access as at a
 similar time other people suggested that the existing people with access
 could handle it and no new uploaders where needed.

 So yeah, short form: i forgot the name from an email months or years ago.


>>> Can you check now who have access?
>>
>> Would it make sense to create a samp...@ffmpeg.org address and put the 
>> people in charge behind that address?
> 
> samp...@ffmpeg.org already exists and some daily debug messages from cronjobs
> end there. I am reluctant to just add people to this as they have not
> agreed to receive such cronjob "spam"
> but i can trivially add anyone who wants to be added
> or create a different alias with everyone who has currently access

If it already exists, we need another name for it as it is not for the server 
side of things but to give the user a common and hopefully static place to send 
requests to... sampleupload@, samples-request@... whatever but both might 
independently change, especially the debug alias.

>>
>> How much work does one expect from that? Do we upload several a day?
> 
> uploads to fate are relativly rare counting them "per month" would make
> more sense than per day

So that means we should be quite safe finding two volunteers for that.


>>
>> I would volunteer to take at least part of the burden.
> 
> thanks

-Thilo

___
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] avfilter: add vr360 filter

[Thilo Borgmann]

Am 05.08.19 um 21:07 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 21:00 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
>>> wrote:
>>>
 Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> Signed-off-by: Eugene Lyapustin 
> ---
>  doc/filters.texi |  137 +++
>  libavfilter/Makefile |1 +
>  libavfilter/allfilters.c |1 +
>  libavfilter/vf_vr360.c   | 1847 ++


> +AVFilter ff_vf_vr360 = {
> +.name  = "vr360",
> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
 video."),

 "vr360" does not make any sense to me. VR and 360 degree are two
>> different
 things.

 And since VR-related filters may very well emerge in the future, we
>> should
 be as clear as possible about these.

>>>
>>> Isnt VR just 360 but for each eye?
>>
>> That would be stereoscopic 360.
>>
>> What makes it VR is that the camera can move within space, not only change
>> viewing direction.
>>
> 
> Ah, than vr360 stands for Video processoR 360.
> What name should be instead?

"mono360" could make sense if a "stereo360" would process two inputs (that are 
not L-R or T-B coded)

Or just "video360"... but we really should save us "vr" for the future.

-Thilo
___
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] avfilter: add vr360 filter

[Paul B Mahol]

On Mon, Aug 5, 2019 at 9:12 PM Thilo Borgmann 
wrote:

> Am 05.08.19 um 21:07 schrieb Paul B Mahol:
> > On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
> > wrote:
> >
> >> Am 05.08.19 um 21:00 schrieb Paul B Mahol:
> >>> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
> >>> wrote:
> >>>
>  Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> > Signed-off-by: Eugene Lyapustin 
> > ---
> >  doc/filters.texi |  137 +++
> >  libavfilter/Makefile |1 +
> >  libavfilter/allfilters.c |1 +
> >  libavfilter/vf_vr360.c   | 1847
> ++
> 
> 
> > +AVFilter ff_vf_vr360 = {
> > +.name  = "vr360",
> > +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>  video."),
> 
>  "vr360" does not make any sense to me. VR and 360 degree are two
> >> different
>  things.
> 
>  And since VR-related filters may very well emerge in the future, we
> >> should
>  be as clear as possible about these.
> 
> >>>
> >>> Isnt VR just 360 but for each eye?
> >>
> >> That would be stereoscopic 360.
> >>
> >> What makes it VR is that the camera can move within space, not only
> change
> >> viewing direction.
> >>
> >
> > Ah, than vr360 stands for Video processoR 360.
> > What name should be instead?
>
> "mono360" could make sense if a "stereo360" would process two inputs (that
> are not L-R or T-B coded)
>
> Or just "video360"... but we really should save us "vr" for the future.
>

v360 then?
___
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] avfilter: add vr360 filter

[Thilo Borgmann]

Am 05.08.19 um 21:16 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 9:12 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 21:07 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
>>> wrote:
>>>
 Am 05.08.19 um 21:00 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
> wrote:
>
>> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
>>> Signed-off-by: Eugene Lyapustin 
>>> ---
>>>  doc/filters.texi |  137 +++
>>>  libavfilter/Makefile |1 +
>>>  libavfilter/allfilters.c |1 +
>>>  libavfilter/vf_vr360.c   | 1847
>> ++
>>
>>
>>> +AVFilter ff_vf_vr360 = {
>>> +.name  = "vr360",
>>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>> video."),
>>
>> "vr360" does not make any sense to me. VR and 360 degree are two
 different
>> things.
>>
>> And since VR-related filters may very well emerge in the future, we
 should
>> be as clear as possible about these.
>>
>
> Isnt VR just 360 but for each eye?

 That would be stereoscopic 360.

 What makes it VR is that the camera can move within space, not only
>> change
 viewing direction.

>>>
>>> Ah, than vr360 stands for Video processoR 360.
>>> What name should be instead?
>>
>> "mono360" could make sense if a "stereo360" would process two inputs (that
>> are not L-R or T-B coded)
>>
>> Or just "video360"... but we really should save us "vr" for the future.
>>
> 
> v360 then?

Works for me.

-Thilo
___
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] Extract QP from h264 encoded videos

[Juan De León]

On Sat, Aug 3, 2019 at 12:15 PM Michael Niedermayer 
wrote:

> > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
> codec_id, int index)
> > +{
> > +switch (codec_id) {
> > +case AV_EXTRACT_QP_CODEC_ID_H264:
> > +return index < AV_QP_ARR_SIZE_H264 ? QP_NAMES_H264[index]
> :NULL;
> > +case AV_EXTRACT_QP_CODEC_ID_VP9:
> > +return index < AV_QP_ARR_SIZE_VP9  ? QP_NAMES_VP9[index]
> :NULL;
> > +case AV_EXTRACT_QP_CODEC_ID_AV1:
> > +return index < AV_QP_ARR_SIZE_AV1  ? QP_NAMES_AV1[index]
> :NULL;
> > +default:
> > +return NULL;
> > +}
> > +}
>
> index is checked for being too large but not for too small ( < 0 )
> not sure that is intended
>
Added a check for (index < 0) to return NULL before the switch, will submit
in new patch.


On Sat, Aug 3, 2019 at 12:36 PM Michael Niedermayer 
wrote:

> > +if (h->avctx->debug & FF_DEBUG_EXTRACTQP) {
> > +int mb_height = h->height / 16;
> > +int mb_width = h->width / 16;
>
> has this been tested with files which have dimensions not a multiple of 16
> ?
>
Yes, tested with a 640x360 video, width and height here correspond to the
coded dimension, which are always multiples of 16 so I believe this should
not be a problem.
typedef struct H264Context

{
...

/* coded dimensions -- 16 * mb w/h */int width
,
height 
;
   ...

> +if (!sd) {
> > +return AVERROR(ENOMEM);
>
> buffer leaks here
>
I updated it to allocate an array of AVQuantizationParams in the side data
so that it can all be freed with a single call. I will submit the new patch
when the patch for libavutil is approved.


On Sat, Aug 3, 2019 at 12:45 PM Michael Niedermayer 
wrote:

>  +int qp_type[AV_QP_ARR_SIZE_AV1];

What happens if a future codec needs more than AV1 ?
> i think this would not be extendible without breaking ABI

Would a macro for largest size be better in this case? I will make that
change in a new patch also.
___
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] Extract QP from h264 encoded videos

[Juan De León]

AVQuantizationParams data structure for extracting qp and storing as 
AV_FRAME_DATA_QUANTIZATION_PARAMS AVFrameSideDataType
design doc: 
https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing

Signed-off-by: Juan De León 
---
 libavutil/Makefile  |   2 +
 libavutil/frame.h   |   6 ++
 libavutil/quantization_params.c |  83 
 libavutil/quantization_params.h | 110 
 4 files changed, 201 insertions(+)
 create mode 100644 libavutil/quantization_params.c
 create mode 100644 libavutil/quantization_params.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 8a7a44e4b5..be1a9c3a9c 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -60,6 +60,7 @@ HEADERS = adler32.h   
  \
   pixdesc.h \
   pixelutils.h  \
   pixfmt.h  \
+  quantization_params.h \
   random_seed.h \
   rc4.h \
   rational.h\
@@ -140,6 +141,7 @@ OBJS = adler32.o
\
parseutils.o \
pixdesc.o\
pixelutils.o \
+   quantization_params.o\
random_seed.o\
rational.o   \
reverse.o\
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 5d3231e7bb..b64fd9c02c 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -179,6 +179,12 @@ enum AVFrameSideDataType {
  * array element is implied by AVFrameSideData.size / 
AVRegionOfInterest.self_size.
  */
 AV_FRAME_DATA_REGIONS_OF_INTEREST,
+/**
+ * To extract quantization parameters from supported decoders.
+ * The data is stored as AVQuantizationParamsArray type, described in
+ * libavuitl/quantization_params.h
+ */
+AV_FRAME_DATA_QUANTIZATION_PARAMS,
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/quantization_params.c b/libavutil/quantization_params.c
new file mode 100644
index 00..d0aff7b35a
--- /dev/null
+++ b/libavutil/quantization_params.c
@@ -0,0 +1,83 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include 
+
+#include "libavutil/quantization_params.h"
+
+/**
+ * Strings describing the corresponding qp_type for each of the enums
+ * listed in libavutil/quantization_params.h
+ * Used for logging.
+ */
+
+static const char* const QP_NAMES_H264[] = {  // enum 
AVQPArrIndexesH264:
+"qp", // AV_QP_Y_H264
+"qpcb",   // AV_QP_U_H264
+"qpcr"// AV_QP_V_H264
+};
+
+static const char* const QP_NAMES_VP9[] = {   // enum 
AVQPArrIndexesVP9:
+   "qyac",// AV_QP_YAC_VP9
+   "qydc",// AV_QP_YDC_VP9
+   "quvdc",   // AV_QP_UVDC_VP9
+   "quvac",   // AV_QP_UVAC_VP9
+   "qiyac",   // AV_QP_INDEX_YAC_VP9
+   "qiydc",   // AV_QP_INDEX_YDC_VP9
+   "qiuvdc",  // AV_QP_INDEX_UVDC_VP9
+   "qiuvac"   // AV_QP_INDEX_UVAC_VP9
+   };
+
+static const char* const QP_NAMES_AV1[] = {  // enum AVQPArrIndexesAV1:
+  

[FFmpeg-devel] [PATCH] configure: cuda_llvm: fix include path for MSYS2

[Ricardo Constantino]

MSYS2 converts paths to MinGW-based applications from unix to
pseudo-windows paths on execution time.
Since there was no space between '-include' and the path, MSYS2 doesn't
detect the path properly.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index bddc05b850..34c2adb4a4 100755
--- a/configure
+++ b/configure
@@ -6094,7 +6094,7 @@ fi
 if enabled cuda_nvcc; then
 nvccflags="$nvccflags -ptx"
 else
-nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only 
-include${source_link}/compat/cuda/cuda_runtime.h"
+nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only -include 
${source_link}/compat/cuda/cuda_runtime.h"
 check_nvcc cuda_llvm
 fi
 
-- 
2.22.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] [RFC] samples.ffmpeg.org

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 09:09:36PM +0200, Thilo Borgmann wrote:
> Am 05.08.19 um 21:02 schrieb Michael Niedermayer:
> > On Mon, Aug 05, 2019 at 08:48:03PM +0200, Thilo Borgmann wrote:
> >> Am 05.08.19 um 17:57 schrieb Paul B Mahol:
> >>> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
> >>> 
> >>> wrote:
> >>>
>  On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
> > On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
>  
> > wrote:
> >
> >> On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
>  From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>  Behalf
>  Of Michael Niedermayer
>  Sent: Monday, August 5, 2019 3:45 AM
>  To: FFmpeg development discussions and patches
>  
>  Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> 
>  On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
> > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
> > 
> > wrote:
> >
> >> Hi all
> >>
> >> It seems we do not have a list of people volunteering to do
>  uploads
> >> to samples. And no place to send such requests to except here,
> >> where
> >> they sometimes get ignored.
> >>
> >
> > Just give everyone with push access right to upload.
> 
>  Upload currently requires an account on the server, giving
>  everyone an
>  account is a security risk.
>  It also doesnt really make sense to give someone access who doesnt
>  need
>  access.
>  If someone wants to take care of uploads (s)he can have access.
> 
>  Of course if theres a majority wanting everyone with push access to
> >> have an
>  account on the server, sure we will do that but i dont think its a
> >> good idea.
>  IMHO its always better (aka more secure) if access is kept at a
> >> minimum.
> 
>  besides, it would be a bit of work to keep the list of who has push
> >> access and
>  who has sampeles access synchronized. Its different servers and
> >> different
>  types of "accounts"
>  and the whole point from my point of view is that id like to spend
>  my
> >> time on
>  other areas on FFmpeg While keeping accounts synchronized would be
>  probably more work than doing the uploads myself
> 
>  Thanks
> >>>
> >>
> >>> My suggestions would be:
> >>> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
> >> how to apply and update the FATE MAINTAINERS list.
> >>
> >> Iam not sure if there is someone, but if so (s)he should send an email
>  to
> >> root or to ffmpeg-devel (again in case he did long ago already)
> >>
> >
> > You are not sure that you gave someone upload access to fate samples?
> > Perhaps you forgot?
> 
>  iam not sure if someone volunteered and did not receive access as at a
>  similar time other people suggested that the existing people with access
>  could handle it and no new uploaders where needed.
> 
>  So yeah, short form: i forgot the name from an email months or years ago.
> 
> 
> >>> Can you check now who have access?
> >>
> >> Would it make sense to create a samp...@ffmpeg.org address and put the 
> >> people in charge behind that address?
> > 
> > samp...@ffmpeg.org already exists and some daily debug messages from 
> > cronjobs
> > end there. I am reluctant to just add people to this as they have not
> > agreed to receive such cronjob "spam"
> > but i can trivially add anyone who wants to be added
> > or create a different alias with everyone who has currently access
> 
> If it already exists, we need another name for it as it is not for the server 
> side of things but to give the user a common and hopefully static place to 
> send requests to... sampleupload@, samples-request@... whatever but both 
> might independently change, especially the debug alias.

created samples-request@... as its not just about uploads, but could also be
about other changes.

note though, people who do not have a .forward in their home directory will
receive the mail locally on the server and not get it send to their email.
So make sure you set that up for yourself before testing.
also ping me on IRC if it doesnt work

[...]

thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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] configure: cuda_llvm: fix include path for MSYS2

[Timo Rothenpieler]

On 05.08.2019 21:47, Ricardo Constantino wrote:

MSYS2 converts paths to MinGW-based applications from unix to
pseudo-windows paths on execution time.
Since there was no space between '-include' and the path, MSYS2 doesn't
detect the path properly.
---
  configure | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index bddc05b850..34c2adb4a4 100755
--- a/configure
+++ b/configure
@@ -6094,7 +6094,7 @@ fi
  if enabled cuda_nvcc; then
  nvccflags="$nvccflags -ptx"
  else
-nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only 
-include${source_link}/compat/cuda/cuda_runtime.h"
+nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only -include 
${source_link}/compat/cuda/cuda_runtime.h"
  check_nvcc cuda_llvm
  fi
  



Are you sure this is necessary? source_link only ever points to either . 
or src, and I don't see why msys2 would need to fix that, since it's a 
relative path.




smime.p7s
Description: S/MIME Cryptographic 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] Extract QP from h264 encoded videos

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 12:16:08PM -0700, Juan De León wrote:
> On Sat, Aug 3, 2019 at 12:15 PM Michael Niedermayer 
> wrote:
> 
> > > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
> > codec_id, int index)
> > > +{
> > > +switch (codec_id) {
> > > +case AV_EXTRACT_QP_CODEC_ID_H264:
> > > +return index < AV_QP_ARR_SIZE_H264 ? QP_NAMES_H264[index]
> > :NULL;
> > > +case AV_EXTRACT_QP_CODEC_ID_VP9:
> > > +return index < AV_QP_ARR_SIZE_VP9  ? QP_NAMES_VP9[index]
> > :NULL;
> > > +case AV_EXTRACT_QP_CODEC_ID_AV1:
> > > +return index < AV_QP_ARR_SIZE_AV1  ? QP_NAMES_AV1[index]
> > :NULL;
> > > +default:
> > > +return NULL;
> > > +}
> > > +}
> >
> > index is checked for being too large but not for too small ( < 0 )
> > not sure that is intended
> >
> Added a check for (index < 0) to return NULL before the switch, will submit
> in new patch.
> 
> 
> On Sat, Aug 3, 2019 at 12:36 PM Michael Niedermayer 
> wrote:
> 
> > > +if (h->avctx->debug & FF_DEBUG_EXTRACTQP) {
> > > +int mb_height = h->height / 16;
> > > +int mb_width = h->width / 16;
> >
> > has this been tested with files which have dimensions not a multiple of 16
> > ?
> >
> Yes, tested with a 640x360 video, width and height here correspond to the
> coded dimension, which are always multiples of 16 so I believe this should
> not be a problem.
> typedef struct H264Context
> 
> {
> ...
> 
> /* coded dimensions -- 16 * mb w/h */int width
> ,
> height 
> ;
>...
> 
> > +if (!sd) {
> > > +return AVERROR(ENOMEM);
> >
> > buffer leaks here
> >
> I updated it to allocate an array of AVQuantizationParams in the side data
> so that it can all be freed with a single call. I will submit the new patch
> when the patch for libavutil is approved.
> 
> 
> On Sat, Aug 3, 2019 at 12:45 PM Michael Niedermayer 
> wrote:
> 
> >  +int qp_type[AV_QP_ARR_SIZE_AV1];
> 
> What happens if a future codec needs more than AV1 ?

> > i think this would not be extendible without breaking ABI
> 
> Would a macro for largest size be better in this case? I will make that
> change in a new patch also.

a macro would still require a major version bump as its a ABI change, if
it changes.
To fix this would probably require a deeper change, we could also
of course just leave it and accept that as the maximum till the next
ABI major bump

thanks
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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 v3] avcodec/vaapi_encode_h264: add support for a/53 closed caption sei

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 10:58:43AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Signed-off-by: Aman Gupta 
> ---
>  libavcodec/vaapi_encode_h264.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index f4965d8b09..280bd4752b 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -39,6 +39,7 @@ enum {
>  SEI_TIMING = 0x01,
>  SEI_IDENTIFIER = 0x02,
>  SEI_RECOVERY_POINT = 0x04,
> +SEI_A53_CC = 0x08,
>  };
>  
>  // Random (version 4) ISO 11578 UUID.
> @@ -72,6 +73,7 @@ typedef struct VAAPIEncodeH264Context {
>  int sei;
>  int profile;
>  int level;
> +bool enable_a53_cc;

does not build

make
CC  libavcodec/vaapi_encode_h264.o
libavcodec/vaapi_encode_h264.c:76:5: error: unknown type name ‘bool’
 bool enable_a53_cc;
 ^
make: *** [libavcodec/vaapi_encode_h264.o] Error 1


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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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 V2 2/2] lavf/showinfo: use error level when get invalid sidedata

[Michael Niedermayer]

On Mon, Aug 05, 2019 at 06:39:21PM +0800, Jun Zhao wrote:
> From: Jun Zhao 
> 
> Use error level when get invalid sidedata, and remove a unnecessary
> newline in error message.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_showinfo.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)

should be ok

thx


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

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


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

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

Re: [FFmpeg-devel] [PATCH] configure: cuda_llvm: fix include path for MSYS2

[Ricardo Constantino]

On Mon, 5 Aug 2019 at 20:57, Timo Rothenpieler 
wrote:

> On 05.08.2019 21:47, Ricardo Constantino wrote:
> > MSYS2 converts paths to MinGW-based applications from unix to
> > pseudo-windows paths on execution time.
> > Since there was no space between '-include' and the path, MSYS2 doesn't
> > detect the path properly.
> > ---
> >   configure | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index bddc05b850..34c2adb4a4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6094,7 +6094,7 @@ fi
> >   if enabled cuda_nvcc; then
> >   nvccflags="$nvccflags -ptx"
> >   else
> > -nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
> -include${source_link}/compat/cuda/cuda_runtime.h"
> > +nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
> -include ${source_link}/compat/cuda/cuda_runtime.h"
> >   check_nvcc cuda_llvm
> >   fi
> >
> >
>
> Are you sure this is necessary? source_link only ever points to either .
> or src, and I don't see why msys2 would need to fix that, since it's a
> relative path.
>

Except symbolic links may not be enabled in MSYS2, so source_link is the
same thing as source_path.
In the case of MSYS2, it would look something like
-include/home/ricardo/ffmpeg and MinGW clang expects it to be converted to
C:\msys64\home\ricardo\ffmpeg, which it doesn't, if there's no space after
-include.


> ___
> 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] configure: cuda_llvm: fix include path for MSYS2

[Ricardo Constantino]

On Mon, 5 Aug 2019 at 21:46, Ricardo Constantino  wrote:

>
>
> On Mon, 5 Aug 2019 at 20:57, Timo Rothenpieler 
> wrote:
>
>> On 05.08.2019 21:47, Ricardo Constantino wrote:
>> > MSYS2 converts paths to MinGW-based applications from unix to
>> > pseudo-windows paths on execution time.
>> > Since there was no space between '-include' and the path, MSYS2 doesn't
>> > detect the path properly.
>> > ---
>> >   configure | 2 +-
>> >   1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/configure b/configure
>> > index bddc05b850..34c2adb4a4 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -6094,7 +6094,7 @@ fi
>> >   if enabled cuda_nvcc; then
>> >   nvccflags="$nvccflags -ptx"
>> >   else
>> > -nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
>> -include${source_link}/compat/cuda/cuda_runtime.h"
>> > +nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
>> -include ${source_link}/compat/cuda/cuda_runtime.h"
>> >   check_nvcc cuda_llvm
>> >   fi
>> >
>> >
>>
>> Are you sure this is necessary? source_link only ever points to either .
>> or src, and I don't see why msys2 would need to fix that, since it's a
>> relative path.
>>
>
> Except symbolic links may not be enabled in MSYS2, so source_link is the
> same thing as source_path.
> In the case of MSYS2, it would look something like
> -include/home/ricardo/ffmpeg and MinGW clang expects it to be converted to
> C:\msys64\home\ricardo\ffmpeg, which it doesn't, if there's no space after
> -include.
>

That's why using source_path still wouldn't fix it, btw. I have tested that
possibility.


>
>> ___
>> 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 1/3] avformat/avio: add avio_print_n_strings and avio_print

[Marton Balint]

These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporery buffer is necessary.

Signed-off-by: Marton Balint 
---
 doc/APIchanges|  3 +++
 libavformat/avio.h| 16 
 libavformat/aviobuf.c | 17 +
 libavformat/version.h |  2 +-
 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..0b19fb067d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2019-08-xx - xx - lavf 58.31.100 - avio.h
+  Add avio_print_n_strings and avio_print.
+
 2019-07-27 - xx - lavu 56.33.100 - tx.h
   Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index dcb8dcdf93..ca08907917 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -574,6 +574,22 @@ int avio_feof(AVIOContext *s);
 /** @warning Writes up to 4 KiB per call */
 int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
 
+/**
+ * Write nb_strings number of strings (const char *) to the context.
+ * @return the total number of bytes written
+ */
+int avio_print_n_strings(AVIOContext *s, int nb_strings, ...);
+
+/**
+ * Write strings (const char *) to the context.
+ * This is a macro around avio_print_n_strings but the number of strings to be
+ * written is determined automatically at compile time based on the number of
+ * parameters passed to this macro. For simple string concatenations this
+ * function is more performant than using avio_printf.
+ */
+#define avio_print(s, ...) \
+avio_print_n_strings(s, sizeof((const char*[]){__VA_ARGS__}) / 
sizeof(const char*), __VA_ARGS__)
+
 /**
  * Force flushing of buffered data.
  *
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2d011027c9..c37b056b64 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1225,6 +1225,23 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
 return ret;
 }
 
+int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
+{
+va_list ap;
+int ret = 0;
+
+va_start(ap, nb_strings);
+for (int i = 0; i < nb_strings; i++) {
+const char *str = va_arg(ap, const char *);
+int len = strlen(str);
+avio_write(s, (const unsigned char *)str, len);
+ret += len;
+}
+va_end(ap);
+
+return ret;
+}
+
 int avio_pause(AVIOContext *s, int pause)
 {
 if (!s->read_pause)
diff --git a/libavformat/version.h b/libavformat/version.h
index 45efaff9b9..feceaedc08 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  30
+#define LIBAVFORMAT_VERSION_MINOR  31
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.16.4

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

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

[FFmpeg-devel] [PATCH 3/3] avformat/avio: remove 4k limit from avio_printf

[Marton Balint]

We do this by switching to AVBPrint.

Signed-off-by: Marton Balint 
---
 doc/APIchanges|  3 +++
 libavformat/avio.h|  5 -
 libavformat/aviobuf.c | 15 ++-
 libavformat/version.h |  2 +-
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 0b19fb067d..fe36c34b90 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2019-08-xx - xx - lavf 58.31.101 - avio.h
+  4K limit removed from avio_printf.
+
 2019-08-xx - xx - lavf 58.31.100 - avio.h
   Add avio_print_n_strings and avio_print.
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index ca08907917..f2051da18d 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -571,7 +571,10 @@ int64_t avio_size(AVIOContext *s);
  */
 int avio_feof(AVIOContext *s);
 
-/** @warning Writes up to 4 KiB per call */
+/**
+ * Writes a formatted string to the context.
+ * @return number of bytes written, < 0 on error.
+ */
 int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
 
 /**
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index c37b056b64..007fba6410 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1215,14 +1215,19 @@ int avio_closep(AVIOContext **s)
 int avio_printf(AVIOContext *s, const char *fmt, ...)
 {
 va_list ap;
-char buf[4096]; /* update doc entry in avio.h if changed */
-int ret;
+AVBPrint bp;
 
+av_bprint_init(&bp, 0, INT_MAX);
 va_start(ap, fmt);
-ret = vsnprintf(buf, sizeof(buf), fmt, ap);
+av_vbprintf(&bp, fmt, ap);
 va_end(ap);
-avio_write(s, buf, strlen(buf));
-return ret;
+if (!av_bprint_is_complete(&bp)) {
+av_bprint_finalize(&bp, NULL);
+return AVERROR(ENOMEM);
+}
+avio_write(s, bp.str, bp.len);
+av_bprint_finalize(&bp, NULL);
+return bp.len;
 }
 
 int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
diff --git a/libavformat/version.h b/libavformat/version.h
index feceaedc08..9814db8633 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR  31
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
2.16.4

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

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

[FFmpeg-devel] [PATCH 2/3] avformat/assenc: optimize writing dialogs

[Marton Balint]

An example where the preivously added API can be useful.

Also fixes ticket #6390.

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

diff --git a/libavformat/assenc.c b/libavformat/assenc.c
index d50f18feb1..12aadca171 100644
--- a/libavformat/assenc.c
+++ b/libavformat/assenc.c
@@ -95,7 +95,7 @@ static void purge_dialogues(AVFormatContext *s, int force)
ass->expected_readorder, dialogue->readorder);
 ass->expected_readorder = dialogue->readorder;
 }
-avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line);
+avio_print(s->pb, "Dialogue: ", dialogue->line, "\r\n");
 if (dialogue == ass->last_added_dialogue)
 ass->last_added_dialogue = next;
 av_freep(&dialogue->line);
-- 
2.16.4

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

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

Re: [FFmpeg-devel] FFmpeg 4.2

[Michael Niedermayer]

On Sun, Aug 04, 2019 at 07:56:00AM +0200, Michael Niedermayer wrote:
> On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote:
> > On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > Its quite some time since 4.1 so its probably getting time to branch
> > > 4.2.
> > > 
> > > If there are any bugs you want fixed in 4.2 its probably a good idea to
> > > fix them soon.
> > > 
> > > Are there any suggestions for a name ?
> > > If not ill pick something from unused past suggestions.
> > > 
> > > If there are no objections i will likely make that release in the next 
> > > weeks
> > 
> > 4.2 branch made
> > i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 
> > weeks
> > please backport any relevant bugfixes to it.
> 
> Status update: There are a few remaining crashes / security issues which i 
> think
> we should fix and include before the release. Iam working on that currently.
> 
> When thats done depends on 
> 1. any delays (bikesheds, distractions, headaches, good weather that makes me 
> ignore
>this and go for a walk or maybe going for a walk occasionally actually 
> helps 
>my efficiency who knows, ...)
> 2. influx of more security reports (fuzzer and any human reports), there where
>several new reports in the last 2 weeks which fall in the "I think that 
> should
>be fixed before the release" category
> 3. murphies law and anything else unexpected

4.2 release made

4.2.1 will be made in a few weeks (sooner if theres something important) 
  please backport any relevant bugfixes

4.3 will be targeted in 5 month and will realistically occur around 6 month 
from now

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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] FFmpeg 4.2

[Thomas Volkert]

Hi,

On 05.08.2019 23:49, Michael Niedermayer wrote:
> 4.2 release made

Thanks - shared on Facebook.


Best regards,
Thomas.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: fix PCR generation intervals

[Marton Balint]

On Mon, 5 Aug 2019, Andreas Håkon wrote:


Hi Marton,


‐‐‐ Original Message ‐‐‐
On Sunday, 4 de August de 2019 22:30, Marton Balint  wrote:


PCR generation was based on counting packets for both CBR and VBR streams.
Couting packets might have worked for CBR streams (when muxrate was specified)
but it only took into account the packets of a service (or the packets of the
PCR stream lately), so even that was problematic for multi program streams.

The new code works on actual PCR for CBR and packet DTS values for VBR streams,
so the default 20ms PCR retransmission time is now respected for both CBR and
VBR.



I do some tests with this patch and the previous 
https://patchwork.ffmpeg.org/patch/14210/

And the result is that the repetition rate of PCR is inconsistent: it's never
constant and varies between different PCR streams.


Are you testing CRB or VBR? For VBR you get PCR at the start of every 
packet with the command line you provided, so PCR interval should be 
constant. DVB Inspector always shows the streams as if they were CBR, so 
the PCR/PTS/DTS view is not showing the intervals properly for VBR.



+int64_t pcr = -1; /* avoid warning */
+
 retransmit_si_info(s, force_pat, dts);
 force_pat = 0;

 write_pcr = 0;
-if (ts_st->pcr_packet_period) {
-if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
frames
-ts_st->pcr_packet_count++;
-if (ts_st->pcr_packet_count >=
-ts_st->pcr_packet_period) {
-ts_st->pcr_packet_count = 0;
-write_pcr = 1;
+if (ts_st->pcr_period) {
+if (ts->mux_rate > 1) {
+pcr = get_pcr(ts, s->pb);
+if (pcr - ts_st->last_pcr >= ts_st->pcr_period)
+write_pcr = 1;
+} else if (dts != AV_NOPTS_VALUE) {
+pcr = (dts - delay) * 300;
+if (pcr - ts_st->last_pcr >= ts_st->pcr_period && is_start)
+write_pcr = 1;
 }
+if (write_pcr)
+ts_st->last_pcr = FFMAX(pcr - ts_st->pcr_period, ts_st->last_pcr 
+ ts_st->pcr_period);
 }


IMHO, here you return to make the same mistake of the previous code:
only consider one PCR stream. Instead of the "if (ts_st->pcr_period)" it's
required to iterate over all PCR streams and do the corresponding checks.
And if some PCR stream has exceeded the pcr_period limit then enforce to
write an empty TS packet with a PCR mark.


For CBR, I agree, even if the extra PCR packets increase the bitrate 
slightly. I can try implementing this.


I am not sure what are we trying to achieve for VBR though. Since you 
don't know the bitrate you can't sensibly calculate PCR for non-start 
packets. So I believe for VBR the code works as it is supposed to.


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