Amffmpeg

I see amffmepg in the osmc source tree:

Is this available for install somehow?

See Ffmpeg not building on vero 4k - #3 by sam_nazarko.

Not trivial – quite messy (AMLogic)

Thanks Sam.

I wonder about a couple of things:

  • This amffmpeg is not being kept updated with upstream ffmpeg.
  • Probably needs some specific flag to enable hw accel.

Seeking some hw acceleration when transcoding for the likes of emby or plex. maybe not realistic at this point.

It’s just a shim to kernel drivers which do accel. There is nothing in ffmpeg doing it
per se.

This would not really matter. Although it is synced up every so often.

What is your use case for Vero 4K / what are you trying to get running?
affmpeg supports decoding but not transcoding. The SoC can do transcoding but it is intended to be a real time transcoder. A couple of observations:

  • file size output is usually larger than input
  • 30fps is the most you can get out of it at real time.

Well, just installed an emby server on Vero 4K. I have some h265 content and found out with surprise that chrome does not support h265 playback (might be only when there is no hardware acceleration on the browser device, like a 2012 imac). Emby was doing software transcoding I guess and I toyed with the idea of using amffmpeg.

Does Emby normally use ffmpeg for transcoding?

My understanding is that amffmpeg is provided for decoding; but not necessarily to provide transcoding capabilities leveraging the VPU. I may be mistaken. To be honest – we’ve never tried amffmpeg (no need for Kodi).

Emby queries the capabilities of the playback device somehow, and does either direct stream or transcoding based on those capabilities. On its settings, it lets you choose between some hardware acceleration options for transcoding (openmax, NVENC, VA API) or a custom ffmpeg version, this all under a configuration category called transcoding.

Thanks for clarifying. I think this is off the cards for now, but might be possible in the future.

Sam

yup, no problem.

This is the ffmpeg that emby runs on this h265 transcoding example, for reference

/usr/bin/ffmpeg -f matroska -codec:0 hevc -codec:1 ac3 -i file:<file> -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -pix_fmt yuv420p -preset veryfast -crf 23 -maxrate 4569124 -bufsize 9138248 -profile:v high -level 4.1 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames expr:gte(t,n_forced*3) -vf scale=trunc(min(max(iw\,ih*dar)\,3840)/2)*2:trunc(ow/dar/2)*2 -copyts -vsync -1 -codec:a:0 aac -strict experimental -ac 6 -ab 384000 -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3 -individual_header_trailer 0 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 0 -segment_list /config/transcoding-temp/f66419fd56082765d0442bfb5ad90044.m3u8 -y /config/transcoding-temp/f66419fd56082765d0442bfb5ad90044%d.ts

Quite a thing.

I think that’s just chucking it to software, which will be slow.
No -hwaccel argument passed.