Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

[Christophe Gisquet]

Hi,

2015-09-26 1:52 GMT+02:00 Michael Niedermayer :
> This segfaults with 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov

Can't reproduce with frame or slice threading or no threading. What
was the command-line?

> #3  0x00af53fd in avcodec_default_execute2 (c=0x1ce34e0, func=0x7470e6
[...]
> #6  0x00a3bc76 in frame_worker_thread (arg=0x1ce2198) at 
> libavcodec/pthread_frame.c:154

Indicates maybe frame+slice, but that brings me to the point: why is
it crashing at all? Is it something that should be avoidable through
my code?

It seems I should just avoid running the slice-threading code in the
frame threading case.

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

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[Anshul]

On 09/26/2015 05:46 AM, DeHackEd wrote:

Assumes 'GA94' format (ATSC standard)

Signed-off-by: DHE 
---
  doc/encoders.texi|  5 +
  libavcodec/libx264.c | 37 +
  2 files changed, 42 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..bb16dea 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with 
@command{ffmpeg}:
  ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
  @end example

+@item a53cc
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
+
+
  @item x264-params (N.A.)
  Override the x264 configuration using a :-separated list of key=value
  parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..4227bcc 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
  int avcintra_class;
  int motion_est;
  int forced_idr;
+int a53_cc;
  char *x264_params;
  } X264Context;

@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
  int nnal, i, ret;
  x264_picture_t pic_out = {0};
  int pict_type;
+AVFrameSideData *side_data;

  x264_picture_init( >pic );
  x4->pic.img.i_csp   = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
  X264_TYPE_AUTO;

  reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads = 
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[0].payload_size = side_data->size + 
11;
+x4->pic.extra_sei.payloads[0].payload = 
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
+x4->pic.extra_sei.payloads[0].payload_type = 4;
+memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
side_data->data, side_data->size);
+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, but hard 
coding
+ * this style may not be the right thing to do -- other formats
+ * do exist. This information is not available in the side_data
+ * so we are going with this right now.
+ */
I think GA94 is correct for this situation, since in our x264 decoder we 
don't consider any other standard

for extracting closed caption.

I don't know if we have any logic which differentiate between ATSC, ISDB 
or DVB we parse all transport stream
in same manner. if someone know where we differentiate atsc and dvb in 
FFmpeg please point me there.


Note: This logic will also fail when x264 is muxed in formats like gxf 
where closed caption are kept in vbi instead

of GA94.

Overall  LGTM.

I don't know how to apply encrypted mails using git, and when I save 
your email in Thunderbird, git am is unable to apply.
if you can send the same patch as attachment or command to convert 
encrypted .eml file to normal patch I would test this too.


-Anshul


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

Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 08:33:26AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2015-09-26 1:52 GMT+02:00 Michael Niedermayer :
> > This segfaults with 
> > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov
> 
> Can't reproduce with frame or slice threading or no threading. What
> was the command-line?

very basic "./ffmpeg -i inputfile -f null -" IIRC
but it did not crash on every run

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add maskedmerge filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  15 ++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_maskedmerge.c | 324 +++
 4 files changed, 341 insertions(+)
 create mode 100644 libavfilter/vf_maskedmerge.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 044876c..e4a80cd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7624,6 +7624,21 @@ lutyuv=y='bitand(val, 128+64+32)'
 @end example
 @end itemize
 
+@section maskedmerge
+
+Merge first input stream with second input stream using per pixel weights in
+the third input stream. 0 means that pixel component from first stream is
+returned unchanged while 255 for 8-bit videos means that pixel component from
+second stream is returned unchanged.
+
+This filter accepts the following options:
+@table @option
+@item planes
+Set which planes will be processed as bitmap, unprocessed planes will be
+copied from first stream.
+By default all planes will be processed.
+@end table
+
 @section mergeplanes
 
 Merge color channel components from several video streams.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c70887e..9125443 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -169,6 +169,7 @@ OBJS-$(CONFIG_LUT3D_FILTER)  += vf_lut3d.o
 OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
 OBJS-$(CONFIG_LUTRGB_FILTER) += vf_lut.o
 OBJS-$(CONFIG_LUTYUV_FILTER) += vf_lut.o
+OBJS-$(CONFIG_MASKEDMERGE_FILTER)+= vf_maskedmerge.o framesync.o
 OBJS-$(CONFIG_MCDEINT_FILTER)+= vf_mcdeint.o
 OBJS-$(CONFIG_MERGEPLANES_FILTER)+= vf_mergeplanes.o framesync.o
 OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c21456d..612fc99 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -191,6 +191,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(LUT,lut,vf);
 REGISTER_FILTER(LUTRGB, lutrgb, vf);
 REGISTER_FILTER(LUTYUV, lutyuv, vf);
+REGISTER_FILTER(MASKEDMERGE,maskedmerge,vf);
 REGISTER_FILTER(MCDEINT,mcdeint,vf);
 REGISTER_FILTER(MERGEPLANES,mergeplanes,vf);
 REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
diff --git a/libavfilter/vf_maskedmerge.c b/libavfilter/vf_maskedmerge.c
new file mode 100644
index 000..72f9fb3
--- /dev/null
+++ b/libavfilter/vf_maskedmerge.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct MaskedMergeContext {
+const AVClass *class;
+int width[4], height[4];
+int nb_planes;
+int planes;
+int max, half, depth;
+FFFrameSync fs;
+
+void (*maskedmerge)(struct MaskedMergeContext *s, const AVFrame *base,
+const AVFrame *overlay, const AVFrame *mask, AVFrame 
*out);
+} MaskedMergeContext;
+
+#define OFFSET(x) offsetof(MaskedMergeContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption maskedmerge_options[] = {
+{ "planes", "set planes", OFFSET(planes), AV_OPT_TYPE_INT, {.i64=0xF}, 0, 
0xF, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(maskedmerge);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
+AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P, 
AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
+AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, 

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[DeHackEd]

On 09/26/2015 05:26 AM, Anshul wrote:
> 
> 
> On 09/26/2015 05:46 AM, DeHackEd wrote:
>> Assumes 'GA94' format (ATSC standard)
>>
>> Signed-off-by: DHE 
>> ---
>>   doc/encoders.texi|  5 +
>>   libavcodec/libx264.c | 37 +
>>   2 files changed, 42 insertions(+)
>>
>> diff --git a/doc/encoders.texi b/doc/encoders.texi
>> index 3550bcc..bb16dea 100644
>> --- a/doc/encoders.texi
>> +++ b/doc/encoders.texi
>> @@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with 
>> @command{ffmpeg}:
>>   ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
>> out.mkv
>>   @end example
>>
>> +@item a53cc
>> +Import closed captions (which must be ATSC compatible format) into output.
>> +Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
>> +
>> +
>>   @item x264-params (N.A.)
>>   Override the x264 configuration using a :-separated list of key=value
>>   parameters.
>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>> index 58fcfb0..4227bcc 100644
>> --- a/libavcodec/libx264.c
>> +++ b/libavcodec/libx264.c
>> @@ -83,6 +83,7 @@ typedef struct X264Context {
>>   int avcintra_class;
>>   int motion_est;
>>   int forced_idr;
>> +int a53_cc;
>>   char *x264_params;
>>   } X264Context;
>>
>> @@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket 
>> *pkt, const AVFrame *frame,
>>   int nnal, i, ret;
>>   x264_picture_t pic_out = {0};
>>   int pict_type;
>> +AVFrameSideData *side_data;
>>
>>   x264_picture_init( >pic );
>>   x4->pic.img.i_csp   = x4->params.i_csp;
>> @@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket 
>> *pkt, const AVFrame *frame,
>>   X264_TYPE_AUTO;
>>
>>   reconfig_encoder(ctx, frame);
>> +
>> +if (x4->a53_cc) {
>> +side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
>> +if (side_data) {
>> +x4->pic.extra_sei.num_payloads = 1;
>> +x4->pic.extra_sei.payloads = 
>> av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
>> +x4->pic.extra_sei.sei_free = av_free;
>> +
>> +x4->pic.extra_sei.payloads[0].payload_size = 
>> side_data->size + 11;
>> +x4->pic.extra_sei.payloads[0].payload = 
>> av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
>> +x4->pic.extra_sei.payloads[0].payload_type = 4;
>> +memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
>> side_data->data, side_data->size);
>> +x4->pic.extra_sei.payloads[0].payload[0] = 181;
>> +x4->pic.extra_sei.payloads[0].payload[1] = 0;
>> +x4->pic.extra_sei.payloads[0].payload[2] = 49;
>> +
>> +/**
>> + * 'GA94' is standard in North America for ATSC, but hard 
>> coding
>> + * this style may not be the right thing to do -- other 
>> formats
>> + * do exist. This information is not available in the 
>> side_data
>> + * so we are going with this right now.
>> + */
> I think GA94 is correct for this situation, since in our x264 decoder we 
> don't consider any other standard
> for extracting closed caption.
> 
> I don't know if we have any logic which differentiate between ATSC, ISDB or 
> DVB we parse all transport stream
> in same manner. if someone know where we differentiate atsc and dvb in FFmpeg 
> please point me there.
> 
> Note: This logic will also fail when x264 is muxed in formats like gxf where 
> closed caption are kept in vbi instead
> of GA94.
> 
> Overall  LGTM.
> 
> I don't know how to apply encrypted mails using git, and when I save your 
> email in Thunderbird, git am is unable to apply.
> if you can send the same patch as attachment or command to convert encrypted 
> .eml file to normal patch I would test this
> too.

I think the easiest solution is to grab the patch from the github repo I use:
https://github.com/DeHackEd/FFmpeg/commit/16b4c7fc2311d672e99f.patch

I think my mail client wrapped some lines. Sorry, this is my first 
patch-by-email.

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

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

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[Anshul]

On 09/26/2015 04:16 PM, Anshul wrote:



On 09/26/2015 03:57 PM, DeHackEd wrote:

On 09/26/2015 05:26 AM, Anshul wrote:


On 09/26/2015 05:46 AM, DeHackEd wrote:

Assumes 'GA94' format (ATSC standard)

Signed-off-by: DHE 
---
   doc/encoders.texi|  5 +
   libavcodec/libx264.c | 37 +
   2 files changed, 42 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..bb16dea 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding 
options with @command{ffmpeg}:
   ffmpeg -i foo.mpg -vcodec libx264 -x264opts 
keyint=123:min-keyint=20 -an out.mkv

   @end example

+@item a53cc
+Import closed captions (which must be ATSC compatible format) into 
output.

+Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
+
+
   @item x264-params (N.A.)
   Override the x264 configuration using a :-separated list of 
key=value

   parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..4227bcc 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
   int avcintra_class;
   int motion_est;
   int forced_idr;
+int a53_cc;
   char *x264_params;
   } X264Context;

@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, 
AVPacket *pkt, const AVFrame *frame,

   int nnal, i, ret;
   x264_picture_t pic_out = {0};
   int pict_type;
+AVFrameSideData *side_data;

   x264_picture_init( >pic );
   x4->pic.img.i_csp   = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, 
AVPacket *pkt, const AVFrame *frame,

X264_TYPE_AUTO;

   reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, 
AV_FRAME_DATA_A53_CC);

+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads = 
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));

+x4->pic.extra_sei.sei_free = av_free;
+
+ x4->pic.extra_sei.payloads[0].payload_size = side_data->size + 11;
+x4->pic.extra_sei.payloads[0].payload = 
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);

+ x4->pic.extra_sei.payloads[0].payload_type = 4;
+ memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
side_data->data, side_data->size);

+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, 
but hard coding
+ * this style may not be the right thing to do -- 
other formats
+ * do exist. This information is not available in 
the side_data

+ * so we are going with this right now.
+ */
I think GA94 is correct for this situation, since in our x264 
decoder we don't consider any other standard

for extracting closed caption.

I don't know if we have any logic which differentiate between ATSC, 
ISDB or DVB we parse all transport stream
in same manner. if someone know where we differentiate atsc and dvb 
in FFmpeg please point me there.


Note: This logic will also fail when x264 is muxed in formats like 
gxf where closed caption are kept in vbi instead

of GA94.

Overall  LGTM.

I don't know how to apply encrypted mails using git, and when I save 
your email in Thunderbird, git am is unable to apply.
if you can send the same patch as attachment or command to convert 
encrypted .eml file to normal patch I would test this

too.
I think the easiest solution is to grab the patch from the github 
repo I use:

https://github.com/DeHackEd/FFmpeg/commit/16b4c7fc2311d672e99f.patch
anshul@linux-z9q9:~/Project/Multimedia/FFmpeg> git apply 
16b4c7fc2311d672e99f.patch

16b4c7fc2311d672e99f.patch:54: trailing whitespace.

16b4c7fc2311d672e99f.patch:75: trailing whitespace.
 */
16b4c7fc2311d672e99f.patch:81: trailing whitespace.
x4->pic.extra_sei.payloads[0].payload[8] =
warning: 3 lines add whitespace errors.
anshul@linux-z9q9:~/Project/Multimedia/FFmpeg>

Though I have fixed it at my end to test, but my advice that you fix 
it too and send another patch.



It works fine for me.

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

[FFmpeg-devel] Help to debug h264 headers (or video) generation in kernel driver

[Andrey Utkin]

I'm working on Linux kernel driver for multimedia grabber and H264
encoder based on Techwell/Intersil 5864 chip. Of course it will be
open and pushed into upstream kernel.

The device produces H264 encoded data, but it lacks any headers. The
reference driver generates headers and glues frames together in code,
but I failed both reverse-engineering and porting that code. The code
of reference driver is overwhelmingly complicated, and I have no
knowledge how H264 bitstream is formed, that's why my attempts failed.

I have reached a limited success with both setting up the hardware
encoder and forming the headers. You can see the samples of produced
video here:
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/ntsc_cif.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/ntsc_d1.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/pal_cif.h264
http://lizard.bluecherry.net/~autkin/tw5864_tiled_video/pal_d1.h264

Currently it produces "tiled" picture. The width of tiles on these
sample videos is 256 pixels.
I am not sure whether the issue is in hardware settings, or incorrect
headers which lead to partial failure of decoding.
Here is ffplay log for playing back such video:
https://gist.github.com/krieger-od/5269c762a36bcb52b93a . Obviously
some enhancements to headers generation are needed.

Playing with hardware mirroring flags proves that the raw frame gets
caught fully and correctly. But for h264 encoding, it gets garbled.
Also please notice that frame order is incorrect, the motion goes back
and forth.

You can see our latest code for this development at
https://github.com/bluecherrydvr/linux/tree/tw5864/drivers/staging/media/tw5864
(branch tw5864, subdirectory drivers/staging/media/tw5864).

Any input is extremely appreciated.

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

[FFmpeg-devel] [PATCH 1/5] dnxhddec: proper rule for interlaced mb flag

[Christophe Gisquet]

It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
---
 libavcodec/dnxhddec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 044e479..e5c5f07 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -50,6 +50,7 @@ typedef struct DNXHDContext {
 const CIDEntry *cid_table;
 int bit_depth; // 8, 10 or 0 if not initialized at all.
 int is_444;
+int mbaff;
 void (*decode_dct_block)(struct DNXHDContext *ctx, int16_t *block,
  int n, int qscale);
 int last_qscale;
@@ -144,6 +145,7 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame 
*frame,
 } else {
 ctx->cur_field = 0;
 }
+ctx->mbaff = buf[0x6] & 32;
 
 ctx->height = AV_RB16(buf + 0x18);
 ctx->width  = AV_RB16(buf + 0x1a);
@@ -183,6 +185,9 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame 
*frame,
 
 if ((ret = dnxhd_init_vlc(ctx, cid)) < 0)
 return ret;
+if (ctx->mbaff && ctx->cid_table->cid != 1260)
+av_log(ctx->avctx, AV_LOG_WARNING,
+   "Adaptive MB interlace flag in an unsupported profile.\n");
 
 // make sure profile size constraints are respected
 // DNx100 allows 1920->1440 and 1280->960 subsampling
@@ -352,7 +357,7 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx, 
AVFrame *frame,
 int qscale, i;
 int interlaced_mb = 0;
 
-if (ctx->cid_table->cid == 1260) {
+if (ctx->mbaff) {
 interlaced_mb = get_bits1(>gb);
 qscale = get_bits(>gb, 10);
 } else
-- 
2.5.2

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

[FFmpeg-devel] [PATCH 3/4] dnxhddec: proper rule for interlaced mb flag

[Christophe Gisquet]

I have reordered the patches so that they don't rely on the slice threading one.
Therefore this one should apply cleanly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] AAC encoder: tweak PNS usage to be more aggressive

[Claudio Freire]

On Fri, Sep 25, 2015 at 10:39 PM, James Almer  wrote:
>> ffmpeg | branch: master | Claudio Freire  | Fri 
>> Sep 25 03:56:32 2015 -0300| [9458a62decfcaa1313b1ba69276466de536d0768] | 
>> committer: Claudio Freire
>>
>> AAC encoder: tweak PNS usage to be more aggressive
>>
>> This patch tweaks search_for_pns to be both more
>> aggressive and more careful when applying PNS. On
>> the one side, it will again try to use PNS on zero
>> (or effectively zero) bands. For this, both zeroes
>> and band_type have to be checked (some ZERO bands
>> aren't marked in zeroes). On the other side, a more
>> accurate rate-distortion measure avoids using PNS
>> where it would cause audible distortion.
>>
>> Also fixed a small bug in the computation of freq
>> that caused PNS usage on low-frequency bands during
>> 8-short windows. This allows re-enabling PNS during
>> 8-short.
>
> Clang and gcc's address sanitizer complain about this change
>
> http://fate.ffmpeg.org/report.cgi?time=20150925234050=x86_64-archlinux-gcc-asan
> http://fate.ffmpeg.org/report.cgi?time=20150925220641=x86_64-debian-asan-144800


It was a pre-existing issue that got exposed by that commit, not the
commit itself.

But fixed in any case.

There may be other instances of the bug, so I'll be on the lookout for
this specific case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[Anshul]

On 09/26/2015 03:57 PM, DeHackEd wrote:

On 09/26/2015 05:26 AM, Anshul wrote:


On 09/26/2015 05:46 AM, DeHackEd wrote:

Assumes 'GA94' format (ATSC standard)

Signed-off-by: DHE 
---
   doc/encoders.texi|  5 +
   libavcodec/libx264.c | 37 +
   2 files changed, 42 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..bb16dea 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with 
@command{ffmpeg}:
   ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
   @end example

+@item a53cc
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
+
+
   @item x264-params (N.A.)
   Override the x264 configuration using a :-separated list of key=value
   parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..4227bcc 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
   int avcintra_class;
   int motion_est;
   int forced_idr;
+int a53_cc;
   char *x264_params;
   } X264Context;

@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
   int nnal, i, ret;
   x264_picture_t pic_out = {0};
   int pict_type;
+AVFrameSideData *side_data;

   x264_picture_init( >pic );
   x4->pic.img.i_csp   = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
   X264_TYPE_AUTO;

   reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads = 
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[0].payload_size = side_data->size + 
11;
+x4->pic.extra_sei.payloads[0].payload = 
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
+x4->pic.extra_sei.payloads[0].payload_type = 4;
+memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
side_data->data, side_data->size);
+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, but hard 
coding
+ * this style may not be the right thing to do -- other formats
+ * do exist. This information is not available in the side_data
+ * so we are going with this right now.
+ */

I think GA94 is correct for this situation, since in our x264 decoder we don't 
consider any other standard
for extracting closed caption.

I don't know if we have any logic which differentiate between ATSC, ISDB or DVB 
we parse all transport stream
in same manner. if someone know where we differentiate atsc and dvb in FFmpeg 
please point me there.

