Mas OpenCL en video, FFMPEG2 y HandBrake.

Responder
1, 2
Mi distribución está enmascarada 5.0 porque hay conflictos que supongo pronto lo arreglaran. Hoy he estado probando opencl y funciona muy bien, que sería mejor para una gtx 1080 vdpau o opencl?
@Brutico ¿acaso vdpau ya tiene encoder?

Como sea Vulkan y OpenCL son mas universales mientras que vdpau esta enfocado a gnu/linux y derivados, ademas de que son proyectos vivos y activos, asi que estan mas actualizados [sin decir que proponiendo como hacer mejor las cosas]
Actualizacion de una tabla que mostre post atras con la compatibilidad de FMPEG con el hardware de la GPU [codificacion y decodificacion por hardware del GPU]

Imagen
Desde hace tiempo el software para codificacion de audio y video MEDIACODER usa FFMPEG 4 para el formato de video h264, h265 y AV1 y con ello agrega el soporte a la codificacion por GPU, la novedad es que agrega el soporte a usar los GPU RADEON [ademas de los ya anteriores nvidia e intel que tiene soporte directo]

En Mediacoder solo es elegir la pestaña de FFMPEG, pulsar el boton de opciones avnazadas..
Imagen



Y elegir AMF [Advanced Media Framework], el cual a su vez llama al modulo de codificacion VCE [Video Coding Engine] de la GPU Radeon.
Imagen
Imagen Ya tenemos FFmpeg IPFS Imagen


E IPFS [InterPlanetary File-System] es un protocolo de comunicacion en red, y ahora la reciente version de FFMPEG tiene soporte nativo integrado para este protocolo de comunicacion punto-a-punto. MPlayer por su cuenta y diseño propio tendra proximamente soporte tambien a IPFS mientras que software que utilize FFMPEG como KODI y la mugresita llamada VLC tandran dentro de poco soporte tambien a este protocolo de comunicacion que permitira compartir y distribuir contenido multimedia [entre otro tipo de datos]; y esperemos, de manera mas facil.
Imagen


Play media from a gateway
This idea seemed so logical and straightforward to me that I set out to figure out how to play my media via IPFS instead of KODI. It turns out KODI has so-called STRM files (opens new window). You can dump the URL to your media, and it works. While this worked, my URLs now looked like: http://10.0.3.3/ipfs/bafybeigagd5nmnn2i ... amiteydbzi. IPFS, being a distributed protocol, felt centralized in this case, as I’d have to ask for my video through 1 specific gateway (opens new window). Instead, I wanted the STRM file to look like this: ipfs://bafybeigagd5nmnn2iys2f3doro7ydre ... amiteydbzi. In this ideal case, a gateway URL would be handled by “something” else internally. In any case, I should not have to specify a gateway. In my mind having this made it possible that a video - any resource really - only has to be found on the IPFS network for it to work. For me, my server could be online, but my data could also be served from anywhere else! A powerful concept; native to IPFS.
But this did not work, KODI is not aware of the IPFS protocol. So this again got me wandering through the KODI codebase to figure out how it handles STRM files and where I might need to make a change to add IPFS support?

# Enter FFmpeg
STRM files aside, it turns out that whatever is in there is eventually handled in FFmpeg (opens new window). Of course, there is more to it than this, but it became clear that getting my ideal way to play video in KODI was diving into the FFmpeg codebase.
In FFmpeg you also have the ffplay utility, which is used to play anything that FFmpeg supports. In this tool, my video would happily play when provided as an HTTP URL:
ffplay http://10.0.3.3/ipfs/bafybeigagd5nmnn2i ... amiteydbzi
but not as:
ffplay ipfs://bafybeigagd5nmnn2iys2f3doro7ydre ... amiteydbzi

To me, the most straightforward approach was twofold.
- Let FFmpeg detect which gateway you use.
- Rewrite that ipfs://bafybeigagd5nmnn2iys2f3doro7ydre ... amiteydbzi internally to a http URL for that detected gateway and play the media.

blog.ipfs.io/2022-08-01-ipfs-and-ffmpeg
Versiones para macosx
ffmpeg 5.1.x https://evermeet.cx/ffmpeg/ffmpeg-109363-g6c814093d8.7z
FFMPEG 5.x con mejoras en Vulkan
Imagen
Imagen Imagen

Con la definicion definitiva de las extensiones para codificacion y decodificacion de video de Vulkan, y con ello que el GPU pueda codificar y decodificar usando la misma API grafica para renderizado 3D, proximamente saldran compilaciones nuevas de FFMPEG 5 que integren estas nuevas, optimizadas y mejoradas funciones de Vulkan.

