Enable platform decoder for proprietary_codecs flag on Linux

[uazo]

from https://groups.google.com/a/chromium.org/g/chromium-dev/c/uI5knHDhLjE

---------------------------------------
Proprietary codecs
In addition, you may want to include support for proprietary audio and video codecs, 
as Google's WebView does. These codecs may be covered by patents or licensing
agreements, and you should seek legal advice before distributing a build of WebView
which includes them. You can enable them with the following GN arguments:

ffmpeg_branding = "Chrome"
proprietary_codecs = true
---------------------------------------

in cromite is active by default because it is derived from bromite.
it is a question of whether the enabling is correct or I might run into legal problems.

[Universalizer]

Under Developer tools library > their is Android WorkManager,
With WorkManager, you could easily set up a task and hand it off to the system to run under the conditions you specify.

In example ; if licensed or patented Target multimedia (video, audio and image) playback require decoder library software, check whether that decoder, if already in-built in user's Device,

If not present than prompt message to user that playback will require external (FOSS) software app like VLC player for their OS.

Uazo, it may simplify your doubt or uncertainties.

[PF4Public]

This setting only enables support of proprietary codecs. That means that the browser would accept that media for processing. The answer to your question however is not a trivial thing. Overall, it is probably OK to have proprietary_codecs = true, besides you decided not to provide WebView. More details follow. Boilerplate clause: I am not a lawyer, consult one if you need legal advice.

To try and answer your question, let's separate following concepts

• Multimedia compression standard. May be covered by several patents and may require obtaining a license accompanied with royalty fees.
• An implementation of a video compression standard (software/hardware).
• A multimedia file compressed in accordance with multimedia compression standard.
• Chromium. Via proprietary_codecs flag enables the handling of a multimedia file compressed in accordance with proprietary compression standard.

Now let's outline how it all works together. In order to produce a compressed multimedia file one needs an implementation of a compression standard. If an implementation is a software for example, usual terms for software apply, that is one needs a license for this software. If a compression standard is a proprietary one, i.e. it is covered by patents, in addition to software license one needs a license from patent holders. The two licenses are usually combined into one if patent holders also offer an implementation. This is however not always the case. In order to "display" a compressed multimedia file the procedure is the same with the exception that for "compressing" one needs a coder and for "uncompressing" — decoder. The two are usually combined into codec.

Chromium built with proprietary_codecs = true expects to use an implementation of a proprietary compression standard. In this particular case it is most likely that the Open Source implementation of one is to be used, so there is no need for a software license. Using the free implementation of a proprietary compression standard does not usually grant a license from compression standard patent holders automatically and one should obtain it separately.

So now let's take MPEG-4 Part 10 (or more commonly known as H.264 or AVC) for example. For this compression standard exists free and opensource implementation: x264, which likely to be used. And it indeed does not grant any licenses from MPEG patent holders: https://web.archive.org/web/20160307015234/http://x264licensing.com/content/does-x264-license-include-avc-patent-royalties. So what are they? According to Via Licensing and MPEG LA website one should obtain a license and pay a royalty fee starting at 100,001^st sold unit. Not selling anything should probably waive this requirement.

Yet another aspect is that of building Cromite together with GPL-2 licensed x264 and distributing the result.

Perhaps by now you can realise why Google is so careful with this thing.

As a side note I should mention that Firefox uses OpenH264 instead of x264. OpenH264 is developed by Cisco and is released under simplified BSD license. What is peculiar here is that Cisco pays royalty fees and promises not to pass royalty fees onto those who use their provided binaries. Those who build OpenH264 from source should obtain licenses and pay fees however.

[uazo]

@PF4Public thanks, it's clear.

This setting only enables support of proprietary codecs.

the idea is to understand what is activated with that flag and to check the corresponding licence, both related to the format and to the software that read that format.
for sure Carl had already looked into the matter, the flag being active, but I know nothing about it and would like to understand it.

[uazo]

