Re: [FFmpeg-devel] [PATCH]lavc/utvideo: Use "&" instead of "&&" in expressions with "~"

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 12:58 AM, Ronald S. Bultje wrote: > I personally think the warning is dumb... But I guess that's just me. I agree; I don't even count it as a valid warning. Maybe disable it? That's only my opinion, of course. - Derek ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/6] hwcontext_vaapi: Set message callbacks on internally-created devices

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 4:11 PM, Mark Thompson wrote: > The message callbacks are library-safe in libva2, so we can now use > them. Also factorise out the common connection code to avoid > duplicating this change. > --- > libavutil/hwcontext_vaapi.c | 74 > +++-- >

Re: [FFmpeg-devel] [PATCH 5/6] hwcontext: Perform usual initialisation on derived device contexts

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 4:11 PM, Mark Thompson wrote: > -ret = qsv_device_init(ctx); > -if (ret < 0) > -goto fail; From the patch context alone, this looks kinda iffy. I assume qsv_device_init is now called via av_hwdevice_ctx_init? - Derek ___

Re: [FFmpeg-devel] [PATCH 2/6] vaapi: Remove H.264 baseline profile

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 4:11 PM, Mark Thompson wrote: > +case FF_PROFILE_H264_BASELINE: > +// Baseline profile is not supported, assume the user meant > +// constrained baseline instead. > +avctx->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE; Trying to automatically (and

Re: [FFmpeg-devel] [PATCH 2/6] vaapi: Remove H.264 baseline profile

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 4:49 PM, Mark Thompson wrote: > Yeah, ok, I agree. Patch changed as enclosing. > > > libavcodec/vaapi_decode.c | 1 - > libavcodec/vaapi_encode_h264.c | 12 > 2 files changed, 4 insertions(+), 9 deletions(-) Looks OK to me. I assume we don't care about the old

Re: [FFmpeg-devel] [PATCH 6/6] hwcontext_vaapi: Add support for mapping to DRM objects

2017-10-08 Thread Derek Buitenhuis
On 10/8/2017 5:11 PM, Mark Thompson wrote: > This is just how hardware surfaces are stored in AVFrames - they have their > own API-specific handles in the data[] pointers because that's the only place > to put them. > > See >

Re: [FFmpeg-devel] [PATCH] avformat/srt: add Haivision Open SRT protocol

2017-10-10 Thread Derek Buitenhuis
On 10/10/2017 7:29 AM, Nablet Developer wrote: > @@ -293,6 +293,7 @@ External library support: >--enable-opengl enable OpenGL rendering [no] >--enable-openssl enable openssl, needed for https support > if gnutls is not used [no] > +

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tonemap: don't use NAN constant as an initializer

2017-09-08 Thread Derek Buitenhuis
On 9/8/2017 10:53 AM, Hendrik Leppkes wrote: > So if it would not be defined at all, the filter would still not > build. So what exactly does that change? Yes it would: libavutil/mathematics.h:#define NANav_int2float(0x7fc0) - Derek

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Derek Buitenhuis
On 9/8/2017 11:15 PM, James Almer wrote: > It reads eight bytes at a time if the buffer is sufficiently aligned, > then finishes reading the remaining bytes one at a time. > If the buffer is unaligned, it reads everything one byte at a time like > it used to. > > See ff_h2645_extract_rbsp() and

[FFmpeg-devel] [PATCH] mjpeg: Add support for ICC side data

2017-08-23 Thread Derek Buitenhuis
his likely does not work for MJPEG files with embedded ICC profiles, but I could not find a real, exisiting file, that had that. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/mjpegdec.c | 90 +++ libavcodec/mjpegd

Re: [FFmpeg-devel] [PATCH] mjpeg: Add support for ICC side data

2017-08-24 Thread Derek Buitenhuis
On 8/24/2017 1:22 AM, Michael Niedermayer wrote: > should be ok i think Rostislav asked me on IRC to try with MJPEG, so I am going to try and synthesize such a file and work on a v2. I don't suppose you, or anyone else has an MJPEG file with ICC profiles embedded? :) - Derek

