Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Rx550 Sapphire
127 views
Skip to first unread message
Sandro kensan
May 7, 2023, 12:24:20 PM5/7/23
to
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
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
Piergiorgio Sartor
May 7, 2023, 12:39:18 PM5/7/23
to
On 07/05/2023 18.24, Sandro kensan wrote:
[...]
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
[...]
> 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?
A cosa ti serve questa scheda video?
> verificare che abbia acquistato qualche cosa che vale 80 euro o poco meno?
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
Giuseppe Della Bianca
May 7, 2023, 2:31:34 PM5/7/23
to
Il Sun, 7 May 2023 18:24:16 +0200, Sandro kensan ha scritto:
> 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.
]zac[
> 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.
> 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.
Per 80 euro le uniche verifiche che ha senso fare è se funziona, se è un
> e mi pare abbia ottenuto buone prestazioni migliori di altre rx550
> testate.
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
Sandro kensan
May 8, 2023, 10:21:45 AM5/8/23
to
On 07/05/23 20:31, Giuseppe Della Bianca wrote:
> Per 80 euro le uniche verifiche che ha senso fare è se funziona, se è un
> buono stato, se ha tutti gli accessori, ecc. .
Funziona bene, per quello che mi serve ovvero usare il browser e al
> Per 80 euro le uniche verifiche che ha senso fare è se funziona, se è un
> buono stato, se ha tutti gli accessori, ecc. .
massimo vedere video a 1200*1920, è da anni che non gioco e al massimo
uso tetris, qualche volta ho sperimentato go kart open source ma solo
per provare.
> 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
vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002]
bus info: pci@0000:01:00.0
version: ff
width: 64 bits
clock: 33MHz
> 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.
Sandro kensan
May 8, 2023, 10:23:49 AM5/8/23
to
On 07/05/23 18:37, Piergiorgio Sartor wrote:
> A cosa ti serve questa scheda video?
> Deve giocare? Fai rendering? E` solo
> per il desktop?
Solo per il desktop. al massimo video ad alta risoluzione (nel futuro
> A cosa ti serve questa scheda video?
> Deve giocare? Fai rendering? E` solo
> per il desktop?
quando cambierò monitor).
>
> 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,
Quindi mi potrei fermare qui.
> 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,
Joe
May 8, 2023, 3:00:55 PM5/8/23
to
Sandro kensan <ken...@kensan.it> wrote:
> 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.
Premettendo che ho avuto a che fare sempre più con nvidia negli ultimi
> 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.
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.
Sandro kensan
May 9, 2023, 12:05:35 PM5/9/23
to
On 08/05/23 21:00, Joe wrote:
> 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... :(
> 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... :(
Joe
May 9, 2023, 12:18:58 PM5/9/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 08/05/23 21:00, Joe wrote:
>
> Quindi si può dedurre qualche cosa, io ci capisco poco... :(
No, rileggi il mio post dove ho messo l'esempio con anche --hwdec,
> On 08/05/23 21:00, Joe wrote:
>
> Quindi si può dedurre qualche cosa, io ci capisco poco... :(
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.
Sandro kensan
May 9, 2023, 7:30:21 PM5/9/23
to
On 09/05/23 18:18, Joe wrote:
> No, rileggi il mio post dove ho messo l'esempio con anche --hwdec,
> avevo fatto proprio l'esempio senza e con...
Scusa, si vede che avevo poca voglia di leggere un testo lungo.
> No, rileggi il mio post dove ho messo l'esempio con anche --hwdec,
> avevo fatto proprio l'esempio senza e con...
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.
Joe
May 10, 2023, 6:32:01 AM5/10/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> Comunque mi dicevi di testare i due comandi mvp:
> mpv --vo=gpu
> mpv --vo=gpu --hwdec=auto
>
>
>
> Comunque mi dicevi di testare i due comandi mvp:
> mpv --vo=gpu
> mpv --vo=gpu --hwdec=auto
>
>
> [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
>
>
> 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
>
>
> 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.
Sì all'occupazione della CPU facci caso già da subito... che alla fine è
> questo viene dopo il fatto che si metta in funzione la decodifica hardware.
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.
Joe
May 10, 2023, 7:59:44 AM5/10/23
to
Joe <J...@e.invalid> wrote:
>
> 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
Errore mio, ho visto che avevi già messo le informazioni in un
>
> 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
messaggio precedente, riportando che il Chip sarebbe:
Baffin - Polaris 11 (o in alcune varianti Polaris 21)
> Che fa parte della microarchitettura:
>
> Graphic Core Next 4 (CGN 4)
quindi, ma va be', vedremo poi nel seguito delle verifiche...
Sandro kensan
May 10, 2023, 12:46:20 PM5/10/23
to
On 10/05/23 12:31, Joe wrote:
> 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.
Sto notando che sui video di YT (non so che codifica abbiano ma suppongo
> 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.
una normale h264 la CPU schizza al 30% in full screen.
> 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:
semplice senza trattino.
> 1.
> # lspci -nnk | egrep -i --color 'vga|3d|2d' -A3
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev ff)
Subsystem: Sapphire Technology Limited Radeon RX 550 640SP
[1da2:e367]
Kernel driver in use: amdgpu
Kernel modules: amdgpu
> 2.
> # lshw -c video
*-display
description: VGA compatible controller
product: Baffin [Radeon RX 550 640SP / RX 560/560X]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 0
bus info: pci@0000:01:00.0
version: ff
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi vga_controller bus_master
version: ff
width: 64 bits
clock: 33MHz
cap_list rom
configuration: driver=amdgpu latency=0
resources: irq:26 memory:d0000000-dfffffff
memory:cfe00000-cfffffff ioport:d000(size=256) memory:febc0000-febfffff
memory:c0000-dffff
>
> ---------------
>
> 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
Questo potrebbe essere una incongruenza.
su:
==========
VULKANINFO
==========
Vulkan Instance Version: 1.3.231
ho trovato:
Layers: count = 1
=================
VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
version 1.3.211, layer version 1:
Layer Extensions: count = 0
Devices: count = 2
GPU id = 0 (AMD Radeon RX 550 Series (RADV POLARIS11))
Layer-Device Extensions: count = 0
GPU id = 1 (llvmpipe (LLVM 15.0.6, 256 bits))
Layer-Device Extensions: count = 0
> 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.
Joe
May 10, 2023, 3:04:29 PM5/10/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 10/05/23 12:31, Joe wrote:
>
>> 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.
>
> Sto notando che sui video di YT (non so che codifica abbiano ma suppongo
> una normale h264 la CPU schizza al 30% in full screen.
Se parliamo di riproduzione dalla finestra del browser a me tende a
> On 10/05/23 12:31, Joe wrote:
>
>> 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.
>
> Sto notando che sui video di YT (non so che codifica abbiano ma suppongo
> una normale h264 la CPU schizza al 30% in full screen.
scegliere il formato VP9. Per vederli in h264 mi era servita un'estensione
del browser:
enhanced-h264ify
Con quella puoi bloccare i formati che la tua scheda non gestisce
via hardware. Io ad esempio ho lasciato solo h264, perché i VP8/9,
stressano molto di più la mia CPU.
In ogni caso per avere sicurezza del formato correntemente scelto,
click destro e fai "stats for nerds" saltano fuori tutte le info
del caso.
Detto questo io uso sempre MPV in combinata con yt-dlp: trascini il link
nella finestra di mpv e parte la riproduzione nel player, che per il mio
hardware è molto più efficiente che riprodurre da dentro il browser.
Per fare test però ti sconsiglio la riproduzione in streaming,
meglio scaricare il video interamente in locale e in seguito
riprodurlo col player.
Anche il browser in realtà potrebbe essere limitativo, per testare
meglio mpv da riga di comando. È la cosa più semplice.
Poi dipende anche cosa devi testare... ma almeno per la decodifica
hardware dei video è la cosa migliore.
> Ho una distro vecchio stampo e quindi ha su, io di solito uso $su
> semplice senza trattino.
> # lspci -nnk | grep -Ei --color 'vga|3d|2d' -A3
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev ff)
> Subsystem: Sapphire Technology Limited Radeon RX 550 640SP
> [1da2:e367]
> Kernel driver in use: amdgpu
> Kernel modules: amdgpu
> # lshw -c video
> *-display
> description: VGA compatible controller
> product: Baffin [Radeon RX 550 640SP / RX 560/560X]
> vendor: Advanced Micro Devices, Inc. [AMD/ATI]
> physical id: 0
> bus info: pci@0000:01:00.0
> version: ff
> width: 64 bits
> clock: 33MHz
> capabilities: pm pciexpress msi vga_controller bus_master
> cap_list rom
> configuration: driver=amdgpu latency=0
> resources: irq:26 memory:d0000000-dfffffff
> memory:cfe00000-cfffffff ioport:d000(size=256) memory:febc0000-febfffff
> memory:c0000-dffff
OK, niente, hai in uso il driver open "amdgpu". Che in realtà dovrebbe
> *-display
> description: VGA compatible controller
> product: Baffin [Radeon RX 550 640SP / RX 560/560X]
> vendor: Advanced Micro Devices, Inc. [AMD/ATI]
> physical id: 0
> bus info: pci@0000:01:00.0
> version: ff
> width: 64 bits
> clock: 33MHz
> capabilities: pm pciexpress msi vga_controller bus_master
> cap_list rom
> configuration: driver=amdgpu latency=0
> resources: irq:26 memory:d0000000-dfffffff
> memory:cfe00000-cfffffff ioport:d000(size=256) memory:febc0000-febfffff
> memory:c0000-dffff
andare più che bene, dicono molto meglio del nouveau open per le nvidia,
con cui ad esempio per la mia scheda l'accelerazione hardware in decodifica
porta ad un crash del sistema risolvibile solo staccando la spina della
corrente.
>> 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
>
> Esatto è quello, inoltre dovrei avere Polaris 11 e non polaris 12.
> Questo potrebbe essere una incongruenza.
Alcune RX550 avevano polaris 12 (lexa), poi in seguito ne hanno
prodotte altre serie sempre RX550 ma con chip "baffin", che in
teoria dovrebbe essere polaris 11.
Comunque sono tutti di architettura GCN 4, per cui a livello di
configurazione e gestione non dovrebbe cambiar nulla. Come prestanzioni
invece non lo so, ma saranno lì imamgino...
> ==========
> VULKANINFO
> ==========
>
> Vulkan Instance Version: 1.3.231
>
> ho trovato:
>
> Layers: count = 1
> =================
> VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
> version 1.3.211, layer version 1:
> Layer Extensions: count = 0
> Devices: count = 2
> GPU id = 0 (AMD Radeon RX 550 Series (RADV POLARIS11))
> Layer-Device Extensions: count = 0
>
> GPU id = 1 (llvmpipe (LLVM 15.0.6, 256 bits))
> Layer-Device Extensions: count = 0
Per il resto non so come si possa sfruttare e quindi testare
quell'API. Anche in questo caso ti rimando al wiki di Arch:
https://wiki.archlinux.org/title/Vulkan
OK ora ch sappiamo che è in uso il driver open amdgpu, bisogna
capire se sono presenti e configurate le librerie/API necesarie
all'aceclerazione hardware.
Partimo da qui, paragrafo 1.3
>> 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
Sandro kensan
May 10, 2023, 4:54:52 PM5/10/23
to
On 10/05/23 21:04, Joe wrote:
> Per prima cosa suggerirrei quindi di verificare con
>
> vainfo
>
> se è presente va-api.
>
> Se il comando non c'è installa
>
> libva-utils
$ vainfo
> Per prima cosa suggerirrei quindi di verificare con
>
> vainfo
>
> se è presente va-api.
>
> Se il comando non c'è installa
>
> libva-utils
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" ... :)
Joe
May 10, 2023, 6:31:28 PM5/10/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 10/05/23 21:04, Joe wrote:
>
>> Per prima cosa suggerirrei quindi di verificare con
>>
>> vainfo
>>
>> se è presente va-api.
>>
>> Se il comando non c'è installa
>>
>> 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
Guarda, così su due piedi ti direi di fare una prova per vedere se
> On 10/05/23 21:04, Joe wrote:
>
>> Per prima cosa suggerirrei quindi di verificare con
>>
>> vainfo
>>
>> se è presente va-api.
>>
>> Se il comando non c'è installa
>>
>> 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
suggerendo "vaapi" come driver per la decodifica hardware si riesca
ad ottenere un coinvolgimento effettivo della GPU:
mpv --no-config --vo=gpu --hwdec=vaapi
Se ricordi prima avevi provato con "auto" perché ha un senso e in
teoria è la gpu e il suo driver insieme a mpv a dover scegliere con
cosa gestire la decodifica.
Appurato che il supporto a vaapi c'è, ora si prova a "forzare" mpv
ad utillizzarlo.
Per quanto riguarda il formato dei file da provare parti dal facile
fino al più "esotico": tipo parti da qualcosa di h264, di cui sei sicuro
di avere il supporto senza problemi.
Poi puoi provare con altra roba tipo VP8, VP9 o anche h265 - hevc.
> $ 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
libvdpau o giù di lì. Questo punto cercando si dovrebbe trovare,
arch è diffusissima ormai e ultra documentata.
Se cerchi cosa serve per avere attivo e funzionante vdpau sicuramente
trovi qualcosa. Io ho trovato una discussione in cui però consigliano
più vaapi. Ma lì secondo me è sempre meglio provare direttamente sul
campo, il sentito dire non mi convince mai del tutto.
pacman -Qi libvdpau
cosa dice?
Se dice che non è installato provvedi e riprova vdpauinfo.
> Interessante che il costruttore possa avere fatto "pasticci" ... :)
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.
Sandro kensan
May 11, 2023, 7:14:03 AM5/11/23
to
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
$ 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...
# 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
file or directory
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
file or directory
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
file or directory
backend libvdpau_radeonsi.so: cannot open shared object file: No such
file or directory
con:
file or directory
$ 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...
Joe
May 11, 2023, 8:12:21 AM5/11/23
to
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!
Sandro kensan
May 11, 2023, 8:20:37 AM5/11/23
to
On 11/05/23 00:31, Joe wrote:
> Guarda, così su due piedi ti direi di fare una prova per vedere se
> suggerendo "vaapi" come driver per la decodifica hardware si riesca
> ad ottenere un coinvolgimento effettivo della GPU:
>
> mpv --no-config --vo=gpu --hwdec=vaapi
Mi sa che non cambia nulla:
> Guarda, così su due piedi ti direi di fare una prova per vedere se
> suggerendo "vaapi" come driver per la decodifica hardware si riesca
> ad ottenere un coinvolgimento effettivo della GPU:
>
> mpv --no-config --vo=gpu --hwdec=vaapi
$ 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)
[ffmpeg/video] h264: No support for codec h264 profile 100.
(+) 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)
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V201 MP4 - AVC 1080p 24fps
8bit - AAC2.0.mp4'
(+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ffmpeg/video] h264: No support for codec h264 profile 100.
(+) 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:30 / 00:00:30 (100%) A-V: 0.000
VO: [gpu] 1920x1080 yuv420p
Exiting... (End of file)
i file di tipo mpeg non danno l'errore"[ffmpeg/video] xxx: No support
for codec "
Comunque in nessun caso c'è la scrittina:
**Using hardware decoding **
Tra l'altro l'errore di ffmpeg/video non mi compariva ieri quando ho
fatto le precedenti prove con "auto". Adesso mi compare con "auto".
> Se ricordi prima avevi provato con "auto" perché ha un senso e in
> teoria è la gpu e il suo driver insieme a mpv a dover scegliere con
> cosa gestire la decodifica.
> Appurato che il supporto a vaapi c'è, ora si prova a "forzare" mpv
> ad utillizzarlo.
> Per quanto riguarda il formato dei file da provare parti dal facile
> fino al più "esotico": tipo parti da qualcosa di h264, di cui sei sicuro
> di avere il supporto senza problemi.
> Poi puoi provare con altra roba tipo VP8, VP9 o anche h265 - hevc.
>> $ 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
>
> Qua manca qualcosa secondo me... tipo qualche libreria coinvolta con
> libvdpau o giù di lì. Questo punto cercando si dovrebbe trovare,
> arch è diffusissima ormai e ultra documentata.
> Se cerchi cosa serve per avere attivo e funzionante vdpau sicuramente
> trovi qualcosa. Io ho trovato una discussione in cui però consigliano
> più vaapi. Ma lì secondo me è sempre meglio provare direttamente sul
> campo, il sentito dire non mi convince mai del tutto.
>
> pacman -Qi libvdpau
>
> cosa dice?
lib64vdpau-devel
lib64vdpau-driver-nouveau
lib64vdpau-driver-r300
lib64vdpau-driver-r600
lib64vdpau-driver-radeonsi
lib64vdpau-driver-virtio_gpu
lib64vdpau-trace
lib64vdpau-va-gl1
lib64vdpau1
vaapi-driver-vdpau
vdpauinfo
vlc-plugin-vdpau
L'unico pacchetto ad essere installato è:
lib64vdpau1 - VDPAU shared library
The Video Decode and Presentation API for Unix (VDPAU) wrapper shared
library. This library is responsible for loading the hardware-specific
VDPAU driver.
Io installerei "radeonsi" come driver ma solo perché nelle prove che mi
hai fatto fare l'ho visto nominare. Il nouveau è il driver open source
di nvidia, le r300 e 600 dovrebbero essere le vecchie schede amd. Poi io
so molto poco sulle schede video.
Posso sempre dissinstallarlo in quanto non ha dipendenze, ho installato
"radeonsi" e poi provato vdpau info:
Decoder capabilities:
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
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 --- not supported ---
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 --- not supported ---
HEVC_MAIN_10 --- not supported ---
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 ---
Se quelle elencate fossero le capacità della mia scheda grafica in
decodifica allora è una schifo! A parte gli Mpeg non mi serve a nulla,
h264 non pervenuto, vp9 nisba e HVEC (265) zero. Uno schifo, confermi?
>> 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.
quindi mi hanno venduto una scheda che è solo nominalmente una 550 :( Ho
scelto Shappire proprio perché l'ho sentita nominare molte volte ...
Sandro kensan
May 11, 2023, 8:33:58 AM5/11/23
to
On 11/05/23 14:20, Sandro kensan wrote:
> Posso sempre dissinstallarlo in quanto non ha dipendenze, ho installato
> "radeonsi" e poi provato vdpau info:
>
> Decoder capabilities:
>
> name level macbs width height
> ----------------------------------------------------
> MPEG1 --- not supported ---
> MPEG2_SIMPLE 3 65536 4096 4096
> MPEG2_MAIN 3 65536 4096 4096
ho provato a fare dei test ma la decodifica hw pare non sia fatta:
> Posso sempre dissinstallarlo in quanto non ha dipendenze, ho installato
> "radeonsi" e poi provato vdpau info:
>
> Decoder capabilities:
>
> name level macbs width height
> ----------------------------------------------------
> MPEG1 --- not supported ---
> MPEG2_SIMPLE 3 65536 4096 4096
> MPEG2_MAIN 3 65536 4096 4096
$ 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
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
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?
Joe
May 11, 2023, 11:52:25 AM5/11/23
to
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.
Joe
May 11, 2023, 12:15:42 PM5/11/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> Se quelle elencate fossero le capacità della mia scheda grafica in
> decodifica allora è una schifo! A parte gli Mpeg non mi serve a nulla,
> h264 non pervenuto, vp9 nisba e HVEC (265) zero. Uno schifo, confermi?
>
>
>>> 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.
>
> 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 ...
Mah, secondo me quello è l'ultimo dei problemi, cioè se c'era il chip
>
> Se quelle elencate fossero le capacità della mia scheda grafica in
> decodifica allora è una schifo! A parte gli Mpeg non mi serve a nulla,
> h264 non pervenuto, vp9 nisba e HVEC (265) zero. Uno schifo, confermi?
>
>
>>> 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.
>
> 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 ...
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?
Sandro kensan
May 11, 2023, 2:20:22 PM5/11/23
to
On 11/05/23 18:15, Joe wrote:
> 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
$ mpv --hwdec=help|cut -f 3 -d " "|uniq|grep -v copy|tail -n +2
> 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
vaapi
vdpau
qsv
auto
no
auto-safe
> Oltre a quanto suggerito sull'aggiornamento del sistema
> nell'altro mio messaggio... MPV come lo hai installato?
> da pacchetto ufficiale?
Sandro kensan
May 11, 2023, 2:22:50 PM5/11/23
to
On 11/05/23 17:52, Joe wrote:
> 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.
ok, buona a sapersi.
> 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:
tutto il resto penso l'abbiano aggiornato di conseguenza, ricevo un
aggiornamento ogni 2 giorni a volte ogni giorno. Dovrebbe essere una
beta ma io la sto usando come una stable. Non mi fido ancora per l'alpha
ma dalla beta 2 penso sia abbastanza stabile da essere usata come
postazione principale.
Più o meno quella o meglio era quella uno o due mesi fa.
> Sei sicuro di aver impostato correttamente i repository in modo che
> urpm punti a quelli della 9 beta 1?
Mageia-Cauldron-netinstall-nonfree-x86_64.iso
dove la Cauldron è la versione in lavorazione per la prossima versione.
Visto che la stable è la 8 la Couldron è la 9. Il link è presente nel
blog che hai anche tu linkato:
https://blog.mageia.org/en/2023/02/28/mageia-9-beta1-is-already-here/
> 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
che ce l'ho e ho aggiunto pochissimi paccetti extra che poi sono alcuni
bin e tutto dai repository ufficiali mageia. Se non hanno fatto "casino"
quelli di Mageia io ho tutti i pacchetti corretti.
>
> 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.
L'unico pacchetto che ho installato esterno è l'applicazione blue
> 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.
griffon che è fuori repository.
Comunque non saprei come fare per seguire le tue indicazioni, dovrei
reistallare tutto da zero e questo mi sarebbe di peso.
> Se fosse qualche codec mancante in ffmpeg non dovresti proprio
> riuscire a riprodurre i video, quindi escluderei quell'inghippo.
free ma questo lo fa il tipo di Mageia che ho installato la quale
abilita i repository tainted:
«tainted repositories: The Tainted repository includes packages under
various licenses, free and nonfree ones, but the main criteria for
packages in this repository is that they may infringe patents and
copyright laws in some countries in the world (e.g. multimedia codecs
needed to play various audio/video files, packages needed to play
commercial video DVD... etc); as such the set of the Tainted media is
added by default but not enabled by default, i.e. it's completely
opt-in; so check your local laws before using packages from this
repository. This repository is only added for the convenience of the
users. This repository is to Mageia what PLF was to Mandriva users or
RPM Fusion is to Fedora users.»
> 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.
una app ma non ci sono riuscito, l'unica cosa che ho fatto. Per fare
questo ho installato nel sistema uno o dei file penso siano state delle
librerie e ovviamente dai repository. Quindi ci sono un paio di file in
più ma nessun file, libreria, driver che ho modificato.
> 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.
"meno incasinata" della versione beta.
Joe
May 11, 2023, 5:05:33 PM5/11/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 11/05/23 18:15, Joe wrote:
>
>> 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
>
> $ mpv --hwdec=help|cut -f 3 -d " "|uniq|grep -v copy|tail -n +2
> vaapi
> vdpau
> qsv
> auto
> no
> auto-safe
>
>> Oltre a quanto suggerito sull'aggiornamento del sistema
>> nell'altro mio messaggio... MPV come lo hai installato?
>> da pacchetto ufficiale?
>
> Tutti i miei pacchetti sono stati installati dai repository ufficiali.
OK. Niente bisogna cercare un po' di più in rete mi sa...
> On 11/05/23 18:15, Joe wrote:
>
>> 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
>
> $ mpv --hwdec=help|cut -f 3 -d " "|uniq|grep -v copy|tail -n +2
> vaapi
> vdpau
> qsv
> auto
> no
> auto-safe
>
>> Oltre a quanto suggerito sull'aggiornamento del sistema
>> nell'altro mio messaggio... MPV come lo hai installato?
>> da pacchetto ufficiale?
>
> Tutti i miei pacchetti sono stati installati dai repository ufficiali.
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 :)
Sandro kensan
May 12, 2023, 11:57:35 AM5/12/23
to
On 11/05/23 23:05, Joe wrote:
Riassumendo mi pare che l'unico punto fisso e sicuro è che la mia scheda
video monta il Chip Baffin. Conseguentemente il mio sistema ha
considerato che è un Polaris 11 (21?):
https://www.techpowerup.com/gpu-specs/amd-baffin.g796
Released
Aug 8th, 2016
GPU Name
Baffin
Codename
Polaris 11/21/31
Generation
Arctic Islands
Architecture
GCN 4.0
Per quanto riguarda i driver installati posso solo dire che il centro di
controllo di Mageia (gui) mi dice solo che
"Setup the graphical server" > "Choose an X Server" > "Volcanic Island
and later (amdgpu)" è settato.
Mi pare di intuire (ho fatto qualche ricerca ma non ci ho capito molto)
che i driver per la mia scheda potrebbero essere i radeonsi o comunque
si provano quelli e si vede come va.
Mi pare di capire che il driver non è settato propriamente e quindi non
è utilizzato.
Io in /usr/lib64/vdpau ho solo:
root root 12707544 apr 27 20:09 libvdpau_radeonsi.so.1.0.0*
penso che ci sia finito per la mia installazione che ho fatto ieri dai
repository, in vdpau non c'è altro (oltre che a dei link)
> Dacci un'occhiata:
> -----------------------------
> # cat /etc/profile.d/vdpau.sh
> -----------------------------
io in profile.d non ho alcun file vdpau eseguibile (shell), ho fatto
anche un grep ma non c'è nulla che abbia a che fare. In profile ci sono
cosa varie tra cui l'esecuzione di tutti i file sh che sono in profile.d
tramite un for.
> Questo file non fa altro che settare la variabile
>
> VDPAU_DRIVER
se avessi trovato il file con le variabili di Shell le avrei settate e
provate.
> Anzi, da quanto ho visto potrebbe essere "radeonsi" nel tuo
> caso.
>
> https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuration
Tieni conto che ho una derivata di Fedora (rpm) e che la
journalizzazione mi dice:
$ journalctl -b --grep='vdpau | dri driver'
-- No entries --
Inoltre ho visto che per una RX480 (la mia dovrebbe essere un po'
migliore perché più recente):
https://bbs.archlinux.org/viewtopic.php?id=226932
Decoder capabilities:
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
HEVC_MAIN_10 186 65536 4096 4096
$ journalctl -b --grep='vdpau | dri driver'
-- No entries --
ma anche:
$ journalctl -b --grep='vdpau | dri '
-- No entries --
> 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,
mi da un "no entries".
Mi pare che tu mi abbia detto che se nei log di Xorg non c'è nulla di
non andare avanti. Comunque settare una variabile d'ambiente non lascia
alcuna traccia nel sistema e quindi ti mostro i risultati:
$ export VDPAU_DRIVER="radeonsi"
$ export LIBVA_DRIVER_NAME="radeonsi"
ritorna zero (no err) la funzione va_openDriver() che dovrebbe aprire il
driver. La lista di decodifiche possibili (se significano quello) è
molto scarna, in pratica solo il MPEG2.
$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
Output surface:
name width height nat types
----------------------------------------------------
B8G8R8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
R8G8B8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
R10G10B10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
B10G10R10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
Bitmap surface:
name width height
------------------------------
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2 16384 16384
B10G10R10A2 16384 16384
A8 16384 16384
Video mixer:
feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY y
HIGH QUALITY SCALING - L1 y
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -
parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 48 4096
VIDEO_SURFACE_HEIGHT y 48 4096
CHROMA_TYPE y
LAYERS y 0 4
attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y
> 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...
$ mpv --no-config --vo=gpu --hwdec=auto 'V001 AVI - MPEG-4 XVID NTSC
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=auto 'V205 MOV - AVC 1080p 24fps 8bit
- AAC2.0.mov'
Exiting... (Quit)
> 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
$ mpv --no-config --vo=gpu --hwdec=vaapi '/home/sandro/Desktop/V001 AVI
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V001 AVI - MPEG-4 XVID NTSC
Exiting... (Quit)
> Posta l'output di tutto quanto, non solo degli ultimi test,
> altrimenti non ci posso capire nulla di più.
Ho messo tutto.
> 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.
https://wiki.mageia.org/en/Mageia_9_Release_Notes
* Graphic drivers
Mesa 3D has been updated to Mesa 3D 23.0.
* X Window System (X11)
Mageia 9 ships with X.Org 21.1.7. XWayland 22.1.8 has been split from
the Xserver and is packaged as standalone tool for easier maintenance.
* AMD video drivers
Mageia 9 uses the free video drivers for AMD/ATI graphics cards,
AMDGPU for newer cards and Radeon for older graphics cards. Compared
with Mageia 8, hardware support has been increased and performance has
been improved.
The proprietary AMDGPU-PRO driver currently only works with X.org
1.1xx, so it cannot be used in Mageia 9.
In case of a hybrid card, the solution exposed with the nouveau
driver and the precommand DRI_PRIME=n is also working, at least with the
radeon driver.
Ho visto che il pacchetto:
plasma-workspace-wayland - Wayland support for Plasma
non è installato. Io ho Plasma.
Però è installato e bloccato (ha un lucchetto):
lib64wayland-server0 - Libraries for wayland-server
>
> Happy tuning :)
Grazie :)
Riassumendo mi pare che l'unico punto fisso e sicuro è che la mia scheda
video monta il Chip Baffin. Conseguentemente il mio sistema ha
considerato che è un Polaris 11 (21?):
https://www.techpowerup.com/gpu-specs/amd-baffin.g796
Released
Aug 8th, 2016
GPU Name
Baffin
Codename
Polaris 11/21/31
Generation
Arctic Islands
Architecture
GCN 4.0
Per quanto riguarda i driver installati posso solo dire che il centro di
controllo di Mageia (gui) mi dice solo che
"Setup the graphical server" > "Choose an X Server" > "Volcanic Island
and later (amdgpu)" è settato.
Mi pare di intuire (ho fatto qualche ricerca ma non ci ho capito molto)
che i driver per la mia scheda potrebbero essere i radeonsi o comunque
si provano quelli e si vede come va.
Mi pare di capire che il driver non è settato propriamente e quindi non
è utilizzato.
Io in /usr/lib64/vdpau ho solo:
root root 12707544 apr 27 20:09 libvdpau_radeonsi.so.1.0.0*
penso che ci sia finito per la mia installazione che ho fatto ieri dai
repository, in vdpau non c'è altro (oltre che a dei link)
> Dacci un'occhiata:
> -----------------------------
> # cat /etc/profile.d/vdpau.sh
> -----------------------------
anche un grep ma non c'è nulla che abbia a che fare. In profile ci sono
cosa varie tra cui l'esecuzione di tutti i file sh che sono in profile.d
tramite un for.
> Questo file non fa altro che settare la variabile
>
> VDPAU_DRIVER
provate.
> Anzi, da quanto ho visto potrebbe essere "radeonsi" nel tuo
> caso.
>
> https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuration
journalizzazione mi dice:
$ journalctl -b --grep='vdpau | dri driver'
-- No entries --
Inoltre ho visto che per una RX480 (la mia dovrebbe essere un po'
migliore perché più recente):
https://bbs.archlinux.org/viewtopic.php?id=226932
Decoder capabilities:
name level macbs width height
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE 3 65536 4096 4096
MPEG2_MAIN 3 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
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_EXTENDED --- not supported ---
H264_PROGRESSIVE_HIGH --- not supported ---
H264_CONSTRAINED_HIGH --- not supported ---
H264_HIGH_444_PREDICTIVE --- not supported ---
HEVC_MAIN 186 65536 4096 4096
H264_PROGRESSIVE_HIGH --- not supported ---
H264_CONSTRAINED_HIGH --- not supported ---
H264_HIGH_444_PREDICTIVE --- not supported ---
HEVC_MAIN_10 186 65536 4096 4096
HEVC_MAIN_STILL --- not supported ---
HEVC_MAIN_12 --- not supported ---
HEVC_MAIN_444 --- not supported ---
HEVC_MAIN_12 --- not supported ---
HEVC_MAIN_444 --- not supported ---
> 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é.
che corrisponde a:
> 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é.
$ journalctl -b --grep='vdpau | dri driver'
-- No entries --
ma anche:
$ journalctl -b --grep='vdpau | dri '
-- No entries --
> 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,
non andare avanti. Comunque settare una variabile d'ambiente non lascia
alcuna traccia nel sistema e quindi ti mostro i risultati:
$ export VDPAU_DRIVER="radeonsi"
$ export LIBVA_DRIVER_NAME="radeonsi"
$ vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.16.0
libva info: User environment variable requested driver 'radeonsi'
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
Quindi riconosce la variabile impostata, riesce ad aprire il driver,
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
ritorna zero (no err) la funzione va_openDriver() che dovrebbe aprire il
driver. La lista di decodifiche possibili (se significano quello) è
molto scarna, in pratica solo il MPEG2.
$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
name width height nat types
----------------------------------------------------
B8G8R8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
R8G8B8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
R10G10B10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
B10G10R10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
P010 P016 I8A8
Bitmap surface:
name width height
------------------------------
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2 16384 16384
B10G10R10A2 16384 16384
A8 16384 16384
Video mixer:
feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY y
HIGH QUALITY SCALING - L1 y
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -
parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 48 4096
VIDEO_SURFACE_HEIGHT y 48 4096
CHROMA_TYPE y
LAYERS y 0 4
attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y
> 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...
480p - MP32.0.avi'
(+) Video --vid=1 (mpeg4 720x480 29.970fps)
(+) Audio --aid=1 (mp3 2ch 44100Hz)
(+) 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:15 / 00:00:31 (50%) A-V: 0.000
VO: [gpu] 720x480 => 853x480 yuv420p
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=auto 'V205 MOV - AVC 1080p 24fps 8bit
- AAC2.0.mov'
(+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ffmpeg/video] h264: No support for codec h264 profile 100.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:09 / 00:00:31 (31%) A-V: 0.000
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[ffmpeg/video] h264: No support for codec h264 profile 100.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
Exiting... (Quit)
> 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
- MPEG-4 XVID NTSC 480p - MP32.0.avi'
(+) Video --vid=1 (mpeg4 720x480 29.970fps)
(+) Audio --aid=1 (mp3 2ch 44100Hz)
(+) 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 (17%) A-V: 0.000
VO: [gpu] 720x480 => 853x480 yuv420p
Exiting... (Quit)
$ 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)
(+) 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:10 / 00:00:31 (35%) A-V: 0.000
VO: [gpu] 720x480 => 853x480 yuv420p
Exiting... (Quit)
> 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.
* Graphic drivers
Mesa 3D has been updated to Mesa 3D 23.0.
* X Window System (X11)
Mageia 9 ships with X.Org 21.1.7. XWayland 22.1.8 has been split from
the Xserver and is packaged as standalone tool for easier maintenance.
* AMD video drivers
Mageia 9 uses the free video drivers for AMD/ATI graphics cards,
AMDGPU for newer cards and Radeon for older graphics cards. Compared
with Mageia 8, hardware support has been increased and performance has
been improved.
The proprietary AMDGPU-PRO driver currently only works with X.org
1.1xx, so it cannot be used in Mageia 9.
In case of a hybrid card, the solution exposed with the nouveau
driver and the precommand DRI_PRIME=n is also working, at least with the
radeon driver.
Ho visto che il pacchetto:
plasma-workspace-wayland - Wayland support for Plasma
non è installato. Io ho Plasma.
Però è installato e bloccato (ha un lucchetto):
lib64wayland-server0 - Libraries for wayland-server
>
> Happy tuning :)
Grazie :)
Joe
May 12, 2023, 4:16:36 PM5/12/23
to
Sandro kensan <ken...@kensan.it> wrote:
>>
>> 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é.
>
> che corrisponde a:
> $ journalctl -b --grep='vdpau | dri driver'
> -- No entries --
> ma anche:
> $ journalctl -b --grep='vdpau | dri '
> -- No entries --
Ma sei sicuro di questa corrispondenza? Io no.
>>
>> 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é.
>
> che corrisponde a:
> $ journalctl -b --grep='vdpau | dri driver'
> -- No entries --
> ma anche:
> $ journalctl -b --grep='vdpau | dri '
> -- No entries --
Stai usando Xorg come server grafico?
pgrep -a X
Quando si avvia, non scrive un file di log da qualche parte?
Storicamente è:
/var/log/Xorg.0.log
per capire il nome che cerchiamo inerente a vdpau e dri, devi
ravanare lì dentro.
journalctl non so cosa sia, immagino sia un pezzo di systemd, ma
avendo slackware che per ora l'ha scansato, non ti so dire di più...
Per la cronaca anche arch usa systemd, ma nel wiki come vedi è
suggerito di controllare il log di X.
In var log non hai nulla di recente?
ls -lt /var/log
???
> The proprietary AMDGPU-PRO driver currently only works with X.org
> 1.1xx, so it cannot be used in Mageia 9.
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.
Sandro kensan
May 13, 2023, 11:30:13 AM5/13/23
to
On 12/05/23 22:14, Joe wrote:
> Ma sei sicuro di questa corrispondenza? Io no.
>
> Stai usando Xorg come server grafico?
>
> pgrep -a X
$ pgrep -a X
> Ma sei sicuro di questa corrispondenza? Io no.
>
> Stai usando Xorg come server grafico?
>
> pgrep -a X
3314 /usr/libexec/Xorg -nolisten tcp -background none -seat seat0 vt1
-auth /var/run/sddm/{e28a56c7-07a4-4ec4-9e7d-b69576c03861} -noreset
-displayfd 16
> Quando si avvia, non scrive un file di log da qualche parte?
>
> Storicamente è:
>
> /var/log/Xorg.0.log
>
> per capire il nome che cerchiamo inerente a vdpau e dri, devi
> ravanare lì dentro.
Allora ho Xorg, il file esiste ed è popolato. Guardando dentro al file
mi accorgo che è lungo (lo posso postare in Rete), la parte importante
mi pare che non c'è DRI ma c'è DRI2:
$ cat Xorg.0.log|grep "DRI2"
[ 19.129] (II) AMDGPU(0): [DRI2] Setup complete
[ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
[ 19.185] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 19.185] (II) Initializing extension DRI2
Altra riga che mi pareva interessante:
[ 18.713] (--) AMDGPU(0): Chipset: "AMD Radeon RX 550 Series" (ChipID
= 0x67ff)
Il blocco completo:
[ 19.129] (II) AMDGPU(0): [DRI2] Setup complete
[ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
[ 19.130] (II) AMDGPU(0): Front buffer pitch: 7680 bytes
[ 19.130] (II) AMDGPU(0): SYNC extension fences enabled
[ 19.130] (II) AMDGPU(0): Present extension enabled
[ 19.130] (==) AMDGPU(0): DRI3 enabled
[ 19.130] (==) AMDGPU(0): Backing store enabled
[ 19.130] (II) AMDGPU(0): Direct rendering enabled
[ 19.154] (II) AMDGPU(0): Use GLAMOR acceleration.
[ 19.154] (II) AMDGPU(0): Acceleration enabled
[ 19.154] (**) AMDGPU(0): DPMS enabled
[ 19.154] (==) AMDGPU(0): Silken mouse enabled
[ 19.155] (II) AMDGPU(0): Set up textured video (glamor)
[ 19.172] (WW) AMDGPU(0): Option "HotplugDriver" is not used
[ 19.172] (II) Initializing extension Generic Event Extension
[ 19.172] (II) Initializing extension SHAPE
[ 19.172] (II) Initializing extension MIT-SHM
[ 19.172] (II) Initializing extension XInputExtension
[ 19.172] (II) Initializing extension XTEST
[ 19.173] (II) Initializing extension BIG-REQUESTS
[ 19.173] (II) Initializing extension SYNC
[ 19.173] (II) Initializing extension XKEYBOARD
[ 19.173] (II) Initializing extension XC-MISC
[ 19.173] (II) Initializing extension SECURITY
[ 19.173] (II) Initializing extension XFIXES
[ 19.173] (II) Initializing extension RENDER
[ 19.173] (II) Initializing extension RANDR
[ 19.174] (II) Initializing extension COMPOSITE
[ 19.174] (II) Initializing extension DAMAGE
[ 19.174] (II) Initializing extension MIT-SCREEN-SAVER
[ 19.174] (II) Initializing extension DOUBLE-BUFFER
[ 19.174] (II) Initializing extension RECORD
[ 19.174] (II) Initializing extension DPMS
[ 19.175] (II) Initializing extension Present
[ 19.175] (II) Initializing extension DRI3
[ 19.175] (II) Initializing extension X-Resource
[ 19.175] (II) Initializing extension XVideo
[ 19.175] (II) Initializing extension XVideo-MotionCompensation
[ 19.175] (II) Initializing extension GLX
[ 19.185] (II) AIGLX: Loaded and initialized radeonsi
[ 19.185] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 19.185] (II) Initializing extension XFree86-VidModeExtension
[ 19.185] (II) Initializing extension XFree86-DGA
[ 19.185] (II) Initializing extension XFree86-DRI
[ 19.185] (II) Initializing extension DRI2
[ 19.187] (II) AMDGPU(0): Setting screen physical size to 508 x 317
Aggiungo che i driver possibili dai repository sono:
# urpmq --fuzzy vdpau
lib64vdpau-devel
lib64vdpau-driver-nouveau
lib64vdpau-driver-r300
lib64vdpau-driver-r600
lib64vdpau-driver-radeonsi
lib64vdpau-driver-virtio_gpu
lib64vdpau-trace
lib64vdpau-va-gl1
lib64vdpau1
vaapi-driver-vdpau
vdpauinfo
vlc-plugin-vdpau
The guessed value will be printed in the Xorg log file, which is
~/.local/share/xorg/Xorg.0.log if rootless, or /var/log/Xorg.0.log if
Xorg is running as root. To search the log file for the values of interest:
$ grep -iE 'vdpau | dri driver' xorg_log_file
(II) RADEON(0): [DRI2] VDPAU driver: radeonsi
dove ho fatto un po di confusione. Comunque le due linee su Xorg ci
sono, eccole:
[ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
>> The proprietary AMDGPU-PRO driver currently only works with X.org
>> 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.
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.
Joe
May 13, 2023, 4:16:16 PM5/13/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> [ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
> [ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
Ottimo, almeno sappiamo di stare sotto Xorg e "radeonsi".
>
> [ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
> [ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
Mi viene in mente che sulla slack ho un file di configurazione per Xorg,
ma forse serve perché ho il driver proprietari nvidia, non so se sia
indispensabile nel caso di altri drivers:
$ cat /etc/X11/xorg.conf.d/10-nvidia.conf
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "Nvidia Corporation"
BoardName ""
EndSection
Ho anche dei templates in /usr/share, per altri drivers tra cui amdgpu:
$ cat /usr/share/X11/xorg.conf.d/10-amdgpu.conf
Section "OutputClass"
Identifier "AMDgpu"
MatchDriver "amdgpu"
Driver "amdgpu"
EndSection
Nel tuo caso potresti fare un tentativo e creare "10-amdgpu.conf" in
"/etc/X11/xorg.conf.d/"
Secondo me non dovrebbe servire, però non si sa mai. Lascialo come
ultima spiaggia insomma.
> 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.
viene utilizzato il processore e non la GPU. Ma per il resto delle
operazioni non è detto che la sceda video non sia adeguatamente
sfruttata dal driver "amdgpu".
Certo quello di decodifica video via hardware gpu era un test buono
per capire se la scheda è gestita e sfruttata in modo ottimale. Ma
alla fine è un compito piuttosto specifico... la GPU fa molto altro.
> Per esempio è un problema i pochi decoder che vdpauinfo mostra?
software dalla CPU. Ma alla fine pazienza: se hai un processore
moderno non è un gran probelma, se hai ancora un macinino con un
core duo quad tipo il mio, tenere il processore scarico e demandare
il più possibile alla scheda video è un must.
> Il problema principale è che mpv non mostra mai la decodifica hardware?
> Altro?
Non saprei, il driver viene caricato, non hai kernel panic, la sessione
grafica si avvia... funzionare funziona comunque in modo accettabile direi.
> # urpmq --fuzzy vdpau
> lib64vdpau-devel
> lib64vdpau-driver-nouveau
> lib64vdpau-driver-r300
> lib64vdpau-driver-r600
> lib64vdpau-driver-radeonsi
> lib64vdpau-driver-virtio_gpu
> lib64vdpau-trace
> lib64vdpau-va-gl1
> lib64vdpau1
> vaapi-driver-vdpau
> vdpauinfo
> vlc-plugin-vdpau
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)
Sandro kensan
May 14, 2023, 5:37:41 PM5/14/23
to
On 13/05/23 22:16, Joe wrote:
> Sandro kensan <ken...@kensan.it> wrote:
>>
>> [ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
>> [ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
>
> Ottimo, almeno sappiamo di stare sotto Xorg e "radeonsi".
dovevo scrivere queste cose diversi post fa ma ho fatto confusione...
> Sandro kensan <ken...@kensan.it> wrote:
>>
>> [ 19.129] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
>> [ 19.129] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
>
> Ottimo, almeno sappiamo di stare sotto Xorg e "radeonsi".
ne so praticamente nulla e quindi seguo quel che mi dici.
>> # urpmq --fuzzy vdpau
>> lib64vdpau-devel
>> lib64vdpau-driver-nouveau
>> lib64vdpau-driver-r300
>> lib64vdpau-driver-r600
>> lib64vdpau-driver-radeonsi
>> lib64vdpau-driver-virtio_gpu
>> lib64vdpau-trace
>> lib64vdpau-va-gl1
>> lib64vdpau1
>> vaapi-driver-vdpau
>> vdpauinfo
>> 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
> ---------
fosse, adesso la situazione è questa:
# rpm -qa | grep -i vdpau
lib64vdpau1-1.5-1.mga9
vlc-plugin-vdpau-3.0.18-5.mga9.tainted
vdpauinfo-1.5-1.mga9
lib64vdpau-driver-radeonsi-23.0.3-2.mga9
vaapi-driver-vdpau-0.7.4-11.mga9
> 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)
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
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
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
VO: [gpu] 1920x1080 yuv420p
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)
(+) Video --vid=1 (mpeg4 720x480 29.970fps)
(+) Audio --aid=1 (mp3 2ch 44100Hz)
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
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
No video PTS! Making something up. Using 29.970030 FPS.
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
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
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
Exiting... (Quit)
Joe
May 15, 2023, 7:01:39 AM5/15/23
to
Sandro kensan <ken...@kensan.it> wrote:
>>
> Non era istallato solo vaapi-driver-vdpau perché non capivo che roba
> fosse, adesso la situazione è questa:
>
> # rpm -qa | grep -i vdpau
> lib64vdpau1-1.5-1.mga9
> vlc-plugin-vdpau-3.0.18-5.mga9.tainted
> vdpauinfo-1.5-1.mga9
> lib64vdpau-driver-radeonsi-23.0.3-2.mga9
> vaapi-driver-vdpau-0.7.4-11.mga9
Ottimo, si fa per dire...
>>
> Non era istallato solo vaapi-driver-vdpau perché non capivo che roba
> fosse, adesso la situazione è questa:
>
> # rpm -qa | grep -i vdpau
> lib64vdpau1-1.5-1.mga9
> vlc-plugin-vdpau-3.0.18-5.mga9.tainted
> vdpauinfo-1.5-1.mga9
> lib64vdpau-driver-radeonsi-23.0.3-2.mga9
> vaapi-driver-vdpau-0.7.4-11.mga9
> 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_DRIVER_NAME. Comunque sì alla fine usava già di suo "radeonsi"
quindi non dovrebbe servire.
> vainfo: Driver version: Mesa Gallium driver 23.0.3 for AMD Radeon RX 550
da mageia... leggi oltre
> 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
Il driver amdgpu li digerisce anche lui.
Ma questi codecs hanno un problemino: non sarebbero redistribuili
senza previo pagamento di un diritto a "qualcuno", se interessa
saperne di più:
https://jina-liu.medium.com/settle-your-questions-about-h-264-license-cost-once-and-for-all-hopefully-a058c2149256
> 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
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.
Sandro kensan
May 15, 2023, 12:52:38 PM5/15/23
to
On 15/05/23 12:59, Joe wrote:
> Sandro kensan <ken...@kensan.it> wrote:
>>>
>> Non era istallato solo vaapi-driver-vdpau perché non capivo che roba
>> fosse, adesso la situazione è questa:
>>
>> # rpm -qa | grep -i vdpau
>> lib64vdpau1-1.5-1.mga9
>> vlc-plugin-vdpau-3.0.18-5.mga9.tainted
>> vdpauinfo-1.5-1.mga9
>> lib64vdpau-driver-radeonsi-23.0.3-2.mga9
>> vaapi-driver-vdpau-0.7.4-11.mga9
>
> Ottimo, si fa per dire...
quindi non serviva a molto, mi pare di capire.
> Sandro kensan <ken...@kensan.it> wrote:
>>>
>> Non era istallato solo vaapi-driver-vdpau perché non capivo che roba
>> fosse, adesso la situazione è questa:
>>
>> # rpm -qa | grep -i vdpau
>> lib64vdpau1-1.5-1.mga9
>> vlc-plugin-vdpau-3.0.18-5.mga9.tainted
>> vdpauinfo-1.5-1.mga9
>> lib64vdpau-driver-radeonsi-23.0.3-2.mga9
>> vaapi-driver-vdpau-0.7.4-11.mga9
>
> Ottimo, si fa per dire...
> Questa riga in realtà non te la dava senza impostare la variabile
> LIBVA_DRIVER_NAME. Comunque sì alla fine usava già di suo "radeonsi"
> quindi non dovrebbe servire.
prima caricava correttamente i driver radeonsi.
>> vainfo: Driver version: Mesa Gallium driver 23.0.3 for AMD Radeon RX 550
>
> Mi sa che alla fine il problema sta nel pacchetto mesa fornito
> da mageia... leggi oltre
>
>
>> 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
>
> Non c'è traccia di H264 nè H265, invece la tua GPU li supporta...
saranno utilissime se mi rivolgo al forum di Mageia in inglese.
> Il driver amdgpu li digerisce anche lui.
> Ma questi codecs hanno un problemino: non sarebbero redistribuili
> senza previo pagamento di un diritto a "qualcuno", se interessa
> saperne di più:
>
> https://jina-liu.medium.com/settle-your-questions-about-h-264-license-cost-once-and-for-all-hopefully-a058c2149256
quindi anche i successori. Ho letto che hanno aumentato i costi di
licenza, spero non abbiano variato la licenza. Sapevo che per la
decodifica questi driver erano gratuiti, dovrebbero esserci problemi per
l'encoding o per chi costruisce dispositivi hw che encodano.
Io comunque ho installato i repository Tainted che mi permettono di
usare il software che altrove è illegale. Ovviamente dipende dagli Stati.
>
>> 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
>
> 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.
So che il problema potrebbe essere la redistribuzione ma sapevo che il
>> 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
>
> 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.
decoding è gratuito.
> 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"?
Tainted installati.
# urpmq --list-media active
Core Release
Core Updates
Nonfree Release
Nonfree Updates
Tainted Release
Tainted Updates
# rpm -qa | grep -i mesa
lib64mesaglu1-9.0.2-3.mga9
lib64mesavulkan-drivers-23.0.3-2.mga9
lib64mesagl1-23.0.3-2.mga9
mesa-23.0.3-2.mga9
lib64mesaegl1-23.0.3-2.mga9
lib64osmesa8-23.0.3-2.mga9
mesa-demos-8.5.0-3.mga9
lib64mesaglesv2_2-23.0.3-2.mga9
# urpmq --fuzzy mesa
lib64mesaegl-devel
lib64mesaegl1
lib64mesagl-devel
lib64mesagl1
lib64mesaglesv1-devel
lib64mesaglesv1_1
lib64mesaglesv2-devel
lib64mesaglesv2_2
lib64mesaglu1
lib64mesaglu1-devel
lib64mesakhr-devel
lib64mesaopencl-devel
lib64mesaopencl1
lib64mesavulkan-devel
lib64mesavulkan-drivers
lib64osmesa-devel
lib64osmesa8
mesa
mesa-common-devel
mesa-demos
mesa-omx-drivers
mesa-demos lo ho installato io per avere dei test sul funzionamento
della scheda grafica e in effetti funziona bene era un pacchetto che
visualizzava un coniglio, una medusa e altro renderizzato. Dava un
punteggio alla fine. C'è un wiki che permetteva di fare un confronto dei
punteggi tra le varie schede grafiche.
L'unico pacchetto che installerei è opnecl che non è installato.
> 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. ;)
nel forum in inglese di Mageia e vedo cosa mi possono dire.
> 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.
che viola o potrebbe violare una licenza software?
Comunque anche se diffusissimi le codifiche h.264 mi sono sempre state
antipatiche in quanto usano dei sistemi sociali per farti pagare dei
soldi direttamente o indirettamente, penso che nel coste della mia RX550
ci siano le licenze a questo gruppo di società (consorzio), tra cui
Apple se non ricordo male. Poi non so come te la pensi.
> 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
> -------------------------------------------------------------
Non so come funziona dnf ma comunque fa uno swap tra due driver, uno
normale e uno tainted (immagino) e con i decoder per gli h.xxx necessari
dalla versione 37 in poi di Fedora.
Caspita, Fedora 37 è di novembre 2022.
>
> 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
> In pratica si dovrebbe capire come ottenere con Mageia la stessa cosa.
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?
Joe
May 15, 2023, 1:40:11 PM5/15/23
to
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.
Joe
May 15, 2023, 5:24:44 PM5/15/23
to
Joe <J...@e.invalid> wrote:
>
> 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.
Spetta, ho fatto casino...
>
> 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.
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}
-Dcpp_std=gnu++17 \
-Dplatforms=x11,wayland \
-Ddri3=enabled \
-Dosmesa=true \
-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.
Sandro kensan
May 16, 2023, 4:23:42 PM5/16/23
to
>> 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.
Hi there, if you're interested, you may want to ask on the dev mailing
>>
>> 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.
list as mentioned in that other thread.
But this is more of a feature then a bug, because those would induce
codec license fees by shipping those codecs enabled for encoding AFAIK -
that is also mentioned in the upstream commit in the linked thread.
Although in our mesa package I don't see the video-codecs option set at
all, so this should use the default.
But I also don't see any bugreports regarding mesa on this issue, so if
nobody cared to report this or asked on the dev mailing list ...
questa la risposta da parte di Doktor5000, lui risponde a tutti. Io non
ho capito molto di quello che ha scritto e quindi non gli ho ancora
risposto. Mi pare dica che se inserissero i codec mesa diventerebbe a
pagamento e che quindi questa è una feature. ok.
Della seconda parte non mi è chiaro se i codec in mesa siano settati o
meno. Pare che nessuno si sia lamentato della mancanza dei codec,
nessuno ha aperto un bug o chiesto nel ml.
Cosa posso rispondergli?
> 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...
h.265/5. Sei sicuro che non siano abilitati in mesa i codec per l'hw
della mia RX550?
> 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.
ho idea da dove iniziare. Dovrei studiare un po' di wiki.
ok, compili un srpm e ti vengono fuori più rpm.
> 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...
il make. Se ti da errore per qualche dipendenza allora la installi e
ridai make, alla fine quando è tutto ok fai un install. No?
> 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
dal browser è più veloce.
> 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.
scaricarmi il pacchetto srpm.
Occorre scaricarsi i devel per la compilazione del pacchetto nei vari
linguaggi: mesa in cosa è scritto? Assembler 6502?
poi scarico rpm-build e bm. Tutti questi pacchetti avranno una serie
enorme di dipendenze, non è che mi piaccia tanto...
È un po' come fare una compilazione, occorre scaricare dai repo tanta roba.
> 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".
...
cd ~/rpmbuild/SPECS
rpmbuild -ba texworks.spec
Check ~/rpmbuild/RPMS/x86_64: you will see the created packages.
e poi si da un # urpmi ~/rpmbuild/RPMS/x86_64/mesa.rpm
(stando attenti alla ~)
> 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...
dire che non può essere modificato per cui devo modificarlo ad un certo
punto del boot, prima che si carichi l'interfaccia grafica.
> 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.
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.
Joe
May 16, 2023, 6:08:56 PM5/16/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> 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.
Al limite puoi sempre reinstallare il pacchetto mesa di default.
>
> 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.
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.
Sandro kensan
May 17, 2023, 6:35:22 PM5/17/23
to
On 17/05/23 00:07, Joe wrote:
> 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.
Innanzitutto ti ringrazio per la grande consulenza che mi hai dato. Vado
> 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.
a scrivere il post e vediamo se ricevo risposta da quelli del forum.
Joe
May 18, 2023, 9:39:34 AM5/18/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 17/05/23 00:07, Joe wrote:
>
>> 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.
>
> 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.
Sì bene, metti anche un link qui, tanto per completezza.
> On 17/05/23 00:07, Joe wrote:
>
>> 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.
>
> 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 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.
Sandro kensan
May 18, 2023, 11:22:32 AM5/18/23
to
On 18/05/23 15:38, Joe wrote:
> 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.
Il mio processore è datato ma abbastanza potente per l'epoca. Però
> 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.
d'estate è un problema perché la ventola va a mille.
> Per cui fai un favore se tieni linkata questa discussione usenet
> al forum e alla mailing list di mageia.
Forse occorre andare di google o altri portali che catalogano usenet.
Ho trovato: google ha i gruppi di discussione anche di usenet e non
necessita di password per accedervi:
https://groups.google.com/g/it.comp.os.linux.iniziare/c/5yJA3THxqGc
lo metto nel forum di JMageia in inglese.
> Ti anticipo che ho fatto un tentativo anch'io alla fine.
Da qui in poi ho tradotto:
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
Sandro kensan
May 18, 2023, 2:55:56 PM5/18/23
to
On 18/05/23 17:21, Sandro kensan wrote:
> 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
Questa la risposta che ho ottenuto:
> 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
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?
Joe
May 18, 2023, 3:07:16 PM5/18/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> Ho messo il link del forum qui sun ng ma il contrario non so come fare.
No ma io intendevo questo... Cioè mettere QUI un link alle risposte che
>
> Ho messo il link del forum qui sun ng ma il contrario non so come fare.
arrivano dal forum e dalla mailing list in inglese.
> 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
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"...
Joe
May 18, 2023, 3:15:35 PM5/18/23
to
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
Sandro kensan
May 19, 2023, 9:19:34 PM5/19/23
to
On 18/05/23 21:15, Joe wrote:
> Prova per conto tuo a creare il pachetto rpm di mesa,
> vedi i dettagli sull'altro mio post che ho inviato pochi
> miuti fa.
ok,
> Prova per conto tuo a creare il pachetto rpm di mesa,
> vedi i dettagli sull'altro mio post che ho inviato pochi
> miuti fa.
ho installato 200 pacchetti e questo mi dispiace :(
Comunque la prima compilazione non mi ha dato errori (exit 0), dovrebbe
essere tutto a posto:
Wrote: /home/sandro/rpmbuild/SRPMS/mesa-23.1.0-2.mga9.src.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-nouveau-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-radeonsi-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-virtio_gpu-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64dri-drivers-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesavulkan-drivers-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64d3d1-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/mesa-omx-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-r600-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64xatracker2-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesavulkan-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64osmesa8-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaopencl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-virtio_gpu-23.1.0-2.mga9.x86_64.rpm
Wrote: /home/sandro/rpmbuild/RPMS/x86_64/lib64d3d1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-radeonsi-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-nouveau-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesagl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaopencl1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64vdpau-driver-r600-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesagl1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64gbm1-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaegl1-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaegl1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64glapi0-debuginfo-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64glapi0-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesagl-devel-23.1.0-2.mga9.x86_64.rpm
Wrote: /home/sandro/rpmbuild/RPMS/x86_64/lib64gbm1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/mesa-omx-drivers-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64d3d-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaegl-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64gbm-devel-23.1.0-2.mga9.x86_64.rpm
Wrote: /home/sandro/rpmbuild/RPMS/x86_64/mesa-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaopencl-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64xatracker-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64osmesa-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64glapi-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesakhr-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaglesv1-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaglesv1_1-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaglesv2_2-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesaglesv2-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64mesavulkan-devel-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64osmesa8-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64xatracker2-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/mesa-debugsource-23.1.0-2.mga9.x86_64.rpm
Wrote:
/home/sandro/rpmbuild/RPMS/x86_64/lib64dri-drivers-debuginfo-23.1.0-2.mga9.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.r53RIc
+ umask 022
+ cd /home/sandro/rpmbuild/BUILD
+ cd mesa-23.1.0
+ /usr/bin/rm -rf /home/sandro/rpmbuild/BUILDROOT/mesa-23.1.0-2.mga9.x86_64
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.Ik3owi
+ umask 022
+ cd /home/sandro/rpmbuild/BUILD
+ rm -rf mesa-23.1.0 mesa-23.1.0.gemspec
+ RPM_EC=0
++ jobs -p
+ exit 0
RPM build warnings:
Duplicate build-ids
/home/sandro/rpmbuild/BUILDROOT/mesa-23.1.0-2.mga9.x86_64/usr/lib64/libGLX_mesa.so.0.0.0
and
/home/sandro/rpmbuild/BUILDROOT/mesa-23.1.0-2.mga9.x86_64/usr/lib64/mesa/libGLX_mesa.so.0.0.0
Duplicate build-ids
/home/sandro/rpmbuild/BUILDROOT/mesa-23.1.0-2.mga9.x86_64/usr/lib/debug/usr/lib64/libGLX_mesa.so.0.0.0-23.1.0-2.mga9.x86_64.debug
and
/home/sandro/rpmbuild/BUILDROOT/mesa-23.1.0-2.mga9.x86_64/usr/lib/debug/usr/lib64/mesa/libGLX_mesa.so.0.0.0-23.1.0-2.mga9.x86_64.debug
i warnings non li capisco assolutamente ma pare ci siano dei duplicati (?).
> 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.
modificando il file spec. Esatto? oppure posso fare la nuova
compilazione sopra i file vecchi? Quel che non mi è certo è dove mettere
la riga dei codec. Io la metterei all'inizio oppure alla fine:
%meson \
*********************************************************
-Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec \
*********************************************************
-Dcpp_std=gnu++17 \
-Dplatforms=x11,wayland \
-Ddri3=enabled \
-Dosmesa=true \
%ifarch %{ix86}
-Dsse2=false \
%endif
...
-Dplatforms=x11,wayland \
-Ddri3=enabled \
-Dosmesa=true \
%ifarch %{ix86}
-Dsse2=false \
%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 \
-Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec \
*********************************************************
%{nil}
%meson_build
Può andare bene una delle due scelte?
Ti chiedo perché la compilazione mi richiede 20 minuti e il processore
va a 90 gradi.
> 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
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.
Joe
May 20, 2023, 7:16:07 AM5/20/23
to
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!
Sandro kensan
May 21, 2023, 8:56:21 AM5/21/23
to
On 20/05/23 13:14, Joe wrote:
> 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'
ecco, questo era il comando che cercavo diversi mesi fa dopo avere fatto
> 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'
l'installazione, invece ho ripiegato sul singolo repository dalla
Finlandia. Da quel che ho capito con $MIRRORLIST utilizza una serie di
repo in modo tale che se uno da errore al wget passa al successivo, in
questo mondo non ci sono mai problemi come invece è capitato a me.
> 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.
aggiunto in passato. Cancellando tutti i repo eccetto source e poi dando
il comando i tainted ci sono.
> 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! ;)
è di molti anni fa, Credo di averlo comprato usato.
> 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.
poi vengono sempre aggiornati.
>
>
> -------- 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!
la compilazione è andata a buon fine, poi ho dato:
>
> -------- 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!
$ 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 \
%{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
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
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 ---
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE 3 65536 4096 4096
MPEG2_MAIN 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
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
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 ---
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 ---
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_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?
HEVC_MAIN_444_12 --- not supported ---
AV1_MAIN --- not supported ---
AV1_HIGH --- not supported ---
AV1_PROFESSIONAL --- not supported ---
mpv non funziona con:
$ mpv --no-config --vo=gpu --hwdec=vdpau
Comunque sei bravissimo, complimenti, non ci speravo... :)
Joe
May 21, 2023, 5:34:03 PM5/21/23
to
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.
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.
Joe
May 21, 2023, 6:02:57 PM5/21/23
to
>> urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST'
delle interfacce, soprattutto quando si comunica con altri via
usenet.
I tainted li aggiungeva anche a me se ricordo bene, ma di default
non mi risultavano "active", si può verificare con:
https://wiki.mageia.org/en/URPMI#Media.2FRepository_commands
--------------------------------------------------------------------
urpmq --list-media active Show all active repositories
urpmq --list-media active --list-url Show all active repositories and their URLs
------------------------------------
Quel wiki lì sopra è molto completo sull'uso di URPM*... conviene
investirci un po' di tempo nella lettura se si usa mageia, poi ti
ritrovi più consapevole di come gestire i pacchetti.
>> urpme --auto-orphans
> comando molto pericoloso...
Se poi ti accorgi che manca qualcosa lo potrai sempre riaggiungere,
se sono pacchetti orfani è perché erano stati messi come dipendenza
di qualcosa che hai poi rimosso. In questo caso però parliamo di
pacchetti che servono come dipendenza "build time" cioè necessari
per compilare e lavorare i sorgenti di un certo pacchetto, non so
se poi te li marca come orfani... sicuramente sono pacchetti che non
servono ai pacchetti generati dalla compilazione in "run time", cioè
per farli girare.
Infatti ad esempio mesa prima ti funzionava, discorso codec a parte,
eppure non avevi tutti i pacchetti -devel necessari per costruire
l'rpm finale di mesa stesso.
Detto questo ripeto, non so se i -devel vengono poi marcati come orfani,
insomma veditelo un po' in autonomia questo aspetto, cerca in rete,
io alla fine su salckware non ho gestione dipendenze per cui non sono
pratico di come rpm tenga in conto questa roba.
> Ho spazio su disco ma non mi fa piacere avere un sacco di pacchetti che
> poi vengono sempre aggiornati.
Giusto, motivo in più per cercare e capire come gestire
questi pacchetti di sviluppo necessari per compilare e
poi eventualmente eliminarli quando nno servonon più.
In Fedora con dnf si può fare qualcosa ma ho visto al
volo, non ho approfondito.
> ma devo installare altri pacchetti oltre che mesa.rpm? Ci sono un sacco
> 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.
>
> A me aggiunge anche i tanted ma forse ha memoria dei repo che ho
> aggiunto in passato. Cancellando tutti i repo eccetto source e poi dando
> il comando i tainted ci sono.
Puoi verificarlo da terminale, come sempre è meglio e più chiaro
> A me aggiunge anche i tanted ma forse ha memoria dei repo che ho
> aggiunto in passato. Cancellando tutti i repo eccetto source e poi dando
> il comando i tainted ci sono.
delle interfacce, soprattutto quando si comunica con altri via
usenet.
I tainted li aggiungeva anche a me se ricordo bene, ma di default
non mi risultavano "active", si può verificare con:
https://wiki.mageia.org/en/URPMI#Media.2FRepository_commands
--------------------------------------------------------------------
urpmq --list-media active Show all active repositories
urpmq --list-media active --list-url Show all active repositories and their URLs
------------------------------------
Quel wiki lì sopra è molto completo sull'uso di URPM*... conviene
investirci un po' di tempo nella lettura se si usa mageia, poi ti
ritrovi più consapevole di come gestire i pacchetti.
>> urpme --auto-orphans
> comando molto pericoloso...
se sono pacchetti orfani è perché erano stati messi come dipendenza
di qualcosa che hai poi rimosso. In questo caso però parliamo di
pacchetti che servono come dipendenza "build time" cioè necessari
per compilare e lavorare i sorgenti di un certo pacchetto, non so
se poi te li marca come orfani... sicuramente sono pacchetti che non
servono ai pacchetti generati dalla compilazione in "run time", cioè
per farli girare.
Infatti ad esempio mesa prima ti funzionava, discorso codec a parte,
eppure non avevi tutti i pacchetti -devel necessari per costruire
l'rpm finale di mesa stesso.
Detto questo ripeto, non so se i -devel vengono poi marcati come orfani,
insomma veditelo un po' in autonomia questo aspetto, cerca in rete,
io alla fine su salckware non ho gestione dipendenze per cui non sono
pratico di come rpm tenga in conto questa roba.
> Ho spazio su disco ma non mi fa piacere avere un sacco di pacchetti che
> poi vengono sempre aggiornati.
questi pacchetti di sviluppo necessari per compilare e
poi eventualmente eliminarli quando nno servonon più.
In Fedora con dnf si può fare qualcosa ma ho visto al
volo, non ho approfondito.
> ma devo installare altri pacchetti oltre che mesa.rpm? Ci sono un sacco
> di rpm nella cartella x64 della compilazione.
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.
Sandro kensan
May 21, 2023, 9:42:11 PM5/21/23
to
On 21/05/23 23:32, Joe wrote:
> 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
dal man dovrebbero essere la stessa cosa o molto simili. Io ho usato
> 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
reinstall.
Ho istallato i pacchetti rpm eccetto i debug.
> È 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.
Certo.
> 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.
Comunque ho capito, con spec si può modificare il nome del file
compilato (rpm) e aggiungere un tag apposito a scelta in moda da
distinguere il pacchetto.
> 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.
che se premo tab mi da sia la lista di rpm che i nomi dei pacchetti da
repo, es:
$ sudo urpmi mesa [se premo tab dopo la a di mesa]
mesa-23.1.0-2.mga9.x86_64.rpm
mesa
mesa-common-devel-23.1.0-2.mga9.x86_64.rpm
ecc.
Poi vdpauinfo è cambiato dopo l'installazione dei due soli pacchetti
mesa e radeonsi driver, quindi non sono rimasti gli originali.
> Assicurato di avere TUTTI i nuovi rpm e non più i vecchi:
>
> va-info
$ vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.16.0
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.1.0 for AMD Radeon RX 550
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
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
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : 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
> vfpauinfo
$ 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:
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:
$ 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). <=========================
(+) 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 vaapi[nv12]
AV: 00:00:31 / 00:00:31 (100%) A-V: 0.000
Exiting... (End of file)
> mpv --noconfig --vo=gpu --hwdec=vdpau
$ 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)
(+) 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
VO: [gpu] 1920x1080 yuv420p
Exiting... (End of file)
> 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). <=====================
(+) 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 vaapi[nv12]
AV: 00:00:31 / 00:00:31 (100%) A-V: 0.000
Exiting... (End of file)
>
> 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.
ok.
> si capisce. Cose del tipo "non funziona" lasciano il tempo
> che trovano, bisogna vedere cosa esce a terminale per
> capirci qualcosa.
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)
(+) 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
VO: [gpu] 1920x1080 yuv420p
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)
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
VO: [gpu] 1920x1080 yuv420p
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)
(+) 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
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:05 / 00:00:31 (17%) A-V: 0.000
Exiting... (Quit)
Altri test con mpeg4:
Exiting... (Quit)
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
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
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)
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
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 720x480 => 853x480 yuv420p
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
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
Exiting... (Quit)
***
Ciao, comincia a funzionare :)
Sandro kensan
May 21, 2023, 9:58:19 PM5/21/23
to
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
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ì?
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
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
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
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ì?
Joe
May 22, 2023, 5:42:43 AM5/22/23
to
Sandro kensan <ken...@kensan.it> wrote:
> 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
> [...]
> 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
>
> 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ì?
Io li avrei installati tutti. Per non saper ne leggere ne scrivere.
> 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ì?
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.
Joe
May 22, 2023, 6:51:14 AM5/22/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
>> va-info
>> vfpauinfo
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.
>
>> va-info
>> mpv --noconfig --vo=gpu --hwdec=auto
>
> $ 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:31 / 00:00:31 (100%) A-V: 0.000
OK, qui ci siamo direi. In automatico sceglie l'api "vaapi" qundi.
>
> $ 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:31 / 00:00:31 (100%) A-V: 0.000
>> vfpauinfo
>
>> mpv --noconfig --vo=gpu --hwdec=vdpau
>
> $ 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:31 / 00:00:31 (100%) A-V: 0.000
Qui invece c'è qualcosa che non va...
>> mpv --noconfig --vo=gpu --hwdec=vdpau
>
> $ 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:31 / 00:00:31 (100%) A-V: 0.000
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.
Sandro kensan
May 22, 2023, 9:01:52 PM5/22/23
to
On 22/05/23 11:42, Joe wrote:
> 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
> Io li avrei installati tutti. Per non saper ne leggere ne scrivere.
ex novo. Poi faccio le prove che mi hai indicato nell'altro post.
Joe
May 23, 2023, 6:45:37 AM5/23/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 22/05/23 11:42, Joe wrote:
>
>> 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.
Già che sei di strada segnateli tutti:
> On 22/05/23 11:42, Joe wrote:
>
>> 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.
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.
Sandro kensan
May 23, 2023, 8:40:56 PM5/23/23
to
On 23/05/23 12:44, Joe wrote:
> Sandro kensan <ken...@kensan.it> wrote:
>> On 22/05/23 11:42, Joe wrote:
>>
>>> 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.
>
> Già che sei di strada segnateli tutti:
>
> find rpmbuild/RPMS -iname "*rpm" | cut -f3 -d\/ > mesa-rebuild-rpms.log
$ find rpmbuild/RPMS/x86_64/ -iname "*rpm" | cut -f4 -d\/
> Sandro kensan <ken...@kensan.it> wrote:
>> On 22/05/23 11:42, Joe wrote:
>>
>>> 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.
>
> 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):
mesa-23.1.0-2.mga9.x86_64.rpm => mesa
occorre tagliare "-23.1.0-2.mga9.x86_64.rpm"
io l'ho fatto con Find and Replace ma con bash si può fare lo stesso ma
io conosco bene solo il Php.
> 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
Risultato:
...
lib64d3d1-debuginfo new installed
lib64mesavulkan-drivers-debuginfo new installed
lib64mesaopencl1 new installed
lib64d3d-devel new installed
lib64vdpau-driver-nouveau-debuginfo new installed
lib64vdpau-driver-r600-debuginfo new installed
lib64osmesa-devel new installed
lib64mesaegl1 replaced
mesa replaced
...
> 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
for package in $(grep "new installed" mesa-rebuild-restore.log | cut
-f1); do
echo -e $package
done
lib64mesaglesv1-devel
lib64gbm-devel
lib64mesakhr-devel
lib64glapi-devel
lib64dri-drivers-debuginfo
lib64mesaegl-devel
lib64glapi0-debuginfo
mesa-debuginfo
lib64mesagl1-debuginfo
lib64osmesa8-debuginfo
lib64mesaopencl1-debuginfo
mesa-common-devel
mesa-omx-drivers-debuginfo
lib64xatracker-devel
lib64vdpau-driver-r600
lib64mesaglesv2-devel
lib64mesagl-devel
lib64vdpau-driver-virtio_gpu-debuginfo
lib64mesaglesv1_1
lib64mesavulkan-devel
lib64xatracker2-debuginfo
lib64vdpau-driver-radeonsi-debuginfo
lib64vdpau-driver-virtio_gpu
lib64mesaegl1-debuginfo
lib64d3d1-debuginfo
lib64mesavulkan-drivers-debuginfo
lib64mesaopencl1
lib64d3d-devel
lib64vdpau-driver-nouveau-debuginfo
lib64vdpau-driver-r600-debuginfo
lib64osmesa-devel
lib64vdpau-driver-nouveau
mesa-debugsource
lib64d3d1
mesa-omx-drivers
lib64mesaopencl-devel
lib64gbm1-debuginfo
> 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.
$ 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
Joe
May 24, 2023, 4:39:05 AM5/24/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> occorre tagliare tutto il nome del pacchetto:
> mesa-23.1.0-2.mga9.x86_64.rpm => mesa
> occorre tagliare "-23.1.0-2.mga9.x86_64.rpm"
> io l'ho fatto con Find and Replace ma con bash si può fare lo stesso ma
> io conosco bene solo il Php.
Fai prima a farlo a mano, una volta che hai i pacchetti
>
> occorre tagliare tutto il nome del pacchetto:
> mesa-23.1.0-2.mga9.x86_64.rpm => mesa
> occorre tagliare "-23.1.0-2.mga9.x86_64.rpm"
> io l'ho fatto con Find and Replace ma con bash si può fare lo stesso ma
> io conosco bene solo il Php.
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.
Sandro kensan
May 24, 2023, 6:43:58 AM5/24/23
to
On 22/05/23 11:42, Joe wrote:
> 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.
Allora ho eseguito un doppio giro con il for:
> 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.
for package in $(ls); do sudo urpmi --reinstall $package; done
e alla fine si installano tutti ma chiede tre dipendenze:
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) n
Con le dipendenze ho sempre risposto no anche perché mi avrebbe
installato i pacchetti dai repo e invece si trattava solo di un ordine
di installazione da eseguire in modo diverso. In pratica prima si doveva
installare:
$ sudo urpmi --reinstall mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
e poi gli altri pacchetti. Comunque dopo il secondo giro è rimasto
quello in alto. Sono tre pacchetti develop e quindi non dovrebbero
esserci problemi se per adesso se non li installo. Giusto?
> 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".
resto che spieghi più avanti. Dovrei fare a meno di installare un mesa
nuovo, poi spero che i pacchetti che vengono generati dal src del mesa
cambino di versione come cambia il mesa. Nel caso in cui mi si chieda di
installare un mesa più aggiornato dovrei rifare la compilazione oppure
non installare quello nuovo.
> 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.
Comunque io esegui compilazioni ogni morte di un Papa.
>
> - 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.
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.
Joe
May 24, 2023, 8:24:20 AM5/24/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> Allora ho eseguito un doppio giro con il for:
>
> for package in $(ls); do sudo urpmi --reinstall $package; done
>
> e alla fine si installano tutti ma chiede tre dipendenze:
>
> 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) n
>
> Con le dipendenze ho sempre risposto no anche perché mi avrebbe
> installato i pacchetti dai repo e invece si trattava solo di un ordine
> di installazione da eseguire in modo diverso. In pratica prima si doveva
> installare:
> $ sudo urpmi --reinstall mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
> e poi gli altri pacchetti. Comunque dopo il secondo giro è rimasto
> quello in alto. Sono tre pacchetti develop e quindi non dovrebbero
> esserci problemi se per adesso se non li installo. Giusto?
Per i pacchetti custom che vanno a rimpiazzare gli originali già
>
> Allora ho eseguito un doppio giro con il for:
>
> for package in $(ls); do sudo urpmi --reinstall $package; done
>
> e alla fine si installano tutti ma chiede tre dipendenze:
>
> 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) n
>
> Con le dipendenze ho sempre risposto no anche perché mi avrebbe
> installato i pacchetti dai repo e invece si trattava solo di un ordine
> di installazione da eseguire in modo diverso. In pratica prima si doveva
> installare:
> $ sudo urpmi --reinstall mesa-debuginfo-23.1.0-2.mga9.x86_64.rpm
> e poi gli altri pacchetti. Comunque dopo il secondo giro è rimasto
> quello in alto. Sono tre pacchetti develop e quindi non dovrebbero
> esserci problemi se per adesso se non li installo. Giusto?
installati non dovrebbe chiederti alcuna dipendenza.
Altrimenti come faresti averli già lì?
Per i nuovi pacchetti custom che non sono già installati invece
hai ragione... urpmi tenta di risolvere le dipendenza ma appoggiandosi
al repo ufficiale anciché ad altri pacchetti custom appena prodotti,
e questo non va bene.
Devi cercare il modo di installare tutti questi nuovi custom
in prima battuta senza risoluzione dipendenze, così da assicurarti
che vengano realmente installati loro e non omonimi del repo,
altrimenti il build non sarebbe servito a nulla.
Forzata l'installazione dei nuovi custom, potrai verificare la
mancanza di qualche dipendenza, sta volta appoggiandoti anche
al repo ufficiale perché si tratterà di pacchetti non prodotti
dal build di mesa.
Come ottenere questo risultato devi saperlo tu via urpmi e
documentazione al seguito.
Veniamo alla pratica:
rispondere no alle varie dipendenze proposte può essere un'idea,
come già hai fatto direi che va bene.
Dei tre pacchetti che avanzano però devi installare tutto:
lib64freeglut-devel 3.4.0 1.mga9 x86_64
lib64mesaglu1-devel 9.0.2 3.mga9 x86_64
con il build che hai fatto. Sono dipendenze richieste da qualcuno
dei pacchetti prodotti.
Qiundi niente, li installi dal repo:
urpmi lib64freeglut lib64mesaglu1
---------------------------------
mesa-common-devel 23.1.0 2.mga9 x86_64
Invece questo no, lo devi installare dalla directory RPMS, fa
parte della lista degli rpm prodotti. Eventualmente installa prima
questo e poi se ti propone i due sopra come dipendenza accetta,
tanto tra i custom non li hai... poi ricontrolla per scrupolo, ma
dalla tua lista degli rpm prodotti che avevi postato l'altro giorno
non li vedo:
https://groups.google.com/g/it.comp.os.linux.iniziare/c/5yJA3THxqGc/m/BUmrFEtxAwAJ
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
> Comunque io esegui compilazioni ogni morte di un Papa.
da mesa e il repo aggiorna (ricompilano loro) mesa e anche pippo...
col tuo mesa custom, il nuovo pippo non funzionerà più, in generale
diciamo che potrebbe non funzionare più.
Sempre in generale l'unica cosa che garantisce la coerenza è:
1- o utilizzare tutto il parco software originale
2- o ricompilare tutto ciò che dipende da un pacchetto custom
introdotto (tipo mesa nel nostro caso)
Poi va be', le mezze misure non vanno mai buttate. Per piccole
modifiche e tempi brevi non ci sono problemi, se tra 6 mesi
aggiorni senza aggiornare anche mesa, qualcosa potrà non funzionare
più.
L'importante è saperlo, la soluzione è aggiornare tutto e ricompilare
ciò che serve customizzato, ovviamente rimpiazzando poi la roba
ufficiale... proprio come stai facendo adesso insomma.
> 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.
aggiornamento saprai dovre potrebbe trovarsi il problema e nel caso
ricompili mesa ecc...
Sandro kensan
May 24, 2023, 7:23:31 PM5/24/23
to
che a scriverla e ricordarsi tutti i particolari di UNIX.
In PHP avre fatto un explode con "-" come separatore e poi avrei preso
tutto il vettore che ne risulta eccetto gli ultimi due elementi e li
avrei unito con un join e "-" come separatore. Oppure avrei preso una
sottostringa senza gli ultimi caratteri con
len("-23.1.0-2.mga9.x86_64.rpm"). Il PHP è molto più semplice.
> 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.
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.
Sandro kensan
May 24, 2023, 7:40:12 PM5/24/23
to
On 24/05/23 14:22, Joe wrote:
> Dei tre pacchetti che avanzano però devi installare tutto:
>
> lib64freeglut-devel 3.4.0 1.mga9 x86_64
> lib64mesaglu1-devel 9.0.2 3.mga9 x86_64
>
> Questi due li puoi installare dal repo, perché non sono prodotti
> con il build che hai fatto. Sono dipendenze richieste da qualcuno
> dei pacchetti prodotti.
> Qiundi niente, li installi dal repo:
>
> urpmi lib64freeglut lib64mesaglu1
> ---------------------------------
>
> mesa-common-devel 23.1.0 2.mga9 x86_64
>
> Invece questo no, lo devi installare dalla directory RPMS, fa
> parte della lista degli rpm prodotti.
Non avevo fatto attenzione. In pratica installando mesa -common-devel mi
> Dei tre pacchetti che avanzano però devi installare tutto:
>
> lib64freeglut-devel 3.4.0 1.mga9 x86_64
> lib64mesaglu1-devel 9.0.2 3.mga9 x86_64
>
> Questi due li puoi installare dal repo, perché non sono prodotti
> con il build che hai fatto. Sono dipendenze richieste da qualcuno
> dei pacchetti prodotti.
> Qiundi niente, li installi dal repo:
>
> urpmi lib64freeglut lib64mesaglu1
> ---------------------------------
>
> mesa-common-devel 23.1.0 2.mga9 x86_64
>
> Invece questo no, lo devi installare dalla directory RPMS, fa
> parte della lista degli rpm prodotti.
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
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
2.2MB of additional disk space will be used.
916KB of packages will be retrieved.
$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))):
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.
Sandro kensan
May 24, 2023, 8:32:10 PM5/24/23
to
On 21/05/23 23:32, Joe wrote:
> Assicurato di avere TUTTI i nuovi rpm e non più i vecchi:
ok, adesso dovrei avere tutti i pacchetti a posto con tutte le dipendenze.
$ 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:
$ 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)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:05 / 00:00:31 (18%) A-V: 0.000
> mpv --noconfig --vo=gpu --hwdec=vdpau
$ 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
$ 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:02 / 00:00:31 (7%) A-V: 0.000
Exiting... (Quit)
> mpv --noconfig --vo=gpu --hwdec=vaapi
Exiting... (Quit)
$ 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).
(+) 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
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
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
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
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'
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.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
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
8bit - AAC2.0.mkv'
(+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
Using hardware decoding (vaapi). <==========================
(+) 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 vaapi[nv12]
AV: 00:00:03 / 00:00:31 (11%) A-V: 0.000
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
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)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vaapi[nv12]
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
Exiting... (Quit)
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.
Sandro kensan
May 24, 2023, 8:38:34 PM5/24/23
to
On 25/05/23 02:32, Sandro kensan wrote:
> 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.
Ho trovato questo:
> 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.
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...
Joe
May 25, 2023, 4:35:42 AM5/25/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 25/05/23 02:32, Sandro kensan wrote:
>
>> 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.
>
> Ho trovato questo:
>
>
> H.264 or VP9 for encoding for YouTube?
Mah.. lì parlano di "codifica", cioè creare un video da cariare
> On 25/05/23 02:32, Sandro kensan wrote:
>
>> 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.
>
> Ho trovato questo:
>
>
> H.264 or VP9 for encoding for YouTube?
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.
Joe
May 25, 2023, 4:55:40 AM5/25/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> 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)
Niente da fare vdpau non funziona.
>
> 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)
> 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'
>
> 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).
>
> Qui rimane al 3%.
>
> ***
>
> $ 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).
>
Niente di ché, hai la conferma che con hwdec auto reisce a trovare il
driver vaapi valido per la decodifica hardware sgravando il processore,
anche VLC in qualche modo riesce a sfruttarla, per capire come fa di
preciso forse si riesce a vedere qualcosa lanciandolo da shell sia con
vlc che senz ainterfaccia con cvlc. A me dice ad esempio:
[00007f07ccc1cec0] avcodec decoder: Using NVIDIA VDPAU Driver Shared
Library 340.108 Wed Dec 11 14:31:24 PST 2019 for hardware decoding
Il ché mi conferma che sta usando decodifica hardware basata su VDPAU
e driver nvidia, io ho il vecchio legacy 340 per la altrettanto vecchia
gpu GT210.
> Comunque direi che mi posso accontentare.
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.
Sandro kensan
May 25, 2023, 8:14:15 PM5/25/23
to
On 25/05/23 10:55, Joe wrote:
> Niente di ché, hai la conferma che con hwdec auto reisce a trovare il
> driver vaapi valido per la decodifica hardware sgravando il processore,
> anche VLC in qualche modo riesce a sfruttarla, per capire come fa di
> preciso forse si riesce a vedere qualcosa lanciandolo da shell sia con
> vlc che senz ainterfaccia con cvlc. A me dice ad esempio:
>
> [00007f07ccc1cec0] avcodec decoder: Using NVIDIA VDPAU Driver Shared
> Library 340.108 Wed Dec 11 14:31:24 PST 2019 for hardware decoding
>
> Il ché mi conferma che sta usando decodifica hardware basata su VDPAU
> e driver nvidia, io ho il vecchio legacy 340 per la altrettanto vecchia
> gpu GT210.
h.265:
> Niente di ché, hai la conferma che con hwdec auto reisce a trovare il
> driver vaapi valido per la decodifica hardware sgravando il processore,
> anche VLC in qualche modo riesce a sfruttarla, per capire come fa di
> preciso forse si riesce a vedere qualcosa lanciandolo da shell sia con
> vlc che senz ainterfaccia con cvlc. A me dice ad esempio:
>
> [00007f07ccc1cec0] avcodec decoder: Using NVIDIA VDPAU Driver Shared
> Library 340.108 Wed Dec 11 14:31:24 PST 2019 for hardware decoding
>
> Il ché mi conferma che sta usando decodifica hardware basata su VDPAU
> e driver nvidia, io ho il vecchio legacy 340 per la altrettanto vecchia
> gpu GT210.
$ vlc Big_Buck_Bunny_1080_10s_30MB.mp4
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[00000000016ed580] main libvlc: Running vlc with the default interface.
Use 'cvlc' to use vlc without interface.
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
[00007f09bcc0ed50] avcodec decoder: Using G3DVL VDPAU Driver Shared
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
Library version 1.0 for hardware decoding <===========
uint DBusMenuExporterDBus::GetLayout(int, int, const QStringList&,
DBusMenuLayoutItem&): Condition failed: menu
uint DBusMenuExporterDBus::GetLayout(int, int, const QStringList&,
DBusMenuLayoutItem&): Condition failed: menu
h.264:
$ vlc 'V204 MKV - AVC 1080p 24fps 8bit - AAC2.0.mkv'
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000000001853580] main libvlc: Running vlc with the default interface.
Use 'cvlc' to use vlc without interface.
uint DBusMenuExporterDBus::GetLayout(int, int, const QStringList&,
DBusMenuLayoutItem&): Condition failed: menu
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
[00007f946cc13390] avcodec decoder: Using G3DVL VDPAU Driver Shared
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
Library version 1.0 for hardware decoding <===========
VC1:
$ vlc hddvd_demo_1080p.mkv
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000000000973580] main libvlc: Running vlc with the default interface.
Use 'cvlc' to use vlc without interface.
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
[00007f8d54c0aa00] avcodec decoder: Using G3DVL VDPAU Driver Shared
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
Library version 1.0 for hardware decoding <===========
[0000000000a3e140] main audio output error: too low audio sample
frequency (0)
[00007f8d54cf0620] main decoder error: failed to create audio output
[0000000000a3e140] vlcpulse audio output error: digital pass-through
stream connection failure: Not supported
[0000000000a3e140] main audio output error: module not functional
[00007f8d54cf0620] main decoder error: failed to create audio output
VC8:
$ vlc 'V208 WEBM - VP8 1080p 24fps 8bit - VORBIS2.0.webm'
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[00000000014ac580] main libvlc: Running vlc with the default interface.
Use 'cvlc' to use vlc without interface.
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
[vp8 @ 0x7f7908c3e180] get_buffer() failed
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
[vp8 @ 0x7f7908c3e180] thread_get_buffer() failed
[vp8 @ 0x7f7908c41240] get_buffer() failed
[vp8 @ 0x7f7908c41240] thread_get_buffer() failed
>> 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.
$ mpv --no-config --vo=gpu --hwdec=auto 'V208 WEBM - VP8 1080p 24fps
8bit - VORBIS2.0.webm'
(+) Video --vid=1 (*) (vp8 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz)
[ffmpeg/video] vp8: No support for codec vp8 profile -99.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:02 / 00:00:31 (9%) A-V: 0.000
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vaapi 'V208 WEBM - VP8 1080p 24fps
Exiting... (Quit)
8bit - VORBIS2.0.webm'
(+) Video --vid=1 (*) (vp8 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz)
[ffmpeg/video] vp8: No support for codec vp8 profile -99.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:02 / 00:00:31 (9%) A-V: 0.000
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V208 WEBM - VP8 1080p 24fps
Exiting... (Quit)
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:03 / 00:00:31 (10%) A-V: 0.000
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
Exiting... (Quit)
Per l'HVEC:
$ mpv --no-config --vo=gpu --hwdec=auto Big_Buck_Bunny_1080_10s_30MB.mp4
(+) Video --vid=1 (*) (hevc 1920x1080 30.000fps)
File tags:
Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
Composer: Sacha Goedegebure
Genre: Animation
Title: Big Buck Bunny, Sunflower version
Using hardware decoding (vaapi).<============================
VO: [gpu] 1920x1080 vaapi[nv12]
V: 00:00:09 / 00:00:10 (100%)
Exiting... (End of file)
$ mpv --no-config --vo=gpu --hwdec=vdpau Big_Buck_Bunny_1080_10s_30MB.mp4
(+) Video --vid=1 (*) (hevc 1920x1080 30.000fps)
File tags:
Artist: Blender Foundation 2008, Janus Bager Kristensen 2013
Comment: Creative Commons Attribution 3.0 - http://bbb3d.renderfarming.net
Composer: Sacha Goedegebure
Genre: Animation
Title: Big Buck Bunny, Sunflower version
VO: [gpu] 1920x1080 yuv420p
V: 00:00:09 / 00:00:10 (100%)
Exiting... (End of file)
Con VP9:
$ mpv --no-config --vo=gpu --hwdec=auto 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].webm'
(+) Video --vid=1 (*) (vp9 1280x720 29.970fps)
[ffmpeg/video] vp9: No support for codec vp9 profile 0.
VO: [gpu] 1280x720 yuv420p
V: 00:00:09 / 00:05:13 (3%)
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vaapi 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].webm'
(+) Video --vid=1 (*) (vp9 1280x720 29.970fps)
[ffmpeg/video] vp9: No support for codec vp9 profile 0.
VO: [gpu] 1280x720 yuv420p
V: 00:00:06 / 00:05:13 (2%)
Exiting... (Quit)
$ mpv --no-config --vo=gpu --hwdec=vdpau 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].webm'
(+) Video --vid=1 (*) (vp9 1280x720 29.970fps)
VO: [gpu] 1280x720 yuv420p
V: 00:00:02 / 00:05:13 (1%)
Exiting... (Quit)
VC1:
$ mpv --no-config --vo=gpu --hwdec=auto hddvd_demo_1080p.mkv
(+) Video --vid=1 (*) '1080p VC-1' (vc1 1920x1080)
(+) Audio --aid=1 --alang=eng (*) 'Dolby Digital 2.0 640kbps' (ac3 2ch
48000Hz)
Audio --aid=2 --alang=eng 'Dolby Digital Plus 5.1 640kbps' (eac3
6ch 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]
AO: [pulse] 48000Hz stereo 2ch float
AV: 00:00:03 / 00:02:01 (3%) A-V: 0.000
$ mpv --no-config --vo=gpu --hwdec=vdpau hddvd_demo_1080p.mkv
(+) Video --vid=1 (*) '1080p VC-1' (vc1 1920x1080)
(+) Audio --aid=1 --alang=eng (*) 'Dolby Digital 2.0 640kbps' (ac3 2ch
48000Hz)
Audio --aid=2 --alang=eng 'Dolby Digital Plus 5.1 640kbps' (eac3
6ch 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:00 / 00:02:01 (0%) A-V: 0.000
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
[ffmpeg/video] vc1: Bits overconsumption: 206424 > 206416
AV: 00:00:03 / 00:02:01 (3%) A-V: 0.000
*****************************
*****************************
Quindi riassumendo mi dicevi nell'altro post:
> La tua scheda in qualche modo dovrebbe supportare hardware decoding
> per VC1, H264, H265, e frose anche VP8. AV1 sicuramente no, e nanche
> VP9.
gli stessi risultati di mpv --auto.
Joe
May 26, 2023, 4:53:08 AM5/26/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 25/05/23 10:55, Joe wrote:
>>
>> [00007f07ccc1cec0] avcodec decoder: Using NVIDIA VDPAU Driver Shared
>> Library 340.108 Wed Dec 11 14:31:24 PST 2019 for hardware decoding
>>
>> Il ché mi conferma che sta usando decodifica hardware basata su VDPAU
>> e driver nvidia, io ho il vecchio legacy 340 per la altrettanto vecchia
>> gpu GT210.
>
> h.265:
> On 25/05/23 10:55, Joe wrote:
>>
>> [00007f07ccc1cec0] avcodec decoder: Using NVIDIA VDPAU Driver Shared
>> Library 340.108 Wed Dec 11 14:31:24 PST 2019 for hardware decoding
>>
>> Il ché mi conferma che sta usando decodifica hardware basata su VDPAU
>> e driver nvidia, io ho il vecchio legacy 340 per la altrettanto vecchia
>> gpu GT210.
>
> h.265:
> [00007f09bcc0ed50] avcodec decoder: Using G3DVL VDPAU Driver Shared
> Library version 1.0 for hardware decoding <===========
>
> h.264:
> Library version 1.0 for hardware decoding <===========
>
> [00007f946cc13390] avcodec decoder: Using G3DVL VDPAU Driver Shared
> Library version 1.0 for hardware decoding <===========
>
> VC1:
> Library version 1.0 for hardware decoding <===========
>
> VC1:
> [00007f8d54c0aa00] avcodec decoder: Using G3DVL VDPAU Driver Shared
> Library version 1.0 for hardware decoding <===========
>
> VP8:
> Library version 1.0 for hardware decoding <===========
>
Fine VLC...
> Con VP8 ho questi risultati:
>
> [ffmpeg/video] vp8: No support for codec vp8 profile -99.
Niente VP8 neanche con MPV.
> Per l'HVEC:
>
> Using hardware decoding (vaapi).<============================
Molto bene!
> Using hardware decoding (vaapi).<============================
> Con VP9:
Peggio che andare di notte... niente da fare.
> Quindi riassumendo mi dicevi nell'altro post:
>
>> La tua scheda in qualche modo dovrebbe supportare hardware decoding
>> per VC1, H264, H265, e frose anche VP8. AV1 sicuramente no, e nanche
>> VP9.
>
> VP8 pare di no e neppure VP9, invece pare VC1, h264/5 funzionino. Vlc ha
> gli stessi risultati di mpv --auto.
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.
Sandro kensan
May 26, 2023, 2:39:33 PM5/26/23
to
On 26/05/23 10:53, Joe wrote:
> 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.
con htop mi mostra un sacco di processi mpv con PID differenti, quando
> 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.
chiudo la finestra di mpv spariscono tutti.
Per esempio con:
$ mpv --no-config --vo=gpu --hwdec=auto 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].mp4'
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi). <==========================
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:02:07 / 00:05:13 (41%) A-V: 0.000
l'mpv che consuma più cpu ha circa il 7% di occupazione e vengono creati
circa 4-6 processi mpv che consumano molto meno ogni uno. Ogni core è
occupato per circa il 5%, i core sono 8.
con:
$ mpv --no-config --vo=gpu --hwdec=vdpau 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].mp4'
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 1280x720 yuv420p
vengono creati 15-17 processi con il processo top che consuma circa il
40%, i seguenti processi consumano circa il 5% che poi scendono andando
giù verso il 15-17esimo processo.
Gli 8 core sono impegnati per circa il 10% ogni uno.
Senza video i core sono in media circa il 2-3% occupati per via che ho
attivo TB, FF, Dolphin e Term.
Non male secondo me, la differenza è notevole. Non riesco a fare la
somma dell'occupazione di CPU sommando tutti i processi mpv. Questo per
avere un numero complessivo e non tanti processi mpv con numeri diversi
(senza accelerazione grafica).
Con VLC e lo stesso video ho circa questi processi vlc:
9%-3%-2%-1%-0.6%-0.6%-0.6%
numeri che ovviamente oscillano.
> 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.
avevo sentito dire che i driver open source di AMD funzionavano
abbastanza bene e meglio di quelli nvidia (Nouveau).
> - 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?
più CPU nel caso di VLC: 9 Vs 7%. Ma tutto sommato ci sta, la differenza
è minima. mpv è un processo emplice mentre vlc potrebbe consumare più
risorse perché è un programma più complesso.
> 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.
(ULTRA HD) [LXb3EKWsInQ].mp4'
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/vdpau] Warning: this compatibility VO is low quality and may have
issues with OSD, scaling, screenshots and more.
[vo/vdpau] vo=gpu is the preferred choice in any case and includes VDPAU
support via hwdec=vdpau or vdpau-copy.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [vdpau] 1280x720 yuv420p
[vo/vdpau] Compositing window manager detected. Assuming timing info is
inaccurate.
AV: 00:00:09 / 00:05:13 (3%) A-V: 0.000
Exiting... (Quit)
Se ne è accorto... Comunque il video si vede lo stesso.
> 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.
scartando solo il vp9 se è troppo recente?
> 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.
Invece mi è arrivato aggi l'aggiornamento di Mesa per cui devo rifare la
compilazione se voglio aggiornare Mageia 9.
> 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.
sperare di non fare danni?
Joe
May 26, 2023, 7:05:47 PM5/26/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 26/05/23 10:53, Joe wrote:
>
>> 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.
>
> con htop mi mostra un sacco di processi mpv con PID differenti, quando
> chiudo la finestra di mpv spariscono tutti.
No, ma lascia perdere così ti complichi la vita...
> On 26/05/23 10:53, Joe wrote:
>
>> 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.
>
> con htop mi mostra un sacco di processi mpv con PID differenti, quando
> chiudo la finestra di mpv spariscono tutti.
Guarda il carico cpu totale "usr" in top in alto a sinistra:
Ad esempio così praticamente in idle (in realtà ho aperta
qualche pagina di youtube, ma senza video in riproduzione
ovvio):
%Cpu(s): 0,3 us
Poi provo a far girare MPV senza decodifica hardware su un
video h264 in 1080p:
%Cpu(s): 16,8 us
Quindi riprovo sempre MPV sempre stesso video ma con decodifica
hardware attiva, lasci anche girare un attimo in modo che s'assesti,
è chiaro che se muovi finestre o simili la cpu lavor adi più:
%Cpu(s): 1,6 us
La differenza è ben visibile, senza andarsi a complicare la vita
col capello spezzato in 4... non è necessario. Come si vede
nell'esempio la CPU lavora ad un decimo del carico attivando la
decodifica hardware. Non è sempre così dipende dai video, e conta
anche il FPS, nell'esempio era a 25fps. Abbastanza basso quindi,
ma ci sono video che la mia GPU non riesce neanche a tenerli in
sincro audio-video, per esempio quello con fps superiore a 55fps
o giù di lì. In quel caso per vederli correttamente devo disattivare
la decodifica hardware e lasciare il lavoro alla CPU che a quanto
pare è un po' più prestante. Ricordo che parlo di una GT210 da
30 euro e un processore Core 2 Quad Q9450 da 2.66 GHz.
>> 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.
>
> Quindi a me va meglio che da te mi pare di capire. Tu hai solo vdpau. Io
> avevo sentito dire che i driver open source di AMD funzionavano
> abbastanza bene e meglio di quelli nvidia (Nouveau).
>
>> - 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?
>
> Provando htop con vlc e mpv sullo stesso video il processo top consuma
> più CPU nel caso di VLC: 9 Vs 7%. Ma tutto sommato ci sta, la differenza
> è minima. mpv è un processo emplice mentre vlc potrebbe consumare più
> risorse perché è un programma più complesso.
mouse o se apri o chiudi una finestra.
VLC lo puoi lanciare come mpv, il comando è "cvlc" sta per cli vlc,
command line interface vlc forse... o similare.
leggendo in giro e non passerebbe da mesa, dovrebbe già essere
disponibilie "out of box". In realtà dalle tue prove non sembra tutto
così "spontaneo" e potrebbe essere che configurando qualcosa o
installando qualche altro pacchetto si riesca sfruttare la decodifica
hardware anche per vp8.
Le libvpx ti risultano installate giusto?
> Non chiedere a me. Tutta questa partita è nuova per me e mai affrontata.
> Invece mi è arrivato aggi l'aggiornamento di Mesa per cui devo rifare la
> compilazione se voglio aggiornare Mageia 9.
caso il pacchetto standard va più che bene. ;)
> Potrei nella prossima compilazione di mesa src mettere a casaccio vp8 e
> sperare di non fare danni?
sicuramente, comunque il PC non dovrebbe esplodere :D
Sandro kensan
May 27, 2023, 8:27:22 AM5/27/23
to
On 27/05/23 01:05, Joe wrote:
> No, ma lascia perdere così ti complichi la vita...
> Guarda il carico cpu totale "usr" in top in alto a sinistra:
https://www.kensan.it/tmp/Screenshot_20230527_021803.png
> No, ma lascia perdere così ti complichi la vita...
> Guarda il carico cpu totale "usr" in top in alto a sinistra:
non ho capito, mi indicheresti precisamente cosa devo controllare?
> Da 9 a 7 la differenza può essere dovuta anche solo al movimento del
> mouse o se apri o chiudi una finestra.
> VLC lo puoi lanciare come mpv, il comando è "cvlc" sta per cli vlc,
> command line interface vlc forse... o similare.
> No, mi sa tanto che vp8 è Open al contrario di h264 e h265, almeno
> leggendo in giro e non passerebbe da mesa, dovrebbe già essere
> disponibilie "out of box". In realtà dalle tue prove non sembra tutto
> così "spontaneo" e potrebbe essere che configurando qualcosa o
> installando qualche altro pacchetto si riesca sfruttare la decodifica
> hardware anche per vp8.
>
> Le libvpx ti risultano installate giusto?
$ urpmq --fuzzy vpx
> leggendo in giro e non passerebbe da mesa, dovrebbe già essere
> disponibilie "out of box". In realtà dalle tue prove non sembra tutto
> così "spontaneo" e potrebbe essere che configurando qualcosa o
> installando qualche altro pacchetto si riesca sfruttare la decodifica
> hardware anche per vp8.
>
> Le libvpx ti risultano installate giusto?
lib64vpx-devel
lib64vpx7
libvpx-utils
installato è solo libvpx7. Ho provato a installare libvpx-utils ma non è
cambiata la situazione:
$ mpv --no-config --vo=gpu --hwdec=auto 'V208 WEBM - VP8 1080p 24fps
8bit - VORBIS2.0.webm'
(+) Video --vid=1 (*) (vp8 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz)
[ffmpeg/video] vp8: No support for codec vp8 profile -99.
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:27 / 00:00:31 (87%) A-V: 0.000
VO: [gpu] 1920x1080 yuv420p
$ mpv --no-config --vo=gpu --hwdec=vdpau 'V208 WEBM - VP8 1080p 24fps
8bit - VORBIS2.0.webm'
(+) Video --vid=1 (*) (vp8 1920x1080 24.000fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz)
(+) 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:28 / 00:00:31 (90%) A-V: 0.000
VO: [gpu] 1920x1080 yuv420p
Questa la descrizione del pacchetto:
libvpx-utils - VP8 utilities and tools
A selection of utilities and tools for VP8, including a sample encoder
and decoder.
Non c'entra con il decoder penso.
> Sempre che non vuoi rinunciare alla funzionalità in questione. In quel
> caso il pacchetto standard va più che bene. ;)
gli aggiornamenti di mesa saranno molto pochi.
>> Potrei nella prossima compilazione di mesa src mettere a casaccio vp8 e
>> sperare di non fare danni?
>
> Direi proprio di no... prova anche ma ti darà qualche errore
> sicuramente, comunque il PC non dovrebbe esplodere :D
tutto inutile metterlo li dentro, mi ero distratto.
Joe
May 27, 2023, 10:53:40 AM5/27/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 27/05/23 01:05, Joe wrote:
>
>> No, ma lascia perdere così ti complichi la vita...
>> Guarda il carico cpu totale "usr" in top in alto a sinistra:
>
> https://www.kensan.it/tmp/Screenshot_20230527_021803.png
>
> non ho capito, mi indicheresti precisamente cosa devo controllare?
top, non htop...
> On 27/05/23 01:05, Joe wrote:
>
>> No, ma lascia perdere così ti complichi la vita...
>> Guarda il carico cpu totale "usr" in top in alto a sinistra:
>
> https://www.kensan.it/tmp/Screenshot_20230527_021803.png
>
> non ho capito, mi indicheresti precisamente cosa devo controllare?
-----------------------------------------------------------------
top - 16:08:50 up 5:54, 1 user, load average: 0,22, 0,44, 0,55
Tasks: 191 total, 1 running, 190 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,8 us, 0,2 sy, 0,0 ni, 98,9 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
[...]
-----
Puoi fare anche così ad esempio:
-------------------------------------
$ top -sn3 |grep ^%Cpu|cut -f1-4 -d\,
%Cpu(s): 4,5 us, 3,0 sy
%Cpu(s): 2,9 us, 0,8 sy
%Cpu(s): 1,2 us, 0,3 sy
-------------------------
Puoi impostare "-n" piacere, lì ho messo 3, ma puoi mettere 10
e poi fai la media... in ogni caso non è preciso comunque credo.
In htop ci sarà bene il modo ma così al volo non so dirti, c'è
sempre il man. :D
Io uso slstatus, ma fa parte dell'ambiente "dwm"/suckless, e nella
barra di stato che si piazza in alto mi mostra vari monitor, cpu
memoria, rete, spazio disco, orario ecc... niente di ché ma è comodo.
In ogni caso "top" come mostrato sopra è sufficiente.
> Però hai ragione VP8 non è sotto brevetto come h.264/5 e quindi è del
> tutto inutile metterlo li dentro, mi ero distratto.
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...
Sandro kensan
May 28, 2023, 9:45:23 PM5/28/23
to
On 27/05/23 16:53, Joe wrote:
> top, non htop...
ah ecco dove sbagliavo.
> -----------------------------------------------------------------
> top - 16:08:50 up 5:54, 1 user, load average: 0,22, 0,44, 0,55
> Tasks: 191 total, 1 running, 190 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 0,8 us, 0,2 sy, 0,0 ni, 98,9 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
> [...]
> -----
>
> Puoi fare anche così ad esempio:
> -------------------------------------
> $ top -sn3 |grep ^%Cpu|cut -f1-4 -d\,
> %Cpu(s): 4,5 us, 3,0 sy
> %Cpu(s): 2,9 us, 0,8 sy
> %Cpu(s): 1,2 us, 0,3 sy
> -------------------------
>
> Puoi impostare "-n" piacere, lì ho messo 3, ma puoi mettere 10
> e poi fai la media... in ogni caso non è preciso comunque credo.
ma allora è lo stesso di conky che ha l'opzione di mettere nel desktop
la CPU usage (un numero intero percentuale) che viene aggiornato ogni
secondo (nel mio caso): posso usare quello che tra l'altro è il dato che
ti ho fornito per valutare quanta risorsa del processore usavano i vari mpv?
> In htop ci sarà bene il modo ma così al volo non so dirti, c'è
> sempre il man. :D
> Io uso slstatus, ma fa parte dell'ambiente "dwm"/suckless, e nella
> barra di stato che si piazza in alto mi mostra vari monitor, cpu
> memoria, rete, spazio disco, orario ecc... niente di ché ma è comodo.
> In ogni caso "top" come mostrato sopra è sufficiente.
forse conky è più immediato ed è molto configurabile e programmabile.
>> Però hai ragione VP8 non è sotto brevetto come h.264/5 e quindi è del
>> 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...
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.
> top, non htop...
ah ecco dove sbagliavo.
> -----------------------------------------------------------------
> top - 16:08:50 up 5:54, 1 user, load average: 0,22, 0,44, 0,55
> Tasks: 191 total, 1 running, 190 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 0,8 us, 0,2 sy, 0,0 ni, 98,9 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
> [...]
> -----
>
> Puoi fare anche così ad esempio:
> -------------------------------------
> $ top -sn3 |grep ^%Cpu|cut -f1-4 -d\,
> %Cpu(s): 4,5 us, 3,0 sy
> %Cpu(s): 2,9 us, 0,8 sy
> %Cpu(s): 1,2 us, 0,3 sy
> -------------------------
>
> Puoi impostare "-n" piacere, lì ho messo 3, ma puoi mettere 10
> e poi fai la media... in ogni caso non è preciso comunque credo.
la CPU usage (un numero intero percentuale) che viene aggiornato ogni
secondo (nel mio caso): posso usare quello che tra l'altro è il dato che
ti ho fornito per valutare quanta risorsa del processore usavano i vari mpv?
> In htop ci sarà bene il modo ma così al volo non so dirti, c'è
> sempre il man. :D
> Io uso slstatus, ma fa parte dell'ambiente "dwm"/suckless, e nella
> barra di stato che si piazza in alto mi mostra vari monitor, cpu
> memoria, rete, spazio disco, orario ecc... niente di ché ma è comodo.
> In ogni caso "top" come mostrato sopra è sufficiente.
>> Però hai ragione VP8 non è sotto brevetto come h.264/5 e quindi è del
>> 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...
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.
Joe
May 29, 2023, 5:45:09 AM5/29/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> forse conky è più immediato ed è molto configurabile e programmabile.
Per valutare l'impiego della CPU e quello della GPU puoi usare quello
>
> forse conky è più immediato ed è molto configurabile e programmabile.
che ti sembra meglio, la cosa importante è che tu abbia una panoramica
della situazione senza perderti in informazioni ultradettagliate che
poi cambiano comunque ogni mezzo secondo. Qui per lo scopo serve
avere un totale dell'impiego CPU semplicemnte per determinare il buon
coinvolgimento della scheda video nella decodifica, da top o da conky
o quel che ti pare, va sempre bene, basta poter vedere un numero solo
che dà un'indicazione anche approssimativa del carico durante la
riproduzione video.
Se rilevi ad occhio che usando MPV il carico si porta intorno al 5%,
mentre con VLC sta sempre intorno al 10%, è segno che VLC sta usando
qualcosa di meno efficiente... Se invece noti una forbice minima, tipo
VLC al 5% e MPV al 6%, allora facilmente la minima differenza può essere
imputabile anche ad altro (magari MPV consuma più risorse di suo
rispetto a VLC o viceversa...) senza necesariamente dipendere
dall'operazione di decodifica hardware.
>> 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...
>
> 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.
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.
Sandro kensan
May 29, 2023, 10:19:46 PM5/29/23
to
On 29/05/23 11:42, Joe wrote:
> Se rilevi ad occhio che usando MPV il carico si porta intorno al 5%,
> mentre con VLC sta sempre intorno al 10%, è segno che VLC sta usando
> qualcosa di meno efficiente... Se invece noti una forbice minima, tipo
> VLC al 5% e MPV al 6%, allora facilmente la minima differenza può essere
> imputabile anche ad altro (magari MPV consuma più risorse di suo
> rispetto a VLC o viceversa...) senza necesariamente dipendere
> dall'operazione di decodifica hardware.
Allora cvlc è fisso al 4% di uso della CPU:
> Se rilevi ad occhio che usando MPV il carico si porta intorno al 5%,
> mentre con VLC sta sempre intorno al 10%, è segno che VLC sta usando
> qualcosa di meno efficiente... Se invece noti una forbice minima, tipo
> VLC al 5% e MPV al 6%, allora facilmente la minima differenza può essere
> imputabile anche ad altro (magari MPV consuma più risorse di suo
> rispetto a VLC o viceversa...) senza necesariamente dipendere
> dall'operazione di decodifica hardware.
===========================================
$ cvlc 'COSTA RICA IN 4K 60fps HDR (ULTRA HD) [LXb3EKWsInQ].mp4'
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000000000dae9b0] dummy interface: using the dummy interface module...
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
[00007f0a38c86c80] avcodec decoder: Using G3DVL VDPAU Driver Shared
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
Library version 1.0 for hardware decoding <==========
mpv balla tra il 3% e il 4%:
============================
$ mpv --no-config --vo=gpu --hwdec=auto 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].mp4'
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi). <==========================
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:01:16 / 00:05:13 (24%) A-V: 0.000
VO: [gpu] 1280x720 vaapi[nv12]
Invece usando vdpau in mpv e quindi senza l'accelerazione hw ho il
processore al 7% - 8%:
============================
$ mpv --no-config --vo=gpu --hwdec=vdpau 'COSTA RICA IN 4K 60fps HDR
(ULTRA HD) [LXb3EKWsInQ].mp4'
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
(+) Video --vid=1 (*) (h264 1280x720 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[ao/pipewire] Could not connect to context '(null)': Host is down
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 1280x720 yuv420p
AV: 00:01:17 / 00:05:13 (25%) A-V: 0.000
senza eseguire nulla eccetto i programmi che ho sempre aperto la CPU è
fissa al 2%.
> Bene, hai ragione, scrivere in rete torna utilissimo dopo tot tempo,
> si ritrova un sacco di informazioni quando si deve nuovamente affrontare
> fuori in passato.
infatti... e con la mia memoria molto scarsa è una manna dal cielo.
> 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.
altri riguardo VP8/9.
> 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.
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.
Joe
May 30, 2023, 10:13:55 AM5/30/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
>> 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.
>
> 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.
Più che affermare, immaginavo che fosse incluso tra le funzionalità
>
>> 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.
>
> 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.
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.
Sandro kensan
May 31, 2023, 8:16:05 AM5/31/23
to
On 30/05/23 16:13, Joe wrote:
> 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,
L'ho già scritto ma io ho dovuto contattare la Sapphire per capire che
> 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,
modello è la mia scheda:
https://www.sapphiretech.com/en/search-result?q=rx550
sul loro sito non è riportata, loro mi hanno dato una descrizione molto
sintetica della mia scheda, io speravo mi mandassero un pdf dettagliato
ma così non è stato, io non ho insistito.
SKU# 11268-13 (numero del prodotto interno alla azienda
Sapphire, ndR)
Product Description SAPPHIRE PULSE RADEON RX 550 4G GDDR5 HDMI / DVI-D
/ DP (UEFI, 6.0GBPS) 白金版
白金版 Edizione Platinum (traduzione, ndR)
P/N xxx-xxxx-xxxx
PN
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
Quindi non è facile capire cosa hai in mano nemmeno chiedendo e
ricevendo risposta dal produttore della scheda video.
> 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.
Immaginavo che non potessi usarla per YT, mi ero ormai rassegnato,
invece ho scaricato l'estensione e ho fatto una prova a pieno schermo a
1080p, il processore non è andato oltre i 56°C quando la temperatura
della stanza è di 23°C. La CPU è stata intorno al 20%. Farò altre prove:
Il video è questo:
https://www.youtube.com/watch?v=MnY_yOka9wA
Notevole, io avrei proseguito a vedere i video con la ventola che gira
al massimo e d'estate è un problema quando la temperatura sale. Con la
tua informazione mi sa che ho centrato l'obiettivo di comprare una
scheda video per non avere la ventola che frulla al massimo dei giri:
grazie!
> 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.
librecad raramente, libre office più spesso.
Invece YT spesso e quindi il problema era li.
> 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)...
che fosse possibile una gestione così accurata del formato di video da
scaricare. Però mi potrebbe essere utile per i video musicali o anche
semplicemente per scaricare la musica da YT anche se penso che il
bitrate sia molto basso, niente che si avvicini a un Flac.
> 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.
non credo che in KDE possa stabilire la posizione delle finestre che si
aprono ma KDE è talmente configurabile che ci sarà un modo più o meno
semplice.
>
> 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.
Io per adesso uso il browser e in futuro quando noterò che il mio PC
> 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.
perde colpi riciclo la RX550, mi prendo un Ryzen, una scheda madre
economica, un po' di RAM (8GB o 16 GB), riciclo il mio Alimentatore da
350 watt (che è piccolo ma non mi ha dato instabilità) e mi faccio il PC
nuovo.
> 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.
un problema.
Grazie!
Joe
May 31, 2023, 10:09:55 AM5/31/23
to
Sandro kensan <ken...@kensan.it> wrote:
>
> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
> che fosse possibile una gestione così accurata del formato di video da
> scaricare.
Molto di più... ad esempio, siccome la mia scheda fa fatica con
>
> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
> che fosse possibile una gestione così accurata del formato di video da
> scaricare.
i video a 60 fps, posso istruirlo affinché cerchi il formato
disponibile con fps inferiore ad esempio a 50 fps, codifica h264
e risoluzione verticale maggiore possibile... tipicamente salta
fuori un 720p h264 30fps o giù di lì, che la mia GPU digerisce
benissimo.
Questo parlando di uso al volo di youtube.. se poi ti interessa
un video e lo vuoi vedere con calma puoi sempre scaricare il
formato più grosso e poi convertirlo con ffmpeg producendo un
nuovo video codificato come vuoi tu ecc ecc... ma è un altro
discorso.
> Però mi potrebbe essere utile per i video musicali o anche
> semplicemente per scaricare la musica da YT anche se penso che il
> bitrate sia molto basso, niente che si avvicini a un Flac.
qualità audio e poi ascolti su un auricolare da pochi spicci, ha
poco senso anche quello...
Per scaricare con yt-dlp, ti avevo già accennato mi sembra, usi il
flag -F per vedere i formati disponibili e poi il flag -f per scegliere
quello che vuoi scaricare. Ma in quel caso lo usi in modalità autonoma
senza MPV...
>> 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.
>
> Ho capito come fai. Con KDE posso associare a dei tasti un comando, poi
> non credo che in KDE possa stabilire la posizione delle finestre che si
> aprono ma KDE è talmente configurabile che ci sarà un modo più o meno
> semplice.
browser, lo ridimensioni un po', poi apri 3 o 4 finestre di MPV anche
loro ridotte in modo da vedere un po' tutto e via.
La comodità vera è che buttando i video in mpv poi, almeno sul mio
sistema con la mia scheda ecc, le risorse CPU impiegate sono veramente
ridotte da consentirmi di navigare, ricercare ecc nel browser mentre
il video in riproduzione viaggia senza intralciare il processore.
Invece riproducendo dal browser anche con il plugin per h264, il carico
è senz'altro più alto... a dirla tutta non ricordo se avessi impostato
bene firefox in modo da abilitare la decodifica via gpu. Con mpv sono
sicuro che lavora la cheda video, è davvero evidente... con un PC come
il mio ci se n'accorge subito.
> Io per adesso uso il browser e in futuro quando noterò che il mio PC
> perde colpi riciclo la RX550, mi prendo un Ryzen, una scheda madre
> economica, un po' di RAM (8GB o 16 GB), riciclo il mio Alimentatore da
> 350 watt (che è piccolo ma non mi ha dato instabilità) e mi faccio il PC
> nuovo.
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.
Sandro kensan
May 31, 2023, 8:02:49 PM5/31/23
to
On 31/05/23 16:09, Joe wrote:
> Sandro kensan <ken...@kensan.it> wrote:
>>
>> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
>> che fosse possibile una gestione così accurata del formato di video da
>> scaricare.
>
> Molto di più... ad esempio, siccome la mia scheda fa fatica con
> i video a 60 fps, posso istruirlo affinché cerchi il formato
> disponibile con fps inferiore ad esempio a 50 fps, codifica h264
> e risoluzione verticale maggiore possibile... tipicamente salta
> fuori un 720p h264 30fps o giù di lì, che la mia GPU digerisce
> benissimo.
ho visto dal file conf gli fps inferiori a 50. Io potrei settarli a 60
> Sandro kensan <ken...@kensan.it> wrote:
>>
>> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
>> che fosse possibile una gestione così accurata del formato di video da
>> scaricare.
>
> Molto di più... ad esempio, siccome la mia scheda fa fatica con
> i video a 60 fps, posso istruirlo affinché cerchi il formato
> disponibile con fps inferiore ad esempio a 50 fps, codifica h264
> e risoluzione verticale maggiore possibile... tipicamente salta
> fuori un 720p h264 30fps o giù di lì, che la mia GPU digerisce
> benissimo.
immagino.
> Questo parlando di uso al volo di youtube.. se poi ti interessa
> un video e lo vuoi vedere con calma puoi sempre scaricare il
> formato più grosso e poi convertirlo con ffmpeg producendo un
> nuovo video codificato come vuoi tu ecc ecc... ma è un altro
> discorso.
con un sito esterno. Pensavo non si potesse più fare.
> Per scaricare con yt-dlp, ti avevo già accennato mi sembra, usi il
> flag -F per vedere i formati disponibili e poi il flag -f per scegliere
> quello che vuoi scaricare. Ma in quel caso lo usi in modalità autonoma
> senza MPV...
Ho visto che le varie estensioni che ci sono riguardo l'h264 non
funzionano bene e non danno il risultato voluto.
Quindi sto indagando il tuo metodo che penso di applicare di tanto in tanto.
Mi viene in mente un particolare: la .cache si cancella di tanto in
tanto o devo cancellarla manualmente quando raggiungerà dimensioni
troppo grandi? Non conviene metterla su /tmp che si resetta ad ogni riavvio?
> Sì va be' per una situazione così "statica" se usi kde ti apri il
> browser, lo ridimensioni un po', poi apri 3 o 4 finestre di MPV anche
> loro ridotte in modo da vedere un po' tutto e via.
aperta dove incollo il link di yt. Sempre con il tuo file mpv.conf
> La comodità vera è che buttando i video in mpv poi, almeno sul mio
> sistema con la mia scheda ecc, le risorse CPU impiegate sono veramente
> ridotte da consentirmi di navigare, ricercare ecc nel browser mentre
> il video in riproduzione viaggia senza intralciare il processore.
> Invece riproducendo dal browser anche con il plugin per h264, il carico
> è senz'altro più alto... a dirla tutta non ricordo se avessi impostato
> bene firefox in modo da abilitare la decodifica via gpu. Con mpv sono
> sicuro che lavora la cheda video, è davvero evidente... con un PC come
> il mio ci se n'accorge subito.
provati tutti ma sono solo fork.
> 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
> --------------------------------------
https://www.youtube.com/watch?v=vw6_OajILRE
e in questo:
https://www.youtube.com/watch?v=5RvBOZ5Hi30
Risolto, il max volume è 1000, l'ho posto a 100 e mi pare ok. Strano che
non possa cambiare il volume dalla finestra di mpv.
> È 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.
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.
Joe
Jun 1, 2023, 8:53:13 AM6/1/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 31/05/23 16:09, Joe wrote:
>> Sandro kensan <ken...@kensan.it> wrote:
>>>
>>> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
>>> che fosse possibile una gestione così accurata del formato di video da
>>> scaricare.
>>
>> Molto di più... ad esempio, siccome la mia scheda fa fatica con
>> i video a 60 fps, posso istruirlo affinché cerchi il formato
>> disponibile con fps inferiore ad esempio a 50 fps, codifica h264
>> e risoluzione verticale maggiore possibile... tipicamente salta
>> fuori un 720p h264 30fps o giù di lì, che la mia GPU digerisce
>> benissimo.
>
> ho visto dal file conf gli fps inferiori a 50. Io potrei settarli a 60
> immagino.
Sì, ma quella riga lì prendila solo come esempio, perché in realtà
> On 31/05/23 16:09, Joe wrote:
>> Sandro kensan <ken...@kensan.it> wrote:
>>>
>>> ecco perché conosci bene yt-dlp che non avevo mai visto e non sospettavo
>>> che fosse possibile una gestione così accurata del formato di video da
>>> scaricare.
>>
>> Molto di più... ad esempio, siccome la mia scheda fa fatica con
>> i video a 60 fps, posso istruirlo affinché cerchi il formato
>> disponibile con fps inferiore ad esempio a 50 fps, codifica h264
>> e risoluzione verticale maggiore possibile... tipicamente salta
>> fuori un 720p h264 30fps o giù di lì, che la mia GPU digerisce
>> benissimo.
>
> ho visto dal file conf gli fps inferiori a 50. Io potrei settarli a 60
> immagino.
prima di andare a valutare l'fps, l'avevo modificata e mi sceglie
prioritariamente il formato "legacy" non dash, con audio e video già
mixati, il codice sarebbe "22" e si tratta di mp4 720p con video in
h264 e audio AAC a 192 kbps. Il "95" è per gli stream live..
Avevo messo in priorità quelli lì perché ho notato che sono più rapidi
nell'aprirsi e scariscarsi, e faccio prima a visionare rapidamente
il contenuto dei video mentre sto cercando qualcosa...
Per i formati vedi qua:
https://gist.github.com/AgentOak/34d47c65b1d28829bb17c24c04a0096f
ma non fidarti del template di youtube-dl, per yt-dlp la sintassi
dovrebbe essere un po' diversa, ti rimando a cercartela nel dettaglio.
Comunque sì, adatta la tua direttiva alle possibilità della tua scheda,
per faer qualche test e vedere cosa regge, quanta cpu impiega ecc, puoi
usare uno dei tanti video di test AV sync, tipo ad esempio:
yt-dlp -F https://www.youtube.com/watch?v=jRA1HBZhJ18
298 mp4 1280x720 60 │ 147.10MiB 686k dash │ avc1.640020 686k video only 720p60, mp4_dash
302 webm 1280x720 60 │ 128.71MiB 600k dash │ vp9 600k video only 720p60, webm_dash
299 mp4 1920x1080 60 │ 261.96MiB 1221k dash │ avc1.64002a 1221k video only 1080p60, mp4_dash
303 webm 1920x1080 60 │ 250.22MiB 1166k dash │ vp9 1166k video only 1080p60, webm_dash
Imposti la configurazione in modo che ti scelga il 299 che dovrebbe
decodificarlo via GPU, e l'audio scegli tu, prendi il migliore, per
quel video lì è il 140. Configurato così mpv, ci trascini dentro il
link e vedi... se sta in sincro molto bene (dovrebbe farcela, è la
mia scheda che è troppo economica ormai), nota anche il consumo cpu,
gpu (radeontop era se ben ricordo) e valuta anche se la banda della
connessione internet che hai è adeguata.
Poi puoi fare la prova scegliendo il vp9, che invece dovrebbe caricare
tutto in spalla al processore, e lì dovresti vedere una bella differenza
anche da radeontop.
Configurazione a parte, ho anche uno script di mpv associato alla
scorciatoia Ctrl-f da cui posso scegliere il formato durante la
riproduzione del video, baypassando la configurazione di mpv quindi.
youtube-quality.lua
https://github.com/jgreco/mpv-youtube-quality
Con questo puoi fare delle prove al volo, forse è più comodo,
una volta trovato il formato che gira meglio lo imposti in
mpv.conf...
Come ho già scritto io ho scelto una config con priorità alla
rapidità di apertura ecc... poi se un video mi interessa vederlo
in qualità migliore, faccio ctrl-f e scelgo l'h264 a 1080p se non
è a più di 50 fps, se c'è solo a 60fps, a volte "spengo" la
decodifica hardware della GPU commentando la riga hwdec di mpv.conf,
così decodifica via software e anche se la CPU sale anche sopra
il 50% pazienza, perlomeno non mi dà problemi di fuori sincro.
Per farlo ho un minimo script bash:
-----------
#!/bin/bash
CONFIG=~/.config/mpv/mpv.conf
case $1 in
on)
sed -i "s/#hwdec=auto/hwdec=auto/" $CONFIG
sed -i "s/#vo=gpu/vo=gpu/" $CONFIG
;;
off)
sed -i "s/hwdec=auto/#hwdec=auto/" $CONFIG
sed -i "s/vo=gpu/#vo=gpu/" $CONFIG
;;
*)
echo "Err - invalid argument"
echo
echo "Usage: $(basename $0) on | off"
;;
esac
----
Non è comunque comodissimo perché la finestra già aperta di MPV
mantiene la vecchia configurazione... quindi devo chiuderla e
poi do:
gpudec off
win+v ---> per aprire una nuova finestra di mpv
quindi trascino nuovamente il link dentro
e infine ctrl+f per scegliere il formato di qualità
È una manovra che faccio molto di rado...
>> Questo parlando di uso al volo di youtube.. se poi ti interessa
>> un video e lo vuoi vedere con calma puoi sempre scaricare il
>> formato più grosso e poi convertirlo con ffmpeg producendo un
>> nuovo video codificato come vuoi tu ecc ecc... ma è un altro
>> discorso.
>
> Questa è una possibilità. Una volta lo facevo con una estensione poi
> con un sito esterno. Pensavo non si potesse più fare.
Con ffmpeg converti quello che vuoi basta avere i codec installati.
> Mi viene in mente un particolare: la .cache si cancella di tanto in
> tanto o devo cancellarla manualmente quando raggiungerà dimensioni
> troppo grandi? Non conviene metterla su /tmp che si resetta ad ogni riavvio?
provare per credere...
> Ho fato alcune prove oggi e a me pare che l'addon non funzioni. li ho
> provati tutti ma sono solo fork.
- apri il tubo dal browser
- play sul video
- click destro sul video e scegli "stats for nerds"
- controlla la riga "Codecs"
Esempio per un video a caso:
------------------------------
avc1.640028 (137) / opus (251)
------------------------------
Se faccio la prova del nove con "yt-dlp -F" trovo proprio
che "137" significa:
--------------------
137 mp4 1920x1080 30 │ 684.63MiB 428k dash │ avc1.640028 428k video only 1080p, mp4_dash
--------------------------------------------------
mentre l'audio:
--------------------
251 webm audio only 2 │ 145.82MiB 91k dash │ audio only opus 91k 48k medium, webm_dash
--------------------------------------------------
Se disabilito un attimo l'estensione "enhanched-h264ify" e
aggiorno la pagina dello stesso video, ecco che youtube mi
serve un altro formato video (per l'audio sceglie sempre lo
stesso di prima):
---------------------------------------
Codecs av01.0.08M.08 (399) / opus (251)
---------------------------------------
È addirittura un AV1, che al momento credo poche schede video
riescano a decodificare via hardware. Per la cronaca, così il
mio processore segna 97% di carico (ricordo che è un vecchio
core2quad, era prevedibile ovviamente). Insomma meglio ri-abilitare
l'estensione che forza h264... anche se... la CPU presenta un carico
dal 20 al 40%, lasciandolo girare si abbassa un po' e si assesta
intorno al 20% (probabilmente perché la pagina youtube macina
anche altra roba appena ricaricata, carica i commenti, suggerimenti
ecc ecc...).
Io non ho modo di vedere il carico della GPU, ho nvidia-msi ma
la mia scheda è talmente scaccia che non viene considerata...
Se poi fermo il video, la cpu va a 1% 0, 2% giù di lì...
Apro mpv con hwdec attivo e ci trascino il link dello stesso video:
- shift + I per vedere le info e leggo
- video h264
- hwdec VDPAU
- native resolution 1280x720
Perché l'impostazione di mpv sceglie il formato "22" appunto 720 ecc,
quindi per fare il paragone con la riproduzione precedente in cui
serviva il 1080p h264:
- faccio ctrl-f e scelgo il formato uguale a prima con codec avc1.640028
- avvio la riproduzione
- leggo sempre con ctrl+I: H264, hwdec VDPAU e risoluzione sta volta a 1920x1080
Ed ecco che la CPU ora non sale mai oltre il 2-3%.
Se scelgo allo stesso modo in mpv il VP9: non leggo più VDPAU dalle info,
e cpu al 15-20% (pensavo peggio)
Scegliendo AV1: si legge "libdav1d" quindi niente VDPAU ovviamente e la
cpu sta sul 35-40%. La libreria libdav1 serviva proprio per il decoding
degli AV1 ovviamente via software, ricordo che l'avevo messa tempo fa.
In sintesi, da firefox anche con h264 forzato, fa abbastanza peggio di
mpv.
>> ~/.config/mpv/mpv.conf
>>
>> --------------------------------
>> volume=10
>> --------------------------------------
>
> Il mio problema è che non ho l'audio su questo video:
>
> https://www.youtube.com/watch?v=vw6_OajILRE
>
> e in questo:
>
> https://www.youtube.com/watch?v=5RvBOZ5Hi30
>
> Risolto, il max volume è 1000, l'ho posto a 100 e mi pare ok. Strano che
> non possa cambiare il volume dalla finestra di mpv.
Sì che puoi! Tasti 9 per meno e 0 per più volume... ma una ricerca falla
>
> Il mio problema è che non ho l'audio su questo video:
>
> https://www.youtube.com/watch?v=vw6_OajILRE
>
> e in questo:
>
> https://www.youtube.com/watch?v=5RvBOZ5Hi30
>
> Risolto, il max volume è 1000, l'ho posto a 100 e mi pare ok. Strano che
> non possa cambiare il volume dalla finestra di mpv.
però, che ste cose sono l'utilizzo base base base. Nella mia impostazione
il volume di default è 10, puoi settarlo come preferisci, "volume=100"
dovrebbe darti il massimo disponibile dal sistema. Se fosse ancora basso
devi alzarlo a livello di sistema, da pulse o alsa o quel che hai su mageia.
> 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.
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.
Sandro kensan
Jun 2, 2023, 12:40:37 PM6/2/23
to
On 01/06/23 14:53, Joe wrote:
> Sì, ma quella riga lì prendila solo come esempio, perché in realtà
> prima di andare a valutare l'fps, l'avevo modificata e mi sceglie
> prioritariamente il formato "legacy" non dash, con audio e video già
> mixati, il codice sarebbe "22" e si tratta di mp4 720p con video in
> h264 e audio AAC a 192 kbps. Il "95" è per gli stream live..
> Avevo messo in priorità quelli lì perché ho notato che sono più rapidi
> nell'aprirsi e scariscarsi, e faccio prima a visionare rapidamente
> il contenuto dei video mentre sto cercando qualcosa...
Ho fatto una cosa semplicissima, ho copiato il tuo file di
> Sì, ma quella riga lì prendila solo come esempio, perché in realtà
> prima di andare a valutare l'fps, l'avevo modificata e mi sceglie
> prioritariamente il formato "legacy" non dash, con audio e video già
> mixati, il codice sarebbe "22" e si tratta di mp4 720p con video in
> h264 e audio AAC a 192 kbps. Il "95" è per gli stream live..
> Avevo messo in priorità quelli lì perché ho notato che sono più rapidi
> nell'aprirsi e scariscarsi, e faccio prima a visionare rapidamente
> il contenuto dei video mentre sto cercando qualcosa...
configurazione tale e quale, ho aggiungo solo il posizionamento e
funziona bene con il 720p che è buona sia per velocità che per consumo
di GB avendo solo 100 GB al mese.
In tal modo il processore sta al 5%.
tempo per configurare ulteriormente il mio sistema. Devo veder come mi
trovo. Per adesso mi pare che si possa fare ma la scomodità è che non ho
i sottotitoli generati automaticamente di YT in modo tale da leggere
l'inglese. Poi devo ad ogni video premere Shift+CTRL+m per aprire una
finestra di mpv. Devo vedere se mi trovo bene.
> Perché mai....
> Con ffmpeg converti quello che vuoi basta avere i codec installati.
rendere obbligatoria la pubblicità...
> Quando chiudi la finestrella di mpv se ne va anche la cache,
> provare per credere...
> Non ti può "parere", lo vedi precisamente:
> - apri il tubo dal browser
> - play sul video
> - click destro sul video e scegli "stats for nerds"
> - controlla la riga "Codecs"
>
> Esempio per un video a caso:
> ------------------------------
> avc1.640028 (137) / opus (251)
> ------------------------------
>
> Se faccio la prova del nove con "yt-dlp -F" trovo proprio
> che "137" significa:
> --------------------
> 137 mp4 1920x1080 30 │ 684.63MiB 428k dash │ avc1.640028 428k video only 1080p, mp4_dash
> --------------------------------------------------
>
> mentre l'audio:
> --------------------
> 251 webm audio only 2 │ 145.82MiB 91k dash │ audio only opus 91k 48k medium, webm_dash > --------------------------------------------------
Codecs:
------------------------------
avc1.640020 (298) / opus (251)
------------------------------
quindi effettivamente con l'estensione ho l'avc1 però il processore è
moltissimo impegnato come anche hai notato tu, oltre il 30%, mentre se
uso MPV con il tuo config e lo stesso video ho il processore al 5%
fisso. Con i video in pausa il processore è al 3%.
se è disponibile il formato e disabilito l'estensione in effetti mi
mostra VP09.
Codecs
vp09.00.51.08.01.01.01.01.00 (302) / opus (251)
> Se disabilito un attimo l'estensione "enhanched-h264ify" e
> aggiorno la pagina dello stesso video, ecco che youtube mi
> serve un altro formato video (per l'audio sceglie sempre lo
> stesso di prima):
> ---------------------------------------
> Codecs av01.0.08M.08 (399) / opus (251)
> ---------------------------------------
>
> È addirittura un AV1, che al momento credo poche schede video
> riescano a decodificare via hardware. Per la cronaca, così il
> mio processore segna 97% di carico (ricordo che è un vecchio
> core2quad, era prevedibile ovviamente). Insomma meglio ri-abilitare
> l'estensione che forza h264... anche se... la CPU presenta un carico
> dal 20 al 40%, lasciandolo girare si abbassa un po' e si assesta
> intorno al 20% (probabilmente perché la pagina youtube macina
> anche altra roba appena ricaricata, carica i commenti, suggerimenti
> ecc ecc...).
browser, la temperatura sale troppo. Magari per il processore non è un
problema ma non mi piace che oltre i 60 gradi la ventola cominci a frullare.
> Io non ho modo di vedere il carico della GPU, ho nvidia-msi ma
> la mia scheda è talmente scaccia che non viene considerata...
interpretarli, eccetto che quando va un video con mpv i grafici si
impennano in generale.
La cosa migliore sarebbe una scheda che supporti il VP9 ma poi se YT ti
consuma un sacco di risorse quando visualizzi i video allora non risolvi
nulla ed è meglio avere una scheda economica.
> Se poi fermo il video, la cpu va a 1% 0, 2% giù di lì...
> Apro mpv con hwdec attivo e ci trascino il link dello stesso video:
>
> - shift + I per vedere le info e leggo
> - video h264
> - hwdec VDPAU
> - native resolution 1280x720
> Perché l'impostazione di mpv sceglie il formato "22" appunto 720 ecc,
> quindi per fare il paragone con la riproduzione precedente in cui
> serviva il 1080p h264:
>
> - faccio ctrl-f e scelgo il formato uguale a prima con codec avc1.640028
> - avvio la riproduzione
> - leggo sempre con ctrl+I: H264, hwdec VDPAU e risoluzione sta volta a 1920x1080
>
> Ed ecco che la CPU ora non sale mai oltre il 2-3%.
> Se scelgo allo stesso modo in mpv il VP9: non leggo più VDPAU dalle info,
> e cpu al 15-20% (pensavo peggio)
>
> Scegliendo AV1: si legge "libdav1d" quindi niente VDPAU ovviamente e la
> cpu sta sul 35-40%. La libreria libdav1 serviva proprio per il decoding
> degli AV1 ovviamente via software, ricordo che l'avevo messa tempo fa.
>
> In sintesi, da firefox anche con h264 forzato, fa abbastanza peggio di
> mpv.
dedotto che l'estensione h264ify non funzionasse invece funziona ma
complessivamente fa abbastanza peggio di mpv.
Farò dei test per vedere la differenza percentuale tra Firefox che
visualizza video con e senza l'estensione di YT. Comunque è
insoddisfacente dal mio punto di vista.
> Sì che puoi! Tasti 9 per meno e 0 per più volume... ma una ricerca falla
> però, che ste cose sono l'utilizzo base base base.
https://github.com/mpv-player/mpv/blob/master/etc/input.conf
i tasti sono pure configurabili a piacere, basta mettere il file:
~/.config/mpv/input.conf
per il volume da me funziona "/" e "*".
#9 add volume -2
#/ add volume -2
#0 add volume 2
#* add volume 2
# Developer note:
# On compilation, this file is baked into the mpv binary, and all lines are
# uncommented (unless '#' is followed by a space) - thus this file
defines the
# default key bindings
Nella mia impostazione
> il volume di default è 10, puoi settarlo come preferisci, "volume=100"
> dovrebbe darti il massimo disponibile dal sistema.
> Se fosse ancora basso
> devi alzarlo a livello di sistema, da pulse o alsa o quel che hai su mageia.
> 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.
impostato --geometry=100%:100% in modo tale che la finestra mi appaia
nell'angolo in basso a destra. Si può impostare anche la grandezza della
finestra con un 100x100 sempre in geometry ma in tal caso la finestra
rimane fissa a quella risoluzione.
> 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.
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 ^_^
Joe
Jun 3, 2023, 6:27:21 AM6/3/23
to
Sandro kensan <ken...@kensan.it> wrote:
> On 01/06/23 14:53, Joe wrote:
>
>> Non è comunque comodissimo perché la finestra già aperta di MPV
>> mantiene la vecchia configurazione... quindi devo chiuderla e
>> poi do:
>>
>> gpudec off
>>
>> win+v ---> per aprire una nuova finestra di mpv
>>
>> quindi trascino nuovamente il link dentro
>>
>> e infine ctrl+f per scegliere il formato di qualità
>>
>>
>> È una manovra che faccio molto di rado...
>
> Manuale dettagliato però per adesso non ho voglia di impiegare molto
> tempo per configurare ulteriormente il mio sistema. Devo veder come mi
> trovo. Per adesso mi pare che si possa fare ma la scomodità è che non ho
> i sottotitoli generati automaticamente di YT in modo tale da leggere
> l'inglese. Poi devo ad ogni video premere Shift+CTRL+m per aprire una
> finestra di mpv. Devo vedere se mi trovo bene.
Per i sottotitoli non ti so dire, ma scommetterei che qualcuno ci ha
> On 01/06/23 14:53, Joe wrote:
>
>> Non è comunque comodissimo perché la finestra già aperta di MPV
>> mantiene la vecchia configurazione... quindi devo chiuderla e
>> poi do:
>>
>> gpudec off
>>
>> win+v ---> per aprire una nuova finestra di mpv
>>
>> quindi trascino nuovamente il link dentro
>>
>> e infine ctrl+f per scegliere il formato di qualità
>>
>>
>> È una manovra che faccio molto di rado...
>
> Manuale dettagliato però per adesso non ho voglia di impiegare molto
> tempo per configurare ulteriormente il mio sistema. Devo veder come mi
> trovo. Per adesso mi pare che si possa fare ma la scomodità è che non ho
> i sottotitoli generati automaticamente di YT in modo tale da leggere
> l'inglese. Poi devo ad ogni video premere Shift+CTRL+m per aprire una
> finestra di mpv. Devo vedere se mi trovo bene.
già pensato... figurati, per mpv ci sono migliaia di user scripts in
lua gli hanno fatto fare anche il caffé!
Per la codifica hardware in realtà sai cosa? Ho visto per caso che nel
manuale di mpv dice:
Ctrl h: Toggle hardware video decoding on/off
Ora, se era off di defult, premendo la scorciatoia in effetti a video
mi compare "hwdec VDPAU"... però devo fare qualche test per capire se
effettivamente il consumo cpu cambia davvero così al volo o se si deve
comunque ritrascinare il link dentro la finestra, perché le info che
ottengo con ctrl+i NON riportano vdpau. Non so se mi sono spiegato va
be'. In pratica se la cosa funziona, il mio script avrebbe poca
utilità, ci cambi solo il default... che puoi cambiare anche aprendo
il config con vim alla fine, tanto si lascia sempre su hwdec=auto e si
imposta la codifica software via CPU solo se qualcosa va storto.
>> Perché mai....
>> Con ffmpeg converti quello che vuoi basta avere i codec installati.
>
> YT ha intenzione di bloccare Ublock Origini e gli altri Adblocker e
> rendere obbligatoria la pubblicità...
te basta avere link di YT, poi lo passi a yt-dlp e vivi felice, non
serve passare da nessun sito terzo e simili menate, scarichi il
video nel formato migliore e quando lo hai in locale lo converti
codificandolo come meglio si adatta al tuo hardware. Se il migliore
era in AV1 ma la tua scheda non lo decodifica in hardware, te lo
converti in locale ad esempio in h265 o h264 e via. Non sono un
esperto di codifica video ma su ffmpeg e opzioni sù e giù c'è un
mondo di roba... bisogna sempre vedere cosa serve ottenere.
> Con radeotop vedo un sacco di parametri della GPU ma non saprei
> interpretarli, eccetto che quando va un video con mpv i grafici si
> impennano in generale.
> La cosa migliore sarebbe una scheda che supporti il VP9 ma poi se YT ti
> consuma un sacco di risorse quando visualizzi i video allora non risolvi
> nulla ed è meglio avere una scheda economica.
a gestire la decodifica hardware della scheda video. Anche lì in rete
si trovano migliaia di discussioni sull'argomento.
Io non mi sono mai sbattuto più di tanto per assicurarmi che firefox
sfrutti hwdec, e non sono neanche sicuro sicuro che sia possibile nel
mio caso, avendo solo VDPAU, mi pare così di sfuggita che fosse stata
implementata quella possibilità ma attraverso VAAPI, quindi per gpu
intel, amd.. per nvidia non so ma ormai le nuove mi sembra si basino su
nvdec per cui sarà ancora un altro discorso.
Quindi se riesci ad impostare il browser correttamente e hai una
GPU che macina VP9, hai voglia se è meglio avere una scheda che lo
supporta, meglio ancora se supporta AV1 che pare essere la codifica
più usata andando avanti. Poi va da sè che i prezzi delle schede negli
ultimi anni sono da pazzi... "ora" ho visto che anche intel sta
presentando schede mi sembra serie "ARC" che in fascia abbordabile
dovrebbero supportare anche codifica AV1. Per linux potrebbe essere
una buona notizia visto il buon supporto che hanno garantito in
passato coi driver già inclusi kernel ecc. Comunque non è roba economica
ed è pensata per gamers, cosa che non a tutti serve. In generale
comunque è una buona notizia sperando che un grosso attore come Intel
possa smuovere un po' le acque nel settore e i prezzi.
Ad ogni modo non mi sono mai sbattuto perché trovo molto più comodo
usare 3 o 4 finestre di mpv, da browser su youtube faccio solo le
ricerche, e anzi a dirla tutta spesso mi trovo meglio a fare la ricerca
da google o duckduckgo e selezionare poi "Video", salta fuori più roba
e spesso anche più attinente... youtube trova un po' quello che piace a
lui, ma può essere anche una mia impressione, pochi risultati e tanti
suggeimenti, a volte anche interessanti ma spesso dispersivi.
> 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.
0 new messages