@Universalizer I don't think it has much to do with this, but I could be wrong

[Universalizer]

ffmpeg_branding = "Chrome"
proprietary_codecs = true

As you mentioned this, it means Chrome itself uses ffmpeg branding open source software libraries, with true support for proprietary_codecs,

---

Go to Cromite Settings > About Cromite > Legal information > Open Source License > <Menu> Find in Page, search "ffmpeg".

You don't need to worry for these software libraries (encoder, decoder and other utilities).

---

As per codec "H.264 MPEG-4 Part 10 (or more commonly known as H.264 or AVC) for example & H.265", both being heavily patented and licensed, also widely distributed under container ".mp4",
Generally years ago i have read somewhere, distribution of content under these Codec requires licensing pool, but not for playback. It is very old reading, need to verify the statement over the internet.

But, ffmpeg contains libx264 & libx265 encoder (As a wrapper, open source implementation by VLC Developer) adopted under ffmpeg, so no problem.

Carl, as Bromite developer is also genius for licensing knowledge, but to clear your doubts, Contact Carl if possible, he may help you.

[uazo]

You don't need to worry for these software libraries (encoder, decoder and other utilities).

is not correct, I think instead I have to check.
because, one thing is the implementation (the code) that uses a format, another is the format itself, which may be under licence.

Contact Carl if possible, he may help you.

no, he must be free to do what he wants. i hope he comes back, but i won't bother him.

[uazo]

And I think a problem exists instead.
among the first thing I saw, that flag enables the AAC codec, which is licensed by VIA.

My company builds products based on the Android operating system. Does Google pay license fees on behalf of its Android OEM partners?

No. The AAC Patent License offered through Via LA’s program does not cover this obligation for Android OEMs. Manufacturers of Android-based products must obtain their own AAC patent licenses either through the Via LA AAC patent pool or bilaterally with each of the individual patent owner/licensors.
...
Those intending to use this source code in hardware or software products are advised that implementations of this code, including in open source software or shareware, may require patent licenses from the relevant patent holders.

refs:

• https://www.via-la.com/licensing-2/aac/aac-faqs/
• https://android.googlesource.com/platform/external/aac/+/refs/heads/master/NOTICE
• https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
• https://en.wikipedia.org/wiki/Advanced_Audio_Coding#Licensing_and_patents

test:

• https://www2.iis.fraunhofer.de/AAC

[PF4Public]

Exactly the same situation as what I described with H.264.

[uazo]

And I think you're right.

[uazo]

the only correct way is to use the libraries built into the s.o., because the licensing of those is up to the s.o. distributor.
I have to check if the ffmpeg library is active or are we using the s.o. services.
In the second case, I guess in linux you don't have the ability to listen to aac, or do you?

[PF4Public]

I have to check if the ffmpeg library is active or are we using the s.o. services.

If you didn't request it specifically, you're probably using built-in ffmpeg. build/linux/unbundle/replace_gn_files.py might be of interest for you.

In the second case, I guess in linux you don't have the ability to listen to aac, or do you?

Why? https://packages.gentoo.org/packages/media-libs/fdk-aac https://packages.debian.org/bookworm/libfdk-aac2

[uazo]

mstorsjo/fdk-aac#118 (comment)

because, as I understand it, distribution is not lawful without an VIA licence, and, mistakenly therefore, I thought that being under licence was not included in linux distributions, but I am probably wrong.

[Universalizer]

Deleted and rewrite,

ffmpeg_branding = "Chrome"
proprietary_codecs = true

As mentioned earlier,
Uazo, if their is any issues in it,
Last resolve will be proprietary_codecs = false in gn.args or in the build.

---

But, Multimedia Container .mp4 generally contains following :-

*** General
Format:  MPEG-4
Format profile:  Base Media / Version 2
Codec ID:  mp42 (mp41/isom/iso2)

*** Video
ID:  1
Format:  AVC
Format/Info:  Advanced Video Codec
Codec configuration box:  avcC