[FFmpeg-devel] [PATCH v2] mjpeg: Add support for ICC side data

2017-08-24 Thread Derek Buitenhuis
JPEGs store embedded profiles under the APP2 marker, signified with a "ICC_PROFILE" null-terminated string header, and can be split across multiple APP2 markers, out of order. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/

[FFmpeg-devel] [PATCH] utils: Do not expand a macro with 'defined' in it

2017-08-24 Thread Derek Buitenhuis
mp;& defined MAP_ANONYMOUS) ^ Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libswscale/utils.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libswscale/utils.c b/libswscale/utils.c index b

Re: [FFmpeg-devel] [PATCH] utils: Do not expand a macro with 'defined' in it

2017-08-24 Thread Derek Buitenhuis
On 8/24/2017 9:02 PM, Derek Buitenhuis wrote: > Fixes: > > libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' > has undefined behavior [-Wexpansion-to-defined] > #if USE_MMAP > ^ > libswscale/utils.c:1577:49: note: expanded

Re: [FFmpeg-devel] [PATCH v2] mjpeg: Add support for ICC side data

2017-08-25 Thread Derek Buitenhuis
On 8/25/2017 1:37 AM, Michael Niedermayer wrote: > should be ok Pushed, with an extra check added for duplicate sequence numbers. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: fix pre convert to framesync2 bugs

2017-08-30 Thread Derek Buitenhuis
On 8/30/2017 2:24 PM, Ronald S. Bultje wrote: > Pushed. Did libvmaf bump its version for this breaking change? (It should have...) If so, bump the required version in configure, or other users will get crashes. - Derek ___ ffmpeg-devel mailing list

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

2017-10-22 Thread Derek Buitenhuis
On 10/22/2017 2:03 PM, James Almer wrote: > This prevents data races in av_crc_get_table() > > Signed-off-by: James Almer > --- > libavutil/Makefile |1 + > libavutil/crc.c| 295 +- > libavutil/crc_tables.c | 1030 >

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

