Re: [FFmpeg-devel] [PATCH] all: use M_SQRT1_2, M_SQRT2, M_PI

[Derek Buitenhuis]

On 11/19/2015 4:12 PM, Ganesh Ajjanagadde wrote:
> Confirmed just now bit-exactness via the hex print:
> 0x1.921fb54442d18p+1
> 0x1.921fb54442d18p+1.

Paul uses FreeBSD, if I recall. This is probably with glibc.

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Derek Buitenhuis]

On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote:
> I will come on Monday if that's okay... could setup a time that works
> for you. I'm based in Melbourne Australia

Most of the channel is usually around during daytime GMT/CET hours.

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Derek Buitenhuis]

On 1/8/2016 6:55 AM, Jean-Yves Avenard wrote:
> We originally had configured AVCodecContext::thread_count to 0, which
> on the machines running the tests would end up creating 8 threads per
> decoder.
> On windows 32 bits, that would amount in thousand of threads being
> created for that particular test which would typically fail with OOM
> (Windows XP would fail to create more than 1380 threads).

FWIW, I have run into this on x64_64 Linux, on transcoding machines,
at work, as well.

This seems to be a rather contentious subject. Would you be amenable to
perhaps joining #ffmpeg-devel to discuss in real time? In my experience,
stuff gets cleared up a lot faster, and with few misunderstandings / large
mailing list flames/threads, for subjects like these, in such a setting.
That's just my 2 cents of course.

Cheers,

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

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[Derek Buitenhuis]

On 5/19/2016 2:18 PM, Derek Buitenhuis wrote:
> On 5/19/2016 2:12 PM, Michael Niedermayer wrote:
>> if derek still wants to leave in 2 weeks then so be it, its his choice
>> but i really hope things can be resolved in a way that everyone
>> stays and works together and is happy
> 
> I will wait 2 weeks.

I've read the "CoC" and IRC meeting. My feelings have not changed.

Please push.

- Derek

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add Cineform HD Decoder

[Derek Buitenhuis]

