On 2016/8/31 6:48, Mark Thompson wrote:
> On 30/08/16 09:00, Jun Zhao wrote:
>> v3 : fix sharpless mapping issue
>> v2 : fix filter support flag check logic issue
>
> Hi,
>
> A general remark to start: vf_scale_vaapi is named to be a scaling filter
> (i.e. it replaces vf_scale/swscale for AV_P
On 2016/8/31 6:48, Mark Thompson wrote:
> On 30/08/16 09:00, Jun Zhao wrote:
>> v3 : fix sharpless mapping issue
>> v2 : fix filter support flag check logic issue
>
> Hi,
>
> A general remark to start: vf_scale_vaapi is named to be a scaling filter
> (i.e. it replaces vf_scale/swscale for AV_P
On Sun, Sep 4, 2016, at 01:34 PM, Thomas Volkert wrote:
>
> If you like or don't like this idea, feel free to leave a comment here.
I know some guys who make shirts. I'll get a quote too.
Can you provide some images of what the shirts look like?
Lou
__
Hi,
On Sun, Sep 4, 2016 at 5:34 PM, Thomas Volkert wrote:
> Hi,
>
> Some guys at the VDD asked for FFmpeg T-shirts.
> I'd like to do a new T-shirt order. The shirts could be given to
> multimedia devs who stop at one of our next booths.
>
> My idea is to order 25 shirts:
>
> 1*S
> 5*M
> 10*L
> 7
Hi!
2016-09-05 0:17 GMT+02:00 Marton Balint :
> Filtering in ffmpeg is unfortunately forcing you to use channel
> layouts, even if you don't want to, even if you only want to say:
> this track has 2 channels, that stream track has 1 channels.
But can't this be fixed?
Carl Eugen
_
On Sun, 4 Sep 2016, Nicolas George wrote:
Le nonidi 19 fructidor, an CCXXIV, Marton Balint a écrit :
Some source files might have a mono track, and a stereo track. If I merge
these, the order will change, because mono is handled as center.
And this is completely correct. What would you want
Hi,
Some guys at the VDD asked for FFmpeg T-shirts.
I'd like to do a new T-shirt order. The shirts could be given to
multimedia devs who stop at one of our next booths.
My idea is to order 25 shirts:
1*S
5*M
10*L
7*XL
2*XXL
Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
On Sun, Sep 04, 2016 at 06:24:31PM +0200, Stefano Sabatini wrote:
> This is meant to slightly reduce the output size.
> ---
> ffprobe.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Mo
On Sun, Sep 04, 2016 at 06:24:37PM +0200, Stefano Sabatini wrote:
> From: Nicolas George
>
> With several modifications and documentation by Stefano Sabatini
> .
>
> Signed-off-by: Nicolas George
> ---
> doc/ffprobe-format.texi | 130
> libavformat/Makefile | 1 +
> lib
On Sun, Sep 04, 2016 at 10:16:57PM +0200, Nicolas George wrote:
> Le nonidi 19 fructidor, an CCXXIV, Paul B Mahol a écrit :
> > And what would that cleaner implementation do?
>
> There is a rather simple implementation of format change in lavfi: have on
> each input a boolean flag "can_deal_with_f
On Sun, Sep 04, 2016 at 09:15:47PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5128.
>
> Please comment, Carl Eugen
> avpacket.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 0ddcbcddd2981c7ce86bf15943a1a4065a412b35
> 0001-lavc-avpacket-Fix-undefined
On Sun, Sep 04, 2016 at 10:05:03PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5809.
>
> Please comment, Carl Eugen
> avcodec.h |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 61bd44b05d7472493311c7f483ab03c0c74870a4
> 0001-lavc-avcodec-Improve-av_pa
On 9/4/16, Nicolas George wrote:
> Which is why I would like to be authorized to ignore this kind of hiccups.
> Format change does not currently work, this particular case used to work
> only by chance. Can I break it and repair it later?
I agree, format change in filtergraph, when works it works
Le nonidi 19 fructidor, an CCXXIV, Marton Balint a écrit :
> Some source files might have a mono track, and a stereo track. If I merge
> these, the order will change, because mono is handled as center.
And this is completely correct. What would you want instead?
Regards,
--
Nicolas George
s
Le nonidi 19 fructidor, an CCXXIV, Paul B Mahol a écrit :
> And what would that cleaner implementation do?
There is a rather simple implementation of format change in lavfi: have on
each input a boolean flag "can_deal_with_format_change". If a frame with a
different format arrives on a filter that
On Sun, 4 Sep 2016, Nicolas George wrote:
Le nonidi 19 fructidor, an CCXXIV, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
doc/filters.texi| 11 +++
libavfilter/af_amerge.c | 12
2 files changed, 15 insertions(+), 8 deletions(-)
Can you explain the u
Hi!
Attached patch fixes ticket #5809.
Please comment, Carl Eugen
From 377749b388637c09f8822e501e53c565e7d4cb94 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 4 Sep 2016 22:03:12 +0200
Subject: [PATCH] lavc/avcodec: Improve av_parser_parse() documentation,
mention padding.
Fixes ti
On 9/4/16, Nicolas George wrote:
> Le quintidi 15 fructidor, an CCXXIV, Michael Niedermayer a ecrit :
>> ./ffmpeg -i tickets//679/oversized_pgs_subtitles.mkv -filter_complex
>> '[0:s:1]scale=848x480,[0:v]overlay=shortest=1' test.avi
>> fails assertion:
>> Assertion progress failed at libavfilter/a
Le quintidi 15 fructidor, an CCXXIV, Michael Niedermayer a écrit :
> ./ffmpeg -i tickets//679/oversized_pgs_subtitles.mkv -filter_complex
> '[0:s:1]scale=848x480,[0:v]overlay=shortest=1' test.avi
> fails assertion:
> Assertion progress failed at libavfilter/avfilter.c:1391
>
> https://trac.ffmpeg
Hi!
2016-08-20 12:09 GMT+02:00 Timo Rothenpieler :
> On 8/19/2016 3:28 PM, Roger Pack wrote:
>> No complaints, would someone please push it for me? Sorry still
>> haven't figured out the key thing yet.
>
> pushed
Did this fix ticket #5775?
Carl Eugen
_
Le nonidi 19 fructidor, an CCXXIV, Marton Balint a écrit :
> Signed-off-by: Marton Balint
> ---
> doc/filters.texi| 11 +++
> libavfilter/af_amerge.c | 12
> 2 files changed, 15 insertions(+), 8 deletions(-)
Can you explain the use case?
Regards,
--
Nicolas Geor
Le nonidi 19 fructidor, an CCXXIV, Carl Eugen Hoyos a écrit :
> This site claims that ISO disagrees:
> http://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0
>
> (No opinion whatsoever here, just a ticket.)
I stand corrected.
Regards,
--
Nicolas George
Signed-off-by: Marton Balint
---
doc/filters.texi| 11 +++
libavfilter/af_amerge.c | 12
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c12b093..b1e3890 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@
2016-09-04 21:24 GMT+02:00 Nicolas George :
>> Subject: [PATCH] lavc/avpacket: Fix undefined behaviour,
>> do not pass a null pointer to memcpy().
>
> I read the spec for memcpy(), passing NULL is not stated as an
> undefined behaviour if the size if 0. UBSan seems to be
> reporting a false positiv
Le nonidi 19 fructidor, an CCXXIV, Carl Eugen Hoyos a écrit :
> From a3dcd65c313e6b456fcb05915508d8d583c1840e Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sun, 4 Sep 2016 21:11:02 +0200
> Subject: [PATCH] lavc/avpacket: Fix undefined behaviour, do not pass a null
> pointer to memcpy(
Hi!
Attached patch fixes ticket #5128.
Please comment, Carl Eugen
From a3dcd65c313e6b456fcb05915508d8d583c1840e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 4 Sep 2016 21:11:02 +0200
Subject: [PATCH] lavc/avpacket: Fix undefined behaviour, do not pass a null
pointer to memcpy().
Hi!
Some scanner - scannersoftware combination (HP_Officejet_Pro_X476dn_MFP
- sane) truncates trailing zeros in pbm files and FreeImage (a library
used in free and proprietary image software) reads such files.
Attached patch copies this behaviour and fixes ticket #5795.
Please comment, Carl Eug
Le nonidi 19 fructidor, an CCXXIV, Dave Rice a écrit :
> I’m not clear as to the reasoning for this, as the ordering of the
> elements doesn’t effect any of the meaing of the xml. However I wanted to
> note that such reordering would create invalid ffprobe xml. ffprobe.xsd
> defines the elements in
> On Sep 4, 2016, at 1:09 PM, Nicolas George wrote:
>
> Le nonidi 19 fructidor, an CCXXIV, Stefano Sabatini a écrit :
>> This is meant to be used for generating output suitable for the
>> ffprobe_default demuxer.
>> ---
>> ffprobe.c | 30 ++
>> 1 file changed, 26 inser
2016-09-04 20:18 GMT+02:00 Michael Niedermayer :
> On Sun, Sep 04, 2016 at 01:52:47PM +0200, Carl Eugen Hoyos wrote:
>> New patch attached, is "-idct simple" necessary?
>> Subject: [PATCH] fate: Add test for ticket #5805.
>
> LGTM
Patch applied.
Thank you, Carl Eugen
___
On Sun, Sep 04, 2016 at 01:52:47PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-04 13:44 GMT+02:00 Michael Niedermayer :
> > the test you submitted adds:
> > +fate-jpg-jfif: CMD = framecrc -idct simple -i
> > $(TARGET_SAMPLES)/jpg/12bpp.jpg
> >
> > that 12bpp sample is not eight bit
>
> Lol,
Hi,
On Sep 4, 2016 5:42 PM, "Timo Rothenpieler" wrote:
>
> On 9/4/2016 4:06 PM, Carl Eugen Hoyos wrote:
> > 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> >> The purpose of this patch is to make conversion from
> >> yuv420p (8 bit) to p010 (10 bit) fast.
> >
> > Do I understand you correctly th
Le nonidi 19 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> This is meant to be used for generating output suitable for the
> ffprobe_default demuxer.
> ---
> ffprobe.c | 30 ++
> 1 file changed, 26 insertions(+), 4 deletions(-)
I find the naming a bit clumsy. It s
Right now, if we attempt to use cuvid in a media player and then
try to seek, the decoder will happily pass out whatever frames were
already in flight before the seek.
There is both the output queue in our code and some number of frames
within the cuvid decoder that need to be accounted for.
cuvi
I've been investigating using cuvid for interactive playback, and even without
using CUDA->OpenGL interop, it's quite usable. This series includes two major
items:
* Declare decoders for the other formats that cuvid supports
* Implement flushing so that seeks in a player will work
Philip Langdale
cuvid/nvdecode also supports mpeg1, mpeg2, h.263/mpeg4-asp and mjpeg.
It should, in theory, also support wmv3 via the vc1 support, given
that vdpau supports this. However, it failed to play wmv3 samples
which vdpau played correctly, so I'm not sure what to make of it.
Signed-off-by: Philip Langda
Hi,
Sorry for the delay. Below some comments.
On Thu, 1 Sep 2016, Carlos Fernandez Sanz wrote:
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavformat/mpegts.c | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git
This is meant to be used for generating output suitable for the
ffprobe_default demuxer.
---
ffprobe.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/ffprobe.c b/ffprobe.c
index 657867d..42a8d8e 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -98,6 +9
This is meant to slightly reduce the output size.
---
ffprobe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ffprobe.c b/ffprobe.c
index 42a8d8e..f2c542a 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -99,6 +99,7 @@ static int use_byte_value_binary_prefix = 0;
static in
On date Sunday 2016-09-04 18:27:55 +0200, Paul B Mahol encoded:
> On 9/4/16, Stefano Sabatini wrote:
> > From: Nicolas George
> >
> > With several modifications and documentation by Stefano Sabatini
> > .
> >
> > Signed-off-by: Nicolas George
> > ---
> > doc/ffprobe-format.texi | 130 +
On 9/4/16, Stefano Sabatini wrote:
> From: Nicolas George
>
> With several modifications and documentation by Stefano Sabatini
> .
>
> Signed-off-by: Nicolas George
> ---
> doc/ffprobe-format.texi | 130
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 2 +
>
From: Nicolas George
With several modifications and documentation by Stefano Sabatini
.
Signed-off-by: Nicolas George
---
doc/ffprobe-format.texi | 130
libavformat/Makefile | 1 +
libavformat/allformats.c | 2 +
libavformat/ffprobedec.c | 397
On 9/4/2016 4:06 PM, Carl Eugen Hoyos wrote:
> 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
>> The purpose of this patch is to make conversion from
>> yuv420p (8 bit) to p010 (10 bit) fast.
>
> Do I understand you correctly that your patch is
> faster without the change I suggested?
With the &:
On 9/4/2016 3:01 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-04 14:55 GMT+02:00 Wilbert Dijkhof
> :
>> I hope this is the right place for this question. If not i hope you
>> can point me to a place where they can help us with further.
>
> No, libav-user (or ffmpeg-user) is the right place.
> Pl
Hi,
On Sep 4, 2016 5:33 PM, "Ronald S. Bultje" wrote:
>
> Hi,
>
> On Sun, Sep 4, 2016 at 10:06 AM, Carl Eugen Hoyos
> wrote:
>
> > 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> > > The purpose of this patch is to make conversion from
> > > yuv420p (8 bit) to p010 (10 bit) fast.
> >
> > Do I u
Hi,
On Sun, Sep 4, 2016 at 10:06 AM, Carl Eugen Hoyos
wrote:
> 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> > The purpose of this patch is to make conversion from
> > yuv420p (8 bit) to p010 (10 bit) fast.
>
> Do I understand you correctly that your patch is
> faster without the change I sug
On 9/3/16, Vittorio Giovara wrote:
> The filter needs input frames with color properties filled out by
> the decoder. Since this is not always possible, add input options to
> the filter so that user may override color space, color primaries,
> transfer characteristics, and color range, as well as
On Sep 4, 2016 5:02 PM, "Timo Rothenpieler" wrote:
>
> > Finally, with the change, the function can also be used
> > for P016, note that I tried to object to P010: It does not
> > serve any real purpose, if I remember correctly, the
> > explanation for the commit was that there is a bug in
> > FFm
2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> The purpose of this patch is to make conversion from
> yuv420p (8 bit) to p010 (10 bit) fast.
Do I understand you correctly that your patch is
faster without the change I suggested?
Carl Eugen
___
ffmpeg-
> Finally, with the change, the function can also be used
> for P016, note that I tried to object to P010: It does not
> serve any real purpose, if I remember correctly, the
> explanation for the commit was that there is a bug in
> FFmpeg's pix_fmt decision routine that needed to
> be worked-around
2016-09-04 15:42 GMT+02:00 Hendrik Leppkes :
> On Sun, Sep 4, 2016 at 1:18 PM, Carl Eugen Hoyos wrote:
>> 2016-09-04 13:10 GMT+02:00 Paul B Mahol :
>>> On 9/4/16, Carl Eugen Hoyos wrote:
2016-09-03 15:25 GMT+02:00 Timo Rothenpieler :
> +output_pixel(tdstY++, (t | (t << 8
On Sun, Sep 4, 2016 at 1:18 PM, Carl Eugen Hoyos wrote:
> 2016-09-04 13:10 GMT+02:00 Paul B Mahol :
>> On 9/4/16, Carl Eugen Hoyos wrote:
>>> 2016-09-03 15:25 GMT+02:00 Timo Rothenpieler :
>>>
+output_pixel(tdstY++, (t | (t << 8)) & 0xFFC0);
>>>
>>> Please remove the "& 0xFFC0" h
Hi!
2016-09-04 14:55 GMT+02:00 Wilbert Dijkhof
:
> I hope this is the right place for this question. If not i hope you
> can point me to a place where they can help us with further.
No, libav-user (or ffmpeg-user) is the right place.
Please tell us if this not clear on:
https://ffmpeg.org/contact
Hi all,
I hope this is the right place for this question. If not i hope you can point
me to a place where they can help us with further.
We have a question about the high bitdepth support (10/12/14 bitdepth) in
ffmpeg.To support those formats in AviSynth, we need to know whether the zero
padding
Hi!
2016-09-04 13:44 GMT+02:00 Michael Niedermayer :
> the test you submitted adds:
> +fate-jpg-jfif: CMD = framecrc -idct simple -i $(TARGET_SAMPLES)/jpg/12bpp.jpg
>
> that 12bpp sample is not eight bit
Lol, thanks for noticing!
New patch attached, is "-idct simple" necessary?
Carl Eugen
From
Hi!
2016-08-31 0:49 GMT+02:00 George Burgess IV :
> +++ b/libavfilter/avf_aphasemeter.c
> @@ -190,7 +190,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>
> metadata = avpriv_frame_get_metadatap(out);
> if (metadata) {
> -uint8_t value[128];
> +char value[
On Sun, Sep 04, 2016 at 01:33:01PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-04 13:27 GMT+02:00 Michael Niedermayer :
> >> >> >> >> Subject: [PATCH] fate: Add test for ticket #5805.
> >> >> >> >
> >> >> >> > fails on mips
> >> >> >>
> >> >> >> How can I fix this?
> >> >> >
> >> >> > see b6e8efb082c2
2016-09-04 13:27 GMT+02:00 Michael Niedermayer :
>> >> >> >> Subject: [PATCH] fate: Add test for ticket #5805.
>> >> >> >
>> >> >> > fails on mips
>> >> >>
>> >> >> How can I fix this?
>> >> >
>> >> > see b6e8efb082c284091e267a29b6060b97692d1740
>> >> > that _should_ work
>> >>
>> >> You mean "sets
On Sun, Sep 04, 2016 at 01:24:13PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-04 13:20 GMT+02:00 Michael Niedermayer :
> >> >> >> Subject: [PATCH] fate: Add test for ticket #5805.
> >> >> >
> >> >> > fails on mips
> >> >>
> >> >> How can I fix this?
> >> >
> >> > see b6e8efb082c284091e267a29
Hi!
2016-09-04 13:20 GMT+02:00 Michael Niedermayer :
>> >> >> Subject: [PATCH] fate: Add test for ticket #5805.
>> >> >
>> >> > fails on mips
>> >>
>> >> How can I fix this?
>> >
>> > see b6e8efb082c284091e267a29b6060b97692d1740
>> > that _should_ work
>>
>> You mean "setsar=sar=sar" makes the dif
On Sun, Sep 04, 2016 at 01:04:30PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-04 12:55 GMT+02:00 Michael Niedermayer :
> >> >> Subject: [PATCH] fate: Add test for ticket #5805.
> >> >
> >> > fails on mips
> >>
> >> How can I fix this?
> >
> > see b6e8efb082c284091e267a29b6060b97692d1740
> > that _sho
2016-09-04 13:10 GMT+02:00 Paul B Mahol :
> On 9/4/16, Carl Eugen Hoyos wrote:
>> 2016-09-03 15:25 GMT+02:00 Timo Rothenpieler :
>>
>>> +output_pixel(tdstY++, (t | (t << 8)) & 0xFFC0);
>>
>> Please remove the "& 0xFFC0" here and below.
>
> Please explain your reasoning here.
The linke
On Thu, Sep 01, 2016 at 03:03:18PM +0200, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> doc/filters.texi | 17 ++
> libavfilter/Makefile |1
> libavfilter/allfilters.c |1
> libavfilter/vf_gblur.c | 276
> +++
> 4 files ch
On 9/4/16, Carl Eugen Hoyos wrote:
> 2016-09-03 15:25 GMT+02:00 Timo Rothenpieler :
>
>> +output_pixel(tdstY++, (t | (t << 8)) & 0xFFC0);
>
> Please remove the "& 0xFFC0" here and below.
Please explain your reasoning here.
___
ffmpeg-devel m
2016-09-04 12:55 GMT+02:00 Michael Niedermayer :
>> >> Subject: [PATCH] fate: Add test for ticket #5805.
>> >
>> > fails on mips
>>
>> How can I fix this?
>
> see b6e8efb082c284091e267a29b6060b97692d1740
> that _should_ work
You mean "setsar=sar=sar" makes the difference?
Carl Eugen
_
On Sun, Sep 04, 2016 at 12:39:38PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-04 3:36 GMT+02:00 Michael Niedermayer :
> > On Sun, Sep 04, 2016 at 12:36:46AM +0200, Carl Eugen Hoyos wrote:
>
> >> Subject: [PATCH] fate: Add test for ticket #5805.
> >
> > fails on mips
>
> How can I fix this?
see b6e
2016-09-04 8:34 GMT+02:00 Jonathan Campbell :
> It looks like mpeg12enc.c though is lacking the code to
> read the A53_CC side data and put the caption data into
> the encoded frame. Mind if I write a patch to do that?
I am quite sure that a clean, working patch would be
very welcome!
Carl Eugen
2016-09-03 15:25 GMT+02:00 Timo Rothenpieler :
> +output_pixel(tdstY++, (t | (t << 8)) & 0xFFC0);
Please remove the "& 0xFFC0" here and below.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listin
2016-09-03 21:14 GMT+02:00 Philip Langdale :
> @@ -626,6 +631,7 @@ void avcodec_register_all(void)
> /* external libraries, that shouldn't be used by default if one of the
> * above is available */
> REGISTER_ENCDEC (LIBOPENH264, libopenh264);
> +REGISTER_DECODER(H263_CUV
2016-09-04 3:36 GMT+02:00 Michael Niedermayer :
> On Sun, Sep 04, 2016 at 12:36:46AM +0200, Carl Eugen Hoyos wrote:
>> Subject: [PATCH] fate: Add test for ticket #5805.
>
> fails on mips
How can I fix this?
Carl Eugen
___
ffmpeg-devel mailing list
ffmp
On Wed, Oct 14, 2015 at 12:38:46AM +0200, Michael Niedermayer wrote:
> On Tue, Oct 13, 2015 at 09:21:41PM +0200, Christophe Gisquet wrote:
> > Allows testing simple_idct12 correctness/bitexactness, as the sample
> > was generated using faani as idct.
> > ---
> > tests/fate/image.mak | 6 ++
71 matches
Mail list logo
