Jump to content

fredericopissarra

Membros
  • Content Count

    271
  • Joined

  • Last visited

Community Reputation

203 Excellent

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. E 8K? Tem gente entusiasmada com isso... 8K é resolução de 7680x4320 (yep... nada de 8k aqui, no máximo 7.7k - te enganaram, de novo!) para 23.976 fps, teríamos um bit rate mínimo de 57.5 Mb/s. Ou seja, o vídeo final típicamente fica 36 vezes maior que o mesmo vídeo em 720p. Aquele vídeo hipotético de 500 MB ficaria com 18 GiB. Isso ai é o tamanho de um episódio de uma série qualquer (geralmente cerca da 40 minutos de vídeo)...
  2. PS: E 4K? Para 3840x2160 @ 23.976 fps você precisa de 14.4 Mb/s de bit rate. Compare com 1280x720: O arquivo final ficará, pelo menos 9 vezes maior, em 4K, contando apenas o bit rate. Sem contar o tamanho dos quadros... Um vídeo de 4K pode ficar de 9 a 18 vezes maior que um em HD. Por isso que para o mesmo vídeo, em 720p tendo uns 500 MB de tamanho, um em 2160p tem uns 4.5 GiB ou mais...
  3. Ahhh... atualmente tenho preferido codificar meus vídeos com frame rate 23.976 fps (NTSC-FILM). Isso me dá um bit rate menor... Também tenho preferido, para Widescreen (aspecto 16:9) a resolução de 1280x720 e para LetterBox (aspecto 4:3), 720x540. Respectivamente, teremos os bit rates de 1.6Mb/s e 650kb/s. Codec avc1 (h264). Chroma subsampling: YUV420P (ou NV12, se estiver recodificando numa velha máquina Intel com um i5 de 3ª geração!)... No caso do Widescreen, poderia ter o padrão de 1920x1080 (Full HD), mas o bit rate teria que ser de 3.6 Mb/s, o que me dá arquivos maiores e o ganho de "clareza" da imagem é indistinguível (a não ser que você vá ver um filme numa TV de 60" ou mais)... Áudio: AC-3, 96 kb/s, stereo e sampling rate de 44.1 kHz. Container: MPEG-4 (.mp4). Em certos casos consigo arquivos até 8 vezes menores que os originais, baixados por ai. Mas é mais comum umas 4 ou 5 vezes menor.
  4. Divida seus códigos em "módulos" (é assim que são chamados cada um dos arquivos com extensão .c) e "ligue" tudo, depois, na hora de "linkar". Esses troços de "programação estruturada", "modular", "funcional", "procedural", "orientada a objetos", etc... É um balaio de gatos que você só vai entender se compreender de onde vieram (lá nos anos 50/60)... De meu lado, acho "orientação a objetos" uma bela de uma porcaria - que diz resolver problemas de estruturação, mas só complica a vida bem mais... No fim das contas um programa é composto de instruções e dados. Nada mais que isso, além dos algorítmos tradicionais... Assim como escrever um artigo ou livro, um autor precisa encontrar seu estilo. Ao encontrar (copiando o estilo dos outros), fixe-se nele e deixe essas bobeiras de lado... Mas, se quiser passar o resto de sua vida profissional sofrendo horrores sem entender o que está fazendo e tendo que solucionar bugs escabrosos que "aparecem do nada", então, continue tentando aderir à moda da vez. E boa sorte.
  5. PS: Se o aspecto é próximo do desejado e reescalonar causará distorções, use o macete das barras pretas!
  6. Tenho observado que a maioria dos vídeos que baixamos, seja via torrents, seja via outros sites de vídeo (Youtube, e... a-ham... XVideos, PornHub, etc...), não aderem aos padrões de vídeos... Por exemplo, O frame-rate pode ser não padronizado (geralmente, 24 fps [filmes da telona], 24000/1001 fps ou 23.976 fps [filmes da telona no padrão NTSC], 25 fps [PAL]; ou 30000/1001 ou 29.97 fps [NTSC]). Alguns frame-rates não são padrão, como 30 fps, por exemplo... Existe um outro problema relativo aos frame-rates: Num container de vídeo são armazenados 2 frame-rates: O do qual o vídeo foi codificado e o qual o vídeo será "tocado". Às vezes os dois não batem... Seria prudente que a relação entre eles fosse 1:1, da mesma forma que a resolução gráfica para o aspect ratio. Outro problema é o aspect ratio. Os mais comuns são 4/3 (letter-box) e 16/9 (wide-screen), mas existem outros: 3/2 (35mm still camera film), 16/10 (outro padrão para wide-screen, menos usual), 5:3 (Super 16 - padrão Europeu), 64/24 e 32:9 (ultra wide-screen - também neos usual). No entanto, muitos vídeos usam resoluções gráficas não padronizadas, distorcendo a imagem (daí o macete das barras pretas que mostrei antes)... Um terceiro problema, mas que não entra, necessariamente, na categoria de padrões, é o bitrate em que o vídeo é codificado... É comum, hoje em dia, que vídeos tenham bitrates MUITO altos, na tentativa de compensar distorções causadas por "artefatos" no vídeo. Então, é comum ver vídeos HD (720p), por exemplo, com bitrates na ordem de 4~5 Mb/s, quando, aproximadamente 2 Mb/s é mais que suficiente. Isso diminuirá o tamanho do vídeo com perdas insignificantes. Minha dica, use o ffmpeg para converter seus vídeos para os padrões... Por exemplo, se você tem um vídeo em 640x382 (uma resolução não padrõnizada - aspecto 320/191), note que ele está mais próximo do aspecto 16/9 (wide screen) do que 4/3 (letter-box). Assim, convertê-lo para 16/9 pode ser uma boa ideia... Ainda, ajuste o framerate... suponha que o vídeo original use 30 fps, usar NTSC pode ser outra boa ideia... E, como vamos usar widescreen, a resolução final poderá ser 1280x720 (duplicar x e y não causará problemas de distorção, se o filtro certo for usado)... assim, com uma nVidia, podemos fazer: $ ffmpeg -hwaccel cuvid \ -i videoin.mp4 \ -c:v h264_nvenc \ -pix_fmt yuv420p \ -bufsize 1.998M -maxrate 1.998M -b:v 1.998M \ -r ntsc \ -vf scale=1280:720:flags=lanczos,setdar=16/9 \ -c:a ac3 \ -b:a 128k -ac 2 -ar 44.1k -async 1 \ videoout.mp4 Aqui ajusto chroma subsampling para o YUV 4:2:0 (algumas vezes o vídeo vêm codificado com NV12, por exemplo); o bitrate para 1.998 Mb/s (segundo aquela minha "fórmula mágica" num post anterior); o frame-rate para 29.97 (ntsc), reescalono o vídeo para 1280x720, usando o filtro lanczos, ajusto o aspect ratio (DAR) para 16/9 [o ffmpeg fará isso sozinho, mas prefiro dar uma mão])... Logo depois uso o codec AC-3 (AAC não funciona na minha TV! hehe), ajustando o bitrate do audio para 128 kb/s, stereo com sampling-rate de 44.1 kHz (48 kHz é exagero!). No audio, o filtro -async 1 (alias para um filtro aresample) garante que o audio estará sincronizado com o novo frame-rate do vídeo... Há uma desvantagem em fazer isso se seu container tem um stream de legenda (subtitle) emburido... As legendas estão sincronizadas com o frame-rate do vídeo, ao mudar o frame-rate não temos como sincronizar as legendas via algum filtro... Assim, retire a legenda do vídeo (opção -sn), obtenha a legenda e resincronize-a usando algum outro software (SubRip, por exemplo). Voilà! videoout.mp4 está dentro do padrão para widescreen 720p. Se você tem um PC com video on-board, mas seu processador é Intel i# de uma geração mais recente (6ª geração em diante?), pode trocar a opção -hwaccel cuvid por: "-hwaccel vaapi -vaapi_device /dev/dri/renderD128"; trocar o encoder para "h264_vaapi", mas deve adicionar o filtro "hwupload" na opção -vf e pode até mudar o escalonador para "scale_vaapi": "-vf hwupload,scale_vaapi=1280:720,setdar=16/9" (para gerações anteriores a 6ª, deixe com "scale=1280:720:flags=lanczos,hwupload,setdar=16/9".
  7. Consulte a sessão de downloads do Forum...
  8. Existem diferenças óbvias entre "dúvida" e "ignorância" (no sentido estrito da palavra). Não saber alguma coisa não é uma "dúvida"... Recomendo que procure material para estudo e estude... Eis alguns pontos: Não existe linguagem "ASSEMBLER"... Assembler é o nome dado ao compilador da linguagem "Assembly" (com 'y'). Vem do inglês, "montador"; Não existe UMA linguagem assembly: Cada família de processadores tem a sua... Intel/AMD x86 é diferente dos ARM, que é diferente dos Risc-V, que é diferente dos MIPS, PowerPC, etc...; Existem vários "sabores" de ASSEMBLERs (montadores); Existem vários modos de operação nos x86-64... Um programa feito para DOS não funciona no Windows e vice-versa (especialmente no Win10); Um "hello world" em assembly dependerá do sistema operacional em uso e do modo de operação... Assembly não é, por definição, portável.
  9. Cruz credo... compra um processador decente, misifio...
  10. Em primeiro lugar, a explicação que dei acima está bem longe de ser um código compilável (são fragmentos). Em segundo... o que diabos é uma "CPU ADM"?
  11. Ahhhh... mas um char não tem sempre 8 bits de tamanho? Nope! Em arquiteturas antigas 1 byte era de 9 bits e existem arquiteturas que não conseguem lidar com 1 byte isolado, dai char pode ter mais que 8 bits...
  12. Uma dica que me repassaram agorinha... Sempre achei que CHAR_BITS, definido em limits.h, fosse o tamanho em bits do tipo char. De fato é, mas também é o tamanho em bits de um byte. A sessão 6.2.6.1 §4 da ISO 9989 (1999 em diante, pelo menos) é clara ao dizer que todos os objetos que não são bit-fields têm tamanho n * CHAR_BITS, onde n é o tamanho em bytes devolvido pelo sizeof. Fica a dica.
  13. Depende do que você interpreta por "variável". Um valor numérico pode ser armazenado na memória ou num registrador... Ela pode ser inteira ou ponto flutuante... Para mostrar, na sintaxe do NASM, eis alguns exemplos: section .data ; define uma região de 4 bytes no segmento de dados contendo o valor 0x0000000A (10), nomeado 'myvar' myvar: dd 10 Daqui para frente, a referência à memória é feita através desse "identificador" 'myvar'. Por exemplo: mov eax,[myvar] ; Lê 4 bytes da memória, na posição de 'myvar', no segmento de dados, e coloca em EAX. Note que poderíamos colocar o valor 10 diretamente em EAX e, nesse caso, o registrador EAX seria sua "variável": mov eax,10 No caso do NASM, valores numéricos em ponto flutuante podem ser atribuídos da mesma forma, na memória: section .data myvar2: dd 3.141592 Esse 'myvar2' é um float, ocupando 4 bytes, da mesma forma que um 'int', no exemplo anterior. E, assim como no exemplo anterior, ele pode ser acessado por uma instrução, mas o 'registrador' será diferente... Por exemplo, via SSE: movss xmm0,[myvar2] Outro lugar onde suas varíaveis podem ser colocadas é na pilha. É o caso de variáveis 'locais'. Mas, isso exige alguma manipulação do "apontador de pilha" (ESP ou RSP, dependendo do modo de operação). Por exemplo: sub rsp,8 ; reserva espaço na pilha (precisa estar alinhada de 8 em 8 bytes!). mov dword [rsp],10 ; escreve 10 na pilha. ... add rsp,8 ; recupera o espaço reservado anteriormente... Bons compiladores de alto nível (C, por exemplo) tentam manter as variáveis locais em registradores sempre que podem para evitar esse tipo de manipulação da pilha (e gastar menos espaço na memória, ganhando velocidade de processamento também).
  14. O código de exemplo do PRNG "bixado", no post, tinha um errinho na geração do arquivo gráfico PPM. Corrigi. É bom lembrar que estou enviando o arquivo para stdout ao invés de gravá-lo diretamente num arquivo, assim, a chamada do executável (como está no post) deve ser: $ cc -O2 -o random random.c $ ./random > pic.ppm Use o 'eog' ("Eye of GNOME", acho, ou "GNOME Image Viewer") para ver o arquivo ou o converta para PNG com o ImageMagick: $ convert pic.ppm pic.png []s Fred
  15. Acredito que eu ainda não tenha mostrado esse post aqui: https://is.gd/AtpHNC Fica a dica de um teste visual para Pseudo Random Numbers Generators. Outra dica (que não está no post) é o uso do utilitário dieharder (disponível nos Linux) para análises de RNGs. []s Fred
×
×
  • Create New...