On 1/10/2016 1:54 AM, James Almer wrote:
>> +AVCodec ff_cfhd_decoder = {
>> +.name   = "cfhd",
>> +.long_name  = NULL_IF_CONFIG_SMALL("Cineform HD"),
>> +.type   = AVMEDIA_TYPE_VIDEO,
>> +.id = AV_CODEC_ID_CFHD,
>> +.priv_data_size = sizeof(CFHDContext),
>> +.init   = cfhd_decode_init,
>> +.close  = cfhd_close_decoder,
>> +.decode = cfhd_decode,
>> +.capabilities   = AV_CODEC_CAP_EXPERIMENTAL | AV_CODEC_CAP_DR1 | 
>> AV_CODEC_CAP_FRAME_THREADS,
> 
> Unless the decoder is prone to crash, i don't think setting it as 
> experimental is
> a good idea. I assume most players out there will not use it because of that 
> flag.

>> +/* some special codewords, not sure what they all mean */
>> +#define TABLE_9_BAND_END1 0x1C7859Eh
>> +#define TABLE_9_BAND_END_LEN1 25
>> +#define TABLE_9_BAND_END2 0x38F0B3Fh
>> +#define TABLE_9_BAND_END_LEN2 26
>> +#define TABLE_9_BAND_END3 0x38F0B3Eh
>> +#define TABLE_9_BAND_END_LEN3 26
> 
> All these are unused.

It stands to reason they shall be used the the future. Perhaps they can be 
added to multimediawiki?


>> +.id= AV_CODEC_ID_CFHD,
>> +.type  = AVMEDIA_TYPE_VIDEO,
>> +.name  = "cfhd",
>> +.long_name = NULL_IF_CONFIG_SMALL("Cineform HD"),
> 
> Missing .props

Internal props too (thread safe init pls!).

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

[FFmpeg-devel] [PATCH] mov: Add an option to toggle dref opening

[Derek Buitenhuis]

This feature is mostly only used by NLE software, and is
both of dubious value being enabled by default, and a
possible security risk.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavformat/isom.h|  1 +
 libavformat/mov.c | 22 +-
 libavformat/version.h |  4 ++--
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index e07dc0e9..99bc7be 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -227,6 +227,7 @@ typedef struct MOVContext {
 struct AVAES *aes_decrypt;
 uint8_t *decryption_key;
 int decryption_key_len;
+int enable_drefs;
 } MOVContext;
 
 int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4cc5ff2..106bdcf 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3051,13 +3051,23 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 
 if (sc->dref_id-1 < sc->drefs_count && sc->drefs[sc->dref_id-1].path) {
 MOVDref *dref = >drefs[sc->dref_id - 1];
-if (mov_open_dref(c, >pb, c->fc->filename, dref,
-  >fc->interrupt_callback) < 0)
-av_log(c->fc, AV_LOG_ERROR,
-   "stream %d, error opening alias: path='%s', dir='%s', "
-   "filename='%s', volume='%s', nlvl_from=%d, nlvl_to=%d\n",
+if (c->enable_drefs) {
+if (mov_open_dref(c, >pb, c->fc->filename, dref,
+  >fc->interrupt_callback) < 0)
+av_log(c->fc, AV_LOG_ERROR,
+   "stream %d, error opening alias: path='%s', dir='%s', "
+   "filename='%s', volume='%s', nlvl_from=%d, 
nlvl_to=%d\n",
+   st->index, dref->path, dref->dir, dref->filename,
+   dref->volume, dref->nlvl_from, dref->nlvl_to);
+} else {
+av_log(c->fc, AV_LOG_WARNING,
+   "Skipped opening external track: "
+   "stream %d, alias: path='%s', dir='%s', "
+   "filename='%s', volume='%s', nlvl_from=%d, nlvl_to=%d."
+   "Set enable_drefs to allow this.\n",
st->index, dref->path, dref->dir, dref->filename,
dref->volume, dref->nlvl_from, dref->nlvl_to);
+}
 } else {
 sc->pb = c->fc->pb;
 sc->pb_is_copied = 1;
@@ -5219,6 +5229,8 @@ static const AVOption mov_options[] = {
 AV_OPT_TYPE_BINARY, {.str="77214d4b196a87cd520045fd20a51d67"},
 .flags = AV_OPT_FLAG_DECODING_PARAM },
 { "decryption_key", "The media decryption key (hex)", 
OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM 
},
+{ "enable_drefs", "Enable external track support.", OFFSET(enable_drefs), 
AV_OPT_TYPE_BOOL,
+{.i64 = 0}, 0, 1, FLAGS },
 
 { NULL },
 };
diff --git a/libavformat/version.h b/libavformat/version.h
index ad9ba63..a4feab8 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,8 +30,8 @@
 #include "libavutil/version.h"
 
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  21
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MINOR  22
+#define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

[Derek Buitenhuis]

* Upstream libutvideo doesn't build as a lib, and Linux is not supported.
  It has no API.
* The fork that was used as an argument to keep support is *also* broken and
  unmaintained now, and it's maintainer/author is fine with removal.
* A third fork on github, *also* doesn't work.
* The only working library that I can find is a package for an obscure distro,
  in German only, with a bunch of patches applied.
* The ASM in libutvideo doesn't even work on x86_64.
* More, I'm sure others can fill in.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 Changelog|   1 +
 LICENSE.md   |   3 -
 MAINTAINERS  |   1 -
 configure|   6 -
 libavcodec/Makefile  |   3 -
 libavcodec/allcodecs.c   |   1 -
 libavcodec/libutvideo.h  |  72 ---
 libavcodec/libutvideodec.cpp | 272 -
 libavcodec/libutvideoenc.cpp | 281 ---
 libavcodec/version.h |   4 +-
 10 files changed, 3 insertions(+), 641 deletions(-)
 delete mode 100644 libavcodec/libutvideo.h
 delete mode 100644 libavcodec/libutvideodec.cpp
 delete mode 100644 libavcodec/libutvideoenc.cpp

diff --git a/Changelog b/Changelog
index 749eb61..424434d 100644
--- a/Changelog
+++ b/Changelog
@@ -67,6 +67,7 @@ version :
 - streamselect video and astreamselect audio filter
 - swaprect filter
 - metadata video and ametadata audio filter
+- libutvideo encoder and decoder removed
 
 
 version 2.8:
diff --git a/LICENSE.md b/LICENSE.md
index 0c53d0f..6c45705 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -17,8 +17,6 @@ Specifically, the GPL parts of FFmpeg are:
   - `libavcodec/x86/flac_dsp_gpl.asm`
   - `libavcodec/x86/idct_mmx.c`
   - `libavfilter/x86/vf_removegrain.asm`
-- libutvideo encoding/decoding wrappers in
-  `libavcodec/libutvideo*.cpp`
 - the X11 grabber in `libavdevice/x11grab.c`
 - the swresample test app in
   `libswresample/swresample-test.c`
@@ -86,7 +84,6 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
-- libutvideo
 - libvidstab
 - libx264
 - libx265
diff --git a/MAINTAINERS b/MAINTAINERS
index b62a4f8..d7d4af1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -209,7 +209,6 @@ Codecs:
   libschroedinger*  David Conrad
   libspeexdec.c Justin Ruggles
   libtheoraenc.cDavid Conrad
-  libutvideo*   Derek Buitenhuis
   libvorbis.c   David Conrad
   libvpx*   James Zern
   libx264.c Mans Rullgard, Jason Garrett-Glaser
diff --git a/configure b/configure
index 2148f11..90a4169 100755
--- a/configure
+++ b/configure
@@ -251,7 +251,6 @@ External library support:
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
-  --enable-libutvideo  enable Ut Video encoding and decoding via 
libutvideo [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
@@ -1475,7 +1474,6 @@ EXTERNAL_LIBRARY_LIST="
 libtesseract
 libtheora
 libtwolame
-libutvideo
 libv4l2
 libvidstab
 libvo_amrwbenc
@@ -2637,8 +2635,6 @@ libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
-libutvideo_decoder_deps="libutvideo"
-libutvideo_encoder_deps="libutvideo"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
 libvorbis_encoder_deps="libvorbis"
@@ -4875,7 +4871,6 @@ die_license_disabled gpl frei0r
 die_license_disabled gpl libcdio
 die_license_disabled gpl librubberband
 die_license_disabled gpl libsmbclient
-die_license_disabled gpl libutvideo
 die_license_disabled gpl libvidstab
 die_license_disabled gpl libx264
 die_license_disabled gpl libx265
@@ -5513,7 +5508,6 @@ enabled libtheora && require libtheora 
theora/theoraenc.h th_info_init -
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
-enabled libutvideo&& require_cpp utvideo "stdint.h stdlib.h 
utvideo/utvideo.h utvideo/Codec.h" 'CCodec*' -lutvideo -lstdc++
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl
 enabled libvidstab&&a

Re: [FFmpeg-devel] [PATCH] options_table: update maximum bitrate limit

[Derek Buitenhuis]

On 2/10/2016 3:26 PM, Rostislav Pehlivanov wrote:
> The type of the option has been changed but the limit was apparently 
> forgotten.
> Some video codes can handle bitrates of over ~2.2 Gbps (like VC-2).
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/options_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Since bit_rate is 64 bits now, I see no issue.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

[Derek Buitenhuis]

On 2/10/2016 4:33 PM, Paul B Mahol wrote:
> I'm fine by this, but it would be nice to have SIMD and 10 bit support
> in decoder.

I agree with the latter.

I'd argue, however, we don't actually support 10-bit via the
wrapper anyway, since you can't even build the library. ;)

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

[Derek Buitenhuis]

On 2/12/2016 5:03 PM, Paul B Mahol wrote:
> make install (as root)and then build FFmpeg with
>> libutvideo support.

Last time I tried this, it failed to configure, due to duplicated symbol 'main'.

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

[FFmpeg-devel] [PATCH][RFC/UNTESTED] swscale/slice: Actually use the buffers' strides

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
I don't know how this could ever have worked, but I also am having a hard time
testing the sliced path in swscale... has it even ever been run?

I have CC'd the original author of this code in the hopes that he
can confirm or deny that this is a correct "fix".
---
diff --git a/libswscale/slice.c b/libswscale/slice.c
index 66fe413..a701487 100644
--- a/libswscale/slice.c
+++ b/libswscale/slice.c
@@ -159,9 +159,9 @@ int ff_init_slice_from_src(SwsSlice * s, uint8_t *src[4], 
int stride[4], int src
 lumY + lumH};
 
 const uint8_t *src_[4] = {src[0] + (relative ? 0 : start[0]) * stride[0],
-  src[1] + (relative ? 0 : start[1]) * stride[0],
-  src[2] + (relative ? 0 : start[2]) * stride[0],
-  src[3] + (relative ? 0 : start[3]) * stride[0]};
+  src[1] + (relative ? 0 : start[1]) * stride[1],
+  src[2] + (relative ? 0 : start[2]) * stride[2],
+  src[3] + (relative ? 0 : start[3]) * stride[3]};
 
 s->width = srcW;
 
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/libutvideoenc: fix compiler warnings, initialize the correct type

[Derek Buitenhuis]

On 2/4/2016 2:12 AM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/libutvideoenc.cpp |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

My personal preference, and that shared by every single person I've
asked, is that we removed this.

As it stands:
- Upstream libutvideo doesn't build as a lib, and Linux is not supported.
- The fork that was used as an argument to keep support is *also* broken and
  unmaintained now, and it's maintainer/author is fine with removal.
- A third fork on github, *also* doesn't work.
- The only working library that I can find is a package for an obscure distro,
  in German only, with a bunch of patches applied.
- The ASM in libutvideo doesn't even work on x86_64.
- More, I'm sure others can fill in.

> --- a/libavcodec/libutvideoenc.cpp
> +++ b/libavcodec/libutvideoenc.cpp
> @@ -229,9 +229,9 @@ static av_cold int utvideo_encode_close(AVCodecContext 
> *avctx)
>  #define OFFSET(x) offsetof(UtVideoContext, x)
>  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
> -{ "pred", "Prediction method", OFFSET(pred), AV_OPT_TYPE_INT, 0, 0, 2, 
> VE, "pred" },
> -{ "left",   NULL, 0, AV_OPT_TYPE_CONST, 0, INT_MIN, INT_MAX, VE, "pred" 
> },
> -{ "median",   NULL, 0, AV_OPT_TYPE_CONST, 2, INT_MIN, INT_MAX, VE, 
> "pred" },
> +{ "pred", "Prediction method", OFFSET(pred), AV_OPT_TYPE_INT, {i64: 0}, 
> 0, 2, VE, "pred" },
> +{ "left",   NULL, 0, AV_OPT_TYPE_CONST, {i64: 0}, INT_MIN, INT_MAX, VE, 
> "pred" },
> +{ "median",   NULL, 0, AV_OPT_TYPE_CONST, {i64: 2}, INT_MIN, INT_MAX, 
> VE, "pred" },

Is this even valid C++, or some GNU extension?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: Move prediction_method to codec private options

[Derek Buitenhuis]

On 2/4/2016 1:56 AM, Michael Niedermayer wrote:
> this breaks existing command line usage like -pred 3
> and "3" previously lacked a named constant so people had to use a
> litteral 3 i think

Already smacked around Vittorio for that. It can be fixed, or it can be 
left/documented.

I have no opinion on which.

> this change should be documented if its left that way

[...]

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

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

[Derek Buitenhuis]

On 2/4/2016 4:14 PM, Rostislav Pehlivanov wrote:
> Do we even support MSVC versions old enough to error on compilation for
> mixed declarations and variables? Will c99conv actually error if it
> encounters such code?

Yes, and, I believe, yes.

> As for the other compilers, I bet they're sufficiently old, disused and
> miscompiling to possibly ignore them.

No idea.

- Derek

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

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

[Derek Buitenhuis]

On 2/4/2016 3:48 PM, Rostislav Pehlivanov wrote:
> The only reason this existed was to allow for old compilers to not
> complain/compile the project's code. As far as I know, we no longer have
> support for such compilers hence this flag has become useless and we
> have no reason to continue dragging so much behind the current standard
> of the C language.

We do. Older MSVC (via c99conv), and I am sure others.

> Michael Niedermayer has already expressed interest in removing said flag:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/187833.html

[...]

> This will essentially help bring the project to near 21st century age
> and finally allow for developers to save on line numbers by NOT having
> to define the variable around which a for loop needs to iterate (e.g.
> have for (int i = 0; i < N; i++) loops instead of having to define 'i'
> at the start of the function like a normal variable), as well as more of
> the syntactic sugar C99 permits.

I do mind for loops, but I consider, along with VLAs, mixed code and var
decls to be bad practice, myself. If you have a ton of variables declared
at the top of blocks, I argue you have other issues. I also believe mixing
code/var decls makes variable shadowing much easier. My 2 cents, for what
little it is worth.

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

Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid

[Derek Buitenhuis]

On 2/5/2016 2:19 PM, Michael Niedermayer wrote:
> because the code builds the header a few lines above, i assume
> the header we just build is correct

Perhaps you could elaborate what CID1351343 is then, in the commit
messages.

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

Re: [FFmpeg-devel] [PATCH]lavc/libx26x: Allow to fail if wrong options were passed

[Derek Buitenhuis]

On 1/28/2016 10:35 AM, Carl Eugen Hoyos wrote:
> Attached patch tries to address ticket #4947.
> (only tested with libx264)

I don't think STRICT_STD_COMPLIANCE is the correct thing to use here.

It looks like explode mode is better suited.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

[Derek Buitenhuis]

On 1/27/2016 9:13 PM, Derek Buitenhuis wrote:
> It could accidentally divide by zero if num was zero.
> 
> Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
> ---
>  libavcodec/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

[21:58] <@nevcairiel> Daemon404: you should push that diff-by-zero patch, half 
of fate is turning yellow

- Derek

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

Re: [FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

[Derek Buitenhuis]

On 1/27/2016 10:03 PM, Michael Niedermayer wrote:
> is the avctx->ticks_per_frame != 0 check needed?

I have no idea, actually.

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

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: speed up scan data copy

[Derek Buitenhuis]

On 1/27/2016 8:35 PM, Hendrik Leppkes wrote:
> This broke building on msvc, ssize_t is not available there.

Shouldn't it be ptrdiff_t anyway?

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

[FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

[Derek Buitenhuis]

It could accidentally divide by zero if num was zero.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavcodec/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 13ee243..491d8ea 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1475,7 +1475,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!avctx->rc_initial_buffer_occupancy)
 avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3 / 4;
 
-if (avctx->ticks_per_frame &&
+if (avctx->ticks_per_frame && avctx->time_base.num &&
 avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
 av_log(avctx, AV_LOG_ERROR,
"ticks_per_frame %d too large for the timebase %d/%d.",
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 2/2] libx265: Enable 12-bit encoding

[Derek Buitenhuis]

On 1/27/2016 12:10 AM, Stephen Hutchinson wrote:
> The configure detection is bumped to X265_BUILD >= 68,
> since API version 68 corresponds with the x265 1.8
> release tarball.

Was 68 the first API version it was in, or merely the tarball?

I would prefer the actual version it was introduced in (or made useful).

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

Re: [FFmpeg-devel] [PATCH 1/2] libx265: Remove experimental flag when encoding 4:2:2 and 4:4:4

[Derek Buitenhuis]

On 1/27/2016 12:10 AM, Stephen Hutchinson wrote:
> 4:2:2 and 4:4:4 support in the HEVC standard was approved in
> October 2014 as part of HEVC Version 2 and published in
> January 2015:
> 
> http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296
> http://www.itu.int/rec/T-REC-H.265-201410-S
> https://hevc.hhi.fraunhofer.de/rext
> ---
>  libavcodec/libx265.c | 8 
>  1 file changed, 8 deletions(-)

OK.

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

Re: [FFmpeg-devel] [PATCH] avutil: Rename FF_CEIL_COMPAT to AV_CEIL_COMPAT

[Derek Buitenhuis]

On 1/27/2016 3:21 PM, Derek Buitenhuis wrote:
> Libav, for some reason, merged this as a public API function. This will
> aid in future merges.
> 
> A define is left for backwards compat, just in case some person
> used it, since it is in a public header.
> 
> Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
> ---

ACKed by Clement on IRC>

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

Re: [FFmpeg-devel] [PATCH 3/3 v2] ffprobe: Deprecate stream timecode field and add frame side data timecode field

[Derek Buitenhuis]

On 1/31/2016 2:36 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
> ---
>  ffprobe.c | 6 ++
>  1 file changed, 6 insertions(+)

OK'd by Clement on IRC.

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

Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data

[Derek Buitenhuis]

On 1/31/2016 8:02 PM, Michael Niedermayer wrote:
> whats the first frame of a gop ?
> for example there may be B frames prior to an I frame in display
> order

In this case, it's the first frame output after decoding the GOP header.

Do you think there is a better way to word it?

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] mpeg12dec: Export GOP timecodes as side data

[Derek Buitenhuis]

On 1/31/2016 9:18 PM, Michael Niedermayer wrote:
> is it intended to set this also when ret < 0

No, you're right, it should not be. Amended locally.

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

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

[Derek Buitenhuis]

On 1/28/2016 12:03 PM, Paul B Mahol wrote:
> Hi,
> 
> 2nd version attached.

[...]

> +{"weights_file",  NULL, OFFSET(weights_file),  AV_OPT_TYPE_STRING, 
> {.str="nnedi3_weights.bin"}, 0, 0, FLAGS },

I still argue this makes the filter useless for 99% of users.

- The weights are literally the only defining feature of
  nnedi3. Without them, it's useless.
- There's no documentation of where to get them or what
  they are, at all.
- In practice, *no other weights to use with nnedi3
  exist*, which makes the idea of an 'option' pretty
  silly IMO.

It's possible to include smaller version of the weights
like MPV does.

At the very least it should print some sort of info on how to obtain
this file, because it's a usability nightmare.

- Derek

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

Re: [FFmpeg-devel] [PATCH 2/2] libx265: Enable 12-bit encoding

[Derek Buitenhuis]

On 1/27/2016 6:18 PM, Stephen Hutchinson wrote:
> I have no strong opinion on it.  68 seems like the compromise
> position since it'd allow both 1.8 and 1.9 to be used, whereas
> any of the earlier ones still fall within 1.8's dev cycle and would
> only be used by those users making builds against Mercurial
> (most of which are probably going to be using builds from
> more recently than 5+ months ago anyway).

OK.

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

Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9

[Derek Buitenhuis]

On 1/30/2016 7:15 PM, Timothy Gu wrote:
> FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

Perhaps this should be restricted to x86?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling

[Derek Buitenhuis]

On 1/30/2016 12:11 PM, Michael Niedermayer wrote:
> patch should be ok

Related to this:

[16:25] <@Daemon404> that src/ dir really screws up my grepping if i dont 
distclean first
[16:25] <@Daemon404> i get all my results twice
[16:25] <@Daemon404> unless i build out of tree
[16:25] <@Daemon404> -_-
[16:34] <@Daemon404> if i cant use standard unix utilities, that's sad

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

Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data

[Derek Buitenhuis]

On 1/31/2016 1:13 PM, Derek Buitenhuis wrote:
> -if (dec_ctx->timecode_frame_start >= 0) {
> -char tcbuf[AV_TIMECODE_STR_SIZE];
> -av_timecode_make_mpeg_tc_string(tcbuf, 
> dec_ctx->timecode_frame_start);
> -print_str("timecode", tcbuf);
> -} else {
> -print_str_opt("timecode", "N/A");
> -}

This bit is going to be moved inside the deprecation defines.

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

[FFmpeg-devel] [PATCH 3/3 v2] ffprobe: Deprecate stream timecode field and add frame side data timecode field

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 ffprobe.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ffprobe.c b/ffprobe.c
index c352b44..f7b51ad 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1917,6 +1917,10 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 if (sd->type == AV_FRAME_DATA_DISPLAYMATRIX && sd->size >= 9*4) {
 writer_print_integers(w, "displaymatrix", sd->data, 9, " 
%11d", 3, 4, 1);
 print_int("rotation", av_display_rotation_get((int32_t 
*)sd->data));
+} else if (sd->type == AV_FRAME_DATA_GOP_TIMECODE && sd->size >= 
8) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
+print_str("timecode", tcbuf);
 }
 writer_print_section_footer(w);
 }
@@ -2227,6 +2231,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 else
 print_str_opt("chroma_location", 
av_chroma_location_name(dec_ctx->chroma_sample_location));
 
+#if FF_API_PRIVATE_OPT
 if (dec_ctx->timecode_frame_start >= 0) {
 char tcbuf[AV_TIMECODE_STR_SIZE];
 av_timecode_make_mpeg_tc_string(tcbuf, 
dec_ctx->timecode_frame_start);
@@ -2234,6 +2239,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 } else {
 print_str_opt("timecode", "N/A");
 }
+#endif
 print_int("refs", dec_ctx->refs);
 break;
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 0/3 v2] Move MPEG1/2 GOP timecodes to side data

[Derek Buitenhuis]

Derek Buitenhuis (3):
  avutil: Add GOP timecode frame side data
  mpeg12dec: Export GOP timecodes as side data
  ffprobe: Deprecate stream timecode field and add frame side data
timecode field

 doc/APIchanges |  3 +++
 ffprobe.c  |  6 ++
 libavcodec/mpeg12dec.c | 22 --
 libavutil/frame.c  |  1 +
 libavutil/frame.h  |  7 ++-
 libavutil/version.h|  4 ++--
 6 files changed, 38 insertions(+), 5 deletions(-)

-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data

[Derek Buitenhuis]

On 1/31/2016 8:29 PM, Michael Niedermayer wrote:
> the spec says this:
> "The time code refers to the  first  picture  after  the  group  of
> pictures header that has a temporal_reference of zero."

I *think* this is the frame I attach the side data too, but I'm
not a master of the mpeg*.c files.

I will update the comment, but please let me know if this is incorrect.

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

[FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data

[Derek Buitenhuis]

The codec context field was rightly deprecated, and the data
may change per-frame.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 ffprobe.c  |  8 
 libavcodec/mpeg12dec.c | 19 ---
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index c352b44..019863a 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2226,14 +2226,6 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 print_str("chroma_location", 
av_chroma_location_name(dec_ctx->chroma_sample_location));
 else
 print_str_opt("chroma_location", 
av_chroma_location_name(dec_ctx->chroma_sample_location));
-
-if (dec_ctx->timecode_frame_start >= 0) {
-char tcbuf[AV_TIMECODE_STR_SIZE];
-av_timecode_make_mpeg_tc_string(tcbuf, 
dec_ctx->timecode_frame_start);
-print_str("timecode", tcbuf);
-} else {
-print_str_opt("timecode", "N/A");
-}
 print_int("refs", dec_ctx->refs);
 break;
 
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 23c77cd..56a87a4 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2413,17 +2413,25 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
-static void mpeg_decode_gop(AVCodecContext *avctx,
+static int mpeg_decode_gop(AVCodecContext *avctx,
 const uint8_t *buf, int buf_size)
 {
 Mpeg1Context *s1  = avctx->priv_data;
 MpegEncContext *s = >mpeg_enc_ctx;
+AVFrameSideData *tcside;
 int broken_link;
 int64_t tc;
 
+tcside = av_frame_new_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_GOP_TIMECODE, 
sizeof(int64_t));
+if (!tcside)
+return AVERROR(ENOMEM);
+
 init_get_bits(>gb, buf, buf_size * 8);
 
-tc = avctx->timecode_frame_start = get_bits(>gb, 25);
+tc = get_bits(>gb, 25);
+
+memcpy(tcside->data, , sizeof(int64_t));
 
 s->closed_gop = get_bits1(>gb);
 /* broken_link indicate that after editing the
@@ -2438,6 +2446,8 @@ static void mpeg_decode_gop(AVCodecContext *avctx,
"GOP (%s) closed_gop=%d broken_link=%d\n",
tcbuf, s->closed_gop, broken_link);
 }
+
+return 0;
 }
 
 static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
@@ -2604,8 +2614,11 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
 break;
 case GOP_START_CODE:
 if (last_code == 0) {
+int gopret;
 s2->first_field = 0;
-mpeg_decode_gop(avctx, buf_ptr, input_size);
+gopret = mpeg_decode_gop(avctx, buf_ptr, input_size);
+if (gopret < 0)
+return gopret;
 s->sync = 1;
 } else {
 av_log(avctx, AV_LOG_ERROR,
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 0/2] Move MPEG1/2 GOP timecodes to side data

[Derek Buitenhuis]

CC'd Clement, side he added it originally.;

Derek Buitenhuis (2):
  avutil: Add GOP timecode frame side data
  mpeg12dec: Export GOP timecodes as side data

 ffprobe.c  |  8 
 libavcodec/mpeg12dec.c | 19 ---
 libavutil/frame.h  |  7 ++-
 libavutil/version.h|  4 ++--
 4 files changed, 24 insertions(+), 14 deletions(-)

-- 
2.7.0

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

[FFmpeg-devel] [PATCH 1/2] avutil: Add GOP timecode frame side data

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavutil/frame.h   | 7 ++-
 libavutil/version.h | 4 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 406c8b5..e07922d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -116,7 +116,12 @@ enum AVFrameSideDataType {
  * an AVMasteringDisplayMetadata type and contains information about the
  * mastering display color volume.
  */
-AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
+AV_FRAME_DATA_MASTERING_DISPLAY_METADATA,
+/**
+ * The GOP timecode in 25 bit timecode format. Data format is 64-bit 
integer.
+ * This is set on the first frame of a GOP.
+ */
+AV_FRAME_DATA_GOP_TIMECODE
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 8e1963c..5352f26 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -64,8 +64,8 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR  16
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR  17
+#define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 0/2] img2dec improvements

[Derek Buitenhuis]

Justin Ruggles (2):
  img2dec: Support Progressive JPEG in jpeg_probe
  img2dec: Add mime_type to image formats

 libavformat/img2dec.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

-- 
2.7.0

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

[FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

From: Justin Ruggles <justin.rugg...@gmail.com>

Improves probing, especially over http when there is a Content-Type header

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavformat/img2dec.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index a755b6f..25cc82e 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -837,7 +837,7 @@ static int webp_probe(AVProbeData *p)
 return 0;
 }
 
-#define IMAGEAUTO_DEMUXER(imgname, codecid)\
+#define IMAGEAUTO_DEMUXER(imgname, codecid, mimetype)\
 static const AVClass imgname ## _class = {\
 .class_name = AV_STRINGIFY(imgname) " demuxer",\
 .item_name  = av_default_item_name,\
@@ -854,19 +854,20 @@ AVInputFormat ff_image_ ## imgname ## _pipe_demuxer = {\
 .priv_class = & imgname ## _class,\
 .flags  = AVFMT_GENERIC_INDEX, \
 .raw_codec_id   = codecid,\
+.mime_type  = mimetype,\
 };
 
-IMAGEAUTO_DEMUXER(bmp, AV_CODEC_ID_BMP)
-IMAGEAUTO_DEMUXER(dds, AV_CODEC_ID_DDS)
-IMAGEAUTO_DEMUXER(dpx, AV_CODEC_ID_DPX)
-IMAGEAUTO_DEMUXER(exr, AV_CODEC_ID_EXR)
-IMAGEAUTO_DEMUXER(j2k, AV_CODEC_ID_JPEG2000)
-IMAGEAUTO_DEMUXER(jpeg,AV_CODEC_ID_MJPEG)
-IMAGEAUTO_DEMUXER(jpegls,  AV_CODEC_ID_JPEGLS)
-IMAGEAUTO_DEMUXER(pictor,  AV_CODEC_ID_PICTOR)
-IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG)
-IMAGEAUTO_DEMUXER(qdraw,   AV_CODEC_ID_QDRAW)
-IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI)
-IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST)
-IMAGEAUTO_DEMUXER(tiff,AV_CODEC_ID_TIFF)
-IMAGEAUTO_DEMUXER(webp,AV_CODEC_ID_WEBP)
+IMAGEAUTO_DEMUXER(bmp, AV_CODEC_ID_BMP,  "image/bmp")
+IMAGEAUTO_DEMUXER(dds, AV_CODEC_ID_DDS,  "image/vnd-ms.dds")
+IMAGEAUTO_DEMUXER(dpx, AV_CODEC_ID_DPX,  "image/dpx")
+IMAGEAUTO_DEMUXER(exr, AV_CODEC_ID_EXR,  "image/x-exr")
+IMAGEAUTO_DEMUXER(j2k, AV_CODEC_ID_JPEG2000, "image/jp2")
+IMAGEAUTO_DEMUXER(jpeg,AV_CODEC_ID_MJPEG,"image/jpeg")
+IMAGEAUTO_DEMUXER(jpegls,  AV_CODEC_ID_JPEGLS,   NULL)
+IMAGEAUTO_DEMUXER(pictor,  AV_CODEC_ID_PICTOR,   NULL)
+IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG,  "image/png")
+IMAGEAUTO_DEMUXER(qdraw,   AV_CODEC_ID_QDRAW,"image/x-pict")
+IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI,  "image/x-sgi")
+IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST,  "image/x-sun-raster")
+IMAGEAUTO_DEMUXER(tiff,AV_CODEC_ID_TIFF, "image/tiff")
+IMAGEAUTO_DEMUXER(webp,AV_CODEC_ID_WEBP, "image/webp")
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: clear priv in av_init_packet()