2017-10-22 Thread Derek Buitenhuis
On 10/22/2017 2:11 PM, James Almer wrote: > It was suggested, but nobody gave it a try (Or they did but found it > wasn't as simple as first thought?). [...] > Thread sanitizer complains about this in every other run, and the tables > are at most 1k each, so this is not a bad solution and can be

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis
On 11/14/2017 8:28 PM, Sasi Inguva wrote: > For H264 files with no bitstream restriction flag, we aren't able to guess > the delay correctly. Especially if it's MOV container, because for MOV > container we just probe the 1st frame and stop in avformat_find_streaminfo . You do not appear to be

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis
On 11/14/2017 11:36 PM, Thierry Foucu wrote: > One option i asked on IRC was to use the spec for max DPB when the bitstream > restriction flag was not set. > But people were worry about low latency usage. > Normally, if the bitstream restriction flag is not set, the DPB should be > set based on

Re: [FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

2017-11-14 Thread Derek Buitenhuis
On 11/15/2017 12:56 AM, Vittorio Giovara wrote: > --- > libavfilter/vf_zscale.c | 26 -- > libavformat/mxfdec.c| 20 > 2 files changed, 44 insertions(+), 2 deletions(-) Accidental inclusion of MXF code? Also, Does the minimum zimg version need to

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis
On 11/14/2017 10:11 PM, Sasi Inguva wrote: > I don't know if the patch can be made more generic to work for all > demuxers, because this patch requires that PTS of all packets be available > in the header. The other route is to make it very specific to codecs with > B-frames. All PTS may not be

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

2017-11-25 Thread Derek Buitenhuis
On 11/26/2017 12:14 AM, Carl Eugen Hoyos wrote: > I am of course in favour of such checks but is there an allocator we support > that actually returns NULL on oom? Anything that doesn't use overcommit. Windows is the big obvious one here. Also various UNIX-like things, and even Linux is not

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

2017-11-25 Thread Derek Buitenhuis
On 11/25/2017 2:40 PM, Clément Bœsch wrote: > Maybe "libavresample is not maintained by the FFmpeg project and will be > dropped at the next major bump. Please use libswresample instead." > > And it probably needs a longer explanation somewhere (website/news/...) All API functions should be

[FFmpeg-devel] [PATCH 0/2] alloc NULL check fuzzer finds

2017-11-24 Thread Derek Buitenhuis
This was from a single FATE pass, an only 2 of the 10+ found. Going to send the tool I use to fuzz it to the list as well. Derek Buitenhuis (2): h264_picture: Actually return error during alloc failure vorbisenc: Check the return value of av_frame_clone libavcodec/h264_picture.c | 12

[FFmpeg-devel] [PATCH 2/2] vorbisenc: Check the return value of av_frame_clone

2017-11-24 Thread Derek Buitenhuis
Prevents a segfault when alloc fails. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/vorbisenc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c index a4ecd8f754..18a679f2dc

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

2017-11-24 Thread Derek Buitenhuis
onfigure && make && cp backtrace.h /usr/local/include && cp .libs/libbacktrace.a /usr/local/lib). Add -lbacktrace to extra-libs. Hacky? Yeah... Derek Buitenhuis (1): Allocation NULL check fuzzing tool libavutil/mem.c | 4 ++-

[FFmpeg-devel] [PATCH 1/1][NO NOT APPLY] Allocation NULL check fuzzing tool

2017-11-24 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavutil/mem.c | 4 ++- libavutil/posixmemalign.c | 86 +++ 2 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 libavutil/posixmemalign.c diff

[FFmpeg-devel] [PATCH 1/2] h264_picture: Actually return error during alloc failure

2017-11-24 Thread Derek Buitenhuis
Fixes NULL dereference during alloc failure. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/h264_picture.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c index e7dd

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

2017-11-24 Thread Derek Buitenhuis
On 11/24/2017 8:09 PM, Paul B Mahol wrote: > Do you have backtrace of this one? Yes, but the alloc failure is not in lavfi: my_posix_memalign:77 in libavutil/posixmemalign.c av_malloc:89 in libavutil/mem.c av_mallocz:240 in libavutil/mem.c av_packet_alloc:53 in libavcodec/avpacket.c

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:06 PM, Carl Eugen Hoyos wrote: > In this case the library and our interface both depend on pthreads > but configure ignores this. Sorry, I wasn't aware our own wrapper code use pthreads too. Patch should be OK then. Upstream pkg-config file is still broken, though. :) - Derek

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:09 PM, Carl Eugen Hoyos wrote: > As said before, it is non-trivial to find such a system > (it worked fine here on osx when I tested last). OS X does not ship with libstdc++, IIRC. You must have been using a ports-build toolchain? Using clang-cl or MSVC on windows will also not

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

2017-11-26 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]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 1:35 PM, Carl Eugen Hoyos wrote: > Attached patch adds a missing dependency to libvmaf, I don't know if > other threads also work. This should also be filed as a bug against libvmaf, since its pkg-config file isn't complete, then. - Derek

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:15 PM, Carl Eugen Hoyos wrote: > I believe I have explained before that I always only use > vanilla toolchains because that's the only thing users > typically have access to. It's possible the OS X version was outdated then, since the system clang has used libc++ as default since

Re: [FFmpeg-devel] [PATCH 2/2] vorbisenc: Check the return value of av_frame_clone

2017-11-26 Thread Derek Buitenhuis
On 11/24/2017 7:27 PM, Derek Buitenhuis wrote: > Prevents a segfault when alloc fails. > > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > --- > libavcodec/vorbisenc.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) If there are no objectio

