Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-06 Thread Derek Buitenhuis
On 06/04/2019 18:40, Marton Balint wrote: > Sorry, vote has been called for, and I used the commit count to select > people as in the second extension: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html That's from 2015... - Derek

Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices

2019-03-25 Thread Derek Buitenhuis
On 21/03/2019 21:30, Michael Niedermayer wrote: > about this specific file, > derek should have write access to samples as well I actually don't remember the specifics / servers / etc... - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices

2019-03-21 Thread Derek Buitenhuis
On 21/03/2019 16:19, James Almer wrote: > FATE_HEVC-$(call DEMDEC, MOV, HEVC) Changed locally. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices

2019-03-21 Thread Derek Buitenhuis
On 21/03/2019 15:29, Derek Buitenhuis wrote: > Definitely sure it's covered within this command, and file's number of > packets. > > Easy to verify: Run the fate test with your patch reverted, and it deadlocks. Scratch that. I was mistaken, it doesn't work with the trimmed file...

[FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices

2019-03-21 Thread Derek Buitenhuis
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. Signed-off-by: Derek Buitenhuis --- Same sample link as v2. Also of note: I'm only adding the -t arg because FATE doesn't seem to have a good way to allow ffmpeg to return a non-zero error code, but also have the test

Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices

2019-03-21 Thread Derek Buitenhuis
On 21/03/2019 15:26, James Almer wrote: > Are you sure the faulty packet is the third one? When i debugged this > the one that reproduced the issue was the 31st. Or is this a cut sample > starting from the faulty RAP? Definitely sure it's covered within this command, and file's number of packets.

[FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices

2019-03-21 Thread Derek Buitenhuis
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. Signed-off-by: Derek Buitenhuis --- Sample: http://chromashift.org/two_first_slice.mp4 (Trimmed to 500KiB like Carl requested). MD5: 58b637d5500c2911d8cfe99fee86cb04 --- tests/fate/hevc.mak | 3

Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: decode at most one slice reporting being the first in the picture

2019-03-20 Thread Derek Buitenhuis
On 18/03/2019 20:31, James Almer wrote: > Fixes deadlocks when decoding packets containing more than one of the > aforementioned > slices when using frame threads. > > Signed-off-by: James Almer > --- If there are no other comments / objections, could this be pushed? - Derek

Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 20:44, Michael Niedermayer wrote: > do you have a sample for h264 ? (or only teh one for hevc) ? On hand, just HEVC. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 18:38, James Almer wrote: > So, what i'm seeing here is two slice NALs in the same packet (which > means processed in the same decode_nal_units() loop in hevcdec.c) > reporting being the "first slice segment in the pic". And that's > seemingly making the threading logic shit itself.

[FFmpeg-devel] [PATCH] h2645_parse: Fix loglevel for NAL header parsing

2019-03-18 Thread Derek Buitenhuis
We don't treat this as an error. Signed-off-by: Derek Buitenhuis --- libavcodec/h2645_parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c index 942f2c5d71..24658b3dfa 100644 --- a/libavcodec/h2645_parse.c +++ b

Re: [FFmpeg-devel] [PATCH 0/2] HEVC/H.264 Parsing / Deadlock Fix

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 15:55, Carl Eugen Hoyos wrote: > The first 500k of this file allow to reproduce the issue, > so I believe the sample is too big. Sure, I can trim it. I'll resend the test + file once a solution is agreed upon. - Derek ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 15:50, James Almer wrote: > This will abort the splitting process when it's meant to only discard > the faulty NAL. Even the log message stats it's skipping it. The log message also claims to be AV_LOG_ERROR. Also there are no comments indicating why this is right, or any commit I

[FFmpeg-devel] [PATCH 2/2] FATE: Add test for HEVC NAL header parsing deadlock

2019-03-18 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis --- tests/fate/hevc.mak | 3 +++ tests/ref/fate/hevc-nal-header-deadlock | 12 2 files changed, 15 insertions(+) create mode 100644 tests/ref/fate/hevc-nal-header-deadlock diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak

[FFmpeg-devel] [PATCH 0/2] HEVC/H.264 Parsing / Deadlock Fix

2019-03-18 Thread Derek Buitenhuis
FATE sample is located here: http://chromashift.org/nal_header_deadlock.mp4 md5sum is: 166f5959a67fccf3017eaeb010a64fcf Since it causes a deadlock in FFmpeg, please be careful if opening in e.g. a browser. Derek Buitenhuis (2): h2645_parse: Propagate NAL header parsing errors FATE

[FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
@ 0x577107c0] thread_get_buffer() failed [hevc @ 0x577107c0] Error parsing NAL unit #5. Error while decoding stream #0:0: Cannot allocate memory Signed-off-by: Derek Buitenhuis --- libavcodec/h2645_parse.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec

Re: [FFmpeg-devel] [PATCH] lavc/libx265: signal CPB properties through side data

2019-03-03 Thread Derek Buitenhuis
On 23/02/2019 00:35, Jan Ekström wrote: > This way values such as maxrate/bufsize can be utilized > further down the chain. > --- > libavcodec/libx265.c | 8 > 1 file changed, 8 insertions(+) OK. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-03-01 Thread Derek Buitenhuis
On 01/03/2019 03:18, Guo, Yejun wrote: > yes, that's the reason I pending VP9 work. As for VP8 ROI, another thinking > is to first push vp8 roi, since libvpx is an external dependency and we don't > know the time when it is available for vp9 roi. Anyway, I'm open to both. Presumably the

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-02-27 Thread Derek Buitenhuis
On 27/02/2019 17:57, Derek Buitenhuis wrote: > You're assuming a single ROI, though, which is only one case. Plenty of things > would need >1. Also note that sets of ROIs are per-frame. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@f

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-02-27 Thread Derek Buitenhuis
On 27/02/2019 17:31, Gyan wrote: > Yes, a string. 4 integers and qp offset so either two more, in rational > form, or a float. You're assuming a single ROI, though, which is only one case. Plenty of things would need >1. > There's already multiple interfaces accepting long multi-entry >

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-02-27 Thread Derek Buitenhuis
On 27/02/2019 16:12, Guo, Yejun wrote: > Signed-off-by: Guo, Yejun > --- > libavcodec/libvpxenc.c | 132 > + > 1 file changed, 132 insertions(+) Do these APIs exist for all supported libvpx versions? > +if (!sd) { > +if

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-02-27 Thread Derek Buitenhuis
On 27/02/2019 13:48, Gyan wrote: > Huh. I haven't suggested removing anything. > > I suggested *adding* a way for this feature to be useful for ffmpeg > users in the near-term. Who knows how long will it take for a decent > per-frame ROI filter, like the facedetect example mentioned in the >

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8 support for ROI-based encoding

2019-02-27 Thread Derek Buitenhuis
On 27/02/2019 10:22, Gyan wrote: > Looks like, at present, the only way to effect ROI is via side data, and > no filter or other in-tree mechanism at present can convey or generate it. Life exists outside of ffmpeg.c, and it's an extremely useful API to have. > Are there any near-term plans to

Re: [FFmpeg-devel] [PATCH] avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream

2019-02-13 Thread Derek Buitenhuis
On 12/02/2019 22:28, Michael Niedermayer wrote: > @@ -5048,7 +5048,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > for (i = 0; i < c->fc->nb_streams; i++) { > st = c->fc->streams[i]; > sc = st->priv_data; > -if

Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun

2019-02-07 Thread Derek Buitenhuis
On 07/02/2019 19:30, Chris Cunningham wrote: > This will reject the file entirely. The testcase I have (can share once > chromium bug is fixed) was previously hitting an av_assert0 in > mov_read_trun, arguably also a total rejection ;). Recovery for this could > be pretty tricky since the dropped

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Derek Buitenhuis
On 07/02/2019 16:43, Werner Robitza wrote: > Several people have already volunteered in this thread (Reto, Kyle and > me), as well as the author of this formula (with whom I've had offline > discussions), which we can use as a starting point: >

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Derek Buitenhuis
On 07/02/2019 08:06, Werner Robitza wrote: >> I don't think that's the suggestion. Separate Github repo belonging to >> the FFmpeg Github organization. > > Correct. No modification in the source tree. I guess my question is: Who amongst the devs here wants to write it? (Not me.) - Derek

Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun

2019-02-07 Thread Derek Buitenhuis
On 07/02/2019 00:12, chcunningham wrote: > Detecting missing tfhd avoids re-using tfhd track info from the previous > moof. For files with multiple tracks, this may make a mess of the > avindex and fragindex, which can later trigger av_assert0 in > mov_read_trun(). > --- > libavformat/isom.h | 1

Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely

2019-01-24 Thread Derek Buitenhuis
On 24/01/2019 20:53, Rostislav Pehlivanov wrote: > NAK, NAK, NAK. Seconded. Please, please, no. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V3] avcodec/libx265: add support for ROI-based encoding

2019-01-23 Thread Derek Buitenhuis
On 23/01/2019 16:11, Guo, Yejun wrote: > Signed-off-by: Guo, Yejun > --- > libavcodec/libx265.c | 66 > > 1 file changed, 66 insertions(+) > > diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c > index 27c90b3..9841536 100644 > ---

Re: [FFmpeg-devel] [PATCH V2] avcodec/libx265: add support for ROI-based encoding

2019-01-22 Thread Derek Buitenhuis
On 21/01/2019 14:40, Guo, Yejun wrote: [...] > +} else { > +// 8x8 block when qg-size is 8, 16*16 block otherwise Cosmetic: Comments should be /**/ to match the rest of the file. > +int mb_size = (ctx->params->rc.qgSize == 8) ? 8 : 16; > +int mbx =

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: add support for ROI-based encoding

2019-01-18 Thread Derek Buitenhuis
On 18/01/2019 15:53, Guo, Yejun wrote: [...] > +static av_cold int libx265_encode_set_roi(libx265Context *ctx, const AVFrame > *frame, x265_picture* pic) > +{ > +// From x265.h: > +/* An array of quantizer offsets to be applied to this image during > encoding. > +* These are added

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

2019-01-18 Thread Derek Buitenhuis
On 17/01/2019 23:33, Michael Niedermayer wrote: > Would you be ok with rejecting RSCC files without a keyframe ? > or more precissely all frames before a keyframe and thus if there is > no keyframe the whole file > (that would be a superset of what this patch rejects) This, to me, soundsp

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

2019-01-18 Thread Derek Buitenhuis
On 18/01/2019 11:46, Carl Eugen Hoyos wrote: > No, you are completely missing the point. I am not. I fully understand the argument in favour of these, I just don't agree. > Possible security issues in this decoder will only be > searched (and therefore found) if the decoder doesn't > timeout

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

2019-01-17 Thread Derek Buitenhuis
On 16/01/2019 12:39, Derek Buitenhuis wrote: > On 16/01/2019 00:41, Guo, Yejun wrote: >> this patch set asks for pushing if no more concerns, thanks. > > I support this. > > If nobody raises any concerns in the next 24-48 hrs, I'll go ahead. > > Thank you f

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

2019-01-17 Thread Derek Buitenhuis
On 17/01/2019 03:06, Carl Eugen Hoyos wrote: > You mean searching for security issues makes no sense? This isn't a security and it isn't a fix. It's a completely arbitrary statistic to make an arbitrary program happy. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH V8 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

2019-01-17 Thread Derek Buitenhuis
On 10/01/2019 08:53, Guo, Yejun wrote: > --- > doc/APIchanges | 3 +++ > libavutil/frame.c | 1 + > libavutil/frame.h | 35 +++ > libavutil/version.h | 2 +- > 4 files changed, 40 insertions(+), 1 deletion(-) Pushed, as stated. - Derek

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2019-01-17 Thread Derek Buitenhuis
On 15/01/2019 21:24, Michael Niedermayer wrote: > Heres a better patch which may work with seeking as long as there are only > 2 files concatenated > > i think completely discarding the parts after the concatenation would cause > user complaints and they would have a point, if the data is in

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

2019-01-16 Thread Derek Buitenhuis
On 16/01/2019 00:41, Guo, Yejun wrote: > this patch set asks for pushing if no more concerns, thanks. I support this. If nobody raises any concerns in the next 24-48 hrs, I'll go ahead. Thank you for sticking with it through the bikeshedding. - Derek

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 18:24, James Almer wrote: > I thought i had amended the patch, but guess not... > > I can revert and reapply with the amended commit message if you want, > but it will kinda litter the tree for not a lot of gain. Then again, the > tree is already a mess with all the merges. Not

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 18:01, James Almer wrote: > Pushes as is then. Thanks. Er. You didn't add the actual description of the problem/fix to the commit message. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 15:45, James Almer wrote: > If there is, i don't know it. > > Float based fate tests have been fine tuned before when different > architectures proved a certain stddev value was not lax enough, so this > one could be increased if needed as well, but if you prefer i can use a > big

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 14:52, Nicolas George wrote: > Therefore, I ask reasons: if you do not want to disclose your > sponsorships, please explain why? https://en.wikipedia.org/wiki/Nothing_to_hide_argument - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 14:38, Nicolas George wrote: > Any unmotivated objection can be interpreted as "I push bad code for a > quick buck and do not intend to stop", do you not think? No, I don't think that, and I think it's offensive to the people who you accuse of that. - Derek

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 13:18, Nicolas George wrote: > I seem to remember that arguments count, not voices. I have given > several arguments in the commit message, almost none of them were > addressed and the dissenting arguments were feeble at best. This is a policy change, not a techncal change. - Derek

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 02:44, James Almer wrote: > Michael suggested 1000*FLT_EPSILON but IMO that's too big and may hide > errors in future implementations. > The value i used is the smallest value i found that didn't fail after > several runs. 6.1e-05 for example fails. I figured that's how it was

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 18:21, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > doc/developer.texi | 10 ++ > 1 file changed, 10 insertions(+) Rather than repeat myself, I'll refer to my previous mails: * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html *

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 16:23, Nicolas George wrote: > Derek Buitenhuis (12019-01-11): >> Irrelevant to whether a patch is acceptable or not to FFmpeg. > > In theory, it is, and it should be. > > In practice, I have several times suspected a sponsored work was the > reason behi

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 15:26, Nicolas George wrote: > Carl Eugen Hoyos (12019-01-11): >> The original unfinished demuxer was posted to the development >> mailing list: >> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html > > Ah, good to know. Still, Paul made efforts to resurrect that

Re: [FFmpeg-devel] [PATCH]lavc/tiff: Support some CMYK samples

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 14:54, Carl Eugen Hoyos wrote: > Hi! > > Attached patch that fixes the sample from ticket #3459 cannot be > factorized with the code in mjpegdec (and psd), the representation is > different. Is there a good reason this is RGB0 instead of RGB24? Other than that, seems OK, if tested

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 14:20, Carl Eugen Hoyos wrote: > Yes, but they can have different representations in FFmpeg. I suppose the "correct" fix is to put it in swscale, but noone is going to want to do that. > Is this patch ok? No strong opinion. I doubt anyone will want to patch swscale, so I suppose

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 13:28, Hendrik Leppkes wrote: > Because the computation accumulates more inaccuarcy then FLT_EPSILON > allows for. That value is really not of that great use. If you have > two accurate numbers and do one calculation, it may work, but if you > do a whole bunch of them, the error

Re: [FFmpeg-devel] [PATCH]lavc: Allow very high bitrates in AVCPBProperties after next version bump

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 00:07, James Almer wrote: > Probalby correct. bitrate fields in AVCodecContext are all int64_t, and > AVCPBProperties fields are usually set to those. Only semi-related: Is it useful to properly clip the bitrate to INT_MAX/INT_MIN where we set it currently (behind deprecation

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-11 Thread Derek Buitenhuis
On 10/01/2019 23:34, James Almer wrote: > -if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) { > +if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) { Can you elaborate a bit more on this? FLT_EPSILON is used correctly here as far as I can tell, and it is not clear why it

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 06:17, Peter Ross wrote: > the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel > support. > i guess it is trivial enough to be duplicated here. Is it worth deduplicating? Plenty of image formats have CMYK. - Derek ___

Re: [FFmpeg-devel] [PATCH] avcodec/nuv: add FF_CODEC_CAP_INIT_CLEANUP

2019-01-11 Thread Derek Buitenhuis
On 11/01/2019 01:15, Michael Niedermayer wrote: > Fixes: memleak > Fixes: > 12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > --- > libavcodec/nuv.c | 1

Re: [FFmpeg-devel] [PATCH] configure: add support for configuring dlltool

2019-01-08 Thread Derek Buitenhuis
On 08/01/2019 16:35, Andoni Morales wrote: > In a multilib toolchain dlltool has to be configured with the correct > architecture options. > This option allows configuring dlltool this way: > --dlltool="x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386" Unsure why this is needed... we already

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

2019-01-04 Thread Derek Buitenhuis
On 04/01/2019 14:15, Nicolas George wrote: > Rostislav Pehlivanov (12019-01-04): >> Hence an AVRational is appropriate as you can have fractions between 0 and >> 1, the encoder can adjust it and it'll be agnostic. > > Yes, AVRational is fine. Producing warnings for an unexpected > denominator

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2019-01-03 Thread Derek Buitenhuis
On 03/01/2019 01:33, Michael Niedermayer wrote: > The file looks like 2 files concatenated, even with FLV main header between > them. Yes, they all seem to be. I was under the impression FLV didn't have a header to check against like this. Seems I was wrong. > the patch below should make this

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2019-01-02 Thread Derek Buitenhuis
On 24/12/2018 16:42, Derek Buitenhuis wrote: > Ping. Is there a decision on eitehr what to do or to ignore this? > > I'll update my downstream code with an FLV edge case if need be. Ping. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@f

Re: [FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack

2019-01-02 Thread Derek Buitenhuis
On 01/01/2019 15:50, Derek Buitenhuis wrote: > If there are no objections, I will push in a day or two. Pushed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack

2019-01-01 Thread Derek Buitenhuis
On 24/12/2018 19:55, Derek Buitenhuis wrote: > --- > v1 had accidentally removed a cast. Woops. > libavformat/mov.c | 6 -- > 1 file changed, 6 deletions(-) If there are no objections, I will push in a day or two. - Derek ___ ffmpeg-d

Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls

2018-12-31 Thread Derek Buitenhuis
On 31/12/2018 09:12, Alex Mogurenko wrote: > I seems to be lame as failed to find how to run fate to check prores_ks :( General way to run all of FATE: $ configure --samples=/home/path/for/samples/ --enable-gpl [...] $ make fate-rsync $ make fate There are sub-targets, too, as listed in

Re: [FFmpeg-devel] [PATCH 6/6] avcodec/mjpegbdec: Propagate error codes

2018-12-30 Thread Derek Buitenhuis
On 28/12/2018 21:22, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpegbdec.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) OK. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/mjpegbdec: Fix some misplaced {} and spaces

2018-12-30 Thread Derek Buitenhuis
On 28/12/2018 21:22, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpegbdec.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) OK. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks: fixed luma quantize if q >= MAX_STORED_Q

2018-12-30 Thread Derek Buitenhuis
On 29/12/2018 16:34, Derek Buitenhuis wrote: > I think it's OK. > > I'll push it in 24 hours if noone else objects. Pushed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] tools/target_dec_fate.sh: print some statistics

2018-12-29 Thread Derek Buitenhuis
On 29/12/2018 09:47, Moritz Barsnick wrote: > I believe this is the sort of math that won't work on old, non-POSIX > Bourne shells. (I'm thinking Solaris /bin/sh here.) In case that > even matters. I don't think we care about those, e.g.: ~/ffmpeg$ grep '+1)' configure eval

Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks: fixed luma quantize if q >= MAX_STORED_Q

2018-12-29 Thread Derek Buitenhuis
On 28/12/2018 20:30, Alex Mogurenko wrote: > --- > libavcodec/proresenc_kostya.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) I think it's OK. I'll push it in 24 hours if noone else objects. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack

2018-12-29 Thread Derek Buitenhuis
On 29/12/2018 10:36, Carl Eugen Hoyos wrote: > Please provide a sample. I mean, the hack being removing is *obviously* wrong and against the QTFF and ISOBMFF specs, to ignore values based on a heuristic. However, since you insist: http://chromashift.org/ffmpegsamps/valid_file.mp4 - Derek

Re: [FFmpeg-devel] [PATCH] fixed luma quantizing when q >= MAX_STORED_Q

2018-12-28 Thread Derek Buitenhuis
On 28/12/2018 17:04, Alex Mogurenko wrote: > problem occurs in slice quant estimation and slice encoding. > > if slice quant >= MAX_STORED_Q we dont use pre-calculated quant matrices > but generate new: > > qmat = ctx->custom_q; > > qmat_chroma = ctx->custom_q; > > for (i = 0;

Re: [FFmpeg-devel] [PATCH] fixed luma quantizing when q >= MAX_STORED_Q

2018-12-28 Thread Derek Buitenhuis
On 27/12/2018 19:28, Alex Mogurenko wrote: > --- > libavcodec/proresenc_kostya.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Can you give a little more detail about what's changed and why, in the commit message? It looks like custom_chroma_q is zero initialized and never set

Re: [FFmpeg-devel] Plans to support HLS-compatible AES-CBCS for MP4

2018-12-28 Thread Derek Buitenhuis
On 28/12/2018 15:39, Toby Steele wrote: > I was wondering whether there are plans to support AES-CBCS mode encryption > as well? This is needed to support CENC-compatible encrypted HLS content > using the fragmented MP4 container format, and so would be a very useful > addition. I'm not aware of

Re: [FFmpeg-devel] Install from Source on CentOS 7

2018-12-28 Thread Derek Buitenhuis
On 28/12/2018 16:21, Larry Apolonio wrote: > [...] You'd need to post your whole config.log (pastebin) likely. However, this list is for development of FFmpeg itself, and this question should be on the user mailing list, or #ffmpeg on FreeNode, where you'll likely get better answers. Cheers, -

Re: [FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack

2018-12-28 Thread Derek Buitenhuis
On 24/12/2018 19:55, Derek Buitenhuis wrote: > This breaks totally valid files that get caught in its heuristic. > > This, according to the commit message, is my own doing, having asked > Michael to implement this check and providing a sample that was > "wrong". I a

Re: [FFmpeg-devel] [PATCH V4 2/2] avcodec/libx264: add support for ROI-based encoding

2018-12-28 Thread Derek Buitenhuis
On 28/12/2018 10:10, Guo, Yejun wrote: > This patch just enables the path from ffmpeg to libx264, > the more encoders can be added later. > > Signed-off-by: Guo, Yejun > --- > libavcodec/libx264.c | 39 +++ > 1 file changed, 39 insertions(+) Seems OK. -

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

2018-12-28 Thread Derek Buitenhuis
On 28/12/2018 10:09, Guo, Yejun wrote: > The encoders such as libx264 support different QPs offset for different MBs, > it makes possible for ROI-based encoding. It makes sense to add support > within ffmpeg to generate/accept ROI infos and pass into encoders. > > Typical usage: After AVFrame is

Re: [FFmpeg-devel] [PATCH V3 3/3] add an example to show how to fill the ROI info

2018-12-27 Thread Derek Buitenhuis
On 27/12/2018 11:06, Guo, Yejun wrote: > This patch is just a quick example to show how to fill the ROI info, > it does not ask for upstreaming, just for your reference. > > to verify the ROI feature with this example, the command line looks like: > ./ffmpeg -i .../path_to_1920x1080_video_file

Re: [FFmpeg-devel] [PATCH V3 1/3] avutil: add ROI data struct and bump version

2018-12-27 Thread Derek Buitenhuis
On 27/12/2018 11:05, Guo, Yejun wrote: > enum AVActiveFormatDescription { > @@ -200,6 +206,19 @@ typedef struct AVFrameSideData { > AVBufferRef *buf; > } AVFrameSideData; > > +typedef struct AVROI { > +/* coordinates at frame pixel level. > + * It will be extended internally if

Re: [FFmpeg-devel] [PATCH V3 2/3] avcodec/libx264: add support for ROI-based encoding

2018-12-27 Thread Derek Buitenhuis
On 27/12/2018 11:06, Guo, Yejun wrote: > +AVFrameSideData *sd = av_frame_get_side_data(frame, > AV_FRAME_DATA_ROIS); > +if (sd != NULL) { Nit: `if (sd)` is convention. > +qoffsets = (float*)av_mallocz_array(mbx * mby, > sizeof(*qoffsets)); > +

[FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack

2018-12-24 Thread Derek Buitenhuis
light (aka that this was silly to do in the first place). Resotores correct behavior on valid files. This reverts commit 8e5e84c2a2a21a979b48e80c5a8dd44754ab3f21. Signed-off-by: Derek Buitenhuis --- v1 had accidentally removed a cast. Woops. libavformat/mov.c | 6 -- 1 file changed, 6 deletions(-)

[FFmpeg-devel] [PATCH] mov: Remove duration-of-last-frame heuristic hack

2018-12-24 Thread Derek Buitenhuis
light (aka that this was silly to do in the first place). Resotores correct behavior on valid files. This reverts commit 8e5e84c2a2a21a979b48e80c5a8dd44754ab3f21. Signed-off-by: Derek Buitenhuis --- libavformat/mov.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/libavform

Re: [FFmpeg-devel] [PATCH v3] avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 06:07, gxw wrote: > The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is > still 32 > in function ff_hevc_sao_edge_filter_8_msa. So, use > AV_INPUT_BUFFER_PADDING_SIZE directly. > Also, use MAX_PB_SIZE directly instead of 64. Fate tests passed. > --- >

Re: [FFmpeg-devel] patch for failing on WavPack DSD files

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 17:47, David Bryant wrote: > I want to do that, but am swamped at work right now, so it will probably be a > few months before I can get to that. > > In the meantime, I think this patch would be a safe stopgap (and prevent the > Kodi crash). I think it's OK for the meantime (my

Re: [FFmpeg-devel] [PATCH 1/3] vcodec/lagarith: Remove duplicate check

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 00:14, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/lagarith.c | 3 --- > 1 file changed, 3 deletions(-) OK. (Can you tell it's Christmas, and I have free time now...? :V) - Derek ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/lagarith: Optimize case with singleton probability distribution

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 00:14, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 > > Found-by: continuous fuzzing > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael

Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based encoding

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 08:41, Guo, Yejun wrote: >>> +size_t nb_rois = frame->rois_buf->size / >>> + sizeof(AVFrameROI); >> >> I think we have some macros that do this already. > > I tried a code search and do not find one, there is a similar macro which > does not work for this case:

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2018-12-24 Thread Derek Buitenhuis
On 26/11/2018 13:51, Derek Buitenhuis wrote: > On 23/11/2018 02:16, Michael Niedermayer wrote: >> do we have some sample flv files that require this patchset / that have >> discontinuites. > > I have many. I've mailed you one privately, while I work on getting a public >

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()

2018-12-24 Thread Derek Buitenhuis
On 24/12/2018 00:14, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > Found-by: continuous fuzzing > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

2018-12-22 Thread Derek Buitenhuis
On 22/12/2018 14:54, Valery Kot wrote: > Ping... > Any maintainer willing to review/push straightforward one-liner patch? > >> Thus 59MB leak in an hour! And keeps growing... Can you add to the commit message to explain what exactly is changed and why? 'Fix leak' isn't very useful. Cheers, -

Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based encoding

2018-12-21 Thread Derek Buitenhuis
A few comments below. On 12/12/2018 16:26, Guo, Yejun wrote: > +if (frame->rois_buf != NULL) { > +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) { > +av_log(ctx, AV_LOG_ERROR, "Adaptive quantization must be > enabled to use ROI encoding, skipping ROI.\n"); This

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2018-11-26 Thread Derek Buitenhuis
On 23/11/2018 02:16, Michael Niedermayer wrote: > do we have some sample flv files that require this patchset / that have > discontinuites. I have many. I've mailed you one privately, while I work on getting a public one. > another thing i just realize now, why is this discontinuity issues

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2018-11-22 Thread Derek Buitenhuis
On 22/11/2018 12:55, Carl Eugen Hoyos wrote: > Only the downstreams that expect invalid files, no? It's the generic way to handle containers which can have discontinuous timestamps. Nothing to do with expecting invalid files. Cheers, - Derek ___

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2018-11-22 Thread Derek Buitenhuis
On 22/11/2018 02:16, Michael Niedermayer wrote: > the specification says this: > "Timestamp UI24 Time in milliseconds at which the data in this tag > applies. This is relative to the first tag in the FLV file, > which always has a timestamp of 0. > " > So flv does

Re: [FFmpeg-devel] [PATCH 1/3] fftools/ffmpeg: Don't mangle start time based on discontinuities for FLV

2018-11-21 Thread Derek Buitenhuis
On 21/11/2018 16:31, Hendrik Leppkes wrote: > Format name comparisons are basically always wrong. Don't we have > AVFMTCTX_NOHEADER for that? I could change it to use that, yeah. I'll send a v2 that does, if the author agrees it's the correct fix. - Derek

[FFmpeg-devel] [PATCH 3/3] lavf: Depecate the live_flv demuxer

2018-11-21 Thread Derek Buitenhuis
It is now the same as the regular FLV demuxer, and has no reason to exist. Signed-off-by: Derek Buitenhuis --- libavformat/allformats.c | 2 ++ libavformat/flvdec.c | 2 ++ libavformat/version.h| 3 +++ 3 files changed, 7 insertions(+) diff --git a/libavformat/allformats.c b

[FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2018-11-21 Thread Derek Buitenhuis
*actually* works. Lying to downstream API users about a demuxer's behavior is not OK. Also set AVFMT_NOBINSEARCH, as this should be true given discontinuous timetsamps. Signed-off-by: Derek Buitenhuis --- libavformat/flvdec.c | 14 -- 1 file changed, 4 insertions(+), 10 deletion

[FFmpeg-devel] [PATCH 1/3] fftools/ffmpeg: Don't mangle start time based on discontinuities for FLV

2018-11-21 Thread Derek Buitenhuis
As far as I can tell, this isn't valid here sicne FLV may not have added streams yet. Signed-off-by: Derek Buitenhuis --- fftools/ffmpeg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index a12208cce9..3bc42c8ca8 100644 --- a/fftools

[FFmpeg-devel] [PATCH 0/3] Reconciling some FLV hacks

2018-11-21 Thread Derek Buitenhuis
emuxer" without a deprecation period. Derek Buitenhuis (3): fftools/ffmpeg: Don't mangle start time based on discontinuities for FLV flvdec: Mark the demuxer as allowing discontinuous timestamps lavf: Depecate the live_flv demuxer fftools/ffmpeg.c | 3 ++- libavform

Re: [FFmpeg-devel] [PATCH] Fix link errors when HAVE_X86ASM is not defined

2018-11-21 Thread Derek Buitenhuis
On 21/11/2018 14:09, Hendrik Leppkes wrote: > This does not apply here, the function is called unconditionally on > x86 (or rather on ARCH_X86) > What we usually do is just put the contents of such functions into the > guard, and not the init function itself - instead of having a second > one.

Re: [FFmpeg-devel] [PATCH] Fix link errors when HAVE_X86ASM is not defined

2018-11-21 Thread Derek Buitenhuis
On 21/11/2018 02:47, Haihao Xiang wrote: > This fixes the link errors below: > > LD ffmpeg_g > libavfilter/libavfilter.so: undefined reference to `ff_scene_sad_avx2' > libavfilter/libavfilter.so: undefined reference to `ff_scene_sad_sse2' > collect2: error: ld returned 1 exit status >

  1   2   3   4   5   6   7   8   9   >