This is the 64bit version of Chris Doty-Humphreys SFC64
Compared to the LCGs these produce much better quality numbers.
Compared to LFGs this needs less state. (our LFG has 224 byte
state for its 32bit version) this has 32byte state
Also the initialization for our LFG is slower.
This is also much
I'm afraid I can't tell, I checked the commits before creating patches out of
them; they did not appear to have superfluous whitespace in them.
-- Original Message --
>From "Michael Niedermayer"
>mailto:mich...@niedermayer.cc>>
To "FFmpeg development discussions and patches"
Here are the two STR files I have used when writing this patch:
https://github.com/aybe/FFmpeg-PSX-STR-tests
Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be
29.97)...
However, as the reversed-engineered docs in jpsxdec mentions, it is sort of
impossible to figure out
Sorry mate but I'm currently having a lot of trouble keeping in track with the
mailing list...
I thought emClient would be a savior but it isn't, it's buggy and confusing as
hell.
Have to check mailing list online, find mail in client so I can reply to it,
really boring!
Anyway... for the
On 13.01.2024 01:57, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the
Signed-off-by: Marth64
---
doc/codecs.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 6bdeb664e7..ca8c08a59f 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -766,7 +766,7 @@ Set rate-distortion optimal quantization.
@item
Signed-off-by: Marth64
---
libavutil/timecode.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavutil/timecode.h b/libavutil/timecode.h
index 060574a172..fe0fc83576 100644
--- a/libavutil/timecode.h
+++ b/libavutil/timecode.h
@@ -98,8 +98,8 @@ uint32_t
On 09.12.2023 06:23, Andreas Rheinhardt wrote:
Timo Rothenpieler:
On 08.12.2023 11:01, Andreas Rheinhardt wrote:
Timo Rothenpieler:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of
On Wed, Jan 03, 2024 at 09:03:32AM +0800, yinshiyou...@loongson.cn wrote:
> > -原始邮件-
> > 发件人: jinbo
> > 发送时间:2023-12-28 16:21:05 (星期四)
> > 收件人: ffmpeg-devel@ffmpeg.org
> > 抄送: yuanhecai
> > 主题: [FFmpeg-devel] [PATCH v3 7/7] avcodec/hevc: Add ff_hevc_idct_32x32_lasx
> > asm opt
> >
> >
On Fri, Jan 12, 2024 at 01:58:03PM +0200, Vladimir Petrov wrote:
> There is a typo at 'libavfilter/vsrc_testsrc.c' in
> 'colorchart_fill_picture()' regarding patch height when using
> colorchart test image source. With current default size 64x64 all is
> fine, but when move to any non-square patch
/*When it is not a planar arrangement, data[1] is empty,
and all the data is interleaved in data[0].
This can result in a segmentation fault when accessing data[ch] .*/
//So I delete the code below:
for (i = 0; i < frame->nb_samples; i++)
for (ch = 0; ch <
On Fri, Jan 12, 2024 at 09:26:03AM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> The only meaningful difference between choose_pix_fmts and the default
> code was the inclusion of an extra branch for `keep_pix_fmt` being true.
>
> However, in this case, we either:
> 1. Force the specific
On Fri, Jan 12, 2024 at 09:25:57AM +0100, Niklas Haas wrote:
> A continuation of my meta patchset on YUVJ removal. This series:
>
> - Fixes a few shortcomings in the YUV negotiation infrastructure, in
> particular around dealing with untagged frames
> - Adds explicit information about the color
On 1/12/24 21:07, Michael Niedermayer wrote:
On Wed, Jan 03, 2024 at 02:51:36PM +0200, Paul Orlyk wrote:
On 12/28/23 21:33, Michael Niedermayer wrote:
On Wed, Dec 27, 2023 at 03:44:09PM +0200, Paul Orlyk wrote:
mode field in Transport header can be sent in upper case so make string
comparison
On Wed, Jan 03, 2024 at 02:51:36PM +0200, Paul Orlyk wrote:
> On 12/28/23 21:33, Michael Niedermayer wrote:
> > On Wed, Dec 27, 2023 at 03:44:09PM +0200, Paul Orlyk wrote:
> > > mode field in Transport header can be sent in upper case so make string
> > > comparison case insensitive.
> > > Also,
It’s not a critical work. But for future contribution I will reference that
website to see what makes more sense to do. Thank you for letting me know!
On Fri, Jan 12, 2024 at 09:26 Marth64 wrote:
> I didn’t know about that website until now. Thanks
>
> On Fri, Jan 12, 2024 at 07:10 Paul B Mahol
As bwdif takes no account of horizontally adjacent pixels the same
code can be used on planes that have multiple components as is used
on single component planes. Update the filtering code to cope with
multi-component planes and add NV12 to the list of supported formats.
Signed-off-by: John Cox
I didn’t know about that website until now. Thanks
On Fri, Jan 12, 2024 at 07:10 Paul B Mahol wrote:
> http://coverage.ffmpeg.org/
>
> *Is this really needed? Does it improves coverage at all?*
>
> On Thu, Jan 11, 2024 at 11:02 PM Marth64 wrote:
>
>> Necessary samples to fate-samples/adx :
>>
http://coverage.ffmpeg.org/
*Is this really needed? Does it improves coverage at all?*
On Thu, Jan 11, 2024 at 11:02 PM Marth64 wrote:
> Necessary samples to fate-samples/adx :
> https://ufile.io/f/v306q
>
> Samples are re-encodes of luckynight from FATE suite.
>
There is a typo at 'libavfilter/vsrc_testsrc.c' in
'colorchart_fill_picture()' regarding patch height when using
colorchart test image source. With current default size 64x64 all is
fine, but when move to any non-square patch size, there is unexpected
behavior:
Test examples:
[Blackstripe on
From: Niklas Haas
These no longer exist.
---
libavutil/pixdesc.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index cf15d3d953..024aa2924d 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2981,8
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
JPEG range YUV inputs were tagged as YUVJ, which resulted in an
automatic conversion to PC range by default.
After YUVJ removal, we will
From: Niklas Haas
To convert between color spaces/ranges, if needed by the codec
properties. We momentarily duplicate the mjpeg strictness logic to also
enfoce full range. This duplication will be cleaned up in an upcoming
commit.
Due to avcodec_open2 being called after ofilter_bind_ost, we
From: Niklas Haas
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain
From: Niklas Haas
The only meaningful difference between choose_pix_fmts and the default
code was the inclusion of an extra branch for `keep_pix_fmt` being true.
However, in this case, we either:
1. Force the specific `ofp->format` that we inherited from
ofilter_bind_ost, or if no format was
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is passed.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're adding YUV range, we might as well add the
YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only
From: Niklas Haas
In addition to YUVJ pixfmts.
---
libavfilter/vf_tiltandshift.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_tiltandshift.c b/libavfilter/vf_tiltandshift.c
index 0b1a03e29e..dc30f4ff1b 100644
--- a/libavfilter/vf_tiltandshift.c
+++
From: Niklas Haas
Otherwise, passing an UNSPECIFIED frame to am MPEG-only filter graph
would trigger insertion of an unnecessary vf_scale filter, which would
perform a memcpy to convert between the two.
This is safe to do because unspecified YUV frames are already
universally assumed to be MPEG
From: Niklas Haas
Currently, this only affects untagged RGB/XYZ/Gray, which get forced to
their corresponding metadata before entering the filter graph. The main
justification for this change, however, is the planned ability to add
automatic promotion of unspecified yuv to mpeg range yuv.
A continuation of my meta patchset on YUVJ removal. This series:
- Fixes a few shortcomings in the YUV negotiation infrastructure, in
particular around dealing with untagged frames
- Adds explicit information about the color range support to every
single AVCodec
- Feeds this information back
32 matches
Mail list logo
