Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

Hi! > On 9 Nov 2023, at 13:28, Anton Khirnov wrote: > > Quoting James Almer (2023-11-09 13:24:45) >> Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they >> should be in the GA. > > Right, I did not mean to imply ALL the people in the above list a

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

le when people with different world views meet head-on, and hope you can discuss in that spirit :) Best regards, Reimar Döffinger ___ 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 with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On 03.05.2019, at 20:16, Michael Niedermayer wrote: > On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote: >> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick >> : > >> And finally: What do you suggest to "punish the violator"? > > while this question wasnt directed at

Re: [FFmpeg-devel] [DECISION] colorhold filter

ary vs. the normal development process? I so far assumed voting was purely a last-resort conflict resolution process. Is there a quorum required, or would a vote be accepted even if there was only one vote cast? Best regards, Reimar Döffinger ___ ffmpeg-

Re: [FFmpeg-devel] [DECISION] colorhold filter

On 05.05.2019, at 18:04, Paul B Mahol wrote: > On 5/5/19, Reimar Döffinger wrote: >> On 04.05.2019, at 15:40, Paul B Mahol wrote: >>> Hi, >>> >>> I open voting for 7 days, for inclusion of colorhold filter in FFmpeg, >>> with minor changes. >&g

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

ery large value, this code will never be able to find the "correct" position. It seems to assume the frame_offset is ordered increasingly (as would be needed for binary search), but that property isn't really checked/enforced. > +av_freep(&ifv->vid_index); > +if (ifv->i

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

