Re: [FFmpeg-devel] [PATCH 0/1][TOOL][HACK] Allocation NULL check fuzzer

2017-12-06 Thread Derek Buitenhuis
On 11/25/2017 12:07 AM, Michael Niedermayer wrote: > I do not know that but i would be surprised if null dereferences tests > where unwelcome > > oss-fuzz will already report null derferences and OOM conditions, as > well as undefined behavior. So in some sense various points on the map >

Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile

2017-12-05 Thread Derek Buitenhuis
On 12/5/2017 9:22 AM, Gyan Doshi wrote: > Revised patch attached. [...] > From bbb8013e7404360139a13b58a377a29d3ca69552 Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Tue, 5 Dec 2017 13:17:53 +0530 > Subject: [PATCH] avcodec/libx265 - Add named option to set profile >

Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently

2017-12-05 Thread Derek Buitenhuis
On 12/5/2017 12:38 AM, Michael Niedermayer wrote: > Noone is known to work on fixing this, so it should be disabled > > Signed-off-by: Michael Niedermayer > --- > tests/fate/mov.mak | 1 - > 1 file changed, 1 deletion(-) *NAK* Disabling failing tests entirely defeats

Re: [FFmpeg-devel] [PATCH] avcodec/libx265.c - Add named option to set profile

2017-12-05 Thread Derek Buitenhuis
On 12/5/2017 2:05 PM, Gyan Doshi wrote: > > On 12/5/2017 7:21 PM, Derek Buitenhuis wrote: > >> This is inconsistent with the way libx264.c does it. It calls the profile >> function before the param parsing. > > From http://x265.readthedocs.io/en/default/cli.html#p

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec.h: remove doxy from the old bsf API functions

2017-10-30 Thread Derek Buitenhuis
On 10/29/2017 7:20 PM, James Almer wrote: > Make it clear that these are deprecated and the new API should be > used instead. > > As a side effect, this slightly reduces differences with libav. > > Signed-off-by: James Almer > --- > libavcodec/avcodec.h | 70 >

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

2017-10-25 Thread Derek Buitenhuis
On 10/25/2017 2:42 AM, Thierry Foucu wrote: > Changed the return value when no VOD were encoded in Mpeg4 bistream. > And if we do have already a decoded frames and we are not in xvid_packed > mode, output the existing decoded frame instead of nothing. > --- > libavcodec/h263dec.c | 9

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

