Fixes: out of array access
Fixes:
23888/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6021365974171648.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 15
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 1634f68..f8a54fc 100644
--- a/libavfilter/vf_showinfo.c
+++
If the framebuffer is a tiled layout, use the fbtile helper routines
to try and detile it into linear layout, if supported by fbtile.
It uses the format_modifier associated with the framebuffer to decide
whether to apply detiling or not and inturn which specific detiling
to apply.
If user is
Added logic to support detiling of framebuffer.
By default this is disabled. Only if requested by the user, the
logic will be triggered.
It uses the fbtile helper routines to do the detiling. Currently
32bit RGB pixel format based framebuffers are supported.
If the underlying hardware context
Add helper routines which can be used to detile tiled framebuffer
layouts into a linear layout, using the cpu.
Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
Newer Intel Tile-Yf tiled layouts.
Currently supported pixel format is 32bit RGB.
It also contains detile_generic
This adds a video filter called fbdetile, which allows the user
to detile framebuffer layout into a linear layout, if required.
It uses the fbtile helper routines to achieve the detiling.
This is useful, if
a) the user doesnt want to apply detiling when capturing some
content/framebuffer which
Have split my changes into 5 patches, so that the concerned people/team
can decide whether to apply a given patch or not.
P1/4) kmsgrab format_modifier patch is independent of other patches
P2/5) fbtile helper routines is indepdent of other patches, and is
used by my hwcontext_drm, hwdownload
If user doesnt specify a format_modifier explicitly, then use GetFB2
to identify the format_modifier of the framebuffer being grabbed.
---
Changelog | 1 +
libavdevice/kmsgrab.c | 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Changelog
Gautam Ramakrishnan (12020-07-04):
> > Minor: we could have FFBETWEEN() for that.
> I shall use this.
You would need to add it first, which is ok by me.
Note that (x >= a) && (x < b) can be written in a more efficient way:
(unsigned)x - a < (unsigned)b - a
> If I got you right, you
Nicolas George:
> gautamr...@gmail.com (12020-07-03):
>> From: Gautam Ramakrishnan
>>
>> This patch adds a pgx decoder.
>
> Reviewing even after push, because there are problems to fix.
>
>> ---
>> Changelog | 1 +
>> doc/general.texi| 2 +
>> libavcodec/Makefile
gautamr...@gmail.com (12020-07-03):
> From: Gautam Ramakrishnan
>
> This patch adds a pgx decoder.
Reviewing even after push, because there are problems to fix.
> ---
> Changelog | 1 +
> doc/general.texi| 2 +
> libavcodec/Makefile | 1 +
>
On Sat, Jul 4, 2020 at 5:42 PM Nicolas George wrote:
>
> gautamr...@gmail.com (12020-07-03):
> > From: Gautam Ramakrishnan
> >
> > This patch adds a pgx decoder.
>
> Reviewing even after push, because there are problems to fix.
>
> > ---
> > Changelog | 1 +
> > doc/general.texi
This reduces the number of paths reachable with DNG and should
improve security
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index cb5e2a9b9b..e7a4e08c1c 100644
---
> On Jul 4, 2020, at 2:29 AM, Marton Balint wrote:
>
>
>
> On Sat, 27 Jun 2020, Zhao Zhili wrote:
>
>> This is a map from 'Macintosh Language Codes' to 'ISO639-2/T'. Some items
>> in the map were ISO639-2/B, some were ISO639-1.
>
> FFMpeg is using ISO639-2/B for language metadata according
Gautam Ramakrishnan (12020-07-04):
> I tried printing the values before writing them for a file which has
> signed values. The values seem fine.
Yes, but the computation relies on architecture- and undocumented
compiler-specific implementations details.
And there were other flaws. Michael pushed
This is just found by reading the code, I have not found a valid
file using this codepath so its untested.
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 2 +-
libavcodec/tiff.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c
On Sat, Jul 4, 2020 at 4:08 AM Nicolas George wrote:
>
> Michael Niedermayer (12020-07-03):
> > will apply patchset
>
> There were still significant problems with the code.
>
> In particular, the handling of the signed case seems suspicious.
I tried printing the values before writing them for a
From: Limin Wang
Or it'll cause null pointer dereference if size < sizeof(uint32_t), also
in case tc[0] > 3, the code will report error directly.
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Hi.
When I first started progressively to contribute do FFmpeg, the project
was far from mature, but it was very much alive.
There was attempts at implementing new and better codecs, directly in
lavc's code base. There were attempts at designing new formats with
useful features.
Even outside
On 7/4/20, Nicolas George wrote:
> Hi.
>
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
>
> There was attempts at implementing new and better codecs, directly in
> lavc's code base. There were attempts at designing new
On Sat, Jul 4, 2020 at 12:02 AM Michael Niedermayer
wrote:
>
> On Fri, Jul 03, 2020 at 01:05:12AM +0530, Gautam Ramakrishnan wrote:
> > On Thu, Jul 2, 2020 at 8:30 PM Michael Niedermayer
> > wrote:
> > >
> > > On Thu, Jul 02, 2020 at 12:04:22AM +0530, gautamr...@gmail.com wrote:
> > > > From:
On 7/4/20, James Almer wrote:
> On 7/4/2020 11:51 AM, Paul B Mahol wrote:
>> On 7/4/20, Nicolas George wrote:
>>> Hi.
>>>
>>> When I first started progressively to contribute do FFmpeg, the project
>>> was far from mature, but it was very much alive.
>>>
>>> There was attempts at implementing
---
libavformat/mov.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index df5bebdff1..da438e4e2c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6945,13 +6945,12 @@ static int mov_read_default(MOVContext *c,
Michael Niedermayer (12020-07-04):
> that would make the code less readable IMHO
In this particular very simple case maybe.
> the same is true for the use of a macro for write_frame_*
> it was IMHO more readable before the macro
Yes, each copy was slightly more readable than the merged macro.
NAK
Removed frame threading.
On 7/4/20, Kieran Kunhya wrote:
> $subj
>
> I have done basic fuzzing on it with no crashes.
> Fixes this sample:
> http://samples.mplayerhq.hu/V-codecs/CFHD/MT_BeartoothHighway_1min_Cineform.avi
>
> Kieran
>
___
Hi,
Why is bad and offensive language tolerated on this mailing list and on IRC?
Or it is not tolerated just for some persons?
On other hand I'm very free to state my opinions if they are stated in
non-offensive manner.
Clearly ones that uses offensive and bad language clearly show that
their
Kieran Kunhya (12020-07-04):
> > i do hope the planned technical committee will help with some of the
> > problems you discussed here.
> > But sometimes people are also rather rigid in discussions less interrested
> > to find a good compromise to move forward with and more interrested in
> >
On 7/4/20, Kieran Kunhya wrote:
> On Sat, Jul 4, 2020 at 7:10 PM Paul B Mahol wrote:
>> Why is bad and offensive language tolerated on this mailing list and on
>> IRC?
>> Or it is not tolerated just for some persons?
>>
>> On other hand I'm very free to state my opinions if they are stated in
>>
On Sun, Jul 5, 2020 at 12:00 AM Michael Niedermayer
wrote:
>
> On Sat, Jul 04, 2020 at 11:01:14PM +0530, Gautam Ramakrishnan wrote:
> > On Sat, Jul 4, 2020 at 12:02 AM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Jul 03, 2020 at 01:05:12AM +0530, Gautam Ramakrishnan wrote:
> > > > On Thu,
This bug was introduced in 3c8a2a1180f03ca6b299ebc27eef21ae86635ca0.
Signed-off-by: Andreas Rheinhardt
---
Sorry for this.
libavcodec/h264_metadata_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index
Zhao Zhili:
>
>
>> On Jul 4, 2020, at 11:32 PM, Andreas Rheinhardt
>> wrote:
>>
>> Zhao Zhili:
>>> ---
>>> libavformat/mov.c | 11 +--
>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>> index df5bebdff1..da438e4e2c 100644
On Sat, 4 Jul 2020 at 18:39, Paul B Mahol wrote:
> NAK
>
> Removed frame threading.
>
That is coming in another patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
From: Gautam Ramakrishnan
This patch enables support for image offsets.
---
libavcodec/jpeg2000dec.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index f62553c874..18a933077e 100644
--- a/libavcodec/jpeg2000dec.c
+++
On 7/4/2020 4:22 PM, Andreas Rheinhardt wrote:
> This bug was introduced in 3c8a2a1180f03ca6b299ebc27eef21ae86635ca0.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for this.
>
> libavcodec/h264_metadata_bsf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Sat, Jul 4, 2020, at 20:09, Paul B Mahol wrote:
> Why is bad and offensive language tolerated on this mailing list and on IRC?
It is not tolerated.
Whatever the reason.
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing
On Sat, Jul 04, 2020 at 02:12:01PM +0200, Nicolas George wrote:
> gautamr...@gmail.com (12020-07-03):
> > From: Gautam Ramakrishnan
> >
[...]
> > +static int pgx_get_number(AVCodecContext *avctx, GetByteContext *g, int
> > *number) {
> > +int ret = AVERROR_INVALIDDATA;
> > +char digit;
On Sat, Jul 04, 2020 at 03:32:31PM +0200, Nicolas George wrote:
> Gautam Ramakrishnan (12020-07-04):
> > > Minor: we could have FFBETWEEN() for that.
> > I shall use this.
>
> You would need to add it first, which is ok by me.
>
> Note that (x >= a) && (x < b) can be written in a more efficient
---
libavformat/mov.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index df5bebdff1..da438e4e2c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6945,13 +6945,12 @@ static int mov_read_default(MOVContext *c,
Verify that the source and destination pixformats are supported by
fbtile before detiling the source into destination.
NOTE: This patch is relative to my v06 patch set.
---
libavutil/hwcontext_drm.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git
Hi
On Sat, Jul 04, 2020 at 04:43:54PM +0200, Nicolas George wrote:
> Hi.
>
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
>
> There was attempts at implementing new and better codecs, directly in
> lavc's code base.
>
> i do hope the planned technical committee will help with some of the
> problems you discussed here.
> But sometimes people are also rather rigid in discussions less interrested
> to find a good compromise to move forward with and more interrested in
> "winning" a discussion. That is also not
On Sat, Jul 04, 2020 at 06:45:02PM +0200, Nicolas George wrote:
> Michael Niedermayer (12020-07-04):
[...]
> > > > +if (bytestream2_get_bytes_left() < width * height * (bpp >> 3))
> > > The multiplication can overflow.
> > ff_set_dimensions() should prevent this
>
> No, it should not, because
From: Gautam Ramakrishnan
This patch assigns default pix format values when
a match does not take place.
---
libavcodec/jpeg2000dec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 3f4a9ef96c..f62553c874 100644
---
Allows shifting of subtitle display times to align them with the video.
This avoids having to rewrite the subtitle file in order to display
subtitles correctly when input is seeked (-ss).
Also handy for minor subtitle timing corrections without rewriting the
subtitles file.
Signed-off-by: Manolis
> On Jul 4, 2020, at 11:32 PM, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> ---
>> libavformat/mov.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index df5bebdff1..da438e4e2c 100644
>> ---
On 7/4/2020 11:43 AM, Nicolas George wrote:
> Hi.
>
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
>
> There was attempts at implementing new and better codecs, directly in
> lavc's code base. There were attempts at
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Saturday, July 4, 2020 5:37 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Project orientation
>
> Another thing worth mentioning is a lack of new blood. Despite participating
> in GSoC for a
On Sat, Jul 4, 2020, at 16:51, Paul B Mahol wrote:
> > So, I ask one last time: What kind of project do you want FFmpeg to be?
>
> Certainly one where you are not part of it.
That is unnecessary.
"If you don't have something nice to say, or something constructive, don't say
anything at all."
On Sat, Jul 4, 2020, at 17:23, James Almer wrote:
> >> So, I ask one last time: What kind of project do you want FFmpeg to be?
> >
> > Certainly one where you are not part of it.
>
> Can you just fuck off already?
2 Wrongs don't make a right.
Insults are not welcome, whatever was said before.
On 7/4/2020 11:51 AM, Paul B Mahol wrote:
> On 7/4/20, Nicolas George wrote:
>> Hi.
>>
>> When I first started progressively to contribute do FFmpeg, the project
>> was far from mature, but it was very much alive.
>>
>> There was attempts at implementing new and better codecs, directly in
>>
Zhao Zhili:
> ---
> libavformat/mov.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index df5bebdff1..da438e4e2c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6945,13 +6945,12 @@ static int
On Wed, 01. Jul 11:30, Omar Emara wrote:
> This patch adds a select_region option to the xcbgrab input device.
> If set to 1, the user will be prompted to select the grabbing area
> graphically by clicking and dragging. A rectangle will be drawn to
> mark the grabbing area. A single click with no
On Mon, 29. Jun 09:26, Valery Kot wrote:
> On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman
> wrote:
> >
> > lgtm. I saw a small improvement when testing.
> >
> > Would be nice to allow weak edges that become strong to trigger neighboring
> > weak
> > edges in the future.
>
> Thanks for the
On Sat, 4 Jul 2020, Zhao Zhili wrote:
On Jul 4, 2020, at 2:29 AM, Marton Balint wrote:
On Sat, 27 Jun 2020, Zhao Zhili wrote:
This is a map from 'Macintosh Language Codes' to 'ISO639-2/T'. Some items
in the map were ISO639-2/B, some were ISO639-1.
FFMpeg is using ISO639-2/B for
On Sat, Jul 04, 2020 at 11:01:14PM +0530, Gautam Ramakrishnan wrote:
> On Sat, Jul 4, 2020 at 12:02 AM Michael Niedermayer
> wrote:
> >
> > On Fri, Jul 03, 2020 at 01:05:12AM +0530, Gautam Ramakrishnan wrote:
> > > On Thu, Jul 2, 2020 at 8:30 PM Michael Niedermayer
> > > wrote:
> > > >
> > > >
On 7/4/20, Kieran Kunhya wrote:
>> >> On other hand I'm very free to state my opinions if they are stated in
>> >> non-offensive manner.
>> >
>> > Like your "hitler" comment?
>>
>> hitler and pals had propaganda, I do not.
>> Ask yourself who holds propaganda for FFmpeg?
>
> Calling someone
> Probably a good idea to check the success of this function (and log error).
> Otherwise, xcb_wait_for_event() will just block and you can't send an
> interrupt
> with ctrl-c because of xcb_grab_server() below.
Can you elaborate? I am not entirely familiar with how logging works.
Should I pass
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 19
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_chromanr.c | 211 ++
4 files changed, 232 insertions(+)
create mode 100644 libavfilter/vf_chromanr.c
On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
> Another area as we are already on the subject is stuff falling a little
> outside what FFmpeg covers.
> Not every filter that anyone wants to write should have to be in FFmpeg
Thank $deity that you are saying this!
FFmpeg is used more
On Sat, Jul 4, 2020 at 7:10 PM Paul B Mahol wrote:
> Why is bad and offensive language tolerated on this mailing list and on IRC?
> Or it is not tolerated just for some persons?
>
> On other hand I'm very free to state my opinions if they are stated in
> non-offensive manner.
Like your "hitler"
> >> On other hand I'm very free to state my opinions if they are stated in
> >> non-offensive manner.
> >
> > Like your "hitler" comment?
>
> hitler and pals had propaganda, I do not.
> Ask yourself who holds propaganda for FFmpeg?
Calling someone hitler is unacceptable. End of story.
Kieran
On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> On Mon, 29. Jun 09:26, Valery Kot wrote:
> > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman
> > wrote:
> > >
> > > lgtm. I saw a small improvement when testing.
> > >
> > > Would be nice to allow weak edges that become strong to
On Sat, Jul 4, 2020 at 11:08 PM Paul B Mahol wrote:
>
> On 7/4/20, Jean-Baptiste Kempf wrote:
> > On Sat, Jul 4, 2020, at 20:09, Paul B Mahol wrote:
> >> Why is bad and offensive language tolerated on this mailing list and on
> >> IRC?
> >
> > It is not tolerated.
> > Whatever the reason.
> >
>
Greetings.
Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
publicly exposed through /usr/include, has been changed thus:
--- avcodec.h 2020-06-11 11:45:16.0 +0200
+++ avcodec.h 2020-07-01 03:45:24.0 +0200
@@ -3370,6 +2334,24 @@ typedef struct AVCodecContext {
*
On 7/4/2020 7:54 PM, Jan Engelhardt wrote:
> Greetings.
>
>
> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
> publicly exposed through /usr/include, has been changed thus:
>
> --- avcodec.h 2020-06-11 11:45:16.0 +0200
> +++ avcodec.h 2020-07-01 03:45:24.0 +0200
>
Jul 4, 2020, 14:17 by hanish...@gmail.com:
> If user doesnt specify a format_modifier explicitly, then use GetFB2
> to identify the format_modifier of the framebuffer being grabbed.
> ---
> Changelog | 1 +
> libavdevice/kmsgrab.c | 22 +-
> 2 files changed, 22
On Wed, Jul 01, 2020 at 11:30:33 +0200, Omar Emara wrote:
> { "region_border", "Set the region border thickness.",
> OFFSET(region_border), AV_OPT_TYPE_INT, { .i64 = 3 }, 1, 128, D },
> +{ "select_region", "Select the grabbing region graphically using the
> pointer.",
On Sun, 05. Jul 09:37, lance.lmw...@gmail.com wrote:
> On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> > On Mon, 29. Jun 09:26, Valery Kot wrote:
> > > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman
> > > wrote:
> > > >
> > > > lgtm. I saw a small improvement when testing.
> > >
On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf wrote:
[...]
> At some point, the project needs to decide what is in and what is out, and
> since FFmpeg has numerous APIs, people can plug them externally. It's not a
> problem to say "No" to a feature, especially when, the number of
On 7/4/20, Jean-Baptiste Kempf wrote:
> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
>> Another area as we are already on the subject is stuff falling a little
>> outside what FFmpeg covers.
>> Not every filter that anyone wants to write should have to be in FFmpeg
>
> Thank $deity
On 7/4/20, Jean-Baptiste Kempf wrote:
> On Sat, Jul 4, 2020, at 20:09, Paul B Mahol wrote:
>> Why is bad and offensive language tolerated on this mailing list and on
>> IRC?
>
> It is not tolerated.
> Whatever the reason.
>
Truth is hidden somewhere else.
> --
> Jean-Baptiste Kempf - President
On Sun, Jul 5, 2020, at 00:06, Paul B Mahol wrote:
> > For example and in my opinion, I don't see why there is support in avformat
> > for things that are not standards, like AMQP/ZMQ, who are neither a
> > multimedia format nor a multimedia protocol.
> > In the same way, if you start to need
On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf wrote:
> [...]
> > At some point, the project needs to decide what is in and what is out, and
> > since FFmpeg has numerous APIs, people can plug them externally. It's not a
On Sat, Jul 4, 2020 at 7:41 PM Paul B Mahol wrote:
>
> On 7/4/20, Kieran Kunhya wrote:
> >> >> On other hand I'm very free to state my opinions if they are stated in
> >> >> non-offensive manner.
> >> >
> >> > Like your "hitler" comment?
> >>
> >> hitler and pals had propaganda, I do not.
> >>
Jul 4, 2020, 14:17 by hanish...@gmail.com:
> If the framebuffer is a tiled layout, use the fbtile helper routines
> to try and detile it into linear layout, if supported by fbtile.
>
> It uses the format_modifier associated with the framebuffer to decide
> whether to apply detiling or not and
On Sat, 04. Jul 21:20, Omar Emara wrote:
> > Probably a good idea to check the success of this function (and log error).
> > Otherwise, xcb_wait_for_event() will just block and you can't send an
> > interrupt
> > with ctrl-c because of xcb_grab_server() below.
>
> Can you elaborate? I am not
On Sun, Jul 05, 2020 at 12:54:53AM +0200, Jan Engelhardt wrote:
> Greetings.
>
>
> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
> publicly exposed through /usr/include, has been changed thus:
>
> --- avcodec.h 2020-06-11 11:45:16.0 +0200
> +++ avcodec.h 2020-07-01
Jul 4, 2020, 14:17 by hanish...@gmail.com:
> Add helper routines which can be used to detile tiled framebuffer
> layouts into a linear layout, using the cpu.
>
> Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
> Newer Intel Tile-Yf tiled layouts.
>
> Currently supported pixel
$subj
I have done basic fuzzing on it with no crashes.
Fixes this sample:
http://samples.mplayerhq.hu/V-codecs/CFHD/MT_BeartoothHighway_1min_Cineform.avi
Kieran
0001-lavc-cfhd-3d-transform-decoding-for-both-progressive.patch
Description: Binary data
Jul 4, 2020, 14:17 by hanish...@gmail.com:
> Added logic to support detiling of framebuffer.
>
> By default this is disabled. Only if requested by the user, the
> logic will be triggered.
>
> It uses the fbtile helper routines to do the detiling. Currently
> 32bit RGB pixel format based
Jul 4, 2020, 14:17 by hanish...@gmail.com:
> This adds a video filter called fbdetile, which allows the user
> to detile framebuffer layout into a linear layout, if required.
>
> It uses the fbtile helper routines to achieve the detiling.
>
> This is useful, if
>
> a) the user doesnt want to
Michael Niedermayer:
> On Sun, Jul 05, 2020 at 12:54:53AM +0200, Jan Engelhardt wrote:
>> Greetings.
>>
>>
>> Between ffmpeg-4.2.3 and ffmpeg-4.3, struct AVCodecContext,
>> publicly exposed through /usr/include, has been changed thus:
>>
>> --- avcodec.h 2020-06-11 11:45:16.0 +0200
>> +++
On 7/4/2020 2:28 PM, Kieran Kunhya wrote:
> $subj
>
> I have done basic fuzzing on it with no crashes.
> Fixes this sample:
> http://samples.mplayerhq.hu/V-codecs/CFHD/MT_BeartoothHighway_1min_Cineform.avi
>
> Kieran
[...]
> @@ -1064,6 +1446,6 @@ AVCodec ff_cfhd_decoder = {
> .init
Hi Lynne,
On Sun, 5 Jul, 2020, 00:53 Lynne, wrote:
> Jul 4, 2020, 14:17 by hanish...@gmail.com:
>
> > Add helper routines which can be used to detile tiled framebuffer
> > layouts into a linear layout, using the cpu.
> >
> > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
>
84 matches
Mail list logo