Re: [FFmpeg-devel] [PATCH 3/3] udp: Actually fail when we're missing required options, like the "warning" says.

2017-11-26 Thread Derek Buitenhuis
On 11/22/2017 3:28 PM, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis <der...@vimeo.com> > --- > There was no reasoning in the commit that added this, so maybe someone on > the list has some insights. > --- > libavformat/udp.c | 4 ++-- > 1 file changed, 2

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 1:50 PM, Carl Eugen Hoyos wrote: > Sorry, I don't understand how pkg-config is related to the missing > dependency of our configure script: Please explain. Because pthreads is a dependency of libvmaf. Looking at libvmaf, it does list pthreads as a dependency:

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:02 PM, Carl Eugen Hoyos wrote: > The way I understand (Linux) dynamic libraries, one implies > the other. The problem is that libvmaf's .pc file put all of its deps in Libs instead of splitting them out into Libs.private, which is used only when static linking. Stuff like

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:05 PM, Nicolas George wrote: > If a library does not use threads but our calls to the library require > threads, then we must consider it a dependency. Netflix made their pkg-config file incorrectly, which causes this. It should be fixed there, but do we want to work around that

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 2:10 PM, Nicolas George wrote: > -> our code depends on pthreads for this filters, it must be expressed > in configure: Carl Eugen's patch is right, there is no need to bugreport > anything. His explanations later were wrong, but it may only be caused > by the confusion you brought.

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix huge alloc in mov_read_ctts

2017-11-26 Thread Derek Buitenhuis
On 11/26/2017 3:10 PM, John Stebbins wrote: > Is there some git magic for this, or is this just something you add manually > to the bottom of the commit message? It's just manual. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 2/3] udp: Check the port number provided by av_url_split as per docs

2017-11-24 Thread Derek Buitenhuis
On 11/23/2017 11:28 PM, Michael Niedermayer wrote: > this seems to break rtp / rtsp > > ive traced it to > ff_rtsp_make_setup_request() calling ffurl_open_whitelist() without > a port Looking at:

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

2017-11-24 Thread Derek Buitenhuis
On 11/24/2017 11:35 PM, Michael Niedermayer wrote: > Maybe integrating this in: > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > would make sense > > That would run it automatically on ffmpeg master HEAD on powerfull hw Could make sense, yeah - wouldn't be that hard. It

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 11:34 PM, Carl Eugen Hoyos wrote: > Please understand I am against removing the paragraph from the > documentation because I believe it is a good idea if developers > are subscribed to -cvslog. Perhaps it can be reworded a bit to say it's encouraged for the cited reasons, but not

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 10:52 PM, Carl Eugen Hoyos wrote: > start_line = fields * (i ^ (par->field_order == AV_FIELD_BB || > par->field_order == AV_FIELD_BT)); > > Which are imo less ugly. Can't agree. It's needlessly less readable bit fiddling. - Derek ___

Re: [FFmpeg-devel] [PATCH]ffmpeg: Improve warnings if av_buffersrc_add_frame*() fail