*** Audio
ID:  2
Format:  AAC LC
Format/Info:  Advanced Audio Codec Low Complexity
Codec ID:  mp4a-40-2

---

Then, Cromite user's will have only one option to download the file, instead of playback video online with codec H.264 & AAC LC in mp4.

These is my guess, probably right or wrong ?, I don't know.

[Universalizer]

https://github.com/FFmpeg/FFmpeg official github.com

[uazo]

These is my guess, probably right or wrong ?, I don't know.

if possible, I would try to maintain support for proprietary codecs delegating them to the s.o. libraries so that the responsibility for the licence falls on the s.o. distributor rather than on me.
of course, 15,000 dollars + a token for each installation is out of the question, so the last chance is to remove support, but it must be investigated first.

[Universalizer]

Good decision.

[PF4Public]

if possible, I would try to maintain support for proprietary codecs delegating them to the s.o. libraries so that the responsibility for the licence falls on the s.o. distributor rather than on me.

It would be easy to achieve on Linux, but I have my doubts about Windows and Android. Have you investigated the latter?

[Universalizer]

Uazo, It is possible,
Support only, if end user's Android OEM device already has natively in-built support in OS.

[uazo]

It would be easy to achieve on Linux
Have you investigated the latter?

no, I am doing the rebase at 121, I will look at this immediately afterwards, for me it is a priority.

Uazo, It is possible,

ah, you make it easy. if chromium doesn't provide for it, I won't be able to do it.

[PF4Public]

if chromium doesn't provide for it, I won't be able to do it.

This is what I suspect to be the case with Windows and Android.

[uazo]

This is what I suspect to be the case with Windows and Android.

i hope this is not the case. last night, reading the code on the couch :) instead it seemed to me that only cast devices use those libraries directly, and therefore only those need to be licensed, but to understand this i have to edit some gn args and recompile.

[uazo]

maybe related #723 (reply in thread)

[uazo]

so, pretty complex issue.
I tell you what I understand so far, it may not be completely true.

it seems like it's perfectly legal to use those codecs the moment you use functionality external to your application, the s.o.'s api i.e. external libraries, because at that point, the license has to be acquired from whoever produced that library, and so it's not my problem.
In the case of Android, the android.media or the media ndk should be used, but chromium uses ffmpeg for aac handling.

indeed it seems that it is not legal to add support for AAC and H264 (the latter only in desktops and ios) in cromite. in fact it seems that it is not really legal to add it in any of the cromite-derived projects, unless the distributor (in this case me) has the necessary licenses available for distribution, which of course I don't know.
mine is obviously not a legal opinion, but rather the effect of a borderline situation that describes how it seems that it might be enough that just integrating the parsing and decoding of the aac into your program would require a license. It is absolutely certain for enconding, on the other hand.
A borderline situation that for me is sufficient to require the elimination of that feature, because Cromite, with ffmpeg_branding=Chrome integrates parsing and deconding code of aac and h264 and with proprietary_codecs=true allows chromium to actually enable that functionality.

I also went to look at the situation in the other applications.

• ffmpeg does not release the compiled, and it specifically says that it is the responsibility of the distributor to verify the necessary licenses
• vlc used to say that since it is a French organization, you don't need a license because in france you can't register a license on ideas (by the way, all over europe) and therefore, according to them, they can distribute it without a license. but then they changed their mind and removed the support:

Neither French law nor European conventions recognize software as patentable (see French section below).
Therefore, software patents licenses do not apply on VideoLAN software.
NB: libaacs is not shipped in VLC.
https://www.videolan.org/legal.html

in the forks:

