Re: [FFmpeg-devel] [PATCH] avcodec/opus: Add {} over multiline if() body

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 10:34 PM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/opus.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Looks reasonable. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH 1/2] vf_paletteuse: Add error checking to apply_palette

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 9:52 PM, Clément Bœsch wrote: > not exactly sure why you haven't just checked if `out` wasn't NULL, but it > should be fine that way too if you prefer it. > > I guess that's only to provide a finer grain error handling? It would make > sense if ff_get_video_buffer was returning a

Re: [FFmpeg-devel] [PATCH 2/2] vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error

2018-01-02 Thread Derek Buitenhuis
On 1/2/2018 9:53 PM, Clément Bœsch wrote: > That's some weird ownership semantic for the error-path, but Nicolas knows > better this API so I'll trust him on this one. Yeah it was weird for me to, but I looked into its implementation to find out. - Derek

Re: [FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

2018-06-19 Thread Derek Buitenhuis
On 19/06/2018 12:31, Michael Niedermayer wrote: > On Mon, Jun 18, 2018 at 09:19:30PM +0100, Derek Buitenhuis wrote: >> Just one of the many, many ways to store this stuff in the header. >> >> Signed-off-by: Derek Buitenhuis >> --- >> Related reading, but not exact

Re: [FFmpeg-devel] [PATCH] ffv1dec: Ensure that pixel format constraints are respected

2018-07-18 Thread Derek Buitenhuis
On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara wrote: >> this does not follow from what you write below. But more so this is not >> how pixel formats were implemented in FFmpeg. >> Where does this idea come from ? > > I found the following description of this pixel format pretty accurate: >

[FFmpeg-devel] [PATCH 1/2] Use QT format for audio sample descriptors depending on stsd version.

2018-09-06 Thread Derek Buitenhuis
in SoundDescriptionV1/V2 need to be read in order to correctly read additional boxes that contain information required for decoding the stream. Signed-off-by: Derek Buitenhuis --- libavformat/isom.h | 1 + libavformat/mov.c | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git

[FFmpeg-devel] [PATCH 0/2] QT Audio Descriptors in MP4

2018-09-06 Thread Derek Buitenhuis
Sample for FATE is here: http://chromashift.org/mp4-with-mov-in24-ver.mp4 Derek Buitenhuis (1): Add FATE test for QT format audio descriptors in MP4 Justin Ruggles (1): Use QT format for audio sample descriptors depending on stsd version. libavformat/isom.h | 1

[FFmpeg-devel] [PATCH 2/2] Add FATE test for QT format audio descriptors in MP4

2018-09-06 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis --- tests/fate/mov.mak | 3 +++ tests/ref/fate/mov-mp4-with-mov-in24-ver | 3 +++ 2 files changed, 6 insertions(+) create mode 100644 tests/ref/fate/mov-mp4-with-mov-in24-ver diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index

Re: [FFmpeg-devel] [PATCH 2/2] Add FATE test for QT format audio descriptors in MP4

2018-09-07 Thread Derek Buitenhuis
On 06/09/2018 16:35, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > tests/fate/mov.mak | 3 +++ > tests/ref/fate/mov-mp4-with-mov-in24-ver | 3 +++ > 2 files changed, 6 insertions(+) > create mode 100644 tests/ref/fate/mov-mp4

Re: [FFmpeg-devel] [PATCH 2/2] Add FATE test for QT format audio descriptors in MP4

2018-09-09 Thread Derek Buitenhuis
On 07/09/2018 17:09, Michael Niedermayer wrote: > tested on linux x86-32/64, mingw32/64, and qemu arm/mips > all work fine Pushed, thanks. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Use QT format for audio sample descriptors depending on stsd version.

2018-09-06 Thread Derek Buitenhuis
On 06/09/2018 17:13, Carl Eugen Hoyos wrote: > Please mention ticket #7376 (and the Handbrake issue) in the commit > message. Wasn't aware there were tickets already, woops. Added locally. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfdec: demux s436m as eia608 subtitle track

2018-07-04 Thread Derek Buitenhuis
On 04/07/2018 23:05, Baptiste Coudurier wrote: > +if (length < 0) > +return AVERROR_INVALIDDATA; > + > +int array_count = avio_rb32(s->pb); > +int array_elem_size = avio_rb32(s->pb); Mixed declarations aren't allowed in FFmpeg. - Derek

Re: [FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

2018-07-10 Thread Derek Buitenhuis
Hi, Sorry for the slow response; life is hectic. On Tue, Jun 19, 2018 at 8:32 PM, Michael Niedermayer wrote: > The absolute values define the bitstream and have to be used OK, I was unaware. > with a count of 4, mjpeg is coded in MCUs of 4 8x8 blocks in that direction > all buffers must be

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

2018-07-10 Thread Derek Buitenhuis
Hi, Apologies for commenting on this so many months after it was pushed. > ffmpeg | branch: master | Sasi Inguva | > Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010] | > committer: Michael Niedermayer > > lavf/mov.c: Guess video codec delay based on PTS while parsing

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

2018-07-10 Thread Derek Buitenhuis
On Tue, Jul 10, 2018 at 4:46 PM, Carl Eugen Hoyos wrote: > Is it possible to produce such a sample with FFmpeg? The slow down happens with all MP4 and MOV files, but if you just want a long sample that makes it obvious, yes ffmpeg can make it. Probably something like (untested): ffmpeg -f

Re: [FFmpeg-devel] [PATCH 1/4] avformat/mov: remove modulo operations from mov_estimate_video_delay()

2018-07-11 Thread Derek Buitenhuis
On Tue, Jul 10, 2018 at 8:17 PM, Michael Niedermayer wrote: > 0.324 <-0.491 sec > > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) All four of these patches combined bring the penalty down from 2-3x to ~1.19x,

