Newsgroup: it.comp.os.linux.iniziare
Titolo: Rx550 Sapphire

Ho comprato su alìexpress la RX550 Sapphire usata pagandola 78-79 euro, 
l'ho installata e funziona senza fare nulla sulla mia mageia beta1. 
glxinfo mi dice che è una series500 con Polaris11, andando sul sito 
della Sapphire mi dice che il mio SN è valido e che è un modello con SKU 
che noto che sul sito non è compresa, non c'è alcun documento su mio 
modello o meglio sulla mia sottoversione. Ho chiesto chiarimenti al 
servizio clienti.
 
C'è qualche controllo che potrei fare sulla mia Mageia in modo da 
verificare che abbia acquistato qualche cosa che vale 80 euro o poco meno?
 
Ho usato una utility sotto Mesa-Demo per vedere se è preformante nel 3D 
e mi pare abbia ottenuto buone prestazioni migliori di altre rx550 testate.
 
-- 
Sandro kensan 
www.kensan.it
 & 
www.qiqi.it
 geek site
Saluto gli agenti della NSA - Hello NSA - 
www.nsa.gov
 

 verificare che abbia acquistato qualche cosa che vale 80 euro o poco meno?
 
A cosa ti serve questa scheda video?
Deve giocare? Fai rendering? E` solo
per il desktop?
 
Se le prestazioni, in una o piu` di
queste situazioni, ti vanno bene, non
vedo cosa altro vi sia da verificare.
 
Se non andassero bene, allora si
potrebbe anche pensare di vedere
come sia la situazione.
 
bye,
 
-- 
 
piergiorgio
 

 testate.
 
Per 80 euro le uniche verifiche che ha senso fare è se funziona, se è un 
buono stato, se ha tutti gli accessori, ecc. .
 
Poi provarla su qualche gioco/programma impegnativo che si intende usare 
adesso o in futuro, e magari provarla anche su windows per vedere come se 
la cava con directx.
 
Da quello che sento le schede video sono tutte over prezzate.
 
 
Se vuoi cercare i dati che riporta l'hardware (e che quindi volendo 
possono essere modificati), puoi usare
 
lshw -enable pci
 
o 
 
lshw -X
 
 
 
https://www.videocardbenchmark.net/gpu.php?gpu=Radeon+RX+550&id=3761
 
 

 
https://www.videocardbenchmark.net/gpu.php?gpu=Radeon+RX+550&id=3761
 
 
Queste le specifiche che mi ha mandato per email Sapphire:
 
SKU#	11268-13
Product Description	SAPPHIRE PULSE RADEON RX 550 4G GDDR5 HDMI / DVI-D / 
DP (UEFI, 6.0GBPS) 白金版
白金版	Edizione Platinum (traduzione, ndR)
Customer	Change to Driver E010-0191-00
Core Speed	1071
Memory Speed	1500
On-Board Memory	4G
Memory Interface	128-Bit
Memory Type	GDDR5 256MX32-6.0 GBPS
Usage of Memory	
PCB Form Factor	ATX
Bracket Form Factor	ATX-SS
	Active-DS
 
Rispetto al link che mi hai fornito la mia scheda è leggermente più 
lenta nel Core speed e nel Memory speed. Comunque per 78.04€ va 
perfettamente bene. Spero mi funzioni a lungo.


 bye,
 
Quindi mi potrei fermare qui.


 e mi pare abbia ottenuto buone prestazioni migliori di altre rx550 testate.
 
Premettendo che ho avuto a che fare sempre più con nvidia negli ultimi
lustri, ti direi di partire da farti una panoramica della situazione
driver per la tua scheda.
 
Non so, tanto per dirti con schede nvidia più o meno vecchiotte puoi
usare il drvier open Nouveau oppure il proprietario nvidia.
 
L'ultima volta che ho avuto a che fare con Radeon era ancora roba
pre amd, una ati radeon... boh 9600 ?? posso ricordare male, parliamo
di secoli fa, e anche lì si poteva usare il driver open, che non ricordo
come si chiaamva... forse proprio radeon, oppure i driver proprietari,
che erano un po' zoppiccanti all'epoca. Ora ho visto da qualche articolo
e discussione in giro che sarebbe tutto molto linuxfriendly anche con
driver open.
 
Puoi provare la riproduzione di video con MPV con il comando, o la
configurazione appropriata per forzare l'utilizzo della GPU, in modo
che scarichi il processore dall'incombenza della decodifica video e
e dai tutto in carico alla GPU della RX550.
 
A quel punto ti tiri giù qualche video dal tubo con "yt-dlp -F", che
ti fa vedere i formati dei video/audio e provi a fare qualche test di
riproduzione osservando se vedi ad esempio dei fuori sincro audio/video.
Ad esempio a me con video a 60fps, pur stando su roba 1080p la mia
scheda video da due soldi (una scalpitante GeForce 210 < 30 €).
Ovviamente devi anche controllare dalle specifiche quali formati
supporta nella decodifica hardware. Ad esempio la mia è in grado di
digerire roba H264 direttamentw, mentre non ha supporto per H265 o meno
che mai AV1, tutte cose più recenti e impegnative per quella ferraglia
lì... in quel caso la GPU non può essere sfruttata e la decodifica la
fa il processore.
 
Su come richiamare precisamente il comando di "mpv" dovrebbe essere
OK una roba tipo la seguente:
 
mpv --no-config --vo=gpu --hwdec=auto file.quelcheè
 
in particolare --vo=gpu, richiede proprio l'utilizzo del driver output
più adeguato, nel mio esempio per la gt218 è VDPAU.
 
Per i dettagli ti puoi guardare il man mpv, su quelle opzioni lì, è
vasto, non mi dilungo oltre qui.
In sintesi, prova con un video h264, che sicuramente è contemplato dalle
specifiche della tua GPU per la decodifica hardware.
 
Poi vedrai quello che stampa a terminale "mpv" durante la riproduzione.
 