fork	link
brave integrates it by default	https://github.com/brave/brave-core/blob/v1.64.29/build/commands/lib/config.js#L334C1-L335C31
windows ungoogled, by default:	https://github.com/ungoogled-software/ungoogled-chromium-windows/blob/master/flags.windows.gn
debian ungoogled, by default:	https://github.com/ungoogled-software/ungoogled-chromium-debian/blob/unified/debian/rules#L63-L64
vanadium, disabled:	https://github.com/GrapheneOS/Vanadium/blob/main/args.gn
CalyxOS, not understood	https://calyxos.org/docs/development/build/chromium/
/e/OS, by default	https://gitlab.e.foundation/e/os/browser/-/blob/master/build/browser.gn_args
thorium, by default:	https://github.com/Alex313031/thorium/blob/main/args.gn#L50-L51

however, in https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-licensees/ i find adobe, apple, microsoft, google but not brave, calyx or eOs.

(fantastically vivaldi reveals the surprise! see further...)

then i found this:

How much work does it take to replace chromium's ffmpeg with Android MediaCodec (for aac codec)
https://groups.google.com/a/chromium.org/g/chromium-dev/c/254DweLTgao

where he talks about the spitzer project, which actually changes from v85 the behavior in android using the pipeline already active in the desktop, which used ffmpeg for decoding.
507834 talks about enabling the new mode, i.e., switching in android from android.media to ffmpeg for compatibility and simplification issues.
unfortunately, it is not possible to restore the deleted code since many changes have been made in the code base.
it would be to bring back webmediaplayer_android.cc and the java counterpart in the gpu process on the other side of the mojo pipe, really a lot of stuff.
from here 570711 on, the code is gone.

the problem can big is that there is no alternative to the ffmepeg demuxer but there is a new project still in development 1266991 that allows the use of the hls format in android by restoring the use of the android libraries, code that would have to be understood thoroughly and exploited to handle aac as well (which is also the only codec not handled in android).
I don't know how much it is worth it and especially the end of that project should be waited for.

build/linux/unbundle/replace_gn_files.py is not needed because it replaces the library root of source code using the system one, it does not make the library linked to the system one at runtime.

instead for windows and linux there is vivaldi's code!
https://github.com/ric2b/Vivaldi-browser/blob/bbf1c070a1230a834cbd122f180afdf98746dca9/platform_media/README.md
under OPERA_LICENSE
In your opinion, can it be used?

I decided to disable aac and h264 in desktop, now we have to figure out how to do it:

To build without patented codecs Chromium provides a GN variable proprietary_codecs that can be set to false. However, besides the codecs itself this disable a lot of code related to MPEG parsing and handling codec metadata which has been patent-free at least since 2017. These code is necessary so we can use FFmpeg demuxer to extract audio or video streams from the media files.
https://github.com/ric2b/Vivaldi-browser/blob/bbf1c070a1230a834cbd122f180afdf98746dca9/platform_media/docs/ffmpeg.md

[PF4Public]

build/linux/unbundle/replace_gn_files.py is not needed because it replaces the library root of source code using the system one, it does not make the library linked to the system one at runtime.

What do you mean?

ldd /usr/lib64/cromite/chrome | grep libav
	libavcodec.so.60 => /usr/lib64/libavcodec.so.60 (0x00007f9823800000)
	libavformat.so.60 => /usr/lib64/libavformat.so.60 (0x00007f9823400000)
	libavutil.so.58 => /usr/lib64/libavutil.so.58 (0x00007f9823213000)

Those are the libraries from ffmpeg. It is not from your releases, it is how I built it.

[uazo]

it is how I built it.

note, those who build for themselves are not a problem, it is those who distribute the build who have the problem.

Those are the libraries from ffmpeg

correct me if I am wrong:

https://source.chromium.org/chromium/chromium/src/+/refs/tags/121.0.6100.0:build/linux/unbundle/replace_gn_files.py;l=112
Copy the GN file from directory of this script to target path.

Which is actually what the script does.
the one doing that work is remove_bundled_libraries.py I think I will also use for the linux build.
see https://source.chromium.org/chromium/chromium/src/+/main:build/linux/unbundle/ffmpeg.gn

[Universalizer]

Will it be supported in Cromite ?

libx264 (FFmpeg Library)
https://en.m.wikipedia.org/wiki/X264