Note: This logic will also fail when x264 is muxed in formats like gxf where 
closed caption are kept in vbi instead
of GA94.

Overall  LGTM.

I don't know how to apply encrypted mails using git, and when I save your email 
in Thunderbird, git am is unable to apply.
if you can send the same patch as attachment or command to convert encrypted 
.eml file to normal patch I would test this
too.

I think the easiest solution is to grab the patch from the github repo I use:
https://github.com/DeHackEd/FFmpeg/commit/16b4c7fc2311d672e99f.patch
anshul@linux-z9q9:~/Project/Multimedia/FFmpeg> git apply 
16b4c7fc2311d672e99f.patch

16b4c7fc2311d672e99f.patch:54: trailing whitespace.

16b4c7fc2311d672e99f.patch:75: trailing whitespace.
 */
16b4c7fc2311d672e99f.patch:81: trailing whitespace.
x4->pic.extra_sei.payloads[0].payload[8] =
warning: 3 lines add whitespace errors.
anshul@linux-z9q9:~/Project/Multimedia/FFmpeg>

Though I have fixed it at my end to test, but my advice that you fix it 
too and send another patch.


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

Re: [FFmpeg-devel] [PATCH 4/4] dnxhddec: parse and print adaptive color transform

[Christophe Gisquet]

2015-09-25 23:25 GMT+02:00 Christophe Gisquet :
[SNIP]

I have reordered the patches so that they don't rely on the slice threading one.
Therefore this one should apply cleanly. (And also not using git
send-email for replies)
From d9601c7b74b5dea0f0be9989cc657fad90c1be7d Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Fri, 25 Sep 2015 17:07:38 +0200
Subject: [PATCH 2/5] dnxhddec: parse and print adaptive color transform

Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.

Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the output format to decide what to do of it.
---
 libavcodec/dnxhddec.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index e5c5f07..22d8c0b 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -51,6 +51,7 @@ typedef struct DNXHDContext {
 int bit_depth; // 8, 10 or 0 if not initialized at all.
 int is_444;
 int mbaff;
+int act;
 void (*decode_dct_block)(struct DNXHDContext *ctx, int16_t *block,
  int n, int qscale);
 int last_qscale;
@@ -189,6 +190,11 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame *frame,
 av_log(ctx->avctx, AV_LOG_WARNING,
"Adaptive MB interlace flag in an unsupported profile.\n");
 
+ctx->act = buf[0x2C] & 7;
+if (ctx->act && ctx->cid_table->cid != 1256)
+av_log(ctx->avctx, AV_LOG_WARNING,
+   "Adaptive color transform in an unsupported profile.\n");
+
 // make sure profile size constraints are respected
 // DNx100 allows 1920->1440 and 1280->960 subsampling
 if (ctx->width != ctx->cid_table->width) {
@@ -354,7 +360,7 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx, AVFrame *frame,
 int dct_linesize_chroma = frame->linesize[1];
 uint8_t *dest_y, *dest_u, *dest_v;
 int dct_y_offset, dct_x_offset;
-int qscale, i;
+int qscale, i, act;
 int interlaced_mb = 0;
 
 if (ctx->mbaff) {
@@ -362,7 +368,15 @@ static int dnxhd_decode_macroblock(DNXHDContext *ctx, AVFrame *frame,
 qscale = get_bits(>gb, 10);
 } else
 qscale = get_bits(>gb, 11);
-skip_bits1(>gb);
+act = get_bits1(>gb);
+if (act) {
+static int warned = 0;
+if (!warned) {
+warned = 1;
+av_log(ctx->avctx, AV_LOG_ERROR,
+   "Unsupported adaptive color transform, patch welcome.\n");
+}
+}
 
 if (qscale != ctx->last_qscale) {
 for (i = 0; i < 64; i++) {
-- 
2.5.2

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

[FFmpeg-devel] [PATCH 2/3 v2] configure: Support for HEASLR on mingw targets

[Alex Smith]

From: Alex Smith 

The appropriate flag for HEASLR (--high-entropy-va) was added in
binutils 2.25.

Also set the image base >4GB so higher entropy gets applied to image
base randomization when used with HEASLR (8 -> 17 bits of
randomization).  Windows does this for compatibility because of "latent
pointer truncation issues".

Signed-off-by: Alex Smith 
---
 configure | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index f6bc622..0a4b4ed 100755
--- a/configure
+++ b/configure
@@ -4401,6 +4401,10 @@ case $target_os in
 add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup
 elif enabled x86_64; then
 add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup
+check_ldflags -Wl,--high-entropy-va # binutils 2.25
+# Set image base >4GB for extra entropy with HEASLR
+add_ldexeflags -Wl,--image-base,0x14000
+append SHFLAGS -Wl,--image-base,0x18000
 fi
 ;;
 win32|win64)
-- 
1.9.5.msysgit.0

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

Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

[Christophe Gisquet]

Hi,

2015-09-26 8:33 GMT+02:00 Christophe Gisquet :
> Is it something that should be avoidable through my code?

I now think so, so please ignore me till I've understood all of the API.

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

[FFmpeg-devel] [PATCH] configure: Combine dynamicbase and nxcompat checks

[Alex Smith]

They were added to binutils in the same version so it's safe to combine.

Signed-off-by: Alex Smith 
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index 3339126..b572d59 100755
--- a/configure
+++ b/configure
@@ -4367,8 +4367,6 @@ case $target_os in
 LIBTARGET=arm-wince
 fi
 enabled shared && ! enabled small && check_cmd $windres --version && 
enable gnu_windres
-check_ldflags -Wl,--nxcompat
-check_ldflags -Wl,--dynamicbase
 enabled x86_32 && check_ldflags -Wl,--large-address-aware
 shlibdir_default="$bindir_default"
 SLIBPREF=""
@@ -4392,6 +4390,7 @@ case $target_os in
 objformat="win32"
 ranlib=:
 enable dos_paths
+check_ldflags -Wl,--nxcompat,--dynamicbase
 # Lets work around some stupidity in binutils.
 # ld will strip relocations from executables even though we need them
 # for dynamicbase (ASLR).  Using -pie does retain the reloc section
-- 
1.9.5.msysgit.0

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

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: clip vp9 loopfilter test pixels inside allowed bitdepth range.

[Ronald S. Bultje]

Hi,

On Fri, Sep 25, 2015 at 6:50 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Fri, Sep 25, 2015 at 6:42 PM, Henrik Gramner 
> wrote:
>
>> On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje 
>> wrote:
>> > ---
>> >  tests/checkasm/vp9dsp.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Ok as long as it doesn't skew the range distribution so much that
>> you'll end up with the same max clipped value all the time.
>
>
> We basically fill pixels with base+/-range, so it clips at worst in one
> direction, and only for a few seed values where base happens to be very low
> or high. So it should be OK.
>

Pushed.

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

Re: [FFmpeg-devel] [PATCH] checkasm: Use a self-balancing tree

[Henrik Gramner]

On Sat, Sep 26, 2015 at 12:04 AM, Michael Niedermayer  wrote:
> ahh, ok, no objection from me then

On Sat, Sep 26, 2015 at 12:53 PM, Ronald S. Bultje  wrote:
> lgtm.

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

[FFmpeg-devel] [PATCH] checkasm: remove use of deprecated av_set_cpu_flags_mask()

[Henrik Gramner]

---
A working implementation of the original patch if we actually do want to get
rid of av_set_cpu_flags_mask().
---
 tests/checkasm/checkasm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 2f967e3..8c75cc9 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -357,8 +357,9 @@ static void check_cpu_flag(const char *name, int flag)
 int old_cpu_flag = state.cpu_flag;
 
 flag |= old_cpu_flag;
-av_set_cpu_flags_mask(flag);
-state.cpu_flag = av_get_cpu_flags();
+av_force_cpu_flags(-1);
+state.cpu_flag = flag & av_get_cpu_flags();
+av_force_cpu_flags(state.cpu_flag);
 
 if (!flag || state.cpu_flag != old_cpu_flag) {
 int i;
-- 
1.8.3.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/xface: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

On Fri, Sep 18, 2015 at 5:31 PM, Ganesh Ajjanagadde
 wrote:
> This patch results in identical behavior of xface, and suppresses 
> -Wstrict-overflow
> warnings observed in GCC 5.2.
> I have manually checked that this usage is safe, and overflow possibility does
> not exist with this expression rewrite.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/xface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/xface.c b/libavcodec/xface.c
> index 8c0cbfd..78b6def 100644
> --- a/libavcodec/xface.c
> +++ b/libavcodec/xface.c
> @@ -315,7 +315,7 @@ void ff_xface_generate_face(uint8_t *dst, uint8_t * const 
> src)
>
>  for (l = i - 2; l <= i + 2; l++) {
>  for (m = j - 2; m <= j; m++) {
> -if (l >= i && m == j)
> +if ((l - i >= 0) && m == j)
>  continue;
>  if (l > 0 && l <= XFACE_WIDTH && m > 0)
>  k = 2*k + src[l + m * XFACE_WIDTH];
> --
> 2.5.2
>

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
> On Sat, 26 Sep 2015 10:59:44 -0400
> Ganesh Ajjanagadde  wrote:
>
>> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  
>> wrote:
>> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
>> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
>> >>>
>> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
>> >>>  wrote:
>> 
>>  Fixes -Wunused-function from
>> 
>>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
>> 
>>  Signed-off-by: Ganesh Ajjanagadde 
>>  ---
>>    libavformat/hls.c | 13 -
>>    1 file changed, 13 deletions(-)
>> 
>>  diff --git a/libavformat/hls.c b/libavformat/hls.c
>>  index c16c770..2ea3a22 100644
>>  --- a/libavformat/hls.c
>>  +++ b/libavformat/hls.c
>>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
>>  playlist **pls, const char *url
>>    return 0;
>>    }
>> 
>>  -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
>>  -{
>>  -AVDictionary *tmp = NULL;
>>  -int ret;
>>  -
>>  -av_dict_copy(, c->avio_opts, 0);
>>  -
>>  -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
>>  );
>>  -
>>  -av_dict_free();
>>  -return ret;
>>  -}
>>  -
>>    static int url_connect(struct playlist *pls, AVDictionary *opts,
>>  AVDictionary *opts2)
>>    {
>>    AVDictionary *tmp = NULL;
>>  --
>>  2.5.2
>> 
>> >>>
>> >>> ping; wm4 basically did not like my old patch: see
>> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
>> >>> his thoughts and my response. Here, I delete as opposed to comment out
>> >>> the lines. I personally do not care about deleting vs commenting out;
>> >>> but one of the two should be used.
>> >>
>> >>
>> >> If you think the inactive code is worth keeping, put it into a git branch 
>> >> or
>> >> tag the commit removing the code.t
>> >
>> > I do not have write access, so I will leave it up to you (or anyone
>> > else pushing) to either apply the old patch or this one (and possibly
>> > tag it if desired).
>>
>> See above for two possiblities on resolving this: either this patch
>> (optionally tagging it), or simply commenting out the function (see
>> above for link to old patch).
>> Ping.
>
> Just get rid of this. I had to deal with the HLS code lately, and it
> was utterly confusing that there was this unused function.
>
> Also, this function is so trivial, that anyone really needing it could
> rewrite it in under a minute, and it'd probably be an improvement too.
> Even discussing keeping this is a waste of energy.

Please push this patch then; you have write access and I don't.

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

Re: [FFmpeg-devel] [PATCH] checkasm: remove use of deprecated av_set_cpu_flags_mask()

[Ronald S. Bultje]

Hi,

On Sat, Sep 26, 2015 at 9:54 AM, Henrik Gramner  wrote:

> ---
> A working implementation of the original patch if we actually do want to
> get
> rid of av_set_cpu_flags_mask().
> ---
>  tests/checkasm/checkasm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 2f967e3..8c75cc9 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -357,8 +357,9 @@ static void check_cpu_flag(const char *name, int flag)
>  int old_cpu_flag = state.cpu_flag;
>
>  flag |= old_cpu_flag;
> -av_set_cpu_flags_mask(flag);
> -state.cpu_flag = av_get_cpu_flags();
> +av_force_cpu_flags(-1);
> +state.cpu_flag = flag & av_get_cpu_flags();
> +av_force_cpu_flags(state.cpu_flag);


Sounds like we do, right? So I guess it's fine.

(Although I never checked why we'd deprecate _mask or whether force is
better.)

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Hendrik Leppkes]

On Sat, Sep 26, 2015 at 7:00 PM, wm4  wrote:
> On Sat, 26 Sep 2015 12:53:58 -0400
> Ganesh Ajjanagadde  wrote:
>
>> On Sat, Sep 26, 2015 at 12:37 PM, wm4  wrote:
>> > On Sat, 26 Sep 2015 12:12:44 -0400
>> > Ganesh Ajjanagadde  wrote:
>> >
>> >> On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
>> >> > On Sat, 26 Sep 2015 10:59:44 -0400
>> >> > Ganesh Ajjanagadde  wrote:
>> >> >
>> >> >> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde 
>> >> >>  wrote:
>> >> >> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
>> >> >> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
>> >> >> >>>
>> >> >> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
>> >> >> >>>  wrote:
>> >> >> 
>> >> >>  Fixes -Wunused-function from
>> >> >> 
>> >> >>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
>> >> >> 
>> >> >>  Signed-off-by: Ganesh Ajjanagadde 
>> >> >>  ---
>> >> >>    libavformat/hls.c | 13 -
>> >> >>    1 file changed, 13 deletions(-)
>> >> >> 
>> >> >>  diff --git a/libavformat/hls.c b/libavformat/hls.c
>> >> >>  index c16c770..2ea3a22 100644
>> >> >>  --- a/libavformat/hls.c
>> >> >>  +++ b/libavformat/hls.c
>> >> >>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, 
>> >> >>  struct
>> >> >>  playlist **pls, const char *url
>> >> >>    return 0;
>> >> >>    }
>> >> >> 
>> >> >>  -static int open_in(HLSContext *c, AVIOContext **in, const char 
>> >> >>  *url)
>> >> >>  -{
>> >> >>  -AVDictionary *tmp = NULL;
>> >> >>  -int ret;
>> >> >>  -
>> >> >>  -av_dict_copy(, c->avio_opts, 0);
>> >> >>  -
>> >> >>  -ret = avio_open2(in, url, AVIO_FLAG_READ, 
>> >> >>  c->interrupt_callback,
>> >> >>  );
>> >> >>  -
>> >> >>  -av_dict_free();
>> >> >>  -return ret;
>> >> >>  -}
>> >> >>  -
>> >> >>    static int url_connect(struct playlist *pls, AVDictionary *opts,
>> >> >>  AVDictionary *opts2)
>> >> >>    {
>> >> >>    AVDictionary *tmp = NULL;
>> >> >>  --
>> >> >>  2.5.2
>> >> >> 
>> >> >> >>>
>> >> >> >>> ping; wm4 basically did not like my old patch: see
>> >> >> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html 
>> >> >> >>> for
>> >> >> >>> his thoughts and my response. Here, I delete as opposed to comment 
>> >> >> >>> out
>> >> >> >>> the lines. I personally do not care about deleting vs commenting 
>> >> >> >>> out;
>> >> >> >>> but one of the two should be used.
>> >> >> >>
>> >> >> >>
>> >> >> >> If you think the inactive code is worth keeping, put it into a git 
>> >> >> >> branch or
>> >> >> >> tag the commit removing the code.t
>> >> >> >
>> >> >> > I do not have write access, so I will leave it up to you (or anyone
>> >> >> > else pushing) to either apply the old patch or this one (and possibly
>> >> >> > tag it if desired).
>> >> >>
>> >> >> See above for two possiblities on resolving this: either this patch
>> >> >> (optionally tagging it), or simply commenting out the function (see
>> >> >> above for link to old patch).
>> >> >> Ping.
>> >> >
>> >> > Just get rid of this. I had to deal with the HLS code lately, and it
>> >> > was utterly confusing that there was this unused function.
>> >> >
>> >> > Also, this function is so trivial, that anyone really needing it could
>> >> > rewrite it in under a minute, and it'd probably be an improvement too.
>> >> > Even discussing keeping this is a waste of energy.
>> >>
>> >> Please push this patch then; you have write access and I don't.
>> >
>> > Send your SSH key to Michael Niedermayer. I'll apply this patch in a
>> > moment.
>>
>> Michael offered write access a month back, to which I replied saying
>> that I do not trust myself with it at the moment and would like to
>> wait a year. I also said that I would reconsider if it is leading to
>> wasted maintainer time. Our back and forth here suggests that there is
>> some wastage.
>>
>> If no one objects to me getting write access, I will send it to
>> Michael. Please note that the intention right now is not for any
>> "maintainership" duties, but simply to ease the application of
>> reviewed patches.
>
> Yes, it's much better for everyone if you just push your own patches,
> after they have been OK'ed.

Personally I find giving new people push access after only 3 months of
activity slightly premature.

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

Re: [FFmpeg-devel] [PATCHv2] avcodec/videotoolbox: fix -Wunused-but-set-variable

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 5:41 PM, Ganesh Ajjanagadde
 wrote:
> pix_fmt was declared presumably to shorten the argument passed to the 
> function.
> However, it is currently not being used for such a purpose.
> This patch simply removes it instead.
> This fixes -Wunused-but-set-variable reported at e.g:
> http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/videotoolbox.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index b78238a..ca44491 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -501,7 +501,6 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
>  VTDecompressionOutputCallbackRecord decoder_cb;
>  CFDictionaryRef decoder_spec;
>  CFDictionaryRef buf_attr;
> -int32_t pix_fmt;
>
>  if (!videotoolbox) {
>  av_log(avctx, AV_LOG_ERROR, "hwaccel context is not set\n");
> @@ -528,8 +527,6 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
>  break;
>  }
>
> -pix_fmt = videotoolbox->cv_pix_fmt_type;
> -
>  decoder_spec = 
> videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
>
>  videotoolbox->cm_fmt_desc = 
> videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
> --
> 2.5.2
>

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Hendrik Leppkes]

On Sat, Sep 26, 2015 at 5:03 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Sep 19, 2015 at 9:03 AM, Ganesh Ajjanagadde  wrote:
>> On Wed, Sep 16, 2015 at 8:29 PM, Michael Niedermayer  
>> wrote:
>>> On Tue, Sep 15, 2015 at 04:54:19PM +0200, Michael Niedermayer wrote:
 On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
 > On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje  
 > wrote:
 > > Hi Ganesh,
 > >
 > > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde 
 > > wrote:
 > >
 > >> Hi all,
 > >>
 > >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
 > >> precisely, what is the policy of requesting a patch to be merged where
 > >> all objections raised have been addressed via discussion/updated
 > >> patches, and which have not been merged in over 2 weeks due to unknown
 > >> reasons?
 > >>
 > >> In particular, there are 2 patchsets I would like to get merged:
 > >> 1. This I consider an important patch, simply because it solves a trac
 > >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
 > >> which also contains links to the patches. A lot of discussion went on
 > >> around it on the mailing lists, and it is supported strongly by
 > >> Nicolas and me. Michael seemed initially hesitant but later became
 > >> convinced of (at least one of the set's) utility, and one of the
 > >> patches was applied. The only objection I recall was from Hendrik,
 > >> which was addressed by Nicolas in a follow-up.
 > >>
 > >> 2. This I consider much more trivial, but in this case there are no
 > >> remaining objections. However, I still consider it important enough
 > >> for a request to re-examine, as I am doing here. The patchset is more
 > >> recent, 
 > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
 > >> and 
 > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
 > >
 > >
 > > Trivial patches can be merged after 24-48 hours if there's no 
 > > objections
 > > outstanding. For more elaborate patches, poke anyone for review if you 
 > > feel
 > > it would be helpful.
 > >
 > > In both cases, having push access yourself will hurry this along (i.e. 
 > > you
 > > really should get push access), but in this case I will push later 
 > > today.
 > > If you don't want push access, poke one of us on IRC to do the push for
 > > you, or bump the original email with a "poke" or "ping".
 >
 > Thanks. Patches for 2) needs work, and I will be posting it soon.


 > Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
 > seems ok with it like I mentioned).

 there where a few patches, iam not exactly sure which are left and
 what effects they have
>>>
 What i objected to and still object to is to cause the terminal to
>>>
>>> i withdraw my objection, ill leave it to others to decide which way is
>>> better. Some arguments in this thread have sort of changed my oppinion
>>> from prefering the heuristic to being undecided on what is better
>>
>> Ping, any other opinions?
>
> It has been a week with no standing objections (Michael withdrew his).
> Further, there have not been any additional comments. Hence, a ping to
> apply https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176481.html.
> More discussion and context: https://trac.ffmpeg.org/ticket/2964.
>

Please ping the actual thread of the patch, and not some seemingly
unrelated thread, so people are actually aware of the topic at hand.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2 1/2] ffplay: add support for interactive volume control

[Ganesh Ajjanagadde]

This is a feature heavily inspired by the mpv player. At the moment, methods
for adjusting volume in ffplay are rather clumsy: either one needs to set it
system-wide, or one needs to set it via the volume filter.

This patch adds key bindings identical to the mpv defaults for muting/unmuting
and increasing/decreasing the volume interactively without any introduction of
external dependencies.

TODO: doc update, possible mouse button bindings (mpv has this).

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index d302793..eada863 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,6 +73,9 @@ const int program_birth_year = 2003;
 /* Calculate actual buffer size keeping in mind not cause too frequent audio 
callbacks */
 #define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30
 
+/* Step size for volume control */
+#define SDL_VOLUME_STEP 2
+
 /* no AV sync correction is done if below the minimum AV sync threshold */
 #define AV_SYNC_THRESHOLD_MIN 0.04
 /* AV sync correction is done if above the maximum AV sync threshold */
@@ -246,6 +249,8 @@ typedef struct VideoState {
 unsigned int audio_buf1_size;
 int audio_buf_index; /* in bytes */
 int audio_write_buf_size;
+int audio_volume;
+int muted;
 struct AudioParams audio_src;
 #if CONFIG_AVFILTER
 struct AudioParams audio_filter_src;
@@ -1348,6 +1353,17 @@ static void toggle_pause(VideoState *is)
 is->step = 0;
 }
 
+static void toggle_mute(VideoState *is)
+{
+is->muted = !is->muted;
+}
+
+static void update_volume(VideoState *is, int sign, int step)
+{
+is->audio_volume += sign * step;
+is->audio_volume = av_clip(is->audio_volume, 0, SDL_MIX_MAXVOLUME);
+}
+
 static void step_to_next_frame(VideoState *is)
 {
 /* if the stream is paused unpause it, then step */
@@ -2447,7 +2463,10 @@ static void sdl_audio_callback(void *opaque, Uint8 
*stream, int len)
 len1 = is->audio_buf_size - is->audio_buf_index;
 if (len1 > len)
 len1 = len;
-memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, len1);
+if (is->muted)
+memset(stream, 0, len1);
+else
+SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
is->audio_buf_index, len1, is->audio_volume);
 len -= len1;
 stream += len1;
 is->audio_buf_index += len1;
@@ -2634,6 +2653,8 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->audio_src = is->audio_tgt;
 is->audio_buf_size  = 0;
 is->audio_buf_index = 0;
+is->audio_volume = SDL_MIX_MAXVOLUME;
+is->muted = 0;
 
 /* init averaging filter */
 is->audio_diff_avg_coef  = exp(log(0.01) / AUDIO_DIFF_AVG_NB);
@@ -3311,6 +3332,17 @@ static void event_loop(VideoState *cur_stream)
 case SDLK_SPACE:
 toggle_pause(cur_stream);
 break;
+case SDLK_m:
+toggle_mute(cur_stream);
+break;
+case SDLK_ASTERISK:
+case SDLK_0:
+update_volume(cur_stream, 1, SDL_VOLUME_STEP);
+break;
+case SDLK_SLASH:
+case SDLK_9:
+update_volume(cur_stream, -1, SDL_VOLUME_STEP);
+break;
 case SDLK_s: // S: Step to next frame
 step_to_next_frame(cur_stream);
 break;
-- 
2.5.3

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

[FFmpeg-devel] [PATCH]h264: Fix ticket #3147 H264 - Wrong field order

[Thomas Mundt]

Hi,
some h264 encoders, like broadcast avc-intra in this case, always set 
sei_pic_struct to "frame" even at interlaced encodings with separate fields. 
FFmpeg h264 decoder always assumes field order as "bottom field first" unless 
"top field first" is definitely detected. This leads to wrong field order 
detection in some cases.Attached patch changes this behavior of h264 decoder 
when sei_pic_struct is used for field order detection.Now "top field first" is 
assumed unless "bottom field first" is definitely detected.
One could say fine, but now "bottom field first" material with sei_pic_struct 
set to "frame" will be detected wrong.Yes, but since "bottom field first" comes 
from the old NTSC standard and is not used with HD anymore I think it´s 
straight forward to favor the majority.
Please comment,Thomas


h264.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Henrik Gramner]

