On Thu, Oct 31, 2024 at 04:13:38PM -0300, James Almer wrote: > On 10/31/2024 3:34 PM, Michael Niedermayer wrote: > > On Tue, Oct 29, 2024 at 04:50:47PM -0300, James Almer wrote: > > > On 10/29/2024 4:29 PM, Michael Niedermayer wrote: > > > > On Tue, Oct 29, 2024 at 01:03:21PM +0100, Michael Niedermayer wrote: > > > > > On Fri, Oct 25, 2024 at 07:56:29PM -0300, James Almer wrote: > > > > > > On 10/25/2024 7:18 PM, Michael Niedermayer wrote: > > > > > > > On Wed, Oct 23, 2024 at 04:36:44PM -0300, James Almer wrote: > > > > > > > > Signed-off-by: James Almer <jamr...@gmail.com> > > > > > > > > --- > > > > > > > > libswscale/output.c | 37 > > > > > > > > +++++++++++++++--------- > > > > > > > > libswscale/utils.c | 4 +-- > > > > > > > > tests/ref/fate/filter-pixdesc-xv48be | 1 + > > > > > > > > tests/ref/fate/filter-pixdesc-xv48le | 1 + > > > > > > > > tests/ref/fate/filter-pixfmts-copy | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-crop | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-field | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-fieldorder | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-hflip | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-il | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-null | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-scale | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-transpose | 2 ++ > > > > > > > > tests/ref/fate/filter-pixfmts-vflip | 2 ++ > > > > > > > > 14 files changed, 48 insertions(+), 15 deletions(-) > > > > > > > > create mode 100644 tests/ref/fate/filter-pixdesc-xv48be > > > > > > > > create mode 100644 tests/ref/fate/filter-pixdesc-xv48le > > > > > > > > > > > > > > didnt apply cleanly so no test but LGTM > > > > > > > > > > > > > > thx > > > > > > > > > > > > It was Niklas recent renaming patch. You can try a rebased version > > > > > > in > > > > > > > > > > > https://github.com/jamrial/FFmpeg/commits/pixdesc/ > > > > > > > > > > thanks, that helped, swscale patches seem turning stale within the > > > > > 500ms > > > > > transit time to the ML > > > > > > > > > > the swscale changes in that branch look good > > > > > tests seems passing on mingw32/64 linux x86-32/64 and mips > > > > > > > > i had to leave before qemu arm tests finished and of course arm faild :) > > > > > > > > make fate-pixfmt-x2bgr10le fate-pixfmt-x2rgb10le -k > > > > TEST pixfmt-x2bgr10le > > > > --- src/tests/ref/fate/pixfmt-x2bgr10le 2024-10-29 20:26:42.011219228 > > > > +0100 > > > > +++ tests/data/fate/pixfmt-x2bgr10le 2024-10-29 20:28:11.519912980 > > > > +0100 > > > > @@ -1,2 +1,2 @@ > > > > -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2bgr10le.yuv > > > > +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2bgr10le.yuv > > > > 15206400 tests/data/pixfmt/x2bgr10le.yuv > > > > Test pixfmt-x2bgr10le failed. Look at > > > > tests/data/fate/pixfmt-x2bgr10le.err for details. > > > > make: *** [src/tests/Makefile:311: fate-pixfmt-x2bgr10le] Error 1 > > > > TEST pixfmt-x2rgb10le > > > > --- src/tests/ref/fate/pixfmt-x2rgb10le 2024-10-29 20:26:42.011219228 > > > > +0100 > > > > +++ tests/data/fate/pixfmt-x2rgb10le 2024-10-29 20:28:12.371919593 > > > > +0100 > > > > @@ -1,2 +1,2 @@ > > > > -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2rgb10le.yuv > > > > +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2rgb10le.yuv > > > > 15206400 tests/data/pixfmt/x2rgb10le.yuv > > > > Test pixfmt-x2rgb10le failed. Look at > > > > tests/data/fate/pixfmt-x2rgb10le.err for details. > > > > make: *** [src/tests/Makefile:311: fate-pixfmt-x2rgb10le] Error 1 > > > > > > > > thx > > > > > > That is a test from a patch i didn't push, so not a problem in git head at > > > least. > > > > > > Is that a BE arm machine? > > > > no > > > > > > > The only thing i can think about is the check in > > > swscale/output.c for AV_PIX_FMT_X2RGB10, which for that target would > > > become > > > AV_PIX_FMT_X2RGB10BE, and thus not trigger with this test. > > > This is IMO wrong because the yuv2packed* pointers are in turn set for > > > both > > > LE and BE. > > > > arm has some funny behavior with misaligned 32bit access > > that is IIRC, if you cast a uint8_t * to int * and it was not an address > > thats > > a multiple of 4 and derefernce you can get results that you dont expect > > IIRC. > > > > if that makes no sense then i dont know, but tell me and ill just > > retest > > I tried applying the patch adding this test and running it under gcc-ubsan > and it didn't complain about unaligned accesses, so i don't know what could > be happening if that target is not BE.
patch doesnt apply anymore but your pixdesc branch worked fine on arm thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