2017-11-23 Thread Derek Buitenhuis
On 11/23/2017 11:09 AM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch implements more verbose warnings as suggested by Nicolas. > > Please comment, Carl Eugen OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 1:33 PM, Kevin Wheatley wrote: > The guess work comes from this list: > > https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-SAMPLE__COLR__SETTINGS It's a mistake to conflate resolutions with the standards listed

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 10:24 AM, Marc-Antoine ARNAUD wrote: > New patch version which fixe the last remark. [...] > +char depth_string[8]; > +snprintf(depth_string, sizeof(depth_string), "%d", (1 1); > +geq->expr_str[A] = av_strdup(depth_string); Missing return value

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 2:38 PM, Marc-Antoine ARNAUD wrote: > It made sense, but this commit don't touch this part of the code. > It can made more sense to add an another path to "prevent bad memory > allocation in geq filter". What do you think ? Ah, you are correct. A 2nd patch would be nice, yes, but

[FFmpeg-devel] [PATCH 0/3][RFC] Random UDP bits

2017-11-22 Thread Derek Buitenhuis
Bits that I saw when I was reviewing the OpenSRT code. Derek Buitenhuis (3): Revert "udp: fix compilation when HAVE_PTHREAD_CANCEL isnt defined" udp: Check the port number provided by av_url_split as per docs udp: Actually fail when we're missing required options, like the

[FFmpeg-devel] [PATCH 1/3] Revert "udp: fix compilation when HAVE_PTHREAD_CANCEL isnt defined"

2017-11-22 Thread Derek Buitenhuis
This was an mplayer-specific hack. This reverts commit a4f94f24b4f153c30bbcaa700bedfb2b3a581e5e. --- Near as I can tell, this is a hack added to deal with the fact that the terrible mplayer build system cannibalized FFmpeg's, and failed at it. There's no reason this should be in FFmpeg, if that

[FFmpeg-devel] [PATCH 3/3] udp: Actually fail when we're missing required options, like the "warning" says.

2017-11-22 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis <der...@vimeo.com> --- There was no reasoning in the commit that added this, so maybe someone on the list has some insights. --- libavformat/udp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/udp.c b/libavformat/udp.c

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: fix last packet timestamps

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 1:10 AM, Marton Balint wrote: > Fixes the packet timestamps of the last packet, which was unset, or guessed by > compute_pkt_fields. > > ffprobe -fflags nofillin -show_packets tests/data/lavf/lavf.mxf > -select_streams v > > Signed-off-by: Marton Balint > --- >

[FFmpeg-devel] [PATCH 2/3] udp: Check the port number provided by av_url_split as per docs

2017-11-22 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis <der...@vimeo.com> --- libavformat/udp.c | 8 1 file changed, 8 insertions(+) diff --git a/libavformat/udp.c b/libavformat/udp.c index 0dde035..7bbd282 100644 --- a/libavformat/udp.c +++ b/libavformat/udp.c @@ -443,6 +443,10 @@ int ff_udp_set_remo

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 3:41 PM, Tobias Rapp wrote: > Writes one set of field framing information for progressive streams and > two sets for interlaced streams. Fixes ticket #6383. > > Unfortunately the OpenDML v1.02 document is not very specific what value > to use for start_line when frame data is not

Re: [FFmpeg-devel] [PATCH] libavformat/mov: Replace duplicate stream_nb check by assert

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 12:04 PM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) If it's a duplicate check, is there even a gain from using an assert? - Derek

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section

2017-11-22 Thread Derek Buitenhuis
On 11/21/2017 11:40 PM, Carl Eugen Hoyos wrote: > I am against removing this paragraph. He specifically asked if it was required of new developers to subscribe to this list, in a separate thread, earlier[1]. Paul explicitly said it was *not* required[2], Timo said no discussion happens on the

Re: [FFmpeg-devel] [PATCH 1/3] Revert "udp: fix compilation when HAVE_PTHREAD_CANCEL isnt defined"

2017-11-23 Thread Derek Buitenhuis
On 11/22/2017 4:41 PM, Paul B Mahol wrote: > LGTM Pushed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

2017-11-27 Thread Derek Buitenhuis
On 11/21/2017 11:12 PM, Dale Curtis wrote: > Otherwise ff_alloc_extradata() just leaks any existing allocated > memory. Should be OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add lv2 wrapper filter

