On 01/04/2020 13:30, Michael Bradshaw wrote:
> On Wed, Apr 1, 2020 at 6:04 AM Derek Buitenhuis
> wrote:
> Do you know where it's properly defined for QTFF? The only references that
> I've been able to find about this atom are in the two links in my original
> email, which
On 01/04/2020 14:28, Matthieu Bouron wrote:
> Would "Skips the DHT segment in jpeg_probe() to avoid looking for JPEG
> markers in the DHT segment data" be OK ?
Sounds OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
On 02/04/2020 10:41, Paul B Mahol wrote:
> I do not care, bool is evil and should never be used.
Why? 'We don't like it' isn't a technical reason.
Also, FFmpeg already uses plenty of C99 features and thus
requires a C99 compiler. What is so inherently evil about a boolean
type that it must not be
On 02/04/2020 14:24, Paul B Mahol wrote:
> No code in FFmpeg use it.
> And it was disallowed before and should be now.
'Because we've always done it that way' is not a valid technical argument.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 02/04/2020 17:47, Moritz Barsnick wrote:
> I though this was the practical argument?:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html
> http://trac.ffmpeg.org/ticket/8591
It isn't really clear to me what the actual problem is from the
description - how is bool fundementally
On 02/04/2020 19:23, Thierry Foucu wrote:
> And here is the patch they used to fix it:
> https://mails.dpdk.org/archives/dev/2018-August/110485.html
Interesting... Altivec isn't standards compliant? TIL.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-deve
On 02/04/2020 19:52, Nicolas George wrote:
> What I read is Apple isn't standards compliant. I knew that.
>
> This fix seems harmless enough.
The fix in the linked archive? I agree.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
On 12/08/2019 20:37, Michael Niedermayer wrote:
> probably ok, but same oppinion as you, cleaner solution preferred if anyone
> has a cleaner one
We're seeing some more of these 'hoov' files show up as more apps misuse iOS
APIs, so since this seems to have been OK'd but never pushed, I'll go ahead
On 10/04/2020 00:09, James Almer wrote:
> EAGAIN is returned when input is provided but can't be consumed. The filtering
> process is unaffected in this case, and the function will be able to consume
> new input after retrieving filtered packets with av_bsf_receive_packet().
>
> Remove the line ab
On 16/04/2020 17:11, Paul B Mahol wrote:
> Will apply.
Please wait more than an hour and a half. Timezones exist.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
On 16/04/2020 16:28, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/formats.c | 41 +
> libavfilter/formats.h | 10 ++
> 2 files changed, 51 insertions(+)
(Just a commnt out of curiosity.)
Are there more filters than vf_
On 16/04/2020 17:10, Paul B Mahol wrote:
> Will apply.
Your behavior here is still unacceptable. You have dismissed or ignore
both comments without any given reason.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
On 16/04/2020 17:48, Nicolas George wrote:
> Derek Buitenhuis (12020-04-16):
>> (Just a commnt out of curiosity.)
>>
>> Are there more filters than vf_crop that this is intended to be used on?
>
> I said:
>
>>> I need it in new code.
It wasn't clear
On 16/04/2020 18:23, Paul B Mahol wrote:
> Why we should listen to your requests? Who you are to demand changes to code?
>
> I'm not bypassing comments, I just state that they are immature, like yours.
That the FFmpeg community continues to put up with this sort
of behavior, more often than no re
On 17/04/2020 14:38, Nicolas George wrote:
> James Almer (12020-04-17):
>> The movenc test does not produce any files. It creates bogus packets
>> that are dumped into the AVOutputFormat output using a custom
>> AVIOContext on each stream that just calculates an md5 hash of the data.
It has an opt
On 05/02/2021 01:54, Andreas Rheinhardt wrote:
> Could AV_CODEC_FLAG_GLOBAL_HEADER be used for this?
It could, but I don't think it should.
The global header is still written, just not with a global palette.
I think it would be, at best, confusing, especially in terms of
intent.
- Derek
___
Derek Buitenhuis (2):
avcodec/gifenc: Add global_palette option
avcodec/gifenc: Only write frame palette entries that actually used
libavcodec/gif.c | 93 ++--
1 file changed, 82 insertions(+), 11 deletions(-)
--
2.30.0
resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis
---
The global palette, if used, is no longer ever shrunk in v2 of this
patch. This is because just because any given frame doesn't refe
resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis
---
Changes since v2:
* shrunk_buf allocated only once per encoder instance.
* Does not use temporary pointers during remapping
default behavior.
Signed-off-by: Derek Buitenhuis
---
Does this need a avcodec minor/patch version bump?
---
libavcodec/gif.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index de41992851..8c07ee2769 100644
--- a
Signed-off-by: Derek Buitenhuis
---
doc/encoders.texi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8fb573c416..d7d81e070d 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1268,6 +1268,44
On 20/02/2021 19:58, Marton Balint wrote:
> docs update is missing for the new option.
Seems there was no documentation at all, so I've add all of it,
and sent patch 3/2.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
On 21/02/2021 21:02, Moritz Barsnick wrote:
>> +@item global_palette @var{integer}
>> +Writes a palette to the global GIF header whee feasible.
> ^ where
>
Fixed and pushed the set (+1 other small fix).
- Derek
___
This reverts commit 4093220029a4d77f272c491e9299680480a08c00.
Signed-off-by: Derek Buitenhuis
---
I have CC'd Michael here, as he is the original author here and the "soltuion"
is nor clear.
To explain this RFC:
We (Vimeo) have started seeing an uptick in broken MP4 files (wh
On 08/03/2021 15:55, Derek Buitenhuis wrote:
> So the options are:
> * Revert 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa and detect them as I
> was already.
Copy-paste fail. This should say 4093220029a4d77f272c491e9299680480a08c00.
On 08/03/2021 17:29, Michael Niedermayer wrote:
> I would try to detect the specific abberant muxer based on the input.
> Then have custom code in the demuxer which is based on reverse engnenering
> the
> issue to do a best effort to recover as much as is possible. And also print a
> big
> war
a network, which is the main place these self-initializing
fragmented ISOBMFF files would be used. This is the same behavior that
was addressed in 2ff3c466eca66bb8eb32bb41a4ce70fe285e3ea0 for live-style
fragmented files.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 7 ++-
1 f
I have no idea how nobody, including myself, noticed this.
Signed-off-by: Derek Buitenhuis
---
libavcodec/gif.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 938bc0e928..cafd93e190 100644
--- a/libavcodec/gif.c
+++ b/libavcodec
On 10/03/2021 17:24, Michael Niedermayer wrote:
> what does the muxer exactly do ?
I provided an explanation of what is happening during the broken muxing
in my original email, as well as a sample, and a text dump of the boxes.
Please see those.
Can you please actually fully read my emails and s
On 11/03/2021 08:36, Michael Niedermayer wrote:
> These are not enough to unambigously reverse engeneer the bug in the muxer
> is it true for every output of the muxer, does it always happen at the
> same position ?
> is the runaway delta always 8 ?
> does it always coincide with the 2nd entry of s
On 11/03/2021 15:38, Michael Niedermayer wrote:
> You explicitly asked me to comment, and also stated that all options you
> listed suck:
Indeed, I was hoping for an insight that wasn't even worse hacks, though, or
an opinion on which was Least Bad. Maybe I should have been more clear in
my inten
On 10/03/2021 15:20, Derek Buitenhuis wrote:
> I have no idea how nobody, including myself, noticed this.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/gif.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Will push in a few hours if nobody
On 12/03/2021 11:20, Martin Storsjö wrote:
> LGTM, I guess the only question that remains is whether "dash" in the
> compatible brands can imply the same too. (Our own muxer never sets "dash"
> as the major brand, only as a compatible brand, and that only if we only
> produce one global sidx.)
a network, which is the main place these self-initializing
fragmented ISOBMFF files would be used. This is the same behavior that
was addressed in 2ff3c466eca66bb8eb32bb41a4ce70fe285e3ea0 for live-style
fragmented files.
Signed-off-by: Derek Buitenhuis
---
Updated the commit message too, to refle
On 12/03/2021 18:49, Martin Storsjö wrote:
> LGTM. The commit message still talks only about the major brand though.
It seems at some point we added an unrelated test, seek-extra-mp4, which uses
an invalid dash-branded (under compatible brands) file generated by
libavformat...
We mux correctly no
Use the tfra timestamp if it is available and sidx timestamp is not.
Fixes reading the entire file after seeking in a live-style DASH FMP4
with an MFRA.
This specifically fixes when use_mfra_for is set.
Signed-off-by: Derek Buitenhuis
---
I could also put it behind an additional use_mfra_for
On 15/03/2021 17:04, Derek Buitenhuis wrote:
> Use the tfra timestamp if it is available and sidx timestamp is not.
>
> Fixes reading the entire file after seeking in a live-style DASH FMP4
> with an MFRA.
>
> This specifically fixes when use_mfra_for is set.
>
> Signed-
still correctly read.
When 0b78016b2d7c36b32d07669c0c86bc4b4225ec98 introduced a
minimum size check, this exposed the bug, and broke probing
any files with extended atom sizes, such as entirely valid
large files that start whith mdat atoms.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual proobing function.
Signed-off-by: Derek Buitenhuis
---
I will reply to this email with the sample file in question.
---
tests/fate/mov.mak
On 18/03/2021 16:14, Derek Buitenhuis wrote:
> The test sample has to have no file extension, otherwise probing
> happens to work, based off file extension alone, and we want to
> test the actual proobing function.
>
> Signed-off-by: Derek Buitenhuis
> ---
> I will reply t
On 18/03/2021 16:14, Derek Buitenhuis wrote:
> The test sample has to have no file extension, otherwise probing
> happens to work, based off file extension alone, and we want to
> test the actual proobing function.
>
> Signed-off-by: Derek Buitenhuis
> ---
> I will reply t
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual probing function.
Signed-off-by: Derek Buitenhuis
---
New features:
* Less typos
* A backslash
---
tests/fate/mov.mak | 3
On 18/03/2021 16:50, Andreas Rheinhardt wrote:
>> The test sample has to have no file extension, otherwise probing
>> happens to work, based off file extension alone, and we want to
>> test the actual proobing function.
> ^
[...]
>> fate-mov-mp4-with-mov-i
On 18/03/2021 16:14, Derek Buitenhuis wrote:
> When extended atom size support was added to probing in
> fec4a2d232d7ebf6d1084fb568d4d84844f25abc, the buffer
> size check was backwards, but probing continued to work
> because there was no minimum size check yet, so despite
> size b
This is important, for example, for connection timed out events,
when used over a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis
---
Sent the wrong version the first time, woops.
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat
This is important, for example, for connection timed out events,
when used ovr a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index
On 25/03/2021 16:35, Derek Buitenhuis wrote:
> This is important, for example, for connection timed out events,
> when used over a network, returning AVERROR(ETIMEDOUT).
>
> Signed-off-by: Derek Buitenhuis
> ---
Will push tonight if there are no objec
On 22/03/2021 22:25, zsugabubus wrote:
> Compared to previous implementation, this rework tries to:
>
> - Improve code quality,
> - Provide better error handling (also: reduce numerous (potential)
> memory leaks),
> - Broader coverage of the standard:
> * multiple periods,
> * multiple base
On 28/03/2021 21:05, Carl Eugen Hoyos wrote:
> The patch clearly mentions that it is a "rework".
> If the maintainer likes it, it would be nice if it can be simplified but
> this may not be possible.
Of course it's /possible/. People have been splitting rewrites/refactors into
these since forever;
On 02/04/2021 12:05, Gyan Doshi wrote:
> Rao
+1
- Drek
___
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 "unsub
On 03/04/2021 11:19, Jean-Baptiste Kempf wrote:
> This is Internet and social networks in 2021.
> It WILL be taken in the wrong way.
>
> Do NOT use anything political or related to the news in naming. Never Ever.
> It might be badly taken, but mostly you have NO idea how it will be taken in
> th
On 07/04/2021 10:02, Hendrik Leppkes wrote:
> As noted in the other thread, VLAs are not supported by all compilers
> we support, so they cannot be used.
We should not be using them as a matter of good practice, as well, IMO.
- Derek
___
ffmpeg-devel ma
On 07/04/2021 16:29, Derek Buitenhuis wrote:
> I must have missed the discussion as it may be hidden in another thread.
>
> A reference would be good for those of us who have not read every single email
> that has ever come into this mailing list.
>
> My 2 cents anyway is t
On 07/04/2021 16:14, Nicolas George wrote:
> Please follow the discussion. Good practice decourages VLA on the stack,
> not pointers to VLA.
I must have missed the discussion as it may be hidden in another thread.
A reference would be good for those of us who have not read every single email
that
On 07/04/2021 16:34, Nicolas George wrote:
> To answer that, I need to know why you think VLAs are considered bad
> practice.
>
> VLAs on the stack are a bad practice because (1) they may use too much
> of the stack in an unexpected way, and (2) they require extra registers
> that ruin optimizatio
On 07/04/2021 19:56, Vittorio Giovara wrote:
> My OS doesn't even let me install Quicktime 7, if anybody could chime in
> and help solve this point it would be much appreciated.
> Alternatively, I'd say we shouldn't cargo cult broken files generated by 11
> year old software, but if people disagree
On 16/04/2021 23:10, Brad Smith wrote:
> ping.
I found this in my spam folder, so it's possible others using GMail had the
same issue.
- Derek
>
> On 4/3/2021 2:49 PM, Brad Smith wrote:
>> avutil/cpu: Use HW_NCPUONLINE to detect # of online CPUs with OpenBSD
>>
>> Signed-off-by: Brad Smith
>>
Rav1e currently uses the time base given to it only for ratecontrol... where
the inverse is taken and used as a framerate. So, do what we do in other
wrappers
and use the framerate if we can.
Signed-off-by: Derek Buitenhuis
---
Notably, this leaves pkt->pts still broken (it was broken bef
nd use the framerate if we can.
>>
>> Signed-off-by: Derek Buitenhuis
>> ---
>> Notably, this leaves pkt->pts still broken (it was broken before, too), but
>> after discussion with James and Lynne, we decided to fix this in the rav1e
>> API
>> and bump th
Not requiring this leads to unexpected result, since Rav1e's current
two pass API has no way to fail in such a case.
Signed-off-by: Derek Buitenhuis
---
libavcodec/librav1e.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index b0ff6
On 02/05/2020 15:46, James Almer wrote:
>> +if ((avctx->flags & AV_CODEC_FLAG_PASS1 || avctx->flags &
>> AV_CODEC_FLAG_PASS2) && !avctx->bit_rate) {
>
> Maybe avctx->flags & (AV_CODEC_FLAG_PASS1 | AV_CODEC_FLAG_PASS2) instead.
I thought about it, but I think the way I already have it is a li
On 11/05/2020 17:35, Thierry Foucu wrote:
> If you have a file with multiple Metadata Keys, the second time you parse
> the keys, you will re-alloc c->meta_keys without freeing the old one.
> This change will avoid parsing all the consecutive Metadata keys.
> ---
> libavformat/mov.c | 3 ++-
> 1 f
On 14/05/2020 18:19, Thierry Foucu wrote:
> Looking at
> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html
> The spec does not seem to say 1 or more. But because the `keys` atom is a
> list of indexes used by the `ilst` and the spec for `keys` said:
> I
On 14/05/2020 19:15, Zachariah Brown wrote:
> The h264_nvenc and hevc_nvenc encoders aren't respecting the framerate in the
> codec context. Instead it was using the timebase which in our use-case was
> 1/1000 so the encoder was behaving as if we wanted 1000fps. This resulted in
> poor encoding
Prevents wrap-around to negative values while calculating the duration string.
Before:
Duration: -411422:-59:-42.17, start: 0.00, bitrate: 0 kb/s
After:
Duration: 781623:28:34.17, start: 0.00, bitrate: 0 kb/s
Signed-off-by: Derek Buitenhuis
---
Minimal example file: http
On 16/05/2020 16:23, Carl Eugen Hoyos wrote:
> I believe there is a ticket that this patch fixes, but I won't find it
> quickly;-(
A quick search of trac didn't reveal anything to me, either...
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 17/05/2020 12:16, Paul B Mahol wrote:
> LGTM
Pushed, thanks.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org wi
On 19/05/2020 19:55, James Almer wrote:
> +if (pic->reordered_opaque) {
If this is meant to be PTS, won't this break on PTS==0?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
On 19/05/2020 22:03, James Almer wrote:
> When pic->reordered_opaque is 0 (default value) x265pic.userData will
> remain NULL. This in turn means x265pic_out.userData will also be NULL
> and avctx->reordered_opaque will be set to 0, so it's functionally the
> expected behavior.
> This is done to av
On 22/05/2020 10:43, Lynne wrote:
> The Xiph foundation never standardized either Daala nor its mapping in Ogg,
> and all files that were created are undecodable without knowledge of the
> git hash.
>
> Patch attached.
+1 from me.
Why was a parser for a WIP/Research codebase/codec pushed anyway
On 28/05/2020 17:26, Lynne wrote:
> That's a bug. We should absolutely not have flags to enable bugs.
> The fast flag should be removed from h264 until that bug is fixed,
> or deprecated altogether.
100% agree. Hard NAK from me for the very little my opinion here
is still worth.
This is basically
On 13/06/2020 17:11, Kieran Kunhya wrote:
> It can therefore be shown that the difference is statistically
> insignificant.
I really think the onus of proving FAST is useful should be on
the people who claim it is useful - something I haven't seen
any evidence for.
- Derek
___
On 14/06/2020 18:40, Paul B Mahol wrote:
> The part I was arguing is applying patches which are clearly blocked.
> Some developers apparently can do that. And other developers opinions
> means nothing much.
It would be good if this community could learn that even being right does
not make it OK fo
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the
FileTypeBox
Signed-off-by: Derek Buitenhuis
---
libavformat/movenc.c | 6 +-
1 file changed, 5 insertions(+
On 17/06/2020 14:45, Derek Buitenhuis wrote:
> This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
> General Requirements & Brands states:
>
> * It SHALL have the av01 brand among the compatible brands array of the
> FileTypeBox
>
> Signed
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the
FileTypeBox
Signed-off-by: Derek Buitenhuis
---
Changes
* Updated FATE refs.
* Moved the write to be for
On 17/06/2020 15:45, James Almer wrote:
> nit: I'd prefer it after the cmfc and iso6 compat brands instead.
Done.
> LGTM either way.
Pushed, thanks.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffm
On 12/06/2020 00:35, Yongle Lin wrote:
> Allow extended language codes using ISO designation for text tracks in mov
> format when strictness is set to experimental
> ---
> This patch includes a support for mov format to extend language codes using
> ISO designation for text
> tracks(https://deve
-off-by: Derek Buitenhuis
---
libavformat/movenc.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b8e45760ee..2927865cb4 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
On 23/06/2020 16:59, Andreas Rheinhardt wrote:
> Use avio_get_dyn_buf in combination with ffio_free_dyn_buf. That way you
> save an allocation+copy in case the data fits into the dynamic buffer's
> write buffer (it has a size of 1024 bytes; I don't know how common it is
> for this box to be smaller
-off-by: Derek Buitenhuis
---
It is still weird to me that we prefer all of our internal code
to use ffio_free_dyn_buf but don't allow actual public API users
to use this functionality.
---
libavformat/movenc.c | 38 ++
1 file changed, 26 insertions(+
ned-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 5515e1b31b..cf66e5b0a2 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -115,6 +115,7 @@ static int use_va
On 27/06/2020 09:27, Michael Niedermayer wrote:
> You explain why allow_unknown_format_opts = 1 is needed
>
> does allow_unknown_format_opts = 0 have a use case too ?
> because if not, this can be simplified
I thought so too, but I thought a change in the behavior like that
might break peoples' s
On 26/06/2020 14:49, Nicolas George wrote:
> Probably a good idea, but these explanation should probably go in
> doc/ffprobe.texi.
Good point. Will add that during when I send v2.
> And I do not maintain ffprobe.
I have not seen Stefano active in a long time. Do you suggest I CC him on the
v2 p
On 26/06/2020 13:58, Derek Buitenhuis wrote:
> When doing streamed output, with e.g. +dash, if the mfra box ended
> up being larger than the AVIOContext write buffer, the (unchecked)
> seeking back to update the box size would silently fail and produce
> an invalid mfra box.
>
&g
On 28/06/2020 13:25, Derek Buitenhuis wrote:
> Will push tonight barring any objections.
Pushed.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
On 28/06/2020 21:23, Marton Balint wrote:
> I try to keep track of most ffprobe changes, so fine by me if people
> agree.
No argument from me.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
ned-off-by: Derek Buitenhuis
---
Changed to just be the main behavior instead of behind an option,
as Michael suggested.
Didn't really know what would be added to ffprobe.texi, though, since
this is no longer an option.
---
fftools/ffprobe.c | 6 ++
1 file changed, 2 insertions(+), 4 del
On 29/06/2020 18:04, Kyle Swanson wrote:
> since libvmaf v1.5.1, libvmaf has been relicensed as BSD+Patent
>
> Signed-off-by: Kyle Swanson
> ---
> configure | 1 -
> 1 file changed, 1 deletion(-)
You'll need to update the pkg-config check too if you want to
to this, since it's at >= 1.3.9 right
On 18/09/2019 10:30, Hello Vectronic wrote:
> The relevant extract from the ISO standard is:
Where is the relevant extract for MOV mode?
The QTFF docs literally say[1]:
If the color parameter type is 'prof', then this field is followed by an
ICC profile. This is the color model used by A
On 18/09/2019 10:30, Hello Vectronic wrote:
> I need to implement support for reading and writing ICC profiles which can be
> stored in MOV/MP4 sample descriptor colour information.
Does anything exist that can even consume or produce these sorts of files?
I looked a while back, and found litera
On 18/09/2019 17:29, Hello Vectronic wrote:
> And here is an example file: http://vectronic.io/icc-profile/icc-profile.mov
>
> And here is the relevant standard:
> https://standards.iso.org/ittf/PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip
>
Of note, the example file is not ISOB
On 22/09/2019 17:18, Kieran Kunhya wrote:
> And just like in the kernel, zero copy technology is maintained outside.
> Good design is separation of different functionality, otherwise the
> combinations of codepaths is exponentiated.
Agreed with everyone else here, this code doesn't belong in an en
On 27/09/2019 15:37, Matthieu Bouron wrote:
> Allows the creation of the sdtp atom while remuxing MP4 to MP4. This
> atom is required by Apple devices (iPhone, Apple TV) in order to accept
> 2160p medias.
Can you point to a document about this (for informational purposes)?
Is this valid for both
On 27/09/2019 16:45, Matthieu Bouron wrote:
> Fixed locally.
+1
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org wi
On 01/10/2019 18:25, James Almer wrote:
> The value in the unused field will be 0x after this change
> instead of 0, since you're writing 32 bits as duration instead of 64
> where the high 32 bits (corresponding to the unused field) are zeroed.
> That means the ivf demuxer prior to this pat
On 07/10/2019 16:06, Matthieu Bouron wrote:
> Ping.
>
No objections from me.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
rav1e now has a release, and is committed to proper semver for its soname:
https://github.com/xiph/rav1e/releases/tag/0.1.0
* All problems and nits form v4 have been addressed.
* Default mode is now QP
On 09/11/2019 18:03, James Almer wrote:
>> +if (ctx->tile_rows >= 0) {
>
> Since these are no longer log2 values, does rav1e change 0 to 1 internally?
> It may be a better idea to make 0 the default, and only call
> rav1e_config_parse_int() if it's > 0.
Yes.
Changed to match this.
>> +i
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
All previous requests applied/fixed.
---
configure | 5 +
doc/encoders.texi | 43 +++
doc/general.texi | 7 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1
201 - 300 of 1507 matches
Mail list logo