On Sat, Sep 26, 2015 at 6:10 PM, Ganesh Ajjanagadde  wrote:
> Have you compared with av_always_inline?

No, other functions in that header used "inline", so I went with the
same for consistency. But I guess we could change those as well if
av_always_inline is preferable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[wm4]

On Sat, 26 Sep 2015 12:53:58 -0400
Ganesh Ajjanagadde  wrote:

> On Sat, Sep 26, 2015 at 12:37 PM, wm4  wrote:
> > On Sat, 26 Sep 2015 12:12:44 -0400
> > Ganesh Ajjanagadde  wrote:
> >
> >> On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
> >> > On Sat, 26 Sep 2015 10:59:44 -0400
> >> > Ganesh Ajjanagadde  wrote:
> >> >
> >> >> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  
> >> >> wrote:
> >> >> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
> >> >> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
> >> >> >>>
> >> >> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
> >> >> >>>  wrote:
> >> >> 
> >> >>  Fixes -Wunused-function from
> >> >> 
> >> >>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
> >> >> 
> >> >>  Signed-off-by: Ganesh Ajjanagadde 
> >> >>  ---
> >> >>    libavformat/hls.c | 13 -
> >> >>    1 file changed, 13 deletions(-)
> >> >> 
> >> >>  diff --git a/libavformat/hls.c b/libavformat/hls.c
> >> >>  index c16c770..2ea3a22 100644
> >> >>  --- a/libavformat/hls.c
> >> >>  +++ b/libavformat/hls.c
> >> >>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, 
> >> >>  struct
> >> >>  playlist **pls, const char *url
> >> >>    return 0;
> >> >>    }
> >> >> 
> >> >>  -static int open_in(HLSContext *c, AVIOContext **in, const char 
> >> >>  *url)
> >> >>  -{
> >> >>  -AVDictionary *tmp = NULL;
> >> >>  -int ret;
> >> >>  -
> >> >>  -av_dict_copy(, c->avio_opts, 0);
> >> >>  -
> >> >>  -ret = avio_open2(in, url, AVIO_FLAG_READ, 
> >> >>  c->interrupt_callback,
> >> >>  );
> >> >>  -
> >> >>  -av_dict_free();
> >> >>  -return ret;
> >> >>  -}
> >> >>  -
> >> >>    static int url_connect(struct playlist *pls, AVDictionary *opts,
> >> >>  AVDictionary *opts2)
> >> >>    {
> >> >>    AVDictionary *tmp = NULL;
> >> >>  --
> >> >>  2.5.2
> >> >> 
> >> >> >>>
> >> >> >>> ping; wm4 basically did not like my old patch: see
> >> >> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html 
> >> >> >>> for
> >> >> >>> his thoughts and my response. Here, I delete as opposed to comment 
> >> >> >>> out
> >> >> >>> the lines. I personally do not care about deleting vs commenting 
> >> >> >>> out;
> >> >> >>> but one of the two should be used.
> >> >> >>
> >> >> >>
> >> >> >> If you think the inactive code is worth keeping, put it into a git 
> >> >> >> branch or
> >> >> >> tag the commit removing the code.t
> >> >> >
> >> >> > I do not have write access, so I will leave it up to you (or anyone
> >> >> > else pushing) to either apply the old patch or this one (and possibly
> >> >> > tag it if desired).
> >> >>
> >> >> See above for two possiblities on resolving this: either this patch
> >> >> (optionally tagging it), or simply commenting out the function (see
> >> >> above for link to old patch).
> >> >> Ping.
> >> >
> >> > Just get rid of this. I had to deal with the HLS code lately, and it
> >> > was utterly confusing that there was this unused function.
> >> >
> >> > Also, this function is so trivial, that anyone really needing it could
> >> > rewrite it in under a minute, and it'd probably be an improvement too.
> >> > Even discussing keeping this is a waste of energy.
> >>
> >> Please push this patch then; you have write access and I don't.
> >
> > Send your SSH key to Michael Niedermayer. I'll apply this patch in a
> > moment.
> 
> Michael offered write access a month back, to which I replied saying
> that I do not trust myself with it at the moment and would like to
> wait a year. I also said that I would reconsider if it is leading to
> wasted maintainer time. Our back and forth here suggests that there is
> some wastage.
> 
> If no one objects to me getting write access, I will send it to
> Michael. Please note that the intention right now is not for any
> "maintainership" duties, but simply to ease the application of
> reviewed patches.

Yes, it's much better for everyone if you just push your own patches,
after they have been OK'ed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 1:18 PM, Hendrik Leppkes  wrote:
> On Sat, Sep 26, 2015 at 6:48 PM, Ganesh Ajjanagadde  wrote:
>> On Sat, Sep 26, 2015 at 12:26 PM, Henrik Gramner  wrote:
>>> On Sat, Sep 26, 2015 at 6:10 PM, Ganesh Ajjanagadde  
>>> wrote:
 Have you compared with av_always_inline?
>>>
>>> No, other functions in that header used "inline", so I went with the
>>> same for consistency. But I guess we could change those as well if
>>> av_always_inline is preferable.
>>
>> Commit  06eb4f0885746b7e8a652d7b6026abf834e04b73 has a fairly detailed
>> explanation of av_always_inline. Essentially the question is: do we
>> trust the compiler to do the right thing here? In the worst case, the
>> compiler will not inline it, in which case what is the performance
>> penalty?
>> My suspicion is that the loss is not that bad, and since there is no
>> inline asm, the compiler in all likelihood won't need the
>> av_always_inline.
>>
>> Thus either one should be ok (pick whichever you prefer), and so LGTM.
>
> The functions were not inline before, so there is no "penality", and only 
> gain.
> For consistency, picking normal inline should be preferred here.

I meant penalty when comparing inline vs av_always_inline, and not
current vs proposed patch.
Anyway, patch is fine.

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

[FFmpeg-devel] [PATCH] checkasm: Fix the function name sorting algorithm

[Henrik Gramner]

The previous implementation was behaving incorrectly in some corner cases.
---
 tests/checkasm/checkasm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 8c75cc9..715b08c 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -289,12 +289,12 @@ static void print_benchs(CheckasmFunc *f)
 /* ASCIIbetical sort except preserving natural order for numbers */
 static int cmp_func_names(const char *a, const char *b)
 {
-int ascii_diff, digit_diff;
+int ascii_diff, digit_diff = 0;
 
 for (; !(ascii_diff = *a - *b) && *a; a++, b++);
-for (; av_isdigit(*a) && av_isdigit(*b); a++, b++);
+for (; av_isdigit(*a) && av_isdigit(*b); a++, b++, digit_diff = -1);
 
-return (digit_diff = av_isdigit(*a) - av_isdigit(*b)) ? digit_diff : 
ascii_diff;
+return (digit_diff &= av_isdigit(*a) - av_isdigit(*b)) ? digit_diff : 
ascii_diff;
 }
 
 /* Perform a tree rotation in the specified direction and return the new root 
*/
-- 
1.8.3.2

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 9:03 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Sep 16, 2015 at 8:29 PM, Michael Niedermayer  wrote:
>> On Tue, Sep 15, 2015 at 04:54:19PM +0200, Michael Niedermayer wrote:
>>> On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
>>> > On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje  
>>> > wrote:
>>> > > Hi Ganesh,
>>> > >
>>> > > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde 
>>> > > wrote:
>>> > >
>>> > >> Hi all,
>>> > >>
>>> > >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
>>> > >> precisely, what is the policy of requesting a patch to be merged where
>>> > >> all objections raised have been addressed via discussion/updated
>>> > >> patches, and which have not been merged in over 2 weeks due to unknown
>>> > >> reasons?
>>> > >>
>>> > >> In particular, there are 2 patchsets I would like to get merged:
>>> > >> 1. This I consider an important patch, simply because it solves a trac
>>> > >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
>>> > >> which also contains links to the patches. A lot of discussion went on
>>> > >> around it on the mailing lists, and it is supported strongly by
>>> > >> Nicolas and me. Michael seemed initially hesitant but later became
>>> > >> convinced of (at least one of the set's) utility, and one of the
>>> > >> patches was applied. The only objection I recall was from Hendrik,
>>> > >> which was addressed by Nicolas in a follow-up.
>>> > >>
>>> > >> 2. This I consider much more trivial, but in this case there are no
>>> > >> remaining objections. However, I still consider it important enough
>>> > >> for a request to re-examine, as I am doing here. The patchset is more
>>> > >> recent, 
>>> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
>>> > >> and 
>>> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
>>> > >
>>> > >
>>> > > Trivial patches can be merged after 24-48 hours if there's no objections
>>> > > outstanding. For more elaborate patches, poke anyone for review if you 
>>> > > feel
>>> > > it would be helpful.
>>> > >
>>> > > In both cases, having push access yourself will hurry this along (i.e. 
>>> > > you
>>> > > really should get push access), but in this case I will push later 
>>> > > today.
>>> > > If you don't want push access, poke one of us on IRC to do the push for
>>> > > you, or bump the original email with a "poke" or "ping".
>>> >
>>> > Thanks. Patches for 2) needs work, and I will be posting it soon.
>>>
>>>
>>> > Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
>>> > seems ok with it like I mentioned).
>>>
>>> there where a few patches, iam not exactly sure which are left and
>>> what effects they have
>>
>>> What i objected to and still object to is to cause the terminal to
>>
>> i withdraw my objection, ill leave it to others to decide which way is
>> better. Some arguments in this thread have sort of changed my oppinion
>> from prefering the heuristic to being undecided on what is better
>
> Ping, any other opinions?

It has been a week with no standing objections (Michael withdrew his).
Further, there have not been any additional comments. Hence, a ping to
apply https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176481.html.
More discussion and context: https://trac.ffmpeg.org/ticket/2964.

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I have often repented speaking, but never of holding my tongue.
>> -- Xenocrates
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/attributes: extend av_uninit to clang

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 1:00 AM, Ganesh Ajjanagadde
 wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> Furthermore, it should be useful for general usage of av_uninit in future.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/attributes.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavutil/attributes.h b/libavutil/attributes.h
> index 50e8eb3..b4b5f13 100644
> --- a/libavutil/attributes.h
> +++ b/libavutil/attributes.h
> @@ -141,6 +141,12 @@
>
>  #if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
>  #define av_uninit(x) x=x
> +#elif defined(__clang__)
> +#define av_uninit(x) \
> +_Pragma("clang diagnostic push") \
> +_Pragma("clang diagnostic ignored \"-Wuninitialized\"") \
> +x=x \
> +_Pragma("clang diagnostic pop")
>  #else
>  #define av_uninit(x) x
>  #endif
> --
> 2.5.2
>

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

[FFmpeg-devel] [PATCH]libx264: Disable global header for AVC-Intra encoding

[Thomas Mundt]

This will fix AVC-Intra encoding in .mov container.
Regards,Thomas


libx264.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] dnxhddec: parse and print adaptive color transform

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 02:36:51PM +0200, Christophe Gisquet wrote:
> 2015-09-25 23:25 GMT+02:00 Christophe Gisquet :
> [SNIP]
> 
> I have reordered the patches so that they don't rely on the slice threading 
> one.
> Therefore this one should apply cleanly. (And also not using git
> send-email for replies)

>  dnxhddec.c |   18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 601f827e23dd0e0561f91b87bc50a402aa138c59  
> 0002-dnxhddec-parse-and-print-adaptive-color-transform.patch
> From d9601c7b74b5dea0f0be9989cc657fad90c1be7d Mon Sep 17 00:00:00 2001
> From: Christophe Gisquet 
> Date: Fri, 25 Sep 2015 17:07:38 +0200
> Subject: [PATCH 2/5] dnxhddec: parse and print adaptive color transform
> 
> Indicates a YCbCr->RGB transform at the block level. Although nothing
> explicitly states it, this would assume the actual content is planar
> RGB.
> 
> Currently unsupported, but the one sequence I found using it flagged
> every mb that way, actually meaning the content was YCbCr, and thus
> best left to the output format to decide what to do of it.
> ---
>  libavcodec/dnxhddec.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)

applied

thanks

[...]

-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Henrik Gramner]

They're short enough that inlining them actually reduces code size due to
all the overhead associated with making a function call.
---
 libavutil/avstring.c | 22 --
 libavutil/avstring.h | 22 ++
 2 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 24d1bb9..57fe74d 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -317,28 +317,6 @@ int av_escape(char **dst, const char *src, const char 
*special_chars,
 }
 }
 