2017-11-24 Thread Derek Buitenhuis
On 11/23/2017 9:16 PM, Paul B Mahol wrote: > +typedef struct LV2Context { > +const AVClass *class; > +char *plugin_uri; > +char *options; > + > +unsigned long nb_inputs; > +unsigned long nb_inputcontrols; > +unsigned long nb_outputs; Why are you using longs instead of

Re: [FFmpeg-devel] [PATCH] libavformat/mov: Replace duplicate stream_nb check by assert

2017-11-22 Thread Derek Buitenhuis
On 11/22/2017 8:09 PM, Michael Niedermayer wrote: > not much, no > its a non static function tough > i can remove the check completely if thats preferred ? I guess leave it since it's non-static. LGTM. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

2017-11-29 Thread Derek Buitenhuis
On 11/29/2017 7:17 PM, Devin Heitmueller wrote: >> Is there a reason we shouldn't fail hard here? > > Not really. The parser will log an error if the callback returns a nonzero > value, but beyond the return value isn’t actively used. That said, no > objection to having it return -1 for

Re: [FFmpeg-devel] [RFC] [Vote] Drop Windows XP support

2017-12-14 Thread Derek Buitenhuis
On 12/14/2017 1:26 PM, wm4 wrote: > The subject of the vote is: > > Should we drop support for Windows XP starting in git master and the > next FFmpeg major release? I am not on the voting list (which is form 2015 and contains people who have since vanished, as well), but I would like to put

Re: [FFmpeg-devel] [PATCH]lavf/mxfenc: Support 60fps output

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 1:27 PM, Carl Eugen Hoyos wrote: > This was successfully tested so I will push if there are no objections. Seems harmless enough if it isn't violating some spec (it is MXF after all...) If someone had objections, they would have responded by now, probably. - Derek

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: checking return value of avio_open_dyn_buf

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 2:53 AM, Steven Liu wrote: > fix CID: 1421196 > > Signed-off-by: Steven Liu > --- > libavformat/hlsenc.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Should be OK if it passes valgrind. - Derek ___

[FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

2017-11-17 Thread Derek Buitenhuis
mb_area_start has 5 entries, and 'a' is iterated through from 0 to 3. 'a2' is set to 'a + 1', and mb_area_start[a2 + 1] is accessed, so if a is 3, then we try to access mb_area_start[5]. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- I'm not 100% sure if this fix is /c

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

2017-11-17 Thread Derek Buitenhuis
On 11/17/2017 5:37 PM, Michael Niedermayer wrote: > hmm, i cant really remember this clearly but from looking at the code > it looks like this is the logic: > b->next[k] < 64 > b->next[k] >= mb_area_start[a + 1] implies mb_area_start[a + 1] < 64 > which implies a < 3 > and a2 < 4 on the first

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

2017-11-17 Thread Derek Buitenhuis
On 11/17/2017 4:42 PM, Martin Vignali wrote: > doesn't know the dvenc code, > but you seems to test the assert of the next line > > Maybe move the assert (a2 < 4); before the for loop, if it's a theorical > case, > or remove it if this case can really happen. I don't see anything that would

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

2017-11-20 Thread Derek Buitenhuis
On 11/20/2017 4:45 PM, Dave Rice wrote: > What do you propose as the default for guessed_hacky_crap? Also are there > supporters for the need of a guessed_hacky_crap optio? Is there precedence in > ffmpeg to enable/disable guesswork via a user option? I personally would never use the guesswork

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

2017-11-20 Thread Derek Buitenhuis
On 11/20/2017 3:19 PM, Dave Rice wrote: > TN2162 requires a colr atom for uncompressed yuv (including v210, v308, v408, > etc) in mov, so I'd prefer to write it in this case. Note that the colr atom > provides an option for unspecified for each of the color values, so there's a > method to

Re: [FFmpeg-devel] [PATCH] Added Turing codec to ffmpeg

2017-11-20 Thread Derek Buitenhuis
On 11/20/2017 10:35 AM, Matteo Naccari wrote: > +enabled libturing && require_pkg_config libturing libturing turing.h > turing_version && > + { check_cpp_condition turing.h > "TURING_API_VERSION > 1" || > + die "ERROR: libturing

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

2017-11-20 Thread Derek Buitenhuis
On 11/20/2017 2:50 PM, Dave Rice wrote: > I am hesitant to see write_colr option removed since the guesswork used here > https://github.com/FFmpeg/FFmpeg/blob/8f4702a93f87f9f76563e80f1ae2141a40029d9d/libavformat/movenc.c#L1747-L1775 > would then be applied to all movs of standard HD and SD size

Re: [FFmpeg-devel] [PATCH 1/6] decklink: Fix case where return value wasn't being set before checked for errors

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > I missed an assignement which cauesd the error case to not ever be properly > checked. > > Signed-off-by: Devin Heitmueller > --- > libavdevice/decklink_enc.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [FFmpeg-devel] [PATCH] avformat/mov: Propagate errors in mov_switch_root.

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:28 AM, Jacob Trimble wrote: > Signed-off-by: Jacob Trimble > --- > libavformat/mov.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Looks OK. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > +uint8_t *audio_in = ((uint8_t *) audioFrameBytes) + > audio_offset; > +for (int x = 0; x < pkt.size; x += sample_size) { I realize this is C++, but I'm not sure if we still try to stick to our C style (aka no

Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > Make use of libklvanc from within the decklink capture module, > initially for EIA-708 and AFD. Support for other VANC types will > come in subsequent patches. > > Signed-off-by: Devin Heitmueller > --- >

Re: [FFmpeg-devel] [PATCH 6/6] decklink: Add support for SCTE-104 to decklink capture

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > --- > libavcodec/avcodec.h| 1 + > libavcodec/codec_desc.c | 6 > libavdevice/decklink_common.h | 6 > libavdevice/decklink_common_c.h | 1 + > libavdevice/decklink_dec.cpp| 64 >

Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:32 AM, Devin Heitmueller wrote: > I don’t have strong feelings either way. I’m happy to jam this into a > subsequent cleanup patch if nobody has an objection (it’s just much easier > since I have about 15 commits after this one in my Git tree). Looks like nobody is bothered,

Re: [FFmpeg-devel] [PATCH 3/6] Preserve AFD side data when going from AVPacket to AVFrame

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > This is needed to ensure that AFD data continues to work when > capturing V210 video with the Decklink libavdevice input. > > Signed-off-by: Devin Heitmueller > --- > libavcodec/decode.c | 1 + > 1 file changed, 1

Re: [FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote: > +/* Active Format Description */ > +if (x4->afd) { > +void *sei_data; > +size_t sei_size; > + > +ret = ff_alloc_afd_sei(frame, 0, _data, _size); > +if (ret < 0) { > +

Re: [FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:38 AM, Devin Heitmueller wrote: > For whatever reason, the spec explicitly calls for the country code to be set > to these values. Here’s the specific language from the spec: > > itu_t_t35_country_code – A fixed 8-bit field, the value of which shall be > 0xB5. >

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

2017-11-14 Thread Derek Buitenhuis
On 11/14/2017 2:15 AM, Sasi Inguva wrote: > Signed-off-by: Sasi Inguva > --- > libavformat/mov.c| 48 > > tests/fate/mov.mak | 5 + > tests/ref/fate/mov-guess-delay-1 | 3 +++ >

Re: [FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.

2017-11-04 Thread Derek Buitenhuis
On 11/3/2017 6:23 PM, Kieran Kunhya wrote: > This patch fixes very high memory usage on pathological streams. [...] > -H2645Packet pkt = { 0 }; > +H2645Packet pkt; > +memset(, 0, sizeof(pkt)); Stray unrelated change. Rest seems reasonable from a cursory glance. I assume it's been

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

2017-11-01 Thread Derek Buitenhuis
On 11/1/2017 1:36 AM, Michael Niedermayer wrote: > The idea would be that there would only be one uint8_t buffer and the > 2000 entries from te pool would point into that. > So as a larger NAL shifts through the 2000 the pointers would get > distributed differently but the size would not grow >

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

2017-11-02 Thread Derek Buitenhuis
On 11/2/2017 10:48 PM, Kieran Kunhya wrote: > I have tried this using the following patch but it does not work: > https://www.irccloud.com/pastebin/qobTcW9d/ > > Nothing obviously seems wrong so I suspect it's not possible to do this > whilst reusing the code between decoder and parser. > The old

Re: [FFmpeg-devel] [PATCH]lavc/alac: Avoid allocating huge memory blocks for malicious alac input.

2017-11-01 Thread Derek Buitenhuis
On 11/1/2017 2:25 PM, Carl Eugen Hoyos wrote: > It appears to me that the alac decoder can be used for DoS, the attached patch > limits the maximum frame size to eight times the default value. > (Higher values brake our encoder here.) Since the official ALAC encoder/decoder are open ource

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

2017-11-09 Thread Derek Buitenhuis
On 11/9/2017 12:21 PM, James Cowgill wrote: > +if (avci->draining_done && pkt && pkt->size != 0) { > +av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n"); > +avcodec_flush_buffers(avctx); > +} Is it more sensible to actually return an error here? Otherwise

Re: [FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

2017-11-09 Thread Derek Buitenhuis
On 11/9/2017 1:23 PM, Rostislav Pehlivanov wrote: >> For now, and only because you looked at the code. But the current code >> does not follow the documentation, so it is really a fix. >> >> > That type of fix is called a correction. It's a fix. Relying on internal implementation knowledge is a

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2

2017-11-09 Thread Derek Buitenhuis
On 11/9/2017 12:39 AM, Jun Zhao wrote: > From 5afdf252b3bb6f8c7a276c2a8bde8f4a95d170e4 Mon Sep 17 00:00:00 2001 > From: Jun Zhao > Date: Wed, 8 Nov 2017 21:04:51 +0800 > Subject: [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2 > > ff_alloc_packet have been deprecated,

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
>> The commit that broke it should be reverted until the author >> of that commit can explain why it changed, or fix it. > > The commit that added the test was the one that broke fate. It never > worked. > So this "sort of" reverts what caused the issue. Wasn't the code it tests added directly

Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault)

2017-12-04 Thread Derek Buitenhuis
On 12/4/2017 4:28 AM, Colin NG wrote: > --- > libavformat/dashdec.c | 112 > -- > 1 file changed, 99 insertions(+), 13 deletions(-) Please describe what is actually being changed, and why, in the commit message. It is both hard to review with no

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

2017-12-04 Thread Derek Buitenhuis
On 12/4/2017 12:45 PM, Carl Eugen Hoyos wrote: > Committers have to be subscribed to -cvslog. "Have to"? I certainly am not, and neither are many. Are you going to kick all of them out and revoke their push access? I think not. It's clear that the majority here do not agree with you on this

Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors

2017-12-04 Thread Derek Buitenhuis
On 12/4/2017 8:03 AM, Mateusz wrote: > After commit 3701d49 'error_resilience: remove avpriv_atomic usage' > we have included windows.h in much more files and we should > avoid conflicts with defines/function declarations. > > Signed-off-by: Mateusz Brzostek > --- >

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

2017-12-05 Thread Derek Buitenhuis
On 12/6/2017 12:36 AM, Jacob Trimble wrote: > Would a 0-length array work? Otherwise I would need to have it be a > 1-length array and have to account for that when calculating the size > to allocate; it would also require a comment to ignore the size of the > array. Aren't 0-length arrays a GNU

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

2017-12-05 Thread Derek Buitenhuis
On 12/5/2017 11:00 PM, Jacob Trimble wrote: > Also, can I use the flexible array member feature, it was introduced > in C99? Would a 0-length array be better? No, I don't think this would be OK inside a public header, unfortunately. - Derek ___

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/6/2017 12:12 AM, Michael Niedermayer wrote: > The test produces different output on qemu arm and x86-64. > From this we know there is a bug, but not where the bug is. > It can be in the test, the newly added code tested or code that was > there before. > > My guess was, its the test, i

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

<    1   2   3   4   5   6   7   8   9   10   >