Re: [FFmpeg-devel] [PATCH] libopus: support disabling phase inversion.

2018-01-22 Thread Derek Buitenhuis
On 1/22/2018 3:16 PM, mrdeg...@gmail.com wrote: > From: Menno > > Signed-off-by: Menno > --- > doc/encoders.texi | 5 + > libavcodec/libopusenc.c | 14 ++ > 2 files changed, 19 insertions(+) > > diff --git a/doc/encoders.texi

Re: [FFmpeg-devel] [PATCH] lavf/movenc: keep eac3_priv around; fixes eac3 in DASH

2018-03-08 Thread Derek Buitenhuis
On 3/8/2018 5:10 AM, Rodger Combs wrote: > --- > libavformat/movenc.c | 1 - > 1 file changed, 1 deletion(-) Er, how/why? No info is provided in this commit message. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Derek Buitenhuis
On 3/12/2018 6:58 AM, Valery Kot wrote: > Could somebody please take a look into my patch? Or is it somehow invisible > / badly formatted? > > It allows for inducing key frames at proper moments by e.g. > -force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL > license, which

Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: zero initialize the padding bytes of the exported extradata

2018-03-09 Thread Derek Buitenhuis
On 3/8/2018 4:02 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/extract_extradata_bsf.c | 4 > 1 file changed, 4 insertions(+) Can't most (or all) of these be fixed by using av_mallocz? - Derek ___

Re: [FFmpeg-devel] [PATCH] lavf/movenc: keep eac3_priv around; fixes eac3 in DASH

2018-03-09 Thread Derek Buitenhuis
On 3/9/2018 2:42 AM, Rodger Combs wrote: > Muxing DASH may involve calling mov_write_eac3_tag multiple times on the same > stream. If we destroy eac3_priv after the first call, we don't have it > later, so we end up not writing that data. This is fine for lavf (since > everything in that atom

Re: [FFmpeg-devel] [PATCH] avformat/mov: print the projection type when reporting it as unsupported

2018-03-09 Thread Derek Buitenhuis
On 3/9/2018 2:24 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: zero initialize the padding bytes of the exported extradata

2018-03-09 Thread Derek Buitenhuis
On 3/9/2018 3:22 PM, James Almer wrote: > Yes, but it's slower, and the buffer is guaranteed to be written to with > actual data after being allocated. > > This is a filter that may run once per processed packet, so the less > overhead the better. Not sure I buy the "speed" argument here, but

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-05 Thread Derek Buitenhuis
On 4/3/2018 5:26 PM, wm4 wrote: > Uh no idea. One angle: > > The idea with AVStream side data is that it can be attached as AVPacket > side data. So if an API user is fine with treating all kinds of side > data per AVPacket, it can call av_format_inject_global_side_data() and > ignore AVStream

Re: [FFmpeg-devel] [PATCH] configure: disable direct stripping in OpenBSD

2018-04-09 Thread Derek Buitenhuis
On 4/9/2018 3:32 PM, James Almer wrote: > Maybe they already know and it was fixed at some point, seeing the > OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to > assume equally outdated binutils). OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks,

