Encoding H264 video on RISC OS using ffmpeg

There’s an updated version of ffmpeg (100965) available here.

It’s now possible to encode H264 video using ffmpeg. Needs alignment exceptions turned off.

See here for examples.

Using the defaults gets around 10fps depending on input format on a Rpi 400 @2.4GHz.

ffmpeg -i input output.mkv

H264 was possible with Christopher Martins last alpha.
Have play around with both yesterdays evening…
Audio converting is round about 10x faster, video converting 3x faster with the new version.
Thank you very much.

Sorry, I have not seen. Is a new new version.
(100965) will not work for me. Gives a “elf wimpslot error”. Giving more wimpslot in ffmpeg !Boot will not work.
The new version before (100647?) works without problems.

The !Boot file needs the Wimpslot increasing to 37200k.

Set Alias$ffmpeg WimpSlot -min 37200k|MRun <FFmpeg$Dir>.ffmpeg %%*0

I wondering. Have you try? ;-)
I use your download without changes. The older one is working, the newer one not (today morning).
I mean !Boot has the same content on both, same in your post.
Have give a double sized wimpslot for the newer one. Same error message.
Can give a second try not before tomorrow morning, sorry.

This is the output you should see when you run ffmpeg in a task window,

*ffmpeg
ffmpeg version N-100965-g89e2fbceee Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 8.2.0 (GCCSDK GCC 8.2.0)
  configuration: --extra-cflags=-I/linux4/gccsdkeabi2/env/include --extra-ldflags='-static -L/linux4/gccsdkeabi2/env/lib -logg -lvorbis -lhogweed -lz -lpng -lbz2 -lm -lexpat -lxml2 -llzma -ldl -lglib-2.0 -lintl -lexpat -ltasn1 -lnettle -lgmp' --enable-cross-compile --prefix=/linux4/gccsdkeabi2/env --host-cc=/usr/bin/gcc --disable-shared --enable-static --disable-pic --arch=arm --target-os=linux --enable-muxers --enable-gnutls --disable-linux-perf --enable-encoders --disable-devices --disable-ffprobe --disable-ffplay --disable-sdl2 --enable-network --enable-libzvbi --enable-libx264 --enable-libvpx --disable-libxvid --enable-libvorbis --enable-libtwolame --enable-libopus --enable-libwebp --enable-libxml2 --enable-libfreetype --enable-libfontconfig --enable-libmp3lame --enable-libcdio --enable-ffmpeg --enable-libass --disable-doc --enable-postproc --enable-gpl --enable-protocol='http,https' --enable-pthreads --enable-runtime-cpudetect --enable-armv5te --enable-vfp --enable-armv6 --enable-armv6t2 --enable-vfpv3 --enable-neon --disable-thumb --enable-hardcoded-tables --disable-debug --disable-stripping --pkg-config=/linux4/gccsdkeabi2/env/ro-pkg-config --cross-prefix=/linux4/gccsdkeabi/env/bin/arm-riscos-gnueabihf-
  libavutil      56. 64.100 / 56. 64.100
  libavcodec     58.120.100 / 58.120.100
  libavformat    58. 66.100 / 58. 66.100
  libavdevice    58. 11.103 / 58. 11.103
  libavfilter     7.102.100 /  7.102.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

[0;33mUse -h to get full help or, even better, run 'man ffmpeg'
[0m*

Todays download is working now. Anyone has changed !Boot inside ;-)
Not sure why my “wimpslot fix” was not working. Maybe I forget a doubleclick after…
Thanks a lot.

I’m never satisfied ;-)
Is there a lame available with a comparable speed up?

Is there a lame available with a comparable speed up?

Both lame 3.100 and sox 14.4.2 have been added to https://www.riscosports.co.uk/eabi.

lame, sox and ffmpeg will all convert wav to mp3 at about the same speed. Up to 22x real time on a RPi 400 @2.4GHz.

Thanks a lot.
Lame: Short try. With my settings 12x real time on Ti but will not work with MusicMan. I have to try a bit more next few days.
SoX: Is it usable as a player? play … infile … like I read (Synopsis) is not working but works in Linux.

SoX: Is it usable as a player? play … infile … like I read (Synopsis) is not working but works in Linux.

To play back a file just add ‘-t oss’,

sox track.wav -t oss

