Marcos FRM

Meio off-topic. Você não conseguiria o mesmo com a versão de linha de comando do HandBrake? Não sei se o FFmpeg usado por ele (linka diretamente as bibliotecas) é compilado com --enable-avisynth (provavelmente não), mas esse filtros básicos de remoção de tarjas, denoise, etc, são nativos, com opções para ajuste fino. Nele você consegue codificar com o x264, x265, svt-av1, libvpx-vp9, etc, usando duas passadas com bitrate ou uma com CQ/CRF. https://handbrake.fr/docs/en/latest/cli/command-line-reference.html

Ahh, é que é um recurso que estará apenas na futura versão 17. Portanto... rode apenas os dois primeiros comandos do post #5 e depois reinicie a máquina. Vamos ver se ajuda.

572f66344d43424c6d316d796b6f7a42-default-sink e 572f66344d43424c6d316d796b6f7a42-default-source estão com 1 byte. Não está certo. Rode apenas os dois primeiros comandos do post #5 e depois reinicie a máquina. Vamos ver se ajuda... Lendo o manual descobri que existe o argumento "@NONE@" para fazê-lo voltar ao padrão. Rode então: pactl set-default-sink @NONE@ pactl set-default-source @NONE@

Hehe. Repita os passos do post #5 que a configuração volta para o padrão. Olhou em "Configurações"?

Você olhou na guia "Configurações" se não tem nada lá? O comando para fazer pelo terminal é: pactl set-default-sink alsa_output.pci-0000_00_1b.0.analog-stereo

Está correto. O dispositivo padrão está provavelmente em "572f66344d43424c6d316d796b6f7a42-default-sink". O PulseAudio também salva o dispositivo usado anteriormente por cada aplicativo em "572f66344d43424c6d316d796b6f7a42-stream-volumes.tdb". Tente redefinir a configuração toda: systemctl --user stop pulseaudio.socket pulseaudio.service rm -f ~/.config/pulse/572f66344d43424c6d316d796b6f7a42* systemctl --user start pulseaudio.socket pulseaudio.service (cuidado se for digitar manualmente: no segundo comando, não pode ter espaço antes do asterisco!) Depois, configure o dispositivo padrão primeiro, antes de tocar qualquer coisa.

Em princípio não. Qual modelo da sua placa-mãe?

Será que não é problema similar ao do outro tópico? Seu usuário tinha UID/GID 1000. Depois, sei lá como , passou a ser UID/GID 1001, mantendo o mesmo nome. Rode isto para ver quem é o dono dos diretórios: ls -an ~/.config/pulse ~/.local/state

Consegue ler e gravar no pendrive sem problema? Caso sim, marque o post #20 como solução para organizar o fórum.

Reinicie o Mint. Certo. Não rode esse.

A RX 580 não é UEFI-only? Pois daí depende... algumas placas com o H61 não possuem BIOS UEFI. @gutopereira

Os drivers da Intel são bons no Linux também... a questão é se as GPUs Arc são competitivas. Provavelmente ainda não. E requerem Linuxes bem atualizados para rodarem. Com distribuições "LTS" nem pensar.

@Henrique - RJ Isso não resolve nada. O pendrive tem que ser acessível pelo usuário logado, sem necessidade de su/sudo/etc. Essa uma das principais atribuições do udisks. @Rhaniery Ignore minha mensagem anterior, pois não funcionará. Fui ler o código do udisks para entender o que está acontecendo. Ele só aplica a ACL ao criar o diretório (caso o mesmo não exista). Então remover a ACL não adianta. Desmonte e desconecte todos os pendrives/discos externos primeiro. Então rode: sudo rmdir /media/usuario (forneça sua senha) Depois reinicie. É para resolver. É uma limitação de distribuições que compilam o udisks com --enable-fhs-media, como é o caso do Debian e derivados. Se o UID do usuário mudar e seu nome continuar o mesmo, acontece isso. Distribuições como Fedora e Arch, que não compilam com --enable-fhs-media, recriam a cada inicialização o diretório base onde os pontos de montagem são colocados, visto que /run/media é volátil (tmpfs), ao contrário de /media. Assim, nelas, basta reiniciar que essa situação é magicamente solucionada.