Ti metto un esempio con e senza hwdec=auto, il file di test è un h264
a 30 fps:
-----------------------------------
$ mpv --vo=gpu --no-config file.mp4
  (+) Video --vid=1 (*) (h264 720x1280 30.000fps)
  (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
  AO: [pulse] 44100Hz stereo 2ch float
  VO: [gpu] 720x1280 yuv420p
  AV: 00:00:02 / 00:05:40 (1%) A-V:  0.000 ct:  0.115
-----------------------------------------------------
 
Così osservo un carico della CPU che si aggira dal 10 al 30%, il ché
significa che la decodifica la fa il processore. Io lo vedo da slstatus
la barra impostata in dwm... qualsiasi cpu-monitor te lo mostra, al
limite ti apri un secondo terminale dove lanci "htop".
 
E ora riprovi aggiungendo "hwdec=auto":
------------------------------------------------
$ mpv --vo=gpu --hwdec=auto --no-config file.mp4
 (+) Video --vid=1 (*) (h264 720x1280 30.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
 Using hardware decoding (vdpau).
 AO: [pulse] 44100Hz stereo 2ch float
 VO: [gpu] 720x1280 vdpau[yuv420p]
 AV: 00:00:36 / 00:05:40 (11%) A-V:  0.000 ct:  0.115
-----------------------------------------------------
 
Dall'output si vede già che si sta decodificando via
hardware "Using hardware decoding (vdpau)", col dettaglio
dell'out driver VDPAU, che è il meglio che possa offrire
la mia scheda.
Nel frattempo la CPU non sale sopra al 3% di carico...
non male, dal 30 al 3!
 
Sempre per la cronaca col driver open Nouveau tutto il
sistema provando a fare un test del genere mi andava in
crash sistematicamente. Tanto per dire che il driver in
usa conta parecchio.
 
Questo non è un benchamark per schede video sia chiaro, è solo un
test di utilizzo quotidiano in cui la GPU può rivelarsi utilissima
se sfruttata adeguatamente dal driver e dalla configurazione del
player video, può essere utlizzato per capire se si possa coinvolgere
la scheda nella decodifica hardware dei video.
 
Probabilmente la GPU in oggetto decodifica anche H265. Altrettanto
probabilmente non supporta AV1, che forse è roba un po' troppo
recente rispetto alla RX550. Questo logicamente non significa che
non puoi vedere video di quel tipo, ma solo che ad esempio MPV
automaticamente passa alla decodifica software via processore.
 
Scritto troppo, ma a me sta roba aveva fatto comodo tempo addietro,
spero possa servire.

 mpv --vo=gpu --no-config file.mp4
 
Post lunghissimo e pieno di informazioni. Se hai un attimo di tempo ti 
mostro un primo risultato tanto per capire se l'inizio è buono:
Ho scaricato un mpg che è semplicissimo da decodificare per tutte le GPU:
https://software-download.name/sample-mpeg-video-file/
 
 
Questo il risultato seguendo la tua guida:
 
[sandro@localhost]$ mpv --vo=gpu --no-config mpeg-sample-video/mpeg.mpeg
  (+) Video --vid=1 (mpeg1video 384x288 25.000fps)
  (+) Audio --aid=1 (mp2 1ch 32000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 32000Hz mono 1ch s16
VO: [gpu] 384x288 => 391x288 yuv420p
AV: 00:03:06 / 00:03:06 (100%) A-V:  0.000
 
Exiting... (End of file)
 
Mi pare di capire che la gestione della decodifica (encodec) è stata 
fatta dalla GPU perché è scritto:
VO: [gpu] 384x288 => 391x288 yuv420p
 
inoltre sempre seguendo la tua giuda la mia CPU non va oltre il 4-5%.
 
Dovrebbe essere proprio un Mpeg1 perché c'è scritto:
(+) Video --vid=1 (mpeg1video 384x288 25.000fps)
 
Scaricando un 264 ho:
 
[sandro@localhost]$ mpv --vo=gpu --no-config h264-sample-video/h264.h264
[lavf] This format is marked by FFmpeg as having no timestamps!
[lavf] FFmpeg will likely make up its own broken timestamps. For
[lavf] video streams you can correct this with:
[lavf]     --no-correct-pts --fps=VALUE
[lavf] with VALUE being the real framerate of the stream. You can
[lavf] expect seeking and buffering estimation to be generally
[lavf] broken as well.
  (+) Video --vid=1 (h264 640x480 25.000fps)
No video PTS! Making something up. Using 25.000000 FPS.
No video PTS! Making something up. Using 25.000000 FPS.
Ignoring further missing PTS warnings.
VO: [gpu] 640x480 yuv420p
V: 00:00:09 / unknown (100%)
 
Exiting... (End of file)
 
Quindi anche questo dovrebbe essere ok:
VO: [gpu] 640x480 yuv420p
 
La CPU sempre al 4-5%.
 
File più grossi da Mega:
https://mega.nz/folder/jLgQiToD#QT2y3SJMYYip9VE7oThoUg
 
 
Ora qualche cosa di impegnativo, un VP8:
https://mega.nz/folder/jLgQiToD#QT2y3SJMYYip9VE7oThoUg/file/XKJVlYwD
 
 
[sandro@localhost]$ mpv --vo=gpu --no-config 'V208 WEBM - VP8 1080p 
24fps 8bit - VORBIS2.0.webm'
  (+) Video --vid=1 (*) (vp8 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:31 / 00:00:31 (100%) A-V:  0.000
 
Exiting... (End of file)
 
La cpu è al 7-8% e cala al 4% quando il filmato è terminato. Cosa significa?
 
 
ORA HEVC:
https://mega.nz/folder/jLgQiToD#QT2y3SJMYYip9VE7oThoUg/file/SXRjmIJL
 
 
[sandro@localhost]$ mpv --vo=gpu --no-config 'V209 MP4 - HEVC 1080p 
24fps 8bit - AAC2.0.mp4'
  (+) Video --vid=1 (*) (hevc 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:31 / 00:00:31 (100%) A-V:  0.000
 
Exiting... (End of file)
 
La CPU al 9-10% che poi cala dopo la fine al 4%.
 
Con un H264 più grosso:
https://mega.nz/folder/jLgQiToD#QT2y3SJMYYip9VE7oThoUg/file/WD4wCJRK
 
 
[sandro@localhost]$ mpv --vo=gpu --no-config 'V204 MKV - AVC 1080p 24fps 
8bit - AAC2.0.mkv'
  (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:31 / 00:00:31 (100%) A-V:  0.000
 
Exiting... (End of file)
 
La CPU al 8-10% che poi cala dopo la fine al 4%.
 
Quindi si può dedurre qualche cosa, io ci capisco poco... :(


 Quindi si può dedurre qualche cosa, io ci capisco poco... :(
 
No, rileggi il mio post dove ho messo l'esempio con anche --hwdec,
avevo fatto proprio l'esempio senza e con...
 
Ci sono due comandi che ho riportato, tu hai usato solo il primo,
il secondo... perso in battaglia. Capisco che il post fosse lungo,
per cui non mi dilungo oltre. Prova e riposta i risultati e fai
caso al carico CPU anche con l'altro comando.

 avevo fatto proprio l'esempio senza e con...
 
Scusa, si vede che avevo poca voglia di leggere un testo lungo.
 
Comunque mi dicevi di testare i due comandi mvp:
mpv --vo=gpu
mpv --vo=gpu --hwdec=auto
 
Prima di tutto mi pareva il caso di vedere se mpv --vo=gpu --hwdec=auto 
triggerasse la scheda video. Mi pare che anche il semplice mpeg4 non 
metta in funzione la scheda video:
 
[sandro@localhost ]$ mpv --vo=gpu --hwdec=auto --no-config 'V001 AVI - 
MPEG-4 XVID NTSC 480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:31 / 00:00:31 (99%) A-V:  0.000
No video PTS! Making something up. Using 29.970030 FPS.
AV: 00:00:31 / 00:00:31 (99%) A-V:  0.000
 
Exiting... (End of file)
 
manca la parte che nel tuo caso è:
  Using hardware decoding (vdpau).
  ...
  VO: [gpu] 720x1280 vdpau[yuv420p]
 
Ho provato anche con gli h264 e non compare mai la linea:
Using hardware decoding
 
 
...non so...
 
Poi certo potrei considerate l'occupazione della CPU nei due casi ma 
questo viene dopo il fatto che si metta in funzione la decodifica hardware.


 questo viene dopo il fatto che si metta in funzione la decodifica hardware.
 
Sì all'occupazione della CPU facci caso già da subito... che alla fine è
la prova del nove sul campo. Però sono d'accordo, in qualche modo direi
che non stai sfruttando la decodifica hardware della GPU.
Il ché non va bene.
 
Intanto partirei da postare l'output di questi comandi, io li
ho provati da root, ma dovrebbero in parte girare anche da user,
l'unica cosa occhio al path, se mai aggiungi /usr/bin/lshw o
/sbin/lspci, cioè lanci col percorso assoluto altrimenti la shell
dell'utente potrebbe non trovare i comandi, stando in dir non presenti
nel PATH dell'utente, insomma, fai "su -" e vivi ATTENTO ma felice:
 
1.
# lspci -nnk | egrep -i --color 'vga|3d|2d' -A3
 
2.
# lshw -c video
 
---------------
 
Ti metto qualche info che ho trovato e magari conosci anche già,
ma utili per capire quale driver dovresti ritrovarti in uso.
 
Per quanto riguarda la scheda video in sè, il chip della RX550
dovrebbe essere noto come:
 
Lexa - Polaris 12
 
Che fa parte della microarchitettura:
 
Graphic Core Next 4 (CGN 4)
 
Da lì vedi quale driver dovrebbe essere disponibile... sulla
wiki di Arch, prima risorsa di info, tanto più che utilizzi una
derivata di arch ecco lo schemino:
 
https://wiki.archlinux.org/title/Xorg#AMD
 
---------------
GCN 3 and later
- Open-source driver:   AMDGPU
- Proprietary driver:   AMDGPU PRO
----------------------------------
 
A questo punto si tratta di capire quale driver stai utilizzando
sul tuo sistema. Ed in seguito vedere come vada configurato il
tutto per sfruttare al meglio le funzionalità della GPU.
 
Se non hai installato driver closed il driver in uso dovrebbe
esssere:
 
amdgpu
 
Prova intanto a postare gli output indicati e vediamo se c'è la
conferma.
 
 
PS.
Anticipo, se vuoi già dare un'occhiata per avere una panoramica
della fazenda:
 
https://wiki.archlinux.org/title/Hardware_video_acceleration
 
 
Ma prima posta l'output così partiamo dalla base.

 Graphic Core Next 4 (CGN 4)
 
Ad ogni modo questo non cambia, penso che sia solo un dettaglio
quindi, ma va be', vedremo poi nel seguito delle verifiche...

 Ma prima posta l'output così partiamo dalla base.
 


> 
https://wiki.archlinux.org/title/Hardware_video_acceleration
 
 
-------
AMD/ATI
 
AMD and ATI open-source drivers support both VA-API and VDPAU:
 
    VA-API on Radeon HD 2000 and newer GPUs is supported by libva-mesa-driver.
    VDPAU on Radeon R300 and newer GPUs is supported by mesa-vdpau.
 
AMDGPU PRO proprietary driver is built on top of AMDGPU driver
and supports both VA-API and VDPAU in addition to AMF.
 
    AMF on Fiji and newer GPUs supported by amf-amdgpu-proAUR.
--------------------------------------------------------------
 
Stando per ora sul versante open amdgpu lì sembra che ci siano due
possiblità:
 
- VA-API
- VDPAU
 
Se salti al paragrafo 2 hai un'idea di come verificare. Troverai il
test finale con mpv circa come abbiamo già fatto ieri... incluso htop
che ti avevo suggerito per vedere il carico lato CPU e radeontop che
però è specificato no mostrare il carico GPU relativo ad operazioni
di decodifica o codifica.
 
Per prima cosa suggerirrei quindi di verificare con
 
vainfo
 
se è presente va-api.
 
Se il comando non c'è installa
 
libva-utils

 libva-utils
 
$ vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 23.0.3 for AMD Radeon RX 550 
Series (polaris11, LLVM 15.0.6, DRM 3.52, 6.3.1-desktop-1.mga9)
vainfo: Supported profile and entrypoints
       VAProfileMPEG2Simple            : VAEntrypointVLD
       VAProfileMPEG2Main              : VAEntrypointVLD
       VAProfileJPEGBaseline           : VAEntrypointVLD
       VAProfileNone                   : VAEntrypointVideoProc
 
 
$ vdpauinfo
display: :0   screen: 0
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared 
object file: No such file or directory
Error creating VDPAU device: 1
 
 
Interessante che il costruttore possa avere fatto "pasticci" ... :)


 Interessante che il costruttore possa avere fatto "pasticci" ... :)
 
:D :D Beh a rigor di logica poteva usare un altro nome: se hai già in
commercio la RX550 con chip Lexa - Polaris 12... e vuoi riciclare
i chip Baffin o rilanciarli in un "corpo scheda" RX550, non chiamarla
più RX550, ma non so, RX549. Per lo meno non si diventa matti per capire
cosa si compra e cosa si ha nel case. Va be' era una battuta da
ignorante, avranno avuto i loro motivi, fatto sta che il nome del
prodotto sarebbe meglio fosse univoco ripspetto alle caratteristiche.

Il manualino che mi hai linkato prosegue con:
 
# journalctl -b --grep='vdpau | dri driver'
mag 10 21:04:21 localhost plasmashell[6252]: Failed to open VDPAU 
backend libvdpau_radeonsi.so: cannot open shared object file: No such 
file or directory
mag 10 21:04:21 localhost plasmashell[6252]: Failed to open VDPAU 
backend libvdpau_radeonsi.so: cannot open shared object file: No such 
file or directory
mag 10 21:05:00 localhost plasmashell[6252]: Failed to open VDPAU 
backend libvdpau_radeonsi.so: cannot open shared object file: No such 
file or directory
mag 10 21:05:00 localhost plasmashell[6252]: Failed to open VDPAU 
backend libvdpau_radeonsi.so: cannot open shared object file: No such 
file or directory
 
con:
$ grep -iE 'vdpau | dri driver' xorg_log_file
grep: xorg_log_file: No such file or directory
 
 
io ho tutto journalizzato eccetto dmesg che funziona ancora.
 
A questo punto non saprei andare avanti. L'unica cosa che mi viene in 
mente è installare:
 
lib64vdpau-driver-radeonsi - VDPAU plugin for radeonsi driver​
 
ma sto andando a caso...



Vedo, vedo... :D
Nulla di male.
 
Però mi sa che ti sei perso il mio ultimo messaggio. Non mi riepto qui
per non annoiare...
Leggi il messaggio e posta gli output suggeriti, fai sapere che interessa
anche a me!

 prodotto sarebbe meglio fosse univoco ripspetto alle caratteristiche.
 
Ho letto che il chip Baffin è più vecchio dell'uscita della RX550, 
quindi mi hanno venduto una scheda che è solo nominalmente una 550 :( Ho 
scelto Shappire proprio perché l'ho sentita nominare molte volte ...


 MPEG2_MAIN                      3 65536  4096  4096
 
ho provato a fare dei test ma la decodifica hw pare non sia fatta:
 
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V203 MPG - MPEG-2 1080p 24fps 
8bit - AC32.0.mpg'
 
  (+) Video --vid=1 (mpeg2video 1920x1080 24.000fps)
  (+) Audio --aid=1 (ac3 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:20 / 00:00:31 (66%) A-V:  0.000
 
Exiting... (Quit)
 
eppure pare supportato il file mpeg2 e ho abilitato il codec vdpau sia 
installando il driver e sia abilitandolo in mpv.
 
Sbaglio qualche cosa?



Intanto ho fatto un gran casino io, ho fatto confusione, non so perché
con qualche altra discussione in cui il contesto era una dervata di Arch
di cui non ricordo neanche il nome.
Poi quando ho visto urpmi, m'è venuta in mente Mandrake Mandriva ora
Mageia... che con Arch non c'entra un piffero.
 
Il wiki di arch comunque non è mai da buttare via... però controllo,
e fallo anche tu, con qualche ricerca in rete su come si ottiene la
decodifica hardware su Mageia.
 
Mi confermi che parliamo di Mageia 9 beta 1:
 
https://blog.mageia.org/en/2023/02/28/mageia-9-beta1-is-already-here/
 
 
Quella roba lì giusto?
 
Sei sicuro di aver impostato correttamente i repository in modo che
urpm punti a quelli della 9 beta 1?
 
Del tipo installi lib64vdpau1 per la stabile e sulla beta 1 poi non
gira... A volte se si fa l'upgrade del sistema intero può capitare di
incorrere in configurazioni del package managere che restano vecchie e
vanno riviste. Io non conosco mageia direttamente, non so come l'hai
installata ecc, quindi vedi te su questo punto.
 
In ogni caso, per non saper né leggere né scrivere... se non hai
problemi a rischiare che il sistema smetta di funzionare (non dovrebbe
ma non so cosa ci fai e il rischio di incasinare c'è sempre)... io
fare un bell'aggiornamento di tutti i pacchetti:
 
- annoterei la roba aggiunta extra parco software ufficiale
- toglierei la roba aggiunta di cui sopra
- aggiornerei tutti i pacchetti installati al repo della tua versione
  di mageia
 
E già così parti da una base pulita.
Poi riaggiungi i pacchetti extra ufficiali e si riprova.
 
Siccome può essere una procedura un po' tortuosa (non è detto, ma
ripeto non conosco bene mageia e non so cosa hai installato sopra
il sistema oltre al software ufficiale e come lo hai fatto) magari
prima cerca bene in rete mageia hardware decoding amdgpu.
 
Se fosse qualche codec mancante in ffmpeg non dovresti proprio
riuscire a riprodurre i video, quindi escluderei quell'inghippo.
 
Se hai pacchetti che avevi compilato su eventuale vecchia versione
di mageia e poi hai aggiornato, potrebbero non funzionare bene, ma
direi che on funzionerebbero del tutto piuttosto che a mezza via.
 
In ogni caso partire dal sistema pulito "vanilla" è sempre una
sicurezza e porta vantaggi in generale.
 
Mentre scrivo mi viene in mente anche un'altra possibilità più estrema:
se hai spazio potresti fare una partizione temporanea, installare lì
mageia pulita e rifare le prove con mpv.
 
A quel punto se riesci a far funzionare da lì, sarà molto più semplice
capire dove sta il problema nel sistema principale magari più "vissuto",
e facilmente incasinato.

 scelto Shappire proprio perché l'ho sentita nominare molte volte ...
 
 
Mah, secondo me quello è l'ultimo dei problemi, cioè se c'era il chip
polaris 12 lexa forse era meglio (non è detto, parlo da ignorante e
si spera sempre che il nuovo sia meglio del vecchio, ma a volte non è
così, quindi prendere con pinze). Ma mooooolto probabilmente ti saresti
accorto della differenza solo in sofisticatissimi e maniacali
benchmarks. Per cui non mi fisserei su questo punto, tanto ormai il
pachetto t'è arrivato ed è in uso...
 
Fai una cosa al volo, butta l'output del comando seguente:
 
mpv --hwdec=help|cut -f 3 -d " "|uniq|grep -v copy|tail -n +2
 
 
Oltre a quanto suggerito sull'aggiornamento del sistema
nell'altro mio messaggio... MPV come lo hai installato?
da pacchetto ufficiale?

 da pacchetto ufficiale?
 
Tutti i miei pacchetti sono stati installati dai repository ufficiali.


 e facilmente incasinato.
 
Potrei farlo quando esce la versione stabile di Mageia 9 che magari è 
"meno incasinata" della versione beta.


 Tutti i miei pacchetti sono stati installati dai repository ufficiali.
 
OK. Niente bisogna cercare un po' di più in rete mi sa...
 
Io nel frattempo ho ricordato che avevo anche impostato
una variabile d'ambiente attraverso uno script apposito
che mi pare fosse inlcuso nel pacchetto libvdpau, su
slackware però...
 
Dacci un'occhiata:
-----------------------------
# cat /etc/profile.d/vdpau.sh
-----------------------------
#!/bin/sh
 
# Disable debugging output of the vdpau backend
export VDPAU_LOG=0
 
# Use the vdpau backend of the nvidia binary driver
export VDPAU_DRIVER="nvidia"
 
# Use the vdpau backend of the nouveau driver
#export VDPAU_DRIVER="nouveau"
 
# Use the vdpau backend of the r300 driver
#export VDPAU_DRIVER="r300"
 
# Use the vdpau backend of the r600 driver
#export VDPAU_DRIVER="r600"
 
# Use the vdpau backend of the radeonsi driver
#export VDPAU_DRIVER="radeonsi"
 
# Use the va-api/opengl backend
#export VDPAU_DRIVER="va_gl"
---------------------------
 
Questo file non fa altro che settare la variabile
 
VDPAU_DRIVER
 
al valore coerente col driver in uso.
Come vedi nel mio caso l'unico valore non commentato è :
 
export VDPAU_DRIVER="nvidia"
 
perché nel mio caso sto usando il driver proprietario,
chiamato proprio "nvidia", e per dire a VDPAU che voglio
sfruttare l'API vdpau stessa con quel driver indico in
modo esplicito attraverso quella variabile di shell.
 
Come vedi in caso di utilizzo di altri driver, come il tuo
il valore da attribuire a VDPAU_DRIVER è sicuramente diverso.
Lì in quello script ci sono dei candidati papabili, che qualcuno
ha già buttato lì, ma sono tutti commentati.
Sta all'utente decomentare il valore giusto per la propria
scheda video e driver in uso.
Ti dico subito che dubito anche se tu stai usando il driver
di nome
 
amdgpu
 
Non è detto che quello sia anche il valore da settare lì.
Anzi, da quanto ho visto potrebbe essere "radeonsi" nel tuo
caso.
 
https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuration
 
 
Alla fine è lo stesso discorso spiegato qui, link di ieri
paragrafo successivo a quello già visto per la verifica.
Dovevamo solo proseguire insomma, alla fine si torna sempre
sul wiki di Arch...
 
Per capire il nome del driver da attribuire a VDPAU_DRIVER
---------------------------------------------
# grep -iE 'vdpau | dri ' /var/log/Xorg.0.log
[    26.976] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia
----------------------------------------------------------
 
Io non ho l'altra riga con "DRI driver". Non chiedere perché.
 
Ad ogni modo veniamo al succo:
-------
VA-API:
You can override the driver for VA-API by using the LIBVA_DRIVER_NAME
environment variable:
 
AMD:
    For AMDGPU driver use radeonsi.
 
Per cui mi sa proprio che ci siamo... "radeonsi" dovrebbe proprio
essere il valore da attribuire alla tua variabile d'ambiente,
datti conferma con la verifica qui sopra, io azzardo in pratica:
 
LIBVA_DRIVER_NAME=radeonsi
 
-----
VDPAU
You can override the driver for VDPAU by using the VDPAU_DRIVER
environment variable.
 
For the open source AMD driver set it to the proper driver version
depending on your GPU, see #Verification
 
Qui è un po' laconico, ma dalla verifica sopra del log di Xorg
direi che va messo quel valore... nel tuo caso, anche vedendo
l'esempio al paragrafo "configuring" del wiki immagino ti ritorni
qualcosa del tipo:
 
(II) RADEON(0): [DRI2] VDPAU driver: radeonsi
 
E pertanto alla fine dovrai impostare:
 
VDPAU_DRIVER="radeonsi"
 
-----------------------
 
 
Insomma all fine avendo conferma da sopra, puoi fare la seguente prova:
(se non hai conferma da sopra fermati e non copiare pedissequamente ma
adatta)
 
- apri un terminale bash e dai:
 
export VDPAU_DRIVER="radeonsi"
export LIBVA_DRIVER_NAME="radeonsi"
 
Ora sempre dallo stesso terminale (se no è inutile) rifai la prova delle
info:
 
vainfo
 
vdpauinfo
 
Quindi riprova anche il test di decodifica hardware con mpv, prova a non
forzare prima (quindi "auto"), poi a forzare vaapi e quindi vdpau.
 
mpv --no-config --vo=gpu --hwdec=auto
 
In teoria già così potrebbe decidere di utilizzare la decodifica
hardware ottimale...
In caso contrario prova come hai già fatto a forzare la mano:
 
mpv --no-config --vo=gpu --hwdec=vaapi
 
E poi:
 
mpv --no-config --vo=gpu --hwdec=vdpau
 
 
Posta l'output di tutto quanto, non solo degli ultimi test,
altrimenti non ci posso capire nulla di più.
 
Domanda al volo, il sistema da te utilizza di default Xorg o Wayland?
Perché nel primo caso quello che ho scritto ha un senso, altrimenti
non ne ho idea.
 
Happy tuning  :)

 Happy tuning  :)
 
Grazie :)


 1.1xx, so it cannot be used in Mageia 9.
 
Ottimo, ti stavo per consigliare di provare coi driver proprietari... :D
 
Boh altre cose non mi vengono in mente.
 
Non si sa mai che ci sia qualche parametro del kernel da aggiungere
all'avvio.
 
In alternativa puoi provare qualche altra distribuzione in una
partizione o altro disco... Un mese fa ho preso un Crucial mx500
da 500 GB a 40 €. Lì di spazio per prove di questo genere ne hai.
Ma probabilmente se hai appena installato puoi farti senza problemi
enne partizioni da tipo 10 GB e installare più sistemi per provare,
partendo da qualcosa che conosci abbastanza bene in cui sai muoverti
oppure qualcosa di molto documentato tipo anche fedora, debian, ubuntu,
arch... non ti dico slackware, ma alla fine perché no.
 
Altra alternativa, prova a chiedere su forum frequentati tipo
linuxquestions.org
, o qualcosa di più specifico per la tua
distribuzione, se quello di mageia è troppo poco frequentato, prova
con quello di fedora. Purtroppo è tutto in inglese, meno comodo
di icoli, ma decisamente più probabile ricevere risposte azzeccate.

 di icoli, ma decisamente più probabile ricevere risposte azzeccate.
 
Comunque mi puoi riassumere la situazione con parole tue perché io non 
ho capito tutti i passaggi che hai fatto e mi hai fatto fare che 
significato hanno.
 
Per esempio è un problema i pochi decoder che vdpauinfo mostra? Il 
problema principale è che mpv non mostra mai la decodifica hardware? Altro?
 
Grazie del grosso aiuto anche se pare non sia risolutivo penso sia un 
grosso passo avanti.


 vlc-plugin-vdpau
 
 
Allora qui potresti assicurarti di quali acchetti hai installato,
posta l'ou del comando seguente:
 
rpm -qa | grep -i vdpau
 
Tra quelli sopra io mi assicurerei di avere:
-----------
lib64vdpau1
lib64vdpau-driver-radeonsi
vaapi-driver-vdpau
vdpauinfo
---------
 
Ricapitolando:
 
1. avere pacchetti sopra installati
 
2. impostare variabili d'ambiente VDAPU_DRIVER e LIBVA_DRIVER_NAME
 
3. testare vdpauinfo e vainfo
 
4. testare con mpv e hwdec (auto, vdpau, vaapi)
 
5. provare aggiungere 10-amdgpu.conf in dir xorg.conf.d/
 
6. tornare a punto (2)

 6. tornare a punto (2)
 
ok. Manca un GOTO 6 all'ultimo punto :)
 
Comunque al primo step posso dire che vdpauinfo e vainfo non cambiano se 
si settano o non settano le variabili di shell. Comunque dopo il primo 
passaggio si ha in sintesi:
 
$ vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.16.0
libva info: User environment variable requested driver 'radeonsi'
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 23.0.3 for AMD Radeon RX 550 
Series (polaris11, LLVM 15.0.6, DRM 3.52, 6.3.1-desktop-1.mga9)
vainfo: Supported profile and entrypoints
       VAProfileMPEG2Simple            : VAEntrypointVLD
       VAProfileMPEG2Main              : VAEntrypointVLD
       VAProfileJPEGBaseline           : VAEntrypointVLD
       VAProfileNone                   : VAEntrypointVideoProc
 
e per $vdpauinfo:
 
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  --- not supported ---
H264_MAIN                      --- not supported ---
H264_HIGH                      --- not supported ---
VC1_SIMPLE                     --- not supported ---
VC1_MAIN                       --- not supported ---
VC1_ADVANCED                   --- not supported ---
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
 
Quindi nulla è cambiato o almeno a me pare così.
Per le prove con mpv su due file video:
 
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V203 MPG - MPEG-2 1080p 24fps 
8bit - AC32.0.mpg'
  (+) Video --vid=1 (mpeg2video 1920x1080 24.000fps)
  (+) Audio --aid=1 (ac3 2ch 48000Hz)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:10 / 00:00:31 (32%) A-V:  0.000
 
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
 
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:31 / 00:00:31 (99%) A-V:  0.000
No video PTS! Making something up. Using 29.970030 FPS.
AV: 00:00:31 / 00:00:31 (99%) A-V:  0.000
 
Exiting... (End of file)
 
non compare mai la decodifica hardware in tutti i 6 casi: 
hwdec=vaapi/vdpau/auto
file mpeg2video e mpeg4.
 
mettendo il file di configurazione per Xorg si ha:
 
i due info danno sempre lo stesso numero di codec disponibili, mpv da 
gli stessi risultati tra cui:
 
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:07 / 00:00:31 (24%) A-V:  0.000
 
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=auto 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:07 / 00:00:31 (24%) A-V:  0.000
 
Exiting... (Quit)


 MPEG4_PART2_ASP                 5 65536  4096  4096
 
Infatti, anche lì Niente H264 e niente VC1.
Credo che anche H265 ricada nello stesso problema di "patenting".
 
Cioè niente no... i video li vedi, ma la funzionalità in grado
di sfruttare la decodifica hardware della GPU è coperta da
una licenza di redistribuzione.
Quella funzionalità, per le schede AMD e driver open, nel tuo caso
amdgpu, viene introdotta attraverso il pacchetto mesa, probabilmente
spezzettato in più pacchetti, che richiamano le varie API che abbiamo
visto VA-API e VDPAU e i driver "radeonsi".
 
https://www.mesa3d.org/
 
 
Prova un po' un "urpmi" per cercare nei repo il pattern "mesa".
Hai tutti i repositories attivati? anche quelli non free e quelli
extra che mi pare per mageia siano i repo chiamati "tainted"?
 
Prova anche il comando rpm -qa |grep mesa, come avevi fatto l'ultima
volta per vdpau, così vediamo cosa c'è sui repo di inerente e cosa
invece hai installato.
 
Non installare nulla di più per il momento, gaurdiare e non toccare. ;)
 
 
Ho trovato parecchie discussioni che lamentano il problema.
I primi ad "accorgersi" di questo "vulnus" sono stati gli sviluppatori
di redhat (che credo non abbiano probelemi a pagare diritti) ma se ho ben
capito avrebbero comunicato il problema al team di fedora che invece è
tecnicamente free software. Allora per non sapere né leggere né scrivere
a fedora hanno iniziato a rilasciare il pacchetto mesa compilato senza
il supporto all'accelerazione hardware per i codec patentati.
Quindi c'è ancora mesa ovviamente, ma di default non supporta più le
funzionalità di hardware encoding della GPU per i video codificati con
formati patentati H264,5,VC1 ecc... prendi con pinze perché potrebbero
esserci imprecisioni.
 
Ad ogni modo in pratica cosa si può fare?
 
Compilare mesa attivando il supporto ai codec desiderati.
Per uso personale e non dovendoli redistribuire a nessuno, non si
incorre in problemi di patenti credo... in ogni caso praticamente
si può fare ecco.
 
C'è qualcuno che lo ha già fatto per l'utenza Fedora a quanto pare
e il pacchetto mesa con attivato tutto dovrebbe essere reperibile
attraverso il loro repo denominato "Fusion".
 
Per OpenSuse addirittura ho visto che hanno un builder che lavora
in cloud: tu modifichi il file SPEC dell'rpm (attivando le funzionalità
che in quello di default sono bloccate) e lanci il build. Il tutto viene
compilato sul loro server remoto dove gira una opensuse aggiornata,
a quel punto ti scarichi il pacchetto è lo installi con yast.
 
In Mageia purtroppo non ho trovato indicazioni precise.
Per quello ti consigliavo di vedere se nei repo "esotici" della tua
versione si trovino dei pacchetti relativi a "mesa" che potrebbero
essere compilati con tutte le funzionalità attivate.
Capito bene se quelli sono ciò che ti serve, e possibilmente non
prima a casaccio, devi capire come sostituire i pacchetti di default
con quelli corrispondenti "esotici".
 
Ad esempio in Fedora (nel link c'è molto di più che potrebbe anche
interessare, darci un occhio è utile):
 
https://rpmfusion.org/Howto/Multimedia?highlight=%28%5CbCategoryHowto%5Cb%29
 
--------------------------
Hardware Accelerated Codec
 
Hardware codecs with AMD (mesa)
 
# Using the rpmfusion-free section This is needed since Fedora 37 and
# later... and mainly concern AMD hardware since NVIDIA hardware with
# nouveau doesn't work well
 
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
-------------------------------------------------------------
 
In pratica si dovrebbe capire come ottenere con Mageia la stessa cosa.

 In pratica si dovrebbe capire come ottenere con Mageia la stessa cosa.
 
https://forums.mageia.org/en/viewtopic.php?f=15&t=14828&p=87030&hilit=h.264#p87030
 
 
 
What's Mageia's stance on removing codecs from mesa?
 
Jan 4th, '23, 07:08
If you have paid attention to Linux news, you surely know that Fedora, 
OpenSUSE and Manjaro removed codecs from Mesa. These codecs make AMD GPU 
users unable to properly use certain codecs (h.264, h.265).
Is Mageia going to remove these codecs from Mesa in Version 9?
 
Io scriverei nel forum di Mageia questo post:
 
Hi, I have installed the beta1 version of Mageia 9 and am using an RX550 
video card with the open radeonsi driver. It seems to me that the 
drivers are correctly installed and that vdpauinfo and vainfo recognise 
that everything is OK. Despite this the hardware decodings are not 
enabled and mpv never allows me to decode mpeg4 as well as h.264 and 
h.265 in hardware. Any tips?



Sì può andare, aggiungici anche "amdgpu" vicino a radeonsi, per evitare
confusioni col driver open radeon per vecchie schede ATI/AMD.
Sicuramente ti daranno indicazioni o al massimo ti rimanderanno a
contattare gli sviluppatori.
 
 
Nel frattempo ti dico la mia.
Per quanto abbia cercato, anche nel repo "tainted", mi pare che un
eventuale pacchetto "mesa" contenente roba non distribuibile sul repo
ufficiale non ci sia...
Dico anche che forse facendo il build del pacchetto mesa, potrebbero
saltar fuori più pacchetti rpm così generati. E che il nostro pacchetto
da ricercare non sia precisamente "mesa" ma qualcos'altro che viene
prodotto quando compili mesa dal suo SRPM, cioè il pacchetto rpm sorgente.
 
Alla fine forse la cosa più speditiva sarebbe provare direttamente, non
so quanto tu sia avvezzo a compilare software utilizzando tutti i crismi
di mageia... devo dirre che su slackware è un po' più semplice questo
passaggio, ma il succo non cambia. E l'importante è aver cognizione di
cosa si sta facendo, poi l'ambiente cambia ma non troppo.
 
In sintesi:
 
1. tiri giù il pacchetto rpms di mesa, puoi farlo anche con urpm
   qualcosa. Io ho provato dal browser ovviamente:
 
   mesa-23.1.0-2.mga9.src.rpm
 
2. poi segui un po' sta roba:
 
 
https://wiki.mageia.org/en/Packaging_for_beginners#Quick_.26_Dirty:_How_to_go_from_SRPM_to_RPM
 
 
   in pratica devi crearti un ambiente di sviluppo che non è altro che
   una banale directory in cui vai ad estrarre in qualche modo il
   pacchetto sopra.
 
3. a questo punto cerchi il file "spec", precisamente si chiama
   "mesa.spec", fantasia vendiamone...
 
4. devi modificarne il contenuto aggiungendo il supporto ai codec:
 
 
https://www.carteakey.dev/building-mesa-vaapi-fedora/
 
 
   lì mostrano la modifica apportata al build di "meson". Io l'ho
   cercato nel file spec e in effetti ora viene compilato così:
   --------
   %meson \
     -Dcpp_std=gnu++17 \
     -Dplatforms=x11,wayland \
     -Ddri3=enabled \
     -Dosmesa=true \
   -----------------
 
   Tu dovresti aggiungervi di seguito la riga seguente:
   --------------------------------------------------
     -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec \
   ----------------------------------------------------------
 
   l'ultimo backslash l'ho aggiunto io ma direi che ci vuole.
 
5. ora devi eseguire il build del nuovo pacchetto mesa personalizzato
 
6. qui vado alla cieca, verranno prodotti uno o più pacchetti rpm,
   non so dove te li piazza, può darsi nella cartella di build
   o non so, leggi bene il wiki di mageia linkato sopra, c'è un
   esempio per il pacchetto "texworks".
 
7. capito cosa è stato creato devi andare ad installare i nuovi
   rpm, in modo da sovrascrivere gli omonimi vecchi già installati.
   Puoi anche rimuoverli prima e installare i nuovi dopo.
   Se qualcosa va storto reinstalli i vecchi ovviamente...
 
Le istruzioni su come portare a termine i punti qui sopra sono
ben descritte nel wiki, o magari sai già utilizzare meglio di
me i vari tool urpm e rpm e già hai capito come proseguire.
 
La cosa significativa è l'aggiunta della riga coi codec.
Il resto lo trovi.
C'è un po' da leggere se sei alle prime armi, ma la possibilità di
sfruttare l'hardware appieno oqquasi penso sia una buona motivazione.
 
 
PS.
In Slackware in questi casi si prende la webdir del pacchetto sorgente
di interesse dal repo ufficiale per mesa ad esempio, ci si entra, si
edita lo slackbuild, e lo si lancia. Il nuovo pacchetto me lo ritrovo
in /tmp. E da lì lo installo con installpkg.

    l'ultimo backslash l'ho aggiunto io ma direi che ci vuole.
 
Spetta, ho fatto casino...
Nel file mesa.spec hai la sezione di build di meson, che è bella
lunga:
------
%build
%meson \
  -Dcpp_std=gnu++17 \
  -Dplatforms=x11,wayland \
  -Ddri3=enabled \
  -Dosmesa=true \
%ifarch %{ix86}
  -Dsse2=false \
%endif
%if 0%{?with_hardware}
  -Dgallium-drivers=swrast,virgl,nouveau,r300%{?with_crocus:,crocus}%{?with_i915:,i915}%{?with_iris:,iris}%{?with_vmware:,svga}%{?with_radeonsi:,radeonsi,r600}%{?with_freedreno:,freedreno}%{?with_etnaviv:,etnaviv}%{?with_tegra:,tegra}%{?with_vc4:,vc4}%{?with_v3d:,v3d}%{?with_kmsro:,kmsro}%{?with_lima:,lima}%{?with_panfrost:,panfrost}%{?with_vulkan_hw:,zink} \
%else
  -Dgallium-drivers=swrast,virgl \
%endif
  -Dgallium-vdpau=%{?with_vdpau:enabled}%{!?with_vdpau:disabled} \
  -Dgallium-omx=%{?with_omx:bellagio}%{!?with_omx:disabled} \
  -Dgallium-va=%{?with_vaapi:enabled}%{!?with_vaapi:disabled} \
  -Dgallium-xa=%{?with_xa:enabled}%{!?with_xa:disabled} \
  -Dgallium-nine=%{?with_nine:true}%{!?with_nine:false} \
%if 0%{?with_opencl}
  -Dgallium-opencl=%{?with_opencl:icd}%{!?with_opencl:disabled} \
%endif
  -Dvulkan-drivers=%{?vulkan_drivers} \
  -Dvulkan-layers=device-select \
  -Dshared-glapi=enabled \
  -Dgles1=enabled \
  -Dgles2=enabled \
  -Dopengl=true \
  -Dgbm=enabled \
  -Dglx=dri \
  -Degl=enabled \
%if 0%{?with_glvnd}
  -Dglvnd=true \
%endif
  -Dgallium-extra-hud=true \
  -Dlmsensors=enabled \
  -Dmicrosoft-clc=disabled \
  -Dllvm=enabled \
  -Dshared-llvm=enabled \
  -Dvalgrind=%{?with_valgrind:enabled}%{!?with_valgrind:disabled} \
  -Dbuild-tests=false \
  -Dselinux=false \
  -Dandroid-libbacktrace=disabled \
  %{nil}
%meson_build
------------
 
OK lì in mezzo inserisci la riga -Dvideo-codecs=ecc...ecc..
incluso il backslash in fondo come le altre righe, tanto per
fare un esempio qua c'è il PKGBUILD di arch:
 
https://github.com/archlinux/svntogit-packages/blob/packages/mesa/trunk/PKGBUILD
 
 
E qui lo slackbuild per mesa su Slackware-current (lì mette una variabile CODECS
contenente i vari h264 ecc ecc come nella riga vista in cima al post):
 
https://mirrors.slackware.com/slackware/slackware64-current/source/x/mesa/mesa.SlackBuild
 
 
Insomma la questione sembra sia stata un po' interpretata a piacere per il
momento. Noi ne approfittiamo per scopiazzare le istruzioni di build e
ottenere il pacchetto finale così come ci serve.

 in /tmp. E da lì lo installo con installpkg.
 
non è tanto diverso in mageia, solo un paio di comandi di più.
 
Però prima di proseguire a fare modifiche su mesa che è un po' 
pericoloso perché potrei trovarmi senza interfaccia grafica se sbaglio 
qualche cosa, vorrei rispondere a Doktor 5000 del forum di mageia in 
modo tale da capire se il problema è mesa.


 modo tale da capire se il problema è mesa.
 
Al limite puoi sempre reinstallare il pacchetto mesa di default.
 
Per compilare mesa, immagino ti serva qualche pacchetto targato -devel.
Non mi fisserei su quale di preciso "a priori": provi a lanciare il
build e se qualcosa manca dovrebbero saltarti fuori degli avvertimenti
ed errori che specificano cosa manca e da lì metti i pacchetti inerenti.
Fai tutto con urpm e un paio di ricerche in google, è una sciocchezza.
 
Inoltre finché non installi il nuovo pacchetto non corri rischi...
 
Va be' vedi tu, prova a chiedere sulla lista che ti hanno consigliato.

 Va be' vedi tu, prova a chiedere sulla lista che ti hanno consigliato.
 
Innanzitutto ti ringrazio per la grande consulenza che mi hai dato. Vado 
a scrivere il post e vediamo se ricevo risposta da quelli del forum.


 a scrivere il post e vediamo se ricevo risposta da quelli del forum.
 
Sì bene, metti anche un link qui, tanto per completezza.
A me sta cosa ha incuriosito, ed è un aspetto che riguarda chiunque
abbia GPU AMD e relativi driver open, mi sembra importante fare
chiarezza sulla questione mesa e codec sbloccati anche per la decodifica
hardware... non è un aspetto marginale soprattutto per chi non ha
PC con processori supercarrozzati.
 
Per cui fai un favore se tieni linkata questa discussione usenet
al forum e alla mailing list di mageia.
 
 
Ti anticipo che ho fatto un tentativo anch'io alla fine.
Non ho hardware AMD su cui testare la configurazione, però
ho provato se non altro ad installare Mageia 9 in macchina
virtuale, io uso la trafila qemu/kvm, libvirt e virt-manager.
 
Prima di scendere nel dettaglio magari in un prossimo post,
sintetizzo:
 
1. ho lavorato con urpm* e com rpmbuild da riga di comando
   per avere maggiore chiarezza e poter poi riportare meglio
   i passaggi anche qui eventualmente
 
2. ho sistemato i repo
 
3. ho aggiunto il repo per i sorgenti SRPM
 
4. ho installato i pacchetti di sviluppo necessari per
   ricompilare il pacchetto "mesa"
 
5. ho scariato ed estratto sempre via urpmi il pacchetto
   src.rpm di "mesa"
 
6. ho infine tentato il "build" con rpmbuild sul mesa.spec
 
7. ho fatto la prova sia col mesa.spec modificato con l'aggiunta
   del supporto ai codec come già indicato qui in precedenza
 
8. ho fatto la stessa prova di build con il file mesa.spec
   originale
 
Il problema è che la compilazione non arriva in fondo.
Salta fuori un errore e sembrerebbe più un bug che l'assenza
di qualcosa di necessario per la costruzione del pacchetto,
anche perché la roba devel che sarebbe servita la dovrebbe
aver installata regolarmente al punto 4:
 
urpmi --buildrequires mesa
 
Cercando l'errore in rete non ho trovato nulla di utile
per capire quale sia il problema, certo mi sembra quasi
impossibile che non funzioni, almeno usando il mesa.spec
originale: se il pacchetto rpm di mesa è distribuito vuol
dire che è stato creato dal team che lo ha rilasciato insieme
al resto della distribuzione per cui il build deve funzionare
in un modo o nell'altro. Forse manca qualcosa sul sistema
che ho installato io e non viene rilevato né da urpmi né
in fase di configure prima della compilazione di mesa.
 
Eventualmente potrei provare con un'installazione di Mageia
stabile, la 8 mi pare, e vedere se si verifica lo stesso
inghippo anche lì, alla fine la 9 è una distribuzione di
sviluppo e qualche incasinamento dovuto a recenti aggiornamenti
potrebbe essere anche da mettere in conto.

 Ti anticipo che ho fatto un tentativo anch'io alla fine.
 
Hai fatto un lavorone :)
Da qui in poi ho tradotto:

Ho tradotto il post con un traduttore automatico, l'ho modificato un po' 
e messo nel forum di Mageia:
 
https://forums.mageia.org/en/viewtopic.php?f=15&t=14932&p=87677#p87677
 
 
Non mi fido molto a scrivere nella mailing list perché non l'ho mai 
fatto e poi io sono un principiante...
 
https://ml.mageia.org/l/info/dev
 


 
https://forums.mageia.org/en/viewtopic.php?f=15&t=14932&p=87677#p87677
 
 
Questa la risposta che ho ottenuto:
 
postby doktor5000 » May 18th, '23, 19:37
 
     kensan wrote:
     You should add the following line below:
     ------------------------------------------------
     -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec \
     ------------------------------------------------
 
 
That's exactly what I mentioned earlier.
But if you don't create a bugreport for this, probably nothing will change.
 
Secondo me questo doktor ha capito poco della questione, se gli 
sviluppatori del pacchetto mesa hanno tolto il supporto ai codec è ovvio 
che se io apri un bug report su mageia allora segnalano la cosa upstream 
ma senza successo perché il supporto l'hanno tolto volontariamente e per 
un buon motivo.
 
In alternativa possono avere tolto il supporto direttamente chi gestisce 
il pacchetto mesa all'interno di mageia ma siamo sempre la.
 
Posso aprire un bug report con la speranza che il mantainer del 
pacchetto risponda alla domanda collaterale di come mai l'srpm non si 
pacchettizza e hai quell'errore.
 
https://wiki.mageia.org/en/How_to_report_a_bug_properly#Reporting_a_New_Bug
 
 
https://bugs.mageia.org/
 
 
Oppure un bug diretto all'impossibilità di compilare l'srpm.
 
Suggerimenti?


 
https://ml.mageia.org/l/info/dev
 
 
Niente di ché, una volta iscritto, invii il messaggio all'indirizzo
email della lista. È una sciocchezza.
 
La tua traduzione postata là mi sa che non potrà avere troppe risposte
se non c'è qualcuno che voglia provare la ricreazione dell'RPM di mesa
sulla sua mageia. Tra l'altro manca il dettaglio dei comandi che avevo
dato per lo scopo... per utenti ed esperti di quella distribuzione sono
sicuramente più comprensibili al volo che non tante parole, tradotte in
automatico per di più.
 
Va be' io nel frattempo faccio una prova con Mageia 8.
Al limite posso anche unirmi alla tua richiesta sui canali "development"
della mailing list. Consiglio comunque di scrivere pochi punti:
 
- versione distribuzione (Mageia 9 va bene - sottinteso aggiornata)
 
- modello scheda video
 
- driver in uso
 
- problema: mancata decodifica hardware
 
- ipotesi causa: mesa compilato senza supporto codecs
 
- altri tentativi di ricompilazione non riferirli se non li esegui
  in prima persona, perché solo così sarai in grado di comunicare
  i dettagli necessari affinché riescano ad orientarsi nella tua
  situazione.
 
 
Nel frattempo anche tu puoi provare a ricreare l'RPM di mesa:
 
https://wiki.mageia.org/en/URPMI#RPM_sources
 
 
È una sciocchezza...
 
lì mancano però due comandi:
 
1. l'url del repo dei sorgenti è farlocco, usa invece:
 
 
su -
password:  --> così diventi root e ti ritrovi in /root.
 
Poi:
 
urpmi.addmedia "Core Sources" 
http://mageia.mirror.garr.it/mirrors/mageia/distrib/9/SRPMS/core/release/
 
 
urpmi --install-src mesa (questo crea la subdir "rpmbuild" e varie
                          sottocartelle)
 
urpmi --buildrequires mesa  (questo installa l'occorrente per
                             compilazione ecc)
 
mettici anche che non si sa mai:
 
urpmi --auto-update  (così sei sicuro di avere tutti i pacchetti
                      aggiornati allo stesso progresso della disto)
 
e infine lanci il build:
 
rpmbuild -bb rpmbuild/SPECS/mesa.spec
 
 
Se ti funziona bene, poi ti dico come proseguire.
Se invece se ne esce con errore dovrai salvarti la paginata
così da poterlo riportare a chi chiedi aiuto. Ci sarà anche
qualche file di log tra le subdir di "rpmbuild"...


Prova per conto tuo a creare il pachetto rpm di mesa,
vedi i dettagli sull'altro mio post che ho inviato pochi
miuti fa.
 
Se funziona la compilazione rifai il test col nuovo
mesa, e se sblocca l'hwdec benissimo. A quel punto puoi
comunicare i passaggi fatti sul forum di mageia a futura
memoria e nel frattempo sfruttare meglio la tua scheda
video.
 
Se ottieni errori nella compilazione come è accaduto a me,
ti presenti sulla mailing di devel, oppure anche sul forum
e chiedi lumi su dove possa stare il problema, ma dovrai
riportargli la parte di schermata in cui esce l'errore, se
no non ti sapranno aiutare molto probabilmente.
 
Se non riesci a copiare la schermata con l'errore, ne
parleremo...
 
Ciao

 Ciao
 
Nota a margine mi sono accorto che aggiornando da terminale il mio 
sistema con # urpmi.update -a mi dare un errore con wget. Ho dovuto 
cambiare i link dei repository per quelli finlandesi non funzionavano, 
In effetti era da qualche settimana che non avevo più aggiornamenti 
mentre di solito avevo un aggiornamento ogni 2 giorni. Comunque vainfo e 
vdpauinfo non sono cambiati anche dopo avere aggiornato il sistema.



Per quanto riguarda i repositories, io avevo usato il comando suggerito
dal wiki, però siccome da me in macchina virtuale non ha funzionato la
compilazione né su Mageia 9, e neanche su Mageia 8, non saprei se
consigliarti di fare altrettanto... ad ogni modo io avevo lanciato
questo comando:
 
urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST'
 
Facendo così mi aggiunge i repo del mirror italiano "
garr.it
" in
automatico.
Aggiunge solo i Core e Nonfree, ma visto che stiamo ricompilando
un pacchetto che fa parte di Core, dovrebbero bastare.
Aggiungere i repo Tainted e attivarli sarebbe stato utile se
contenessero un pacchetto RPM mesa già pronto con i codecs sbloccati,
invece in ogni caso occorre crearselo in locale, per cui Core dovrebbe
essere sufficiente.
 
La riga aggiunta va bene in quella posizione tra "%meson" e "%{nihl}",
se la sbagliassi mettendola da altre parti credo che ti dia errore
subito, uscendo dalla procedura immediatamente.
Confermo i tempi, anzi, se tu in "bare metal" ci metti 20 minuti, immagina
quanto impiega il mio vecchio core2 quad a compilare mesa dentro
macchina virtuale... anche da me la cpu va a 100%, credo sia abbastanza
normale, per lo meno si sfrutta tutta la potenza dell'hardware!  ;)
 
I warnings per il momento ignorali bellamente.
 
Infine per quanto riguarda tutti i pacchetti devel che sono stati
installati, forse, e dico forse... non essendo stati installati
direttamente ma via "buildrequires" se hai seguito le mie indicazioni,
potrebbero essere forse rimossi dopo che avrai finito di testare
tutto quanto con:
 
urpme --auto-orphans
 
Non ne sono sicuro e non ho trovato informazioni in tal senso,
ma non ho cercato troppo... 200 pacchetti alla fine non sono
un'esagerazione. Avere uno spazio di 30GB in sù oggigiorno non
è un problema.
 
 
-------- OT ----------------------
Si trova roba inerente al software "Mock", un sistema pensato
per i pacchettizzatori capace di eseguire tutto il lavoro di
build in un ambiente isolato che non coinvolgerebbe il sistema
reale su cui gira... in partica fai il build e aggiungi quello
che serve per farlo entro questo "chroot", dopodiché salvi gli
RPM creati e butti via tutto il resto, dopodiché installi gli
RPM sul sistema vero.
Ovvio che un sistema del genere dovrebbe funzionare per un rebuild
di qualcosa che già gira sul sitema, tipo il nostro "mesa". Ma
se tu vlessi aggiungere un pacchetto che non c'è in mageia e ne
creassi l'RPM con Mock, dopo non è detto che funzioni sul sistema
reale perché apotrebbe aver bisogno di dipendenze assenti, installate
invece nel chroot di Mock.
--------------------------
 
Bene, prova con la modifica dello spec file e fai sapere ciao!

 Bene, prova con la modifica dello spec file e fai sapere ciao!
 
la compilazione è andata a buon fine, poi ho dato:
 
$ sudo urpmi mesa-23.1.0-2.mga9.x86_64.rpm
[sudo] password for sandro:
Package mesa-23.1.0-2.mga9.x86_64 is already installed
$ sudo urpmi --reinstall mesa-23.1.0-2.mga9.x86_64.rpm
 
 
SECURITY: The following package is _NOT_ signed (OK ((none))): 
mesa-23.1.0-2.mga9.x86_64.rpm
installing mesa-23.1.0-2.mga9.x86_64.rpm
Preparing... 
##############################################################################################
       1/1: mesa 
##############################################################################################
       1/1: removing mesa-23.1.0-2.mga9.x86_64
 
##############################################################################################
 
ho controllato il file spec:
 
   -Dlmsensors=enabled \
   -Dmicrosoft-clc=disabled \
   -Dllvm=enabled \
   -Dshared-llvm=enabled \
   -Dvalgrind=%{?with_valgrind:enabled}%{!?with_valgrind:disabled} \
   -Dbuild-tests=false \
   -Dselinux=false \
   -Dandroid-libbacktrace=disabled \
   -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec \
   %{nil}
%meson_build
 
 
quindi era ok
 
i due info non sono cambiati (vainfo e vdpauinfo)
 
ma devo installare altri pacchetti oltre che mesa.rpm? Ci sono un sacco 
di rpm nella cartella x64 della compilazione.
 
name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  --- not supported ---
H264_MAIN                      --- not supported ---
H264_HIGH                      --- not supported ---
VC1_SIMPLE                     --- not supported ---
VC1_MAIN                       --- not supported ---
VC1_ADVANCED                   --- not supported ---
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
 
ok, mi sono deciso di installare anche il driver radeonsi e adesso 
funziona vdpauinfo:
 
[x86_64]$ ls
lib64d3d1-23.1.0-2.mga9.x86_64.rpm 
lib64mesaopencl-devel-23.1.0-2.mga9.x86_64.rpm
lib64d3d1-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64mesavulkan-devel-23.1.0-2.mga9.x86_64.rpm
lib64d3d-devel-23.1.0-2.mga9.x86_64.rpm 
lib64mesavulkan-drivers-23.1.0-2.mga9.x86_64.rpm
lib64dri-drivers-23.1.0-2.mga9.x86_64.rpm 
lib64mesavulkan-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64dri-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64osmesa8-23.1.0-2.mga9.x86_64.rpm
lib64gbm1-23.1.0-2.mga9.x86_64.rpm 
lib64osmesa8-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64gbm1-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64osmesa-devel-23.1.0-2.mga9.x86_64.rpm
lib64gbm-devel-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-nouveau-23.1.0-2.mga9.x86_64.rpm
lib64glapi0-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-nouveau-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64glapi0-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-r600-23.1.0-2.mga9.x86_64.rpm
lib64glapi-devel-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-r600-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaegl1-23.1.0-2.mga9.x86_64.rpm
 
**lib64vdpau-driver-radeonsi-23.1.0-2.mga9.x86_64.rpm
 
lib64mesaegl1-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-radeonsi-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaegl-devel-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-virtio_gpu-23.1.0-2.mga9.x86_64.rpm
lib64mesagl1-23.1.0-2.mga9.x86_64.rpm 
lib64vdpau-driver-virtio_gpu-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesagl1-debuginfo-23.1.0-2.mga9.x86_64.rpm 
lib64xatracker2-23.1.0-2.mga9.x86_64.rpm
lib64mesagl-devel-23.1.0-2.mga9.x86_64.rpm 
lib64xatracker2-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv1_1-23.1.0-2.mga9.x86_64.rpm 
lib64xatracker-devel-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv1-devel-23.1.0-2.mga9.x86_64.rpm
 
**mesa-23.1.0-2.mga9.x86_64.rpm
 
lib64mesaglesv2_2-23.1.0-2.mga9.x86_64.rpm
mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv2-devel-23.1.0-2.mga9.x86_64.rpm
mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesakhr-devel-23.1.0-2.mga9.x86_64.rpm
mesa-debugsource-23.1.0-2.mga9.x86_64.rpm
lib64mesaopencl1-23.1.0-2.mga9.x86_64.rpm
mesa-omx-drivers-23.1.0-2.mga9.x86_64.rpm
lib64mesaopencl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
mesa-omx-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
 
$ vdpauinfo
name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  52 65536  4096  4096
H264_MAIN                      52 65536  4096  4096
H264_HIGH                      52 65536  4096  4096
VC1_SIMPLE                      1 65536  4096  4096
VC1_MAIN                        2 65536  4096  4096
VC1_ADVANCED                    4 65536  4096  4096
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
H264_CONSTRAINED_BASELINE       0 65536  4096  4096
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
VP9_PROFILE_0                  --- not supported ---
VP9_PROFILE_1                  --- not supported ---
VP9_PROFILE_2                  --- not supported ---
VP9_PROFILE_3                  --- not supported ---
HEVC_MAIN                      186 65536  4096  4096
HEVC_MAIN_10                   186 65536  4096  4096
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---
HEVC_MAIN_444_10               --- not supported ---
HEVC_MAIN_444_12               --- not supported ---
AV1_MAIN                       --- not supported ---
AV1_HIGH                       --- not supported ---
AV1_PROFESSIONAL               --- not supported ---
 
vainfo non funziona perché forse manca la libreria correlata?
 
mpv non funziona con:
$ mpv --no-config --vo=gpu --hwdec=vdpau
 
Comunque sei bravissimo, complimenti, non ci speravo... :)


 ottimo, complilazione eseguita con successo! :)
 
 