libx265 (FFmpeg Library)
https://en.m.wikipedia.org/wiki/X265

[PF4Public]

@uazo With replace_gn_files.py you replace existing file third_party/ffmpeg/BUILD.gn with build/linux/unbundle/ffmpeg.gn. After this gn file was replaced ninja then creates dummy includes in out/Release/gen, which include <libavcodec/avcodec.h> instead of third_party/ffmpeg/libavcodec/avcodec.h, which allows remove_bundled_libraries.py to clean third_party/ffmpeg/ which no longer takes part in compilation with the end-result being that chrome binary is linked to system libavcodec.so.60 and other ffmpeg-provided libraries.

[uazo]

ah, other thing.
I decided not to use the cisco dll, too dangerous to load libraries not under my control among other things in the gpu process.
in fact, i really don't know how to do it for linux, but I am starting to try the solution indicated in #710 (comment).
@PF4Public is there any way in linux to verify the source of a .so library? Is the path enough?

[uazo]

@PF4Public when you have time and willing, would you do this check for me?

• add "is_component_ffmpeg = true" to gn gen
• do the build

at this point you should get "libffmpeg.so" in the out.
Now you should try if, by deleting it, the browser use the libffmpeg.so of the s.o. (as written in https://groups.google.com/a/chromium.org/g/chromium-packagers/c/R5rcZXWxBEQ/m/XzfC2kFQH2gJ)
I'll give it a try, too.

by the way, no problem with device fingerpriting, since internally chromium sets an allowlist of ffmpeg codecs to use, so even if you have a library with all codecs, only those officially supported by chromium are currently supported. possibly, the only problem is the security of the library source.

[uazo]

I confirm that it works.
I got the .so from https://github.com/nwjs-ffmpeg-prebuilt/nwjs-ffmpeg-prebuilt

alternatively, what if I made a repo that was only used to produce the .so and that the user has to fork and launch the action?
EDIT: just have to launch ninja -C out/lin64/ libffmpeg.so

[PF4Public]

@PF4Public is there any way in linux to verify the source of a .so library? Is the path enough?

Sorry, but I don't understand your question. Could you please rephrase it?

@PF4Public when you have time and willing, would you do this check for me?

• add "is_component_ffmpeg = true" to gn gen
• do the build

at this point you should get "libffmpeg.so" in the out. Now you should try if, by deleting it, the browser use the libffmpeg.so of the s.o. (as written in https://groups.google.com/a/chromium.org/g/chromium-packagers/c/R5rcZXWxBEQ/m/XzfC2kFQH2gJ)

Oh, by the way I forgot to tell you that usage of system ffmpeg was made impossible in recent versions of Chromium. They use a modified version of ffmpeg and as such system ffmpeg should be build accordingly. AFAIK only Arch linux does that in official repository. I do too, but it is "unofficial" :) All that means that you cannot rely on system ffmpeg on Linux any longer.

[uazo]

is there any way in linux to verify the source of a .so library? Is the path enough?

Sorry, but I don't understand your question. Could you please rephrase it?

certainly.
In Windows, I can enable a sandbox flag that does not allow non-Microsoft libraries to be loaded, or I can check the origin of the dll by checking the digital signature of the file.
so, assuming that i do not distribute the libffmpeg.so file but leave it to the user to download (or better, build), what do you think is the best way to ensure that a malicious library is not loaded in linux?

Oh, by the way I forgot to tell you that usage of system ffmpeg was made impossible in recent versions of Chromium

In my opinion, you can bring this to the attention of the chromium team.

[uazo]

another update.
Just to complicate matters, I found a new possibility for fingerprinting the device using the media API, but it is still not exploited by tools such as creepjs... I need users' logs... carl absolutely disagreed with this, and he is actually right, but to do my job better I should have them.

[uazo]

They use a modified version of ffmpeg and as such system ffmpeg should be build accordingly.

I checked for linux, it is not true that they use a particular ffmpeg modified version. to what are you referring?
This is their ./configure for linux x64

--disable-everything --disable-all --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-static --enable-avcodec --enable-avformat --enable-avutil --enable-static --enable-libopus --disable-debug --disable-bzlib --disable-error-resilience --disable-iconv --disable-network --disable-schannel --disable-sdl2 --disable-symver --disable-xlib --disable-zlib --disable-securetransport --disable-faan --disable-alsa --disable-autodetect --enable-decoder='vorbis,libopus,flac' --enable-decoder='pcm_u8,pcm_s16le,pcm_s24le,pcm_s32le,pcm_f32le,mp3' --enable-decoder='pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw' --enable-demuxer='ogg,matroska,wav,flac,mp3,mov' --enable-parser='opus,vorbis,flac,mpegaudio,vp9' --extra-cflags=-I/usr/local/google/home/dalecurtis/code/chrome/src/third_party/opus/src/include --disable-linux-perf --x86asmexe=nasm --optflags='\"-O2\"' --enable-decoder='theora,vp8' --enable-parser='vp3,vp8' --enable-lto --arch=x86_64 --target-os=linux --enable-pic --cc=clang --cxx=clang++ --ld=clang --extra-ldflags='-fuse-ld=lld' --enable-decoder='aac,h264' --enable-demuxer=aac --enable-parser='aac,h264'

I do too, but it is "unofficial"

so do you distribute a version of ffmpeg without the correct licences? or is it only for your internal use? is that correct, can you do it? I ask because if there is a legal way I would do it too.
I'm interested because there is no other way to decode aac since there is no hardware decoder for audio in (chromium) linux, so, I must also release that .so file.

[PF4Public]

download (or better, build), what do you think is the best way to ensure that a malicious library is not loaded in linux?

If your library is loaded in runtime (on demand, like LoadLibraryEx and GetProcAddress in Windows), then you could download it on your build machine, checksum it, hardcode it into the binary, and then compare the checksum before each load of the library.

Checking the manually built library is a big problem in it's own. Simplest would be to verify the archive of the sources from which it should be built because making reproducible builds so that you could verify the resulting binary everywhere is a daunting task (dependent on the size of a library of course)

a sandbox flag that does not allow non-Microsoft libraries to be loaded, or I can check the origin of the dll by checking the digital signature of the file

I don't think such a thing exists in Linux, but I'll do a research on the topic and let you know if I can find something.

In my opinion, you can bring this to the attention of the chromium team.
I checked for linux, it is not true that they use a particular ffmpeg modified version. to what are you referring?

Compare /libavformat/avformat.h in ffmpeg project and in Chromium:
https://github.com/FFmpeg/FFmpeg/blob/3635c1ee97faeb2fb0757a0b158e7de959dfa298/libavformat/avformat.h#L1277-L1281

attribute_deprecated
int64_t    av_stream_get_end_pts(const AVStream *st);
#endif

#define AV_PROGRAM_RUNNING 1

https://source.chromium.org/chromium/chromium/src/+/main:third_party/ffmpeg/libavformat/avformat.h;l=1116-1124?q=av_stream_get_first_dts&ss=chromium%2Fchromium%2Fsrc%3Athird_party%2Fffmpeg%2F

attribute_deprecated
int64_t    av_stream_get_end_pts(const AVStream *st);
#endif

// Chromium: We use the internal field first_dts vvv
int64_t    av_stream_get_first_dts(const AVStream *st);
// Chromium: We use the internal field first_dts ^^^

#define AV_PROGRAM_RUNNING 1

They use internal field, which means that if system library does not provide this field it leads to a runtime failure.

so do you distribute a version of ffmpeg without the correct licences? or is it only for your internal use? is that correct, can you do it?

No, I build this library locally and anyone building ungoogled-chromium or Cromite using my overlay should also do the same locally. In this case I do not distribute anything at all. I also provide pre-compiled ungoogled-chromium, which does not require system ffmpeg, but it has proprietary codecs enabled. I'm not a lawyer and didn't investigate how unlawful/lawful that might be :)