-int av_isdigit(int c)
-{
-return c >= '0' && c <= '9';
-}
-
-int av_isgraph(int c)
-{
-return c > 32 && c < 127;
-}
-
-int av_isspace(int c)
-{
-return c == ' ' || c == '\f' || c == '\n' || c == '\r' || c == '\t' ||
-   c == '\v';
-}
-
-int av_isxdigit(int c)
-{
-c = av_tolower(c);
-return av_isdigit(c) || (c >= 'a' && c <= 'f');
-}
-
 int av_match_name(const char *name, const char *names)
 {
 const char *p;
diff --git a/libavutil/avstring.h b/libavutil/avstring.h
index 234c030..a306e89 100644
--- a/libavutil/avstring.h
+++ b/libavutil/avstring.h
@@ -203,17 +203,27 @@ char *av_strtok(char *s, const char *delim, char 
**saveptr);
 /**
  * Locale-independent conversion of ASCII isdigit.
  */
-av_const int av_isdigit(int c);
+static inline av_const int av_isdigit(int c)
+{
+return c >= '0' && c <= '9';
+}
 
 /**
  * Locale-independent conversion of ASCII isgraph.
  */
-av_const int av_isgraph(int c);
+static inline av_const int av_isgraph(int c)
+{
+return c > 32 && c < 127;
+}
 
 /**
  * Locale-independent conversion of ASCII isspace.
  */
-av_const int av_isspace(int c);
+static inline av_const int av_isspace(int c)
+{
+return c == ' ' || c == '\f' || c == '\n' || c == '\r' || c == '\t' ||
+   c == '\v';
+}
 
 /**
  * Locale-independent conversion of ASCII characters to uppercase.
@@ -238,7 +248,11 @@ static inline av_const int av_tolower(int c)
 /**
  * Locale-independent conversion of ASCII isxdigit.
  */
-av_const int av_isxdigit(int c);
+static inline av_const int av_isxdigit(int c)
+{
+c = av_tolower(c);
+return av_isdigit(c) || (c >= 'a' && c <= 'f');
+}
 
 /**
  * Locale-independent case-insensitive compare.
-- 
1.8.3.2

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 12:37 PM, wm4  wrote:
> On Sat, 26 Sep 2015 12:12:44 -0400
> Ganesh Ajjanagadde  wrote:
>
>> On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
>> > On Sat, 26 Sep 2015 10:59:44 -0400
>> > Ganesh Ajjanagadde  wrote:
>> >
>> >> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  
>> >> wrote:
>> >> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
>> >> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
>> >> >>>
>> >> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
>> >> >>>  wrote:
>> >> 
>> >>  Fixes -Wunused-function from
>> >> 
>> >>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
>> >> 
>> >>  Signed-off-by: Ganesh Ajjanagadde 
>> >>  ---
>> >>    libavformat/hls.c | 13 -
>> >>    1 file changed, 13 deletions(-)
>> >> 
>> >>  diff --git a/libavformat/hls.c b/libavformat/hls.c
>> >>  index c16c770..2ea3a22 100644
>> >>  --- a/libavformat/hls.c
>> >>  +++ b/libavformat/hls.c
>> >>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
>> >>  playlist **pls, const char *url
>> >>    return 0;
>> >>    }
>> >> 
>> >>  -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
>> >>  -{
>> >>  -AVDictionary *tmp = NULL;
>> >>  -int ret;
>> >>  -
>> >>  -av_dict_copy(, c->avio_opts, 0);
>> >>  -
>> >>  -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
>> >>  );
>> >>  -
>> >>  -av_dict_free();
>> >>  -return ret;
>> >>  -}
>> >>  -
>> >>    static int url_connect(struct playlist *pls, AVDictionary *opts,
>> >>  AVDictionary *opts2)
>> >>    {
>> >>    AVDictionary *tmp = NULL;
>> >>  --
>> >>  2.5.2
>> >> 
>> >> >>>
>> >> >>> ping; wm4 basically did not like my old patch: see
>> >> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
>> >> >>> his thoughts and my response. Here, I delete as opposed to comment out
>> >> >>> the lines. I personally do not care about deleting vs commenting out;
>> >> >>> but one of the two should be used.
>> >> >>
>> >> >>
>> >> >> If you think the inactive code is worth keeping, put it into a git 
>> >> >> branch or
>> >> >> tag the commit removing the code.t
>> >> >
>> >> > I do not have write access, so I will leave it up to you (or anyone
>> >> > else pushing) to either apply the old patch or this one (and possibly
>> >> > tag it if desired).
>> >>
>> >> See above for two possiblities on resolving this: either this patch
>> >> (optionally tagging it), or simply commenting out the function (see
>> >> above for link to old patch).
>> >> Ping.
>> >
>> > Just get rid of this. I had to deal with the HLS code lately, and it
>> > was utterly confusing that there was this unused function.
>> >
>> > Also, this function is so trivial, that anyone really needing it could
>> > rewrite it in under a minute, and it'd probably be an improvement too.
>> > Even discussing keeping this is a waste of energy.
>>
>> Please push this patch then; you have write access and I don't.
>
> Send your SSH key to Michael Niedermayer. I'll apply this patch in a
> moment.

Michael offered write access a month back, to which I replied saying
that I do not trust myself with it at the moment and would like to
wait a year. I also said that I would reconsider if it is leading to
wasted maintainer time. Our back and forth here suggests that there is
some wastage.

If no one objects to me getting write access, I will send it to
Michael. Please note that the intention right now is not for any
"maintainership" duties, but simply to ease the application of
reviewed patches.

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

Re: [FFmpeg-devel] [PATCHv2] avcodec: use HAVE_THREADS header guards to silence -Wunused-function

[Ganesh Ajjanagadde]

On Fri, Sep 18, 2015 at 9:05 AM, Ganesh Ajjanagadde  wrote:
> On Fri, Sep 18, 2015 at 4:40 AM, wm4  wrote:
>> On 17.09.2015 15:07, Ganesh Ajjanagadde wrote:
>>>
>>> When compiled with --disable-pthreads, e.g
>>>
>>> http://fate.ffmpeg.org/report.cgi?time=20150917015044=alpha-debian-qemu-gcc-4.7,
>>> a bunch of -Wunused-functions are reported.
>>> This patch should silence such warnings.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>   libavcodec/alac.c  | 2 +-
>>>   libavcodec/exr.c   | 2 +-
>>>   libavcodec/ffv1dec.c   | 4 ++--
>>>   libavcodec/flacdec.c   | 2 +-
>>>   libavcodec/h264.c  | 2 +-
>>>   libavcodec/huffyuvdec.c| 2 +-
>>>   libavcodec/mdec.c  | 2 +-
>>>   libavcodec/mimic.c | 4 ++--
>>>   libavcodec/mpeg12dec.c | 2 +-
>>>   libavcodec/mpeg4videodec.c | 2 +-
>>>   libavcodec/pngdec.c| 2 +-
>>>   libavcodec/takdec.c| 4 ++--
>>>   libavcodec/tta.c   | 4 ++--
>>>   libavcodec/vp3.c   | 4 ++--
>>>   libavcodec/vp8.c   | 4 ++--
>>>   libavcodec/vp9.c   | 2 +-
>>>   libavcodec/wavpack.c   | 2 +-
>>>   17 files changed, 23 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
>>> index 827c0db..f2e5907 100644
>>> --- a/libavcodec/alac.c
>>> +++ b/libavcodec/alac.c
>>> @@ -609,7 +609,7 @@ static av_cold int alac_decode_init(AVCodecContext *
>>> avctx)
>>>   return 0;
>>>   }
>>>
>>> -static int init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>>>   {
>>>   ALACContext *alac = avctx->priv_data;
>>>   alac->avctx = avctx;
>>> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
>>> index 3b6b245..778088e 100644
>>> --- a/libavcodec/exr.c
>>> +++ b/libavcodec/exr.c
>>> @@ -1426,7 +1426,7 @@ static av_cold int decode_init(AVCodecContext
>>> *avctx)
>>>   return 0;
>>>   }
>>>
>>> -static int decode_init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
>>>   {EXRContext *s = avctx->priv_data;
>>>
>>>   // allocate thread data, used for non EXR_RAW compreesion types
>>> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
>>> index 557b1a0..70ae37d 100644
>>> --- a/libavcodec/ffv1dec.c
>>> +++ b/libavcodec/ffv1dec.c
>>> @@ -1008,7 +1008,7 @@ static int decode_frame(AVCodecContext *avctx, void
>>> *data, int *got_frame, AVPac
>>>   return buf_size;
>>>   }
>>>
>>> -static int init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>>>   {
>>>   FFV1Context *f = avctx->priv_data;
>>>   int i, ret;
>>> @@ -1061,7 +1061,7 @@ static void copy_fields(FFV1Context *fsdst,
>>> FFV1Context *fssrc, FFV1Context *fsr
>>>   }
>>>   }
>>>
>>> -static int update_thread_context(AVCodecContext *dst, const
>>> AVCodecContext *src)
>>> +av_unused static int update_thread_context(AVCodecContext *dst, const
>>> AVCodecContext *src)
>>>   {
>>>   FFV1Context *fsrc = src->priv_data;
>>>   FFV1Context *fdst = dst->priv_data;
>>> diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
>>> index 8653da7..00744da 100644
>>> --- a/libavcodec/flacdec.c
>>> +++ b/libavcodec/flacdec.c
>>> @@ -623,7 +623,7 @@ static int flac_decode_frame(AVCodecContext *avctx,
>>> void *data,
>>>   return bytes_read;
>>>   }
>>>
>>> -static int init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>>>   {
>>>   FLACContext *s = avctx->priv_data;
>>>   s->decoded_buffer = NULL;
>>> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
>>> index b797893..fa66b53 100644
>>> --- a/libavcodec/h264.c
>>> +++ b/libavcodec/h264.c
>>> @@ -701,7 +701,7 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx)
>>>   return 0;
>>>   }
>>>
>>> -static int decode_init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
>>>   {
>>>   H264Context *h = avctx->priv_data;
>>>   int ret;
>>> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
>>> index a700abb..eda11ee 100644
>>> --- a/libavcodec/huffyuvdec.c
>>> +++ b/libavcodec/huffyuvdec.c
>>> @@ -571,7 +571,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>>   return ret;
>>>   }
>>>
>>> -static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
>>> +av_unused static av_cold int decode_init_thread_copy(AVCodecContext
>>> *avctx)
>>>   {
>>>   HYuvContext *s = avctx->priv_data;
>>>   int i, ret;
>>> diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
>>> index a9b7e82..b169ac6 100644
>>> --- a/libavcodec/mdec.c
>>> +++ b/libavcodec/mdec.c
>>> @@ -233,7 +233,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>>   return 0;
>>>   }
>>>
>>> -static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
>>> +av_unused 

[FFmpeg-devel] [PATCH]lavf/rawenc: Force one stream for hevc and m4v

[Carl Eugen Hoyos]

Hi!

Attached patch forces one stream for the output formats hevc 
and (raw) m4v.

Please comment, Carl Eugen
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index d65c7c7..7a1a3d0 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -241,6 +241,7 @@ AVOutputFormat ff_hevc_muxer = {
 .extensions= "hevc",
 .audio_codec   = AV_CODEC_ID_NONE,
 .video_codec   = AV_CODEC_ID_HEVC,
+.write_header  = force_one_stream,
 .write_packet  = ff_raw_write_packet,
 .flags = AVFMT_NOTIMESTAMPS,
 };
@@ -253,6 +254,7 @@ AVOutputFormat ff_m4v_muxer = {
 .extensions= "m4v",
 .audio_codec   = AV_CODEC_ID_NONE,
 .video_codec   = AV_CODEC_ID_MPEG4,
+.write_header  = force_one_stream,
 .write_packet  = ff_raw_write_packet,
 .flags = AVFMT_NOTIMESTAMPS,
 };
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.

[Matt Oliver]

On 26 September 2015 at 04:08, Michael Niedermayer  wrote:

> On Fri, Sep 25, 2015 at 09:41:59PM +1000, Matt Oliver wrote:
> > On 25 September 2015 at 17:58, Matt Oliver  wrote:
> >
> > > Allows the decklink device to be used with native win32/os2 threads
> > > instead of just pthreads.
> > >
> > > Note: I dont have a decklink device to test this but It just allows the
> > > use of the already tested win32/os2 pthread simulation functions so
> there
> > > shouldnt be any issues.
> > >
> >
> > Actually added the patch this time :(
>
> >  configure   |4 ++--
> >  libavdevice/decklink_common.cpp |2 +-
> >  libavdevice/decklink_dec.cpp|2 +-
> >  libavdevice/decklink_enc.cpp|2 +-
> >  4 files changed, 5 insertions(+), 5 deletions(-)
> > 4aa7edd4948d914a5f8f580bda23c9edb931f860
> 0003-avdevice-decklink-Allow-compilation-with-native-thre.patch
> > From 13c98e75292284a8b9e17c3a459208c1c06c10cb Mon Sep 17 00:00:00 2001
> > From: Matt Oliver 
> > Date: Fri, 25 Sep 2015 17:52:57 +1000
> > Subject: [PATCH 3/3] avdevice/decklink: Allow compilation with native
> threads.
> >
> > ---
> >  configure   | 4 ++--
> >  libavdevice/decklink_common.cpp | 2 +-
> >  libavdevice/decklink_dec.cpp| 2 +-
> >  libavdevice/decklink_enc.cpp| 2 +-
> >  4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure b/configure
> > index e21820a..58865d9 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2652,9 +2652,9 @@ avfoundation_indev_extralibs="-framework CoreVideo
> -framework Foundation -framew
> >  avfoundation_indev_select="avfoundation"
> >  bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h
> dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
> >  caca_outdev_deps="libcaca"
> > -decklink_outdev_deps="decklink pthreads"
> > +decklink_outdev_deps="decklink threads"
> >  decklink_outdev_extralibs="-lstdc++"
> > -decklink_indev_deps="decklink pthreads"
> > +decklink_indev_deps="decklink threads"
> >  decklink_indev_extralibs="-lstdc++"
> >  dshow_indev_deps="IBaseFilter"
> >  dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
> -lshlwapi"
> > diff --git a/libavdevice/decklink_common.cpp
> b/libavdevice/decklink_common.cpp
> > index ac7964c..476315f 100644
> > --- a/libavdevice/decklink_common.cpp
> > +++ b/libavdevice/decklink_common.cpp
> > @@ -26,7 +26,7 @@
> >  #include 
> >  #endif
> >
> > -#include 
> > +#include "libavutil/thread.h"
> >  #include 
> >
> >  extern "C" {
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index 747f47e..5c86d94 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -21,7 +21,7 @@
> >
> >  #include 
> >
> > -#include 
> > +#include "libavutil/thread.h"
> >  #include 
> >
> >  extern "C" {
> > diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
> > index 6c5450f..1c9f728 100644
> > --- a/libavdevice/decklink_enc.cpp
> > +++ b/libavdevice/decklink_enc.cpp
> > @@ -21,7 +21,7 @@
> >
> >  #include 
> >
> > -#include 
> > +#include "libavutil/thread.h"
> >  #include 
> >
> >  extern "C" {
>
> i have no means to test either but
> shouldnt libavutil/*.h be under extern "C" { ?
>
> [...]


I didnt have any problems with that on my setup because thread.h when not
using pthread just declares static inline functions and the pthread header
adds its own extern "C". If there is some other pthread implementation
somewhere that doesnt do this then that may be an issue in which case i can
move it inside the extern "C"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[DeHackEd]

Assumes 'GA94' format (ATSC standard)

Signed-off-by: DHE 
---
 doc/encoders.texi|  5 +
 libavcodec/libx264.c | 37 +
 2 files changed, 42 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..aabbda0 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with 
@command{ffmpeg}:
 ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
 @end example
 
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
+
+
 @item x264-params (N.A.)
 Override the x264 configuration using a :-separated list of key=value
 parameters.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 58fcfb0..8540ff9 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -83,6 +83,7 @@ typedef struct X264Context {
 int avcintra_class;
 int motion_est;
 int forced_idr;
+int a53_cc;
 char *x264_params;
 } X264Context;
 
@@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 int nnal, i, ret;
 x264_picture_t pic_out = {0};
 int pict_type;
+AVFrameSideData *side_data;
 
 x264_picture_init( >pic );
 x4->pic.img.i_csp   = x4->params.i_csp;
@@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 X264_TYPE_AUTO;
 
 reconfig_encoder(ctx, frame);
+
+if (x4->a53_cc) {
+side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
+if (side_data) {
+x4->pic.extra_sei.num_payloads = 1;
+x4->pic.extra_sei.payloads = 
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[0].payload_size = side_data->size + 
11;
+x4->pic.extra_sei.payloads[0].payload = 
av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);
+x4->pic.extra_sei.payloads[0].payload_type = 4;
+memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
side_data->data, side_data->size);
+x4->pic.extra_sei.payloads[0].payload[0] = 181;
+x4->pic.extra_sei.payloads[0].payload[1] = 0;
+x4->pic.extra_sei.payloads[0].payload[2] = 49;
+
+/**
+ * 'GA94' is standard in North America for ATSC, but hard 
coding
+ * this style may not be the right thing to do -- other formats
+ * do exist. This information is not available in the side_data
+ * so we are going with this right now.
+ */
+x4->pic.extra_sei.payloads[0].payload[3] = 'G';
+x4->pic.extra_sei.payloads[0].payload[4] = 'A';
+x4->pic.extra_sei.payloads[0].payload[5] = '9';
+x4->pic.extra_sei.payloads[0].payload[6] = '4';
+x4->pic.extra_sei.payloads[0].payload[7] = 3;
+x4->pic.extra_sei.payloads[0].payload[8] =
+((side_data->size/3) & 0x1f) | 0x40;
+x4->pic.extra_sei.payloads[0].payload[9] = 0;
+x4->pic.extra_sei.payloads[0].payload[side_data->size+10] = 
255;
+}
+}
+
 }
 do {
 if (x264_encoder_encode(x4->enc, , , frame? >pic: NULL, 
_out) < 0)
@@ -821,6 +857,7 @@ static const AVOption options[] = {
 {"level", "Specify level (as defined by Annex A)", OFFSET(level), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
+{"a53cc",  "Use A53 Closed Captions (if available)",  
OFFSET(a53_cc),AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1, VE},
 {"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0, VE},
 { "crf",   "Select the quality for constant quality mode",
OFFSET(crf),   AV_OPT_TYPE_FLOAT,  {.dbl = -1 }, -1, FLT_MAX, VE },
 { "crf_max",   "In CRF mode, prevents VBV from lowering quality beyond 
this point.",OFFSET(crf_max), AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE 
},
-- 
1.8.4.1

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

Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

[Christophe Gisquet]

Hi,

2015-09-26 1:52 GMT+02:00 Michael Niedermayer :
> This segfaults with 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov

Patch reworked:
- Preallocate RowContext to avoid reloading it
- Use of init_thread_copy due to that
- Fix crashes due to mishandling of code around execute2

The speed of slice-threading is equivalent to frame-threading, which
makes the later less attractive. Several decoders forgo implementing
it.

-- 
Christophe
From 354a8e016e1e10a4288534782104479aae3e62a9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Fri, 25 Sep 2015 08:56:43 +0200
Subject: [PATCH 3/5] dnxhddec: implement slice multithreading

Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
---
 libavcodec/dnxhddec.c | 219 ++
 1 file changed, 131 insertions(+), 88 deletions(-)

diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 22d8c0b..fa93407 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -32,10 +32,21 @@
 #include "internal.h"
 #include "thread.h"
 
+typedef struct RowContext {
+DECLARE_ALIGNED(16, int16_t, blocks)[12][64];
+int luma_scale[64];
+int chroma_scale[64];
+GetBitContext gb;
+int last_dc[3];
+int last_qscale;
+} RowContext;
+
 typedef struct DNXHDContext {
 AVCodecContext *avctx;
-GetBitContext gb;
+RowContext *rows;
 BlockDSPContext bdsp;
+const uint8_t* buf;
+int buf_size;
 int64_t cid;///< compression id
 unsigned int width, height;
 enum AVPixelFormat pix_fmt;
@@ -43,30 +54,29 @@ typedef struct DNXHDContext {
 uint32_t mb_scan_index[68]; /* max for 1080p */
 int cur_field;  ///< current interlaced field
 VLC ac_vlc, dc_vlc, run_vlc;
-int last_dc[3];
 IDCTDSPContext idsp;
-DECLARE_ALIGNED(16, int16_t, blocks)[12][64];
 ScanTable scantable;
 const CIDEntry *cid_table;
 int bit_depth; // 8, 10 or 0 if not initialized at all.
 int is_444;
 int mbaff;
 int act;
-void (*decode_dct_block)(struct DNXHDContext *ctx, int16_t *block,
+void (*decode_dct_block)(const struct DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
  int n, int qscale);
-int last_qscale;
-int luma_scale[64];
-int chroma_scale[64];
 } DNXHDContext;
 
 #define DNXHD_VLC_BITS 9
 #define DNXHD_DC_VLC_BITS 7
 
-static void dnxhd_decode_dct_block_8(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_8(const DNXHDContext *ctx,
+ RowContext *row, int16_t *block,
  int n, int qscale);
-static void dnxhd_decode_dct_block_10(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
+  RowContext *row, int16_t *block,
   int n, int qscale);
-static void dnxhd_decode_dct_block_10_444(DNXHDContext *ctx, int16_t *block,
+static void dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
+  RowContext *row, int16_t *block,
   int n, int qscale);
 
 static av_cold int dnxhd_decode_init(AVCodecContext *avctx)
@@ -76,6 +86,11 @@ static av_cold int dnxhd_decode_init(AVCodecContext *avctx)
 ctx->avctx = avctx;
 ctx->cid = -1;
 avctx->colorspace = AVCOL_SPC_BT709;
+
+ctx->rows = av_mallocz_array(avctx->thread_count, sizeof(RowContext));
+if (!ctx->rows)
+return AVERROR(ENOMEM);
+
 return 0;
 }
 
@@ -116,6 +131,20 @@ static int dnxhd_init_vlc(DNXHDContext *ctx, uint32_t cid)
 return 0;
 }
 
+static av_cold int dnxhd_decode_init_thread_copy(AVCodecContext *avctx)
+{
+DNXHDContext *ctx = avctx->priv_data;
+
+// make sure VLC tables will be loaded when cid is parsed
+ctx->cid = -1;
+
+ctx->rows = av_mallocz_array(avctx->thread_count, sizeof(RowContext));
+if (!ctx->rows)
+return AVERROR(ENOMEM);
+
+return 0;
+}
+
 static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame *frame,
const uint8_t *buf, int buf_size,
int first_field)
@@ -240,7 +269,8 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame *frame,
 return 0;
 }
 
-static av_always_inline void dnxhd_decode_dct_block(DNXHDContext *ctx,
+static av_always_inline void dnxhd_decode_dct_block(const DNXHDContext *ctx,
+RowContext *row,
 int16_t *block, int n,
 int qscale,
 int index_bits,
@@ -254,61 +284,61 @@ static 

Re: [FFmpeg-devel] [PATCH] cmdutils: silence unused warnings under --disable-swscale, --disable-swresample

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 10:20 AM, Ganesh Ajjanagadde
 wrote:
> This patch silences such warnings by placing initializations under a header 
> guard,
> see e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919095430=compile=x86_64-archlinux-gcc-disableswscale,
> http://fate.ffmpeg.org/log.cgi?time=20150919095048=compile=x86_64-archlinux-gcc-disableswresample
> for examples of such warnings.
> It also has the benefit of placing library specific #defines next to each 
> other.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  cmdutils.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/cmdutils.c b/cmdutils.c
> index b696008..38d6334 100644
> --- a/cmdutils.c
> +++ b/cmdutils.c
> @@ -533,7 +533,12 @@ int opt_default(void *optctx, const char *opt, const 
> char *arg)
>  #if CONFIG_AVRESAMPLE
>  const AVClass *rc = avresample_get_class();
>  #endif
> -const AVClass *sc, *swr_class;
> +#if CONFIG_SWSCALE
> +const AVClass *sc = sws_get_class();
> +#endif
> +#if CONFIG_SWRESAMPLE
> +const AVClass *swr_class = swr_get_class();
> +#endif
>
>  if (!strcmp(opt, "debug") || !strcmp(opt, "fdebug"))
>  av_log_set_level(AV_LOG_DEBUG);
> @@ -557,7 +562,6 @@ int opt_default(void *optctx, const char *opt, const char 
> *arg)
>  consumed = 1;
>  }
>  #if CONFIG_SWSCALE
> -sc = sws_get_class();
>  if (!consumed && (o = opt_find(, opt, NULL, 0,
>   AV_OPT_SEARCH_CHILDREN | AV_OPT_SEARCH_FAKE_OBJ))) {
>  struct SwsContext *sws = sws_alloc_context();
> @@ -579,7 +583,6 @@ int opt_default(void *optctx, const char *opt, const char 
> *arg)
>  }
>  #endif
>  #if CONFIG_SWRESAMPLE
> -swr_class = swr_get_class();
>  if (!consumed && (o=opt_find(_class, opt, NULL, 0,
>  AV_OPT_SEARCH_CHILDREN | 
> AV_OPT_SEARCH_FAKE_OBJ))) {
>  struct SwrContext *swr = swr_alloc();
> --
> 2.5.2
>

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

Re: [FFmpeg-devel] [PATCHv2] avcodec/videotoolbox: fix -Wunused-but-set-variable

[wm4]

On Sat, 26 Sep 2015 10:55:29 -0400
Ganesh Ajjanagadde  wrote:

> On Sat, Sep 19, 2015 at 5:41 PM, Ganesh Ajjanagadde
>  wrote:
> > pix_fmt was declared presumably to shorten the argument passed to the 
> > function.
> > However, it is currently not being used for such a purpose.
> > This patch simply removes it instead.
> > This fixes -Wunused-but-set-variable reported at e.g:
> > http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.
> >
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  libavcodec/videotoolbox.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index b78238a..ca44491 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -501,7 +501,6 @@ static int videotoolbox_default_init(AVCodecContext 
> > *avctx)
> >  VTDecompressionOutputCallbackRecord decoder_cb;
> >  CFDictionaryRef decoder_spec;
> >  CFDictionaryRef buf_attr;
> > -int32_t pix_fmt;
> >
> >  if (!videotoolbox) {
> >  av_log(avctx, AV_LOG_ERROR, "hwaccel context is not set\n");
> > @@ -528,8 +527,6 @@ static int videotoolbox_default_init(AVCodecContext 
> > *avctx)
> >  break;
> >  }
> >
> > -pix_fmt = videotoolbox->cv_pix_fmt_type;
> > -
> >  decoder_spec = 
> > videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
> >
> >  videotoolbox->cm_fmt_desc = 
> > videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
> > --
> > 2.5.2
> >
> 
> ping

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[wm4]

On Sat, 26 Sep 2015 12:12:44 -0400
Ganesh Ajjanagadde  wrote:

> On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
> > On Sat, 26 Sep 2015 10:59:44 -0400
> > Ganesh Ajjanagadde  wrote:
> >
> >> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  
> >> wrote:
> >> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
> >> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
> >> >>>
> >> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
> >> >>>  wrote:
> >> 
> >>  Fixes -Wunused-function from
> >> 
> >>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
> >> 
> >>  Signed-off-by: Ganesh Ajjanagadde 
> >>  ---
> >>    libavformat/hls.c | 13 -
> >>    1 file changed, 13 deletions(-)
> >> 
> >>  diff --git a/libavformat/hls.c b/libavformat/hls.c
> >>  index c16c770..2ea3a22 100644
> >>  --- a/libavformat/hls.c
> >>  +++ b/libavformat/hls.c
> >>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
> >>  playlist **pls, const char *url
> >>    return 0;
> >>    }
> >> 
> >>  -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
> >>  -{
> >>  -AVDictionary *tmp = NULL;
> >>  -int ret;
> >>  -
> >>  -av_dict_copy(, c->avio_opts, 0);
> >>  -
> >>  -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
> >>  );
> >>  -
> >>  -av_dict_free();
> >>  -return ret;
> >>  -}
> >>  -
> >>    static int url_connect(struct playlist *pls, AVDictionary *opts,
> >>  AVDictionary *opts2)
> >>    {
> >>    AVDictionary *tmp = NULL;
> >>  --
> >>  2.5.2
> >> 
> >> >>>
> >> >>> ping; wm4 basically did not like my old patch: see
> >> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
> >> >>> his thoughts and my response. Here, I delete as opposed to comment out
> >> >>> the lines. I personally do not care about deleting vs commenting out;
> >> >>> but one of the two should be used.
> >> >>
> >> >>
> >> >> If you think the inactive code is worth keeping, put it into a git 
> >> >> branch or
> >> >> tag the commit removing the code.t
> >> >
> >> > I do not have write access, so I will leave it up to you (or anyone
> >> > else pushing) to either apply the old patch or this one (and possibly
> >> > tag it if desired).
> >>
> >> See above for two possiblities on resolving this: either this patch
> >> (optionally tagging it), or simply commenting out the function (see
> >> above for link to old patch).
> >> Ping.
> >
> > Just get rid of this. I had to deal with the HLS code lately, and it
> > was utterly confusing that there was this unused function.
> >
> > Also, this function is so trivial, that anyone really needing it could
> > rewrite it in under a minute, and it'd probably be an improvement too.
> > Even discussing keeping this is a waste of energy.
> 
> Please push this patch then; you have write access and I don't.

Send your SSH key to Michael Niedermayer. I'll apply this patch in a
moment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 12:26 PM, Henrik Gramner  wrote:
> On Sat, Sep 26, 2015 at 6:10 PM, Ganesh Ajjanagadde  wrote:
>> Have you compared with av_always_inline?
>
> No, other functions in that header used "inline", so I went with the
> same for consistency. But I guess we could change those as well if
> av_always_inline is preferable.

Commit  06eb4f0885746b7e8a652d7b6026abf834e04b73 has a fairly detailed
explanation of av_always_inline. Essentially the question is: do we
trust the compiler to do the right thing here? In the worst case, the
compiler will not inline it, in which case what is the performance
penalty?
My suspicion is that the loss is not that bad, and since there is no
inline asm, the compiler in all likelihood won't need the
av_always_inline.

Thus either one should be ok (pick whichever you prefer), and so LGTM.

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 7:11 PM, Michael Niedermayer  wrote:
> On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh Ajjanagadde wrote:
>> This patch results in identical behavior of movenc, and suppresses 
>> -Wstrict-overflow
>> warnings observed in GCC 5.2.
>> I have manually checked that all usages are safe, and overflow possibility 
>> does
>> not exist with this expression rewrite.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/movenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index af03d1e..6e4a1a6 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track, int 
>> cluster_idx)
>>  {
>>  int64_t next_dts;
>>
>> -if (cluster_idx >= track->entry)
>> +if (cluster_idx - track->entry >= 0)
>
> i do not understand what this fixes or why
> also plese quote the actual warnings which are fixed in the commit
> message

I have posted v2 with a more detailed commit message. It should be
self explanatory.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

This patch results in identical behavior of movenc, and suppresses 
-Wstrict-overflow
warnings observed in GCC 5.2:
http://fate.ffmpeg.org/log.cgi?time=20150926231053=compile=x86_64-archlinux-gcc-threads-misc,
"warning: assuming signed overflow does not occur when assuming that (X - c) > 
X is always false [-Wstrict-overflow]"
I have manually checked that all usages are safe, and overflow possibility does
not exist with this expression rewrite.

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

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index af03d1e..6e4a1a6 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track, int 
cluster_idx)
 {
 int64_t next_dts;
 
-if (cluster_idx >= track->entry)
+if (cluster_idx - track->entry >= 0)
 return 0;
 
 if (cluster_idx + 1 == track->entry)
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: dynamically allocate filename buffer

[Marton Balint]

On Sat, 26 Sep 2015, Ganesh Ajjanagadde wrote:


filename was set to an arbitrary 1024 characters. ffplay would thus be unable to
play files whose name exceeds that arbitrary threshold.

This patch dynamically allocates and frees the filename buffer to remove such
limitations.

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] ffplay: dynamically allocate filename buffer

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 4:50 PM, Timo Rothenpieler
 wrote:
>> @@ -3120,7 +3121,10 @@ static VideoState *stream_open(const char *filename, 
>> AVInputFormat *iformat)
>>  is = av_mallocz(sizeof(VideoState));
>>  if (!is)
>>  return NULL;
>> -av_strlcpy(is->filename, filename, sizeof(is->filename));
>> +is->filename = av_malloc(strlen(filename)+1);
>> +if (!is->filename)
>> +goto fail;
>> +strcpy(is->filename, filename);
>
> av_strdup

thanks, updated patch.

>
>>  is->iformat = iformat;
>>  is->ytop= 0;
>>  is->xleft   = 0;
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] ffplay: dynamically allocate filename buffer

[Ganesh Ajjanagadde]

filename was set to an arbitrary 1024 characters. ffplay would thus be unable to
play files whose name exceeds that arbitrary threshold.

This patch dynamically allocates and frees the filename buffer to remove such
limitations.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index fb4af24..a31db85 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -290,7 +290,7 @@ typedef struct VideoState {
 SDL_Rect last_display_rect;
 int eof;
 
-char filename[1024];
+char *filename;
 int width, height, xleft, ytop;
 int step;
 
@@ -1137,6 +1137,7 @@ static void stream_close(VideoState *is)
 sws_freeContext(is->img_convert_ctx);
 #endif
 sws_freeContext(is->sub_convert_ctx);
+av_free(is->filename);
 av_free(is);
 }
 
@@ -3120,7 +3121,9 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 is = av_mallocz(sizeof(VideoState));
 if (!is)
 return NULL;
-av_strlcpy(is->filename, filename, sizeof(is->filename));
+is->filename = av_strdup(filename);
+if (!is->filename)
+goto fail;
 is->iformat = iformat;
 is->ytop= 0;
 is->xleft   = 0;
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] configure: Combine dynamicbase and nxcompat checks

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 02:15:24AM -0400, Alex Smith wrote:
> They were added to binutils in the same version so it's safe to combine.
> 
> Signed-off-by: Alex Smith 
> ---
>  configure | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

applied

thanks

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCHv2 1/2] ffplay: add support for interactive volume control

