Memo to myself: It looks like it's possible to emulate ppc64le:

https://stackoverflow.com/questions/53259899/is-it-possible-to-run-vm-with-ppc64le-architecture-on-a-host-machine-with-x86-64

Hi Dmitri, good catch.
I'm sorry but I've missed your message.

Do you have access to ppc64el hardware via ssh or have you been able to virtualize it using kvm/qemu?

After some debugging I think it's an upstream bug in ffmpeg on ppc64el and I need to create some demo using ffmpeg from CLI.

Thank you for providing the generated mp4. Although the file is bigger (29.4kB vs. 12.1kB on AMD64), it shows some strange purple artifacts between blue and red.

I think it's okay. that the test fails in this case because obviously there is a problem while encoding, perhaps some POWER8 CPU architecture related bug...

I'll try to create a raw video and then to transcode it in a qemu VM on ppc64el and then perhaps file a bugreport against ffmpeg.

-- Andy

The problem reported in this bug report stroke again in version 2.1.1 of the video package, when compiled on a ppc64el system using ffmpeg 5 and g++ 13. The BIST for VideoWriter in the previous version (2.0.2) run correctly on ppc64el, but using ffmpeg 4 and g++ 11.

(BTW, please fix a typo in line 319 of inst/VideoWriter.m : “realtive” ⇒ “relative”.)

This is the relevant part of the build log:

[inst/VideoWriter.m]
>>>>> /<<PKGBUILDDIR>>/inst/VideoWriter.m
***** demo
 fn = fullfile (tempdir (), "sombrero.mp4");
 w = VideoWriter (fn);
 w.FrameRate = 50;
 open (w);
 z = sombrero ();
 hs = surf (z);
 axis manual
 nframes = 200;
 for ii = 1:nframes
   set (hs, "zdata", z * sin (2*pi*ii/nframes + pi/5));
   drawnow
   writeVideo (w, getframe (gcf));
 endfor
 close (w)
 printf ("Now run 'open %s' to read the video with your default video player or try 'demo VideoReader'!\n", fn);
***** test
 fn = fullfile (tempdir(), "rainbow.mp4");
 width = 200;
 height = 150;
 nframes = 120;
 p = permute (rainbow (width), [3 1 2]);
 raw_video = zeros (height, width, 3, nframes);
 w = VideoWriter (fn);
 for k=1:nframes
   ps = circshift (p, k * 6);
   img = uint8 (255 * repmat (ps, height, 1));
   raw_video (:, :, :, k) = img;
   writeVideo (w, img);
 endfor
 close (w)
 ## read video and compare
 clear -x raw_video fn
 r = VideoReader (fn);
 for k=1:size (raw_video, 4)
   img = readFrame (r);
   d = double (img) - raw_video(:,:,:,k);
   # FIXME: This write/read roundtrip check doesn't work well due to compression artifacts
   #        see also bug #58451 (https://savannah.gnu.org/bugs/?58451)
   #        what would be a better way?
   rel_err = sum (abs(d(:)))/numel(d)/255;
   warn_thres = 0.025;
   if (rel_err > warn_thres)
     warning ("The realtive deviation exceeds the given threshold (%.3f > %.3f).\n\
     Please inspect '%s' manually. You should see a horizontal rainbow running from left to right.", rel_err, warn_thres, fn);
   endif
   assert (rel_err < 2 * warn_thres)
 endfor
 close (r);
[swscaler @ 0x100115a7840] ALTIVEC: Color Space BGR24
warning: The realtive deviation exceeds the given threshold (0.148 > 0.025).
     Please inspect '/tmp/rainbow.mp4' manually. You should see a horizontal rainbow running from left to right.
warning: called from
    __test__ at line 29 column 6
    test at line 682 column 11
    /tmp/tmp.U4KNDwlVn4 at line 14 column 31

!!!!! test failed
assert (rel_err < 2 * warn_thres) failed
1 test, 0 passed, 0 known failure, 0 skipped

Hi Rafael, thank you for your report.

Have you tried to visually inspect /tmp/rainbow.mp4 and is it visually comparable to the desired result?

And do you have a better idea to implement checks rather than doing a encode/decode cycle? Perhaps I can switch to use a lossless/raw format or run thwo checks:
1.) Some lossless raw format (with low error threshold)
2.) mp4 container with H264/avc1 video codec (with higher threshold)

Other ideas welcome.

Do I have the chance to reproduce your test result on AMD64? Perhaps some qemu/kvm magic?

-- Andy

This is probably a resurrection of bug #58451. The ppc64el autobuilder for the Debian package octave-video (version 2.1.1) choked on the BIST in VideoWriter.m that writes/reads rainbow.mp4. The full log can be seen here and this is the relevant part:

***** test
 fn = fullfile (tempdir(), "rainbow.mp4");
 width = 200;
 height = 150;
 nframes = 120;
 p = permute (rainbow (width), [3 1 2]);
 raw_video = zeros (height, width, 3, nframes);
 w = VideoWriter (fn);
 for k=1:nframes
   ps = circshift (p, k * 6);
   img = uint8 (255 * repmat (ps, height, 1));
   raw_video (:, :, :, k) = img;
   writeVideo (w, img);
 endfor
 close (w)
 ## read video and compare
 clear -x raw_video fn
 r = VideoReader (fn);
 for k=1:size (raw_video, 4)
   img = readFrame (r);
   d = double (img) - raw_video(:,:,:,k);
   # FIXME: This write/read roundtrip check doesn't work well due to compression artifacts
   #        see also bug #58451 (https://savannah.gnu.org/bugs/?58451)
   #        what would be a better way?
   rel_err = sum (abs(d(:)))/numel(d)/255;
   warn_thres = 0.025;
   if (rel_err > warn_thres)
     warning ("The realtive deviation exceeds the given threshold (%.3f > %.3f).\n\
     Please inspect '%s' manually. You should see a horizontal rainbow running from left to right.", rel_err, warn_thres, fn);
   endif
   assert (rel_err < 2 * warn_thres)
 endfor
 close (r);
[swscaler @ 0x100115a7840] ALTIVEC: Color Space BGR24
warning: The realtive deviation exceeds the given threshold (0.148 > 0.025).
     Please inspect '/tmp/rainbow.mp4' manually. You should see a horizontal rainbow running from left to right.
warning: called from
    __test__ at line 29 column 6
    test at line 682 column 11
    /tmp/tmp.U4KNDwlVn4 at line 14 column 31

!!!!! test failed
assert (rel_err < 2 * warn_thres) failed