2017-10-25 Thread Derek Buitenhuis
This time to the list properly... woops. On 10/25/2017 7:38 PM, Thierry Foucu wrote: > I tried using one of those files. > Without the patch, the decoder will return only 29 frames > With this patch, the decoder will return 1947 frames. > The time of decoding the file were the same (with or

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

2017-10-31 Thread Derek Buitenhuis
On 10/31/2017 2:25 AM, Michael Niedermayer wrote: > (though as said, this fix is not ideal or complete, I would very much > prefer if this would be fixed by using a single buffer or any other > solution that avoids the speedloss.) Using a single buffer would be marginally faster, but it does

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec.h: remove doxy from the old bsf API functions

2017-10-29 Thread Derek Buitenhuis
On 10/29/2017 3:49 PM, James Almer wrote: > Make it clear that these are deprecated and the new API should be > used instead. > > As a side effect, this reduces differences with libav. > > Signed-off-by: James Almer > --- > With this, existing users will get an extra

[FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
Hello all. This is a little rambling / stream of thought, but take it as you will, and perhaps some discussion or change comes of it. Or, more likely, personal attacks, flames, and no change. Or 1 few will reply and then the thread will die and people will go on like it never happened. Sorry to

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 8:54 PM, Rostislav Pehlivanov wrote: > We can't agree to disagree in this case, not if you seriously think that > this is an attack. Would you continue to interpret such vague events as > attacks? You gave it as an example after all. You can use the

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 7:10 PM, Rostislav Pehlivanov wrote: > That's a greeting, a welcoming back. You know, you're with friends, you get > some money together, one of you goes to the store to grab a few beers, he > comes back, "Ah, and you're back, and you bought enough

[FFmpeg-devel] [RFC][PATCH][Type 2] Revert "doc/developer.texi: Add a code of conduct"

2018-05-14 Thread Derek Buitenhuis
It was never enforced, and there is no documented way to enforce it, rendering it useless. This reverts commit 89e9393022373bf97d528e6e9f2601ad0b3d0fc1. --- doc/developer.texi | 29 - 1 file changed, 29 deletions(-) diff --git a/doc/developer.texi

[FFmpeg-devel] [RFC][PATCH][Type 1] developers: Add a section on CoC enforcemnet

2018-05-14 Thread Derek Buitenhuis
This is currently directly copied from the VideoLAN CoC[1] in order to spur discussion. [1] https://wiki.videolan.org/Code_of_Conduct/#Disciplinary_actions Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- doc/developer.tex

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 6:24 PM, James Almer wrote: > As it currently stands, the only way to enforce the CoC is with a vote, > from a committee made from a list of ~20 devs about three or so years > ago who may or may not still be active, and who may or may not even know >

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
>> Lies, Lies and Lies. > > > I don't think it's a good thing to call a dev a liar based on limited > available information. If you have doubts, you can express it as such, but > don't assert doubts as truths. Hmm... there must be some reason that people continue ad hominem attacks even though we

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-14 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 6:28 PM, Rostislav Pehlivanov wrote: > iive just noticed you joined, said hi, and you left saying you were > attacked. Since when is a normal form of welcoming back considered an > attack? I agree with jamrial, you definitely overreacted. If you

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Thu, May 10, 2018 at 4:55 PM, Rostislav Pehlivanov wrote: > Could you send a patch to disable the decoders as well? > Looks good otherwise. Yeah, I thought about doing that too. I can add that, though the option will have to be renamed to something else. - Derek

[FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
attackers to gain the contents of system files. Disable building these by default. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- I've been hard disabling these at $dayjob for a long time, after some "interesting" upload attempts, but it should probably be done fo

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Thu, May 10, 2018 at 5:11 PM, Paul B Mahol wrote: > I do not like it being disabled by default. With all due respect, this is not a valid technical argument, in any respect. > There are options to disable compilation of such modules already. We should be defaulting to

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Thu, May 10, 2018 at 6:52 PM, Gyan Doshi wrote: > On 5/10/2018 11:17 PM, Marton Balint wrote: >> Maybe it is better if we simply get rid of the "probing" part, so the user >> would have to explicitly specify the demuxer to use them. > > +1 > > Maybe shift such probes to

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
> If you think you are fixing security issue you are very wrong. You've nailed that "saying what you think" part of communication, but need to word a little on the all important "saying why you think that" part. Keep practicing, you can do it. I believe in you. - Derek

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote: > I do not have time to explain security basics. > Get a decent book and read it from a start to an end. Speaking frankly for a second: Why do people put up with this sort of crud on this mailing list? Insult-laden

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Fri, May 11, 2018 at 12:41 AM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > Speaking frankly for a second: Why do people put up with this sort of > crud on this > mailing list? Unrelatedly, sorry for the broken linebreaks. Bad

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Fri, May 11, 2018 at 12:36 AM, wm4 wrote: > Experience shows that it's always the obscure features which cause > security issues. Regarding the bloat: these small things add up a lot, > and suddenly you have hundreds of demuxers. It's hard to filter them > out manually,

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
On Fri, May 11, 2018 at 12:49 AM, James Darnley wrote: > I want to argue some more so here you go: it isn't "by default". Strange definition of default, but OK. > It gets rendered because you asked for it to be rendered. You asked for > /etc/passwd to be rendered so

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
> You web people already have options for the various annoying whitelists. > Is this not covered by one of them? As noted in my other reply to Paul, I find it a poor choice to shunt the responsibility of good/secure defaults to the user. As a side note, derisively referring to me as "you web

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
> Disabling demuxers by default does not seem to be a good idea to me. So rendering arbitrary text files by default seems like a good idea in comparsion? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

2018-05-10 Thread Derek Buitenhuis
> please correct me if iam wrong, theres quite a bit iam guessing here > IIUC the problem is that in your usecase > 1. ffmpeg has access to sensitive files > 2. one of these files can be opened by an attacker with ffmpeg > 2b. This involves the file being probed as a supported format It is

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Check AVPacket->duration for being positive not just non zero

2018-05-17 Thread Derek Buitenhuis
On Thu, May 17, 2018 at 1:22 AM, Michael Niedermayer wrote: > Some demuxers (mov, microdvd at least) set duration negative. > > Signed-off-by: Michael Niedermayer > --- > fftools/ffmpeg.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

2018-05-17 Thread Derek Buitenhuis
On Tue, May 15, 2018 at 8:44 PM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > We already did this for audio, but it should be done for video too. > If we don't, seeking back to the start of the file, for example, can > become quite broken, since the first N packets will

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-17 Thread Derek Buitenhuis
On Thu, May 17, 2018 at 1:15 AM, Michael Niedermayer wrote: > I have no magic bullet sadly, which is why i didnt reply. Even lacking a solution, a public agreement that change is needed is a start, isn't it? > But if there is a consensus to enforce some CoC. Then it will

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-16 Thread Derek Buitenhuis
On Wed, May 16, 2018 at 4:42 PM, Thomas Volkert wrote: >> Maybe the solution should be something that does not require all those >> people to convene everytime there is some petty trolling going on >> again. > Yes. Suggestions welcome... >> There is a big difference between "not

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-16 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > This is a little rambling / stream of thought, but take it as you will, > and perhaps some discussion or change comes of it. Or, more likely, personal > attacks, flames, and no change. Or 1

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

2018-05-16 Thread Derek Buitenhuis
On Wed, May 16, 2018 at 3:25 PM, James Almer wrote: > I think the issue is not the lack of clear enforcement rules, but a lack > of a proactive enforcer, be it a person or a body. The CoC has done > nothing but give people something to say when they want to be passive >

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

2018-05-15 Thread Derek Buitenhuis
On Mon, May 14, 2018 at 11:26 PM, Patrick Keroulas wrote: > Signed-off-by: Patrick Keroulas > --- > doc/APIchanges | 3 +++ > libavcodec/avcodec.h | 8 > libavcodec/version.h | 4 ++-- > 3 files

[FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

2018-05-15 Thread Derek Buitenhuis
-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/mov.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 1975011..a74983f 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -3579,7 +3579,7 @@ stati

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

2018-05-15 Thread Derek Buitenhuis
On Tue, May 15, 2018 at 9:10 PM, Tomas Härdin wrote: > Why don't we do this for every format? In this case, it is specific to MOV and MP4, since it's caused by the way we apply edit lists at the packet level (reordering, marking them as discard, changing timestamps, etc.).

Re: [FFmpeg-devel] [PATCH] pixdesc: Only check against valid entries when iterating over lists of enums

2018-06-10 Thread Derek Buitenhuis
On 10/06/2018 13:27, Derek Buitenhuis wrote: > I will send a patch to modify the doxygen for the affected enums as well, > since I think it's likely downstream users may try to iterate over them > in a similar fashion. Scratch that part, it already is documented, it seems.

Re: [FFmpeg-devel] [PATCH] pixdesc: Only check against valid entries when iterating over lists of enums

2018-06-10 Thread Derek Buitenhuis
On 09/06/2018 18:31, Michael Niedermayer wrote: > theres no hole in color_range_names > this may lead to static analyzers complaining about dead code v2 sent. I will send a patch to modify the doxygen for the affected enums as well, since I think it's likely downstream users may try to iterate

[FFmpeg-devel] [PATCH v2] pixdesc: Only check against valid entries when iterating over lists of enums

2018-06-10 Thread Derek Buitenhuis
Some of these enums have gaps in between their values, since they correspond to the values in various specs, instead of being an incrementing list. Fixes segfaults when, for example, using the valid API call: av_color_primaries_from_name("jecdec-p22"); Signed-off-by: Derek

[FFmpeg-devel] [PATCH] pixdesc: Only check against valid entries when iterating over lists of enums

2018-06-08 Thread Derek Buitenhuis
Some of these enums have gaps in between their values, since they correspond to the values in various specs, instead of being an incrementing list. Fixes segfaults when, for example, using the valid API call: av_color_primaries_from_name("jecdec-p22"); Signed-off-by: Derek

[FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

2018-06-18 Thread Derek Buitenhuis
Just one of the many, many ways to store this stuff in the header. Signed-off-by: Derek Buitenhuis --- Related reading, but not exactly the same type: * https://github.com/libjpeg-turbo/libjpeg-turbo/issues/92 * https://github.com/libjpeg-turbo/libjpeg-turbo/commit

Re: [FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

2018-06-18 Thread Derek Buitenhuis
On 18/06/2018 21:19, Derek Buitenhuis wrote: > Just one of the many, many ways to store this stuff in the header. > > Signed-off-by: Derek Buitenhuis > --- > Related reading, but not exactly the same type: > * https://github.com/libjpeg-turbo/libjpeg-turbo/issues/92

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

2018-05-29 Thread Derek Buitenhuis
Hi, On Tue, May 29, 2018 at 5:04 PM, Sasi Inguva wrote: > Hi. sorry for the late reply. I sent a patch similar to this a while back > https://patchwork.ffmpeg.org/patch/8227/ but it got lost in the sea. You > also want to do, Sorry I missed that! I'd prefer to use your patch over mine. I'll

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.

2018-05-30 Thread Derek Buitenhuis
On Tue, May 29, 2018 at 11:39 PM, Sasi Inguva wrote: > If start_time is not set, ffmpeg takes the duration from the global > movie instead of the per stream duration. > Signed-off-by: Sasi Inguva Probably OK, though it seems your git client didn't have your email configured. - Derek

Re: [FFmpeg-devel] [PATCH] lavc/libx265: allow users to set closed GOP via generic lavc flag

2018-06-01 Thread Derek Buitenhuis
On Fri, Jun 1, 2018 at 11:49 AM, Gyan Doshi wrote: [...] What is the default setting? If it is setting open GOP by default, I think this is a bad idea. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix timestamps to be strictly monotonic for video also.

2018-06-01 Thread Derek Buitenhuis
On Fri, Jun 1, 2018 at 12:23 AM, wrote: > From: Sasi Inguva > > Using same timestamp for multiple packets confuses clients like Ffms2 > while seeking to a packet with specific timestamp. > > Signed-off-by: Sasi Inguva > --- > libavformat/mov.c | 9 + > 1 file changed, 5 insertions(+),

Re: [FFmpeg-devel] [PATCH] lavc/libx265: allow users to set closed GOP via generic lavc flag

2018-06-01 Thread Derek Buitenhuis
On Fri, Jun 1, 2018 at 2:25 PM, Gyan Doshi wrote: > x265's default setting is open GOP. lavc's default is open as well. LGTM then. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

2018-06-05 Thread Derek Buitenhuis
On 30/05/2018 00:48, Michael Niedermayer wrote: >> Sorry I missed that! I'd prefer to use your patch over mine. > > iam fine with sasis original patch too Pushed with the changes that were requested in that thread. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH] avformat/yuv4mpegdec: simplify math

2018-05-01 Thread Derek Buitenhuis
On 5/1/2018 10:15 PM, Paul B Mahol wrote: > If you have no other remarks, I will update reference and push patch. Is the reference change actually correct? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

2018-04-26 Thread Derek Buitenhuis
On 4/26/2018 3:49 PM, Tobias Rapp wrote: > "ost" is of type OutputStream here, which only has top_field_first with > values auto=-1/bff=0/tff=1. AVFrame has the > interlaced_frame/top_field_first pair you mentioned, while > AVCodecContext has field_order. Ah, I misunderstood the type and

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: fix mixed code and declarations

2018-04-29 Thread Derek Buitenhuis
On 4/29/2018 3:21 AM, James Almer wrote: > +BenchmarkTimeStamps time_stamps = { .real_usec = av_gettime_relative() }; Does this build on supported versions of MSVC? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH]lswr/swresample: Mention actually supported formats when erroring out

2017-10-26 Thread Derek Buitenhuis
On 10/26/2017 4:03 PM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch is supposed to fix ticket #6779. > > Please comment, Carl Eugen Is the 'p' suffix on each needed, since swr only supports 'planar' audio? - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH]lswr/swresample: Mention actually supported formats when erroring out

2017-10-26 Thread Derek Buitenhuis
On 10/26/2017 5:13 PM, Carl Eugen Hoyos wrote: > Not sure I understand: > Do you mean that the filter option should not require "p" but add > it always? > > Or do you mean it is obvious for users that only planar > formats are supported? If it lines up with the option names, then yes, leave the

Re: [FFmpeg-devel] [PATCH] avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()

2017-10-26 Thread Derek Buitenhuis
On 10/26/2017 11:47 AM, Michael Niedermayer wrote: > +if (get_bits_left(>gb) < 0) { > +return AVERROR_INVALIDDATA; > +} Is this possible? I don't see where get_bits.h is include in this (probably deep in some other header), so can't see if it's using the unchecked reader. - Derek

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

2017-10-23 Thread Derek Buitenhuis
On 10/23/2017 3:56 AM, Michael Niedermayer wrote: > the initialization should be thread safe as it never writes a different > value in the same spot > This would avoid the need to alwas hardcode the tables Still no reason to *not* put it under ff_thread_once, though, to minimize work done. -

Re: [FFmpeg-devel] [PATCH][RFC]lavu/mem: Do not realloc in av_fast_alloc() if size == min_size

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 5:02 PM, Carl Eugen Hoyos wrote: > I just confirmed the ("arbitrary") limit defaults to INT_MAX which at least > on some systems is 2G as claimed above. Right, but this is system-dependent, and not specific to FFmpeg, which was what I meant. I digress though, this is off-topic from

Re: [FFmpeg-devel] [PATCH v4] lavr: deprecate the entire library

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 5:11 PM, Ronald S. Bultje wrote: > I'm in favour of deprecating and eventually removing it. As Mike used to > say: you need to break eggs to make omelettes. I'm in favour simply because I don't know of a good reason to *not* deprecate it? Does it have ASM, modes, APIs, etc. that

Re: [FFmpeg-devel] [PATCH][RFC]lavu/mem: Do not realloc in av_fast_alloc() if size == min_size

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 1:44 PM, Carl Eugen Hoyos wrote: > FFmpeg has an arbitrary allocation limit (2G iirc), av_fast_realloc() > increases the allocation even if the requested is equal the already > allocated size. I believe this can lead to unnecessary OOM (no > testcase) if the requested (and already

Re: [FFmpeg-devel] [PATCH] avformat/hls: release mem resource to fix memleak

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 12:42 PM, Steven Liu wrote: > av_opt_get(v->input, "http_version", AV_OPT_SEARCH_CHILDREN, > _version_opt); > c->http_multiple = http_version_opt && strncmp((const char > *)http_version_opt, "1.1", 3) == 0; > +av_free(http_version_opt); Looks OK, but the

Re: [FFmpeg-devel] Global options to compile FFmpeg with only audio-related features

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 4:00 PM, Cyber Sinh wrote: > What do you think? That patches are welcome :). - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: release mem resource to fix memleak

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 4:31 PM, Nicolas George wrote: > Does it really matter? If av_opt_get() fails for any reason, > http_multiple will just be false, which would let the processing > continue, only in a slightly degraded manner that was the norm a few > months ago. I contend that checking errors should

Re: [FFmpeg-devel] [PATCH] avcodec/utvideodec: add support for UMH2, UMY2, UMH4, UMY4, UMRA, UMRG

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 3:10 PM, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/utvideo.h| 8 +- > libavcodec/utvideodec.c | 194 > ++-- > libavformat/riff.c | 6 ++ > 3 files changed, 169 insertions(+), 39

Re: [FFmpeg-devel] [PATCH] avformat/hls: release mem resource to fix memleak

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 5:50 PM, Aman Gupta wrote: > There is already a check in place to prevent strncmp from being called with > NULL. The point before still holds. Are people really arguing against consistent use of error checking? Inconsistent standards of error checking are how bugs and security

Re: [FFmpeg-devel] [PATCH v2] avformat/hls: release mem resource to fix memleak

2017-12-30 Thread Derek Buitenhuis
On 12/31/2017 5:50 AM, Aman Gupta wrote: > +int r = av_opt_get(v->input, "http_version", AV_OPT_SEARCH_CHILDREN, > _version_opt); > +if (r >= 0) { > +c->http_multiple = strncmp((const char *)http_version_opt, > "1.1", 3) == 0; > +av_freep(_version_opt); >

Re: [FFmpeg-devel] [PATCH] avformat/hls: release mem resource to fix memleak

2017-12-30 Thread Derek Buitenhuis
On 12/31/2017 5:21 AM, Aman Gupta wrote: > I really don't think it makes any sense in this case, since it is expected > that the av_opt_get will fail on non-http io contexts. It doesn't matter if > the failure is due to AVERROR_OPTION_NOT_FOUND or AVERROR(ENOMEM). The only > thing that matters is

Re: [FFmpeg-devel] [PATCH 1/6] avformat: add url field to AVFormatContext

2017-12-30 Thread Derek Buitenhuis
On 12/30/2017 9:16 PM, Marton Balint wrote: > + * - muxing: may be set by the caller before avformat_write_header() (or > + * avformat_init_output() if that is called first). Set to an > + * empty string if it was NULL in avformat_init_output(). For the muxing

Re: [FFmpeg-devel] [PATCH] Adding mkdir option for img2enc (2nd attempt)

2017-12-27 Thread Derek Buitenhuis
Hi, On 12/27/2017 12:27 PM, Dr Alan Barclay wrote: > Resending the two (git format-patch) patches, without the top lines > removed (which I thought I needed to do as some patch emails didn't seem > to have them). > > All comments and help appreciated. [...] > Subject: [PATCH 1/2] Move

Re: [FFmpeg-devel] [PATCH] configure: check SDL2 function with a header

2017-12-29 Thread Derek Buitenhuis
On 12/29/2017 6:36 AM, KO Myung-Hun wrote: > Sorry about that. > > SDL2 uses SDLCALL to specify a calling convention. On OS/2, it's defined > to `_System' which is similar to `_cdecl' but does not prepend '_'. > > After all, without a header, a function is used without `_System'. And > linker

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

2017-12-29 Thread Derek Buitenhuis
On 12/29/2017 8:25 PM, Carl Eugen Hoyos wrote: > 2017-12-29 20:47 GMT+01:00 Derek Buitenhuis <derek.buitenh...@gmail.com>: >> On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote: >>> New patch attached, only tested with fate. >> >>> +if (INT_

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

2017-12-29 Thread Derek Buitenhuis
On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote: > New patch attached, only tested with fate. > +if (INT_MAX / sizeof(*sc->stts_data) <= entries) > return AVERROR(ENOMEM); Should probably be something thing AVERROR(EINVAL), I think. > +sc->stts_count = FFMIN(1024 * 1024,

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

2017-12-29 Thread Derek Buitenhuis
On 12/29/2017 9:32 PM, Derek Buitenhuis wrote: > Because the buffer is now grown exponentially (by a factor of 2 every > time it is resizes), it's possible that it ends up with almost double > the size of 'entries' after resizes. > > For example, consider a valid MP4 file with (

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

2017-12-29 Thread Derek Buitenhuis
On 12/29/2017 8:42 PM, Carl Eugen Hoyos wrote: > Sorry, I don't understand this sentence - could you try with > other words? Because the buffer is now grown exponentially (by a factor of 2 every time it is resizes), it's possible that it ends up with almost double the size of 'entries' after

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

2017-12-31 Thread Derek Buitenhuis
On 12/31/2017 2:04 PM, Carl Eugen Hoyos wrote: > This is not helpful;-( > Is it so unlikely that the patch has small gain for gbr > (theoretically compensated by existing fast conversion > from gbr to rgb) but large impact for rgb (with slow > conversion from rgb into gbr)? I went and tested the

Re: [FFmpeg-devel] [PATCH v2] avformat/hls: release mem resource to fix memleak

2017-12-31 Thread Derek Buitenhuis
On 12/31/2017 6:19 AM, Derek Buitenhuis wrote: > Looking closer into the implementation of av_opt_get just kind of made me sad, > though. It has a bunch of unchecked allocations, such that it can return 0 but > have the string be NULL. I'll send a patch tomorrow to address that properl

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

2017-12-31 Thread Derek Buitenhuis
On 12/31/2017 2:21 PM, Carl Eugen Hoyos wrote: > The real-world issue I see is screen-recording. > > Given that these are small functions and the obvious user advantage > I really believe supporting both pix_fmts is the best solution. Generic RGB packing has no place inside the encoder and

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

2017-12-31 Thread Derek Buitenhuis
On 12/31/2017 2:08 PM, Paul B Mahol wrote: Why do they change? Do I understand correctly that the files get bigger (~5%)? If yes, wouldn't that indicate that the patch is not a good idea? >>> >>> Its because of different scaling path. Have nothing to do with >>> good or bad idea. >>

Re: [FFmpeg-devel] [PATCH] libopus: support disabling phase inversion.

2018-01-22 Thread Derek Buitenhuis
On 1/22/2018 4:46 PM, Paul B Mahol wrote: > NACK. > > Option name is too loong, and its type is not boolean. Opinions on what to call it welcome. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] ffprobe: Initialize coded_width/height

2018-02-02 Thread Derek Buitenhuis
On 2/2/2018 7:46 PM, James Almer wrote: > Pushed as is. Removing the two lines after printing bogus values for > four releases is imo not nice. For starters, it can't be backported. > > They will be removed alongside AVStream->codec in the future. fftools/ffprobe.c:2918:1: error: unknown type

Re: [FFmpeg-devel] [PATCH] cmdutils: Do not unconditionally define functions using avdevice's API

2018-02-08 Thread Derek Buitenhuis
On 2/8/2018 4:34 PM, James Almer wrote: > I just reverted that commit, but in any case this patch needs to be > taken into account for when (and if) it's reapplied. Sounds good. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] cmdutils: Do not unconditionally define functions using avdevice's API

2018-02-08 Thread Derek Buitenhuis
avdevice is not a hard requiremnet for any of the fftools, and this was broken in cdc78058c78dfa4966758a342acd2c1f3b282c46. Fixes build with --disable-avdevice. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- I see you guys can't decide on whether to

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: fix compilation with x264 builds >= 153

2017-12-25 Thread Derek Buitenhuis
On 12/25/2017 9:22 PM, James Almer wrote: > Want me to change it in a separate commit? Sure. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: fix compilation with x264 builds >= 153

2017-12-25 Thread Derek Buitenhuis
On 12/25/2017 8:58 PM, James Almer wrote: > @@ -272,6 +272,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, > const AVFrame *frame, >int *got_packet) > { > X264Context *x4 = ctx->priv_data; > +const av_unused AVPixFmtDescriptor *desc = >

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-26 Thread Derek Buitenhuis
On 12/26/2017 4:10 PM, Nicolas George wrote: > I missed that. If the proposal was similar enough to what was sent > yesterday, then my objection does not stand, of course, sorry. The version on the ML then was different, and it never reached consensus at all on wording. I object for the reasons

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-26 Thread Derek Buitenhuis
On 12/26/2017 3:54 PM, Rostislav Pehlivanov wrote: > This has been on the ML for over a month. No one disagreed then. No one was > on vacation then. I agree with Nicholas, sending a new, different version of a patch, *on Christmas Day*, and pushing on Boxing Day if nobody has objections, is not

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-26 Thread Derek Buitenhuis
On 12/26/2017 4:52 PM, Rostislav Pehlivanov wrote: > You didn't even bother to read the patch? Your objections have been > addressed. > Since your new objection is invalid, I still intent to push it. I said wording, which others had issues with, and were *not* addressed until v2 of the patch

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-26 Thread Derek Buitenhuis
On 12/26/2017 5:03 PM, Nicolas George wrote: > Derek Buitenhuis (2017-12-26): >> It would be nice if this community moved away from the "aggressive asshole" >> style of development, as seen here, but after so many years, that just >> seems impossible. Normal peopl

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

2017-12-28 Thread Derek Buitenhuis
On 12/28/2017 12:44 AM, Carl Eugen Hoyos wrote: >> out of nowhere without being provoked is not a welcome behavior at all. > > That doesn't sound correct to me. He literally said nothing to you on this thread before you insulted him. Cut it out. - Derek

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-28 Thread Derek Buitenhuis
On 12/25/2017 5:53 PM, Rostislav Pehlivanov wrote: > Deprecate the entire library. Merged years ago to provide compatibility > with Libav, it remained unmaintained by the FFmpeg project and duplicated > functionality provided by libswresample. > > In order to improve consistency and reduce attack

Re: [FFmpeg-devel] [PATCH] configure: check SDL2 function with a header

2017-12-28 Thread Derek Buitenhuis
On 12/28/2017 2:44 PM, KO Myung-Hun wrote: > On OS/2, '_' is not prepended to a function name. > --- > configure | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) It's not immediately clear to be how checking a header instead relates to function name mangling (or lack thereof)? -

Re: [FFmpeg-devel] [PATCH 2/2] examples/qsvdec: remove the deprecated filed refcounted_frames

2017-12-28 Thread Derek Buitenhuis
On 12/28/2017 9:27 AM, Zhong Li wrote: > It was just useful for deprecated API (avcodec_decode_video2), > but useless for new decode APIs (avcodec_send_packet/avcodec_receive_frame). > > Signed-off-by: Zhong Li > --- > doc/examples/qsvdec.c | 1 - > 1 file changed, 1

Re: [FFmpeg-devel] [PATCH 1/2] lavu/qsv: add log message for libmfx version

2017-12-28 Thread Derek Buitenhuis
On 12/28/2017 9:27 AM, Zhong Li wrote: > +av_log(ctx, AV_LOG_VERBOSE, > + "Initialize MFX session: API version is %d.%d, implementation > version is %d.%d\n", > + MFX_VERSION_MAJOR, MFX_VERSION_MINOR, ver.Major, ver.Minor); Maybe AV_LOG_DEBUG? I have no strong opinion,

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

2017-12-28 Thread Derek Buitenhuis
On 12/28/2017 10:19 PM, Carl Eugen Hoyos wrote: > I care much less about what he says (did he really talk to you?) or > writes, more about what he does. For the record: Nobody talked to me. There is no conspiracy. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] libopus wrapper not supporting inband FEC

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 4:45 PM, Amit Gandhi wrote: > Does anyone happen to know why inband FEC option is not supported by libopus > wrapper in ffmpeg while the packet_loss option is supported? Probably no other reason than the fact that nobody mapped it to an AVOption yet. - Derek

[FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-01 Thread Derek Buitenhuis
This fixes a double free in he error case. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- This does fix the double free, but I am unsure if it is the correct free to removed to fix it. Comments welcome. --- libavfilter/vf_paletteuse.c | 1 - 1 file changed, 1 deletion(-)

[FFmpeg-devel] [PATCH 1/2] vf_paletteuse: Add error checking to apply_palette

2018-01-01 Thread Derek Buitenhuis
This fixes a segfault caused by passing NULL to ff_filter_frame when an error occurs. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavfilter/vf_paletteuse.c | 25 - 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/libav

[FFmpeg-devel] [PATCH 1/3] lavc/options: Remove unneeded header

2018-01-01 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/options.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavcodec/options.c b/libavcodec/options.c index 82e1217..41b6052 100644 --- a/libavcodec/options.c +++ b/libavcodec/options.c @@ -30,7 +30,6 @@ #i

[FFmpeg-devel] [PATCH 0/2] Smll vf_paletteuse error branch fixes

2018-01-01 Thread Derek Buitenhuis
/filter/anim-palette.png -lavfi paletteuse=bayer \ -pix_fmt bgra -bitexact -f framecrc - Derek Buitenhuis (2): vf_paletteuse: Add error checking to apply_palette vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error libavfilter/vf_paletteuse.c | 26

Re: [FFmpeg-devel] [PATCH 1/2] vf_paletteuse: Add error checking to apply_palette

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 10:16 PM, Clément Bœsch wrote: > I don't think you'll be much off by always assuming ENOMEM here when > getting a NULL out frame, I think that's the common idiom when a function > supposed to return allocated stuff returns NULL. > > But that's not very important, feel free to push as

<    2   3   4   5   6   7   8   9   >