[Derek Buitenhuis]

On 2/24/2016 3:10 PM, Michael Niedermayer wrote:
> This should fix leaving uninitialized pointers in priv which can confuse
> user applications.
> See: https://github.com/golang/go/issues/14426
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avpacket.c |1 +
>  1 file changed, 1 insertion(+)

Should be noted this is only for release branches.

LGTM, though.

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

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> If this cannot be fixed differently, we should either increase 
> the score for the existing 32bit probe functions or reduce the 
> score for mime types before this gets applied. Several probe 
> functions (outside of img2dec.c) return MAX for 32 bits, I just 
> wanted to give problematic mpeg streams a better chance to get 
> detected.

I forgot to mention that lowering the score of mimetype-detected
stuff is still OK, to me, at least.

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

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:

Replies are mine.

>> In terms of how the score for a MIME type match compares with 
>> those of the individual content matching probe functions, I'd 
>> say it makes sense. The stronger probing functions have a 
>> score which reflects their reliability.
> 
> But even _EXTENSION + 1 is correct in practically all cases 
> (the exception are mpeg streams that start with the needed four 
> bytes) and should not be beaten by mime_type.

URLs with no extension at all, or extensions with query params
after them are very normal. This argument is silly.

>> Improves probing, especially over http when there is a 
>> Content-Type header
> 
> Please give an example of a failing stream.
> If you cannot share, please provide console output and 
> hexdump of the relevant bytes.

