Alright, I'll just convert to rgb then. Both the windows codec and the ds
decoder decode the subsampling by simply duplicating the u/v samples within
a 2x2 block (no interpolation). Should I do that too? Or would
interpolation be preferred? As far as I was able to see the windows codec
takes the av
fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
> It was introduced in d3d9b1fc8e2dfc8b4d66c9916ab7221062ff4660;
> Fixes Coverity issue #733800.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I have no testcase for this; but hopefully Michael can test it with the
> testcase that led t
On Tue, Mar 16, 2021 at 8:22 AM Florian Nouwt wrote:
> Alright, I'll just convert to rgb then. Both the windows codec and the ds
> decoder decode the subsampling by simply duplicating the u/v samples within
> a 2x2 block (no interpolation). Should I do that too? Or would
> interpolation be prefer
On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt wrote:
> It's actually closer to normal yuv than ycocg. If you look at the
> coefficients of normal yuv
> r = y + 1.14v
> g = y - 0.39u - 0.58v
> b = y + 2.03u
>
> ycocg
> r = y + co - cg
> g = y + cg
> b = y - co - cg
>
> the format used in actimagi
Why would those equations not make sense?? I literally looked the top two
up on wikipedia. And the bottom one was reverse engineered from the ds
decoder and I verified it to be accurate for this codec.
I too think that converting to rgb is not the most elegant solution, but it
would be better than
Up until now, there has been no check that each chapter has a unique id;
there was only a check for whether a chapter id is zero (this happens
often when the chapters originated from a format that lacks the concept
of chapter id and simply counts from zero) which is invalid in Matroska.
In this cas
These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:
[0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
Signed-off-by: Zane van Iperen
---
libavformat/pp_bnk.c | 51 ++
64 bits are needed in order to retain the uid values of Matroska
chapters; the type is kept signed because the semantics of NUT chapters
depend upon whether the id is > 0 or < 0.
Signed-off-by: Andreas Rheinhardt
---
Apologies for being so late.
doc/APIchanges| 4
libavformat/a
Zane van Iperen:
> These files are technically a series of planar mono tracks.
> If the "music" flag is set, merge the packets from the two
> mono tracks, essentially replicating:
>
> [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/p
On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:
+
+if (ctx->is_music) {
+if (pkt->stream_index == 0) {
+ctx->current_track--;
I have to admit to be confused by this. Won't this imply that
ctx->current_track will always be zero for music files until you hit t
On 16/3/21 6:47 pm, Zane van Iperen wrote:
On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:
+
+ if (ctx->is_music) {
+ if (pkt->stream_index == 0) {
+ ctx->current_track--;
I have to admit to be confused by this. Won't this imply that
ctx->current_track will
Zane van Iperen:
>
>
> On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:
>
>>> +
>>> + if (ctx->is_music) {
>>> + if (pkt->stream_index == 0) {
>>> + ctx->current_track--;
>>
>> I have to admit to be confused by this. Won't this imply that
>> ctx->current_track will
On Tue, Mar 16, 2021 at 18:30:19 +1000, Zane van Iperen wrote:
Nit:
> Subject: avformat/pp_bnk: treat music files are stereo
^ as
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.
These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:
[0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
Signed-off-by: Zane van Iperen
---
libavformat/pp_bnk.c | 52 ++
Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
> 64 bits are needed in order to retain the uid values of Matroska
> chapters; the type is kept signed because the semantics of NUT chapters
> depend upon whether the id is > 0 or < 0.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Apologies for bei
On 15.03.2021 17:19, Gyan Doshi wrote:
On 2021-03-15 18:54, Tobias Rapp wrote:
In the meanwhile libx264 allows to be configured for including both
8/10 bit
support within a single library. The new libx264 interface was enabled in
2f96190732d15510ba29471fa45d66841c0c3df1.
Signed-off-by: Tobia
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
>> 64 bits are needed in order to retain the uid values of Matroska
>> chapters; the type is kept signed because the semantics of NUT chapters
>> depend upon whether the id is > 0 or < 0.
>>
>> Signed-off-by: Andreas Rheinhardt
>> -
No further comments, so set pushed.
--
Anton Khirnov
___
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 "unsubsc
No further comments, so set pushed.
--
Anton Khirnov
___
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 "unsubsc
Quoting James Almer (2021-03-10 16:17:35)
> On 3/10/2021 9:03 AM, Anton Khirnov wrote:
> > avcodec_open2() is massive, splitting it makes it more readable.
> >
> > Also, add a missing error code to ticks_per_frame sanity check.
> > ---
> > libavcodec/encode.c | 157 ++
Greetings,
Thank you for your help in advance.
Unfortunately, my patch, which add support the "HEVC with alpha" profile to the
videotoolbox encoder, has not been reviewed for nearly three weeks. Would it be
possible to give me why nobody has reviewed my patch?
Regards,
Hironori Bono
E-mail: bo
Quoting Andreas Rheinhardt (2021-03-16 10:34:22)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
> >> 64 bits are needed in order to retain the uid values of Matroska
> >> chapters; the type is kept signed because the semantics of NUT chapters
> >> depend upon whether the id i
On Mon, Mar 15, 2021 at 5:06 PM Zhao Zhili wrote:
>
> ---
> libavformat/libsrt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index 233e9096fa..ac865c5658 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @
Am 10.03.21 um 18:19 schrieb Thilo Borgmann:
> Am 10.03.21 um 09:25 schrieb Zane van Iperen:
>> Before you do, just give it a crack locally.
>>
>> I couldn't get the cloned version of the site to look identical to what's
>> already published (something to do with incorrect CSS symlinks iirc). It's
On 3/11/2021 10:34 AM, Michael Niedermayer wrote:
On Wed, Mar 10, 2021 at 06:25:58PM -0300, James Almer wrote:
On 3/10/2021 5:22 PM, Michael Niedermayer wrote:
On Sat, Mar 06, 2021 at 06:45:57PM -0300, James Almer wrote:
On 3/6/2021 6:35 PM, Michael Niedermayer wrote:
On Fri, Mar 05, 2021 at
Some measurements:
cpu: Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
gpu: Quadro RTX 4000
GPU H264 DECODING
=
NOTE:
- first column is max floating average over past 10s
- second column is overall maximum during measurement (at least 1 min)
- measure for custom app using new ffmpe
This patch adds support to decode IEC61937_EAC3 (aka dolby digital plus).
Signed-off-by: Denis Shulyaka
---
libavformat/spdifdec.c | 47 ++
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c
index
On Fri, Mar 12, 2021 at 2:06 PM Mark Thompson wrote:
> On 12/03/2021 18:29, Suji Velupillai wrote:
> > On Fri, Mar 12, 2021 at 1:12 AM Jean-Baptiste Kempf
> wrote:
> >
> >> On Thu, 11 Mar 2021, at 23:09, suji.velupil...@broadcom.com wrote:
> >>> Initial commit to add VKAPI hardware accelerator i
Hi,
apart from the existing code and the sample files in ticket #9153,
Nellymoser in swf is apparently supported by Flash binaries if I read
the existing exploit correctly.
Please comment, Carl Eugen
From 3d1a744ce548fab6f3ae1b8f7f867a80452637b7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Da
These fields can't be set via AVOptions, ergo one can check them before
having allocated anything.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/utils.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index
Also move them to ff_decode_preinit().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/decode.c | 35 +++
libavcodec/utils.c | 40
2 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/libavcodec/decode.c b/lib
This is how it is supposed to happen, yet when using frame threading,
the codec's init function has been called before preinit. This can lead
to crashes when e.g. using unsupported lowres values for decoders
together with frame threading.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/utils.c
Signed-off-by: Andreas Rheinhardt
---
I actually wonder why this flag is not used for encoders. Several of
them explicitly check for invalid channel values.
libavcodec/decode.c | 5 +
libavcodec/utils.c | 8
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavcodec/
Added in dc51a72ba45fbefb9f1c6c3ca5a5b2388d69b2da, yet even back then
the check was always true as the AVCodecContext has already been memset
to zero before that.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/options.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/options.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/options.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 53f13dab37..58c7ce8d62 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -140,10 +140,9 @@ static i
Unfortunately it is not possible to move the hack to the bottom, because
the "normal processing" (dv_profiles lookup loop) will catch it
otherwise (with a wrong profile), because it does not check the frame_size:
for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++)
if (dsf == dv_profil
Oh yes, of course. I updated the commit-message in the attached new patch.
Am 13.03.21 um 11:41 schrieb Michael Niedermayer:
The commit message should mention "Fixes Ticket8333" if that is a bugfix
for that ticket
also maybe some of the other details you write in your mail could be moved
into
Would it be possible for someone to take a look at this please? Would be
lovely to get it merged at some point. Please let me know if further
changes are needed.
Cheers,
Dave
On Tue, Oct 13, 2020 at 10:25 AM Dave Evans wrote:
> This patch fixes the total failure to parse cues when style and reg
On Tue, 16 Mar 2021, Mark Plomer wrote:
Unfortunately it is not possible to move the hack to the bottom, because
the "normal processing" (dv_profiles lookup loop) will catch it
otherwise (with a wrong profile), because it does not check the frame_size:
Then at least check the 50/60 flag as
On Tue, 16 Mar 2021, Marton Balint wrote:
On Tue, 16 Mar 2021, Mark Plomer wrote:
Unfortunately it is not possible to move the hack to the bottom, because
the "normal processing" (dv_profiles lookup loop) will catch it
otherwise (with a wrong profile), because it does not check the frame_
On 16/3/21 11:31 pm, Thilo Borgmann wrote:
Am 10.03.21 um 18:19 schrieb Thilo Borgmann:
Am 10.03.21 um 09:25 schrieb Zane van Iperen:
Before you do, just give it a crack locally.
I couldn't get the cloned version of the site to look identical to what's
already published (something to do wit
> -Original Message-
> From: Guo, Yejun
> Sent: 2021年3月13日 14:29
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH 5/5] lavfi/dnn_backend_openvino.c: fix mem leak for TaskItem
> upon error
>
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 12 ++--
> 1 file chan
Thank you Mark for your feedback. Please see inline
On Fri, Mar 12, 2021 at 1:14 PM Mark Thompson wrote:
> On 11/03/2021 22:09, suji.velupil...@broadcom.com wrote:
> > From: Suji Velupillai
> >
> > Initial commit to add VKAPI hardware accelerator implementation.
> > The depedency component vkil
On 3/12/2021 9:15 PM, James Almer wrote:
For ffmpeg 4.4, as the last version featuring avcodec_encode_video2/audio2 and
since marking an encoder as AV_CODEC_CAP_DR1 capable will make it unusable with
that API, we should only port encoders using the AVCodec.receive_packet() API.
The rest can be p
On Mon, 15. Mar 11:52, Martin Storsjö wrote:
> On Sat, 13 Mar 2021, Andriy Gelman wrote:
>
> > From: Andriy Gelman
> >
> > Commit 8c8e5d5286bf598a89ef9993a2cf6ea409d03a32 added a way to reduce
> > seek time by waiting for the windowed tcp packets instead of creating a
> > new socket connection.
ping on this patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
FF_CODEC_CAP_AUTO_THREADS added in 8a129077cc requires internal.h
---
libavcodec/libdavs2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 383b54039a..0f18353c93 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -23,6 +23,7 @
47 matches
Mail list logo