A ACL está errada, pois está liberando acesso para o UID 1000. Desmonte o pendrive, rode: sudo setfacl -b /media/usuario (forneça sua senha) Depois reinicie. O udisks deverá adicionar novamente a ACL.

Algo está quebrado na sua instalação. O que os seguintes comandos retornam? Nota: não precisa ficar anexando imagens. Copie o texto e depois cole aqui no fórum usando a função "Code" do editor (o ícone "<>"). ls -al /media ls -al /media/usuario getfacl /media/usuario

Rode: ls -al /media/usuario/LW

O dono do ponto de montagem está correto (uid/gid 1001, seu usuário). Por que você está navegando pela pasta como root? ("admin://" na barra de endereço)

Então é a IPM H55 (HDMI). Tem o BIOS lá no site da PCWARE.

Como usa o H55, descarta a IPM P55. Então sobram IPM H55 e IPM H55 (HDMI). Pela especificação, a única diferente é a presença da porta HDMI... a sua tem?

O aplicativo Fotos atualizou aqui no Windows 10 para a versão 2023.11080.4003.0. Agora suporta WebP, basta configurar a associação de arquivo.

AMD Ryzen 5 1600 (AF) https://www.cpu-world.com/CPUs/Zen/AMD-Ryzen 5 1600 (AF).html CPUID 800F82 (Zen+, Pinnacle Ridge). MC Extractor v1.90.2 r274, arquivo B550MAE.18a (BIOS F18a): +-------------------------------------------------------------------+ ¦ AMD ¦ ¦-------------------------------------------------------------------¦ ¦ # ¦ CPUID ¦ Revision ¦ Date ¦ Size ¦ Offset ¦ Last ¦ ¦----+----------+----------+------------+--------+-----------+------¦ ¦ 1 ¦ 00800F82 ¦ 0800820D ¦ 2019-04-16 ¦ 0xC80 ¦ 0x449000 ¦ Yes ¦ ¦----+----------+----------+------------+--------+-----------+------¦ [...] Tem o microcódigo para funcionar... Para os Zen originais (Summit Ridge), CPUID 800F11, também está lá: [...] ¦----+----------+----------+------------+--------+-----------+------¦ ¦ 3 ¦ 00800F11 ¦ 08001138 ¦ 2019-02-04 ¦ 0xC80 ¦ 0x44AA00 ¦ Yes ¦ ¦----+----------+----------+------------+--------+-----------+------¦ [...]

Você mudou o rótulo... findmnt -u /media/usuario/LW

Estava montado? Tem que aparecer, no aplicativo Discos, aquela linha "Montado em ...".

Eu acho que é o codec usado. Tentei enviar um em MPEG-2 (do tempo do DVD...) e aconteceu isso. Já H.264 ele envia normal. Veja nas propriedades do arquivo... Outra coisa. Teste o aplicativo do WhatsApp da Microsoft Store. Talvez seja mais compatível.

Apple até que está colaborando. Suporta WebP (Safari 14+), AVIF (16.4+, quando o suporte ficou completo) e agora JPEG XL (17+). Firefox não suporta JPEG XL nas versões estáveis -- apenas na Nightly e requer uma configuração experimental em about:config. Chrome (e Edge por usar a mesma base) removeu o suporte na versão 110. Portanto, o Safari liderar a adoção é bem-vindo. Supondo que os demais sigam o mesmo caminho adicionando JPEG XL, também será em versões novas. O importante é ter suporte universal de pelo menos um, AVIF ou JPEG XL, nos quatro principais navegadores: Chrome, Edge, Safari, Firefox. Daí finalmente a web começará a sair dos Tempos Antigos no que diz respeito às imagens... AVIF está mais próximo de conseguir: basta o Edge adicioná-lo.