Anzitutto assicurati di avere installato TUTTI gli RPM
che sono stati prodotti dal rebuild dello spec di mesa.
In rpmbuild c'è la sub-directory RPMS che contiene appunto
i pacchetti rpm prodotti dalle operazioni di build, tutto
piuttosto ovvio.
Lì dentro ci sono quindi tutti pacchetti coerenti tra
loro... intendo, hai impostato il mesa.spec modificando
la riga dei codec, e questa potrebbe aver generato nuovi
pacchetti anche loro con funzionalità in più rispetto a
quelli ufficiali della distribuzione, quindi vanno
installati al posto degli originali.
 
Ma facciamola più semplice:
 
- hai riconfigurato mesa.spec
 
- hai ottenuto enne rpm
 
- ora devi installarli tutti
 
- e in modo che se alcuni di essi erano già presenti
  sul sistema, vengano rimpiazzati dai nuovi che hai
  prodotto... facile
 
In pratica io farei qualcosa del tipo:
 
cd rpmbuild/RPMS
urpmi --reinstall *rpm
 
oppure, non so che differenza c'è, ma ho trovato anche
 
urpmi --replacepkgs *rpm
 
È fondamentale essere certi che urpmi installi gli
rpm che hai prodotto in locale, ovviamente, e non
li peschi di nuovo dal repo remoto, altrimenti quanto
fatto è evidentemente inutile... lo scrivo ma mi pare
banalmente ovvio. Insomma devi essere sicuro di avere
installati non più i pacchetti originali ma quelli che
ti sei creato appsitamente per far funzionare la scheda
video.
 
