Vi que aqui são feitas perguntas relacionadas à codificação e ao ShareX, então decidi perguntar neste portal.
Basicamente gravei o vídeo usando o ShareX 16.1. Versão ffmpeg:
ffmpeg version n7.0-14-g2d3ee7c069-20240423 Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13.2.0 (crosstool-NG 1.26.0.65_ecc5e41)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-fontconfig --enable-libharfbuzz --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-libdvdread --enable-libdvdnav --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libaribcaption --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libssh --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --enable-libvpl --enable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --enable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --disable-doc --disable-ffplay --disable-ffprobe --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-libs=-lgomp --extra-ldflags=-pthread --extra-ldexeflags= --cc=x86_64-w64-mingw32-gcc --cxx=x86_64-w64-mingw32-g++ --ar=x86_64-w64-mingw32-gcc-ar --ranlib=x86_64-w64-mingw32-gcc-ranlib --nm=x86_64-w64-mingw32-gcc-nm --extra-version=20240423
libavutil 59. 8.100 / 59. 8.100
libavcodec 61. 3.100 / 61. 3.100
libavformat 61. 1.100 / 61. 1.100
libavdevice 61. 1.100 / 61. 1.100
libavfilter 10. 1.100 / 10. 1.100
libswscale 8. 1.100 / 8. 1.100
libswresample 5. 1.100 / 5. 1.100
libpostproc 58. 1.100 / 58. 1.100
Universal media converter
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
As configurações dentro do ShareX são:
Na última tela você pode ver que copiei argumentos de linha de comando adicionais para gravação com microfone.
Gravei um vídeo de 2 horas e fiquei feliz em assistir ao material no dia seguinte, mas quando abri o VLC ou o Media Player Classic (versão mais recente) e quis pular para 1 hora e 5 minutos de vídeo, demorou cerca de 10 minutos para chegar lá...
Não tenho certeza se esse problema está relacionado ao NVENC (tenho uma 3770k e uma GTX1070ti, então decidi usar uma GPU, essa CPU está ficando sobrecarregada com vários programas e outras coisas) ou se é apenas comportamento do ShareX.
Parece muito estranho que as gravações do ShareX não busquem rapidamente. Basicamente, se eu for para 01:05:00, demora cerca de ~10 minutos. E então eu quero ir para 01:30:00 e vai demorar novamente uma quantidade enorme de tempo.
É como se esse vídeo tivesse sido gravado usando blocos "monolíticos" e não em "pedaços", então pular leva uma quantidade enorme de tempo.
O que preciso adicionar para fazer a busca funcionar rápido? Acho que talvez eu deva adicionar algo dentro de Additional command line arguments , assim como para filmes normais do YouTube ou qualquer filme de qualquer serviço, por exemplo, Netflix? Ou, improvável, talvez eu não consiga fazer isso?
Também estou aberto a outras sugestões com codificação e vários parâmetros, mas o principal culpado é esse problema de salto.
Uma maneira de possivelmente consertar problemas de busca é garantir que haja quadros-chave suficientes no vídeo , já que os players de vídeo geralmente os usam para pular para um tempo específico escolhido pelo usuário. Eles primeiro encontram o quadro-chave mais próximo e, em seguida, decodificam quadros mais otimizados até que o tempo seja atingido.
Para garantir que o codificador esteja incluindo quadros-chave suficientes, você pode adicionar
-g 60à opção ShareX ffmpeg additional args. Este parâmetro especifica o número de quadros entre 2 quadros-chave.60Com30FPS significa que estamos adicionando um quadro-chave a cada2segundos, então, no máximo, menos de2segundos precisarão ser decodificados.É claro que um GOP menor significa um tamanho de arquivo maior, pois mais quadros-chave = mais quadros completos no seu vídeo.