[FFmpeg-devel] [PATCH v3] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
This packet was not necessarily unreferenced. Signed-off-by: Derek Buitenhuis --- fftools/ffprobe.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 3becb6330e..5aaddb0308 100644 --- a/fftools/ffprobe.c +++ b/fftools/ffprobe.c

Re: [FFmpeg-devel] [PATCH v2] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
On 21/06/2019 15:26, James Almer wrote: > Remove the three lines below as well before pushing. They are > superfluous as av_packet_unref() does the same internally. OK. The documentation for av_packet_unref says it sets the 'remaining' fields to default values, but av_init_packet says it sets

Re: [FFmpeg-devel] [PATCH v2] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
On 21/06/2019 15:26, Nicolas George wrote: > How can the packet not be unreferenced when the very previous > instruction is av_packet_unref()? All the code paths I see either pass > through the existing av_packet_unref() before reaching the new one or > arrive with a blank packet. Am I missing

Re: [FFmpeg-devel] [PATCH] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
On 21/06/2019 14:46, James Almer wrote: > Why not just call this unconditionally instead of the init() + zero below? I wasn't sure from a quick skim if these packets were referenced elsewhere (and thus unrefercing twice would be problematic). If it's safe to do so, I will. - Derel

[FFmpeg-devel] [PATCH v2] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
This packet was not necessarily unreferenced. Signed-off-by: Derek Buitenhuis --- fftools/ffprobe.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 3becb6330e..dac70ba5a1 100644 --- a/fftools/ffprobe.c +++ b/fftools/ffprobe.c @@ -2429,6 +2429,8

[FFmpeg-devel] [PATCH] ffprobe: Fix memory leak

2019-06-21 Thread Derek Buitenhuis
This packet was not necessarily unreferenced. Signed-off-by: Derek Buitenhuis --- fftools/ffprobe.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index 3becb6330e..52f24e7dfd 100644 --- a/fftools/ffprobe.c +++ b/fftools

