Re: [FFmpeg-devel] [PATCH] all: use M_SQRT1_2, M_SQRT2, M_PI

On 11/19/2015 4:12 PM, Ganesh Ajjanagadde wrote: > Confirmed just now bit-exactness via the hex print: > 0x1.921fb54442d18p+1 > 0x1.921fb54442d18p+1. Paul uses FreeBSD, if I recall. This is probably with glibc. - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote: > I will come on Monday if that's okay... could setup a time that works > for you. I'm based in Melbourne Australia Most of the channel is usually around during daytime GMT/CET hours. - Derek ___

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

On 1/8/2016 6:55 AM, Jean-Yves Avenard wrote: > We originally had configured AVCodecContext::thread_count to 0, which > on the machines running the tests would end up creating 8 threads per > decoder. > On windows 32 bits, that would amount in thousand of threads being > created for that

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

On 5/19/2016 2:18 PM, Derek Buitenhuis wrote: > On 5/19/2016 2:12 PM, Michael Niedermayer wrote: >> if derek still wants to leave in 2 weeks then so be it, its his choice >> but i really hope things can be resolved in a way that everyone >> stays and works together and is hap

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add Cineform HD Decoder

On 1/10/2016 1:54 AM, James Almer wrote: >> +AVCodec ff_cfhd_decoder = { >> +.name = "cfhd", >> +.long_name = NULL_IF_CONFIG_SMALL("Cineform HD"), >> +.type = AVMEDIA_TYPE_VIDEO, >> +.id = AV_CODEC_ID_CFHD, >> +.priv_data_size =

[FFmpeg-devel] [PATCH] mov: Add an option to toggle dref opening

This feature is mostly only used by NLE software, and is both of dubious value being enabled by default, and a possible security risk. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/isom.h| 1 + libavformat/mov.c | 22 +- libav

[FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

working library that I can find is a package for an obscure distro, in German only, with a bunch of patches applied. * The ASM in libutvideo doesn't even work on x86_64. * More, I'm sure others can fill in. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- Cha

Re: [FFmpeg-devel] [PATCH] options_table: update maximum bitrate limit

On 2/10/2016 3:26 PM, Rostislav Pehlivanov wrote: > The type of the option has been changed but the limit was apparently > forgotten. > Some video codes can handle bitrates of over ~2.2 Gbps (like VC-2). > > Signed-off-by: Rostislav Pehlivanov > --- >

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

On 2/10/2016 4:33 PM, Paul B Mahol wrote: > I'm fine by this, but it would be nice to have SIMD and 10 bit support > in decoder. I agree with the latter. I'd argue, however, we don't actually support 10-bit via the wrapper anyway, since you can't even build the library. ;) - Derek

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support

On 2/12/2016 5:03 PM, Paul B Mahol wrote: > make install (as root)and then build FFmpeg with >> libutvideo support. Last time I tried this, it failed to configure, due to duplicated symbol 'main'. - Derek ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH][RFC/UNTESTED] swscale/slice: Actually use the buffers' strides

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- I don't know how this could ever have worked, but I also am having a hard time testing the sliced path in swscale... has it even ever been run? I have CC'd the original author of this code in the hopes that he can confirm o

Re: [FFmpeg-devel] [PATCH] avcodec/libutvideoenc: fix compiler warnings, initialize the correct type

On 2/4/2016 2:12 AM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/libutvideoenc.cpp |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) My personal preference, and that shared by every single person I've asked, is that

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: Move prediction_method to codec private options

On 2/4/2016 1:56 AM, Michael Niedermayer wrote: > this breaks existing command line usage like -pred 3 > and "3" previously lacked a named constant so people had to use a > litteral 3 i think Already smacked around Vittorio for that. It can be fixed, or it can be left/documented. I have no

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 2/4/2016 4:14 PM, Rostislav Pehlivanov wrote: > Do we even support MSVC versions old enough to error on compilation for > mixed declarations and variables? Will c99conv actually error if it > encounters such code? Yes, and, I believe, yes. > As for the other compilers, I bet they're

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 2/4/2016 3:48 PM, Rostislav Pehlivanov wrote: > The only reason this existed was to allow for old compilers to not > complain/compile the project's code. As far as I know, we no longer have > support for such compilers hence this flag has become useless and we > have no reason to continue

Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: Assert that the header we assembled is valid