I need users' logs... carl absolutely disagreed with this, and he is actually right, but to do my job better I should have them.

Would creating several virtual machines and gathering logs there suffice? I could do this if it might help you.

[uazo]

checksum it, hardcode it into the binary, and then compare the checksum before each load of the library.

I like this solution, I don't know if I can do it, but I like it: I first have to check whether the build is reproducible so I could put the .so without the proprietary codecs in the official build, and allow the user to replace the library.
i think i'll proceed in steps, for linux for now i'll continue as before, today, if i can, i'll publish this patch. yesterday i tested it on browserstack with real devices and it seems to work.
I would like to propose adoption to other browsers as well, once I am sure it works.

They use internal field, which means that if system library does not provide this field it leads to a runtime failure.

you're right, I checked it wrong.

I'm not a lawyer and didn't investigate how unlawful/lawful that might be :)

Yeah, same problem as mine.

Would creating several virtual machines and gathering logs there suffice?

unfortunately i think i need physical machines, i.e. not virtual ones: I don't want to make public yet the fingerpriting flaw i found until i solve it, we can discuss it later.

I could do this if it might help you.

thanks, we'll talk again, actually you're already helping me a lot.

[uazo]

for those who want to try, release: https://github.com/uazo/cromite/releases/tag/v122.0.6261.111-6144adc65250e66b02fbd658839dd786fa5bf1ea is the same version of https://github.com/uazo/cromite/releases/tag/v122.0.6261.111-aeb7dce1db09d042991073d6352a1363efeeceee but with the patch of #856
as a check, you can open chrome://media-internals: kAudioDecoderName and kVideoDecoderName must be not ffmpeg for the aac and h264 codecs.
all youtube live videos are in aac format, h264 and HEVC videos can be found, for example, at https://tools.woolyss.com/html5-audio-video-tester