Re: [FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet duration

2019-06-19 Thread Derek Buitenhuis
On 19/06/2019 06:43, Gyan wrote: >> setting track_duration is inconsistent; some times it includes >> duration and some times not. > It may be best to check the commits for these assignments to see if the > inconsistency is deliberate. > The track duration is written into the media header box for

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-06-02 Thread Derek Buitenhuis
On 02/06/2019 21:19, Derek Buitenhuis wrote: > This has nothing to do with API changes, it's a Rust toolchain (build > system, specifically) thing. These changes don't change API/ABI. Also to add: We will probably be cutting a 'real' rav1e release soon (0.1.0), I think. That could also be a

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-06-02 Thread Derek Buitenhuis
On 02/06/2019 19:27, Carl Eugen Hoyos wrote: > Since a lot of unexpected changes can happen after months, > this sounds to me like a strong reason to wait. This has nothing to do with API changes, it's a Rust toolchain (build system, specifically) thing. These changes don't change API/ABI. -

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-06-02 Thread Derek Buitenhuis
On 02/06/2019 19:45, Moritz Barsnick wrote: > https://github.com/lu-zero/crav1e says: > > Status > The API is far from stable Yeah, that's not super true any more, and I'll remove it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-06-02 Thread Derek Buitenhuis
On 31/05/2019 23:08, Carl Eugen Hoyos wrote: > So is your patch meant to wait until this merge is done? > I would suggest so... Soon has a (TM) beside it for a reason (there needs to be some work done on Rust itself first, I think.) I would expect it to take at least 1-2 months. The API itself

Re: [FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder

2019-05-30 Thread Derek Buitenhuis
On 30/05/2019 17:27, James Almer wrote: > All three options are important to get decent and/or fast encodings, so > if you'd rather not add options for them, you should document what > key=value combinations can be passed to rav1e-params, either in > encoders.doxy, or as a printed list like

Re: [FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder

2019-05-30 Thread Derek Buitenhuis
On 30/05/2019 15:51, James Almer wrote: > You could add tile-columns, tile-rows, and speed options. I'm of two minds here. One one hand, it is convenient. On the other hand, you may end up with a crappy pile of stuff like libx264.c where everything has its own option or aomenc where new stuff

[FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder

2019-05-29 Thread Derek Buitenhuis
Uses the crav1e C bindings for rav1e. Port to the new send/receive API by: James Almer . Signed-off-by: Derek Buitenhuis --- Changes since v2: * Removed 4:0:0 support; seems broken in rav1e (ref: https://github.com/xiph/rav1e/issues/1312) * Moved to use FF_CODEC_CAP_INIT_CLEANUP

Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder

2019-05-29 Thread Derek Buitenhuis
On 29/05/2019 17:12, James Almer wrote: >> +end: >> +if (cfg) >> +rav1e_config_unref(cfg); >> + >> +if (ret) >> +librav1e_encode_close(avctx); > > Use the FF_CODEC_CAP_INIT_CLEANUP flag in AVCodec.caps_internal instead. > It will call AVCodec.close() on AVCodec.init()

Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder

2019-05-29 Thread Derek Buitenhuis
On 29/05/2019 16:01, Lynne wrote: > for (int i = 0; i < desc->nb_components; i++) { > rav1e_frame_fill_plane() should probably return an error if the plane index > is invalid. Yep. Fixed locally. - Derek ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder

2019-05-29 Thread Derek Buitenhuis
Uses the crav1e C bindings for rav1e. Port to the new send/receive API by: James Almer . Signed-off-by: Derek Buitenhuis --- The only thing I didn't address from the last set of replies was the second 'ret' variable, since I prefer it that way (having a separate ret for avcodec values

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-05-29 Thread Derek Buitenhuis
On 29/05/2019 01:19, James Darnley wrote: > IIRC either qp or cqp Yeah, I'll use that; it makes sense. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-05-28 Thread Derek Buitenhuis
On 28/05/2019 20:58, James Almer wrote: > I think x26* and vpx/aom call it crf? It's not in option_tables.h in any > case. They do not. This is a constant quantizer mode, not constant rate factor. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-05-28 Thread Derek Buitenhuis
On 28/05/2019 20:49, Derek Buitenhuis wrote: >>> +static const AVOption options[] = { >>> +{ "quantizer", "use constant quantizer mode", OFFSET(quantizer), >>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE }, >>> +{ "max-qua

Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-05-28 Thread Derek Buitenhuis
On 28/05/2019 20:32, James Almer wrote: >> +default: >> +// This should be impossible >> +return (RaChromaSampling) -1; > > If it's not meant to happen, then it should probably be an av_assert0. Yeah, that makes more sense. Will change. >> +int rret; >> +int ret = 0;

[FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder

2019-05-28 Thread Derek Buitenhuis
Uses the crav1e C bindings for rav1e. Missing version bump and changelog entry. Signed-off-by: Derek Buitenhuis --- Hoping to get some eyes on this, and maybe help some people who want to test out rav1e without having to use Y4Ms or pipes. Some points: * The C bindings for rav1e currently

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: Support full range videos

2019-05-26 Thread Derek Buitenhuis
On 25/05/2019 22:55, Derek Buitenhuis wrote: > This patch also adds support for checking the AVCOL range. If you object that > strongly to it, I'm sure they don't mind switching to -color_range jpeg. That > works with x264, etc. too. Pushed as-is, as per IRC conversation.

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: Support full range videos

2019-05-25 Thread Derek Buitenhuis
On 25/05/2019 22:31, James Almer wrote: > Ah hell, whatever, just push it. Jeeb pointed out the reason you wrote > this patch. Reverting this patch in the future should be trivial anyway. This patch also adds support for checking the AVCOL range. If you object that strongly to it, I'm sure they

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: Support full range videos

2019-05-25 Thread Derek Buitenhuis
On 25/05/2019 04:25, James Almer wrote: >> + > > Unnecessary empty line. Fixed. > Could we not? The idea is to eventually kill these, so we should at > least try to not make them even more widespread... As far as I know, they can't be removed, as there isn't a simple replacement for some of

Re: [FFmpeg-devel] [PATCH] swresample/swresample: check for invalid sample rates

2019-05-24 Thread Derek Buitenhuis
On 24/05/2019 17:05, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libswresample/swresample.c | 8 > 1 file changed, 8 insertions(+) Seems reasonable. What happens if these aren't in place? - Derek ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH] avcodec/libx265: Support full range videos

2019-05-24 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis --- libavcodec/libx265.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 07bca81aef..f56def53d5 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -133,6 +133,14

Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.

2019-05-24 Thread Derek Buitenhuis
On 23/05/2019 23:58, Darren Mo wrote: > To clarify, do you mean we should merge this now or wait for the second > patch, which fixes the root cause? I have no strong opinion on it. Unsure which is better for a user experience, given they'll both be broken in some way. I'd say merge if you feel

Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.

2019-05-23 Thread Derek Buitenhuis
On 22/05/2019 18:55, Darren Mo wrote: > Good question. The subtitle would be discarded if it overlaps an edit > boundary. > > The root cause is the MOV demuxer currently marks boundary packets for > discard. However, due to subtitle frames not being discarded (fixed by this > patch), the root

Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.

2019-05-22 Thread Derek Buitenhuis
On 29/04/2019 23:45, fumoboy007 wrote: > One situation where a subtitle packet can be marked for discard is when > demuxing an MOV file that has an edit list. > --- > libavcodec/decode.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Will this work properly if a given

Re: [FFmpeg-devel] [PATCH V2] lavf/oggparsevorbis: Fix change the case of metadata keys issue

2019-04-22 Thread Derek Buitenhuis
On 22/04/2019 13:19, myp...@gmail.com wrote: > Ping? > LGTM. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org

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

  1   2   3   4   5   6   7   8   9   10   >