The SDK supports LowPower and non-LowPower modes, but some features are
available only under one of the two modes. Currently non-LowPower mode
is always chosen in FFmpeg if the mode is not set explicitly, which will
result in some SDK errors if a feature is unavailable under non-LowPower
mode. With
This takes the used values from ISO/IEC 13818-1 Table 2-45 and adds
them to the mpegts.h header. No functional changes.
Signed-off-by: Brad Hards
---
libavformat/mpegts.c| 16
libavformat/mpegts.h| 10 ++
libavformat/mpegtsenc.c | 6 +++---
3 files changed, 21 i
On Tue, 2020-09-29 at 16:21 +0100, Mark Thompson wrote:
> On 16/09/2020 07:44, Haihao Xiang wrote:
> > ${includedir}/mfx has been added to Cflags in libmfx.pc for the current
> > libmfx. We may add ${includedir}/mfx to the search path for olda
> > versions of libmfx so that we may include foo.h ins
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sheervideo.c | 343
1 file changed, 172 insertions(+), 171 deletions(-)
diff --git a/libavcodec/sheervideo.c b/libavcodec/sheervideo.c
index 3f9b299a1e..e1a203d361 100644
--- a/libavcodec/sheervideo.c
+++ b
Don't needlessly copy an array around; don't create a table with
default symbols; and use smaller types to save stack space: The longest
code here is 16 bits, so one can store the codes in this type.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sheervideo.c | 19 +++
1 file c
On Tue, 2020-09-29 at 16:09 +0100, Mark Thompson wrote:
> On 16/09/2020 07:44, Haihao Xiang wrote:
> > The oneAPI Video Processing Library (oneVPL) is a single interface for
> > encode, decode and video processing, the obsolete features in Intel
> > Media Software Development Kit are removed from o
They are no-ops.
Signed-off-by: James Almer
---
tools/target_dec_fuzzer.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 7bea736fcf..39d4bb5647 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -118,17 +11
Signed-off-by: James Almer
---
tools/target_dem_fuzzer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index eefb5c5fa3..10082993fe 100644
--- a/tools/target_dem_fuzzer.c
+++ b/tools/target_dem_fuzzer.c
@@ -105
Signed-off-by: James Almer
---
libavformat/options.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/libavformat/options.c b/libavformat/options.c
index 3160904fda..59e0389815 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -55,35 +5
Michael Niedermayer:
> On Thu, Oct 08, 2020 at 09:53:13PM +0200, Andreas Rheinhardt wrote:
>> Said escape code is only six bits long, so that one has at least 25 - 6
>> bits in the bitstream reader's cache after reading it; therefore the
>> whole following 18 bits (containing the actual code) are a
From: Chip Kerchner
---
libswscale/ppc/yuv2rgb_altivec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libswscale/ppc/yuv2rgb_altivec.c b/libswscale/ppc/yuv2rgb_altivec.c
index 536545293d..930ef6b98f 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_alt
---
libswscale/utils.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 9ca378bd3b..832c9f873c 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -864,6 +864,11 @@ static void fill_xyztables(struct SwsContext *c)
Fixes vf_scale outputting RGB AVFrames with limited range flagged
in case either input or output specifically sets the range.
This is the reverse of the logic utilized for RGB and PAL8 content
in sws_setColorspaceDetails.
---
libswscale/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
On 10/9/2020 7:43 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Allocate it only when it's needed.
>>
>> Fixes: OOM
>> Fixes:
>> 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz
On 10/9/2020 7:41 PM, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> James Almer:
>>> On 10/9/2020 1:36 PM, Michael Niedermayer wrote:
On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
> Allocate it only when needed, and instead of giving it a fixed initial
> size
>
Andreas Rheinhardt:
> James Almer:
>> On 10/9/2020 1:36 PM, Michael Niedermayer wrote:
>>> On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
Allocate it only when needed, and instead of giving it a fixed initial size
that's doubled on each realloc, ensure it's always big enough
James Almer:
> Allocate it only when it's needed.
>
> Fixes: OOM
> Fixes:
> 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: James Alme
On 10/9/2020 6:16 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 10/9/2020 1:36 PM, Michael Niedermayer wrote:
>>> On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
Allocate it only when needed, and instead of giving it a fixed initial size
that's doubled on each realloc, e
Michael Niedermayer:
> On Thu, Oct 08, 2020 at 09:53:12PM +0200, Andreas Rheinhardt wrote:
>> It can't because the corresponding trees don't have any loose ends.
>>
>> Removing the checks also removed an instance of av_log(NULL (with a
>> nonsense message) from the codebase.
>>
>> Signed-off-by: An
On 10/9/2020 6:57 PM, James Almer wrote:
> On 10/9/2020 6:55 PM, Michael Niedermayer wrote:
>> On Fri, Oct 09, 2020 at 03:04:30PM +0200, Anton Khirnov wrote:
>>> Specifically: pts_wrap_bits, first_dts, cur_dts.
>>> They are supposed to be private and are located in the private section
>>> of AVStre
On Fri, Oct 9, 2020 at 10:02 PM Michael Niedermayer
wrote:
>
> On Wed, Oct 07, 2020 at 09:27:20PM +0300, Jan Ekström wrote:
> > Fixes vf_scale outputting RGB AVFrames with limited range in
> > case either input or output specifically sets the range.
> >
> > Keeps the external interfaces the same,
On Fri, Oct 09, 2020 at 03:04:23PM +0200, Anton Khirnov wrote:
> Those are private fields, no reason to have them exposed in a public
> header.
> ---
> libavformat/avformat.h | 3 +--
> libavformat/internal.h | 4
> libavformat/mux.c | 12 ++--
> libavformat/utils.c| 14 +++
On 10/9/2020 6:55 PM, Michael Niedermayer wrote:
> On Fri, Oct 09, 2020 at 03:04:30PM +0200, Anton Khirnov wrote:
>> Specifically: pts_wrap_bits, first_dts, cur_dts.
>> They are supposed to be private and are located in the private section
>> of AVStream, but ffmpeg.c currently accesses them regard
On Fri, Oct 09, 2020 at 03:04:25PM +0200, Anton Khirnov wrote:
> Those are private fields, no reason to have them exposed in a public
> header.
> ---
> libavformat/avformat.h | 6 +-
> libavformat/internal.h | 5 +
> libavformat/mux.c | 18 +-
> libavformat/mxfenc.c
On Fri, Oct 09, 2020 at 03:04:30PM +0200, Anton Khirnov wrote:
> Specifically: pts_wrap_bits, first_dts, cur_dts.
> They are supposed to be private and are located in the private section
> of AVStream, but ffmpeg.c currently accesses them regardless. They
> should be moved to AVStreamInternal once
- Call srt_epoll_release() to avoid fd leak on libsrt_setup() error.
- Call srt_cleanup() on libsrt_open() failure.
- Fix return value and method on mode parsing failure.
Based on a patch by Nicolas Sugino .
Signed-off-by: Marton Balint
---
libavformat/libsrt.c | 21 ++---
1 fil
Allocate it only when it's needed.
Fixes: OOM
Fixes:
23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer
---
libavcodec/h2645_parse.
On Thu, Oct 08, 2020 at 09:53:12PM +0200, Andreas Rheinhardt wrote:
> It can't because the corresponding trees don't have any loose ends.
>
> Removing the checks also removed an instance of av_log(NULL (with a
> nonsense message) from the codebase.
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
On Thu, Oct 08, 2020 at 09:53:13PM +0200, Andreas Rheinhardt wrote:
> Said escape code is only six bits long, so that one has at least 25 - 6
> bits in the bitstream reader's cache after reading it; therefore the
> whole following 18 bits (containing the actual code) are already in the
> bitstream
James Almer:
> On 10/9/2020 1:36 PM, Michael Niedermayer wrote:
>> On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
>>> Allocate it only when needed, and instead of giving it a fixed initial size
>>> that's doubled on each realloc, ensure it's always big enough for the NAL
>>> currently
On 10/9/2020 1:36 PM, Michael Niedermayer wrote:
> On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
>> Allocate it only when needed, and instead of giving it a fixed initial size
>> that's doubled on each realloc, ensure it's always big enough for the NAL
>> currently being parsed.
>>
>
Signed-off-by: James Almer
---
fftools/cmdutils.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 88fdbeaf1e..ba25e5c884 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2302,7 +2302,8
I've been sitting on this for a couple of years now, and I figured I
should just send it out. This is what I believe is a conceptually
correct port of bwdif to cuda (modulo edge handling which is not done
in the same way because the conditional checks for edges are expensive
in cuda, but that's the
James Almer:
> Signed-off-by: James Almer
> ---
> fftools/cmdutils.c | 28 ++--
> 1 file changed, 6 insertions(+), 22 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 88fdbeaf1e..83989b8190 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmd
And deprecate the linked list based one.
Based on a patch by Josh de Kock.
Signed-off-by: James Almer
---
doc/APIchanges | 5 +
libavdevice/alldevices.c | 22 ++
libavdevice/avdevice.h | 36
libavdevice/version.h| 7
Signed-off-by: James Almer
---
fftools/cmdutils.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 88fdbeaf1e..83989b8190 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2302,7 +2302,8 @@ s
Signed-off-by: James Almer
---
libavdevice/alldevices.c | 76
libavdevice/avdevice.c | 46
2 files changed, 76 insertions(+), 46 deletions(-)
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index a6f68dd3bb..413
On Thu, 8 Oct 2020, Marton Balint wrote:
On Tue, 6 Oct 2020, Marton Balint wrote:
On Wed, 30 Sep 2020, Paul B Mahol wrote:
On Tue, Sep 29, 2020 at 11:10:21PM +0200, Marton Balint wrote:
This should increase the effectiveness of ffio_ensure_seekback by
reducing
the
number of buffer
On Wed, Oct 07, 2020 at 09:27:20PM +0300, Jan Ekström wrote:
> Fixes vf_scale outputting RGB AVFrames with limited range in
> case either input or output specifically sets the range.
>
> Keeps the external interfaces the same, but allows us to retrieve
> and set nonzero value for RGB. Additionally
Paul B Mahol:
> On Fri, Oct 09, 2020 at 04:36:27PM +0200, Andreas Rheinhardt wrote:
>> Anton Khirnov:
>>> Those are private fields, no reason to have them exposed in a public
>>> header.
>>> ---
>>> libavdevice/v4l2.c | 2 +-
>>
>> This is a problem: There is no requirement to update li
On Fri, Oct 09, 2020 at 04:36:27PM +0200, Andreas Rheinhardt wrote:
> Anton Khirnov:
> > Those are private fields, no reason to have them exposed in a public
> > header.
> > ---
> > libavdevice/v4l2.c | 2 +-
>
> This is a problem: There is no requirement to update libavdevice at the
>
On Fri, Oct 09, 2020 at 03:04:27PM +0200, Anton Khirnov wrote:
> This effectively reverts ae2cb9290ac and 52c5521877a.
> ---
> fftools/ffmpeg_opt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
breaks:
./ffmpeg -ss 2:16 -i ~/tickets/2687/Thailand-Wave.wmv last2sec-of-source.asf
wi
On Fri, Oct 09, 2020 at 08:13:24AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-10-06 00:15:06)
> > On Mon, Oct 05, 2020 at 10:26:24AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2020-10-03 20:23:02)
> > > > On Fri, Oct 02, 2020 at 08:03:28PM +0200, Anton Khirn
On Wed, Oct 7, 2020 at 9:27 PM Jan Ekström wrote:
>
> Fixes vf_scale outputting RGB AVFrames with limited range in
> case either input or output specifically sets the range.
>
> Keeps the external interfaces the same, but allows us to retrieve
> and set nonzero value for RGB. Additionally defines
On Thu, Oct 08, 2020 at 09:48:41PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: shift exponent -1 is negative
> > Fixes:
> > 26107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-5378790047612928
> >
> > Found-by: continuous fuzzing process
> > https://github.c
On Fri, Oct 09, 2020 at 10:37:20PM +0800, Steven Liu wrote:
>
>
> > 在 2020年10月9日，03:19，Michael Niedermayer 写道：
> >
> > Fixes: Timeout (too long -> 1ms)
> > Fixes:
> > 26108/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5653887668977664
> >
> > Found-by: continuous fuzzing process
> >
On Thu, Oct 08, 2020 at 10:25:11AM -0300, James Almer wrote:
> Allocate it only when needed, and instead of giving it a fixed initial size
> that's doubled on each realloc, ensure it's always big enough for the NAL
> currently being parsed.
>
> Fixes: OOM
> Fixes:
> 23817/clusterfuzz-testcase-min
From: ffmpeg-devel on behalf of Andreas
Rheinhardt
Sent: Friday, October 9, 2020 8:11 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/adts_header: add frame_length
field and avpriv function to parse AAC ADTS header
Nachiket Tara
Nachiket Tarate:
> @James Almer
>
> Kindly merge this patch if it looks fine.
>
Can we see the supposed applications first?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
@James Almer
Kindly merge this patch if it looks fine.
--
Thanks & Regards,
Nachiket Tarate
From: ffmpeg-devel on behalf of Nachiket
Tarate
Sent: Thursday, October 8, 2020 8:02 PM
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH] libavcodec/adts_h
> 在 2020年10月9日，03:19，Michael Niedermayer 写道：
>
> Fixes: Timeout (too long -> 1ms)
> Fixes:
> 26108/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5653887668977664
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by:
Anton Khirnov:
> Those are private fields, no reason to have them exposed in a public
> header.
> ---
> libavdevice/v4l2.c | 2 +-
This is a problem: There is no requirement to update libavdevice at the
same time as libavformat; one might use a newer version of libavformat
together wit
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 12 ++---
libavformat/dump.c | 3 ++-
libavformat/internal.h | 10 +++
libavformat/mpegts.c | 2 +-
libavformat/sbgdec.c |
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/asfdec_f.c| 2 +-
libavformat/avformat.h| 13 -
libavformat/avidec.c | 2 +-
libavformat/internal.h| 13 +
libavformat/matroskadec.c | 8
libavformat/mp
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 2 +-
libavformat/internal.h | 2 ++
libavformat/utils.c| 5 +++--
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index ef6d
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 29 -
libavformat/internal.h | 29 +
libavformat/mov.c | 12 ++--
libavformat/mp3dec.c | 8
libavformat/swfdec.
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 3 +--
libavformat/internal.h | 4
libavformat/mux.c | 12 ++--
libavformat/utils.c| 14 +++---
4 files changed, 18 insertions(+), 15 deletions(-)
diff --git a
This struct is for internal use of avformat_find_stream_info(), so it
should not be exposed in public headers. Keep a stub pointer in its
place to avoid changing AVStream layout, since e.g. ffmpeg.c accesses
some fields located after it (even though they are marked as private).
---
libavformat/avf
Those are private fields, no reason to have them exposed in a public
header.
---
libavdevice/v4l2.c | 2 +-
libavformat/aacdec.c | 2 +-
libavformat/aadec.c | 6 +-
libavformat/acm.c| 2 +-
libavformat/asfdec_f.c | 10 ++--
libavformat/av1dec.c
Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
---
libavformat/ape
This effectively reverts ae2cb9290ac and 52c5521877a.
---
fftools/ffmpeg_opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 19f719e3ff..a5c92bf461 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2215,7 +2
Specifically: pts_wrap_bits, first_dts, cur_dts.
They are supposed to be private and are located in the private section
of AVStream, but ffmpeg.c currently accesses them regardless. They
should be moved to AVStreamInternal once that bug is fixed.
Remove the marker for the private AVStream section,
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 6 +-
libavformat/internal.h | 5 +
libavformat/mux.c | 18 +-
libavformat/mxfenc.c | 10 +-
4 files changed, 20 insertions(+), 19 deletions(-)
diff -
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 3 ---
libavformat/internal.h | 3 +++
libavformat/mux.c | 16
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avf
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 12
libavformat/internal.h | 12
libavformat/mov.c | 4 ++--
libavformat/mxfdec.c | 2 +-
libavformat/utils.c| 14 +++---
5 files changed, 22 ins
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 4 ++--
libavformat/internal.h | 3 +++
libavformat/nutdec.c | 2 +-
libavformat/utils.c| 20 ++--
4 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 7 ---
libavformat/internal.h | 7 +++
libavformat/utils.c| 28 ++--
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavformat/avformat
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 11 ---
libavformat/internal.h | 11 +++
libavformat/mux.c | 6 +++---
libavformat/utils.c| 10 +-
4 files changed, 19 insertions(+), 19 deletions(-)
diff --
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 6 --
libavformat/internal.h | 6 ++
libavformat/utils.c| 18 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavformat/avformat.h b/libavfo
Those are private fields, no reason to have them exposed in a public
header.
---
libavformat/avformat.h | 22 --
libavformat/internal.h | 22 ++
libavformat/mpegts.c | 4 ++--
libavformat/utils.c| 38 +++---
4 files cha
On Fri, Oct 09, 2020 at 01:48:46PM +0100, Kieran O Leary wrote:
> On Fri, Oct 9, 2020 at 12:10 PM Paul B Mahol wrote:
>
> > On Fri, Oct 09, 2020 at 10:08:45AM +0100, Kieran O Leary wrote:
> > > Pinging as I think my comment got lost in the conversation, my main
> > concern
> > > is about the Prin
On Fri, Oct 9, 2020 at 12:10 PM Paul B Mahol wrote:
> On Fri, Oct 09, 2020 at 10:08:45AM +0100, Kieran O Leary wrote:
> > Pinging as I think my comment got lost in the conversation, my main
> concern
> > is about the Printing Density value aka 1,
>
> This patch is for encoder, not for decoder (we
On Fri, Oct 09, 2020 at 10:08:45AM +0100, Kieran O Leary wrote:
> Pinging as I think my comment got lost in the conversation, my main concern
> is about the Printing Density value aka 1,
This patch is for encoder, not for decoder (well decoder also need fixing but
later).
The meaning of 1 value
On Thu, Oct 08, 2020 at 09:33:35PM +0200, Michael Niedermayer wrote:
> On Wed, Oct 07, 2020 at 05:12:47PM +0200, Paul B Mahol wrote:
> > On Wed, Oct 07, 2020 at 04:45:56PM +0200, Michael Niedermayer wrote:
> > > On Tue, Oct 06, 2020 at 12:08:27PM +0200, Anton Khirnov wrote:
> > > > Quoting Paul B M
On Thu, Oct 08, 2020 at 22:02:02 +1100, Peter Ross wrote:
> Week nine or so of lockdown...
What, wait. I'm like week thirty or so. ;)
> OBJS-$(CONFIG_MPJPEG_DEMUXER)+= mpjpegdec.o
> OBJS-$(CONFIG_MPJPEG_MUXER) += mpjpeg.o
> OBJS-$(CONFIG_MPL2_DEMUXER) += m
Pinging as I think my comment got lost in the conversation, my main concern
is about the Printing Density value aka 1,
K
On Thu, Oct 8, 2020 at 10:25 AM Kieran O Leary
wrote:
> Woah, more amazing film preservation patches, thank you!
> From my uninformed reading of the code, does this only supp
76 matches
Mail list logo