In slackware per assicurarsi di questo si aggunge un "TAG"
al nome del pacchetto, in modo che sia poi riconoscibile
e appaia targato, "alien", "SBo", "pippo", "custom",
"handbuilt" o quel che vuoi, basta che poi sia riconoscibile.
Sicuramente si può fare la stessa cosa andando a modificare
il file "spec" per gli rpm immagino. Va be' ormai che hai fatto
lascia così... spero che passando ad urpmi in modo esplicito i
file rpm realmente presenti nella dir RPMS sia sufficiente per
essere sicuri di avere installati i nuovi pacchetti.
 
Assicurato di avere TUTTI i nuovi rpm e non più i vecchi:
 
va-info
 
vfpauinfo
 
mpv --noconfig --vo=gpu --hwdec=auto
 
mpv --noconfig --vo=gpu --hwdec=vdpau
 
mpv --noconfig --vo=gpu --hwdec=vaapi
 
Metti gli output completi in modo ordinato altrimenti non
si capisce. Cose del tipo "non funziona" lasciano il tempo
che trovano, bisogna vedere cosa esce a terminale per
capirci qualcosa.

 di rpm nella cartella x64 della compilazione.
 
Devi installare tutti i pacchetti rpm generati nella subdir
 
rpmbuild/RPMS
 