[Marton Balint]

On Sat, 26 Sep 2015, Ganesh Ajjanagadde wrote:


This is a feature heavily inspired by the mpv player. At the moment, methods
for adjusting volume in ffplay are rather clumsy: either one needs to set it
system-wide, or one needs to set it via the volume filter.

This patch adds key bindings identical to the mpv defaults for muting/unmuting
and increasing/decreasing the volume interactively without any introduction of
external dependencies.

TODO: doc update, possible mouse button bindings (mpv has this).

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index d302793..eada863 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,6 +73,9 @@ const int program_birth_year = 2003;
/* Calculate actual buffer size keeping in mind not cause too frequent audio 
callbacks */
#define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30

+/* Step size for volume control */
+#define SDL_VOLUME_STEP 2


Maybe (SDL_MIX_MAXVOLUME/40) or something like that would be more 
readable/future proof.



+
/* no AV sync correction is done if below the minimum AV sync threshold */
#define AV_SYNC_THRESHOLD_MIN 0.04
/* AV sync correction is done if above the maximum AV sync threshold */
@@ -246,6 +249,8 @@ typedef struct VideoState {
unsigned int audio_buf1_size;
int audio_buf_index; /* in bytes */
int audio_write_buf_size;
+int audio_volume;
+int muted;
struct AudioParams audio_src;
#if CONFIG_AVFILTER
struct AudioParams audio_filter_src;
@@ -1348,6 +1353,17 @@ static void toggle_pause(VideoState *is)
is->step = 0;
}

+static void toggle_mute(VideoState *is)
+{
+is->muted = !is->muted;
+}
+
+static void update_volume(VideoState *is, int sign, int step)
+{
+is->audio_volume += sign * step;
+is->audio_volume = av_clip(is->audio_volume, 0, SDL_MIX_MAXVOLUME);


Update audio_volume in one step to avoid the race condition reading the 
unclipped value from it in the audio thread.



+}
+
static void step_to_next_frame(VideoState *is)
{
/* if the stream is paused unpause it, then step */
@@ -2447,7 +2463,10 @@ static void sdl_audio_callback(void *opaque, Uint8 
*stream, int len)
len1 = is->audio_buf_size - is->audio_buf_index;
if (len1 > len)
len1 = len;
-memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, len1);
+if (is->muted)
+memset(stream, 0, len1);
+else
+SDL_MixAudio(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, 
len1, is->audio_volume);


I guess this only works because most SDL audio drivers reset the audio 
buffer before calling the callback. I am not sure this reliably works 
on all platforms, so probably it is better if you always initalize the 
buffer with zeroes before mixing into it. SDL2 explicitly needs this 
anyway.


Also you may want add a special case for max volume to eliminate the 
performance penalty of the extra memset/memcpy. (Yes, not really 
significant).


Something like:

if (!muted and maxvolume)
  memcpy
else {
  memset
  if (!muted)
Mix
}


len -= len1;
stream += len1;
is->audio_buf_index += len1;
@@ -2634,6 +2653,8 @@ static int stream_component_open(VideoState *is, int 
stream_index)
is->audio_src = is->audio_tgt;
is->audio_buf_size  = 0;
is->audio_buf_index = 0;
+is->audio_volume = SDL_MIX_MAXVOLUME;
+is->muted = 0;


Are you sure you want to reset the settings here? This get called when the 
user changes the audio stream as well. I think it is better if you only 
set these in stream_open.




/* init averaging filter */
is->audio_diff_avg_coef  = exp(log(0.01) / AUDIO_DIFF_AVG_NB);
@@ -3311,6 +3332,17 @@ static void event_loop(VideoState *cur_stream)
case SDLK_SPACE:
toggle_pause(cur_stream);
break;
+case SDLK_m:
+toggle_mute(cur_stream);
+break;
+case SDLK_ASTERISK:


SDLK_KP_MULTIPLY is the numeric keypad key.


+case SDLK_0:
+update_volume(cur_stream, 1, SDL_VOLUME_STEP);
+break;
+case SDLK_SLASH:


SDLK_KP_DIVIDE


+case SDLK_9:
+update_volume(cur_stream, -1, SDL_VOLUME_STEP);
+break;
case SDLK_s: // S: Step to next frame
step_to_next_frame(cur_stream);
break;
--
2.5.3


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

Re: [FFmpeg-devel] [PATCHv2 2/2] ffplay: introduce key repeats

[Marton Balint]

On Sat, 26 Sep 2015, Ganesh Ajjanagadde wrote:


Key repeats have been introduced simply because they improve usability in my
experience for volume, brightness, and other such controls by speeding up the
time taken to go from 0 to max intensity. As a side benefit, this enables rapid
seeking through a file via left/right keys.

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index eada863..fb4af24 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3772,6 +3772,8 @@ int main(int argc, char **argv)
SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
SDL_EventState(SDL_USEREVENT, SDL_IGNORE);

+SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
+


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Michael Niedermayer]

