Some of the versions of Apple Clang produces a ton of the warnings
related to the missing nullablity specifiers on the existing codebase of
ffmpeg which significantly slows down the compilation becuase of the
produced output size (especially on CI as a part of external build systems
because they us
> On May 31, 2025, at 14:13, Martin Storsjö wrote:
>
> On Sat, 31 May 2025, Dmitriy Kovalenko wrote:
>
>> Correct. I meant dual issue
>> https://developer.arm.com/documentation/ddi0460/d/Cycle-Timings-and-Interlock-Behavior/Dual-issue
>
> D
the quoted message.
You can still use “>” to make a partial quote (hope it works lol)
Best regards,
Dmitriy Kovalenko
> On May 31, 2025, at 12:43, Christopher Snowhill wrote:
>
> by
> not allowing one to insert text into the middle of
Correct. I meant dual issue
https://developer.arm.com/documentation/ddi0460/d/Cycle-Timings-and-Interlock-Behavior/Dual-issue
Best regards,
Dmitriy Kovalenko
On May 31, 2025, at 12:32, Kieran Kunhya wrote:
On Sat, 31 May 2025, 10:17 Dmitriy Kovalenko,
mailto:dmtr.kovale...@outlook.com
This patch integrates so called double bufferring when we are loading
2 batch of elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
ich does detect such issues.
I managed to rewrite the function to avoid using any callee saved
registers. The only register I keep using is v7 which is not callee saved.
Dmitriy Kovalenko (2):
swscale: rgb_to_yuv neon optimizations
swscale: Neon rgb_to_yuv_half process 32 pixe
Great. I send another version with the reverted change for the asr register
change. What is the correct process to reply for the inline changes then?
Inline email answer or cover letter?
> On May 30, 2025, at 11:10, Martin Storsjö wrote:
>
> On Fri, 30 May 2025, Dmitriy Kovale
I'm sorry for the previous patch it seems to be something happening off with
the corrupted
patch got sent at the outlook step, I'll keep using send-email.
=== __every single__ inline comment response ===
> This is an unrelated change
Fixed and resolved
> The patch adds trailing whitespace here
=== Feedback response ===
> Also, with that fixed, this fails to properly back up and restore registers
> v8-v15; checkasm doesn't notice this on macOS, but on Linux and windows,
> checkasm has a call wrapper which does detect such issues.
I managed to rewrite the function to avoid using any ca
, Martin Storsjö wrote:
>
> On Thu, 29 May 2025, Dmitriy Kovalenko wrote:
>
>> I appreciate the review for both the commits. I did fix all the unrelated
>> changes and iterated in the new version, would appreciate the rearview.
>
> Don't top post.
>
> There a
This patch integrates so called double bufferring when we are loading
2 batch of elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
I appreciate the review for both the commits. I did fix all the unrelated
changes and iterated in the new version, would appreciate the rearview.
> On May 29, 2025, at 20:53, Martin Storsjö wrote:
>
> On Tue, 27 May 2025, Dmitriy Kovalenko wrote:
>
>> This particular s
This patch integrates so called double bufferring when we are loading
2 batch of elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
macos nor linux arm builds so why not to keep them?
Dmitriy Kovalenko (2):
swscale: rgb_to_yuv neon optimizations
swscale: Neon rgb_to_yuv_half process 32 pixels at a time
libswscale/aarch64/input.S | 212 +++--
1 file changed, 155 insertions(+), 57 deletions
This patches integrates so called double bufferring when we are loading
2 batch elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read e
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
Bumping on the review for this one
On 19/05/2025 21:50, Dmitriy Kovalenko wrote:
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the performance.
This particular set of changes is a small imp
Signed-off-by: Dmitriy Kovalenko
---
libswscale/aarch64/input.S | 166 +
1 file changed, 112 insertions(+), 54 deletions(-)
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
index c1c0adffc8..ee8eb24c14 100644
--- a/libswscale/aarch64/input.S
+
s case, so
finally no need to apply this patch.
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
other platforms
should be suffering from -Wredundant-decls as well (unless their libc
headers are very clean and don't contain duplicate decls).
So unless I miss something else, we should still apply this patch (as
fixing OS/2 libc headers won't happen any time soon).
--
Kind regard
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2016-04-21 00:05:57 +, Michael Niedermayer said:
On Thu, Apr 21, 2016 at 01:48:22AM +0300, Dmitriy Kuminov wrote:
you all want the same, a perfect solution
iam sure you can reach some consensus about what to do and work
together to do it.
Iam happy to apply whatever patch the OS/2
wish to change
my patch just to make your internal believer happy. What about "ups"
and "downs", well, it's just a matter of viewport, please don't be so
childish here.
A question to maintainers with commit rights: please clarify, what
should I do to have my
also be
separated but unfortunately I don't have any more time to work on these
patches (as it turns out - just to please you). You can modify it
yourself if you wish (and if you are fine with the fact that it will
keep our branches diverged) but please give me some credit in the
commit messa
res (if at all). And that's in general,
again. In case of FFmpeg, symlinks don't make any harm (at least you
didn't present any proof of that so far).
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH
___
ffmpeg-dev
decide what to do here, but I won't
accept symlink usage removal in our repositiries. I will, however,
accept your patch that will allow to go both ways (with the symlink
usage being the default choice if supported by the underlying IFS).
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitw
f it fails.
To that I agree, it's the best solution. Can you provide your
correction to this patch that prefrorms such a check in the "os/2" case
at least? I guess you use EMX bash/pdksh so you can test it right away.
--
Kind regards,
Dmitriy Kuminov
CPO
ver the failure in your
case (if I read it right). So I still think we should remove ln_s
redefinition via cp on OS/2 in FFmpeg. In case of a proper IFS (I have
JFS here but HPFS is also fine) symlinking src works like a charm
(performed a full build).
--
Kind regards,
Dmitriy Kuminov
CPO
a temporary solution, one may do this in their enviroment before
starting configure:
for v in PATH TEMP TMPDIR ; do
eval "export $v=\$(expr \"\$$v\" | tr '\\\' /)"
done
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH
___
s some time & disk space). And more over, symlinks work
well in most cases in a proper OS/2 environment these days. So I think
they should be generally enabled unless there is a specific case when
they introduce a real incompatibility. FFmpeg is not such a case.
--
Kind regards,
D
Yes of course
> On 3/31/16, Dmitriy wrote:
>> I create a special video. You can download it using the link
>>
>> https://drive.google.com/file/d/0B8rMLdq9Vq55QmwwcVJDVkZoM1E/view?usp=sharing
>>
>> Convert it to .apng format with
>> ffmpeg -i apng_test.a
I create a special video. You can download it using the link
https://drive.google.com/file/d/0B8rMLdq9Vq55QmwwcVJDVkZoM1E/view?usp=sharing
Convert it to .apng format with
ffmpeg -i apng_test.avi apng_test.apng
The result file will be empty.
___
ffmpeg
>> In come cases APNG encoder generate only static video.
>>
>> The errors are located in the apng_encode_frame function (pngenc.c file).
>>
>> The
>> av_frame_copy(diffFrame, s->last_frame);
>> and
>> av_frame_copy(diffFrame, s->last_frame);
>>
>> functions doesn't work if the image size was chang
me_copy(diffFrame, s->last_frame);
to restore image size before recovery diffFrame image.
--
С уважением,
Dmitriy mailto:diz...@mail.ru
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
37 matches
Mail list logo