On Sun, May 05, 2019 at 10:05:17PM +0200, Carl Eugen Hoyos wrote: > Am So., 5. Mai 2019 um 21:59 Uhr schrieb Reimar Döffinger > : > > > +if (aud_magic == MKTAG('G','R','A','W')) { > > > +ifv->is_audio_p

[FFmpeg-devel] Quo vadis, code of conduct?

ALLY stands behind it (even if most live up to it, that is quite a different thing from standing up for it). My apologies for barging in here and starting this kind of thing. But if you haven't lately given it a thought where you stand on the topic, I take the liberty to ask you to. Best regar

Re: [FFmpeg-devel] [PATCH] libavutil: add an FFT & MDCT implementation

On 07.05.2019, at 01:33, Lynne wrote: > May 6, 2019, 11:41 PM by barsn...@gmx.net: > >> On Mon, May 06, 2019 at 02:23:26 +0200, Lynne wrote: >> >>> This allowed for the exptabs to be computed just once on startup and >>> stored in a global array. >>> >> >> I have no real understanding of this

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

On 07.05.2019, at 12:00, Swaraj Hota wrote: > On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote: >> >> >>> +/*read video index*/ >>> +avio_seek(s->pb, 0xf8, SEEK_SET); >> [...] >>> +avio_skip(s->pb, ifv->vi

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

On 08.05.2019, at 08:01, Carl Eugen Hoyos wrote: > Am Mi., 8. Mai 2019 um 00:52 Uhr schrieb Reimar Döffinger > : >> >> On 07.05.2019, at 12:00, Swaraj Hota wrote: >> >>> On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote: >>

Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

On Wed, May 08, 2019 at 03:06:37PM +0530, Swaraj Hota wrote: > On Wed, May 08, 2019 at 12:52:01AM +0200, Reimar Döffinger wrote: > > First, seeking should be handled specially, by resetting the state. > > You should not make the get_packet less efficient because of that. > > T

Re: [FFmpeg-devel] [PATCH v3] lavf/h264: add support for h264 video from Arecont camera, fixes ticket #5154

memcpy(pkt->data + new_size, data + j + 2, end - j -1); > +new_size += end - j - 1; > +w = 1; > +break; > +} else if (j + 1 > end && i > start && i <= end) { > +memcpy(pkt->

Re: [FFmpeg-devel] [PATCH v9] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720

On 10.05.2019, at 15:10, Shivam Goyal wrote: > > -> Making two avio contexts and one calling the other ( I am not sure if > i implemented it in the right way, but still i reached low level ). Can't you at least figure out the header size, decrypt the header and pass that to the normal header

Re: [FFmpeg-devel] [PATCH v4] lavf/h264: add support for h264 video from Arecont camera, fixes ticket #5154

nning a whole, potentially many, many GB large video file for a 8-character string. A false positive has a REALLY high likelihood. I think this needs to be changed into a more clever approach, that actually knows where these strings can appear and removes them in a more targeted way... Best r

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

On 12.05.2019, at 08:12, Peter Ross wrote: > +static int read_mb_value(GetBitContext *gb) > +{ > +int v = 1; > +int size; > + > +do { > +size = 0; > +if (!get_bits1(gb)) > +break; > +v++; > +do { > +if (!get_bits1(gb)) > +

Re: [FFmpeg-devel] Discussion of all-inclusive full stack builds

On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote: > On May 12, 2019, at 11:54 AM, Nicolas George wrote: > > > > Tim Jones (12019-05-12): > > > >> --disable-all-proprietary/--enable-all-proprietary > > > > As for this one, on the other hand, there will be opposition: we do not > > want enc

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

er to enforce our license. Even if nothing happens, the work companies have to do to show compliance (because their customers require it or to reduce their risk) becomes much harder. Which is why the Linux kernel currently is working on cleaning up their license header mess. Best regards, Reimar D

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

oser. Don't call them if you have other options. Compromise and consesus is always better. Though I admit a way to ask the mood more like a poll sounds interesting to me, maybe even anonymous? Best regards, Reimar Döffinger ___ ffmpeg-devel mailing li

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

On Tue, May 14, 2019 at 10:37:03PM +1000, Peter Ross wrote: > On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote: > > On 12.05.2019, at 08:12, Peter Ross wrote: > > > +static int read_mb_value(GetBitContext *gb) > > > +{ > > >

Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: fix mpeg2 missing headers

On Wed, May 15, 2019 at 09:39:00AM +, Andreas Rheinhardt wrote: > > This problem really needs to be solved. The bitstream generated breaks the > > standard! > > > If I am not mistaken, then the bitstream generated doesn't break the > standard; it is just inconvenient for streaming purposes. (

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On Tue, May 14, 2019 at 08:41:02PM +0200, Lynne wrote: > May 14, 2019, 7:12 PM by one...@gmail.com: > > On 5/14/19, Carl Eugen Hoyos <> ceffm...@gmail.com > > > > wrote: > >>> Am 14.05.2019 um 19:17 schrieb Lynne <>>> d...@lynne.ee > >>> : > >

Re: [FFmpeg-devel] [PATCHv3] VP4 video decoder

On Thu, May 16, 2019 at 09:35:00PM +1000, Peter Ross wrote: > +static int read_mb_value(GetBitContext *gb) > +{ > +int v = 1; > +int size; > +OPEN_READER(re, gb); > + > +do { > +int bit; > +size = 0; > + > +UPDATE_CACHE(re, gb); > +bit = SHOW_UBITS(re

Re: [FFmpeg-devel] [PATCHv3] VP4 video decoder

On Thu, May 16, 2019 at 08:00:55PM +0200, Reimar Döffinger wrote: > v = 127 + SHOW_UBITS(re, gb, 7); Sorry typo, must be 129 instead of 127. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] VP4 video decoder

On Thu, May 16, 2019 at 08:00:55PM +0200, Reimar Döffinger wrote: > On Thu, May 16, 2019 at 09:35:00PM +1000, Peter Ross wrote: > > +static int read_mb_value(GetBitContext *gb) > > +{ > > +int v = 1; > > +int size; > > +OPEN_READER(re, gb); > &g

Re: [FFmpeg-devel] [PATCHv3] VP4 video decoder

On Fri, May 17, 2019 at 08:09:45PM +1000, Peter Ross wrote: > ah, i see what you did there! it works perfectly, just missing > UPDATE_CACHE at the start and in the loop. > > test results on i7 decoding 3 minute long 4k video with vp4. Looks fairly close to noise to me, though for me it seemed a bi

Re: [FFmpeg-devel] [DECISION] Ban Nicolas George from project

wish to keep the feud going, please deal with the consequences yourself and stop dragging the whole project into your self-created messes. Sorry for the bluntness and my excuses if I ruined the chances for a peaceful weekend. Best regards, Reimar Döffinger. On 17.05.2019, at 21:25, Paul B

Re: [FFmpeg-devel] [PATCH] avcodec/v210dec: Fix alignment check for AVX2

On 18.05.2019, at 12:15, Michael Niedermayer wrote: > On Sat, May 18, 2019 at 12:02:55PM +0200, James Darnley wrote: >> On 2019-05-18 09:39, Michael Niedermayer wrote: >>> Fixes: "null pointer dereference" >>> Fixes: >>> 14551/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5088609

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

On 20.05.2019, at 09:23, Mathieu Duponchelle wrote: > Thanks :) > > On 5/19/19 7:00 PM, Devin Heitmueller wrote: >> Hello Paul, >> >> On Fri, May 17, 2019 at 4:44 AM Paul B Mahol wrote: >>> On 5/17/19, Mathieu Duponchelle wrote: There isn't one, as I said the added indentation is becau

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

On Mon, May 20, 2019 at 10:05:49AM +0200, Hendrik Leppkes wrote: > On Mon, May 20, 2019 at 9:44 AM Reimar Döffinger > wrote: > > On 20.05.2019, at 09:23, Mathieu Duponchelle > > wrote: > > > On 5/19/19 7:00 PM, Devin Heitmueller wrote: > > >> Are you

Re: [FFmpeg-devel] [PATCH 1/4] avcodec: add siren audio decoder

On Tue, May 21, 2019 at 04:51:19PM +0200, Moritz Barsnick wrote: > (It only matters on hardware which requires double precision software > emulation, but if explicitly using float, make sure to stick to float.) It's a best practice regardless of emulation or not. Even x86 has for example much bett

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

On Tue, May 21, 2019 at 11:15:03AM -0300, James Almer wrote: > > I have a feeling this loop should have a stop condition like v < > > SOME_LARGE_VALUE, say INT_MAX-255 or yuv_macroblock_count, to reject > > corrupt/malicious files and not cause undefined behavior > > Using get_bits_left(gb) would b

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2 && dc_pred[idx + 1].type == type) { > +dc += dc_pred[idx + 1].dc; > +count++; > +} Maybe do dc_pred += idx at the start and then only dc_pred[-6], dc_pred[6] etc? > +#define loop_stride 12 > +uint8_t loop[12 * loop_stride]; Hm, at 144 bytes, might it

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

On Tue, May 21, 2019 at 09:30:54PM +0200, Reimar Döffinger wrote: > > +#define SHIFT(v, shift) ((v) >> (shift)) > > +#define ABS_SHIFT(v, shift) ((v) > 0 ? SHIFT(v, shift) : -SHIFT(-v, shift)) > > Don't we have something like that already? Seems we don't

Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: combine eob_run_base and eob_run_get_bits tables

On Sat, May 25, 2019 at 12:04:49PM +1000, Peter Ross wrote: > --- > This provides a small readability improvement. > I observe no performance change on x86_64 or arm6. Looks good to me, but probably the maintainer should decide. I guess I'd be very mildly curious to know if the asm code the compil

Re: [FFmpeg-devel] [PATCH v5] avformat/ifv: added support for ifv cctv files

On Sun, May 26, 2019 at 01:46:32AM +0530, Swaraj Hota wrote: > +st = avformat_new_stream(s, NULL); > +if (!st) > +return AVERROR(ENOMEM); > + > +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; > +st->codecpar->codec_id = AV_CODEC_ID_H264; > +st->codecpar->width = ifv->wid

Re: [FFmpeg-devel] [PATCH v5] avformat/ifv: added support for ifv cctv files

On 29.05.2019, at 19:51, Swaraj Hota wrote: >> >> Entirely depends on the purpose. >> If the aim is to have a working demuxer, I think it is acceptable from what >> I looked at. >> I guess the only concern might be that not supporting piped input would be a >> bit of a regression from the fir

Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: repeat mpeg2 missing headers [v2]

On 28.05.2019, at 12:48, Andreas Håkon wrote: > Hi, > > This patch supersedes #13105 (https://patchwork.ffmpeg.org/patch/13105/) > > A new (simpler and more robust) implementationof of the reinsertion of the > missing headers in the MPEG-2 bitstream from the HW QSV encoder. > > The problem i

Re: [FFmpeg-devel] [PATCH 2/4] cbs: Remove useless initializations

On 03.06.2019, at 00:37, Andreas Rheinhardt wrote: > Up until now, a temporary variable was used and initialized every time a > value was read in CBS; if reading turned out to be successfull, this > value was overwritten (without having ever been looked at) with the > value read if reading was s

Re: [FFmpeg-devel] [PATCH 2/4] cbs: Remove useless initializations

On 03.06.2019, at 14:07, Andreas Rheinhardt wrote: > Reimar Döffinger: >> On 03.06.2019, at 00:37, Andreas Rheinhardt >> wrote: >> >>> Up until now, a temporary variable was used and initialized every time a >>> value was read in CBS; if reading turne

Re: [FFmpeg-devel] [PATCH] avcodec/h264_sei: Add experimental acces to truncated SEI data

On 04.06.2019, at 00:21, Antonin Gouzer wrote: > --- > Some codecs editors had miss interpreted the H264 standart and > have coded a wrong size in the SEI data. > size = SEI size + 1. > The SEI data is detected as "truncated" > Ex: > https://drive.google.com/file/d/1cNtLwnfPnyJnYqE7OYhU3SCoLRt

Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: repeat mpeg2 missing headers [v2]

On 04.06.2019, at 15:07, Andreas Håkon wrote: > Hi, > > I need to admit that I'm completely wrong in the end. After spending a lot > of time on a patch to solve the problem (making the MPEG-2 QSV encoder > compatible with broadcasts), I discovered that this solution works: > > $ ffmpeg ... -

Re: [FFmpeg-devel] [PATCH] avcodec/h264_sei: Add experimental acces to truncated SEI data

On 04.06.2019, at 22:33, Antonin Gouzer wrote: > Hello, > Thanks for your response. > It's difficult to say if this is a common issue. > I have hundred of thousands of files like this from an editor. > > Even the off by one Size is not standart compliant and it would be > incorrect to not report

Re: [FFmpeg-devel] [PATCH] vaapi_encode_mjpeg: WA: fix bad component id bug

On 07.06.2019, at 22:28, "U. Artie Eoff" wrote: > When compile time optimizations are enabled and > compiling with GNU GCC 9.x, the pointer assignment > to the inline brace-enclosed list initialized > array does not work and "component" ends up pointing > to an empty array. This is probably a bu

Re: [FFmpeg-devel] [PATCH v4] vaapi_encode_mjpeg: fix bad component id bug

On 07.06.2019, at 23:45, "U. Artie Eoff" wrote: > The compound literals assigned to "components" > only exist within the scope of the if/else > block (thanks Mark Thompson for the better > explanation). > > Thus, after this if/else block, "components" > ends up pointing to an arbitrary/undefined

Re: [FFmpeg-devel] [PATCH 3/3] avformat/vividas: reduce keybits to require half the space

On 07.06.2019, at 23:56, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/vividas.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/libavformat/vividas.c b/libavformat/vividas.c > index 5e303b9c52..72f2093d13 100644 > ---

Re: [FFmpeg-devel] [PATCHv5 2/2] VP4 video decoder

On 08.06.2019, at 03:08, Peter Ross wrote: > --- > comments against v4 patch addressed. thanks. > > +#if CONFIG_VP4_DECODER > +static int vp4_get_mb_count(Vp3DecodeContext *s, GetBitContext *gb) > +{ > +int v = 1; > +int bits; > +while ((bits = show_bits(gb, 9)) == 0x1ff && v < >

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264_sei: Add acces to truncated SEI data

looks good to me if maintainer has no objections... On 08.06.2019, at 15:21, Antonin Gouzer wrote: > --- > Some codecs editors had miss interpreted the H264 standart and > have coded a wrong size in the SEI data. > size = SEI size + 1. > The SEI data is detected as "truncated" > Ex: > https://d

Re: [FFmpeg-devel] [PATCH 3/4] avformat/wsddec: Fix undefined shift

On 08.06.2019, at 11:28, Michael Niedermayer wrote: > Fixes: left shift of 1 by 31 places cannot be represented in type 'int' > Fixes: > 15123/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5738039235575808 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/t

Re: [FFmpeg-devel] [PATCHv5 2/2] VP4 video decoder

On 09.06.2019, at 03:07, Peter Ross wrote: > On Sat, Jun 08, 2019 at 08:49:15AM +0200, Reimar Döffinger wrote: >> >> >> On 08.06.2019, at 03:08, Peter Ross wrote: >> >>> --- >>> comments against v4 patch addressed. thanks. >>> >&g

Re: [FFmpeg-devel] FFmpeg android support

ple. But none of the "reinvented the wheel" build processes are supported. As most objective measure, it seems not tested via fate.ffmpeg.org, which always is a bad sign. Best regards, Reimar Döffinger ___ ffmpeg-devel mailing list ffmpeg-devel@

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_gblur: add x86 SIMD optimizations

On 12.06.2019, at 03:00, Ruiling Song wrote: > ffmpeg | branch: master | Ruiling Song | Wed May 15 > 17:54:10 2019 +0800| [83f9da77684e7ea0d8e9f9712ec716424140043a] | committer: > Ruiling Song > > avfilter/vf_gblur: add x86 SIMD optimizations > > The horizontal pass get ~2x performance wit

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_gblur: add x86 SIMD optimizations

On 12.06.2019, at 11:44, "Jean-Baptiste Kempf" wrote: > On Wed, Jun 12, 2019, at 07:51, Reimar Döffinger wrote: >> Where does this license come from? > > Original file. > Very classical BSD-3 > >> Is that even GPL-compatible? > > Yes, of course.

Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: unknown codec triggers error

On 14.06.2019, at 03:15, Chris Cunningham wrote: > Only "succeed" to read a header if the codec is valid. Otherwise > return AVERROR_INVALIDDATA. That doesn't sound right to me, an unknown codec in (possibly) a single stream is not an error. I understood the discussion more to say the if it's

Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: unknown codec triggers error

On 14.06.2019, at 17:01, James Almer wrote: > On 6/14/2019 11:52 AM, Reimar Döffinger wrote: >> >> >> On 14.06.2019, at 03:15, Chris Cunningham wrote: >> >>> Only "succeed" to read a header if the codec is valid. Otherwise >>> return AVE

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/apedec: Fix multiple integer overflows in filter_3800()

On 16.06.2019, at 12:30, Lynne wrote: > Jun 16, 2019, 10:57 AM by mich...@niedermayer.cc: > >> Fixes: left shift of negative value -4 >> Fixes: signed integer overflow: -15091694 * 167 cannot be represented in >> type 'int' >> Fixes: signed integer overflow: 1898547155 + 453967445 cannot be r

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/apedec: Fix multiple integer overflows in filter_3800()

On 16.06.2019, at 17:12, Paul B Mahol wrote: > On 6/16/19, Reimar Döffinger wrote: >> >> >> On 16.06.2019, at 12:30, Lynne wrote: >> >>> Jun 16, 2019, 10:57 AM by mich...@niedermayer.cc: >>> >>>> Fixes: left shift of negative valu

Re: [FFmpeg-devel] [PATCH 3/7] avcodec/alsdec: Fix integer overflow with buffer number

On 21.06.2019, at 00:47, Michael Niedermayer wrote: > Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type > 'int' > Fixes: > 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600 > > Found-by: continuous fuzzing process > https://github.

Re: [FFmpeg-devel] [PATCH] avcodec/videodsp_template: Fix overflow of addition

On 18.06.2019, at 16:25, Michael Niedermayer wrote: > Fixes: addition of unsigned offset to 0x7f56fc26a9b6 overflowed to > 0x7f56fc26a8be* > Fixes: > clusterfuzz-testcase-minimized-mediasource_MP4_AVC1_pipeline_integration_fuzzer-4917949056679936 > > Reported-by: Matt Wolenetz > Reviewed-by

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/bink: Fix integer overflow in unquantize_dct_coeffs()

On 18.06.2019, at 14:55, Michael Niedermayer wrote: > Fixes: signed integer overflow: -3447 * 2883584 cannot be represented in type > 'int' > Fixes: > 15265/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5088311799971840 > > Found-by: continuous fuzzing process > https://gith

Re: [FFmpeg-devel] [PATCH V1] lavfi/normalize: improve the performance

rite a SIMD version of the normalize function specific to that format and the SIMD instruction set available and call it instead of normalize if applicable. I would expect that you should see at least a 3x speedup if using e.g. SSE2 (which is why I don't consider a 10% speedup worth changing th

Re: [FFmpeg-devel] [PATCH] avcodec: add delayer bitstream filter

On 26.06.2019, at 13:15, Andreas Håkon wrote: > Hi Moritz, > >>> Wouldn't this be better if extended to be a BSF version of setpts? In >>> addition to delays, rescaling as well as other ops could be carried out >>> on TS. >> >> I second that notion, or at least the suggestion of a setpts bsf.

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function

of an actual bug like here I would say dead code if nothing else is a reminder of the bug, though admittedly a very poor one. Either way I suggest to discuss such things more relaxed, a few days more or less hardly matters and there might be useful insights from other people (of

Re: [FFmpeg-devel] [PATCH 4/4] avformat/vividas: Fixes overflow in shift in recover_key()

On 28.06.2019, at 22:53, Michael Niedermayer wrote: > Fixes: left shift of 133 by 24 places cannot be represented in type 'int' > Fixes: > 15365/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5716153105645568 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz

Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line

I don't think we should be using errno when avoidable, and it is avoidable here by disallowing min/max int32 values themselves. Or using strtoll. I'm also rather sceptical about allowing negative values here, does that make sense? Admittedly the type is set to just "int", but maybe it should be u

Re: [FFmpeg-devel] Changes in cofigure script

On 29.06.2019, at 18:26, Dmitry A wrote: > сб, 29 июн. 2019 г. в 21:43, Dmitry A : > >> >> >> сб, 29 июн. 2019 г. в 19:11, Dmitry A : >> >>> >>> >>> сб, 29 июн. 2019 г. в 19:04, Carl Eugen Hoyos : >>> Am Sa., 29. Juni 2019 um 14:23 Uhr schrieb Dmitry A < dmitry.adj...@gmail.com

Re: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument

On 01.07.2019, at 01:12, Carl Eugen Hoyos wrote: > Undefined behaviour was reported in ticket #7981, attached patch tries > to fix it. I suspect it makes more sense to check header_len against 0? And is the NULL pointer really undefined behaviour even if length is 0?

Re: [FFmpeg-devel] [PATCH]lavc/frame_thread_encoder: Do not memcpy() from NULL

On 01.07.2019, at 00:51, Carl Eugen Hoyos wrote: > Hi! > > I believe attached patch fixes undefined behaviour and ticket #7981. Same here, I think it makes more sense to check the "size" instead of the pointer. But I also suspect we might want to think of a way to not need all these explici

Re: [FFmpeg-devel] [PATCH] avutil: add av_memcpy() to avoid undefined behavior with NULL, NULL, 0

On 03.07.2019, at 08:29, Michael Niedermayer wrote: > On Tue, Jul 02, 2019 at 08:42:43PM -0300, James Almer wrote: >> On 7/2/2019 5:56 PM, Michael Niedermayer wrote: >>> Signed-off-by: Michael Niedermayer >>> --- >>> doc/APIchanges | 3 +++ >>> libavutil/mem.h | 13 + >>> l

Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line

On 03.07.2019, at 09:28, Olivier MAIGNIAL wrote: > Hello, thanks for review, > > 1) Can you give some reason about why we shouldn't use errno? I think it is > more clear to accept the full int32 range, even if min/max int32 values are > very unlikely to be used. It is a global variable, with al

Re: [FFmpeg-devel] [PATCH 2/6] avformat/vividas: Fixes overflow in shift in recover_key()

ps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >Suggested-by: Reimar Döffinger >Signed-off-by: Michael Niedermayer >--- > libavformat/vividas.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > >diff --git a/libavformat/vividas.c b/libavformat/v

Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line

This seems reasonable to me, but I have not been involved in any rtp code. The commit message is maybe a bit on the verbose side, but I don't have any strong opinion. On 12.07.2019, at 08:40, Olivier Maignial wrote: > === PROBLEM === > > I was trying to record h264 + aac streams from an RTSP s

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sanm: Check extradata_size before allocations

On 16.07.2019, at 00:50, Michael Niedermayer wrote: > Fixes: Leaks > Fixes: > 15349/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5102530557640704 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/fitsdec: Prevent division by 0 with huge data_max

On 16.07.2019, at 00:50, Michael Niedermayer wrote: > Fixes: division by 0 > Fixes: > 15657/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5738154838982656 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by:

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/fitsdec: Prevent division by 0 with huge data_max

On 16.07.2019, at 20:31, Michael Niedermayer wrote: > On Tue, Jul 16, 2019 at 08:34:14AM +0200, Reimar Döffinger wrote: >> On 16.07.2019, at 00:50, Michael Niedermayer wrote: >> >>> Fixes: division by 0 >>> Fixes: >>> 15657/clusterfuzz-testcas

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/fitsdec: Prevent division by 0 with huge data_max

On 18.07.2019, at 12:54, Michael Niedermayer wrote: > On Thu, Jul 18, 2019 at 08:21:21AM +0200, Reimar Döffinger wrote: >> >> >> On 16.07.2019, at 20:31, Michael Niedermayer wrote: >> >>> On Tue, Jul 16, 2019 at 08:34:14AM +0200, Reimar Döffinger wrote: &

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size

On 21.07.2019, at 00:36, Lynne wrote: > Jul 20, 2019, 11:08 PM by mich...@niedermayer.cc: > >> Fixes: Timeout (22 -> 7 sec) >> Fixes: >> 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >> >> Found-by: continuous fuzzing process >> https://github.com/google/

Re: [FFmpeg-devel] [PATCH 6/6] avcodec/flicvideo: More strictly check chunk size for FLI_COPY

On 19.07.2019, at 21:46, Michael Niedermayer wrote: > On Fri, Jul 19, 2019 at 03:54:19PM +0200, Paul B Mahol wrote: >> On 7/19/19, Michael Niedermayer wrote: >>> On Sat, Jun 22, 2019 at 01:29:36AM +0200, Michael Niedermayer wrote: Fixes: Timeout (40sec -> 13sec) Fixes: 15417/clust

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/aacdec: factorize the adts frame resync code

On 21.07.2019, at 02:51, James Almer wrote: > ffmpeg | branch: master | James Almer | Sat Jul 20 > 10:13:08 2019 -0300| [a38eab8b7501440f872ff1af8a0c5482b7b3e532] | committer: > James Almer > > avformat/aacdec: factorize the adts frame resync code > > Signed-off-by: James Almer > >> http:/

Re: [FFmpeg-devel] [PATCH v4 2/3] lavc/libdavs2.c: fix decoder info level setting

On 22.07.2019, at 06:23, hwrenx wrote: > Mapping log level from av_log_level to davs3_log_level_e: > > [AV_LOG_QUIET, AV_LOG_ERROR] => DAVS2_LOG_ERROR > [AV_LOG_WARNING] => DAVS2_LOG_WARNING > [AV_LOG_INFO] => DAVS2_LOG_INFO > [AV_LOG_VERBOSE, AV_LOG_TRACE] => DA

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp3: Check that theora is theora

On 22.07.2019, at 01:25, Michael Niedermayer wrote: > Fixes: Timeout (2min -> 100ms) > Fixes: > 15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > S

Re: [FFmpeg-devel] [PATCH] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

Why is "block" not aligned? Does the code for other architectures also use unaligned instructions for these? On 23.07.2019, at 09:27, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned. > --- > libavcodec/mips/h264dsp_mmi.c | 48 +-

Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions

On 22.07.2019, at 23:57, Michael Niedermayer wrote: > The dimensions are always 320x200 they are hardcoded in the demuxer. > Hardcode them instead in the decoder. > > Fixes: Timeout (16sec -> 400ms) > Fixes: > 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712

Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions

On 24.07.2019, at 02:39, Kieran Kunhya wrote: >> >> What was the cause of the slow decoding? Does this actually fix it, or >> does it just swipe it "under the carpet"? >> If someone ever found a sample with a different solution, how would they >> know that they shouldn't just remove this again?

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

On 25.07.2019, at 17:35, velocit...@gmail.com wrote: > +// Lookup table lookup > +if (lut) > +value = lut[value]; As this function is in the innermost loop, doing the if here instead of having 2 different implementations is likely not ideal speed-wise. > +// Color scaling >

Re: [FFmpeg-devel] [PATCH v2] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

Is there a mips maintainer? otherwise: On 24.07.2019, at 08:46, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned. > --- > libavcodec/mips/simple_idct_mmi.c | 2 +- > libavutil/mips/mmiutils.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp3: Check that theora is theora

On 24.07.2019, at 14:37, Michael Niedermayer wrote: > On Mon, Jul 22, 2019 at 07:07:57AM +0200, Reimar Döffinger wrote: >> >> >> On 22.07.2019, at 01:25, Michael Niedermayer wrote: >> >>> Fixes: Timeout (2min -> 100ms) >>>

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi.

On 26.07.2019, at 10:25, Shiyou Yin wrote: > 1. Refine setting zero process in function ff_h264_add_pixels4_8_mmi and > ff_h264_idct_add_8_mmi. "refine" is rather unspecific. What was changed? How large is the improvement, any specific numbers? > 2. Remove redundant setting zeor Typo _

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

On 26.07.2019, at 09:34, Nick Renieris wrote: > Στις Παρ, 26 Ιουλ 2019 στις 2:21 π.μ., ο/η Reimar Döffinger > έγραψε: >> >> On 25.07.2019, at 17:35, velocit...@gmail.com wrote: >> >>> +// Lookup table lookup >>> +if (lut) >>> +

Re: [FFmpeg-devel] [PATCH v3] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

On 26.07.2019, at 07:18, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned. Looks good to me if standard DECLARE_ALIGNED should work for stack on MIPS. (on x86 it used to be possible for the stack pointer to only be 8-byte aligned, in which case DECLARE_

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/lcldec: Optimize YUV422 case

On 28.07.2019, at 00:31, Michael Niedermayer wrote: > This merges several byte operations and avoids some shifts inside the loop > > Improves: Timeout (330sec -> 134sec) > Improves: > 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472 > > Found-by: continuou

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/lcldec: Optimize YUV422 case

On 28.07.2019, at 13:56, Michael Niedermayer wrote: > On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote: >> >> >> On 28.07.2019, at 00:31, Michael Niedermayer wrote: >> >>> This merges several byte operations and avoids some shifts inside

Re: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi.

I have no MIPS experience, but for what little it is worth thus: it looks fine to me. On 28.07.2019, at 06:42, Shiyou Yin wrote: > In function ff_h264_add_pixels4_8_mmi, there is no need to reset '%[ftmp0]' > to 0, because it's value has never changed since the start of the asm block. > This pa

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

On 28.07.2019, at 10:40, Nick Renieris wrote: > Actually, I checked a more accurate version of my loop, and GCC > optimizes away the LUT check anyway: > https://godbolt.org/z/G1e1R4 > As you can see it's smart enough to create 2 versions of my functions > (started at L3 with a lookup and L7 witho

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

On 28.07.2019, at 08:55, Paul B Mahol wrote: >> >> Just provide as metadata and leave to e.g. libavfilter. >> > > That does not follow DNG specification. > I really do not have time to comment on other irrelevant stuff you pointed > in your review. If you had just told me that I should back o

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

On 28.07.2019, at 16:45, Paul B Mahol wrote: > On Sun, Jul 28, 2019 at 4:39 PM Reimar Döffinger > wrote: > >> On 28.07.2019, at 08:55, Paul B Mahol wrote: >> >>>> >>>> Just provide as metadata and leave to e.g. libavfilter. >>>> >

Re: [FFmpeg-devel] [PATCH v3] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

On 29.07.2019, at 11:54, "Shiyou Yin" wrote: >> > DECLARE_ALIGNED is defined in ' libavutil/mem.h ' and related to compiler. No > matter mips or x86, > it's definition is ' #define DECLARE_ALIGNED(n,t,v) t __attribute__ > ((aligned (n))) v' when build > with gcc or clang (Specific imple

Re: [FFmpeg-devel] [PATCH] avcodec/arm/sbcenc: save callee preserved vfp registers

Seems sensible to me, though extra points if you or someone has numbers on performance impact. To know whether it would be worthwhile to check if it can be optimized... On 28.07.2019, at 23:46, James Cowgill wrote: > When compiling FFmpeg with GCC-9, some very random segfaults were > observed i

Re: [FFmpeg-devel] [PATCH v5] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

Looks good to me On 31.07.2019, at 03:30, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-byte aligned. > --- > libavcodec/mips/simple_idct_mmi.c | 2 +- > libavutil/mips/mmiutils.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcod

Re: [FFmpeg-devel] [PATCH v5] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.

On Wed, Jul 31, 2019 at 09:30:01AM +0800, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-byte aligned. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsu

  1   2   3   4   5   6   7   8   >