De tal manera que FFMPEG podra usar el GPU [cosa que hace desde la version 4.3] para la aceleracion de compresion y descompresion de video en formato AV1, VP9, AVC, HEVC y algunos otros empleando Vulkan. Otras cosas que incluiran las proximas versiones de FFMPEG son:
- Filtros de procesamiento visual morpho, scharr, hsvkey, hsvhold, limitdiff, xcorrelate, varblur y huesaturation.
- Filtros de procesamiento del audio afwtdn, adecorrelate, atilt, grayworld, apsyclip, asdr, aspectralstats, adynamicequalizer y anlmf.
- Nuevas versiones de diferentes multiplexores de video.



.
Ahora tambien en gnu/linux se tendra esta opcion de codificacion por el GPU empleando vulkan, por lo menos para h264, con lo que ffmpeg se beneficiara de esto:

vulkan video encoding: radv update
Estan creando un controlador de video para radeon RADV con el soporte a estas extensiones de vulkan para la codificacion de video.

-->airlied.blogspot.com/2022/12/vulkan-video-encoding-radv-update.html
-->github.com/cyanreg/FFmpeg/tree/vulkan_decode
Y lo dicho, ya tenemos FFmpeg 5.1 con soporte a IPFS, la version mas reciente de FFMPEG es la 5.1.3.

Pero espera, tambien pronto vendra la version final de FFMPEG 6 de nobre Von Neumann. vendra con nuevos formatos de audio y video, y con ello nuevo codigo mejorado y depurado de los modulos encoders y decoders que tiene, entre esas mejoras estara un mejor uso de multihilos y mayor velocidad de procesamiento.


- Radiance HDR image support
- ddagrab (Desktop Duplication) video capture filter
- ffmpeg -shortest_buf_duration option
- ffmpeg now requires threading to be built
- ffmpeg now runs every muxer in a separate thread
- Add new mode to cropdetect filter to detect crop-area based on motion vectors and edges
- VAAPI decoding and encoding for 10/12bit 422, 10/12bit 444 HEVC and VP9
- WBMP (Wireless Application Protocol Bitmap) image format
- a3dscope filter
- bonk decoder and demuxer
- Micronas SC-4 audio decoder
- LAF demuxer
- APAC decoder and demuxer
- Media 100i decoders
- DTS to PTS reorder bsf
- ViewQuest VQC decoder
- backgroundkey filter
- nvenc AV1 encoding support
- MediaCodec decoder via NDKMediaCodec
- MediaCodec encoder
- oneVPL support for QSV
- QSV AV1 encoder
- QSV decoding and encoding for 10/12bit 422, 10/12bit 444 HEVC and VP9
- showcwt multimedia filter
- corr video filter
- adrc audio filter
- afdelaysrc audio filter
- WADY DPCM decoder and demuxer
- CBD2 DPCM decoder
- ssim360 video filter
- ffmpeg CLI new options: -stats_enc_pre[_fmt], -stats_enc_post[_fmt], -stats_mux_pre[_fmt]
- hstack_vaapi, vstack_vaapi and xstack_vaapi filters
- XMD ADPCM decoder and demuxer
- media100 to mjpegb bsf
- ffmpeg CLI new option: -fix_sub_duration_heartbeat
- WavArc decoder and demuxer
- CrystalHD decoders deprecated
- SDNS demuxer
- RKA decoder and demuxer
- filtergraph syntax in ffmpeg CLI now supports passing file contents as option values
- hstack_qsv, vstack_qsv and xstack_qsv filters
AOMedia¿pensara sacar un formato de audio? Y esto porque lei que aomedia tendra algo que ver de tener objetos de audio [como es en atmos, dts:x o mpeg-h-3d] manejados con OpenCL
ImagenGrupo Chronos agrega AV1 para la decodificacion de video en el GPU

De esta manera suando la API VULKAN, en el GPU se podra decodificar MPEG-4 AVC [h264], MPEG-4 HEVC [h265] junto con AV1, claro esta que hablamos de GPUs que soporten la decodificacion de AV1 pero lo bueno es que se podra usar directo la API Vulkan para ello.

Con la adicion de la instruccion VK_KHR_video_decode_av1 en la API Vulkan 1.3.277 es que se logra este soporte en la API.
github.com/KhronosGroup/Vulkan-Docs/commit/8c4e3f27f12060fd0bd1302393c4808fee6ce81f
60 respuestas
Responder
1, 2
Volver a General