[macchrome]

Platform audio-visual (AV) decoding under Linux including xHE_ACC

https://github.com/macchrome/chromium/releases/tag/v123.6312.127-M123.0.6312.127-r1262506-portable-ungoogled-Lin64

[uazo]

you must supply your own Chromium compatible dynamically loaded FFMpeg libraries

that is exactly the problem.
How do you allow the download of a component for which you do not have a licence?

[macchrome]

We have to be pragmatic, unless the desire is that each indiviual user of Chromium compiles it from source,

[uazo]

unless the desire is that each indiviual user of Chromium compiles it from source,

well, that would be nice. the use of my docker images would already allow this.
in fact, the idea is to create a docker image for 'in house' build of ffmpeg for chromium.
is that there should be 10 of me to do everything! :( but slowly I will get there!

[lpslp]

cromite is definitely missing some codecs.

I didn't create a separate ticket because I can't even name which codecs exactly - but cromite behaves very strangely.
Sometimes I get this

and this same video opens NORMALLY in chrome and firefox. And even! in palemoon video opens normally, but in cromite - doesn't. (I can't give links to video examples)

but the very fact that even palemoon opens video what cromite can't - is very sad

[PF4Public]

@lpslp If you cannot publish links with failing videos, you can examine the "Media" tab in devtools, to see which codec was expected and wasn't found.

[lpslp]

thanks for advice PF4Public
in latest Google Chrome it show it like this

upd
i want add some screen from log, maybe it helps to find "what's wrong"

[PF4Public]

It looks like they're trying to use the codec, that is for some reason disabled in Cromite. The "Track" tab should show the actual codec that is used there, for example AV1 or h264.

[lpslp]

The "Track" tab should show

sorry, but i don't know where is it...
if you can, describe, where exactly "this" tab located?

[PF4Public]

[lpslp]

those was from Google Chrome...

[PF4Public]

h264 is unlikely to be a problem, but aac…
@uazo, is it possible that aac is disabled in Cromite?

[uazo]

chrome://media-internals please use this and send the log.