On 11/28/2023 2:30 PM, Derek Buitenhuis wrote:
> Direct insults are unacceptable and I have forwarded this to CC,
> which can hopefully look after the vote.
(I include myself in this, the irony wasn't lost on me.)
- Derek
___
ffmpeg-devel m
On 11/28/2023 3:50 PM, Anton Khirnov wrote:
> Calling things generically bad is the opposite of helpful.
I cannot offer help on making a paragraph that I don't fully
understand become more comprehensible, as that would require
I understand it fully.
But, I would again like to state these votes sh
On 06/04/2019 18:40, Marton Balint wrote:
> Sorry, vote has been called for, and I used the commit count to select
> people as in the second extension:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html
That's from 2015...
- Derek
On 22/04/2019 13:19, myp...@gmail.com wrote:
> Ping?
>
LGTM.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with
On 29/04/2019 23:45, fumoboy007 wrote:
> One situation where a subtitle packet can be marked for discard is when
> demuxing an MOV file that has an edit list.
> ---
> libavcodec/decode.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Will this work properly if a given subtitl
On 22/05/2019 18:55, Darren Mo wrote:
> Good question. The subtitle would be discarded if it overlaps an edit
> boundary.
>
> The root cause is the MOV demuxer currently marks boundary packets for
> discard. However, due to subtitle frames not being discarded (fixed by this
> patch), the root c
On 23/05/2019 23:58, Darren Mo wrote:
> To clarify, do you mean we should merge this now or wait for the second
> patch, which fixes the root cause?
I have no strong opinion on it. Unsure which is better for a user experience,
given they'll both be broken in some way.
I'd say merge if you feel
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 07bca81aef..f56def53d5 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -133,6 +133,14
On 24/05/2019 17:05, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libswresample/swresample.c | 8
> 1 file changed, 8 insertions(+)
Seems reasonable. What happens if these aren't in place?
- Derek
___
ffmpeg-devel mailing list
ff
On 25/05/2019 04:25, James Almer wrote:
>> +
>
> Unnecessary empty line.
Fixed.
> Could we not? The idea is to eventually kill these, so we should at
> least try to not make them even more widespread...
As far as I know, they can't be removed, as there isn't a simple replacement
for some of the
On 25/05/2019 22:31, James Almer wrote:
> Ah hell, whatever, just push it. Jeeb pointed out the reason you wrote
> this patch. Reverting this patch in the future should be trivial anyway.
This patch also adds support for checking the AVCOL range. If you object that
strongly to it, I'm sure they do
On 25/05/2019 22:55, Derek Buitenhuis wrote:
> This patch also adds support for checking the AVCOL range. If you object that
> strongly to it, I'm sure they don't mind switching to -color_range jpeg. That
> works with x264, etc. too.
Pushed as-is, as per IRC con
Uses the crav1e C bindings for rav1e.
Missing version bump and changelog entry.
Signed-off-by: Derek Buitenhuis
---
Hoping to get some eyes on this, and maybe help some people who want to
test out rav1e without having to use Y4Ms or pipes.
Some points:
* The C bindings for rav1e currently
On 28/05/2019 20:32, James Almer wrote:
>> +default:
>> +// This should be impossible
>> +return (RaChromaSampling) -1;
>
> If it's not meant to happen, then it should probably be an av_assert0.
Yeah, that makes more sense. Will change.
>> +int rret;
>> +int ret = 0;
On 28/05/2019 20:49, Derek Buitenhuis wrote:
>>> +static const AVOption options[] = {
>>> +{ "quantizer", "use constant quantizer mode", OFFSET(quantizer),
>>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE },
>>> +{ "max-qua
On 28/05/2019 20:58, James Almer wrote:
> I think x26* and vpx/aom call it crf? It's not in option_tables.h in any
> case.
They do not. This is a constant quantizer mode, not constant rate factor.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
On 29/05/2019 01:19, James Darnley wrote:
> IIRC either qp or cqp
Yeah, I'll use that; it makes sense.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or e
Uses the crav1e C bindings for rav1e.
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
The only thing I didn't address from the last set of replies was the
second 'ret' variable, since I prefer it that way (having a separate
ret for avc
On 29/05/2019 16:01, Lynne wrote:
> for (int i = 0; i < desc->nb_components; i++) {
> rav1e_frame_fill_plane() should probably return an error if the plane index
> is invalid.
Yep. Fixed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
On 29/05/2019 17:12, James Almer wrote:
>> +end:
>> +if (cfg)
>> +rav1e_config_unref(cfg);
>> +
>> +if (ret)
>> +librav1e_encode_close(avctx);
>
> Use the FF_CODEC_CAP_INIT_CLEANUP flag in AVCodec.caps_internal instead.
> It will call AVCodec.close() on AVCodec.init() failu
Uses the crav1e C bindings for rav1e.
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
Changes since v2:
* Removed 4:0:0 support; seems broken in rav1e (ref:
https://github.com/xiph/rav1e/issues/1312)
* Moved to use FF_CODEC_CAP_INIT_CLEANUP
On 30/05/2019 15:51, James Almer wrote:
> You could add tile-columns, tile-rows, and speed options.
I'm of two minds here.
One one hand, it is convenient.
On the other hand, you may end up with a crappy pile of stuff
like libx264.c where everything has its own option or aomenc
where new stuff is
On 30/05/2019 17:27, James Almer wrote:
> All three options are important to get decent and/or fast encodings, so
> if you'd rather not add options for them, you should document what
> key=value combinations can be passed to rav1e-params, either in
> encoders.doxy, or as a printed list like libx264
On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
> So is your patch meant to wait until this merge is done?
> I would suggest so...
Soon has a (TM) beside it for a reason (there needs to be some
work done on Rust itself first, I think.) I would expect it to
take at least 1-2 months. The API itself won
On 02/06/2019 19:45, Moritz Barsnick wrote:
> https://github.com/lu-zero/crav1e says:
>
> Status
> The API is far from stable
Yeah, that's not super true any more, and I'll remove it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 02/06/2019 19:27, Carl Eugen Hoyos wrote:
> Since a lot of unexpected changes can happen after months,
> this sounds to me like a strong reason to wait.
This has nothing to do with API changes, it's a Rust toolchain (build
system, specifically) thing. These changes don't change API/ABI.
- Dere
On 02/06/2019 21:19, Derek Buitenhuis wrote:
> This has nothing to do with API changes, it's a Rust toolchain (build
> system, specifically) thing. These changes don't change API/ABI.
Also to add: We will probably be cutting a 'real' rav1e release soon (0.1.0),
I think.
On 19/06/2019 06:43, Gyan wrote:
>> setting track_duration is inconsistent; some times it includes
>> duration and some times not.
> It may be best to check the commits for these assignments to see if the
> inconsistency is deliberate.
> The track duration is written into the media header box for
This packet was not necessarily unreferenced.
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 3becb6330e..52f24e7dfd 100644
--- a/fftools/ffprobe.c
+++ b/fftools
This packet was not necessarily unreferenced.
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 3becb6330e..dac70ba5a1 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2429,6 +2429,8
On 21/06/2019 14:46, James Almer wrote:
> Why not just call this unconditionally instead of the init() + zero below?
I wasn't sure from a quick skim if these packets were
referenced elsewhere (and thus unrefercing twice would
be problematic).
If it's safe to do so, I will.
- Derel
__
On 21/06/2019 15:26, Nicolas George wrote:
> How can the packet not be unreferenced when the very previous
> instruction is av_packet_unref()? All the code paths I see either pass
> through the existing av_packet_unref() before reaching the new one or
> arrive with a blank packet. Am I missing some
On 21/06/2019 15:26, James Almer wrote:
> Remove the three lines below as well before pushing. They are
> superfluous as av_packet_unref() does the same internally.
OK.
The documentation for av_packet_unref says it sets the 'remaining'
fields to default values, but av_init_packet says it sets the
This packet was not necessarily unreferenced.
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 3becb6330e..5aaddb0308 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
Signed-off-by: Derek Buitenhuis
---
Onward and upward with the never-ending quest to manually forward
all the HTTP options to the subcontexts in every meta-muxer!
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 4
2 files changed, 7 insertions(+)
diff --git a/doc/muxers.texi b/doc
On 27/06/2019 05:16, Steven Liu 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 w
On 03/07/2019 08:41, Reimar Döffinger wrote:
> Of course another question might be if it might make sense to replace all
> memcpy uses with it.
I would expect this may break some compiler optimizations around
memcpy (like __builtin_memcpy, or direct inlining), no?
- Derek
___
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
Lots of stuff happened since v3!
* The C API / library is now in rav1e's main repo, and officially supported.
* rav1e will bump the soname and pkg-config version on any breaking changes.
* C API is n
On 09/07/2019 19:34, Derek Buitenhuis wrote:
> +Go to @url{https://github.com/lu-zero/crav1e/} and follow the instructions
> to build
> +the C library. To enable using rav1e in FFmpeg, pass @code{--enable-librav1e}
> +to @file{./configure}.
Eugh. This is supposed to point to https:
On 09/07/2019 19:34, Derek Buitenhuis wrote:
> * Added two pass support.
As a side note, I really dislike the stats_out/stats_in API, since it requires
the whole stats be held in memory. This my become problematic when rav1e adds
temporal RDO (think mbtree) and the stats files grow a
On 09/07/2019 22:06, James Almer wrote:
>> @@ -3174,6 +3176,7 @@ libopenmpt_demuxer_deps="libopenmpt"
>> libopus_decoder_deps="libopus"
>> libopus_encoder_deps="libopus"
>> libopus_encoder_select="audio_frame_queue"
>> +librav1e_encoder_deps="librav1e"
>
> Needs to enable extract_extradata_bsf
On 09/07/2019 21:23, Moritz Barsnick wrote:
>> +Sets the minimum quantizer (ceiling) to use when in bitrate mdoe.
>
> Typo -> "mode"
Fixed locally.
>
>> +av_log(avctx, AV_LOG_ERROR, "Unknown return code from
>> rav1e_send_frame.\n");
>> +return AVERROR_UNKNOWN;
>
> Feel free t
On 10/07/2019 13:56, James Almer wrote:
>> Heavily disagree. rav1e has its own 'tiles' option that determines the right
>> cols/rows to use for a reason, and I will not be emulating libaomenc's algo
>> instead of using the one provided by rav1e. It's confusing at best (since
>> it goes against the
On 13/07/2019 19:37, James Almer wrote:
> Just use av_reallocp(). Each call will make the buffer bigger, so you're
> not really making use the no-op benefits from av_fast_realloc(), which
> only trigger if newsize <= size.
I'll wait for your reply to Nicholas and do whichevr people agree on.
>> +
On 15/07/2019 15:53, James Almer wrote:
>>> AV_BASE64_DECODE_SIZE(strlen(avctx->stats_in));
>>
>> I copied this directly from libtheoraenc.c which has had this for more than
>> 10
>> years... is it wrong? Should it be changed too?
>
> It's not wrong, that helper macro was added three years ago an
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 the
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
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
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 a
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
h
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
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
On 16/09/2018 23:01, Artjom Vejsel wrote:
> Signed-off-by: Artjom Vejsel
> ---
> libavformat/http.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
This should be an AVOption instead of a hardcoded number.
- Derek
___
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
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
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 us
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.
ff-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 @
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 w
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
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
>
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
__
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
http://ffmpeg
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 w
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 lik
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 ins
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
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
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
ff
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
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
n
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 m
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
On 21/11/2018 02:47, Haihao Xiang wrote:
> This fixes the link errors below:
>
> LD ffmpeg_g
> libavfilter/libavfilter.so: undefined reference to `ff_scene_sad_avx2'
> libavfilter/libavfilter.so: undefined reference to `ff_scene_sad_sse2'
> collect2: error: ld returned 1 exit status
> Makefil
On 21/11/2018 14:09, Hendrik Leppkes wrote:
> This does not apply here, the function is called unconditionally on
> x86 (or rather on ARCH_X86)
> What we usually do is just put the contents of such functions into the
> guard, and not the init function itself - instead of having a second
> one.
Ah,
uot;demuxer" without a deprecation period.
Derek Buitenhuis (3):
fftools/ffmpeg: Don't mangle start time based on discontinuities for
FLV
flvdec: Mark the demuxer as allowing discontinuous timestamps
lavf: Depecate the live_flv demuxer
fftools/ffmpeg.c | 3 ++-
As far as I can tell, this isn't valid here sicne FLV may not have added
streams yet.
Signed-off-by: Derek Buitenhuis
---
fftools/ffmpeg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index a12208cce9..3bc42c8ca8 100644
--- a/ff
ow it *actually* works. Lying to
downstream API users about a demuxer's behavior is not OK.
Also set AVFMT_NOBINSEARCH, as this should be true given discontinuous
timetsamps.
Signed-off-by: Derek Buitenhuis
---
libavformat/flvdec.c | 14 --
1 file changed, 4 insertions(+), 1
It is now the same as the regular FLV demuxer, and has no reason to exist.
Signed-off-by: Derek Buitenhuis
---
libavformat/allformats.c | 2 ++
libavformat/flvdec.c | 2 ++
libavformat/version.h| 3 +++
3 files changed, 7 insertions(+)
diff --git a/libavformat/allformats.c b
On 21/11/2018 16:31, Hendrik Leppkes wrote:
> Format name comparisons are basically always wrong. Don't we have
> AVFMTCTX_NOHEADER for that?
I could change it to use that, yeah. I'll send a v2 that does, if
the author agrees it's the correct fix.
- Derek
_
On 22/11/2018 02:16, Michael Niedermayer wrote:
> the specification says this:
> "Timestamp UI24 Time in milliseconds at which the data in this tag
> applies. This is relative to the first tag in the FLV file,
> which always has a timestamp of 0.
> "
> So flv does no
On 22/11/2018 12:55, Carl Eugen Hoyos wrote:
> Only the downstreams that expect invalid files, no?
It's the generic way to handle containers which can have
discontinuous timestamps. Nothing to do with expecting invalid
files.
Cheers,
- Derek
___
ffmpeg-
On 23/11/2018 02:16, Michael Niedermayer wrote:
> do we have some sample flv files that require this patchset / that have
> discontinuites.
I have many. I've mailed you one privately, while I work on getting a public
one.
> another thing i just realize now, why is this discontinuity issues comin
On 07/10/2019 11:40, vectronic wrote:
> Hello,
>
> Wondering if anyone would be able to review these changes? I’m currently
> using this in production and it is working well.
The patch set looks OK to me. I will push in 24h if nobody objects.
- Derek
On 09/03/2020 21:43, James Almer wrote:
> The second patch is very outdated, and should be squashed with the first
> (alongside a lavc minor version bump that would be reflected in the
> APIChanges entry).
Yes, the update and bump before pushing is implied, I thought.
- Derek
On 10/03/2020 11:33, Hendrik Leppkes wrote:
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changing delay.
I second this. A lot of software an usecases benefits (or requires) this.
Not to mention non-determinism...
- Derek
__
On 10/03/2020 09:36, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> ---
> libavcodec/pthread_frame.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
In addition to the points already raised (and which I agree
On 11/03/2020 03:28, Dai, Jianhui J wrote:
> As reply in another thread, the sequence of output frames still follows
> standard, like display order POC in H264.
> Big enough frame cache can guarantee deterministic delay in some extent, but
> not always (decoding time > caching time).
That was my
On 11/03/2020 05:29, Dai, Jianhui J wrote:
> Like RTSP/RTMP/DASH, the latency is variable according to network bandwidth.
He is not talking about wallclock or een latency in the time domain.
Latency as in 'number of packets passed in before a frame is output'. Which this
patch makes both non-dete
On 11/03/2020 14:53, Devin Heitmueller wrote:
> Regardless of the actual proposed patch, I think the author's use of
> wallclock time to describe the problem is very reasonable. I do a
> large amount of work where I'm measuring "glass-to-glass" latency,
> where I am interested in the total pipelin
On 11/03/2020 20:42, Martin Storsjö wrote:
> FWIW, while I agree it shouldn't be the default, I have occasionally
> considered the need for this particular feature.
Arguably slice threading should be used, but that assumes you have sane input,
which is obviously not always the case for some.
> C
On 17/03/2020 10:54, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/hevc_sei.c | 31 +++
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c| 14 ++
> t
On 17/03/2020 23:11, Limin Wang wrote:
> The user data unregistered allows arbitrary data to be carried in the
> bitstream,
> for example, ROI info, time info etc. For the real support patch, please
> refer to
> the pending patch series 7, 8 in below link:
> https://patchwork.ffmpeg.org/project/f
On 18/03/2020 14:31, Andreas Rheinhardt wrote:
> I initially also wanted to remove the internal note for AVStream's private
> fields ("be aware that physically removing these fields will break
> ABI"), but then I became aware that ffmpeg.c uses several of them
> (pts_wrap_bits, first_dts, cur_dts,
On 21/08/2019 10:04, Andreas Rheinhardt wrote:
> +#if FF_API_NONCONST_ENUM_PROTOCOLS
> const char *avio_enum_protocols(void **opaque, int output)
> +#else
> +const char *avio_enum_protocols(const void **opaque, int output)
> +#endif
Do we actually allow breakage like this (even at major bumps)?
On 23/03/2020 22:11, Lynne wrote:
> The specifications are de-facto frozen now as they've already been used in
> production for years now, the author has indicated reluctance on IRC to change
> it further, and the only potential changes would, from what I understand, be
> forward-compatible.
+1 fr
On 07/03/2020 15:32, David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host. Drop the condition that
On 31/03/2020 00:25, Michael Bradshaw wrote:
> If this really breaks things for people (which I highly doubt it will) they
> can always send a patch with a better and more robust implementation. But I
> feel strongly that we should not stabilize the write_colr flag with this
> auto-guessing logic.
On 31/03/2020 00:36, Michael Bradshaw wrote:
> The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
> experimental and the clli atom is not written by default.
Would it make sense to allow it by default for QTFF only, since it is properly
defined in it? OR would that perhaps be a
On 01/04/2020 09:52, Matthieu Bouron wrote:
> ---
> libavformat/img2dec.c | 1 +
> 1 file changed, 1 insertion(+)
Looks correct, but a commit message explaining why would be good.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ff
101 - 200 of 1502 matches
Mail list logo