On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh Ajjanagadde wrote:
> This patch results in identical behavior of movenc, and suppresses 
> -Wstrict-overflow
> warnings observed in GCC 5.2.
> I have manually checked that all usages are safe, and overflow possibility 
> does
> not exist with this expression rewrite.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/movenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index af03d1e..6e4a1a6 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track, int 
> cluster_idx)
>  {
>  int64_t next_dts;
>  
> -if (cluster_idx >= track->entry)
> +if (cluster_idx - track->entry >= 0)

i do not understand what this fixes or why
also plese quote the actual warnings which are fixed in the commit
message

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

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


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

Re: [FFmpeg-devel] [PATCHv3] ffplay: add support for interactive volume control

[Marton Balint]

On Sat, 26 Sep 2015, Ganesh Ajjanagadde wrote:


This is a feature heavily inspired by the mpv player. At the moment, methods
for adjusting volume in ffplay are rather clumsy: either one needs to set it
system-wide, or one needs to set it via the volume filter.

This patch adds key bindings identical to the mpv defaults for muting/unmuting
and increasing/decreasing the volume interactively without any introduction of
external dependencies.

TODO: doc update, possible mouse button bindings (mpv has this).


Please add the docs.

Otherwise LGTM.

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

Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Allow compilation with native threads.

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 08:45:13PM +1000, Matt Oliver wrote:
> On 26 September 2015 at 04:08, Michael Niedermayer  wrote:
> 
> > On Fri, Sep 25, 2015 at 09:41:59PM +1000, Matt Oliver wrote:
> > > On 25 September 2015 at 17:58, Matt Oliver  wrote:
> > >
> > > > Allows the decklink device to be used with native win32/os2 threads
> > > > instead of just pthreads.
> > > >
> > > > Note: I dont have a decklink device to test this but It just allows the
> > > > use of the already tested win32/os2 pthread simulation functions so
> > there
> > > > shouldnt be any issues.
> > > >
> > >
> > > Actually added the patch this time :(
> >
> > >  configure   |4 ++--
> > >  libavdevice/decklink_common.cpp |2 +-
> > >  libavdevice/decklink_dec.cpp|2 +-
> > >  libavdevice/decklink_enc.cpp|2 +-
> > >  4 files changed, 5 insertions(+), 5 deletions(-)
> > > 4aa7edd4948d914a5f8f580bda23c9edb931f860
> > 0003-avdevice-decklink-Allow-compilation-with-native-thre.patch
> > > From 13c98e75292284a8b9e17c3a459208c1c06c10cb Mon Sep 17 00:00:00 2001
> > > From: Matt Oliver 
> > > Date: Fri, 25 Sep 2015 17:52:57 +1000
> > > Subject: [PATCH 3/3] avdevice/decklink: Allow compilation with native
> > threads.
> > >
> > > ---
> > >  configure   | 4 ++--
> > >  libavdevice/decklink_common.cpp | 2 +-
> > >  libavdevice/decklink_dec.cpp| 2 +-
> > >  libavdevice/decklink_enc.cpp| 2 +-
> > >  4 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index e21820a..58865d9 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2652,9 +2652,9 @@ avfoundation_indev_extralibs="-framework CoreVideo
> > -framework Foundation -framew
> > >  avfoundation_indev_select="avfoundation"
> > >  bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h
> > dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
> > >  caca_outdev_deps="libcaca"
> > > -decklink_outdev_deps="decklink pthreads"
> > > +decklink_outdev_deps="decklink threads"
> > >  decklink_outdev_extralibs="-lstdc++"
> > > -decklink_indev_deps="decklink pthreads"
> > > +decklink_indev_deps="decklink threads"
> > >  decklink_indev_extralibs="-lstdc++"
> > >  dshow_indev_deps="IBaseFilter"
> > >  dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
> > -lshlwapi"
> > > diff --git a/libavdevice/decklink_common.cpp
> > b/libavdevice/decklink_common.cpp
> > > index ac7964c..476315f 100644
> > > --- a/libavdevice/decklink_common.cpp
> > > +++ b/libavdevice/decklink_common.cpp
> > > @@ -26,7 +26,7 @@
> > >  #include 
> > >  #endif
> > >
> > > -#include 
> > > +#include "libavutil/thread.h"
> > >  #include 
> > >
> > >  extern "C" {
> > > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > > index 747f47e..5c86d94 100644
> > > --- a/libavdevice/decklink_dec.cpp
> > > +++ b/libavdevice/decklink_dec.cpp
> > > @@ -21,7 +21,7 @@
> > >
> > >  #include 
> > >
> > > -#include 
> > > +#include "libavutil/thread.h"
> > >  #include 
> > >
> > >  extern "C" {
> > > diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
> > > index 6c5450f..1c9f728 100644
> > > --- a/libavdevice/decklink_enc.cpp
> > > +++ b/libavdevice/decklink_enc.cpp
> > > @@ -21,7 +21,7 @@
> > >
> > >  #include 
> > >
> > > -#include 
> > > +#include "libavutil/thread.h"
> > >  #include 
> > >
> > >  extern "C" {
> >
> > i have no means to test either but
> > shouldnt libavutil/*.h be under extern "C" { ?
> >
> > [...]
> 
> 
> I didnt have any problems with that on my setup because thread.h when not
> using pthread just declares static inline functions and the pthread header
> adds its own extern "C". If there is some other pthread implementation
> somewhere that doesnt do this then that may be an issue in which case i can
> move it inside the extern "C"

libavutil/thread.h could potentially include any other header from
libavutil, and that is not guranteed to be C++ compatible
this could also change at any point in the future, i dont think
including libavutil headers in C++ withoutr proper "extern C"
is a good idea.

also thread.h includes compat/* stuff which contain more includes
each of them could cause failure

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 07:20:57PM +0200, Hendrik Leppkes wrote:
> On Sat, Sep 26, 2015 at 7:00 PM, wm4  wrote:
> > On Sat, 26 Sep 2015 12:53:58 -0400
> > Ganesh Ajjanagadde  wrote:
> >
> >> On Sat, Sep 26, 2015 at 12:37 PM, wm4  wrote:
> >> > On Sat, 26 Sep 2015 12:12:44 -0400
> >> > Ganesh Ajjanagadde  wrote:
> >> >
> >> >> On Sat, Sep 26, 2015 at 12:06 PM, wm4  wrote:
> >> >> > On Sat, 26 Sep 2015 10:59:44 -0400
> >> >> > Ganesh Ajjanagadde  wrote:
> >> >> >
> >> >> >> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde 
> >> >> >>  wrote:
> >> >> >> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  
> >> >> >> > wrote:
> >> >> >> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
> >> >> >> >>>
> >> >> >> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
> >> >> >> >>>  wrote:
> >> >> >> 
> >> >> >>  Fixes -Wunused-function from
> >> >> >> 
> >> >> >>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
> >> >> >> 
> >> >> >>  Signed-off-by: Ganesh Ajjanagadde 
> >> >> >>  ---
> >> >> >>    libavformat/hls.c | 13 -
> >> >> >>    1 file changed, 13 deletions(-)
> >> >> >> 
> >> >> >>  diff --git a/libavformat/hls.c b/libavformat/hls.c
> >> >> >>  index c16c770..2ea3a22 100644
> >> >> >>  --- a/libavformat/hls.c
> >> >> >>  +++ b/libavformat/hls.c
> >> >> >>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, 
> >> >> >>  struct
> >> >> >>  playlist **pls, const char *url
> >> >> >>    return 0;
> >> >> >>    }
> >> >> >> 
> >> >> >>  -static int open_in(HLSContext *c, AVIOContext **in, const char 
> >> >> >>  *url)
> >> >> >>  -{
> >> >> >>  -AVDictionary *tmp = NULL;
> >> >> >>  -int ret;
> >> >> >>  -
> >> >> >>  -av_dict_copy(, c->avio_opts, 0);
> >> >> >>  -
> >> >> >>  -ret = avio_open2(in, url, AVIO_FLAG_READ, 
> >> >> >>  c->interrupt_callback,
> >> >> >>  );
> >> >> >>  -
> >> >> >>  -av_dict_free();
> >> >> >>  -return ret;
> >> >> >>  -}
> >> >> >>  -
> >> >> >>    static int url_connect(struct playlist *pls, AVDictionary 
> >> >> >>  *opts,
> >> >> >>  AVDictionary *opts2)
> >> >> >>    {
> >> >> >>    AVDictionary *tmp = NULL;
> >> >> >>  --
> >> >> >>  2.5.2
> >> >> >> 
> >> >> >> >>>
> >> >> >> >>> ping; wm4 basically did not like my old patch: see
> >> >> >> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html
> >> >> >> >>>  for
> >> >> >> >>> his thoughts and my response. Here, I delete as opposed to 
> >> >> >> >>> comment out
> >> >> >> >>> the lines. I personally do not care about deleting vs commenting 
> >> >> >> >>> out;
> >> >> >> >>> but one of the two should be used.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> If you think the inactive code is worth keeping, put it into a 
> >> >> >> >> git branch or
> >> >> >> >> tag the commit removing the code.t
> >> >> >> >
> >> >> >> > I do not have write access, so I will leave it up to you (or anyone
> >> >> >> > else pushing) to either apply the old patch or this one (and 
> >> >> >> > possibly
> >> >> >> > tag it if desired).
> >> >> >>
> >> >> >> See above for two possiblities on resolving this: either this patch
> >> >> >> (optionally tagging it), or simply commenting out the function (see
> >> >> >> above for link to old patch).
> >> >> >> Ping.
> >> >> >
> >> >> > Just get rid of this. I had to deal with the HLS code lately, and it
> >> >> > was utterly confusing that there was this unused function.
> >> >> >
> >> >> > Also, this function is so trivial, that anyone really needing it could
> >> >> > rewrite it in under a minute, and it'd probably be an improvement too.
> >> >> > Even discussing keeping this is a waste of energy.
> >> >>
> >> >> Please push this patch then; you have write access and I don't.
> >> >
> >> > Send your SSH key to Michael Niedermayer. I'll apply this patch in a
> >> > moment.
> >>
> >> Michael offered write access a month back, to which I replied saying
> >> that I do not trust myself with it at the moment and would like to
> >> wait a year. I also said that I would reconsider if it is leading to
> >> wasted maintainer time. Our back and forth here suggests that there is
> >> some wastage.
> >>
> >> If no one objects to me getting write access, I will send it to
> >> Michael. Please note that the intention right now is not for any
> >> "maintainership" duties, but simply to ease the application of
> >> reviewed patches.
> >
> > Yes, it's much better for everyone if you just push your own patches,
> > after they have been OK'ed.
> 
> Personally I find giving new people push access after only 3 months of
> activity slightly 

Re: [FFmpeg-devel] [PATCHv2 1/2] ffplay: add support for interactive volume control

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 6:29 PM, Marton Balint  wrote:
>
> On Sat, 26 Sep 2015, Ganesh Ajjanagadde wrote:
>
>> This is a feature heavily inspired by the mpv player. At the moment,
>> methods
>> for adjusting volume in ffplay are rather clumsy: either one needs to set
>> it
>> system-wide, or one needs to set it via the volume filter.
>>
>> This patch adds key bindings identical to the mpv defaults for
>> muting/unmuting
>> and increasing/decreasing the volume interactively without any
>> introduction of
>> external dependencies.
>>
>> TODO: doc update, possible mouse button bindings (mpv has this).
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>> ffplay.c | 34 +-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/ffplay.c b/ffplay.c
>> index d302793..eada863 100644
>> --- a/ffplay.c
>> +++ b/ffplay.c
>> @@ -73,6 +73,9 @@ const int program_birth_year = 2003;
>> /* Calculate actual buffer size keeping in mind not cause too frequent
>> audio callbacks */
>> #define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30
>>
>> +/* Step size for volume control */
>> +#define SDL_VOLUME_STEP 2
>
>
> Maybe (SDL_MIX_MAXVOLUME/40) or something like that would be more
> readable/future proof.

Changed to / 50.

>
>> +
>> /* no AV sync correction is done if below the minimum AV sync threshold */
>> #define AV_SYNC_THRESHOLD_MIN 0.04
>> /* AV sync correction is done if above the maximum AV sync threshold */
>> @@ -246,6 +249,8 @@ typedef struct VideoState {
>> unsigned int audio_buf1_size;
>> int audio_buf_index; /* in bytes */
>> int audio_write_buf_size;
>> +int audio_volume;
>> +int muted;
>> struct AudioParams audio_src;
>> #if CONFIG_AVFILTER
>> struct AudioParams audio_filter_src;
>> @@ -1348,6 +1353,17 @@ static void toggle_pause(VideoState *is)
>> is->step = 0;
>> }
>>
>> +static void toggle_mute(VideoState *is)
>> +{
>> +is->muted = !is->muted;
>> +}
>> +
>> +static void update_volume(VideoState *is, int sign, int step)
>> +{
>> +is->audio_volume += sign * step;
>> +is->audio_volume = av_clip(is->audio_volume, 0, SDL_MIX_MAXVOLUME);
>
>
> Update audio_volume in one step to avoid the race condition reading the
> unclipped value from it in the audio thread.

Ok, updated.

>
>> +}
>> +
>> static void step_to_next_frame(VideoState *is)
>> {
>> /* if the stream is paused unpause it, then step */
>> @@ -2447,7 +2463,10 @@ static void sdl_audio_callback(void *opaque, Uint8
>> *stream, int len)
>> len1 = is->audio_buf_size - is->audio_buf_index;
>> if (len1 > len)
>> len1 = len;
>> -memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index,
>> len1);
>> +if (is->muted)
>> +memset(stream, 0, len1);
>> +else
>> +SDL_MixAudio(stream, (uint8_t *)is->audio_buf +
>> is->audio_buf_index, len1, is->audio_volume);
>
>
> I guess this only works because most SDL audio drivers reset the audio
> buffer before calling the callback. I am not sure this reliably works on all
> platforms, so probably it is better if you always initalize the buffer with
> zeroes before mixing into it. SDL2 explicitly needs this anyway.

Good catch, I only looked at the old documentation.

>
> Also you may want add a special case for max volume to eliminate the
> performance penalty of the extra memset/memcpy. (Yes, not really
> significant).
>
> Something like:
>
> if (!muted and maxvolume)
>   memcpy
> else {
>   memset
>   if (!muted)
> Mix
> }

Changed.

>
>> len -= len1;
>> stream += len1;
>> is->audio_buf_index += len1;
>> @@ -2634,6 +2653,8 @@ static int stream_component_open(VideoState *is, int
>> stream_index)
>> is->audio_src = is->audio_tgt;
>> is->audio_buf_size  = 0;
>> is->audio_buf_index = 0;
>> +is->audio_volume = SDL_MIX_MAXVOLUME;
>> +is->muted = 0;
>
>
> Are you sure you want to reset the settings here? This get called when the
> user changes the audio stream as well. I think it is better if you only set
> these in stream_open.

I am still quite new to the organization of the code, and missed this
in my limited testing. Thanks a lot, changed.

>
>>
>> /* init averaging filter */
>> is->audio_diff_avg_coef  = exp(log(0.01) / AUDIO_DIFF_AVG_NB);
>> @@ -3311,6 +3332,17 @@ static void event_loop(VideoState *cur_stream)
>> case SDLK_SPACE:
>> toggle_pause(cur_stream);
>> break;
>> +case SDLK_m:
>> +toggle_mute(cur_stream);
>> +break;
>> +case SDLK_ASTERISK:
>
>
> SDLK_KP_MULTIPLY is the numeric keypad key.

>
>> +case SDLK_0:
>> +update_volume(cur_stream, 1, SDL_VOLUME_STEP);
>> +break;
>> +case SDLK_SLASH:
>
>
> SDLK_KP_DIVIDE

Ah, I was wondering why mpv had two sets of key bindings for
increase/decrease 

[FFmpeg-devel] [PATCHv3] ffplay: add support for interactive volume control

[Ganesh Ajjanagadde]

This is a feature heavily inspired by the mpv player. At the moment, methods
for adjusting volume in ffplay are rather clumsy: either one needs to set it
system-wide, or one needs to set it via the volume filter.

This patch adds key bindings identical to the mpv defaults for muting/unmuting
and increasing/decreasing the volume interactively without any introduction of
external dependencies.

TODO: doc update, possible mouse button bindings (mpv has this).

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index d302793..f5bc579 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,6 +73,9 @@ const int program_birth_year = 2003;
 /* Calculate actual buffer size keeping in mind not cause too frequent audio 
callbacks */
 #define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30
 
+/* Step size for volume control */
+#define SDL_VOLUME_STEP (SDL_MIX_MAXVOLUME / 50)
+
 /* no AV sync correction is done if below the minimum AV sync threshold */
 #define AV_SYNC_THRESHOLD_MIN 0.04
 /* AV sync correction is done if above the maximum AV sync threshold */
@@ -246,6 +249,8 @@ typedef struct VideoState {
 unsigned int audio_buf1_size;
 int audio_buf_index; /* in bytes */
 int audio_write_buf_size;
+int audio_volume;
+int muted;
 struct AudioParams audio_src;
 #if CONFIG_AVFILTER
 struct AudioParams audio_filter_src;
@@ -1348,6 +1353,16 @@ static void toggle_pause(VideoState *is)
 is->step = 0;
 }
 
+static void toggle_mute(VideoState *is)
+{
+is->muted = !is->muted;
+}
+
+static void update_volume(VideoState *is, int sign, int step)
+{
+is->audio_volume = av_clip(is->audio_volume + sign * step, 0, 
SDL_MIX_MAXVOLUME);
+}
+
 static void step_to_next_frame(VideoState *is)
 {
 /* if the stream is paused unpause it, then step */
@@ -2447,7 +2462,13 @@ static void sdl_audio_callback(void *opaque, Uint8 
*stream, int len)
 len1 = is->audio_buf_size - is->audio_buf_index;
 if (len1 > len)
 len1 = len;
-memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, len1);
+if (!is->muted && is->audio_volume == SDL_MIX_MAXVOLUME)
+memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, 
len1);
+else {
+memset(stream, 0, len1);
+if (!is->muted)
+SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
is->audio_buf_index, len1, is->audio_volume);
+}
 len -= len1;
 stream += len1;
 is->audio_buf_index += len1;
@@ -3122,6 +3143,8 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 init_clock(>audclk, >audioq.serial);
 init_clock(>extclk, >extclk.serial);
 is->audio_clock_serial = -1;
+is->audio_volume = SDL_MIX_MAXVOLUME;
+is->muted = 0;
 is->av_sync_type = av_sync_type;
 is->read_tid = SDL_CreateThread(read_thread, is);
 if (!is->read_tid) {
@@ -3311,6 +3334,17 @@ static void event_loop(VideoState *cur_stream)
 case SDLK_SPACE:
 toggle_pause(cur_stream);
 break;
+case SDLK_m:
+toggle_mute(cur_stream);
+break;
+case SDLK_KP_MULTIPLY:
+case SDLK_0:
+update_volume(cur_stream, 1, SDL_VOLUME_STEP);
+break;
+case SDLK_KP_DIVIDE:
+case SDLK_9:
+update_volume(cur_stream, -1, SDL_VOLUME_STEP);
+break;
 case SDLK_s: // S: Step to next frame
 step_to_next_frame(cur_stream);
 break;
-- 
2.5.3

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

[FFmpeg-devel] [PATCH] doc/ffplay: add information regarding volume control

[Ganesh Ajjanagadde]

ffplay now supports dynamic volume control. This documents the supported
behavior.

Signed-off-by: Ganesh Ajjanagadde 
---
 doc/ffplay.texi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index be696c8..2a35c21 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -197,6 +197,15 @@ Toggle full screen.
 @item p, SPC
 Pause.
 
+@item m
+Toggle mute.
+
+@item 9, 0
+Decrease and increase volume respectively.
+
+@item /, *
+Decrease and increase volume respectively.
+
 @item a
 Cycle audio channel in the current program.
 
-- 
2.5.3

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

[FFmpeg-devel] [PATCH] ffplay: add support for interactive volume control

[Ganesh Ajjanagadde]

This is a feature heavily inspired by the mpv player. At the moment, methods
for adjusting volume in ffplay are rather clumsy: either one needs to set it
system-wide, or one needs to set it via the volume filter.

This patch adds key bindings identical to the mpv defaults for muting/unmuting
and increasing/decreasing the volume interactively without any introduction of
external dependencies.

Key repeats have been introduced simply because they improve usability
in my experience for volume, brightness, and other such controls by speeding up
the time taken to go from 0 to max intensity. As a side benefit, this enables
rapid seeking through a file via left/right keys.

TODO: doc update, possible mouse button bindings (mpv has this).

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 44 +++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index d302793..4f3322b 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,6 +73,9 @@ const int program_birth_year = 2003;
 /* Calculate actual buffer size keeping in mind not cause too frequent audio 
callbacks */
 #define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30
 
+/* Step size for volume control */
+#define SDL_VOLUME_STEP 2
+
 /* no AV sync correction is done if below the minimum AV sync threshold */
 #define AV_SYNC_THRESHOLD_MIN 0.04
 /* AV sync correction is done if above the maximum AV sync threshold */
@@ -246,6 +249,8 @@ typedef struct VideoState {
 unsigned int audio_buf1_size;
 int audio_buf_index; /* in bytes */
 int audio_write_buf_size;
+int audio_volume;
+int muted;
 struct AudioParams audio_src;
 #if CONFIG_AVFILTER
 struct AudioParams audio_filter_src;
@@ -1348,6 +1353,25 @@ static void toggle_pause(VideoState *is)
 is->step = 0;
 }
 
+static void toggle_mute(VideoState *is)
+{
+is->muted = !is->muted;
+}
+
+static void update_volume(VideoState *is, int sign, int step)
+{
+if (sign > 0) {
+is->audio_volume += step;
+if (is->audio_volume > SDL_MIX_MAXVOLUME)
+is->audio_volume = SDL_MIX_MAXVOLUME;
+}
+else {
+is->audio_volume -= step;
+if (is->audio_volume < 0)
+is->audio_volume = 0;
+}
+}
+
 static void step_to_next_frame(VideoState *is)
 {
 /* if the stream is paused unpause it, then step */
@@ -2447,7 +2471,10 @@ static void sdl_audio_callback(void *opaque, Uint8 
*stream, int len)
 len1 = is->audio_buf_size - is->audio_buf_index;
 if (len1 > len)
 len1 = len;
-memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, len1);
+if (is->muted)
+SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
is->audio_buf_index, len1, 0);
+else
+SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
is->audio_buf_index, len1, is->audio_volume);
 len -= len1;
 stream += len1;
 is->audio_buf_index += len1;
@@ -2634,6 +2661,8 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->audio_src = is->audio_tgt;
 is->audio_buf_size  = 0;
 is->audio_buf_index = 0;
+is->audio_volume = SDL_MIX_MAXVOLUME;
+is->muted = 0;
 
 /* init averaging filter */
 is->audio_diff_avg_coef  = exp(log(0.01) / AUDIO_DIFF_AVG_NB);
@@ -3311,6 +3340,17 @@ static void event_loop(VideoState *cur_stream)
 case SDLK_SPACE:
 toggle_pause(cur_stream);
 break;
+case SDLK_m:
+toggle_mute(cur_stream);
+break;
+case SDLK_ASTERISK:
+case SDLK_0:
+update_volume(cur_stream, 1, SDL_VOLUME_STEP);
+break;
+case SDLK_SLASH:
+case SDLK_9:
+update_volume(cur_stream, -1, SDL_VOLUME_STEP);
+break;
 case SDLK_s: // S: Step to next frame
 step_to_next_frame(cur_stream);
 break;
@@ -3740,6 +3780,8 @@ int main(int argc, char **argv)
 SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
 SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
 
+SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
+
 if (av_lockmgr_register(lockmgr)) {
 av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
 do_exit(NULL);
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[Ganesh Ajjanagadde]

On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  wrote:
> On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
>> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
>>>
>>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
>>>  wrote:

 Fixes -Wunused-function from

 http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1

 Signed-off-by: Ganesh Ajjanagadde 
 ---
   libavformat/hls.c | 13 -
   1 file changed, 13 deletions(-)

 diff --git a/libavformat/hls.c b/libavformat/hls.c
 index c16c770..2ea3a22 100644
 --- a/libavformat/hls.c
 +++ b/libavformat/hls.c
 @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
 playlist **pls, const char *url
   return 0;
   }

 -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
 -{
 -AVDictionary *tmp = NULL;
 -int ret;
 -
 -av_dict_copy(, c->avio_opts, 0);
 -
 -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
 );
 -
 -av_dict_free();
 -return ret;
 -}
 -
   static int url_connect(struct playlist *pls, AVDictionary *opts,
 AVDictionary *opts2)
   {
   AVDictionary *tmp = NULL;
 --
 2.5.2

>>>
>>> ping; wm4 basically did not like my old patch: see
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
>>> his thoughts and my response. Here, I delete as opposed to comment out
>>> the lines. I personally do not care about deleting vs commenting out;
>>> but one of the two should be used.
>>
>>
>> If you think the inactive code is worth keeping, put it into a git branch or
>> tag the commit removing the code.t
>
> I do not have write access, so I will leave it up to you (or anyone
> else pushing) to either apply the old patch or this one (and possibly
> tag it if desired).

See above for two possiblities on resolving this: either this patch
(optionally tagging it), or simply commenting out the function (see
above for link to old patch).
Ping.

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

[FFmpeg-devel] [PATCHv2 2/2] ffplay: introduce key repeats

[Ganesh Ajjanagadde]

Key repeats have been introduced simply because they improve usability in my
experience for volume, brightness, and other such controls by speeding up the
time taken to go from 0 to max intensity. As a side benefit, this enables rapid
seeking through a file via left/right keys.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index eada863..fb4af24 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3772,6 +3772,8 @@ int main(int argc, char **argv)
 SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
 SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
 
+SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
+
 if (av_lockmgr_register(lockmgr)) {
 av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
 do_exit(NULL);
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] ffplay: add support for interactive volume control

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 11:16 AM, Timothy Gu  wrote:
> On Sat, Sep 26, 2015 at 7:47 AM, Ganesh Ajjanagadde
>  wrote:
>> diff --git a/ffplay.c b/ffplay.c
>> index d302793..4f3322b 100644
>> --- a/ffplay.c
>> +++ b/ffplay.c
>> @@ -1348,6 +1353,25 @@ static void toggle_pause(VideoState *is)
>>  is->step = 0;
>>  }
>>
>> +static void toggle_mute(VideoState *is)
>> +{
>> +is->muted = !is->muted;
>> +}
>> +
>
>> +static void update_volume(VideoState *is, int sign, int step)
>> +{
>> +if (sign > 0) {
>> +is->audio_volume += step;
>> +if (is->audio_volume > SDL_MIX_MAXVOLUME)
>> +is->audio_volume = SDL_MIX_MAXVOLUME;
>> +}
>> +else {
>> +is->audio_volume -= step;
>> +if (is->audio_volume < 0)
>> +is->audio_volume = 0;
>> +}
>> +}
>
> AV_CLIP?
>
>> +
>>  static void step_to_next_frame(VideoState *is)
>>  {
>>  /* if the stream is paused unpause it, then step */
>> @@ -2447,7 +2471,10 @@ static void sdl_audio_callback(void *opaque, Uint8 
>> *stream, int len)
>>  len1 = is->audio_buf_size - is->audio_buf_index;
>>  if (len1 > len)
>>  len1 = len;
>> -memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, 
>> len1);
>> +if (is->muted)
>
>> +SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
>> is->audio_buf_index, len1, 0);
>
> memset?
>
>> +else
>> +SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
>> is->audio_buf_index, len1, is->audio_volume);
>>  len -= len1;
>>  stream += len1;
>>  is->audio_buf_index += len1;
>
>> @@ -3740,6 +3780,8 @@ int main(int argc, char **argv)
>>  SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
>>  SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
>>
>> +SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, 
>> SDL_DEFAULT_REPEAT_INTERVAL);
>> +
>>  if (av_lockmgr_register(lockmgr)) {
>>  av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
>>  do_exit(NULL);
>
> Separate patch please.

Thanks, updated patches.

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Henrik Gramner]