... your argument is "it's not 100% broken so let's not
improve it"? Really?

> If this cannot be fixed differently, we should either increase 
> the score for the existing 32bit probe functions or reduce the 
> score for mime types before this gets applied. Several probe 
> functions (outside of img2dec.c) return MAX for 32 bits, I just 
> wanted to give problematic mpeg streams a better chance to get 
> detected.

[...]

> The alternative is to only use mime type for jpeg: I am 
> assuming this is the only problematic case, note that we have 
> to make sure it's not mjpeg, that's why the probe function is 
> so long.

Um, what? Why the heck would you only use mime-type for JPEG?
It is definitely not the only problematic case, and this sounds
utterly silly.

>> If a MIME type is specified, that does have significant weight 
>> in terms of probability, given that it was set somewhere either 
>> by a client or server program doing a content check or 
>> explicitly by some user.
> 
> Wouldn't the server simply run "file" doing less checks than we 
> already do now? (If it doesn't trust the extension.)

No. This is especially not true on modern CDNs (such as AWS or
GCS), where files are stored as 'blob's and mimetype can be
set properly during the push to storage. It's not 1999 anymore.

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

Re: [FFmpeg-devel] [PATCH 3/3] lavu/rational: add more info regarding floor(x+0.5) usage

[Derek Buitenhuis]

On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote:
> -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64
> +// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64,
> +// see Ticket2713 for affected gcc/glibc versions

I've never seen this comment before, but it makes me wonder: how the heck do 
these
functions work in the rest of the codebase?

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

Re: [FFmpeg-devel] [PATCH 1/3] lavu/attributes: introduce av_likely, av_unlikely

[Derek Buitenhuis]

On 2/25/2016 7:27 AM, wm4 wrote:
> They also make code ugly as fuck, and are more cargo-cult than anything
> else. They might possibly be ok in some very critical parts of the
> code, but otherwise not at all.

+1 to this.

I will absolutely *not* ACK any patch sets that start littering likely/unlikely
all over the codebase. I am indifferent to very limited use, but you must 
include
tests showing it actually does something better.

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

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

On 2/26/2016 2:44 PM, Carl Eugen Hoyos wrote:
> Derek Buitenhuis  gmail.com> writes:
> 
>> On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> You misunderstand:
> Most "imageauto" demuxers return a score of 51. In all cases 
> when 51 is returned, the detection is nearly certain. Your 
> patch disables the detection for all these cases (although 
> it is nearly certain) in favour of the mime type.
> 
> (That is how I understand the patch, please correct me if 
> setting mime_type actually has another effect than 
> returning 75 in case of conformance.)
> 
> I don't think the solution is to increase the score for 
> these probe functions: mpeg streams may start with any 
> bytes and 32 bit accordance should not return maximum 
> (or nearly maximum) score.

See below. The scoring should be fixed.

> My argument is: Let's please improve the jpeg auto-detection 
> (the only one that shows issues) instead of disabling it.

Forgot what this particular patch does for a second.

I'm not saying it should be disabled. I'm saying scoring should be
as such:

1) Probing the file file itself: Highest score.
2) Mime-type: Medium score.
3) File extension: Lower score.

Mime-type is a *much* better mechanism for detection than file
extension over HTTP(S), and it will not affect detection in local
files at all. Mime-type should be tried before e.g. mp3 probing,
which seems to have a lot of misdirections.

This can only be a net improvement, IMO.

> (You should be slightly more careful with your arguments: 
> I originally thought that there might be one or two probe 
> functions that should sometimes return a score instead of 
> 0 because the decoders may accept invalid files but that 
> is not the case except for the case without mime_type.)
> 
> There are 14 "imageauto" demuxers with image type 
> auto-detection. Three (png, dds, webp) return a score of 99, 
> I don't know if they would be effected by the patch in 
> question or not but all three decoders do not work if the 
> respective probe function fails.
> 
> The qdraw decoder fails for samples that fail auto-detection.
> 
> Of the nine image format types with probe functions that 
> return 51, the following fail decoding if the probe 
> function returns 0:
> bmp, dpx, exr, j2k, sgi, sunrast, tiff
> 
> The pictor decoder fails for images that are not 
> auto-detected.
> 
> That leaves only the jpegls autodetection that may not 
> return a score for images that can be decoded: Since the 
> patch you provided does not add a mime_type for jpegls, 
> I don't think it can be used as an argument here.
> 
> So let's improve the jpeg auto-detection, I know it isn't 
> perfect yet.

See above. It's not meant to replace, it's meant to augment.

> I am sorry if I misunderstand this (who does "the push"?):
> Are you arguing user-set mime_types are (except for jpeg) 
> more plausible than an autodetection that never returns 0 
> for images that can be decoded?

Again, see above where I have laid out the scoring I think
would be appropriate.

However, mime-type is far, far more likely to be accurate
than the file extension. I am arguing that it's better than
that, for URLs.

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

