Michael Niedermayer skrev
> On Tue, Aug 08, 2017 at 11:49:45PM +0200, Tomas Härdin wrote:
> [...]
>
> > ffmpeg.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> > 5bd20883fdc12aefa609fc803fe5709069b3e9a0
> > 0003-Don-t-complain-
ons 2024-05-15 klockan 23:29 +0200 skrev Michael Niedermayer:
> On Wed, May 15, 2024 at 09:39:43PM +0200, Tomas Härdin wrote:
> > Hi
> >
> > So as I said in the coverity thread it would be good if we could
> > get at
> > least part of the codebase covered using f
tor 2024-05-16 klockan 13:12 +0100 skrev Andrew Sayers:
> On Wed, May 15, 2024 at 09:39:43PM +0200, Tomas Härdin wrote:
> > Hi
> >
> > So as I said in the coverity thread it would be good if we could
> > get at
> > least part of the codebase covered using f
The entire patchset passes FATE
/Tomas
From c000b8a5e90883f28ce6c58960227e5825ac20d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 15 May 2024 21:03:47 +0200
Subject: [PATCH 1/5] lavu/common.h: Fix UB in av_clipl_int32_c()
Found by value analysis
---
libavutil
From 7b18f24c0bedfeebcdfb23ea837cea8d4c35cf30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 16 May 2024 16:33:44 +0200
Subject: [PATCH 2/5] lavu/common.h: Fix UB in av_clip_intp2_c()
Found by value analysis
---
libavutil/common.h | 2 +-
1 file changed, 1 insertion
From f81730f8facc54ef23df79ac8d33075403b4f76f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 16 May 2024 16:37:58 +0200
Subject: [PATCH 3/5] lavu/common.h: Fix UB in av_clip_uintp2_c()
Found by value analysis
---
libavutil/common.h | 4 ++--
1 file changed, 2
From f9a12089bc98dde0ccc2487d1442ec6ddb7705f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 16 May 2024 18:10:58 +0200
Subject: [PATCH 4/5] lavu/intmath.h: Fix UB in ff_ctz_c() and ff_ctzll_c()
Found by value analysis
---
libavutil/intmath.h | 4 ++--
1 file changed
This doesn't really fix anything, it just makes the value analysis
easier. I don't feel strongly about it.
/Tomas
From cf9c56d7d4d7325d51ba6d99259431be7fca1f67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 20 May 2024 14:46:01 +0200
Subject: [PATCH
tor 2024-05-30 klockan 00:24 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > static av_always_inline av_const int av_clip_intp2_c(int a, int p)
> > {
> > - if (((unsigned)a + (1 << p)) & ~((2 << p) - 1))
> > + if (((unsigned)a + (1U <&l
tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
> Hi,
>
> Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin" a
> écrit :
> > The entire patchset passes FATE
>
> Is the version in riscv/intmath.h safe? It looks to me that the GCC
> codegen for no
tor 2024-05-30 klockan 00:31 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > */
> > static av_always_inline av_const int32_t av_clipl_int32_c(int64_t
> > a)
> > {
> > - if ((a+0x8000u) & ~UINT64_C(0x)) return
> > (in
t it that maybe it wasn't working so well 20 years ago, but we've
> increased compiler version requirements since then.
I think we still support MSVC, but maybe we shouldn't? It's possible to
cross-compile for Windows either way.
/Tomas
__
tor 2024-05-30 klockan 16:06 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 12:50:05 GMT+03:00, "Tomas Härdin" a
> écrit :
> > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont:
> > > Can't we just use the compiler built-ins here?
tor 2024-05-30 klockan 14:50 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 12:40:20 GMT+03:00, "Tomas Härdin" a
> écrit :
> > tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
> > > Hi,
> > >
> > > Le 30 mai 2024
Ping
Will push in a couple of days
/Tomas
___
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".
Ping
This stops us from producing broken output
/Tomas
___
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
tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a
> écrit :
> > > We should depend on punning as long as it conforms to the
> > > standard.
> >
> > My mistake,
tor 2024-05-30 klockan 12:42 -0300 skrev James Almer:
> On 5/30/2024 12:32 PM, Tomas Härdin wrote:
> > tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
> > >
> > >
> > > Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin"
> > > a
fre 2024-05-31 klockan 02:22 +0200 skrev Michael Niedermayer:
> On Thu, May 30, 2024 at 12:15:27AM +0200, Tomas Härdin wrote:
> > This doesn't really fix anything, it just makes the value analysis
> > easier. I don't feel strongly about it.
>
> if it doesnt fix
tor 2024-05-30 klockan 20:49 +0300 skrev Rémi Denis-Courmont:
> Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit
> > It is not a "theoretical" UB - that's not how UB works.
>
> It is a *theoretical* UB if you can not prove that it leads to
>
sed |= used[i] * (1 << i);
> + rps->used |= used[i] * (1U << i);
Why not just (uint32_t)used[i] << i?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To u
ated
> events.
Also reasonable. I could help man a booth at IBC or any other event in
Europe
> Also we need more cute girls on these events, everything i hear
> its 100% male geeks/hackers.
Michael please
/Tomas
___
ffmpeg-devel mailing lis
sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer:
> Hi
>
>
> On Sat, Jun 01, 2024 at 05:19:26PM +0200, Tomas Härdin wrote:
>
> [...]
>
> > > * Fund professional real live presence on multimedia / FOSS /
> > > buisness related
> > >
of av_image_get_buffer_size() before adding
HEADER_SIZE to it. There will be a signed overflow (UB) for images of
size 16385x16385 (and many others).
Aside: av_image_get_buffer_size() will UB for sizes above INT_MAX
because the size_t's in sizes[] get accumulated into an int. Besides
> Check the return value of av_image_get_buffer_size() before adding
> HEADER_SIZE to it. There will be a signed overflow (UB) for images of
> size 16385x16385 (and many others).
Sorry, I missed the multiplication by h+128 in av_image_check_size2().
So this isn't a problem in this specific case.
tor 2024-05-30 klockan 16:23 +0200 skrev Tomas Härdin:
> Ping
>
> This stops us from producing broken output
Pushed
/Tomass
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
tor 2024-05-30 klockan 16:23 +0200 skrev Tomas Härdin:
> Ping
>
> Will push in a couple of days
Passes FATE -> pushed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubs
mån 2024-06-03 klockan 08:50 +0200 skrev Thilo Borgmann via ffmpeg-
devel:
> Am 02.06.24 um 22:14 schrieb Tomas Härdin:
> > sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer:
> > > Hi
> > >
> > >
> > > On Sat, Jun 01,
bly) #10906.
Shouldn't users use non-buggy versions of libx26? I've had people ask
about CC, and I'm sure many users would be annoyed at them suddenly
breaking. I suggest complaining loudly at compile time and/or when
loading libx265 instead
/Tomas
tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
> > > The SEI handling of libx265 is buggy and can easily lead
> > > to memory corruption: It reuses certain buffers, but
tis 2024-06-11 klockan 10:16 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt:
> > > > > The SEI han
tions
> > Please provide benchmarks (for sh4, avr32)
>
> This is a ridiculous request, considering nobody has such hardware at
> all.
Maybe Måns has? He's the one who added the AVR32 code. The SH4 code was
added all the way back in 2003 in 0c6bd2ea by someone who goes by BERO.
tis 2024-06-11 klockan 18:10 +0200 skrev Michael Niedermayer:
> On Tue, Jun 11, 2024 at 05:50:35PM +0200, Tomas Härdin wrote:
> [...]
> > Perhaps we should demand platforms for which we have asm also have
> > FATE
> > instances?
>
> qemu based fate we have for s
Pushed patches 1-4
/Tomas
___
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".
; libavutil/intreadwrite.h | 2 -
> 7 files changed, 1 insertion(+), 358 deletions(-)
> delete mode 100644 libavcodec/avr32/mathops.h
> delete mode 100644 libavutil/avr32/bswap.h
> delete mode 100644 libavutil/avr32/intreadwrite.h
Sounds good to me
/Tomas
___
mån 2024-06-17 klockan 11:41 -0300 skrev James Almer:
> Signed-off-by: James Almer
> ---
> tests/fate/lavf-container.mak | 2 ++
> tests/ref/lavf-fate/hevc.mp4 | 3 +++
> 2 files changed, 5 insertions(+)
> create mode 100644 tests/ref/lavf-fate/hevc.mp4
roken files then
there's no reason to be lenient. And if such a broken encoder exists we
could try to get it fixed
> @@ -112,6 +112,13 @@ typedef struct Jpeg2000DecoderContext {
> Jpeg2000Tile *tile;
> Jpeg2000DSPContext dsp;
>
> + uint8_t isHT; // HTJ2K?
Isn't it possible to mix Part 1 and HT in the same file? I know HTONLY
exists also
> @@ -406,6 +420,7 @@ static void recover_mag_sgn(StateVars *mag_sgn,
> uint8_t pos, uint16_t q, int32_t
> E[n] = 32 - ff_clz(v[pos][i] | 1);
> mu_n[n] = (v[pos][i] >> 1) + 1;
> mu_n[n] <<= pLSB;
> + mu_n[n] |= (1 << (pLSB - 1)); // Add 0.5 (reconstruction
> parameter = 1/2)
Aren't there conformance files to catch these kinds of errors? I
remember looked at J2K a while back, and I think we should add such
files to FATE
/Tomas
___
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".
p0_10 | 6 ++
> 2 files changed, 9 insertions(+)
> create mode 100644 tests/ref/fate/jpeg2000dec-p0_10
Sounds good, assuming it decodes correctly
If there are more files like this, could we add all of them in one go?
/Tomas
___
ffmpeg-deve
;))
> {
> st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
> st->codecpar->codec_id = AV_CODEC_ID_EIA_608;
OK
/Tomas
___
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".
ffv1 version %d\n",
> v);
> return 0;
Commit message isn't quite accurate - this rather resurrects the error
print
/Tomas
___
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".
mån 2024-06-03 klockan 08:50 +0200 skrev Thilo Borgmann via ffmpeg-
devel:
> Am 02.06.24 um 22:14 schrieb Tomas Härdin:
> > sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer:
> > > Hi
> > >
> > >
> > > On Sat, Jun 01,
id you incorrectly format that message? Or did you really mean that
> the UB when the size is greater than INT_MAX doesn't affect my patch?
It doesn't affect this patch because AV_PIX_FMT_RGBA64BE isn't planar
/Tomas
___
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".
ons 2024-06-19 klockan 05:51 + skrev WATANABE Osamu:
> First of all, I appreciate your kind review.
> I'm writing to discuss the changes and would like to hear your
> feedback on these.
>
>
> > On Jun 18, 2024, at 23:20, Tomas Hardin wrote:
> >
> >
tis 2024-06-18 klockan 07:59 -0700 skrev Pierre-Anthony Lemieux:
> On Tue, Jun 18, 2024 at 7:25 AM Tomas Härdin wrote:
> >
> > lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com:
> > > From: Pierre-Anthony Lemieux
> > >
> > > p0_10.j2k is on
gt;mastering), 0)) {
> + (uint8_t *)descriptor-
> >mastering, descriptor->mastering_size, 0)) {
> ret = AVERROR(ENOMEM);
> goto fail_and_free;
> }
Looks OK
/Tomas
___
mån 2024-07-01 klockan 16:51 +0200 skrev Anton Khirnov:
> Quoting Tomas Härdin (2024-04-16 16:12:13)
> > tis 2024-04-16 klockan 09:52 -0300 skrev James Almer:
> > > On Tue, Apr 16, 2024 at 9:38 AM Anton Khirnov
> > > wrote:
> > >
> > > > Quoting T
c->bypp = 4;
> break;
> - default:
> - av_log(avctx, AV_LOG_INFO, "unsupported pixel format\n");
> - return AVERROR(EINVAL);
Sounds OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.o
gnalling ffmpeg to
create a remap filter is a good idea, I don't know whether we have any
mechanism for that at the moment. If we don't then perhaps that
shouldn't hold up this patch?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
size * channel + sample_index];
> + }
why not memcpy()? Should get inlined by any decent compiler I think
/Tomas
___
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".
_index];
> +}
What I meant with my previous comment on this is that the innermost
loop can be replaced with memcpy(), making the code simpler.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/f
*s, AVPacket *pkt)
> if (!mxf->edit_unit_byte_count &&
> (!mxf->edit_units_count || mxf->edit_units_count >
> EDIT_UNITS_PER_BODY) &&
> !(ie.flags & 0x33)) { // I-frame, GOP start
> -
omp, float d)
> +{
> + char value[128];
> + snprintf(value, sizeof(value), "%f", d);
> + if (comp) {
> + char key2[128];
> + snprintf(key2, sizeof(key2), "%s%c", key, comp);
> + av_dict_set(metadata, key2, value, 0);
> + }
fre 2021-10-29 klockan 15:33 +0200 skrev Paul B Mahol:
> On Fri, Oct 29, 2021 at 3:12 PM Tomas Härdin
> wrote:
> >
> > > +static double get_hx(const uint8_t *src, int linesize, int w,
> > > int h)
> > > +{
> > > + int64_t sum
fre 2021-10-29 klockan 17:00 +0200 skrev Paul B Mahol:
> On Fri, Oct 29, 2021 at 4:46 PM Tomas Härdin
> wrote:
>
> > fre 2021-10-29 klockan 15:33 +0200 skrev Paul B Mahol:
> > > On Fri, Oct 29, 2021 at 3:12 PM Tomas Härdin
> > > wrote:
> > > >
>
fre 2021-10-29 klockan 19:17 +0200 skrev Paul B Mahol:
> On Fri, Oct 29, 2021 at 6:59 PM Tomas Härdin
> wrote:
>
> > fre 2021-10-29 klockan 17:00 +0200 skrev Paul B Mahol:
> > > On Fri, Oct 29, 2021 at 4:46 PM Tomas Härdin
> > > wrote:
> > >
> &
fre 2021-10-29 klockan 19:43 +0200 skrev Paul B Mahol:
> On Fri, Oct 29, 2021 at 7:26 PM Tomas Härdin
> wrote:
>
> > fre 2021-10-29 klockan 19:17 +0200 skrev Paul B Mahol:
> > > On Fri, Oct 29, 2021 at 6:59 PM Tomas Härdin
> > > wrote:
> > >
> &
fre 2021-10-29 klockan 21:17 -0400 skrev Ronald S. Bultje:
> Hi Thomas,
>
> On Fri, Oct 29, 2021 at 9:12 AM Tomas Härdin
> wrote:
>
> > tor 2021-10-28 klockan 21:09 +0200 skrev Paul B Mahol:
> > > + const uint16_t *src = (const uint16_t *)ssrc;
> >
&g
lör 2021-10-30 klockan 10:28 -0400 skrev Ronald S. Bultje:
> Hi,
>
> On Sat, Oct 30, 2021 at 4:57 AM Tomas Härdin
> wrote:
>
> > Maybe we should upgrade to C11 then? This gives us access to more
> > useful language features. Type-generic expressions look
ling here
I don't see anything else that needs fixing, except maybe splitting the
actual reordering into a separate patch as (IIRC) Marton wants
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpe
->channels, and if not, then similarly, warn the user and
> break
> out.
>
> Maybe a hard failure (returning AVERROR_INVALIDDATA) is not
> necessary, to
> allow some slightly invalid metadata?
We should be as strict as we can get away with. Else we encourage
laxness in other i
tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> The mxf and mxf_opatom muxer expect H.264 in Annex B format.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The check here is taken from mpegtsenc.
You didn't think to make both muxers share code instead of co
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Also covers writing mastering display metadata.
So you're merging the D-10 user comments test and ProRes remuxing? What
about remuxing D-10?
/Tomas
___
ffmpeg-devel mailing lis
t profile;
> uint8_t interlaced;
> - int intra_only; // 1 or 0 when there are separate UIDs for Long
> GOP and Intra, -1 when Intra/LGOP detection can be ignored
> + int8_t intra_only; // 1 or 0 when there are separate UIDs for
Looks OK, and should work
xt *s)
> uint8_t present[FF_ARRAY_ELEMS(mxf_essence_container_uls)] =
> {0};
> int64_t timestamp = 0;
>
> - if (!s->nb_streams)
> - return -1;
Looks OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
uld write *some* output if we really wanted to, like the header
partition key and klv fill. Not very useful however.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
alue for mxf_write_packet() I think. But then the other
parsing functions should change at the same time. So let's not hold
this patch up with that. Looks OK for now.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
ooks OK of course
/Tomas
___
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".
> av_freep(&mxf->index_entries);
> av_freep(&mxf->body_partition_offset);
> - if (mxf->timecode_track) {
> - av_freep(&mxf->timecode_track->priv_data);
> - av_freep(&mxf->timecode_track);
> - }
&
av_mallocz(sizeof(UID) * 4 + 2 + 1);
> if (!p)
> return AVERROR(ENOMEM);
> snprintf(p, 2 + 1, "0x");
Could use strncpy() while you're at it.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
xhd_codec_uls[] = {
Not sure if the narrowing of types here does any good. You might need
to put cid and interlaced after codec_ul. On the other hand UID is
uint8_t[] so perhaps it works out.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
tis 2021-11-09 klockan 22:48 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> > > It is just a flag per supported CID. So there is no reason to use
> > > an avpriv function for this purpose.
> &
tis 2021-11-09 klockan 22:07 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> > > The mxf and mxf_opatom muxer expect H.264 in Annex B format.
> > >
> > > Signed-off-by: Andreas Rheinhardt
>
e = avpriv_dnxhd_get_frame_size(cid)) ==
> DNXHD_VARIABLE) {
> - frame_size = avpriv_dnxhd_get_hr_frame_size(cid, st-
> >codecpar->width, st->codecpar->height);
> - }
> - if (frame_size < 0)
> - return 0;
Looks simple enough. Might want
> h264_mp4toannexb.
> +# FIXME: The timestamps of the demuxed file are not properly
> reordered.
> +# Furthermore the extradata is wrong: It is one of the AVC intra
> SPS/PPS;
> +# decoding only works due to in-band extradata.
Is this a problem with the samples or the code? Or both?
ons 2021-11-10 klockan 14:21 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 22:07 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> > > > > The mxf
ons 2021-11-10 klockan 14:52 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> > > These tests exhibit two bugs: Instead of using the in-band
> > > extradata
> > > the demuxer makes up some ext
,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01,0
x00,0x00 },
Please add a reference to the relevant SMPTE document in the comment,
or perhaps at the list of references at the start of the file
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
tis 2023-09-19 klockan 17:12 +0200 skrev Michael Riedl:
> MXF muxer requires rangecoder otherwise static linking fails.
>
> Signed-off-by: Michael Riedl
Pushed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
t;offset < mxf->run_in)
One stray space in there which of course can be fixed when pushing
Looks OK
/Tomas
___
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".
goto next;
> }
>
> if lt * d[2]) >> 14) + ((rt * d[3]) >> 14))
> != rm) {
> sum = UINT64_MAX;
> goto next;
> }
Looks like a massive hack. I'd prefer to form
On Wed, 2023-10-25 at 21:00 +0200, Paul B Mahol wrote:
> On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin wrote:
>
> >
> > > if (c) {
> > > e[0] = 1 << 14;
> > > e[1] = 0 << 14;
> > >
eight) {
> + av_log(s->avctx, AV_LOG_ERROR, "image offsets outside
> image");
> + return AVERROR_INVALIDDATA;
> + }
Probably OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/list
>
> +enum AVStreamGroupParamsType {
> + AV_STREAM_GROUP_PARAMS_NONE,
Maybe AV_STREAM_GROUP_PARAMS_NUM on the end?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
lör 2023-10-28 klockan 22:04 +0300 skrev Rémi Denis-Courmont:
> This is so that they can be loaded from assembler, rather than
> duplicated.
Is loading these constants via immediates slower than the indirect load
that the patchset does?
ons 2023-10-25 klockan 21:59 +0200 skrev Paul B Mahol:
> On Wed, Oct 25, 2023 at 9:03 PM Tomas Härdin wrote:
>
> > On Wed, 2023-10-25 at 21:00 +0200, Paul B Mahol wrote:
> > > On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin
> > > wrote:
> > >
ons 2023-10-25 klockan 16:40 -0300 skrev James Almer:
> On 10/25/2023 4:25 PM, Tomas Härdin wrote:
> > >
> > > +enum AVStreamGroupParamsType {
> > > + AV_STREAM_GROUP_PARAMS_NONE,
> >
> > Maybe AV_STREAM_GROUP_PARAMS_NUM on the end?
>
> For
Philip Langdale, Carl Eugen
> Hoyos
> - videotoolbox* Rick Kern, Aman Gupta
> + videotoolbox* Rick Kern, Aman Gupta, Zhao
> Zhili
Sounds good to me
/Tomas
___
ffmpeg-devel mailing lis
at they
have already given implicit permission to publish?
That said, this part strikes me as far more relevant wrt the GDPR:
> I patched the voting system to log all authorized voters in the
> future to prevent this situation in the future.
/Tomas
__
rack of which
WebRTC implementations this works with. Or maybe this is better handled
with an external project, testing which implementations interoperate?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
T
his at least means we get bug reports. But
there's no way to ensure old bugs don't resurface.
/Tomas
___
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".
tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> Whitespaces after semicolon breaks some servers
Which servers? If the spec allows whitespace then the onus is on them
to fix their implementations.
/Tomas
___
ffmpeg-devel mailing list
ffm
tis 2023-11-14 klockan 13:49 +0100 skrev Thilo Borgmann via ffmpeg-
devel:
> Am 14.11.23 um 10:28 schrieb Tomas Härdin:
> > lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf:
> > >
> > > You have been told, now, several times, that a list of email is a
tis 2023-11-14 klockan 18:51 +0200 skrev Rémi Denis-Courmont:
> Le tiistaina 14. marraskuuta 2023, 17.47.07 EET Tomas Härdin a écrit
> :
> > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > > Whitespaces after semicolon breaks some servers
> >
> >
tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya:
> On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote:
>
> > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > > Whitespaces after semicolon breaks some servers
> >
> > Which servers? If the spec a
tis 2023-11-14 klockan 18:46 +0200 skrev Rémi Denis-Courmont:
> Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit
> :
> > Ballots should be public IMO, secret voting is cowardice.
>
> The French (XIXth century) Empire used notoriously public ballots,
> an
tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
> This is meant to introduce functionality to handle QR codes.
Why?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
tor 2023-11-30 klockan 15:39 + skrev Cosmin Stejerean via ffmpeg-
devel:
>
> > On Nov 30, 2023, at 03:07, Tomas Härdin wrote:
> >
> > tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
> > > This is meant to introduce functionality to handle QR code
new library but now when reading it again I
> stumble over the word "side-by-side" which indicates that the two parts
> should not interact with each other.
You can include LGPL code in a proprietary library if you provide the
object files for the proprietary parts, such th
>width & 7) + j] = buf[avctx->width >> 3] >> (7 -
> j) & 1;
An extra pair of parenthesis around the right-hand side would be
prudent:
(buf[avctx->width >> 3] >> (7 - j)) & 1
/Tomas
___
ffmpeg-devel
minor fix: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`.
> Other bit depths saw this change in ced0d6c14d, but this instance was
> missed, presumably because of the #ifdef block.
I think it'd be best to split this off into its own patch, even if it's
trivial
/Tomas
1 - 100 of 1473 matches
Mail list logo