On Sat, Sep 26, 2015 at 5:18 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Sep 26, 2015 at 11:09 AM, Hendrik Leppkes  wrote:
>> Please ping the actual thread of the patch, and not some seemingly
>> unrelated thread, so people are actually aware of the topic at hand.
>
> Apologies, but since the thread was so old and no one seemed willing
> to apply it at the time, I deleted it from my inbox. I do not know an
> easy way to reply again to the actual thread, at least for the gmail
> web interface that I use.

You can click the sender's e-mail address at the top of the pipermail
web interface to reply with the correct headers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 12:04 PM, Henrik Gramner  wrote:
> They're short enough that inlining them actually reduces code size due to
> all the overhead associated with making a function call.
> ---
>  libavutil/avstring.c | 22 --
>  libavutil/avstring.h | 22 ++
>  2 files changed, 18 insertions(+), 26 deletions(-)
>
> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> index 24d1bb9..57fe74d 100644
> --- a/libavutil/avstring.c
> +++ b/libavutil/avstring.c
> @@ -317,28 +317,6 @@ int av_escape(char **dst, const char *src, const char 
> *special_chars,
>  }
>  }
>
> -int av_isdigit(int c)
> -{
> -return c >= '0' && c <= '9';
> -}
> -
> -int av_isgraph(int c)
> -{
> -return c > 32 && c < 127;
> -}
> -
> -int av_isspace(int c)
> -{
> -return c == ' ' || c == '\f' || c == '\n' || c == '\r' || c == '\t' ||
> -   c == '\v';
> -}
> -
> -int av_isxdigit(int c)
> -{
> -c = av_tolower(c);
> -return av_isdigit(c) || (c >= 'a' && c <= 'f');
> -}
> -
>  int av_match_name(const char *name, const char *names)
>  {
>  const char *p;
> diff --git a/libavutil/avstring.h b/libavutil/avstring.h
> index 234c030..a306e89 100644
> --- a/libavutil/avstring.h
> +++ b/libavutil/avstring.h
> @@ -203,17 +203,27 @@ char *av_strtok(char *s, const char *delim, char 
> **saveptr);
>  /**
>   * Locale-independent conversion of ASCII isdigit.
>   */
> -av_const int av_isdigit(int c);
> +static inline av_const int av_isdigit(int c)
> +{
> +return c >= '0' && c <= '9';
> +}
>
>  /**
>   * Locale-independent conversion of ASCII isgraph.
>   */
> -av_const int av_isgraph(int c);
> +static inline av_const int av_isgraph(int c)
> +{
> +return c > 32 && c < 127;
> +}
>
>  /**
>   * Locale-independent conversion of ASCII isspace.
>   */
> -av_const int av_isspace(int c);
> +static inline av_const int av_isspace(int c)
> +{
> +return c == ' ' || c == '\f' || c == '\n' || c == '\r' || c == '\t' ||
> +   c == '\v';
> +}
>
>  /**
>   * Locale-independent conversion of ASCII characters to uppercase.
> @@ -238,7 +248,11 @@ static inline av_const int av_tolower(int c)
>  /**
>   * Locale-independent conversion of ASCII isxdigit.
>   */
> -av_const int av_isxdigit(int c);
> +static inline av_const int av_isxdigit(int c)
> +{
> +c = av_tolower(c);
> +return av_isdigit(c) || (c >= 'a' && c <= 'f');
> +}
>
>  /**
>   * Locale-independent case-insensitive compare.
> --
> 1.8.3.2

Have you compared with av_always_inline?

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

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Hendrik Leppkes]

On Sat, Sep 26, 2015 at 6:48 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Sep 26, 2015 at 12:26 PM, Henrik Gramner  wrote:
>> On Sat, Sep 26, 2015 at 6:10 PM, Ganesh Ajjanagadde  wrote:
>>> Have you compared with av_always_inline?
>>
>> No, other functions in that header used "inline", so I went with the
>> same for consistency. But I guess we could change those as well if
>> av_always_inline is preferable.
>
> Commit  06eb4f0885746b7e8a652d7b6026abf834e04b73 has a fairly detailed
> explanation of av_always_inline. Essentially the question is: do we
> trust the compiler to do the right thing here? In the worst case, the
> compiler will not inline it, in which case what is the performance
> penalty?
> My suspicion is that the loss is not that bad, and since there is no
> inline asm, the compiler in all likelihood won't need the
> av_always_inline.
>
> Thus either one should be ok (pick whichever you prefer), and so LGTM.

The functions were not inline before, so there is no "penality", and only gain.
For consistency, picking normal inline should be preferred here.

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

[FFmpeg-devel] [PATCH 2/2] checkasm/vp9dsp: add const to suppress "discards const qualifier" warnings

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/vp9dsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 0f45a8b..d175e17 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -107,8 +107,8 @@ static void check_ipred(void)
 #define setdx(a,b,c,d) setpx(a,b,c-(d)+(rnd()%((d)*2+1)))
 #define setsx(a,b,c,d) setdx(a,b,c,(d) << (bit_depth - 8))
 static void randomize_loopfilter_buffers(int bidx, int lineoff, int str,
- int bit_depth, int dir,
- int* E, int* F, int* H, int* I,
+ int bit_depth, int dir, const int *E,
+ const int *F, const int *H, const int 
*I,
  uint8_t *buf0, uint8_t *buf1)
 {
 uint32_t mask = (1 << bit_depth) - 1;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avfilter: add maskedmerge filter

[Moritz Barsnick]

On Sat, Sep 26, 2015 at 10:29:15 +0200, Paul B Mahol wrote:

> +Merge first input stream with second input stream using per pixel weights in
> +the third input stream. 0 means that pixel component from first stream is
> +returned unchanged while 255 for 8-bit videos means that pixel component from
> +second stream is returned unchanged.

> +Merge first input stream with second input stream using per pixel weights in
> +the third input stream.

Merge the first input stream with the second input stream using per
pixel weights in the third input stream.

(I'm not keen on omitting all those "the"s, though it would work in
this sentence.)

> 0 means that pixel component from first stream is returned unchanged
> while 255 for 8-bit videos means that pixel component from second
> stream is returned unchanged.

A value of 0 in the third stream means that the pixel component from
the first stream is returned unchanged, while the maximum value (e.g.
255 for 8-bit videos) means that the pixel component from the second
stream is returned unchanged. Intermediate values define the amount of
merging between both input streams' pixels.

> +This filter accepts the following options:
> +@table @option
> +@item planes
> +Set which planes will be processed as bitmap, unprocessed planes will be
> +copied from first stream.
> +By default all planes will be processed.
> +@end table

Syntax, values? I assume like "extractplanes"'s "planes" option, right?

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

Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Force one stream for hevc and m4v

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 10:47:53AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch forces one stream for the output formats hevc 
> and (raw) m4v.
> 
> Please comment, Carl Eugen

>  rawenc.c |2 ++
>  1 file changed, 2 insertions(+)
> 152253d1707fbee45355abd6364a9ecc592942c8  patchonestream.diff

LGTM

thx

[...]

-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffplay: dynamically allocate filename buffer

[Timo Rothenpieler]

> @@ -3120,7 +3121,10 @@ static VideoState *stream_open(const char *filename, 
> AVInputFormat *iformat)
>  is = av_mallocz(sizeof(VideoState));
>  if (!is)
>  return NULL;
> -av_strlcpy(is->filename, filename, sizeof(is->filename));
> +is->filename = av_malloc(strlen(filename)+1);
> +if (!is->filename)
> +goto fail;
> +strcpy(is->filename, filename);

av_strdup

>  is->iformat = iformat;
>  is->ytop= 0;
>  is->xleft   = 0;



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

Re: [FFmpeg-devel] [PATCH] avfilter: add maskedmerge filter

[Paul B Mahol]

On 9/26/15, Moritz Barsnick  wrote:
> On Sat, Sep 26, 2015 at 10:29:15 +0200, Paul B Mahol wrote:
>
>> +Merge first input stream with second input stream using per pixel weights
>> in
>> +the third input stream. 0 means that pixel component from first stream is
>> +returned unchanged while 255 for 8-bit videos means that pixel component
>> from
>> +second stream is returned unchanged.
>
>> +Merge first input stream with second input stream using per pixel weights
>> in
>> +the third input stream.
>
> Merge the first input stream with the second input stream using per
> pixel weights in the third input stream.
>
> (I'm not keen on omitting all those "the"s, though it would work in
> this sentence.)
>
>> 0 means that pixel component from first stream is returned unchanged
>> while 255 for 8-bit videos means that pixel component from second
>> stream is returned unchanged.
>
> A value of 0 in the third stream means that the pixel component from
> the first stream is returned unchanged, while the maximum value (e.g.
> 255 for 8-bit videos) means that the pixel component from the second
> stream is returned unchanged. Intermediate values define the amount of
> merging between both input streams' pixels.
>
>> +This filter accepts the following options:
>> +@table @option
>> +@item planes
>> +Set which planes will be processed as bitmap, unprocessed planes will be
>> +copied from first stream.
>> +By default all planes will be processed.
>> +@end table
>
> Syntax, values? I assume like "extractplanes"'s "planes" option, right?
>

Nope, its bitmask, 0 - return first stream unchanged, 1 process only
first plane, 2 process only second plane, 3 process 1st and 2nd plane
and so on...

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

[FFmpeg-devel] [PATCH] ffplay: dynamically allocate filename buffer

[Ganesh Ajjanagadde]

filename was set to an arbitrary 1024 characters. ffplay would thus be unable to
play files whose name exceeds that arbitrary threshold.

This patch dynamically allocates and frees the filename buffer to remove such
limitations.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index fb4af24..55435bc 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -290,7 +290,7 @@ typedef struct VideoState {
 SDL_Rect last_display_rect;
 int eof;
 
-char filename[1024];
+char *filename;
 int width, height, xleft, ytop;
 int step;
 
@@ -1137,6 +1137,7 @@ static void stream_close(VideoState *is)
 sws_freeContext(is->img_convert_ctx);
 #endif
 sws_freeContext(is->sub_convert_ctx);
+av_free(is->filename);
 av_free(is);
 }
 
@@ -3120,7 +3121,10 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 is = av_mallocz(sizeof(VideoState));
 if (!is)
 return NULL;
-av_strlcpy(is->filename, filename, sizeof(is->filename));
+is->filename = av_malloc(strlen(filename)+1);
+if (!is->filename)
+goto fail;
+strcpy(is->filename, filename);
 is->iformat = iformat;
 is->ytop= 0;
 is->xleft   = 0;
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] avutil/avstring: Inline some tiny functions

[Henrik Gramner]

On Sat, Sep 26, 2015 at 7:23 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Sep 26, 2015 at 1:18 PM, Hendrik Leppkes  wrote:
>> On Sat, Sep 26, 2015 at 6:48 PM, Ganesh Ajjanagadde  wrote:
>>> Commit  06eb4f0885746b7e8a652d7b6026abf834e04b73 has a fairly detailed
>>> explanation of av_always_inline. Essentially the question is: do we
>>> trust the compiler to do the right thing here? In the worst case, the
>>> compiler will not inline it, in which case what is the performance
>>> penalty?
>>> My suspicion is that the loss is not that bad, and since there is no
>>> inline asm, the compiler in all likelihood won't need the
>>> av_always_inline.
>>>
>>> Thus either one should be ok (pick whichever you prefer), and so LGTM.
>>
>> The functions were not inline before, so there is no "penality", and only 
>> gain.
>> For consistency, picking normal inline should be preferred here.
>
> I meant penalty when comparing inline vs av_always_inline, and not
> current vs proposed patch.
> Anyway, patch is fine.

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Ronald S. Bultje]

Hi,

On Sat, Sep 26, 2015 at 7:19 PM, Ganesh Ajjanagadde 
wrote:

> On Sat, Sep 26, 2015 at 7:11 PM, Michael Niedermayer 
> wrote:
> > On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh Ajjanagadde wrote:
> >> This patch results in identical behavior of movenc, and suppresses
> -Wstrict-overflow
> >> warnings observed in GCC 5.2.
> >> I have manually checked that all usages are safe, and overflow
> possibility does
> >> not exist with this expression rewrite.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavformat/movenc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> index af03d1e..6e4a1a6 100644
> >> --- a/libavformat/movenc.c
> >> +++ b/libavformat/movenc.c
> >> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track,
> int cluster_idx)
> >>  {
> >>  int64_t next_dts;
> >>
> >> -if (cluster_idx >= track->entry)
> >> +if (cluster_idx - track->entry >= 0)
> >
> > i do not understand what this fixes or why
> > also plese quote the actual warnings which are fixed in the commit
> > message
>
> I have posted v2 with a more detailed commit message. It should be
> self explanatory.


Even with the new message, it's still not clear to me what's being fixed.
What does the warning check for? What is the problem in the initial
expression?

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

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[James Almer]

On 9/26/2015 8:41 AM, DeHackEd wrote:
> +/**
> + * 'GA94' is standard in North America for ATSC, but hard 
> coding
> + * this style may not be the right thing to do -- other 
> formats
> + * do exist. This information is not available in the 
> side_data
> + * so we are going with this right now.
> + */
> +x4->pic.extra_sei.payloads[0].payload[3] = 'G';
> +x4->pic.extra_sei.payloads[0].payload[4] = 'A';
> +x4->pic.extra_sei.payloads[0].payload[5] = '9';
> +x4->pic.extra_sei.payloads[0].payload[6] = '4';

AV_WL32(x4->pic.extra_sei.payloads[0].payload + 3, MKTAG('G', 'A', '9', '4'));

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 10:55 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Sep 26, 2015 at 10:32 PM, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Sat, Sep 26, 2015 at 7:19 PM, Ganesh Ajjanagadde 
>> wrote:
>>
>>> On Sat, Sep 26, 2015 at 7:11 PM, Michael Niedermayer 
>>> wrote:
>>> > On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh Ajjanagadde wrote:
>>> >> This patch results in identical behavior of movenc, and suppresses
>>> -Wstrict-overflow
>>> >> warnings observed in GCC 5.2.
>>> >> I have manually checked that all usages are safe, and overflow
>>> possibility does
>>> >> not exist with this expression rewrite.
>>> >>
>>> >> Signed-off-by: Ganesh Ajjanagadde 
>>> >> ---
>>> >>  libavformat/movenc.c | 2 +-
>>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> >> index af03d1e..6e4a1a6 100644
>>> >> --- a/libavformat/movenc.c
>>> >> +++ b/libavformat/movenc.c
>>> >> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track,
>>> int cluster_idx)
>>> >>  {
>>> >>  int64_t next_dts;
>>> >>
>>> >> -if (cluster_idx >= track->entry)
>>> >> +if (cluster_idx - track->entry >= 0)
>>> >
>>> > i do not understand what this fixes or why
>>> > also plese quote the actual warnings which are fixed in the commit
>>> > message
>>>
>>> I have posted v2 with a more detailed commit message. It should be
>>> self explanatory.
>>
>>
>> Even with the new message, it's still not clear to me what's being fixed.
>> What does the warning check for? What is the problem in the initial
>> expression?
>
> Compilers make transformations on the statements in order to possibly
> get better performance when compiled with optimizations. However, some
> of these optimizations require assumptions in the code. In particular,
> the compiler is internally rewriting cluster_idx >= track->entry to
> cluster_idx - track->entry >= 0 internally for some reason (I am not
> an asm/instruction set guy, so I can't comment why it likes this).
> However, such a transformation is NOT always safe as integer
> arithmetic can overflow (try e.g extreme values close to INT_MIN,
> INT_MAX). The warning is spit out since the compiler can't be sure
> that this is safe, but it still wants to do it (I suspect only the
> -O3/-O2 level that try this, can check if you want).
>
> What I have done is manually audit this code to ensure this
> transformation is safe, and rewritten the expression to match what the
> compiler anyway transforms it into. This thereby suppresses the
> warning.

Just checked: it is something triggered at -O3 but not at -O2.
However, this does not change the key points made above.

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

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 07:41:32AM -0400, DeHackEd wrote:
> Assumes 'GA94' format (ATSC standard)
> 
> Signed-off-by: DHE 
> ---
>  doc/encoders.texi|  5 +
>  libavcodec/libx264.c | 37 +
>  2 files changed, 42 insertions(+)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 3550bcc..aabbda0 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2069,6 +2069,11 @@ For example to specify libx264 encoding options with 
> @command{ffmpeg}:
>  ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
> out.mkv
>  @end example
>  
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Only the mpeg2 and h264 decoders provide these. Default is 0 (off).
> +
> +
>  @item x264-params (N.A.)
>  Override the x264 configuration using a :-separated list of key=value
>  parameters.
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 58fcfb0..8540ff9 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -83,6 +83,7 @@ typedef struct X264Context {
>  int avcintra_class;
>  int motion_est;
>  int forced_idr;
> +int a53_cc;
>  char *x264_params;
>  } X264Context;
>  
> @@ -256,6 +257,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
> const AVFrame *frame,
>  int nnal, i, ret;
>  x264_picture_t pic_out = {0};
>  int pict_type;
> +AVFrameSideData *side_data;
>  
>  x264_picture_init( >pic );
>  x4->pic.img.i_csp   = x4->params.i_csp;
> @@ -278,6 +280,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket 
> *pkt, const AVFrame *frame,
>  X264_TYPE_AUTO;
>  
>  reconfig_encoder(ctx, frame);
> +
> +if (x4->a53_cc) {
> +side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
> +if (side_data) {
> +x4->pic.extra_sei.num_payloads = 1;
> +x4->pic.extra_sei.payloads = 
> av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));

missing malloc failure check


> +x4->pic.extra_sei.sei_free = av_free;
> +
> +x4->pic.extra_sei.payloads[0].payload_size = side_data->size 
> + 11;
> +x4->pic.extra_sei.payloads[0].payload = 
> av_mallocz(x4->pic.extra_sei.payloads[0].payload_size);

missing malloc failure check


> +x4->pic.extra_sei.payloads[0].payload_type = 4;
> +memcpy(x4->pic.extra_sei.payloads[0].payload + 10, 
> side_data->data, side_data->size);
> +x4->pic.extra_sei.payloads[0].payload[0] = 181;
> +x4->pic.extra_sei.payloads[0].payload[1] = 0;
> +x4->pic.extra_sei.payloads[0].payload[2] = 49;
> +
> +/**
> + * 'GA94' is standard in North America for ATSC, but hard 
> coding
> + * this style may not be the right thing to do -- other 
> formats
> + * do exist. This information is not available in the 
> side_data
> + * so we are going with this right now.
> + */
> +x4->pic.extra_sei.payloads[0].payload[3] = 'G';
> +x4->pic.extra_sei.payloads[0].payload[4] = 'A';
> +x4->pic.extra_sei.payloads[0].payload[5] = '9';
> +x4->pic.extra_sei.payloads[0].payload[6] = '4';
> +x4->pic.extra_sei.payloads[0].payload[7] = 3;
> +x4->pic.extra_sei.payloads[0].payload[8] =
> +((side_data->size/3) & 0x1f) | 0x40;
> +x4->pic.extra_sei.payloads[0].payload[9] = 0;
> +x4->pic.extra_sei.payloads[0].payload[side_data->size+10] = 
> 255;
> +}
> +}
> +
>  }
>  do {
>  if (x264_encoder_encode(x4->enc, , , frame? >pic: NULL, 
> _out) < 0)
> @@ -821,6 +857,7 @@ static const AVOption options[] = {
>  {"level", "Specify level (as defined by Annex A)", OFFSET(level), 
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
>  {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
>  {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
> +{"a53cc",  "Use A53 Closed Captions (if available)",  
> OFFSET(a53_cc),AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1, VE},

AV_OPT_TYPE_BOOL

[...]

-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 10:32 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Sep 26, 2015 at 7:19 PM, Ganesh Ajjanagadde 
> wrote:
>
>> On Sat, Sep 26, 2015 at 7:11 PM, Michael Niedermayer 
>> wrote:
>> > On Fri, Sep 18, 2015 at 05:15:50PM -0400, Ganesh Ajjanagadde wrote:
>> >> This patch results in identical behavior of movenc, and suppresses
>> -Wstrict-overflow
>> >> warnings observed in GCC 5.2.
>> >> I have manually checked that all usages are safe, and overflow
>> possibility does
>> >> not exist with this expression rewrite.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavformat/movenc.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> >> index af03d1e..6e4a1a6 100644
>> >> --- a/libavformat/movenc.c
>> >> +++ b/libavformat/movenc.c
>> >> @@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track,
>> int cluster_idx)
>> >>  {
>> >>  int64_t next_dts;
>> >>
>> >> -if (cluster_idx >= track->entry)
>> >> +if (cluster_idx - track->entry >= 0)
>> >
>> > i do not understand what this fixes or why
>> > also plese quote the actual warnings which are fixed in the commit
>> > message
>>
>> I have posted v2 with a more detailed commit message. It should be
>> self explanatory.
>
>
> Even with the new message, it's still not clear to me what's being fixed.
> What does the warning check for? What is the problem in the initial
> expression?

Compilers make transformations on the statements in order to possibly
get better performance when compiled with optimizations. However, some
of these optimizations require assumptions in the code. In particular,
the compiler is internally rewriting cluster_idx >= track->entry to
cluster_idx - track->entry >= 0 internally for some reason (I am not
an asm/instruction set guy, so I can't comment why it likes this).
However, such a transformation is NOT always safe as integer
arithmetic can overflow (try e.g extreme values close to INT_MIN,
INT_MAX). The warning is spit out since the compiler can't be sure
that this is safe, but it still wants to do it (I suspect only the
-O3/-O2 level that try this, can check if you want).

What I have done is manually audit this code to ensure this
transformation is safe, and rewritten the expression to match what the
compiler anyway transforms it into. This thereby suppresses the
warning.

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

Re: [FFmpeg-devel] [PATCH] libx264: copy A53 closed captions from source

[Dave Yeo]

On 09/26/15 03:27 AM, DeHackEd wrote:

I think my mail client wrapped some lines. Sorry, this is my first 
patch-by-email.


For Thunderbird, there is an extension, "Toggle Word Wrap" which gives 
the option of disabling word wrap under the Options menu.

Or just attach.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] tests/checkasm/checkasm: remove use of deprecated av_set_cpu_flags_mask()

[Henrik Gramner]

On Sat, Sep 26, 2015 at 2:07 AM, Ganesh Ajjanagadde
 wrote:
> This patch completes the removal of all uses of av_set_cpu_flags_mask, so the
> deprecated function can be removed in a future version bump.

This is incorrect, it will set the flag to zero every time and
therefore never run any tests.

Actually, what is that reasoning for having that function deprecated?
Looking through the commit logs it appears to have been marked as
deprecated in the same merge commit as it was added (from libav, where
it's not deprecated).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] dnxhddec: proper rule for interlaced mb flag

[Michael Niedermayer]

On Sat, Sep 26, 2015 at 02:31:55PM +0200, Christophe Gisquet wrote:
> It currently only applies to CID 1260, but this flag is dependent on
> a higher-level flag located in the header.
> ---
>  libavcodec/dnxhddec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

applied

thanks

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

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


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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 11:09 AM, Hendrik Leppkes  wrote:
> On Sat, Sep 26, 2015 at 5:03 PM, Ganesh Ajjanagadde  wrote:
>> On Sat, Sep 19, 2015 at 9:03 AM, Ganesh Ajjanagadde  wrote:
>>> On Wed, Sep 16, 2015 at 8:29 PM, Michael Niedermayer  
>>> wrote:
 On Tue, Sep 15, 2015 at 04:54:19PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
> > On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje  
> > wrote:
> > > Hi Ganesh,
> > >
> > > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde 
> > > 
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
> > >> precisely, what is the policy of requesting a patch to be merged 
> > >> where
> > >> all objections raised have been addressed via discussion/updated
> > >> patches, and which have not been merged in over 2 weeks due to 
> > >> unknown
> > >> reasons?
> > >>
> > >> In particular, there are 2 patchsets I would like to get merged:
> > >> 1. This I consider an important patch, simply because it solves a 
> > >> trac
> > >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
> > >> which also contains links to the patches. A lot of discussion went on
> > >> around it on the mailing lists, and it is supported strongly by
> > >> Nicolas and me. Michael seemed initially hesitant but later became
> > >> convinced of (at least one of the set's) utility, and one of the
> > >> patches was applied. The only objection I recall was from Hendrik,
> > >> which was addressed by Nicolas in a follow-up.
> > >>
> > >> 2. This I consider much more trivial, but in this case there are no
> > >> remaining objections. However, I still consider it important enough
> > >> for a request to re-examine, as I am doing here. The patchset is more
> > >> recent, 
> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
> > >> and 
> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
> > >
> > >
> > > Trivial patches can be merged after 24-48 hours if there's no 
> > > objections
> > > outstanding. For more elaborate patches, poke anyone for review if 
> > > you feel
> > > it would be helpful.
> > >
> > > In both cases, having push access yourself will hurry this along 
> > > (i.e. you
> > > really should get push access), but in this case I will push later 
> > > today.
> > > If you don't want push access, poke one of us on IRC to do the push 
> > > for
> > > you, or bump the original email with a "poke" or "ping".
> >
> > Thanks. Patches for 2) needs work, and I will be posting it soon.
>
>
> > Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
> > seems ok with it like I mentioned).
>
> there where a few patches, iam not exactly sure which are left and
> what effects they have

> What i objected to and still object to is to cause the terminal to

 i withdraw my objection, ill leave it to others to decide which way is
 better. Some arguments in this thread have sort of changed my oppinion
 from prefering the heuristic to being undecided on what is better
>>>
>>> Ping, any other opinions?
>>
>> It has been a week with no standing objections (Michael withdrew his).
>> Further, there have not been any additional comments. Hence, a ping to
>> apply https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176481.html.
>> More discussion and context: https://trac.ffmpeg.org/ticket/2964.
>>
>
> Please ping the actual thread of the patch, and not some seemingly
> unrelated thread, so people are actually aware of the topic at hand.

Apologies, but since the thread was so old and no one seemed willing
to apply it at the time, I deleted it from my inbox. I do not know an
easy way to reply again to the actual thread, at least for the gmail
web interface that I use.

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

Re: [FFmpeg-devel] [PATCH] ffplay: add support for interactive volume control

[Timothy Gu]

On Sat, Sep 26, 2015 at 7:47 AM, Ganesh Ajjanagadde
 wrote:
> diff --git a/ffplay.c b/ffplay.c
> index d302793..4f3322b 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -1348,6 +1353,25 @@ static void toggle_pause(VideoState *is)
>  is->step = 0;
>  }
>
> +static void toggle_mute(VideoState *is)
> +{
> +is->muted = !is->muted;
> +}
> +

> +static void update_volume(VideoState *is, int sign, int step)
> +{
> +if (sign > 0) {
> +is->audio_volume += step;
> +if (is->audio_volume > SDL_MIX_MAXVOLUME)
> +is->audio_volume = SDL_MIX_MAXVOLUME;
> +}
> +else {
> +is->audio_volume -= step;
> +if (is->audio_volume < 0)
> +is->audio_volume = 0;
> +}
> +}

AV_CLIP?

> +
>  static void step_to_next_frame(VideoState *is)
>  {
>  /* if the stream is paused unpause it, then step */
> @@ -2447,7 +2471,10 @@ static void sdl_audio_callback(void *opaque, Uint8 
> *stream, int len)
>  len1 = is->audio_buf_size - is->audio_buf_index;
>  if (len1 > len)
>  len1 = len;
> -memcpy(stream, (uint8_t *)is->audio_buf + is->audio_buf_index, len1);
> +if (is->muted)

> +SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
> is->audio_buf_index, len1, 0);

memset?

> +else
> +SDL_MixAudio(stream, (uint8_t *)is->audio_buf + 
> is->audio_buf_index, len1, is->audio_volume);
>  len -= len1;
>  stream += len1;
>  is->audio_buf_index += len1;

> @@ -3740,6 +3780,8 @@ int main(int argc, char **argv)
>  SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
>  SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
>
> +SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, 
> SDL_DEFAULT_REPEAT_INTERVAL);
> +
>  if (av_lockmgr_register(lockmgr)) {
>  av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
>  do_exit(NULL);

Separate patch please.

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function

[wm4]

On Sat, 26 Sep 2015 10:59:44 -0400
Ganesh Ajjanagadde  wrote:

> On Fri, Sep 18, 2015 at 11:16 AM, Ganesh Ajjanagadde  wrote:
> > On Fri, Sep 18, 2015 at 11:08 AM, wm4  wrote:
> >> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
> >>>
> >>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
> >>>  wrote:
> 
>  Fixes -Wunused-function from
> 
>  http://fate.ffmpeg.org/report.cgi?time=20150820031140=arm64-darwin-clang-apple-5.1
> 
>  Signed-off-by: Ganesh Ajjanagadde 
>  ---
>    libavformat/hls.c | 13 -
>    1 file changed, 13 deletions(-)
> 
>  diff --git a/libavformat/hls.c b/libavformat/hls.c
>  index c16c770..2ea3a22 100644
>  --- a/libavformat/hls.c
>  +++ b/libavformat/hls.c
>  @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
>  playlist **pls, const char *url
>    return 0;
>    }
> 
>  -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
>  -{
>  -AVDictionary *tmp = NULL;
>  -int ret;
>  -
>  -av_dict_copy(, c->avio_opts, 0);
>  -
>  -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
>  );
>  -
>  -av_dict_free();
>  -return ret;
>  -}
>  -
>    static int url_connect(struct playlist *pls, AVDictionary *opts,
>  AVDictionary *opts2)
>    {
>    AVDictionary *tmp = NULL;
>  --
>  2.5.2
> 
> >>>
> >>> ping; wm4 basically did not like my old patch: see
> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
> >>> his thoughts and my response. Here, I delete as opposed to comment out
> >>> the lines. I personally do not care about deleting vs commenting out;
> >>> but one of the two should be used.
> >>
> >>
> >> If you think the inactive code is worth keeping, put it into a git branch 
> >> or
> >> tag the commit removing the code.t
> >
> > I do not have write access, so I will leave it up to you (or anyone
> > else pushing) to either apply the old patch or this one (and possibly
> > tag it if desired).
> 
> See above for two possiblities on resolving this: either this patch
> (optionally tagging it), or simply commenting out the function (see
> above for link to old patch).
> Ping.

Just get rid of this. I had to deal with the HLS code lately, and it
was utterly confusing that there was this unused function.

Also, this function is so trivial, that anyone really needing it could
rewrite it in under a minute, and it'd probably be an improvement too.
Even discussing keeping this is a waste of energy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]h264: Fix ticket #3147 H264 - Wrong field order

[Kieran Kunhya]

On 26 September 2015 at 16:59, Thomas Mundt
 wrote:
> Hi,
> some h264 encoders, like broadcast avc-intra in this case

avc-intra sets pic-struct. Is this new?

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil/opencl: Fix volatile pointer

[Timo Rothenpieler]

> On Thu, Sep 24, 2015 at 05:12:23PM +0200, Timo Rothenpieler wrote:
>> ---
>>  libavutil/opencl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> LGTM

pushed this one.

If anyone with OpenCL experience could have a look at the other two,
that'd be highly apreciated.
I never worked with OpenCL before and it's quite possible that i made
some mistakes that degrade performance or something like that.



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

Re: [FFmpeg-devel] [PATCH 1/2] checkasm/Makefile: add missing testclean target

[Henrik Gramner]

On Sat, Sep 26, 2015 at 9:23 PM, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [FFmpeg-devel] [PATCH 2/2] checkasm/vp9dsp: add const to suppress "discards const qualifier" warnings

[Henrik Gramner]

On Sat, Sep 26, 2015 at 9:23 PM, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/vp9dsp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [FFmpeg-devel] [PATCH]libx264: Disable global header for AVC-Intra encoding

[Kieran Kunhya]

On 26 September 2015 at 15:25, Thomas Mundt
 wrote:
> This will fix AVC-Intra encoding in .mov container.
> Regards,Thomas

ok, assuming fate passes.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] checkasm/Makefile: add missing testclean target

[James Almer]

On 9/26/2015 4:29 PM, Henrik Gramner wrote:
> On Sat, Sep 26, 2015 at 9:23 PM, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  tests/checkasm/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Lgtm.

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