TUTTI, vedi bene l'altro mio messaggio lo ripeto anche qui.
Potrebbero essere anche in ulteriori subdir tipo
 
rpmbuild/RPMS/x86_64
 
Insomma vedi tu... dove sono gli RPM per capirci.

 capirci qualcosa.
 
ok.
 
Altri test con Mpeg2:
 
AUTO
$  mpv --no-config --vo=gpu --hwdec=auto 'V203 MPG - MPEG-2 1080p 24fps 
8bit - AC32.0.mpg'
  (+) Video --vid=1 (mpeg2video 1920x1080 24.000fps)
  (+) Audio --aid=1 (ac3 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:03 / 00:00:31 (10%) A-V:  0.000
 
Exiting... (Quit)
 
VAAPI
$  mpv --no-config --vo=gpu --hwdec=vaapi 'V203 MPG - MPEG-2 1080p 24fps 
8bit - AC32.0.mpg'
  (+) Video --vid=1 (mpeg2video 1920x1080 24.000fps)
  (+) Audio --aid=1 (ac3 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:02 / 00:00:31 (7%) A-V:  0.000
 
Exiting... (Quit)
 
VDPAU
$  mpv --no-config --vo=gpu --hwdec=vdpau 'V203 MPG - MPEG-2 1080p 24fps 
8bit - AC32.0.mpg'
  (+) Video --vid=1 (mpeg2video 1920x1080 24.000fps)
  (+) Audio --aid=1 (ac3 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:05 / 00:00:31 (17%) A-V:  0.000
 
Exiting... (Quit)
 
Altri test con mpeg4:
 
AUTO
$  mpv --no-config --vo=gpu --hwdec=auto 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:06 / 00:00:31 (20%) A-V:  0.000
 
Exiting... (Quit)
 
VAAPI
$  mpv --no-config --vo=gpu --hwdec=vaapi 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:05 / 00:00:31 (18%) A-V:  0.000
 
Exiting... (Quit)
 
VDPAU
$  mpv --no-config --vo=gpu --hwdec=vdpau 'V001 AVI - MPEG-4 XVID NTSC 
480p - MP32.0.avi'
  (+) Video --vid=1 (mpeg4 720x480 29.970fps)
  (+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
AV: 00:00:05 / 00:00:31 (18%) A-V:  0.000
 
Exiting... (Quit)
 
***
 
Ciao, comincia a funzionare :)


Questa è la lista dei pacchetti rpm:
 
lib64d3d1-23.1.0-2.mga9.x86_64.rpm
lib64mesaopencl-devel-23.1.0-2.mga9.x86_64.rpm
lib64d3d1-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesavulkan-devel-23.1.0-2.mga9.x86_64.rpm
lib64d3d-devel-23.1.0-2.mga9.x86_64.rpm
lib64mesavulkan-drivers-23.1.0-2.mga9.x86_64.rpm
lib64dri-drivers-23.1.0-2.mga9.x86_64.rpm
lib64mesavulkan-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64dri-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64osmesa8-23.1.0-2.mga9.x86_64.rpm
lib64gbm1-23.1.0-2.mga9.x86_64.rpm
lib64osmesa8-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64gbm1-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64osmesa-devel-23.1.0-2.mga9.x86_64.rpm
lib64gbm-devel-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-nouveau-23.1.0-2.mga9.x86_64.rpm
lib64glapi0-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-nouveau-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64glapi0-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-r600-23.1.0-2.mga9.x86_64.rpm
lib64glapi-devel-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-r600-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaegl1-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-radeonsi-23.1.0-2.mga9.x86_64.rpm
lib64mesaegl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-radeonsi-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaegl-devel-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-virtio_gpu-23.1.0-2.mga9.x86_64.rpm
lib64mesagl1-23.1.0-2.mga9.x86_64.rpm
lib64vdpau-driver-virtio_gpu-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesagl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64xatracker2-23.1.0-2.mga9.x86_64.rpm
lib64mesagl-devel-23.1.0-2.mga9.x86_64.rpm
lib64xatracker2-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv1_1-23.1.0-2.mga9.x86_64.rpm
lib64xatracker-devel-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv1-devel-23.1.0-2.mga9.x86_64.rpm
mesa-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv2_2-23.1.0-2.mga9.x86_64.rpm
mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
lib64mesaglesv2-devel-23.1.0-2.mga9.x86_64.rpm
mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
lib64mesakhr-devel-23.1.0-2.mga9.x86_64.rpm
mesa-debugsource-23.1.0-2.mga9.x86_64.rpm
lib64mesaopencl1-23.1.0-2.mga9.x86_64.rpm
mesa-omx-drivers-23.1.0-2.mga9.x86_64.rpm
lib64mesaopencl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
mesa-omx-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
 
Tutti i pacchetti debuginfo non li ho installati, i pacchetti devel li 
ho installati solo se erano già installati, gli altri pacchetti come:
 
lib64d3d1-23.1.0-2.mga9.x86_64.rpm
 
se non erano installati non li ho installati nella nuova versione 
modificata.
 
va bene così?


 va bene così?
 
Io li avrei installati tutti. Per non saper ne leggere ne scrivere.
Caso mai potrai sempre disinstallari in un secondo momento visto che
ne hai la lista.
Ti basterà qualcosa come:
 
cd ${dir degli RPM}
for in *debuginfo*rpm; do
    urpme $i
done
 
Questo per i "debuginfo".
 
Invece credo non sia corretto il discorso di lasciare indietro i
nuovi pacchetti creati che non erano installati in precedenza.
Siccome sei in una fase diciamo così, di test di questa manovra,
abbonda pure con l'installazione, sicuramente così non sbagli.
Eventualmente in un secondo momento potrai provare a sfoltire
qualcosa, ma informandoti su cosa contengono e a cosa servono
i pacchetti che rimuovi.
 
Non hai tutti i torti, è probabile che alcuni pacchetti "-devel"
creati servano installati solo in caso di compilazione di ulteriore
software che li richiede in build-time, roba che a te potrebbe non
servire al momento, però prima di toglierli devi capire quali
esattamente ed essere certo di quello che realmente non serve.
 
Tieni anche conto che se in futuro dovrai compilare qualcosa
diciamo "pippo-vulkan" che in buildtime ha bisogno ad esempio
di:
 
lib64mesavulkan-devel
 
Cosa accade?
 
Posso sbagliarmi, ma si potrbbe ottenere una installazione "incoerente".
Mi spiego:
 
- hai ricompilato e installato "mesa-custom"
- il quale ha generato anche "lib64mesavulkan-devel" (custom anche lui)
- non lo installi perché non ti serve subito
- te ne dimentichi
- poi fra tot mesi, vuoi compilare un software che dipende da mesavulkan
- lanci il tuo bravo "urpmi --install-src pippo-vulkan"
- installi le dipendenze per compilarlo "urpmi --buildrequires"
- e urpmi ti installerà lib64mesavulkan-devel
- ma qui casca l'asino perché quello lì sopra sarà il mesavulkan
  ufficiale, originale, che si aspetta di lavorare con mesa originale.
- così ti ritroverai con installati mesa-custom, ma mesavulkan-devel originale
 
Può darsi che un'incoerenza del genere non porti a nulla, come che
possa compromettere la compilazione dell'ipotetico pippo-vulkan o
peggio possa portare ad un pippo-vulkan che non funziona bene e non
ti dà errori, al ché ti ritrovi con malfunzionamenti senza sapere
perché e dove cercare il problema.
 
Purtroppo customizzare il sistema comporta queste problematiche, è
inevitabile... ed è anche un po' scomodo. Ma alla fine secondo me è
accettabile se è il prezzo da pagare per avere l'hardware supportato
e funzionante. D'altra parte quell'hardware lo hai pagato 100 e usarlo
al 20% sarebbe in ogni caso uno spreco.
 
Questo discorso è tanto più vero in fase di aggiornamento del sistema,
 
urpmi --auto-update
 
verosimilmente ti andrà a togliere il tuo nuovo mesa, e a mettere quello
originale. Non sono sicuro di quale criterio userà ma ad esempio se
in mageia 9 introdurranno una versione più recente di mesa, quasi
sicuramente il tuo mesa custom verrà sovrascritto dall'rpm del repo che
avrà versione maggiore rispetto alla tua.
 
In quel caso dovrai nuovamente rifare il build, partendo dai sorgenti
srpm del mesa nuovo, editare lo spec e lanciare rpmbuild...
Come dicevo avere un sistema custom non è comodo.
Sarebbe preferibile se rilasciassero in qualche repo affidabile l'rpm
di mesa precompilato comprensivo di supporto ai codec patentati, ma
non so se sia possibile, forse in qualche server ubicato in paesi in cui
quel cavillo di licenza può essere ignorato, ma non dipende da noi,
quindi alla fine si fa prima a ricompilare e accettare un po' di
scomodità in più.
 
In ambito di utilizzo del sistema io mi regolo aggiornando la parte
"core" del parco software, quindi sincronizzandola con il repo
ufficiale, solo ogni tot mesi.
Questo perché non ho esigenze critiche su patches inerenti la sicurezza
e allo stesso tempo ho parecchio software di terze parti compilato
"contro" i pacchetti "core", cioè "che si appoggia" e potrebbe dipendere
dal "core" dell'ultimo aggiornamento.
Se facessi un aggiornamento del "core" dovrei ricreare parecchi
pacchetti, e non sarebbe un'operazione veloce e indolore. Questo discorso
non vale per pacchetti di software non "core", tipo il browser web, il
client mail e altra roba che aggiorno frequentemente e che sta dicamo
così ad "alto livello". In poche parole tocco poco spesso le "fondamenta",
e mi limito ad aggiornare se mi serve solo i "piani alti".
 
Purtroppo "mesa" fa parte delle fondamenta, è un pacchetto fondamentale
per tanti altri che vi si appoggiano sopra. In teoria, ad essere
pignoli, modificando mesa, si dovrebbe ricompilare anche tutti i
pacchetti che vi dipendo in cascata, e anche indirettamente... poi
nella pratica vista la modifica "piccola" non credo che sia necessario,
se no a quel punto userebbero tutti Gentoo.

 AV: 00:00:31 / 00:00:31 (100%) A-V:  0.000
 
Qui invece c'è qualcosa che non va...
o meglio "vdpau" sembra non sfruttarlo in hardware.
 
Facciamo una prova più di dettaglio allora:
 
1.
Imposta la variabile d'ambiente VDPAU ecc ecc come
avevamo detto:
 
export VDPAU_DRIVER=radeonsi
 
 
2.
Poi riprova sia con hwdec auto che vdpau, come segue
 
mpv --log-file=mpv-auto.log --no-config --vo=gpu --hwdec=auto
 
mpv --log-file=mpv-vdpau.log --no-config --vo=gpu --hwdec=vdpau
 
In questo modo ti avrà creato anche due file di log:
 
mpv-auto.log
mpv-vdpau.log
 
 
3.
Ora fai così:
 
cat mpv-auto | nc 
termbin.com
 9999
 
cat mpv-vdpau | nc 
termbin.com
 9999
 
Ti restituiranno due links che incollerai nel tuo mesasggio,
in queso modo posso scaricarli e analizzarli un attimo meglio.

 Io li avrei installati tutti. Per non saper ne leggere ne scrivere.
 
Domani li installo tutti e mi segno il nome dei file che ho installato 
ex novo. Poi faccio le prove che mi hai indicato nell'altro post.


 ex novo. Poi faccio le prove che mi hai indicato nell'altro post.
 
Già che sei di strada segnateli tutti:
 
find rpmbuild/RPMS -iname "*rpm" | cut -f3 -d\/ > mesa-rebuild-rpms.log
 
Così sai che quelli lì non sono pacchetti ufficiali e basta, ma pacchetti
ufficiali potenzialmente customizzati attraverso il rebuild di mesa.
Un domani volessi tornare a quelli ufficiali, con solo installati quelli
che hai ora, ci deve essere il modo attraverso
 
A quel punto se vuoi fotografare la situazione di quali hai installato
attualmente in modo da distinguerli da quelli che aggiungerai
installandoli tutti, puoi fare una cosa tipo (non testato):
 
for package in $(cat mesa-rebuild-rpms.log); do
    if (rpm -qa | grep -q $package); then
        echo -e "$package\tnew installed"
    else
        echo -e "$package\treplaced"
    fi
done > mesa-rebuild-restore.log
 
A questo punto ti puoi già fare addirittura lo script per tornare
alla situazione originaria oqquasi (restano i pacchetti devel
aggiunti con --buildrequires).
 
In pratica se vorrai togliere i pacchetti nuovi non presenti prima
del rebuild e dell'installazione di tutto il set di pacchetti custom
derivanti da mesa, farai qualcosa tipo:
 
for package in (grep "new installed" mesa-rebuild-restore.log | cut -f1); do
    urpme $package
done
 
Volendo potrai anche toglierli tutti e poi aggiungere solo quelli
installati in origine, scaricandoli di nuovo dal repo con urpmi,
in modo da tornare al set ufficiale (con cui però no hai decoding
via GPU). Però per capirci il modo di tornare indietro c'è ecco.

 via GPU). Però per capirci il modo di tornare indietro c'è ecco.
 
si e mi pare funzioni.
 
$ for package in $(grep "replaced" mesa-rebuild-restore.log | cut -f1); 
do     echo -e $package; done
lib64mesavulkan-drivers
lib64xatracker2
lib64gbm1
lib64glapi0
lib64dri-drivers
lib64osmesa8
lib64mesaegl1
mesa
lib64vdpau-driver-radeonsi
lib64mesagl1
lib64mesaglesv2_2


 io conosco bene solo il Php.
 
Fai prima a farlo a mano, una volta che hai i pacchetti
elencati in un file di testo... ad ogni modo se il pattern
è il seguente:
 
nome-versione-build.distrib.arch.rpm
 
considerando che il nome può contenere il "trattino",
si può vedere come un insieme di campi separati dal
trattino, e sappiamo che buttando via gli ultimi due
campi "versione" e "build.distrib.arch.rpm", resta
solo il nome. Bisogna lavorare dal fondo, o rigirare
la frittata:
 
echo lib64vdpau-driver-nouveau-debuginfo-23.1.0-2.mga9.x86_64.rpm \
     | rev | cut -f1,2 -d- --complement |rev
 
il primo "rev" stampa al contrario la stringa, così
gli ultimi due campi diventano i primi. Per buttarli
via usi cut con delimiter "trattino" e --complement,
in pratica stampa tutto tranne i primi due campi.
A quel punto rigiri di nuovo la stringa con "rev".
Provare per credere.
 
Hai ragione comunque, nell'eventuale ritorno ai pacchetti
ufficiali anche la versione che si trova sul repo potrebbe
essere cambiata nel frattempo rispetto al corrispondente
generato in locale, qundi va usato un elenco di pacchetti
col solo nome, senza la versione ecc... la lista col nome
intero può andar bene solo per rimuoverli con urpme, in
quel caso dovrebbe proprio funzionare comunque. Invece per
reinstallare gli ufficiali no, serve solo il nome pulito.

 perché e dove cercare il problema.
 
Comunque io esegui compilazioni ogni morte di un Papa.

Si è un problema. Cercherò di vedere se c'è gente che si è mossa per 
togliermi le castagne dal fuoco con un repository apposito, mi pare che 
sai la soluzione più efficace e nel frattempo dovrò arrangiarmi 
compilando ogni tanto mesa.
 
Per adesso non ho null'altro di customizzato per cui non ho l'esigenza 
di fare come te e cioè non aggiornare il core se non di tanto in tanto.


 di fare come te e cioè non aggiornare il core se non di tanto in tanto.
 
Te lo auguro, comunque se qualcosa non funzionerà più dopo qualche
aggiornamento saprai dovre potrebbe trovarsi il problema e nel caso
ricompili mesa ecc...

 reinstallare gli ufficiali no, serve solo il nome pulito.
 
Anche questo ma rpm -qa funziona solo con il pacchetto dal nome semplice:
 
rpm -qa lib64vdpau-driver-nouveau-debuginfo-23.1.0-2.mga9.x86_64.rpm
 
non funziona ma funziona solo:
 
rpm -qa lib64vdpau-driver-nouveau-debuginfo
 
per cui ho dovuto avere la lista col nome senza la versione in numero.


 parte della lista degli rpm prodotti.
 
Non avevo fatto attenzione. In pratica installando mesa -common-devel mi 
chiede due pacchetti dipendenti e quindi ho fatto come mi hai detto: li 
ho installati dai repo o comunque ha fatto tutto lui. Ecco i comandi:
 
$ sudo urpmi --reinstall mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
 
To satisfy dependencies, the following packages are going to be installed:
   Package                        Version      Release       Arch
(medium "Core Release")
   lib64freeglut-devel            3.4.0        1.mga9        x86_64
   lib64mesaglu1-devel            9.0.2        3.mga9        x86_64
(command line) <=======================
   mesa-common-devel              23.1.0       2.mga9        x86_64
2.2MB of additional disk space will be used.
916KB of packages will be retrieved.
Proceed with the installation of the 3 packages? (Y/n) Y
 
 
     $MIRRORLIST: 
media/core/release/lib64mesaglu1-devel-9.0.2-3.mga9.x86_64.rpm
     $MIRRORLIST: 
media/core/release/lib64freeglut-devel-3.4.0-1.mga9.x86_64.rpm 
 
SECURITY: The following package is _NOT_ signed (OK ((none))): 
mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
installing /var/cache/urpmi/rpms/lib64mesaglu1-devel-9.0.2-3.mga9.x86_64.rpm
/var/cache/urpmi/rpms/lib64freeglut-devel-3.4.0-1.mga9.x86_64.rpm
mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
Preparing... 
#####################################################################################################
       1/3: lib64mesaglu1-devel 
#####################################################################################################
       2/3: lib64freeglut-devel 
#####################################################################################################
       3/3: mesa-common-devel 
#####################################################################################################
 
adesso dovrebbe essere tutto ok e quindo procedo con il test di cui mi 
dicevi alcuni giorni fa.


 mpv --noconfig --vo=gpu --hwdec=vaapi
 
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V204 MKV - AVC 1080p 24fps 
8bit - AAC2.0.mkv'
  (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
Using hardware decoding (vaapi).
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:02 / 00:00:31 (9%) A-V:  0.000
 
Exiting... (Quit)
 
****************************************************
 
Con le due variabili esportate:
 
$ export VDPAU_DRIVER="radeonsi"
$ export LIBVA_DRIVER_NAME="radeonsi"
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V204 MKV - AVC 1080p 24fps 
8bit - AAC2.0.mkv'
  (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:03 / 00:00:31 (12%) A-V:  0.000
 
Exiting... (Quit)
 
Per completezza mostro pure i vdpauinfo:
 
$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
 
Video surface:
 
name   width height types
-------------------------------------------
420    16384 16384  NV12 YV12
422    16384 16384  UYVY YUYV
444    16384 16384  Y8U8V8A8 V8U8Y8A8
420_16 16384 16384
422_16 16384 16384
444_16 16384 16384
 
Decoder capabilities:
 

$ vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.16.0
libva info: User environment variable requested driver 'radeonsi' 
<==========================================
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 23.1.0 for AMD Radeon RX 550 
Series (polaris11, LLVM 15.0.6, DRM 3.52, 6.3.3-desktop-1.mga9)
vainfo: Supported profile and entrypoints
       VAProfileMPEG2Simple            : VAEntrypointVLD
       VAProfileMPEG2Main              : VAEntrypointVLD
       VAProfileVC1Simple              : VAEntrypointVLD
       VAProfileVC1Main                : VAEntrypointVLD
       VAProfileVC1Advanced            : VAEntrypointVLD
       VAProfileH264ConstrainedBaseline: VAEntrypointVLD
       VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
       VAProfileH264Main               : VAEntrypointVLD
       VAProfileH264Main               : VAEntrypointEncSlice
       VAProfileH264High               : VAEntrypointVLD
       VAProfileH264High               : VAEntrypointEncSlice
       VAProfileHEVCMain               : VAEntrypointVLD
       VAProfileHEVCMain               : VAEntrypointEncSlice
       VAProfileHEVCMain10             : VAEntrypointVLD
       VAProfileJPEGBaseline           : VAEntrypointVLD
       VAProfileNone                   : VAEntrypointVideoProc
 
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V204 MKV - AVC 1080p 24fps 
8bit - AAC2.0.mkv'
  (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
Using hardware decoding (vaapi). <==========================
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:03 / 00:00:31 (11%) A-V:  0.000
 
Exiting... (Quit)
 
$ mpv --no-config --vo=gpu --hwdec=auto 'V204 MKV - AVC 1080p 24fps 8bit 
- AAC2.0.mkv'
  (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
Using hardware decoding (vaapi).<===========================
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:02 / 00:00:31 (7%) A-V:  0.000
 
Exiting... (Quit)
 
Provando con un altro file ho notato che VLC non fa salire l'uso del 
processore (3%):
 
***
 
$ mpv --no-config --vo=gpu --hwdec=vdpau '200506_Kitchen 
Food_03_4k_009.mp4'
  (+) Video --vid=1 (*) (h264 3840x2160 25.000fps)
VO: [gpu] 3840x2160 yuv420p
V: 00:00:18 / 00:00:18 (100%)
Exiting... (End of file)
 
Qui invece sale oltre il 20% (26% circa)
 
***
 
$ mpv --no-config --vo=gpu --hwdec=auto '200506_Kitchen Food_03_4k_009.mp4'
  (+) Video --vid=1 (*) (h264 3840x2160 25.000fps)
Using hardware decoding (vaapi).
VO: [gpu] 3840x2160 vaapi[nv12]
V: 00:00:18 / 00:00:18 (100%)
 
Exiting... (End of file)
 
Qui rimane al 3%.
 
***
 
Non mi è chiaro Youtube, vorrei sperimentare qualche video da YT in 
h.264 ma non trovo la sezione apposita. Ci dovrebbe essere perché a suo 
tempo avevano creato una sezione per il VP8 e penso che ci sia anche per 
gli altri de-codec.
 
Comunque direi che mi posso accontentare.


 gli altri de-codec.
 
Ho trovato questo:
 
 
H.264 or VP9 for encoding for YouTube?
 
🌐 
video.stackexchange.com
 › questions › 16324 › 
h-264-or-vp9-for-encoding-for-youtube
 
tl;dr: Since Youtube reencodes all videos regardless of the upload 
format, it really isn't that important. Just export your video with a 
high bitrate to preserve quality. Also see my answer here regarding 
quality loss caused by Youtube.
 
Long answer: Each reencoding of a video to a compressed format lowers 
the quality. Usually, that means you'll lose quality at two points: When 
you export the edited video from your editing software and when you 
upload the exported video to Youtube, at which point it is reencoded to 
a highly compressed, streaming-compatible format. You have no control 
over that second step, so what you can do to achieve the maximum quality 
possible is make sure you lose as little quality as possible during the 
first encoding.
In theory, that would mean export to a perceptually (even though 
technically not) uncompressed format like Apple ProRes or DNxHD as you 
suggested. However, unfortunately, Youtube doesn't support those 
formats, so you'll have to use a compressed format. To minimize quality 
loss, set a high bitrate in your export settings (assuming rendering and 
upload time aren't an issue. If they are, you'll have to find some 
middle ground; exporting with a bitrate that is higher than the bitrate 
of the source material won't yield any more quality, so that is as high 
as I would go). If you do that, it doesn't really matter which codec you 
use, both are highly efficient regarding file-size/quality ratio (VP9 
probably a bit more so, but that's more important when you're dealing 
with low bitrates). Youtube recommends H264, so that's what I would use. 
However, the best advice I can give you is to try out both, i.e. export 
the same video as both H264 and VP9 with identical bitrates/other 
settings, upload both to youtube and check which one looks better to you.
Answer from MoritzLost on Stack Exchange
 
Quindi mi pare di capire che YT non abbia un formato di riproduzione 
standard. mah...


 H.264 or VP9 for encoding for YouTube?
 
Mah.. lì parlano di "codifica", cioè creare un video da cariare
sul tubo.
A te interessa invece tirare giù un video dal tubo già codificato
in uno specifico formato per poi provarne la riproduzione, ovvero
testarne la decodifica in modo da verificare se viene fatta in
hardware dalla GPU o via software dal processore.
 
Per questo scopo puoi utilizzare yt-dlp con cui scarichi il video
(e anche l'audio) scegliendo il formato audio+video per quel dato
video. Una volta che lo hai in locale fai il solito test con mpv.
 
Anche se VDPAU non sembra supportato neanche dopo il rebuild di
mesa, prova lo stesso sia con --hwdec=auto che --hwdec=vdpau, anche
con altri formati tipo VP8, VP9, H265, AV1, quel che è...
Non serve più invece che forzi vaapi, perché almeno dai test che
hai incollato nell'altro post, quanto scegli "auto" mpv sceglie
vaapi, quindi è inutile poi rifare il test con hwdec=vaapi, per lo
stesso file di input almeno. Se cambi formati dell'input invece,
scegliendo "auto" potrebbe anche scegliere un'altra API per la
decodifica.
Insomma parti sempre da "auto" ed evntualmente in un secondo momento
testa le API che NON sono state scelte automaticamente al primo giro,
ad esempio se con auto sceglie vaapi forza solo vdpau...
 
La tua scheda in qualche modo dovrebbe supportare hardware decoding
per VC1, H264, H265, e frose anche VP8. AV1 sicuramente no, e nanche
VP9.
 
Sul tubo trovi roba codificata in VP9 e in AVC1. Quest'ultimo dovrebbe
essere molto molto simile ad H264, almeno per testare la decodifica
hardware della tua scheda sono intercambiabili. Invece VP9 no, è roba
diversa e come dicevo, prova ma la tua scheda non dovrebbe essere in
grado di decodificarlo in hardware.
 
In sintesi (ne riporto solo un pezzo):
 
yt-dlp -F "
https://www.youtube.com/watch?v=LXb3EKWsInQ
"
 
ID  EXT   RESOLUTION FPS HDR CH │   FILESIZE    TBR PROTO │ VCODEC           VBR ACODEC      ABR ASR MORE INFO
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
22  mp4   1280x720    30      2 │ ~ 63.98MiB  1669k https │ avc1.64001F    1669k mp4a.40.2    0k 44k 720p
136 mp4   1280x720    30        │   57.61MiB  1540k dash  │ avc1.4d401f    1540k video only          720p, mp4_dash
247 webm  1280x720    30        │   45.33MiB  1212k dash  │ vp9            1212k video only          720p, webm_dash
298 mp4   1280x720    60        │   92.61MiB  2476k dash  │ avc1.4d4020    2476k video only          720p60, mp4_dash
302 webm  1280x720    60        │   72.78MiB  1946k dash  │ vp9            1946k video only          720p60, webm_dash
398 mp4   1280x720    60 10     │   43.10MiB  1152k dash  │ av01.0.08M.10  1152k video only          720p60 HDR, mp4_dash
698 mp4   1280x720    60 10     │  117.45MiB  3140k dash  │ av01.0.08M.10  3140k video only          720p60 HDR, mp4_dash
334 webm  1280x720    60 10     │  162.31MiB  4339k dash  │ vp9.2          4339k video only          720p60 HDR, webm_dash
299 mp4   1920x1080   60        │  163.71MiB  4377k dash  │ avc1.64002a    4377k video only          1080p60, mp4_dash
303 webm  1920x1080   60        │  128.47MiB  3435k dash  │ vp9            3435k video only          1080p60, webm_dash
399 mp4   1920x1080   60 10     │   80.90MiB  2163k dash  │ av01.0.09M.10  2163k video only          1080p60 HDR, mp4_dash
699 mp4   1920x1080   60 10     │  190.18MiB  5084k dash  │ av01.0.09M.10  5084k video only          1080p60 HDR, mp4_dash
335 webm  1920x1080   60 10     │  251.88MiB  6734k dash  │ vp9.2          6734k video only          1080p60 HDR, webm_dash
308 webm  2560x1440   60        │  383.24MiB 10245k dash  │ vp9           10245k video only          1440p60, webm_dash
400 mp4   2560x1440   60 10     │  207.25MiB  5541k dash  │ av01.0.12M.10  5541k video only          1440p60 HDR, mp4_dash
700 mp4   2560x1440   60 10     │  508.28MiB 13588k dash  │ av01.0.12M.10 13588k video only          1440p60 HDR, mp4_dash
336 webm  2560x1440   60 10     │  606.59MiB 16217k dash  │ vp9.2         16217k video only          1440p60 HDR, webm_dash
315 webm  3840x2160   60        │  952.43MiB 25462k dash  │ vp9           25462k video only          2160p60, webm_dash
401 mp4   3840x2160   60 10     │  435.51MiB 11643k dash  │ av01.0.13M.10 11643k video only          2160p60 HDR, mp4_dash
701 mp4   3840x2160   60 10     │  931.57MiB 24905k dash  │ av01.0.13M.10 24905k video only          2160p60 HDR, mp4_dash
337 webm  3840x2160   60 10     │    1.05GiB 28822k dash  │ vp9.2         28822k video only          2160p60 HDR, webm_dash
 
 
Da lì ad esempio se vuoi testare qualcosa in AV1:
 
yt-dpl -f 140+699 "
https://www.youtube.com/watch?v=LXb3EKWsInQ
"
 
Questo ti scarica un audiovideo con:
 
audio - mp4a.40.2  129k 44k medium, m4a_dash
video - av01.0.09M.10  5084k video only          1080p60 HDR, mp4_dash
 
Ne fa il merge di solito in mkv come contenitore e così hai il video
in locale pronto da testare con mpv.
 
Roba in VP8 sul tubo credo che non ne trovi più, ma posso sbagliarmi.

 Comunque direi che mi posso accontentare.
 
Sì è già un passo avanti rispetto alla situazione di partenza.
Ti chiederei se puoi riportare ancora il test con un video codificato
in H265/HECV.
 
Come sempre prima hwdec auto, poi hwdec forzato all'API che non aveva
scelto al primo giro... se con auto sceglie vaapi, al secondo giro
prova a forzare vdpau, tanto per vedere se non funziona neanche con
h265, non si sa mai. Ovviamente non serve che forzi vaapi se già con
auto te lo sceglie e riesce a sfruttarlo.

 VP9.
 
VP8 pare di no e neppure VP9, invece pare VC1, h264/5 funzionino. Vlc ha 
gli stessi risultati di mpv --auto.


 gli stessi risultati di mpv --auto.
 
Sì, non so se hai fatto caso anche al carico della GPU rispetto a quello
della CPU, come avevamo detto all'inizio della discussione... casomai
facci caso perché poi l'obiettivo pratico è proprio quello. Quindi vai
di htop radeontop o come si chiamava ecc... da controllare durante le
varie prove di riproduzione video.
 
L'unica cosa che mi insospettisce, probabilmente per mia ignoranza su
vdpau/vaapi e similari, è il diverso esito tra MPV e VLC.
Il primo riesce ad utilizzare esclusivamente VAAPI, mentre il secondo
usa VDPAU (G3DVL VDPAU).
 
- Quale è meglio? Boo... da me vaapi non funziona coi driver nvidia
  legacy, quindi non ti so dire... coi driver Nouveau funziona ma
  crasha tutto e devo togliere corrente al PC per riavviarlo, non è
  colpa del driver open ma del connubio GT210 + Nouveau che non si
  sposano bene per la video decodifica hardware. In sintesi io qui
  poso provare solo vdpau, quindi niente confronto con vaapi.
 
- Con quale dei due rilevi maggiore sgravio della CPU?
  O maggiore carico sulla scheda video "GPU"? (ovvimente facendo la prova
  sullo stesso video, altrimenti non ha senso... e senza fare nel
  frattempo altre attività che falsino l'impiego di questi componenti)
 
- Perché se VLC riesce ad utilizzare VDPAU, invece MPV pur forzandolo
  con hwdec=vdpau non conferma la decodifica hardware con quell'API?
 
 
Potresti fare un'ulteriore prova un po' a casaccio:
 
--vo=vdpau --hwdec=vdpau
 
Cioè forzare anche "vo" a vdpau... senza garanzia che salti fuori
qualcosa di buono.
 
 
 
Per quanto riguarda VP8 e VP9, al di là che per il secondo proprio
non dovresti avere supporto a livello hardware, in ogni caso, se
ricordi quando hai fatto il rebuild di mesa, nello spec hai attivato
solamente i codec VC, H264 e H265.
Per cui bisognerebbe forse informarsi meglio su come attivare VP8
a livello software... non so se si fa sempre da mesa o da ffmpeg o
da cos'altro.
 
Per farti un esempio, io ricordo di aver dovuto ricompilare FFMpeg
per poter visualizzare (anche solo con decodifica software) alcuni
formati video codificati con codec proprietari ecc...
Sempre perché ffmpeg di default distribuito da slack era compilato
senza quei codecs attivati.
 
Come vedi si sovrappongono due problemi:
 
- funzionalità hardware della GPU
 
- configurazione software del sistema con supporto a tutti i codec
  coinvolti nei test
 
Se manca il primo punto non c'è alcuna possiblità di ottenere nulla
neanche risolvendo il secondo aspetto... però se non si è sicuri,
occorre partire dal secondo e fare il test per confermare o smentire
il primo. C'è da sporcarsi le mani insomma.

 il primo. C'è da sporcarsi le mani insomma.
 
Potrei nella prossima compilazione di mesa src mettere a casaccio vp8 e 
sperare di non fare danni?


 sperare di non fare danni?
 
Direi proprio di no... prova anche ma ti darà qualche errore
sicuramente, comunque il PC non dovrebbe esplodere  :D

 sicuramente, comunque il PC non dovrebbe esplodere  :D
 
Però hai ragione VP8 non è sotto brevetto come h.264/5 e quindi è del 
tutto inutile metterlo li dentro, mi ero distratto.


 tutto inutile metterlo li dentro, mi ero distratto.
 
Già, si tratta di capire un po' meglio come funziona tutta la catena
per i codec VP8 / VP9.
Intendo a partire dal lato kernel quindi dal driver "amdgpu" che stai
usando, per arrivare al palyer MPV e lì in mezzo capire cosa viene
utilizzato per la decodifica (credo ffmpeg ma non ne sono sicuro) e quali
librerie e codec necessita il programma di decodifica, anche per
appoggiarsi poi a varie API come abbiamo già visto in modo da richiamare
le funzionalità della GPU attraverso il driver.
Ad esempio vaapi per la decodifica h264 passava da mesa.
Come ho già scritto, nel tuo caso VP8 e VP9 sono fruibili via decodifica
software, quindi vuol dire che non è un problema codec, altrimenti
proprio non li vedresti per niente. La questione è un po' più sottile
e occorre focalizzarla proprio sul discorso decodifica hardware.
 
C'è da cercare bene in rete...

 C'è da cercare bene in rete...
 
faccio qualche prova con le % di CPU per vlc e per mpv e poi direi che 
non è il caso di usare ulteriormente il tuo tempo, sei stato 
gentilissimo. Mi hai detto che interessava anche a te ma hai impiegato 
moltissimo tempo per darmi una mano :).
 
Poi mi metto a scrivere una miniguida da mettere sul forum di Mageia in 
modo che sia utile anche a me.
È che mi risulta più facile ricordare una cosa che ho scritto su 
Internet che mettere un file in una cartella sul mio HD.


 Internet che mettere un file in una cartella sul mio HD.
 
Bene, hai ragione, scrivere in rete torna utilissimo dopo tot tempo,
si ritrova un sacco di informazioni quando si deve nuovamente affrontare
lo stesso problema ma no si ricorda più come si aveva fatto a venirne
fuori in passato.
Riguardo VP8 e VP9, per avere la decodifica hardware, o da "vainfo" o
da "vpauinfo" devono risultare supportati. Altrimenti direi che i test
con le applicazioni (vlc, mpv, mplayer ecc...) non aggiungono alcun
esito positivo. Non credo sia possibile ad esempio che mpv ti riporti
"using vaapi for hardware decoding" e allo stesso tempo vainfo non abbia
la riga di supporto allo stesso codec del video in questione.
 
Qualche ricerca per capire se occorra configurare qualcosa di più per
coprendere quei codec l'ho fatta ma senza riscontri... come già scritto
si trova qualche riferimento secondo cui vp8 e vp9 dovrebbero funzionare
così senza far nulla. Io non ne sono convintissimo, almeno così a naso...
soprattutto perché immaginavo che il supporto al decoding hardware almeno
per vp8 la tua GPU avrebbe dovuto averlo.

 per vp8 la tua GPU avrebbe dovuto averlo.
 
Io ci capisco poco ma leggo qui:
https://wiki.archlinux.org/title/Hardware_video_acceleration#VDPAU_drivers
 
 
che per la decodifica con il codec VP8 che non è nemmeno nominato. Qui 
il VP8 è nominato ma:
https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers
 
 
c'è un NO per:
libva-mesa-driver  	libva-vdpau-driver
                         (VDPAU adapter)
 
Tu invece affermi che il VP8 è supportato per la mia scheda.


 Tu invece affermi che il VP8 è supportato per la mia scheda.
 
Più che affermare, immaginavo che fosse incluso tra le funzionalità
di decodifica, ma non ne sono assolutamente sicuro...
Se cerchi in giro le specifiche della tua scheda grafica trovi un po'
di tutto, da chi dice che sia basata su chip Lexa a chi dice Baffin,
da chi dice che il VP9 via hardware lo decodifica, a chi dice di no.
È un modello un po' ballerino come informazioni in circolazione,
comunque vedo... da lì VA-API via mesa sembra impossibilitato a
decodificare via GPU i VP8 e VP9.
In ogni caso non mi sembra un grosso problema, è vero che vp9 per
video in alta qualità sembra il predefinito ad esempio sul tubo,
ma in ogni caso dovresti riuscire a forzare la richiesta del formato
a h264, ad esempio con l'estensione:
 
https://github.com/alextrv/enhanced-h264ify
 
 
Questo fa sì che dal browser sia scelta la riproduzione via codec
h264, che la scheda video digerisce bene... bypassando quindi VP9.
 
Roba in VP8 non saprei dove potresti trovarla, può essere che non
ne avresti a che fare più o meno mai, quindi alla fine non è un problema
se l'hwdec non lo supporta.
 
Per quanto riguarda youtube io in realtà uso sempre mpv + yt-dlp,
quest'ultimo si integra nel player e provvede a scaricare il video
secondo le impostazioni scelte (nel mio caso h264 a 720p se ben
ricordo)...
In ogni caso non utilizzo il browser per riprodurre il video, mi è
molto più comodo avere una finestrella di MPV o anche due o tre accanto
al browser aperto sulla pagina del tubo in cui ho fatto una ricerca,
e da lì trascino i video nelle finestre mpv e li faccio partire
in sequenza in modo da visionare rapidamente i vari video.
A spiegarlo può sembrare arzigogolato, ma nella pratica è un'operazione
"al volo", c'è da dire che usando dwm e qualche scorciatoia da tatiera
il tutto è ancora più speditivo:
 
win+v mi apre mpv, se lo premo 2 o 3 volte arrivano tre finestre
di mpv messe già al loro posto una sotto l'altra sulla destra (tiling wm).
Mi resta il browser a sinistra, in cui pinzo i links dei video e li
tracino nelle finestre a destra.
 
In aggiunta ho nel browser anche l'estensione:
 
https://github.com/woodruffw/ff2mpv
 
 
che aggiunge un bottone in alto nella barra del browser accanto alle
altre estensioni tipo ublock ecc... premendolo si apre mpv che inizia
a riprodurre il video corrispondente alla pagina youtube corrente.
L'estensione aggiunge anche mpv al menu contestuale, quindi se clicco
tasto dx su un video del tubo e scelgo play with mpv ecco che si apre
mpv e riproduce il video in questione.
Comunque è più rapida la prima organizzazione con le finestre mpv già
aperte e trascinarci dentro i links.
 
Questo era solo un esempio di utilizzo, la cosa importante è che
automaticamente mi scelgie il codec con hwdec supportato. In
un'operazione del genere come descritta sopra, è un dettaglio che fa
la differenza su PC datati.

 la differenza su PC datati.
 
enormemente, fa molta differenza come scritto qui sopra, d'estate poi è 
un problema.
 
Grazie!


 nuovo.
 
Fai comunque anche una prova di trascinamento a tempo perso con una
finestra di mpv. Ovviamente devi settare mpv.conf con hwdec auto vo gpu
ecc... da me è in:
 
~/.config/mpv/mpv.conf
 
--------------------------------
player-operation-mode=pseudo-gui
vo=gpu
video-sync=display-resample
hwdec=auto
cache=yes
cache-dir=~/.cache/mpv
cache-on-disk=yes
ytdl-format=22/95/best[height <= 1080][vcodec ^= ?avc][fps <= 50]/best[height <= 1080][vcodec ^= ?avc]/best
idle=yes
volume=10
script-opts=ytdl_hook-ytdl_path=yt-dlp
--------------------------------------
 
È tutto un po' incasinato, ora su qualche riga non ricordo
benissimo neanch'io il meccanismo, specie quella di ytdl-format.
Però un po' dal man e un po' da ricerca in rete, ci si dovrebbe
uscire per adattare eventualmente ad altri settaggi.

 uscire per adattare eventualmente ad altri settaggi.
 
Mi ha aperto una finestra grande che suppongo sia 1080p e poi su un 
altro video una 720p. Forse è il caso di impostare 720 per risparmiare 
Giga: devo cambiare i 1080 in 720?
ytdl-format=22/95/best[height <= 720][vcodec ^= ?avc][fps <= 
50]/best[height <= 720][vcodec ^= ?avc]/best
 
darò una occhiata in rete o sul man.


 darò una occhiata in rete o sul man.
 
Vedi sopra.. lasciando il "22" ti prende preferibilmente il
formato h264 720 non dash. Per risparmiare Giga dici...
lì non ti posso aiutare, devi vedere tu quanto trffico hai,
quanto ti serve la qualità dei video ecc ecc.
 
Se metti "18" invece di 22 ti tira giù il 360p che è ancora
più economico in termini di banda. Poi dipende un po' da cosa
ti serve, se devi leggere dello scritto nei video, un minimo
di qualità fa molto comodo.
In ogni caso sì fai riferimento al manuale e affianca una bella
ricerca delle istruzioni per yt-dlp in modo da capire il meccanismo
di quella direttiva di scelta automatica...
Quando si apre un video, ripeto, se premi ctrl+I appaiono le
informazioni incluso il formato del video, la risoluzione il codec,
il driver/API che stai usando per la decodifica ecc ecc... per cui
da lì hai la certezza sia della risoluzione del video corrente, sia
la modalità che il player sta usando per riprodurlo (VDPAU nel mio
caso oppure no, da te vedrai scritto "(vaapi)" credo).
 
Ti lascio anche un video da cui si vede mpv in dwm più o meno
schermata simile a quella che mi ritrovo io, giusto per darti l'idea
delle finestre gestite automaticamente e delle informazioni su
cpu ram ecc che si vedono nella barra in cima, ne avavmo parlato
in precedenza...
 
https://www.youtube.com/watch?v=w-g04TLp0tg
 
 
Le finestre lì le gestisce il window manager, mentre su kde,
mpv si apre di default in modo proporzionale alla risoluzione
o qualcosa del genere.
Puoi impostarlo però come vuoi, si tratta di vedere come fare,
nel man c'è scritto, ma fai prima a cercare in rete mi sa. Io
al volo non lo ricordo.
 
Mi pare che di carne al fuoco ne ho messa, vedi un po' tu come
può servirti... ovvio che dovrai metterci un po' del tuo per
ottenere una configurazione soddisfacente, ma così parti già
abbastanza instradato.

 abbastanza instradato.
 
Ti ringrazio per tutte le info che mi hai dato, in particolare il file 
di configurazione che già così mi soddisfa parecchio. La compilazione 
del file mesa era la mia prima compilazione di un file rpm, Poi tutto il 
resto.
 
Questa estate mi sarà molto utile per tenera bassa la temperatura della 
CPU quando voglio vedere video.
 
Ciao e grazie di nuovo ^_^


 resto.
 
Ottimo!  ;)