Re: [FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

[Derek Buitenhuis]

On 2/26/2016 5:14 PM, Derek Buitenhuis wrote:
> +ret = avio_read(pb, _buf[0], 4);
> +if (ret <= 0)
> +return CHECK_SEEK_FAILED;

This check should be <, not <=.

Changed locally.

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

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

On 2/26/2016 3:05 PM, Carl Eugen Hoyos wrote:
> Or in other words: Except for jpeg, there is no 
> probe function that returns 0 although the decoder 
> can decode the image.

I'll take your word for it on this part.

> So please provide your failing jpeg cases to 
> improve the probing.
> I will probably look myself into the issue but I 
> prefer to have samples to test.

Is it perhaps preferable to share a JPEG parser? I
think these sorts of failures will continue to pop
up as long as the JPEG probing is an ad-hoc parser.

I do believe mimetype is still useful while this is
the case.

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

Re: [FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

[Derek Buitenhuis]

On 2/26/2016 5:30 PM, wm4 wrote:
> The ffio_ensure_seekback() checks are probably unnecessary.

I can remove them if you prefer. Should I?

> Seems a bit verbose, but ok.

I added the av_log stuff because otherwise you just get "Invalid Argument"
from the ffmpeg cli, with no other explanation.

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

[FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

[Derek Buitenhuis]

Fixes large amounts of seeking past EOF, which could be extremely
slow over a network.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
Example of the problem:
ffmpeg -f mp3 -i http://chromashift.org/skyfire.ico

This problem was exacerbated even more by the fact that libavformat
tends to identify EVERYTHING as MP3.
---
 libavformat/mp3dec.c | 60 
 1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index c76b21e..da4c134 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -57,6 +57,11 @@ typedef struct {
 int is_cbr;
 } MP3DecContext;
 
+enum CheckRet {
+CHECK_WRONG_HEADER = -1,
+CHECK_SEEK_FAILED  = -2,
+};
+
 static int check(AVIOContext *pb, int64_t pos, uint32_t *header);
 
 /* mp3 read */
@@ -371,21 +376,39 @@ static int mp3_read_header(AVFormatContext *s)
 for (i = 0; i < 64 * 1024; i++) {
 uint32_t header, header2;
 int frame_size;
-if (!(i&1023))
-ffio_ensure_seekback(s->pb, i + 1024 + 4);
+if (!(i&1023)) {
+ret = ffio_ensure_seekback(s->pb, i + 1024 + 4);
+if (ret < 0)
+return ret;
+}
 frame_size = check(s->pb, off + i, );
 if (frame_size > 0) {
-avio_seek(s->pb, off, SEEK_SET);
-ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
-if (check(s->pb, off + i + frame_size, ) >= 0 &&
+ret = avio_seek(s->pb, off, SEEK_SET);
+if (ret < 0)
+return ret;
+ret = ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
+if (ret < 0)
+return ret;
+ret = check(s->pb, off + i + frame_size, );
+if (ret >= 0 &&
 (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
 {
 av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at 
%"PRId64".\n", i, off);
-avio_seek(s->pb, off + i, SEEK_SET);
+ret = avio_seek(s->pb, off + i, SEEK_SET);
+if (ret < 0)
+return ret;
 break;
+} else if (ret == CHECK_SEEK_FAILED) {
+av_log(s, AV_LOG_ERROR, "Invalid frame size (%d): Could not 
seek to %"PRId64".\n", frame_size, off + i + frame_size);
+return AVERROR(EINVAL);
 }
+} else if (frame_size == CHECK_SEEK_FAILED) {
+av_log(s, AV_LOG_ERROR, "Failed to read frame size: Could not seek 
to %"PRId64".\n", (int64_t) (i + 1024 + frame_size + 4));
+return AVERROR(EINVAL);
 }
-avio_seek(s->pb, off, SEEK_SET);
+ret = avio_seek(s->pb, off, SEEK_SET);
+if (ret < 0)
+return ret;
 }
 
 // the seek index is relative to the end of the xing vbr headers
@@ -427,16 +450,21 @@ static int mp3_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 static int check(AVIOContext *pb, int64_t pos, uint32_t *ret_header)
 {
 int64_t ret = avio_seek(pb, pos, SEEK_SET);
+uint8_t header_buf[4];
 unsigned header;
 MPADecodeHeader sd;
 if (ret < 0)
-return ret;
+return CHECK_SEEK_FAILED;
+
+ret = avio_read(pb, _buf[0], 4);
+if (ret <= 0)
+return CHECK_SEEK_FAILED;
 
-header = avio_rb32(pb);
+header = AV_RB32(_buf[0]);
 if (ff_mpa_check_header(header) < 0)
-return -1;
+return CHECK_WRONG_HEADER;
 if (avpriv_mpegaudio_decode_header(, header) == 1)
-return -1;
+return CHECK_WRONG_HEADER;
 
 if (ret_header)
 *ret_header = header;
@@ -468,8 +496,14 @@ static int64_t mp3_sync(AVFormatContext *s, int64_t 
target_pos, int flags)
 
 for(j=0; j<MIN_VALID; j++) {
 ret = check(s->pb, pos, NULL);
-if(ret < 0)
-break;
+if(ret < 0) {
+if (ret == CHECK_WRONG_HEADER) {
+break;
+} else if (ret == CHECK_SEEK_FAILED) {
+av_log(s, AV_LOG_ERROR, "Could not seek to %"PRId64".\n", 
pos);
+return AVERROR(EINVAL);
+}
+}
 if ((target_pos - pos)*dir <= 0 && abs(MIN_VALID/2-j) < score) {
 candidate = pos;
 score = abs(MIN_VALID/2-j);
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Derek Buitenhuis]

On 2/26/2016 5:42 PM, Reimar Döffinger wrote:
> +av_assert0(frame->format == avctx->pix_fmt);

Is this valid? Mid-stream colorspace changes are fairly common.

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

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

[Derek Buitenhuis]

On 2/24/2016 3:19 PM, Carl Eugen Hoyos wrote:
> (Do you have an example where the probing fails?)
> 
> The idea of these additional demuxers is that they probe 
> the content instead of relying on the file suffix. 
> File suffix provides a score of _EXTENSION (50), so if probing 
> is possible and uses more than 16 bit, _EXTENSION + 1 is 
> returned to allow a better detection.
> AV_SCORE_MIME is 75, so iiuc this patch would just disable 
> autodetection (except for png, dds and webp which compare 
> 64 bit and return _MAX) in favour of the mimetype.
> Or am I reading the code incorrectly and mimetype doesn't 
> lead to a score of 75?
> 
> Why aren't the mimetypes added to the (original) image2 
> demuxer if they are really needed?

From the author:

  First I'll address the image2 suggestion. It certainly is possible to put a 
large
  list of image MIME types in the image2 demuxer, however, a MIME type is 
associated
  with a specific image format, so it is a waste of information not to use it to
  detect the specific format when appropriate. The primary purpose of image2 is
  for image sequences, so using MIME types for that is not applicable at all.
  Just because image2 calls the other probe functions internally to select the
  codec doesn't mean that the other image formats shouldn't be first-class
  citizens in terms of detection.

  In terms of how the score for a MIME type match compares with those of the
  individual content matching probe functions, I'd say it makes sense. The
  stronger probing functions have a score which reflects their reliability. If
  a MIME type is specified, that does have significant weight in terms of
  probability, given that it was set somewhere either by a client or server
  program doing a content check or explicitly by some user. So maybe it should
  override the weaker content checks. It is similar to extension, but it is less
  likely to be arbitrary if present and matching a specific media format.

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

Re: [FFmpeg-devel] [PATCH] mov: Add an option to toggle dref opening

[Derek Buitenhuis]

On 1/16/2016 7:58 PM, Marton Balint wrote:
> CLI users still going to need an option for it.

What do you mean? Demuxer options are all exposed in the CLI.

-enable_drefs 1 works fine.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Derek Buitenhuis]

On 1/23/2016 8:50 PM, Andreas Cadhalpun wrote:
> On 23.01.2016 13:33, Michael Niedermayer wrote:
>> On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote:
>>> ---
>>>  common.mak | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> confirmed to fix checkheaders
> 
> Pushed.

cygwin does not have -W.

Furthermore, makign *environment* deductions based on your *target compiler*
is incredibly broken.

People also build via msvc with a cygwin shell, and on native linux with 
wine+cl.exe.

- Derek

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Derek Buitenhuis]

On 1/23/2016 9:29 PM, Derek Buitenhuis wrote:
> cygwin does not have -W.
> 
> Furthermore, makign *environment* deductions based on your *target compiler*
> is incredibly broken.
> 
> People also build via msvc with a cygwin shell, and on native linux with 
> wine+cl.exe.
> 
> - Derek

ARGH, my MUA responded to the wrong mail.

This was meant for the msvc build patch.

Disregard it in this thread.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Derek Buitenhuis]

On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote:
> Do you have a better idea?

Yes, don't do it, full stop.

Is the feature here (bit exact builds out of tree) worth
all the hacks? In my gut: no. Several others have expressed
the same opinion.

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

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Derek Buitenhuis]

On 1/24/2016 11:52 AM, Andreas Cadhalpun wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
>> Lets just revert this entire batch and re-try after proper testing and 
>> review.
> 
> You're very quick to suggest a revert here, but very reluctant about reverting
> commit 31741ae. That's not consistent.

And you're very quick about pushing a broken patch after literally five minutes.

Myself, wm4, Timo, and James, I believe, were/are all in favour of a revert for
this (dst_path) patch, as well. Who exactly is supporting this slew of quick
fixes?

As for 31741ae, it's unrelated to this, and attacking someone based on a 
something
utterly unrelated is childish at best. (My opinion on 31741ae is: why the heck 
haven't
you been trying to fix it in VLC? My hunch is that it's less effort to make your
packages happy by just reverting it here.)

> Thus I object to reverting this before the regression caused by 31741ae is 
> fixed.

Oh, please. How old are we?

> Also, please be a bit more constructive. Just complaining that it doesn't work
> in your setup is not helpful, as I don't have that setup and thus can't 
> investigate
> the problem. At the very least I'd need to see the output of 'make V=1'.

One could argue the same for you. You'd rather push a bunch of different 
(broken)
fixes until it works instead of reverting and making *one* patch that works. 
That's
hardly constructive.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.

[Derek Buitenhuis]

On 1/24/2016 4:33 PM, Kieran Kunhya wrote:
> The internal encoder is superior to libvo-aacenc.
> ---

Just about everything is.

+1 to removing.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/imgutils: remove special case for aligning the palette

[Derek Buitenhuis]

> ffmpeg | branch: master | Michael Niedermayer  | 
> Sun Feb 14 15:22:47 2016 +0100| [0eb4092c1bf4d74c3b9a65fb0dbe4f90d3a316d0] | 
> committer: Michael Niedermayer

[...]

> +if (align < 4) {
> +av_log(NULL, AV_LOG_ERROR, "Formats with a palette require a 
> minimum alignment of 4\n");
> +return AVERROR(EINVAL);
> +}

This is a silent API break. You changed behavior of a function in such a way
that functioning code no longer works.

See, for example: https://github.com/FFMS/ffms2/issues/256

The related bit of code: 
https://github.com/FFMS/ffms2/blob/7c2e08109d6097d5a644722ca7cfafa002203457/src/core/videosource.cpp#L159-L162

(Why the heck GRAY8 has a palette at all is also a bit WTF,
but unrelated to my point here.)

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

Re: [FFmpeg-devel] Subtitles for GSoC

[Derek Buitenhuis]

On 3/10/2016 8:11 PM, wm4 wrote:
> Since XML libraries are apparently always broken, bloated, insecure, and
> hard to use, that has always been a point of contention. Although it
> would be the right approach.

You're not going to find an XML library that is not annoying/hard to use
because XML is annoying/hard to use correctly.

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

Re: [FFmpeg-devel] [PATCH 1/3] Revert "hls: Add and use a memebr of AVIOInternal rather than abuse opaque"

[Derek Buitenhuis]

On 3/14/2016 11:22 AM, Hendrik Leppkes wrote:
> This reverts commit 9f9ed79d4cb40e5d9093899f8a79086ff23da844.
> 
> The hlsopts member was never set anywhere and always NULL, furthermore
> the HLS demuxer needs to retrieve the proper options from the underlying
> http protocol (cookies, user-agent, etc), so a dummy context won't help.
> ---
>  libavformat/avio_internal.h | 5 -
>  libavformat/aviobuf.c   | 4 
>  libavformat/hls.c   | 6 ++
>  3 files changed, 6 insertions(+), 9 deletions(-)

Should this patch be merged into the later one, since, IIRC, it crashes
with just this one applied.

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

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

[Derek Buitenhuis]

On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> Please also note that I can use av_lfg_get, it does not result in
> slowdown, since speed benefits here come from the ziggurat algo.
> Concretely, it is 82 cycles vs 81 cycles; too little to clearly
> distinguish. I was just not too happy with av_lfg_get << 32 |
> av_lfg_get as it resulted in some bad values in the Anderson Darling
> tests.

"If one wants good Gaussian samples" doesn't explain at all how it is
relevant to a set of multimedia libraries like FFmpeg. Why do we want
those? That is the relevant information which should be mentioned
in the commit message.

> I don't know if good quality Gaussian samples are needed, I welcome
> comments from AAC coding people.

The impression I have from them (atomnuker in previous email) is that
it is not that important, but I'm not an 'AAC' person.

> In particular, I have already mentioned in the patch notes that this
> yields ~ 1-2% in aac encoding speed. If you do a profile run,
> av_bmg_get does show up with nearly 2-3% time spent in it overall.

There is no mention of AAC in the patch notes for this patch, actually.

I'll defer to Rostislav (atomnuker) and other on whether adding yet another
public API that Is Not Multimedia Related is worth 1-2% yield.

- Derek

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

Re: [FFmpeg-devel] [PATCH] Use lowercase includes and library names for schannel check

[Derek Buitenhuis]

On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
> I see this:
> libavformat/tls_schannel.c:#include 
> libavformat/tls_securetransport.c:#include 
> 
> Are those different headers?

Consider that one is for OS X native TLS, and one is for
Windows native TLS.

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

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

[Derek Buitenhuis]

On 3/15/2016 2:56 PM, Ronald S. Bultje wrote:
> Might be related to aacenc? But yes, we need to know overall speed gain of
> some useful end user feature before/after this.

[13:42] <@atomnuker> well, AAC just requires the random numbers to be only 
somewhat random
[13:43] <@atomnuker> you could probably replace the random numbers with just a 
static table of somewhat random numbers
[13:43] <@atomnuker> and that probably won't really change much in terms of the 
output quality
[13:43] <@atomnuker> though an integer RNG might be useful for some things I 
have in mind
[13:44] <@Daemon404> we do have one. but it is not 64bit
[13:44] <@atomnuker> yeah, a 32 bit one would be enough


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

Re: [FFmpeg-devel] Speed difference when using ffmpeg + x264 with stdin, or libx264

[Derek Buitenhuis]

On 3/15/2016 8:58 AM, Pradeep Ramachandran wrote:
> Has anyone else experienced such a stark difference in speed? Are the
> limits of linux pipes the reason for this difference, or is there something
> else going on here?

First: This is probably the wrong list.

Second: Did you expect piping a very large amount of data to *not* be slow?

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

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

[Derek Buitenhuis]

On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote:
> Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits),
> and has a much smaller cache (128 bits). Thus, the timings should also
> be more stable.
> 
> This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and
> likely less random as measured by BigCrush - most LFG's perform
> quite poorly on the BigCrush suite:
> http://www6.tw.freebsd.org/distfiles/testu01.pdf.
> In particular, FFmpeg's seems to be Ran055 in the paper, see pg31.

This doesn't explain how it benefits our uses of PRNGs. We are a set of 
multimedia
libraries, not a general utilities library. Most of our use is for noise 
generation
or unit tests, neither of which benefits much/at all from this. For encrypted 
streams,
we pass in keys via options (e.g. MP4 CENC), mostly.

- Derek

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

Re: [FFmpeg-devel] [PATCH v3] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

On 4/5/2016 10:26 AM, Michael Niedermayer wrote:
> should be ok fro ffmpegs side, i dont know the xvid API

As far as I can tell from its documentation, this is the official / correct
way. The API is kinda bad in that sense.

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

Re: [FFmpeg-devel] ffservers future

[Derek Buitenhuis]

On 4/8/2016 2:30 PM, Michael Niedermayer wrote:
> There are a few known bugs in it like code depending on
> sizeof(AVStream) and general a little too much direct access into APIs
> these things will cause ffserver to frequently break if APIs change
> even slightly.

To calrify, the problem is accessing and allocating *internal* structures.

As in, it includes libavformat/internal.h.

So any change in *non-public* API there breaks it.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[Derek Buitenhuis]

On 4/10/2016 8:09 PM, Rostislav Pehlivanov wrote:
> There are far less users of libfaac than libstagefright, so I think just a
> changelog entry would be enough.

I very much doubt this. Very few people could even *compile* the libstagefright 
code.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[Derek Buitenhuis]

On 4/10/2016 5:42 PM, Michael Niedermayer wrote:
> this is not possible currently libfaac is twice as fast than the
> native encoder.

Twice as fast and produces crap output.

Personally I think 31x realtime (which is the example you've given) is pretty 
quick.

I somewhat double people are using this on e.g. ARM, but I'm also pretty sure 
it's faster
than realtime on ARM too.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Add bits_per_raw_sample to AVCodecParameters

[Derek Buitenhuis]

On 4/11/2016 12:32 AM, Michael Niedermayer wrote:
> The bits_per_raw_sample represents the number of bits of precission per 
> sample.
> 
> The field is added at the logical place, not at the end as the code was just
> recently added
> 
> This fixes the regression about loosing the audio sample precission 
> information
> 
> The change in the fate test checksum un-does the change from the merge
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avcodec.h |   17 +
>  libavcodec/utils.c   |2 ++
>  tests/ref/lavf/ffm   |2 +-
>  3 files changed, 20 insertions(+), 1 deletion(-)

Is this ever used for anything other than identifying 24-bit PCM?
I always wondered why we just didn't have a 24-bit PCM format.

Also, if this is applied, you should update matroskaenc.c to use it.

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

Re: [FFmpeg-devel] [PATCH 8/8] lavf/movenc+dashenc: add automatic bitstream filtering

[Derek Buitenhuis]

On 4/8/2016 1:38 AM, Rodger Combs wrote:
> @@ -617,6 +617,7 @@ static int dash_write_header(AVFormatContext *s)
>  ctx->opaque = s->opaque;
>  ctx->io_close   = s->io_close;
>  ctx->io_open= s->io_open;
> +av_dict_set(, "fflags", "-autobsf", 0);

Don't do this. This is a SILENT API break. You should have to explicitly
enable it, not add a line to disable it to keep current code working.
This will screw any API user who uses the DASH muxing API.

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

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

On 3/3/2016 7:50 PM, Michael Niedermayer wrote:
> The io_open/close callbacks afterwards seem direct access IIUC
> so its not possible to remove or add any fields prior
> 
> though maybe they have been added so recently that its ok to move
> them above all "no direct access" fields
> or maybe iam missing something

Crap. I must have screwed up when merging those callbacks. I can move
the be blacklist entry under them, or I can break ABI and move both,
since I don't think there is release.

Which do people prefer? They're both kinda meh.

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

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

On 3/4/2016 3:02 PM, James Almer wrote:
> ry to non break ABI just yet, leave it as last resort. We did it not even
> half a year ago, and we'd have to push every single scheduled deprecation.
> If this can be resolved moving only the new entries then that's preferable.

OK I did it this way.

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

[FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
This matches API with Libav, in a forthcoming merge, using our
exisiting infastructure code.

CC'd Michael, since he wrote the whitelisting code.

This has been tested with FATE.
---
 Changelog |  1 +
 doc/APIchanges|  3 +++
 libavformat/async.c   |  2 +-
 libavformat/avformat.h|  7 +++
 libavformat/avidec.c  |  2 +-
 libavformat/avio.c| 22 --
 libavformat/avio.h|  5 +
 libavformat/avio_internal.h   |  2 +-
 libavformat/aviobuf.c | 13 +
 libavformat/cache.c   |  2 +-
 libavformat/concat.c  |  2 +-
 libavformat/concatdec.c   |  2 +-
 libavformat/crypto.c  |  2 +-
 libavformat/ftp.c |  4 ++--
 libavformat/gopher.c  |  2 +-
 libavformat/hls.c |  2 +-
 libavformat/hlsproto.c|  4 ++--
 libavformat/http.c|  6 +++---
 libavformat/icecast.c |  2 +-
 libavformat/internal.h|  2 +-
 libavformat/md5proto.c|  2 +-
 libavformat/mmst.c|  2 +-
 libavformat/mpeg.c|  2 +-
 libavformat/options.c |  2 +-
 libavformat/options_table.h   |  1 +
 libavformat/rdt.c |  2 +-
 libavformat/rtmpcrypt.c   |  2 +-
 libavformat/rtmpproto.c   |  4 ++--
 libavformat/rtpdec_asf.c  |  2 +-
 libavformat/rtpproto.c|  6 +++---
 libavformat/rtsp.c| 10 +-
 libavformat/rtspdec.c |  4 ++--
 libavformat/sapdec.c  |  4 ++--
 libavformat/sapenc.c  |  4 ++--
 libavformat/smoothstreamingenc.c  |  8 
 libavformat/srtpproto.c   |  2 +-
 libavformat/subfile.c |  2 +-
 libavformat/tls.c |  2 +-
 libavformat/tls_securetransport.c |  2 +-
 libavformat/url.h |  3 ++-
 libavformat/utils.c   | 19 +++
 libavformat/version.h |  4 ++--
 42 files changed, 114 insertions(+), 62 deletions(-)

diff --git a/Changelog b/Changelog
index d6459a8..0e70724 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - datascope filter
 - bench and abench filters
 - ciescope filter
+- protocol blacklisting API
 
 
 version 3.0:
diff --git a/doc/APIchanges b/doc/APIchanges
index a75f346..2fc6a71 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-XX-XX - xxx - lavf 57.28.100
+  Add protocol blacklisting API
+
 2016-02-28 - xxx - lavc 57.27.101
   Validate AVFrame returned by get_buffer2 to have required
   planes not NULL and unused planes set to NULL as crashes
diff --git a/libavformat/async.c b/libavformat/async.c
index a835292..0cc6fb0 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -251,7 +251,7 @@ static int async_open(URLContext *h, const char *arg, int 
flags, AVDictionary **
 
 /* wrap interrupt callback */
 c->interrupt_callback = h->interrupt_callback;
-ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
options, h->protocol_whitelist);
+ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
options, h->protocol_whitelist, h->protocol_blacklist);
 if (ret != 0) {
 av_log(h, AV_LOG_ERROR, "ffurl_open failed : %s, %s\n", 
av_err2str(ret), arg);
 goto url_fail;
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b843a4b..b133575 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1838,6 +1838,13 @@ typedef struct AVFormatContext {
  */
 char *protocol_whitelist;
 
+/**
+ * ',' separated list of disallowed protocols.
+ * - encoding: unused
+ * - decoding: set by user through AVOptions (NO direct access)
+ */
+char *protocol_blacklist;
+
 /*
  * A callback for opening new IO streams.
  *
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 3859810..eaf8421 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1089,7 +1089,7 @@ static int read_gab2_sub(AVFormatContext *s, AVStream 
*st, AVPacket *pkt)
 
 ast->sub_ctx->pb = pb;
 
-if (ff_copy_whitelists(ast->sub_ctx, s) < 0)
+if (ff_copy_whiteblacklists(ast->sub_ctx, s) < 0)
 goto error;
 
 if (!avformat_open_input(>sub_ctx, "", sub_demuxer, NULL)) {
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 69b6eaa..0be820b 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -55,6 +55,7 @@ static void *urlcontext_child_next(void *obj, void *prev)
 #define D AV_OPT_FLAG_DECODING_PARAM
 static const AVOption options[] = {
 {"protocol_whitelist", "List of protocols that are allowed to be used", 

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Derek Buitenhuis]

On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote:
> +  printf("AVColorTransferCharacteristic=%d calling func(%f) 
> expected=%f\n",
> + i, test_data[j], result);

Comparing floats exactly probably isn't a great idea, since
floating point implementations differ between architectures.

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

Re: [FFmpeg-devel] [PATCH] Opus in MP4 support

[Derek Buitenhuis]

On 3/7/2016 4:29 AM, Matthew Gregan wrote:
> Hi,
> 
> The attached patch adds basic mux/demux support for the Opus audio codec in 
> MP4.
> 
> Mozilla have expressed interest in shipping support for this in:
> https://groups.google.com/d/msg/mozilla.dev.platform/mdDZ-nBr_jM/MaLi2BDOAgAJ

Hi,

Why have you not used the correct Object Type? Opus is registered with MP4RA.
Similar question regarding why you have marked the tag as non-standard.

See: http://www.mp4ra.org/codecs.html

- Derek

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

[Derek Buitenhuis]

On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:

[...]

> ---
>  libavcodec/aacenc_utils.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Cool. Looks like an obvious/easy win, assuming it's identical.

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

[FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.

Heavily based off of a patch from 2012.

Original-by: Nicolas George <geo...@nsup.org>
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavcodec/libxvid.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index 76e725e..b48568f 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -96,6 +96,9 @@ struct xvid_ff_pass1 {
 };
 
 static int xvid_encode_close(AVCodecContext *avctx);
+static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+ const AVFrame *picture, int *got_packet);
+
 
 /*
  * Xvid 2-Pass Kludge Section
@@ -707,6 +710,40 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 av_assert0(xvid_enc_create.num_plugins + (!!x->ssim) + (!!x->variance_aq) 
+ (!!x->lumi_aq) <= FF_ARRAY_ELEMS(plugins));
 
+/* Encode a dummy frame to get the extradata immediately */
+if (x->quicktime_format) {
+AVFrame *picture;
+AVPacket packet;
+int size, got_packet, ret;
+
+av_init_packet();
+
+picture = av_frame_alloc();
+if (!picture)
+return AVERROR(ENOMEM);
+
+xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
+if( xerr ) {
+av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder 
reference\n");
+return -1;
+}
+x->encoder_handle = xvid_enc_create.handle;
+size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
+picture->data[0] = av_malloc(size + size / 2);
+if (!picture->data[0])
+return AVERROR(ENOMEM);
+picture->data[1] = picture->data[0] + size;
+picture->data[2] = picture->data[1] + size / 4;
+memset(picture->data[0], 0, size);
+memset(picture->data[1], 128, size / 2);
+ret = xvid_encode_frame(avctx, , picture, _packet);
+if (!ret && got_packet)
+av_packet_unref();
+av_free(picture->data[0]);
+av_frame_unref(picture);
+xvid_encore(x->encoder_handle, XVID_ENC_DESTROY, NULL, NULL);
+}
+
 /* Create encoder context */
 xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
 if (xerr) {
-- 
2.8.0.rc3

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

Re: [FFmpeg-devel] libavcodec/exr : Add support for UINT32

[Derek Buitenhuis]

On 4/3/2016 5:58 PM, Martin Vignali wrote:
> Hello,
> 
> In attach a patch to add support for UINT32 pixel type.

[...]

> +#ifndef UINT32_MAX
> +#define UINT32_MAX  (0x)
> +#endif

Don't do this, we already require this header be present and working.

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

Re: [FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

[Derek Buitenhuis]

On 4/3/2016 10:22 AM, Michael Niedermayer wrote:
> please add somethng like this to the commit message
> LGTM

Applied with updated commit message.

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

Re: [FFmpeg-devel] [PATCH] Add coded_width/height to AVCodecParameters

[Derek Buitenhuis]

On 4/3/2016 9:49 PM, Clément Bœsch wrote:
> dv needed something like this too, but the code was pretty much hacky in
> the first place and it was changed not to use them, which avoided such
> commit. Where is this needed exactly?

Look at the new rv20 test from 1 April.

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

Re: [FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

On 4/3/2016 9:54 PM, Derek Buitenhuis wrote:
> Modifying global header extradata in encode_frame is an API violation
> and only happens to work currently because mov writes its header
> at the end of the file.
> 
> Heavily based off of a patch from 2012.
> 
> Original-by: Nicolas George <geo...@nsup.org>
> Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
> ---
>  libavcodec/libxvid.c | 39 +++
>  1 file changed, 39 insertions(+)

This is v2, if it wasn't clear.

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

[FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.

Heavily based off of a patch from 2012.

Original-by: Nicolas George <geo...@nsup.org>
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavcodec/libxvid.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index 76e725e..e353154 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -96,6 +96,9 @@ struct xvid_ff_pass1 {
 };
 
 static int xvid_encode_close(AVCodecContext *avctx);
+static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+ const AVFrame *picture, int *got_packet);
+
 
 /*
  * Xvid 2-Pass Kludge Section
@@ -707,6 +710,42 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 av_assert0(xvid_enc_create.num_plugins + (!!x->ssim) + (!!x->variance_aq) 
+ (!!x->lumi_aq) <= FF_ARRAY_ELEMS(plugins));
 
+/* Encode a dummy frame to get the extradata immediately */
+if (x->quicktime_format) {
+AVFrame *picture;
+AVPacket packet;
+int size, got_packet, ret;
+
+av_init_packet();
+
+picture = av_frame_alloc();
+if (!picture)
+return AVERROR(ENOMEM);
+
+xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
+if( xerr ) {
+av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder 
reference\n");
+return AVERROR_EXTERNAL;
+}
+x->encoder_handle = xvid_enc_create.handle;
+size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
+picture->data[0] = av_malloc(size + size / 2);
+if (!picture->data[0]) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+picture->data[1] = picture->data[0] + size;
+picture->data[2] = picture->data[1] + size / 4;
+memset(picture->data[0], 0, size);
+memset(picture->data[1], 128, size / 2);
+ret = xvid_encode_frame(avctx, , picture, _packet);
+if (!ret && got_packet)
+av_packet_unref();
+av_free(picture->data[0]);
+av_frame_free();
+xvid_encore(x->encoder_handle, XVID_ENC_DESTROY, NULL, NULL);
+}
+
 /* Create encoder context */
 xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
 if (xerr) {
-- 
2.8.0.rc3

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

[FFmpeg-devel] [PATCH] psxstr: Remove some commented out code

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavformat/psxstr.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index b57981a..38186f7 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -104,13 +104,7 @@ static int str_probe(AVProbeData *p)
  && sector_count*VIDEO_DATA_CHUNK_SIZE >=frame_size)){
 return 0;
 }
-
-/*st->codec->width  = AV_RL16([0x28]);
-st->codec->height = AV_RL16([0x2A]);*/
-
-// if (current_sector == sector_count-1) {
-vid++;
-// }
+vid++;
 
 }
 break;
-- 
2.8.0.rc3

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

[FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

[Derek Buitenhuis]

From: Hendrik Leppkes 

---
 libavformat/internal.h |  7 +++
 libavformat/utils.c| 23 +++
 2 files changed, 30 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 7defce8..cd390dd 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -22,6 +22,8 @@
 #define AVFORMAT_INTERNAL_H
 
 #include 
+
+#include "libavutil/bprint.h"
 #include "avformat.h"
 #include "os_support.h"
 
@@ -596,4 +598,9 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket 
**ppkt, AVCodecContext *en
  */
 int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t 
*palette);
 
+/**
+ * Finalize buf into extradata and set its size appropriately.
+ */
+int ff_bprint_to_codecpar_extradata(AVCodecParameters *par, struct AVBPrint 
*buf);
+
 #endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3bd2df3..3bf96ad 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4866,3 +4866,26 @@ int ff_get_packet_palette(AVFormatContext *s, AVPacket 
*pkt, int ret, uint32_t *
 
 return 0;
 }
+
+int ff_bprint_to_codecpar_extradata(AVCodecParameters *par, struct AVBPrint 
*buf)
+{
+int ret;
+char *str;
+
+ret = av_bprint_finalize(buf, );
+if (ret < 0)
+return ret;
+if (!av_bprint_is_complete(buf)) {
+av_free(str);
+return AVERROR(ENOMEM);
+}
+
+par->extradata = str;
+/* Note: the string is NUL terminated (so extradata can be read as a
+ * string), but the ending character is not accounted in the size (in
+ * binary formats you are likely not supposed to mux that character). When
+ * extradata is copied, it is also padded with AV_INPUT_BUFFER_PADDING_SIZE
+ * zeros. */
+par->extradata_size = buf->len;
+return 0;
+}
-- 
2.8.0.rc3

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

Re: [FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

[Derek Buitenhuis]

On 3/31/2016 9:49 PM, Derek Buitenhuis wrote:
> From: Hendrik Leppkes <h.lepp...@gmail.com>
> 
> ---
>  libavformat/internal.h |  7 +++
>  libavformat/utils.c| 23 +++
>  2 files changed, 30 insertions(+)

Ping.

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

[FFmpeg-devel] [PATCH v2] wavdec: Only set the codec ID in read_header

[Derek Buitenhuis]

WAV is not a NOHEADER format, and thus should not be changing
stream codec IDs and probing in read_packet.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavformat/wavdec.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index d95596f..0391737 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -60,6 +60,19 @@ typedef struct WAVDemuxContext {
 int rifx; // RIFX: integer byte order for parameters is big endian
 } WAVDemuxContext;
 
+static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
+{
+if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codec->codec_tag == 1) {
+enum AVCodecID codec;
+int ret = ff_spdif_probe(s->pb->buffer, s->pb->buf_end - s->pb->buffer,
+ );
+if (ret > AVPROBE_SCORE_EXTENSION) {
+s->streams[0]->codec->codec_id = codec;
+wav->spdif = 1;
+}
+}
+}
+
 #if CONFIG_WAV_DEMUXER
 
 static int64_t next_tag(AVIOContext *pb, uint32_t *tag, int big_endian)
@@ -528,6 +541,8 @@ break_loop:
 ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
 ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
 
+set_spdif(s, wav);
+
 return 0;
 }
 
@@ -561,18 +576,6 @@ static int wav_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 AVStream *st;
 WAVDemuxContext *wav = s->priv_data;
 
-if (CONFIG_SPDIF_DEMUXER && wav->spdif == 0 &&
-s->streams[0]->codec->codec_tag == 1) {
-enum AVCodecID codec;
-ret = ff_spdif_probe(s->pb->buffer, s->pb->buf_end - s->pb->buffer,
- );
-if (ret > AVPROBE_SCORE_EXTENSION) {
-s->streams[0]->codec->codec_id = codec;
-wav->spdif = 1;
-} else {
-wav->spdif = -1;
-}
-}
 if (CONFIG_SPDIF_DEMUXER && wav->spdif == 1)
 return ff_spdif_read_packet(s, pkt);
 
@@ -833,6 +836,8 @@ static int w64_read_header(AVFormatContext *s)
 
 avio_seek(pb, data_ofs, SEEK_SET);
 
+set_spdif(s, wav);
+
 return 0;
 }
 
-- 
2.8.0.rc3

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

[FFmpeg-devel] [PATCH v3] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.

Heavily based off of a patch from 2012.

Original-by: Nicolas George <geo...@nsup.org>
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavcodec/libxvid.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index 76e725e..b362921 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -96,6 +96,9 @@ struct xvid_ff_pass1 {
 };
 
 static int xvid_encode_close(AVCodecContext *avctx);
+static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+ const AVFrame *picture, int *got_packet);
+
 
 /*
  * Xvid 2-Pass Kludge Section
@@ -707,6 +710,43 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 av_assert0(xvid_enc_create.num_plugins + (!!x->ssim) + (!!x->variance_aq) 
+ (!!x->lumi_aq) <= FF_ARRAY_ELEMS(plugins));
 
+/* Encode a dummy frame to get the extradata immediately */
+if (x->quicktime_format) {
+AVFrame *picture;
+AVPacket packet;
+int size, got_packet, ret;
+
+av_init_packet();
+
+picture = av_frame_alloc();
+if (!picture)
+return AVERROR(ENOMEM);
+
+xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
+if( xerr ) {
+av_frame_free();
+av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder 
reference\n");
+return AVERROR_EXTERNAL;
+}
+x->encoder_handle = xvid_enc_create.handle;
+size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
+picture->data[0] = av_malloc(size + size / 2);
+if (!picture->data[0]) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+picture->data[1] = picture->data[0] + size;
+picture->data[2] = picture->data[1] + size / 4;
+memset(picture->data[0], 0, size);
+memset(picture->data[1], 128, size / 2);
+ret = xvid_encode_frame(avctx, , picture, _packet);
+if (!ret && got_packet)
+av_packet_unref();
+av_free(picture->data[0]);
+av_frame_free();
+xvid_encore(x->encoder_handle, XVID_ENC_DESTROY, NULL, NULL);
+}
+
 /* Create encoder context */
 xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
 if (xerr) {
-- 
2.8.0.rc3

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

[FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[Derek Buitenhuis]

It's not even used anymore, and the checks are no longer
functionally important.

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
 libavcodec/hevc.c|  2 +-
 libavcodec/hevc.h|  4 ++--
 libavcodec/hevc_parse.c  | 11 +--
 libavcodec/hevc_parser.c |  2 +-
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 0d53a33..785aa7e 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2866,7 +2866,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t 
*buf, int length)
 
 /* split the input packet into NAL units, so we know the upper bound on the
  * number of slices in the frame */
-ret = ff_hevc_split_packet(s, >pkt, buf, length, s->avctx, s->is_nalff,
+ret = ff_hevc_split_packet(>pkt, buf, length, s->avctx, s->is_nalff,
s->nal_length_size);
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_ERROR,
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index c91f815..5865f65 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -1080,13 +1080,13 @@ void ff_hevc_hls_mvd_coding(HEVCContext *s, int x0, int 
y0, int log2_cb_size);
 /**
  * Extract the raw (unescaped) HEVC bitstream.
  */
-int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t *src, int length,
+int ff_hevc_extract_rbsp(const uint8_t *src, int length,
  HEVCNAL *nal);
 
 /**
  * Split an input packet into NAL units.
  */
-int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, const uint8_t *buf, 
int length,
+int ff_hevc_split_packet(HEVCPacket *pkt, const uint8_t *buf, int length,
  AVCodecContext *avctx, int is_nalff, int 
nal_length_size);
 
 int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index d557cc7..6ee8496 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -29,14 +29,13 @@
 
 /* FIXME: This is adapted from ff_h264_decode_nal, avoiding duplication
  * between these functions would be nice. */
-int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t *src, int length,
+int ff_hevc_extract_rbsp(const uint8_t *src, int length,
  HEVCNAL *nal)
 {
 int i, si, di;
 uint8_t *dst;
 
-if (s)
-nal->skipped_bytes = 0;
+nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
 if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
 if (src[i + 2] != 3) {  \
@@ -110,7 +109,7 @@ int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t 
*src, int length,
 dst[di++] = 0;
 si   += 3;
 
-if (s && nal->skipped_bytes_pos) {
+if (nal->skipped_bytes_pos) {
 nal->skipped_bytes++;
 if (nal->skipped_bytes_pos_size < nal->skipped_bytes) {
 nal->skipped_bytes_pos_size *= 2;
@@ -205,7 +204,7 @@ static int hls_nal_unit(HEVCNAL *nal, AVCodecContext *avctx)
 }
 
 
-int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, const uint8_t *buf, 
int length,
+int ff_hevc_split_packet(HEVCPacket *pkt, const uint8_t *buf, int length,
  AVCodecContext *avctx, int is_nalff, int 
nal_length_size)
 {
 int consumed, ret = 0;
@@ -269,7 +268,7 @@ int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, 
const uint8_t *buf, in
 }
 nal = >nals[pkt->nb_nals];
 
-consumed = ff_hevc_extract_rbsp(s, buf, extract_length, nal);
+consumed = ff_hevc_extract_rbsp(buf, extract_length, nal);
 if (consumed < 0)
 return consumed;
 
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 4625e61..59893bb 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -239,7 +239,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 src_length = 20;
 }
 
-consumed = ff_hevc_extract_rbsp(NULL, buf, src_length, nal);
+consumed = ff_hevc_extract_rbsp(buf, src_length, nal);
 if (consumed < 0)
 return consumed;
 
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Derek Buitenhuis]

On 4/24/2016 3:39 PM, Nicolas George wrote:
> Clearing the extradata is not related to the codecpar change,
> and it breaks if auto_convert is disabled.
> 
> Fix trac ticket #5461.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavformat/concatdec.c | 5 -
>  1 file changed, 5 deletions(-)

Removing this causes failures when concatdec is used to concat two H.264
streams from an MP4 source, when remuxed, IIRC.

Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip

./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Derek Buitenhuis]

On 4/24/2016 4:26 PM, Nicolas George wrote:
> That may be true, but the fix is incorrect, and should not have sneaked
> during a completely unrelated merge. For the sake of tracking changes, I
> want to revert this, and then look for a more correct fix.

The fix was deemed OK at the time by a few others, but by no means am I
claiming it was correct. I'll go with your word on it, since you know
the code best here.

> I will look at this example.

All right.

> (Note that I am not accusing you of dishonesty; I know the merges are
> a tremendous work, especially the evil plans, and I guess keeping track of
> the extra changes necessary to get everything working is hard.)

Didn't think you were, and thanks.

That particular merge (codecpar) was a team effort, though. All the commits
and issues were tracked on a github fork and branch, which still exists.
I do not plan to remove that branch, in case of regressions like this, in
which it can provide insight sometimes.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Derek Buitenhuis]

On 4/25/2016 2:14 PM, Ivan Uskov wrote:
> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
> elementary h.264 stream decodes by qsvdec.

Could you perhaps elaborate in the commit message, and a code comment, on
why it must be 2? Where does that value come from, etc.

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

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[Derek Buitenhuis]

On 4/25/2016 7:50 PM, John Warburton wrote:
> Is it possible that this patch, particularly to libavcodec/hevc.h, is
> causing my compilation error today, cross-compiling using mingw-w64
> and gcc-5.3.0 from GNU/Linux to Windows 64-bit?

Yes it looks as if qsv also called that, and I missed it.

I have sent a patch to fix it.

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

Re: [FFmpeg-devel] [PATCH] qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp

[Derek Buitenhuis]

On 4/25/2016 11:37 PM, Michael Niedermayer wrote:
> i cant easily test this but does this need a
> av_freep of skipped_bytes_pos somewhere ?
> 
> otherwise it should be ok

I cannot easily test it either, unfortunately.

I'm not sure why it would, though (without having looked very hard).

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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Derek Buitenhuis]

On 4/25/2016 4:49 PM, Carl Eugen Hoyos wrote:
> Can you confirm that this is Windows-only, ie that lto 
> works fine on Linux with the Intel compiler?
> (It did work fine when I last tested.)

FWIW, I've had issues with LTO on Linux, with clang and gold, due to (lack of) 
DCE.

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

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

[Derek Buitenhuis]

On 4/27/2016 2:17 PM, Ricardo Constantino wrote:
> configure already checks for minimum major version 6 which is the
> first one using MIT license and fails if lower.

Gotcha.

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

Re: [FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

[Derek Buitenhuis]

On 4/27/2016 9:50 AM, Ivan Uskov wrote:
> Since it was added to commit message too, it is not the issue, right?
> I  left  the "bug fixed" because it was really the bug which force decoder to
> produce doubled frames output.

I don't think it is worth debating, really. I'll push this patch today if 
nobody objects.

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

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

[Derek Buitenhuis]

On 4/23/2016 6:00 PM, Timo Rothenpieler wrote:
> As the nvEncodeApi.h header is now MIT licensed, this can be dropped.
> The loaded CUDA and NVENC libraries are part of the nvidia driver, and
> thus count as system libraries.
> ---
>  configure | 1 -
>  1 file changed, 1 deletion(-)

I presume there is no way to check the version?

Only being pedantic though, since I doubt it really matters.

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

Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Derek Buitenhuis]

On 4/26/2016 5:41 PM, Ronald S. Bultje wrote:
> ---
>  doc/filters.texi |  13 
>  libavfilter/colorspacedsp.c  |   9 +++
>  libavfilter/colorspacedsp.h  |   6 ++
>  libavfilter/colorspacedsp_template.c | 128 
> +++
>  libavfilter/vf_colorspace.c  |  53 ++-
>  5 files changed, 207 insertions(+), 2 deletions(-)

This seems like a good enough place to ask this:

[19:15] < Daemon404> wm4, can you perhaps enlighten me on what vf_colorspace is
[19:15] < Daemon404> does it replace swscale, or colormatrix
[19:15] < Daemon404> or both
[19:16] < Daemon404> or parts of each but not totally
[19:16] < Daemon404> or what
[19:16] < wm4> that's a very good question

I'm really not clear.

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