Thanks a lot. Now I hav seen in the manual.

*sox track.mp3 -q -t oss

Is working well.

Senseless comparison.
Nobody seriously compares tools used on a Pentium 1 with the same on i5.

Sorry, I not see the comparison to the old version… ;-)
As I wrote…
The version I use before was Christophers Iyonix Version.
Chris new one I try with the same jobs was 10x faster with audio and 3x faster with video on all machines I try.

Have a working Pandora Classic (OMAP3+600MHz) and a Pi1A as the slowest RISC OS 5 machines.
What do you mean with lower resolution. What should I try.

Short try…

Audio
Test.mpa Time: 00:03:38.31 = 218.31s
ffmpeg -i Test.mpa -q:a 3 -c:a libmp3lame -loglevel error Test.mp3

Video
Track: 30fps ; Time: 00:03:38.31 = 218.31s

Video 1
ffmpeg -i Test.mp4 -qscale 5 -c:v mpeg2video -loglevel error Test.mpg
Video 2
ffmpeg -i Test.mpg -qscale 5 -c:v libx264 -loglevel error Test2.mp4
Video 3
ffmpeg -i Test.mp4 -vf scale=320:-1 -qscale 5 -c:v mpeg2video -loglevel error Test_kl.mpg
Video 4
ffmpeg -i Test.mpg -vf scale=160:-1 -qscale 5 -c:v libx264 -loglevel error Test_kl.mp4

Reference: ffmpeg 3.0 “Iyonix optimized” on Titanium
Audio
201s —> 1,1x
Video 1
199s —> 1,1x
Video 2
421s —> 0,5x (-c:v mpeg4)
Video 3
153s —> 1,4x
Video 4
349s —> 0,6x (-c:v mpeg4)

Latest ffmpeg
Titanium
Audio
16s —> 13,6x
Video 1
96s —> 2,3x
Video 2
85s —> 2,6x
Video 3
65s —> 3,4x
Video 4
45s —> 4,9x

ARMX6
Audio
35s —> 6,2x
Video 1
231s —> 0,9x
Video 2
200s —> 1,1x
Video 3
265s —> 0,8x (24fps)
Video 4
111s —> 1,9x

Pi4 (1,5Ghz)
Audio
13s —> 17x
Video 1
80s —> 2,7x
Video 2
405s —> 0,5x
Video 3
58s —> 3,8x
Video 4
69s —> 3,2x

I wondering about any results but try again was the same.
Older Pi and Pandora will follow.

Looking at the relative performance of the Titanium, ARMx6 and Pi4, the ratios are as I’d expect, except for Video 2 on the Pi4 which is about 4x slower than the rest. Might be worth re-running that one to check.

Video2 was the point I wondering. All tests I do 3×.
The results are the same (+/-5s). Is the codec the reason, should also Video4 slower.
I will try with -loglevel verbose to I get any infos.

All three systems can run Linux, so it would be very interesting to see the comparison with RISC OS on the same hardware.

I will try with -loglevel verbose to I get any infos.

Part of the “verbose output” … speed=0.531x … fps= 16
Not sure why :-(

All three systems can run Linux, so it would be very interesting to see the comparison with RISC OS on the same hardware.

Never on ARMX6 …

Pi4 Linux (1,5Ghz)
Audio
12s —> 18.2x
Video 1
44s —> 4.9x
Video 2
115s —> 1.9x
Video 3
38s —> 5,8x
Video 4
34s —> 6.4x

Titanium Linux
Audio
15s —> 14,1x
Video 1
91s —> 2,4x
Video 2
242s —> 0.9x
Video 3
78s —> 2,8x
Video 4
70s —> 3.1x

And now? Video encoding is a “Miracle Bag” (? “Wundertüte”) ;-)
Change one option and…

Looks to me as if ffmpeg might be using hardware acceleration on the Pi4 under Linux but not RISC OS. But on the Titanium it looks like the last 3 tests are running far less optimally under Linux than RISC OS.

Disc bandwidth limitations?

Disc bandwidth limitations?

Should not.
In RISC OS I use RAMDisc for all Tests.
Ti Linux root is placed on a fast SATA SSD.
Pi4 Linux runs from a fast Samsung Evo Card.

Is it possible (or a reason why not) to compile a ffmpeg version that works without alignment exceptions off?