On 2/5/2016 2:19 PM, Michael Niedermayer wrote: > because the code builds the header a few lines above, i assume > the header we just build is correct Perhaps you could elaborate what CID1351343 is then, in the commit messages. - Derek ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/libx26x: Allow to fail if wrong options were passed

On 1/28/2016 10:35 AM, Carl Eugen Hoyos wrote: > Attached patch tries to address ticket #4947. > (only tested with libx264) I don't think STRICT_STD_COMPLIANCE is the correct thing to use here. It looks like explode mode is better suited. - Derek ___

Re: [FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

On 1/27/2016 9:13 PM, Derek Buitenhuis wrote: > It could accidentally divide by zero if num was zero. > > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > --- > libavcodec/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) [21:58] <@nevcai

Re: [FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

On 1/27/2016 10:03 PM, Michael Niedermayer wrote: > is the avctx->ticks_per_frame != 0 check needed? I have no idea, actually. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: speed up scan data copy

On 1/27/2016 8:35 PM, Hendrik Leppkes wrote: > This broke building on msvc, ssize_t is not available there. Shouldn't it be ptrdiff_t anyway? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/util: Fix timebase overflow check

It could accidentally divide by zero if num was zero. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index 13ee243..491d8ea 100644 --- a/liba

Re: [FFmpeg-devel] [PATCH 2/2] libx265: Enable 12-bit encoding

On 1/27/2016 12:10 AM, Stephen Hutchinson wrote: > The configure detection is bumped to X265_BUILD >= 68, > since API version 68 corresponds with the x265 1.8 > release tarball. Was 68 the first API version it was in, or merely the tarball? I would prefer the actual version it was introduced in

Re: [FFmpeg-devel] [PATCH 1/2] libx265: Remove experimental flag when encoding 4:2:2 and 4:4:4

On 1/27/2016 12:10 AM, Stephen Hutchinson wrote: > 4:2:2 and 4:4:4 support in the HEVC standard was approved in > October 2014 as part of HEVC Version 2 and published in > January 2015: > > http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296 > http://www.itu.int/rec/T-REC-H.265-201410-S >

Re: [FFmpeg-devel] [PATCH] avutil: Rename FF_CEIL_COMPAT to AV_CEIL_COMPAT

On 1/27/2016 3:21 PM, Derek Buitenhuis wrote: > Libav, for some reason, merged this as a public API function. This will > aid in future merges. > > A define is left for backwards compat, just in case some person > used it, since it is in a public header. > > Signed-off

Re: [FFmpeg-devel] [PATCH 3/3 v2] ffprobe: Deprecate stream timecode field and add frame side data timecode field

On 1/31/2016 2:36 PM, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > --- > ffprobe.c | 6 ++ > 1 file changed, 6 insertions(+) OK'd by Clement on IRC. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data

On 1/31/2016 8:02 PM, Michael Niedermayer wrote: > whats the first frame of a gop ? > for example there may be B frames prior to an I frame in display > order In this case, it's the first frame output after decoding the GOP header. Do you think there is a better way to word it? - Derek

Re: [FFmpeg-devel] [PATCH 2/3 v2] mpeg12dec: Export GOP timecodes as side data

On 1/31/2016 9:18 PM, Michael Niedermayer wrote: > is it intended to set this also when ret < 0 No, you're right, it should not be. Amended locally. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

On 1/28/2016 12:03 PM, Paul B Mahol wrote: > Hi, > > 2nd version attached. [...] > +{"weights_file", NULL, OFFSET(weights_file), AV_OPT_TYPE_STRING, > {.str="nnedi3_weights.bin"}, 0, 0, FLAGS }, I still argue this makes the filter useless for 99% of users. - The weights are literally

Re: [FFmpeg-devel] [PATCH 2/2] libx265: Enable 12-bit encoding

On 1/27/2016 6:18 PM, Stephen Hutchinson wrote: > I have no strong opinion on it. 68 seems like the compromise > position since it'd allow both 1.8 and 1.9 to be used, whereas > any of the earlier ones still fall within 1.8's dev cycle and would > only be used by those users making builds against

Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9

On 1/30/2016 7:15 PM, Timothy Gu wrote: > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1. Perhaps this should be restricted to x86? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling

On 1/30/2016 12:11 PM, Michael Niedermayer wrote: > patch should be ok Related to this: [16:25] <@Daemon404> that src/ dir really screws up my grepping if i dont distclean first [16:25] <@Daemon404> i get all my results twice [16:25] <@Daemon404> unless i build out of tree [16:25] <@Daemon404>

Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data

On 1/31/2016 1:13 PM, Derek Buitenhuis wrote: > -if (dec_ctx->timecode_frame_start >= 0) { > -char tcbuf[AV_TIMECODE_STR_SIZE]; > -av_timecode_make_mpeg_tc_string(tcbuf, > dec_ctx->timecode_frame_start); > -pri

[FFmpeg-devel] [PATCH 3/3 v2] ffprobe: Deprecate stream timecode field and add frame side data timecode field

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- ffprobe.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ffprobe.c b/ffprobe.c index c352b44..f7b51ad 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -1917,6 +1917,10 @@ static void show_frame(WriterContext *w, AVFrame

[FFmpeg-devel] [PATCH 0/3 v2] Move MPEG1/2 GOP timecodes to side data

Derek Buitenhuis (3): avutil: Add GOP timecode frame side data mpeg12dec: Export GOP timecodes as side data ffprobe: Deprecate stream timecode field and add frame side data timecode field doc/APIchanges | 3 +++ ffprobe.c | 6 ++ libavcodec/mpeg12dec.c | 22

Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data

On 1/31/2016 8:29 PM, Michael Niedermayer wrote: > the spec says this: > "The time code refers to the first picture after the group of > pictures header that has a temporal_reference of zero." I *think* this is the frame I attach the side data too, but I'm not a master of the mpeg*.c files.

[FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data

The codec context field was rightly deprecated, and the data may change per-frame. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- ffprobe.c | 8 libavcodec/mpeg12dec.c | 19 --- 2 files changed, 16 insertions(+), 11 deletions(-)

[FFmpeg-devel] [PATCH 0/2] Move MPEG1/2 GOP timecodes to side data

CC'd Clement, side he added it originally.; Derek Buitenhuis (2): avutil: Add GOP timecode frame side data mpeg12dec: Export GOP timecodes as side data ffprobe.c | 8 libavcodec/mpeg12dec.c | 19 --- libavutil/frame.h | 7 ++- libavutil

[FFmpeg-devel] [PATCH 1/2] avutil: Add GOP timecode frame side data

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavutil/frame.h | 7 ++- libavutil/version.h | 4 ++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/libavutil/frame.h b/libavutil/frame.h index 406c8b5..e07922d 100644 --- a/libavutil/frame.h

[FFmpeg-devel] [PATCH 0/2] img2dec improvements

Justin Ruggles (2): img2dec: Support Progressive JPEG in jpeg_probe img2dec: Add mime_type to image formats libavformat/img2dec.c | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) -- 2.7.0 ___ ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

From: Justin Ruggles <justin.rugg...@gmail.com> Improves probing, especially over http when there is a Content-Type header Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/img2dec.c | 31 --- 1 file changed, 16 insertions(+),

Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: clear priv in av_init_packet()

On 2/24/2016 3:10 PM, Michael Niedermayer wrote: > This should fix leaving uninitialized pointers in priv which can confuse > user applications. > See: https://github.com/golang/go/issues/14426 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/avpacket.c |1 +

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote: > If this cannot be fixed differently, we should either increase > the score for the existing 32bit probe functions or reduce the > score for mime types before this gets applied. Several probe > functions (outside of img2dec.c) return MAX for 32

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote: Replies are mine. >> In terms of how the score for a MIME type match compares with >> those of the individual content matching probe functions, I'd >> say it makes sense. The stronger probing functions have a >> score which reflects their

Re: [FFmpeg-devel] [PATCH 3/3] lavu/rational: add more info regarding floor(x+0.5) usage

On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote: > -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64 > +// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64, > +// see Ticket2713 for affected gcc/glibc versions I've never seen this comment

Re: [FFmpeg-devel] [PATCH 1/3] lavu/attributes: introduce av_likely, av_unlikely

On 2/25/2016 7:27 AM, wm4 wrote: > They also make code ugly as fuck, and are more cargo-cult than anything > else. They might possibly be ok in some very critical parts of the > code, but otherwise not at all. +1 to this. I will absolutely *not* ACK any patch sets that start littering

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

On 2/26/2016 2:44 PM, Carl Eugen Hoyos wrote: > Derek Buitenhuis gmail.com> writes: > >> On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote: > You misunderstand: > Most "imageauto" demuxers return a score of 51. In all cases > when 51 is returned, the detectio

Re: [FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

On 2/26/2016 5:14 PM, Derek Buitenhuis wrote: > +ret = avio_read(pb, _buf[0], 4); > +if (ret <= 0) > +return CHECK_SEEK_FAILED; This check should be <, not <=. Changed locally. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

On 2/26/2016 3:05 PM, Carl Eugen Hoyos wrote: > Or in other words: Except for jpeg, there is no > probe function that returns 0 although the decoder > can decode the image. I'll take your word for it on this part. > So please provide your failing jpeg cases to > improve the probing. > I will

Re: [FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

On 2/26/2016 5:30 PM, wm4 wrote: > The ffio_ensure_seekback() checks are probably unnecessary. I can remove them if you prefer. Should I? > Seems a bit verbose, but ok. I added the av_log stuff because otherwise you just get "Invalid Argument" from the ffmpeg cli, with no other explanation. -

[FFmpeg-devel] [PATCH] lavf/mp3: Properly check return values of seeks and reads while reading the header

Fixes large amounts of seeking past EOF, which could be extremely slow over a network. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- Example of the problem: ffmpeg -f mp3 -i http://chromashift.org/skyfire.ico This problem was exacerbated even more by th

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

On 2/26/2016 5:42 PM, Reimar Döffinger wrote: > +av_assert0(frame->format == avctx->pix_fmt); Is this valid? Mid-stream colorspace changes are fairly common. - erek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 2/2] img2dec: Add mime_type to image formats

On 2/24/2016 3:19 PM, Carl Eugen Hoyos wrote: > (Do you have an example where the probing fails?) > > The idea of these additional demuxers is that they probe > the content instead of relying on the file suffix. > File suffix provides a score of _EXTENSION (50), so if probing > is possible and

Re: [FFmpeg-devel] [PATCH] mov: Add an option to toggle dref opening

On 1/16/2016 7:58 PM, Marton Balint wrote: > CLI users still going to need an option for it. What do you mean? Demuxer options are all exposed in the CLI. -enable_drefs 1 works fine. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

On 1/23/2016 8:50 PM, Andreas Cadhalpun wrote: > On 23.01.2016 13:33, Michael Niedermayer wrote: >> On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote: >>> --- >>> common.mak | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> confirmed to fix checkheaders > >

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

On 1/23/2016 9:29 PM, Derek Buitenhuis wrote: > cygwin does not have -W. > > Furthermore, makign *environment* deductions based on your *target compiler* > is incredibly broken. > > People also build via msvc with a cygwin shell, and on native linux with > wine+cl.exe. &

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote: > Do you have a better idea? Yes, don't do it, full stop. Is the feature here (bit exact builds out of tree) worth all the hacks? In my gut: no. Several others have expressed the same opinion. - Derek ___

Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

On 1/24/2016 11:52 AM, Andreas Cadhalpun wrote: > On 24.01.2016 03:19, Hendrik Leppkes wrote: >> Lets just revert this entire batch and re-try after proper testing and >> review. > > You're very quick to suggest a revert here, but very reluctant about reverting > commit 31741ae. That's not

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.

On 1/24/2016 4:33 PM, Kieran Kunhya wrote: > The internal encoder is superior to libvo-aacenc. > --- Just about everything is. +1 to removing. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/imgutils: remove special case for aligning the palette

> ffmpeg | branch: master | Michael Niedermayer | > Sun Feb 14 15:22:47 2016 +0100| [0eb4092c1bf4d74c3b9a65fb0dbe4f90d3a316d0] | > committer: Michael Niedermayer [...] > +if (align < 4) { > +av_log(NULL, AV_LOG_ERROR, "Formats with a palette require a > minimum alignment

Re: [FFmpeg-devel] Subtitles for GSoC

On 3/10/2016 8:11 PM, wm4 wrote: > Since XML libraries are apparently always broken, bloated, insecure, and > hard to use, that has always been a point of contention. Although it > would be the right approach. You're not going to find an XML library that is not annoying/hard to use because XML is

Re: [FFmpeg-devel] [PATCH 1/3] Revert "hls: Add and use a memebr of AVIOInternal rather than abuse opaque"

On 3/14/2016 11:22 AM, Hendrik Leppkes wrote: > This reverts commit 9f9ed79d4cb40e5d9093899f8a79086ff23da844. > > The hlsopts member was never set anywhere and always NULL, furthermore > the HLS demuxer needs to retrieve the proper options from the underlying > http protocol (cookies, user-agent,

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote: > If one wants good Gaussian samples, then yes, I need a 64 bit rng. > Please also note that I can use av_lfg_get, it does not result in > slowdown, since speed benefits here come from the ziggurat algo. > Concretely, it is 82 cycles vs 81 cycles;

Re: [FFmpeg-devel] [PATCH] Use lowercase includes and library names for schannel check

On 3/15/2016 7:26 PM, Reimar Döffinger wrote: > I see this: > libavformat/tls_schannel.c:#include > libavformat/tls_securetransport.c:#include > > Are those different headers? Consider that one is for OS X native TLS, and one is for Windows native TLS. - Derek

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

On 3/15/2016 2:56 PM, Ronald S. Bultje wrote: > Might be related to aacenc? But yes, we need to know overall speed gain of > some useful end user feature before/after this. [13:42] <@atomnuker> well, AAC just requires the random numbers to be only somewhat random [13:43] <@atomnuker> you could

Re: [FFmpeg-devel] Speed difference when using ffmpeg + x264 with stdin, or libx264

On 3/15/2016 8:58 AM, Pradeep Ramachandran wrote: > Has anyone else experienced such a stark difference in speed? Are the > limits of linux pipes the reason for this difference, or is there something > else going on here? First: This is probably the wrong list. Second: Did you expect piping a

Re: [FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote: > Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits), > and has a much smaller cache (128 bits). Thus, the timings should also > be more stable. > > This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and >

Re: [FFmpeg-devel] [PATCH v3] libxvid: Create extradata in init using a dummy frame

On 4/5/2016 10:26 AM, Michael Niedermayer wrote: > should be ok fro ffmpegs side, i dont know the xvid API As far as I can tell from its documentation, this is the official / correct way. The API is kinda bad in that sense. Thanks, - Derek ___

Re: [FFmpeg-devel] ffservers future

On 4/8/2016 2:30 PM, Michael Niedermayer wrote: > There are a few known bugs in it like code depending on > sizeof(AVStream) and general a little too much direct access into APIs > these things will cause ffserver to frequently break if APIs change > even slightly. To calrify, the problem is

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

On 4/10/2016 8:09 PM, Rostislav Pehlivanov wrote: > There are far less users of libfaac than libstagefright, so I think just a > changelog entry would be enough. I very much doubt this. Very few people could even *compile* the libstagefright code. - Derek

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

On 4/10/2016 5:42 PM, Michael Niedermayer wrote: > this is not possible currently libfaac is twice as fast than the > native encoder. Twice as fast and produces crap output. Personally I think 31x realtime (which is the example you've given) is pretty quick. I somewhat double people are using

Re: [FFmpeg-devel] [PATCH] avcodec: Add bits_per_raw_sample to AVCodecParameters

On 4/11/2016 12:32 AM, Michael Niedermayer wrote: > The bits_per_raw_sample represents the number of bits of precission per > sample. > > The field is added at the logical place, not at the end as the code was just > recently added > > This fixes the regression about loosing the audio sample

Re: [FFmpeg-devel] [PATCH 8/8] lavf/movenc+dashenc: add automatic bitstream filtering

On 4/8/2016 1:38 AM, Rodger Combs wrote: > @@ -617,6 +617,7 @@ static int dash_write_header(AVFormatContext *s) > ctx->opaque = s->opaque; > ctx->io_close = s->io_close; > ctx->io_open= s->io_open; > +av_dict_set(, "fflags",

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

On 3/3/2016 7:50 PM, Michael Niedermayer wrote: > The io_open/close callbacks afterwards seem direct access IIUC > so its not possible to remove or add any fields prior > > though maybe they have been added so recently that its ok to move > them above all "no direct access" fields > or maybe iam

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

On 3/4/2016 3:02 PM, James Almer wrote: > ry to non break ABI just yet, leave it as last resort. We did it not even > half a year ago, and we'd have to push every single scheduled deprecation. > If this can be resolved moving only the new entries then that's preferable. OK I did it this way. -

[FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- This matches API with Libav, in a forthcoming merge, using our exisiting infastructure code. CC'd Michael, since he wrote the whitelisting code. This has been tested with FATE. --- Changelog | 1

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote: > + printf("AVColorTransferCharacteristic=%d calling func(%f) > expected=%f\n", > + i, test_data[j], result); Comparing floats exactly probably isn't a great idea, since floating point implementations differ

Re: [FFmpeg-devel] [PATCH] Opus in MP4 support

On 3/7/2016 4:29 AM, Matthew Gregan wrote: > Hi, > > The attached patch adds basic mux/demux support for the Opus audio codec in > MP4. > > Mozilla have expressed interest in shipping support for this in: > https://groups.google.com/d/msg/mozilla.dev.platform/mdDZ-nBr_jM/MaLi2BDOAgAJ Hi, Why

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote: [...] > --- > libavcodec/aacenc_utils.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Cool. Looks like an obvious/easy win, assuming it's identical. - Derek ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

Modifying global header extradata in encode_frame is an API violation and only happens to work currently because mov writes its header at the end of the file. Heavily based off of a patch from 2012. Original-by: Nicolas George <geo...@nsup.org> Signed-off-by: Derek Buitenhuis <dere

Re: [FFmpeg-devel] libavcodec/exr : Add support for UINT32

On 4/3/2016 5:58 PM, Martin Vignali wrote: > Hello, > > In attach a patch to add support for UINT32 pixel type. [...] > +#ifndef UINT32_MAX > +#define UINT32_MAX (0x) > +#endif Don't do this, we already require this header be present and working. - Derek

Re: [FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

On 4/3/2016 10:22 AM, Michael Niedermayer wrote: > please add somethng like this to the commit message > LGTM Applied with updated commit message. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] Add coded_width/height to AVCodecParameters

On 4/3/2016 9:49 PM, Clément Bœsch wrote: > dv needed something like this too, but the code was pretty much hacky in > the first place and it was changed not to use them, which avoided such > commit. Where is this needed exactly? Look at the new rv20 test from 1 April. - Derek

Re: [FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

On 4/3/2016 9:54 PM, Derek Buitenhuis wrote: > Modifying global header extradata in encode_frame is an API violation > and only happens to work currently because mov writes its header > at the end of the file. > > Heavily based off of a patch from 2012. > > Original-by

[FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

Modifying global header extradata in encode_frame is an API violation and only happens to work currently because mov writes its header at the end of the file. Heavily based off of a patch from 2012. Original-by: Nicolas George <geo...@nsup.org> Signed-off-by: Derek Buitenhuis <dere

[FFmpeg-devel] [PATCH] psxstr: Remove some commented out code

Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/psxstr.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c index b57981a..38186f7 100644 --- a/libavformat/psxstr.c +++ b/libavformat/ps

[FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

From: Hendrik Leppkes --- libavformat/internal.h | 7 +++ libavformat/utils.c| 23 +++ 2 files changed, 30 insertions(+) diff --git a/libavformat/internal.h b/libavformat/internal.h index 7defce8..cd390dd 100644 --- a/libavformat/internal.h +++

Re: [FFmpeg-devel] [PATCH] Introduce ff_bprint_to_codecpar_extradata for avformat

On 3/31/2016 9:49 PM, Derek Buitenhuis wrote: > From: Hendrik Leppkes <h.lepp...@gmail.com> > > --- > libavformat/internal.h | 7 +++ > libavformat/utils.c| 23 +++ > 2 files changed, 30 inser

[FFmpeg-devel] [PATCH v2] wavdec: Only set the codec ID in read_header

WAV is not a NOHEADER format, and thus should not be changing stream codec IDs and probing in read_packet. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/wavdec.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff

[FFmpeg-devel] [PATCH v3] libxvid: Create extradata in init using a dummy frame

Modifying global header extradata in encode_frame is an API violation and only happens to work currently because mov writes its header at the end of the file. Heavily based off of a patch from 2012. Original-by: Nicolas George <geo...@nsup.org> Signed-off-by: Derek Buitenhuis <dere

[FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

It's not even used anymore, and the checks are no longer functionally important. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/hevc.c| 2 +- libavcodec/hevc.h| 4 ++-- libavcodec/hevc_parse.c | 11 +-- libavcodec/hevc_parser.c | 2

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

On 4/24/2016 3:39 PM, Nicolas George wrote: > Clearing the extradata is not related to the codecpar change, > and it breaks if auto_convert is disabled. > > Fix trac ticket #5461. > > Signed-off-by: Nicolas George > --- > libavformat/concatdec.c | 5 - > 1 file changed, 5

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

On 4/24/2016 4:26 PM, Nicolas George wrote: > That may be true, but the fix is incorrect, and should not have sneaked > during a completely unrelated merge. For the sake of tracking changes, I > want to revert this, and then look for a more correct fix. The fix was deemed OK at the time by a few

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

On 4/25/2016 2:14 PM, Ivan Uskov wrote: > The attached patch does fixes the issue of frames duplication when > elementary h.264 stream decodes by qsvdec. Could you perhaps elaborate in the commit message, and a code comment, on why it must be 2? Where does that value come from, etc. -

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

On 4/25/2016 7:50 PM, John Warburton wrote: > Is it possible that this patch, particularly to libavcodec/hevc.h, is > causing my compilation error today, cross-compiling using mingw-w64 > and gcc-5.3.0 from GNU/Linux to Windows 64-bit? Yes it looks as if qsv also called that, and I missed it. I

Re: [FFmpeg-devel] [PATCH] qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp

On 4/25/2016 11:37 PM, Michael Niedermayer wrote: > i cant easily test this but does this need a > av_freep of skipped_bytes_pos somewhere ? > > otherwise it should be ok I cannot easily test it either, unfortunately. I'm not sure why it would, though (without having looked very hard). - Derek

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

On 4/25/2016 4:49 PM, Carl Eugen Hoyos wrote: > Can you confirm that this is Windows-only, ie that lto > works fine on Linux with the Intel compiler? > (It did work fine when I last tested.) FWIW, I've had issues with LTO on Linux, with clang and gold, due to (lack of) DCE. - Derek

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

On 4/27/2016 2:17 PM, Ricardo Constantino wrote: > configure already checks for minimum major version 6 which is the > first one using MIT license and fails if lower. Gotcha. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

On 4/27/2016 9:50 AM, Ivan Uskov wrote: > Since it was added to commit message too, it is not the issue, right? > I left the "bug fixed" because it was really the bug which force decoder to > produce doubled frames output. I don't think it is worth debating, really. I'll push this patch today

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

On 4/23/2016 6:00 PM, Timo Rothenpieler wrote: > As the nvEncodeApi.h header is now MIT licensed, this can be dropped. > The loaded CUDA and NVENC libraries are part of the nvidia driver, and > thus count as system libraries. > --- > configure | 1 - > 1 file changed, 1 deletion(-) I presume

Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.

On 4/26/2016 5:41 PM, Ronald S. Bultje wrote: > --- > doc/filters.texi | 13 > libavfilter/colorspacedsp.c | 9 +++ > libavfilter/colorspacedsp.h | 6 ++ > libavfilter/colorspacedsp_template.c | 128 > +++ >

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