Re: [FFmpeg-devel] [PATCH] configure: disable direct stripping in OpenBSD

2018-04-09 Thread Derek Buitenhuis
On 4/7/2018 10:58 PM, James Almer wrote: > It appears strip -o creates new files without preserving permissions > from the source binary, resulting in non executable files. This sounds like something the OpenBSD people should be informed of, no? - Derek

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-05 Thread Derek Buitenhuis
On 4/5/2018 7:35 PM, Nicolas George wrote: > A completely braindead API versus using a data structure the way it is > supposed to be used, by adding fields when necessary? You call this a > trade-off? You could have voiced your opinion without being a jackass about it. Cut it out. - Derek

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-05 Thread Derek Buitenhuis
Hi, If you wish to address me, please do so publicly in the future. Nobody benefits from this stuff happening in private. CCing ffmpeg-devel where this belongs. On 4/5/2018 7:44 PM, Nicolas George wrote: > This remark would have more weight if you also made it to people who > actually deserve

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-05 Thread Derek Buitenhuis
On 4/5/2018 8:14 PM, Rostislav Pehlivanov wrote: > I think it makes sense to have it in AVStream rather than as side data. > I don't have an opinion on whether codec switches should be indicated. It > would be nice for them to be a separate segment if that's possible and > reliable, since it would

Re: [FFmpeg-devel] Respect AR and NM overrides for Windows builds.

2018-04-17 Thread Derek Buitenhuis
On 4/17/2018 12:28 AM, Dale Curtis wrote: > Necessary for clang-cl cross compiling builds to work on Linux. Looks fairly reasonable, I think. Are you manually overriding these? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avcodec/allcodecs: add FFMPEG_PREFER_* env vars

2018-04-19 Thread Derek Buitenhuis
On 4/19/2018 11:40 AM, wm4 wrote: > Regarding this patch, personally I don't think using getenv() to > configure what is pretty much API semantics is acceptable. But a new > API function that restricts what codecs are used based on a string > argument might be ok. Then applications could use it to

Re: [FFmpeg-devel] [PATCH] configure: fix clang-cl detection

2018-04-19 Thread Derek Buitenhuis
On 4/18/2018 9:27 AM, Timo Rothenpieler wrote: > On 18.04.2018 10:05, Wang Bin wrote: >>> >>> >>> -elif $_cc -nologo- 2>&1 | grep -q Microsoft; then >>> +elif $_cc -nologo- 2>&1 | grep -q Microsoft || $_cc -v 2>&1 | grep -q >>> clang && $_cc -? > /dev/null 2>&1; then >>>

Re: [FFmpeg-devel] Respect AR and NM overrides for Windows builds.

2018-04-19 Thread Derek Buitenhuis
On 4/17/2018 11:09 PM, Dale Curtis wrote: > Yes, to cross-compile on Linux you need to use llvm-ar and llvm-nm. This is > pretty chromium specific, but you can get the gist of what's necessary from > this Chromium change: > >

Re: [FFmpeg-devel] [PATCH] mov: Properly abide by the track's media duration

2018-04-19 Thread Derek Buitenhuis
On 4/18/2018 11:08 PM, Jan Ekström wrote: > Just an off-hand comment that given that audio frames in AAC tend to > have 1024 samples usually (or in more general, "1028 samples is quite > unlikely for AAC"), I'd say 1024 is correct for a duration of an AAC > frame. Looking at the hash, the actual

[FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

2018-04-23 Thread Derek Buitenhuis
on files with edit lists that are longer than the media duration. The FATE changes are expected, and output is more correct (the AAC frame is not 1028 samples). Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavformat/mov.c | 6 +++--- tests/re

[FFmpeg-devel] [PATCH] mov: Properly abide by the track's media duration

2018-04-17 Thread Derek Buitenhuis
on files with edit lists that are longer than the media duration. Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- Personally I'd have removed the incorrect setting of the stream duration in the stts reading code... --- libavformat/mov.c | 6 +++--- 1 file changed, 3 inse

Re: [FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

2018-04-25 Thread Derek Buitenhuis
On 4/23/2018 4:46 PM, Derek Buitenhuis wrote: > The track's media duration from the mdhd atom takes precedence > over both the stts and elst atom for calculating and setting > the track's total duraion. > > Technically, we shouldn't be using the stts atom at all for > calculatin

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-27 Thread Derek Buitenhuis
On 3/27/2018 11:46 PM, Alexander Strasser wrote: >> + * of the stream's rate, for example: 1.2 means play back this entry at >> 1.2x speed. >> + * If this value is 0, then the first sample (located at 'start') must >> be displayed >> + * for the duration of the entry. >> + */ >>

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-01 Thread Derek Buitenhuis
On 4/1/2018 12:44 AM, Michael Niedermayer wrote: >> Not sure I follow what this has to do with timelines? There is no format that >> exists that store timeline data interleaved, as far as I know - it is a >> purely theoretical scenario. > > that surprises me. But if this case never occurs (or

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:47 PM, Nicolas George wrote: > Derek Buitenhuis (2018-03-28): >> Do you have an actual suggest though? > > Maybe not using a badly designed API that requires everything to be > stored in a serialized uint8_t array. Isn't this the same as saying "don't use

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:12 PM, Michael Niedermayer wrote: > This is problematic as its non extensible. (unless iam missing something) > Consider that a field is added to AVTimelineEntry, the entries array would > have a larger element size and that would require all user apps to be rebuild Do you have an

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:49 PM, wm4 wrote: > You just need to change * to **. Then the size of the struct doesn't > matter anymore for array access and can be excluded from the ABI. To be thorough: Does anyone else have opinions on this approach? - Derek ___

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-02 Thread Derek Buitenhuis
On 4/1/2018 10:38 PM, Michael Niedermayer wrote: >> I agree that the APIs are annoyingly different, but that they should remain >> separate APIs. The suggestion of aligned (same names, args, etc.) seems the >> most reasonable to me - consistency. >> >> I don't really think they can share some

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-04-03 Thread Derek Buitenhuis
On 4/3/2018 4:15 AM, wm4 wrote: > So I think all what you've been writing can be reduced to: should this > really be side data, or would it be better to just make it a new > AVStream field. I don't really have an opinion on this one way or another. Do others? - Derek

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-30 Thread Derek Buitenhuis
On 3/30/2018 11:20 AM, Michael Niedermayer wrote: > I mean derek (who wrote the patch) has not even had time to reply to my > comment. > I am very interrested in what his oppinion is, does he agree? does he > think its impossible or too hard or irrelevant ? Or does he see something > i didnt

Re: [FFmpeg-devel] [PATCH 0/8] HLS/DASH live streaming stability updates

2018-03-31 Thread Derek Buitenhuis
Hi, On 3/30/2018 6:07 AM, vdi...@akamai.com wrote: > This patch series contains minor bug fixes and error handling functionalities > for uninterrupted long duration HLS/DASH live streaming use cases. During live > streaming, it was observed that ingest network fluctuations are common which > were

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-31 Thread Derek Buitenhuis
On 3/29/2018 7:55 PM, Michael Niedermayer wrote: >> That is not what i meant >> >> what i meant is to align the APIs that handle timespan related information >> and not have totally different interfaces for each. >> For example they might share the same struct in some cases to deliver data >> They

Re: [FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

2018-03-31 Thread Derek Buitenhuis
On 3/30/2018 1:44 PM, Steve Lhomme wrote: > +if (BCRYPT_SUCCESS(ret)) { > +NTSTATUS ret = BCryptGenRandom(algo_handle, , sizeof(seed), 0); > +BCryptCloseAlgorithmProvider(algo_handle, 0); > +if (BCRYPT_SUCCESS(ret)) > return seed; > } How does this

[FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-27 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> --- libavcodec/avcodec.h | 8 +++ libavutil/timeline.h | 160 +++ 2 files changed, 168 insertions(+) create mode 100644 libavutil/timeline.h diff --git a/libavcodec/avcod

[FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

2018-03-27 Thread Derek Buitenhuis
nd would make adding regression tests problematic. So, everyone, rev up your diesel powered bikesheds and drive them full steam into this thread's back yard, over my daffodils. Derek Buitenhuis (1): avcodec/avutil: Add timeline side data libavcodec/avcodec.h | 8 +++ libavu

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

2018-03-27 Thread Derek Buitenhuis
On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote: > I think we should drop the internal crap if the tools and the API support > it. Would also solve a lot of issues like ffmpeg.c not trimming the start > frame (so people complain all the time about longer files). I personally agree, but I thought

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-29 Thread Derek Buitenhuis
On 3/29/2018 2:06 AM, Michael Niedermayer wrote: > Its how AVStreams are living in AVFormatContext too > so to me it seems thats the obvious and consistent way to go. > i do not know if there are any unforseen issues with that ... Sounds like the best way to go about it then. Thanks, - Derek

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

2018-03-29 Thread Derek Buitenhuis
On 3/29/2018 1:06 PM, wm4 wrote: > I think mov files at least use a > filename/URL for external references, which actually could be handled > in generic files. The dref box is for the whole track, FWIW, and not for edit list entries. - Derek ___

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-29 Thread Derek Buitenhuis
On 3/29/2018 2:13 AM, Michael Niedermayer wrote: > Well, no unless we want a single unified API that represents information > about timespans. > We can use completely unrelated systems to handle the virtual timeline, > the codec and related changes, chapters, ... Personal opinion time: From

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

2018-03-29 Thread Derek Buitenhuis
On 3/27/2018 8:44 PM, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > --- > libavcodec/avcodec.h | 8 +++ > libavutil/timeline.h | 160 > +++ > 2 files changed, 168 insertions(

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

2018-03-16 Thread Derek Buitenhuis
On 3/15/2018 5:54 PM, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavfilter/Makefile | 1 + > libavfilter/af_hrtfm.c | 477 > +++ > libavfilter/allfilters.c | 1 + > 3 files changed, 479 insertions(+) >

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: write track title metadata for mov files

2018-03-20 Thread Derek Buitenhuis
On 3/20/2018 8:31 AM, Carl Eugen Hoyos wrote: > More precisely: I asked you if it is well-defined (assuming it is not since > this is the only reason I can think of it was not used so far). He linked to the definition in the QTFF spec directly above, so it is certainly defined, at least. On

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec: propagate SAR to h/w frames

2018-03-20 Thread Derek Buitenhuis
On 3/19/2018 11:33 PM, Aman Gupta wrote: > From: Aman Gupta > > Allows consumers who are converting hardware buffers > to OpenGL textures to render the frames at the intended > display resolution. > --- > libavcodec/mediacodecdec_common.c | 13 + >

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: write track title metadata for mov files

2018-03-22 Thread Derek Buitenhuis
On 3/21/2018 9:30 PM, Courtland Idstrom wrote: > Please let me know if this is sufficient. I can also upload these movies > somewhere, I didn't think it would be appropriate to attach them to this > email. I'm satisfied with with it, thanks for checking! Patch LGTM. - Derek

Re: [FFmpeg-devel] OpenCV filter should be built as C++, and C builds fail since OpenCV 3.4.1

2018-03-19 Thread Derek Buitenhuis
On 3/19/2018 8:57 PM, Nicolas George wrote: > Derek Buitenhuis (2018-03-19): >> libutvideo was handled 100% incorrectly. We hardcoded libstdc++ as a >> dependency, but the proper solution was to link with CXX instead of CC. > > This is not a *proper* solution, since it does

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: write track title metadata for mov files

2018-03-19 Thread Derek Buitenhuis
On 3/19/2018 9:11 PM, Courtland Idstrom wrote: > Track title (atom 'name') is a well defined user data atom for mov files. > Existing code (for mp4) only writes title metadata if present. > > Relevant reference docs: > > >

Re: [FFmpeg-devel] OpenCV filter should be built as C++, and C builds fail since OpenCV 3.4.1

2018-03-19 Thread Derek Buitenhuis
On 3/19/2018 5:01 PM, Jan Ekström wrote: > On Mon, Mar 19, 2018 at 6:28 PM, wm4 wrote: >> On Mon, 19 Mar 2018 09:35:22 -0400 >> Jeff Cook wrote: >> >>> Hello, >>> >>> Please see the bug report at https://github.com/opencv/opencv/issues/10963

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: write track title metadata for mov files

2018-03-21 Thread Derek Buitenhuis
On 3/21/2018 2:30 AM, Courtland Idstrom wrote: > What can I do to facilitate this? Would it help to create a couple of > samples from QuickTime Pro, and perhaps show the metadata atoms as > displayed by ffprobe -v trace? Any way of verifying will do, even a hex editor. - Derek

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec: propagate SAR to h/w frames

2018-03-20 Thread Derek Buitenhuis
On 3/20/2018 7:06 PM, Aman Gupta wrote: > I guess I could leave just the if statement, to override the sar when > display-width/height is available (which is only on newer Android OS > versions). Seems reasonable to me. - Derek ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

2018-04-26 Thread Derek Buitenhuis
On 4/26/2018 12:29 PM, wm4 wrote: > You never follow that though. You participate in endless flames, until > the other side is tired and gives up. This. The one who has endless energy to argue their point wins on ffmpeg-devel, not the one with the correct or even most-supported point. Observed

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

2018-04-26 Thread Derek Buitenhuis
On 4/26/2018 3:06 PM, Tobias Rapp wrote: > +if (ost->top_field_first == 0) { > +enc_ctx->field_order = AV_FIELD_BB; > +} else if (ost->top_field_first == 1) { > +enc_ctx->field_order = AV_FIELD_TT; > +} This doesn't look correct;

Re: [FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

2018-04-26 Thread Derek Buitenhuis
On 4/25/2018 4:07 PM, Derek Buitenhuis wrote: > Ping. > > If there are no further comments, I plan to push tomorrow evening. It's been over 10 days, and the sole comment was addressed. Pushed. - Derek ___ ffmpeg-devel mailing list ffm

[FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-08 Thread Derek Buitenhuis
-by: Derek Buitenhuis --- libavcodec/h264_slice.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index 58e1aaf02f..d09cee4b13 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -358,6 +358,7 @@ int

Re: [FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-08 Thread Derek Buitenhuis
On 08/10/2018 19:23, Carl Eugen Hoyos wrote: > I cannot reproduce ticket #7475 (it says "framerate num 30 den 1" > no matter how many threads I use, tested with up to 8), and - more > related to this patch - the sample from ticket #7475 reaches neither > line 358 nor line 400 in h264_slice.c here

Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer

2018-10-11 Thread Derek Buitenhuis
On 11/10/2018 22:21, Jan Ekström wrote: > I'd probably disable creation of such files unless you enable a less > standards-compliant strictness mode. Is there even an IVF spec, though? If not, there's not really such a thing as "standards-compliant". - Derek

Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer

2018-10-11 Thread Derek Buitenhuis
On 11/10/2018 23:39, Alex Sukhanov wrote: > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF Yeah, not really a spec. I have no strong objections, I guess. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] libavcodec/libx265.c: support for the x265 loglevel configured with ffmpeg loglevel option

2018-10-16 Thread Derek Buitenhuis
On 15/10/2018 06:08, lance.lmw...@gmail.com wrote: > From: Limin Wang > > --- > libavcodec/libx265.c | 18 ++ > 1 file changed, 18 insertions(+) A few questions: * Do we do anything similar elsewhere in FFmpeg? * Does x265 have a log callback we can register? I'd prefer that

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-23 Thread Derek Buitenhuis
Hi, On 21/10/2018 15:07, Henrik Gramner wrote: > Fixed in x264-sandbox. All uses of plain strtok() will be removed from > x264 in the next push. > > I though all of the strtok() uses in x264 had already been converted > to strtok_r() but apparently that wasn't the case. Sorry about that. I'd

Re: [FFmpeg-devel] [PATCH 1/5] lavc/qsvenc: add forced_idr opiton

2018-10-29 Thread Derek Buitenhuis
On 29/10/2018 20:51, Rogozhkin, Dmitry V wrote: > Should not the option be named 'force_idr' as well? It makes better > sense to me in that way... That would be inconsistent with the rest of the options for various encoders in FFmpeg, all named forced_idr. - Derek

Re: [FFmpeg-devel] [PATCH 1/2] libavutil: Undeprecate the AVFrame reordered_opaque field

2018-10-29 Thread Derek Buitenhuis
On 29/10/2018 20:10, Martin Storsjö wrote: > Sorry, I think you've misunderstood this patch altogether. > > It's not about reviving this field or not, it's all in full use > already. It was never deprecated with any active plan to remove it, the > only steps were a few doxygen comments, never any

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

2018-10-29 Thread Derek Buitenhuis
On 25/10/2018 13:58, Martin Storsjö wrote: > +x4->nb_reordered_opaque = x264_encoder_maximum_delayed_frames(x4->enc) + > 1; Is it possible this changes when the encoder is reconfigured (e.g. to interlaced)? - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 1/2] libavutil: Undeprecate the AVFrame reordered_opaque field

2018-10-29 Thread Derek Buitenhuis
On 25/10/2018 13:58, Martin Storsjö wrote: > This was marked as deprecated (but only in the doxygen, not with an > actual deprecation attribute) in 81c623fae05 in 2011, but was > undeprecated in ad1ee5fa7. > --- > libavutil/frame.h | 1 - > libavutil/version.h | 2 +- > 2 files changed, 1

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

2018-10-31 Thread Derek Buitenhuis
On 30/10/2018 19:49, Martin Storsjö wrote: > Hmm, that might make sense, but with a little twist. The max reordered > frames for H.264 is known, but onto that you also get more delay due to > frame threads and other details that this function within x264 knows > about. So that would make it [H264

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

2018-11-01 Thread Derek Buitenhuis
On 31/10/2018 21:41, Martin Storsjö wrote: > Even though we do allow reconfiguration, it doesn't look like we support > changing any parameters which would actually affect the delay, only RC > method and targets (CRF, bitrate, etc). So given that, the current patch > probably should be safe - what

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

2018-10-30 Thread Derek Buitenhuis
On 29/10/2018 21:06, Martin Storsjö wrote: > As I guess there can be old frames in flight, the only safe option is to > enlarge, not to shrink it. But in case a realloc moves the array, the old > pointers end up pretty useless. Just always allocate the max (which is known for H.264), and adjust

Re: [FFmpeg-devel] [PATCH 1/2] libavutil: Undeprecate the AVFrame reordered_opaque field

2018-10-29 Thread Derek Buitenhuis
On 29/10/2018 14:10, Martin Storsjö wrote: >> I don't understand why this is being used in favour of a proper >> pointer field? An integer field is just ascting to be misused. >> Even the doxygen is really sketchy on it. > > It's essentially meant to be used as union { ptr; int64_t } assuming you

Re: [FFmpeg-devel] [PATCH v2] avcodec: add an AV1 parser

2018-10-03 Thread Derek Buitenhuis
On 03/10/2018 13:53, Derek Buitenhuis wrote: > Won't this break horribly on e.g. 4:4:0? Woops, there's no such thing in AV1. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec: add an AV1 parser

2018-10-03 Thread Derek Buitenhuis
On 03/10/2018 14:26, James Almer wrote: >> Shouldn't this be set at the bottom of this block (since parsing can fail)? > > If extradata parsing fails and we bail out without setting this first, > no packet will ever be parsed since this runs first thing every time. > > A better API would allow

Re: [FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-09 Thread Derek Buitenhuis
On 08/10/2018 16:36, Derek Buitenhuis wrote: > If we don't copy this value first, it is seen as 0 by h264_slice_header_init, > due to zero-allocation of the new context, triggering an old hack that > multiplied the denominator by 2 for files produced by old x264 versions, but > only

Re: [FFmpeg-devel] [PATCH v2] avcodec: add an AV1 parser

2018-10-03 Thread Derek Buitenhuis
Hi, Apologies if you've covered any of these comments before. On 03/10/2018 02:44, James Almer wrote: > Simple parser to set keyframes, frame type, structure, width, height, and > pixel > format, plus stream profile and level. > > Signed-off-by: James Almer > --- > Missing Changelog entry and

Re: [FFmpeg-devel] [PATCH v2] avcodec: add an AV1 parser

2018-10-03 Thread Derek Buitenhuis
On 03/10/2018 14:43, James Almer wrote: > That's in Metadata OBUs and/or in container defined structures. It's > meant to be propagated internally as stream/packet/frame side data, > which the parser API can't handle. > > The demuxer and/or the decoder are the ones that need to handle that. OK.

Re: [FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-08 Thread Derek Buitenhuis
On 08/10/2018 19:52, Carl Eugen Hoyos wrote: > Please also mention ticket #7083 in the commit message. > > Sorry for my other mail, thank you for testing again! Added locally, thanks. Wasn't aware of that bug; could have saved me 30 mins of printf debugging. - Derek

Re: [FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows

2018-08-31 Thread Derek Buitenhuis
On 31/08/2018 16:18, James Almer wrote: > The doxy in the public header: > https://aomedia.googlesource.com/aom/+/master/aom/aomcx.h#312 > > One shouldn't have to look at source code when there's documentation for > public API, but since the latter is apparently wrong... If it's like this, at

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

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

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

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

Re: [FFmpeg-devel] [PATCH 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 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 V3 2/3] avcodec/libx264: add support for ROI-based encoding

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

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

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

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

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

Re: [FFmpeg-devel] [PATCH 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 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 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 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] 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

<    3   4   5   6   7   8   9   >