#h265 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #h265, aggregated by home.social.
-
Review of Rikomagic DS08 Android 13 digital signage player
-
Clarifying HEVC licensing fees, royalties, and why vendors kill HEVC support
-
Почему одинаковая надпись H.264 или H.265 на IP-камерах не делает их одинаковыми
На рынке видеонаблюдения есть удивительно живучий миф: если на двух IP-камерах написано H.264 или H.265, значит, и вести себя они должны примерно одинаково. Нагрузка на сеть будет похожей, архив займет сопоставимый объем, сервер разницы не заметит, а совместимость окажется чем-то само собой разумеющимся. Разберем, почему одинаковая надпись H.264 или H.265 не делает IP-камеры одинаковыми, какие параметры действительно влияют на поведение потока и на что стоит смотреть при выборе, тестировании и модернизации системы.
https://habr.com/ru/articles/1020930/
#видеонаблюдение #видео #видеоаналитика #vms #видеоархив #сетевые_технологии #h264 #h265 #кодеки #система_видеонаблюдения
-
Почему одинаковая надпись H.264 или H.265 на IP-камерах не делает их одинаковыми
На рынке видеонаблюдения есть удивительно живучий миф: если на двух IP-камерах написано H.264 или H.265, значит, и вести себя они должны примерно одинаково. Нагрузка на сеть будет похожей, архив займет сопоставимый объем, сервер разницы не заметит, а совместимость окажется чем-то само собой разумеющимся. Разберем, почему одинаковая надпись H.264 или H.265 не делает IP-камеры одинаковыми, какие параметры действительно влияют на поведение потока и на что стоит смотреть при выборе, тестировании и модернизации системы.
https://habr.com/ru/articles/1020930/
#видеонаблюдение #видео #видеоаналитика #vms #видеоархив #сетевые_технологии #h264 #h265 #кодеки #система_видеонаблюдения
-
Почему одинаковая надпись H.264 или H.265 на IP-камерах не делает их одинаковыми
На рынке видеонаблюдения есть удивительно живучий миф: если на двух IP-камерах написано H.264 или H.265, значит, и вести себя они должны примерно одинаково. Нагрузка на сеть будет похожей, архив займет сопоставимый объем, сервер разницы не заметит, а совместимость окажется чем-то само собой разумеющимся. Разберем, почему одинаковая надпись H.264 или H.265 не делает IP-камеры одинаковыми, какие параметры действительно влияют на поведение потока и на что стоит смотреть при выборе, тестировании и модернизации системы.
https://habr.com/ru/articles/1020930/
#видеонаблюдение #видео #видеоаналитика #vms #видеоархив #сетевые_технологии #h264 #h265 #кодеки #система_видеонаблюдения
-
Irgendwie hat die Jellyfin-App auf der Streambar von Roku seit einiger Zeit Probleme HEVC (H265) abzuspielen.
Abspielen klappt schon, allerdings kommt es zu sehr nervigen Unterbrechungen weil dauernd gebuffert wird.
Die Bitrate der Dateien ist nicht so außergewöhnlich verglichen mit denen, die problemlos abgespielt werden können.
... alle H265 Dateien nochmal zu konvertieren und durch H264 auszutauschen... Darauf habe ich keine Lust -.-
In Findroid auf dem Smartphone funktionieren einige (aber nicht alle) H265-Dateien ohne andauerndes Gebuffer.
Mal schauen, wie viele H265-Dateien ich überhaupt habe. War mein Standard-Codec für eine gewisse Zeit, bis ich wieder H264 mit Nvenc enkodiert habe.
-
Irgendwie hat die Jellyfin-App auf der Streambar von Roku seit einiger Zeit Probleme HEVC (H265) abzuspielen.
Abspielen klappt schon, allerdings kommt es zu sehr nervigen Unterbrechungen weil dauernd gebuffert wird.
Die Bitrate der Dateien ist nicht so außergewöhnlich verglichen mit denen, die problemlos abgespielt werden können.
... alle H265 Dateien nochmal zu konvertieren und durch H264 auszutauschen... Darauf habe ich keine Lust -.-
In Findroid auf dem Smartphone funktionieren einige (aber nicht alle) H265-Dateien ohne andauerndes Gebuffer.
Mal schauen, wie viele H265-Dateien ich überhaupt habe. War mein Standard-Codec für eine gewisse Zeit, bis ich wieder H264 mit Nvenc enkodiert habe.
-
Irgendwie hat die Jellyfin-App auf der Streambar von Roku seit einiger Zeit Probleme HEVC (H265) abzuspielen.
Abspielen klappt schon, allerdings kommt es zu sehr nervigen Unterbrechungen weil dauernd gebuffert wird.
Die Bitrate der Dateien ist nicht so außergewöhnlich verglichen mit denen, die problemlos abgespielt werden können.
... alle H265 Dateien nochmal zu konvertieren und durch H264 auszutauschen... Darauf habe ich keine Lust -.-
In Findroid auf dem Smartphone funktionieren einige (aber nicht alle) H265-Dateien ohne andauerndes Gebuffer.
Mal schauen, wie viele H265-Dateien ich überhaupt habe. War mein Standard-Codec für eine gewisse Zeit, bis ich wieder H264 mit Nvenc enkodiert habe.
-
Irgendwie hat die Jellyfin-App auf der Streambar von Roku seit einiger Zeit Probleme HEVC (H265) abzuspielen.
Abspielen klappt schon, allerdings kommt es zu sehr nervigen Unterbrechungen weil dauernd gebuffert wird.
Die Bitrate der Dateien ist nicht so außergewöhnlich verglichen mit denen, die problemlos abgespielt werden können.
... alle H265 Dateien nochmal zu konvertieren und durch H264 auszutauschen... Darauf habe ich keine Lust -.-
In Findroid auf dem Smartphone funktionieren einige (aber nicht alle) H265-Dateien ohne andauerndes Gebuffer.
Mal schauen, wie viele H265-Dateien ich überhaupt habe. War mein Standard-Codec für eine gewisse Zeit, bis ich wieder H264 mit Nvenc enkodiert habe.
-
Irgendwie hat die Jellyfin-App auf der Streambar von Roku seit einiger Zeit Probleme HEVC (H265) abzuspielen.
Abspielen klappt schon, allerdings kommt es zu sehr nervigen Unterbrechungen weil dauernd gebuffert wird.
Die Bitrate der Dateien ist nicht so außergewöhnlich verglichen mit denen, die problemlos abgespielt werden können.
... alle H265 Dateien nochmal zu konvertieren und durch H264 auszutauschen... Darauf habe ich keine Lust -.-
In Findroid auf dem Smartphone funktionieren einige (aber nicht alle) H265-Dateien ohne andauerndes Gebuffer.
Mal schauen, wie viele H265-Dateien ich überhaupt habe. War mein Standard-Codec für eine gewisse Zeit, bis ich wieder H264 mit Nvenc enkodiert habe.
-
Comment on this video (which us not shown on my Fedi instance, yay federation!)
https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF
I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!
Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).
As OBS can use your GPU for video capture (encoding), the issue is purely in software support.
I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.
For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.
For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.
-
Comment on this video (which us not shown on my Fedi instance, yay federation!)
https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF
I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!
Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).
As OBS can use your GPU for video capture (encoding), the issue is purely in software support.
I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.
For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.
For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.
-
Comment on this video (which us not shown on my Fedi instance, yay federation!)
https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF
I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!
Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).
As OBS can use your GPU for video capture (encoding), the issue is purely in software support.
I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.
For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.
For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.
-
Comment on this video (which us not shown on my Fedi instance, yay federation!)
https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF
I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!
Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).
As OBS can use your GPU for video capture (encoding), the issue is purely in software support.
I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.
For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.
For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.
-
Rockchip RK3588 and RK3576 H.264 and H.265 video decoders gain mainline Linux support
-
https://www.europesays.com/ie/340092/ German Court: Cease-and-Desist Against Notebooks and PCs Sold by ASUS & Acer #acer #against #Asus #CeaseAndDesist #Court #damage #Éire #Europe #german #Germany #GPU #H265 #hevc #Https://wwwTechpowerupCom/346421/germanCourtCeaseAndDesistAgainstNotebooksAndPcsSoldByAsusAcer #IE #Ireland #News #Nokia #notebooks #oem #patent #pcs #ru0026d #sold #Technology
-
M5Stack AI-8850 LLM Accelerator M.2 Kit offers an alternative to Raspberry Pi AI HAT+ 2
-
M5Stack AI-8850 LLM Accelerator M.2 Kit offers an alternative to Raspberry Pi AI HAT+ 2
-
M5Stack AI-8850 LLM Accelerator M.2 Kit offers an alternative to Raspberry Pi AI HAT+ 2
-
M5Stack AI-8850 LLM Accelerator M.2 Kit offers an alternative to Raspberry Pi AI HAT+ 2
-
M5Stack AI-8850 LLM Accelerator M.2 Kit offers an alternative to Raspberry Pi AI HAT+ 2
-
MUSE Book laptop review – Testing an octa-core RISC-V Linux laptop in 2026
-
VisionFive 2 Lite SBC Review – Ubuntu 24.04 on a low-cost RISC-V SBC in 2026
-
Видеокодек AV2 готов. Почему нам важны открытые стандарты
Новые видеокодеки моментально улучшают жизнь миллионов людей. Тем не нужно прикладывать практически никаких усилий, разве что обновить железо или софт. После этого видеофайлы магически уменьшаются в размере, качество картинки становится лучше, видео в интернете перестаёт тормозить и т. д. Например, новый видеокодек AV2 уменьшает трафик на 30%. Единственный недостаток — скорость кодирования многократно возрастает, потому что используются сложные интеллектуальные технологии (например, психофизические модели зрения и мозга, новые способы предсказания будущего (межкадровых изменений) по предыдущим кадрам, последние открытия в математике (вроде треллис-квантования ). Появляется ощущение некоего волшебства. Вообще, эффективное сжатие напрямую связано с пониманием данных, то есть с уровнем интеллекта. Чем глубже понимание смысла, тем больше мы видим аналогий, паттернов, циклов и рекурсий, которые можно использовать для «упаковки» информации. Как говорится, достаточно продвинутая технология неотличима от магии. Так и видеокодеки нового поколения — это настоящая программная магия.
https://habr.com/ru/companies/ruvds/articles/970584/
#av2 #av1 #hevc #h265 #сжатие_данных #AOMedia #avm #psnr #ssim #ruvds_статьи
-
Видеокодек AV2 готов. Почему нам важны открытые стандарты
Новые видеокодеки моментально улучшают жизнь миллионов людей. Тем не нужно прикладывать практически никаких усилий, разве что обновить железо или софт. После этого видеофайлы магически уменьшаются в размере, качество картинки становится лучше, видео в интернете перестаёт тормозить и т. д. Например, новый видеокодек AV2 уменьшает трафик на 30%. Единственный недостаток — скорость кодирования многократно возрастает, потому что используются сложные интеллектуальные технологии (например, психофизические модели зрения и мозга, новые способы предсказания будущего (межкадровых изменений) по предыдущим кадрам, последние открытия в математике (вроде треллис-квантования ). Появляется ощущение некоего волшебства. Вообще, эффективное сжатие напрямую связано с пониманием данных, то есть с уровнем интеллекта. Чем глубже понимание смысла, тем больше мы видим аналогий, паттернов, циклов и рекурсий, которые можно использовать для «упаковки» информации. Как говорится, достаточно продвинутая технология неотличима от магии. Так и видеокодеки нового поколения — это настоящая программная магия.
https://habr.com/ru/companies/ruvds/articles/970584/
#av2 #av1 #hevc #h265 #сжатие_данных #AOMedia #avm #psnr #ssim #ruvds_статьи
-
Видеокодек AV2 готов. Почему нам важны открытые стандарты
Новые видеокодеки моментально улучшают жизнь миллионов людей. Тем не нужно прикладывать практически никаких усилий, разве что обновить железо или софт. После этого видеофайлы магически уменьшаются в размере, качество картинки становится лучше, видео в интернете перестаёт тормозить и т. д. Например, новый видеокодек AV2 уменьшает трафик на 30%. Единственный недостаток — скорость кодирования многократно возрастает, потому что используются сложные интеллектуальные технологии (например, психофизические модели зрения и мозга, новые способы предсказания будущего (межкадровых изменений) по предыдущим кадрам, последние открытия в математике (вроде треллис-квантования ). Появляется ощущение некоего волшебства. Вообще, эффективное сжатие напрямую связано с пониманием данных, то есть с уровнем интеллекта. Чем глубже понимание смысла, тем больше мы видим аналогий, паттернов, циклов и рекурсий, которые можно использовать для «упаковки» информации. Как говорится, достаточно продвинутая технология неотличима от магии. Так и видеокодеки нового поколения — это настоящая программная магия.
https://habr.com/ru/companies/ruvds/articles/970584/
#av2 #av1 #hevc #h265 #сжатие_данных #AOMedia #avm #psnr #ssim #ruvds_статьи
-
Well .. it takes quite a bit longer to encode #h265 than I was expecting. Still crazy to me that CPU encoding is still superior to GPU encoding.
-
Well .. it takes quite a bit longer to encode #h265 than I was expecting. Still crazy to me that CPU encoding is still superior to GPU encoding.
-
Well .. it takes quite a bit longer to encode #h265 than I was expecting. Still crazy to me that CPU encoding is still superior to GPU encoding.
-
Well .. it takes quite a bit longer to encode #h265 than I was expecting. Still crazy to me that CPU encoding is still superior to GPU encoding.
-
Well .. it takes quite a bit longer to encode #h265 than I was expecting. Still crazy to me that CPU encoding is still superior to GPU encoding.
-
В последнее время стал жать видео в AV1 через #ffmpeg и #HandBrake. Из трёх кодировщиков: libsvtav1, libaom-av1 и librav1e стабильно работает первый, хорошо и эффективнее жмёт маленькие видео по сравнению с распространённым H265, но пытаюсь ужать видео в 2,2 ГБ и размер его только увеличивается 🙄
Обратился к интернету и вот результатыСравнение libsvtav1 и libaom-av1: ключевые различия
libaom-av1 — это эталонный кодировщик AV1, разработанный Альянсом открытых медиа (AOMedia), в основном при участии Google. Он ориентирован на достижение максимального качества и сжатия, часто используется как точка отсчёта при сравнении других кодировщиков. В то время как SVT-AV1 (libsvtav1) — это проект, созданный Intel и Netflix, с акцентом на высокую скорость и масштабируемость, особенно в многопоточных средах.
SVT-AV1 разработан для практических применений, включая трансляции и массовое перекодирование, где важна производительность.
Ниже приведено детальное сравнение двух кодировщиков по ключевым параметрам.Качество и эффективность сжатия
libaom-av1 традиционно считается лидером по качеству, особенно на медленных пресетах (например, cpu-used=2). В тестах с метриками вроде VMAF он может давать чуть лучшее качество при одинаковом битрейте, особенно на сложных сценах и статике. Это делает его предпочтительным для архивного перекодирования или когда качество важнее времени.
SVT-AV1 немного уступает в пиковой эффективности, но разница минимальна — «на волосок». При этом он предлагает гораздо более предсказуемое и стабильное качество на пресетах средней и высокой скорости. Благодаря оптимизациям, он эффективен даже при низких битрейтах, что важно для стриминга.
Скорость и производительность
SVT-AV1 значительно превосходит libaom-av1 по скорости кодирования, особенно на современных CPU. Например, тесты на Snapdragon 680 показали, что SVT-AV1 работает в 2–3 раза быстрее при сопоставимом качестве. Это достигается за счёт отказа от некоторых сложных функций AV1 и использования эффективной многопоточной архитектуры на основе тайлов и строк.
libaom-av1, напротив, известен своей медлительностью, особенно в однопоточном режиме. Его многопоточность слабо оптимизирована, что делает его менее пригодным для массового использования.
Применение и экосистема
libaom-av1 — идеален для задач, где важна максимальная эффективность сжатия, а время кодирования не критично (например, перекодирование фильмов).
SVT-AV1 — выбор для live-стриминга, медиасерверов (например, Nimble Streamer), облачных транскодеров и любых сценариев, где важна масштабируемость и скорость.
ВЫВОД
Выбирайте libaom-av1, если вам нужно максимальное качество и вы готовы ждать.
Выбирайте SVT-AV1, если важна скорость, масштабируемость и производительность в реальных условиях.
SVT-AV1 считается более «практичным» кодировщиком будущего, тогда как libaom-av1 остаётся «золотым стандартом» для измерения качества.
-
В последнее время стал жать видео в AV1 через #ffmpeg и #HandBrake. Из трёх кодировщиков: libsvtav1, libaom-av1 и librav1e стабильно работает первый, хорошо и эффективнее жмёт маленькие видео по сравнению с распространённым H265, но пытаюсь ужать видео в 2,2 ГБ и размер его только увеличивается 🙄
Обратился к интернету и вот результатыСравнение libsvtav1 и libaom-av1: ключевые различия
libaom-av1 — это эталонный кодировщик AV1, разработанный Альянсом открытых медиа (AOMedia), в основном при участии Google. Он ориентирован на достижение максимального качества и сжатия, часто используется как точка отсчёта при сравнении других кодировщиков. В то время как SVT-AV1 (libsvtav1) — это проект, созданный Intel и Netflix, с акцентом на высокую скорость и масштабируемость, особенно в многопоточных средах.
SVT-AV1 разработан для практических применений, включая трансляции и массовое перекодирование, где важна производительность.
Ниже приведено детальное сравнение двух кодировщиков по ключевым параметрам.Качество и эффективность сжатия
libaom-av1 традиционно считается лидером по качеству, особенно на медленных пресетах (например, cpu-used=2). В тестах с метриками вроде VMAF он может давать чуть лучшее качество при одинаковом битрейте, особенно на сложных сценах и статике. Это делает его предпочтительным для архивного перекодирования или когда качество важнее времени.
SVT-AV1 немного уступает в пиковой эффективности, но разница минимальна — «на волосок». При этом он предлагает гораздо более предсказуемое и стабильное качество на пресетах средней и высокой скорости. Благодаря оптимизациям, он эффективен даже при низких битрейтах, что важно для стриминга.
Скорость и производительность
SVT-AV1 значительно превосходит libaom-av1 по скорости кодирования, особенно на современных CPU. Например, тесты на Snapdragon 680 показали, что SVT-AV1 работает в 2–3 раза быстрее при сопоставимом качестве. Это достигается за счёт отказа от некоторых сложных функций AV1 и использования эффективной многопоточной архитектуры на основе тайлов и строк.
libaom-av1, напротив, известен своей медлительностью, особенно в однопоточном режиме. Его многопоточность слабо оптимизирована, что делает его менее пригодным для массового использования.
Применение и экосистема
libaom-av1 — идеален для задач, где важна максимальная эффективность сжатия, а время кодирования не критично (например, перекодирование фильмов).
SVT-AV1 — выбор для live-стриминга, медиасерверов (например, Nimble Streamer), облачных транскодеров и любых сценариев, где важна масштабируемость и скорость.
ВЫВОД
Выбирайте libaom-av1, если вам нужно максимальное качество и вы готовы ждать.
Выбирайте SVT-AV1, если важна скорость, масштабируемость и производительность в реальных условиях.
SVT-AV1 считается более «практичным» кодировщиком будущего, тогда как libaom-av1 остаётся «золотым стандартом» для измерения качества.
-
В последнее время стал жать видео в AV1 через #ffmpeg и #HandBrake. Из трёх кодировщиков: libsvtav1, libaom-av1 и librav1e стабильно работает первый, хорошо и эффективнее жмёт маленькие видео по сравнению с распространённым H265, но пытаюсь ужать видео в 2,2 ГБ и размер его только увеличивается 🙄
Обратился к интернету и вот результатыСравнение libsvtav1 и libaom-av1: ключевые различия
libaom-av1 — это эталонный кодировщик AV1, разработанный Альянсом открытых медиа (AOMedia), в основном при участии Google. Он ориентирован на достижение максимального качества и сжатия, часто используется как точка отсчёта при сравнении других кодировщиков. В то время как SVT-AV1 (libsvtav1) — это проект, созданный Intel и Netflix, с акцентом на высокую скорость и масштабируемость, особенно в многопоточных средах.
SVT-AV1 разработан для практических применений, включая трансляции и массовое перекодирование, где важна производительность.
Ниже приведено детальное сравнение двух кодировщиков по ключевым параметрам.Качество и эффективность сжатия
libaom-av1 традиционно считается лидером по качеству, особенно на медленных пресетах (например, cpu-used=2). В тестах с метриками вроде VMAF он может давать чуть лучшее качество при одинаковом битрейте, особенно на сложных сценах и статике. Это делает его предпочтительным для архивного перекодирования или когда качество важнее времени.
SVT-AV1 немного уступает в пиковой эффективности, но разница минимальна — «на волосок». При этом он предлагает гораздо более предсказуемое и стабильное качество на пресетах средней и высокой скорости. Благодаря оптимизациям, он эффективен даже при низких битрейтах, что важно для стриминга.
Скорость и производительность
SVT-AV1 значительно превосходит libaom-av1 по скорости кодирования, особенно на современных CPU. Например, тесты на Snapdragon 680 показали, что SVT-AV1 работает в 2–3 раза быстрее при сопоставимом качестве. Это достигается за счёт отказа от некоторых сложных функций AV1 и использования эффективной многопоточной архитектуры на основе тайлов и строк.
libaom-av1, напротив, известен своей медлительностью, особенно в однопоточном режиме. Его многопоточность слабо оптимизирована, что делает его менее пригодным для массового использования.
Применение и экосистема
libaom-av1 — идеален для задач, где важна максимальная эффективность сжатия, а время кодирования не критично (например, перекодирование фильмов).
SVT-AV1 — выбор для live-стриминга, медиасерверов (например, Nimble Streamer), облачных транскодеров и любых сценариев, где важна масштабируемость и скорость.
ВЫВОД
Выбирайте libaom-av1, если вам нужно максимальное качество и вы готовы ждать.
Выбирайте SVT-AV1, если важна скорость, масштабируемость и производительность в реальных условиях.
SVT-AV1 считается более «практичным» кодировщиком будущего, тогда как libaom-av1 остаётся «золотым стандартом» для измерения качества.
-
В последнее время стал жать видео в AV1 через #ffmpeg и #HandBrake. Из трёх кодировщиков: libsvtav1, libaom-av1 и librav1e стабильно работает первый, хорошо и эффективнее жмёт маленькие видео по сравнению с распространённым H265, но пытаюсь ужать видео в 2,2 ГБ и размер его только увеличивается 🙄
Обратился к интернету и вот результатыСравнение libsvtav1 и libaom-av1: ключевые различия
libaom-av1 — это эталонный кодировщик AV1, разработанный Альянсом открытых медиа (AOMedia), в основном при участии Google. Он ориентирован на достижение максимального качества и сжатия, часто используется как точка отсчёта при сравнении других кодировщиков. В то время как SVT-AV1 (libsvtav1) — это проект, созданный Intel и Netflix, с акцентом на высокую скорость и масштабируемость, особенно в многопоточных средах.
SVT-AV1 разработан для практических применений, включая трансляции и массовое перекодирование, где важна производительность.
Ниже приведено детальное сравнение двух кодировщиков по ключевым параметрам.Качество и эффективность сжатия
libaom-av1 традиционно считается лидером по качеству, особенно на медленных пресетах (например, cpu-used=2). В тестах с метриками вроде VMAF он может давать чуть лучшее качество при одинаковом битрейте, особенно на сложных сценах и статике. Это делает его предпочтительным для архивного перекодирования или когда качество важнее времени.
SVT-AV1 немного уступает в пиковой эффективности, но разница минимальна — «на волосок». При этом он предлагает гораздо более предсказуемое и стабильное качество на пресетах средней и высокой скорости. Благодаря оптимизациям, он эффективен даже при низких битрейтах, что важно для стриминга.
Скорость и производительность
SVT-AV1 значительно превосходит libaom-av1 по скорости кодирования, особенно на современных CPU. Например, тесты на Snapdragon 680 показали, что SVT-AV1 работает в 2–3 раза быстрее при сопоставимом качестве. Это достигается за счёт отказа от некоторых сложных функций AV1 и использования эффективной многопоточной архитектуры на основе тайлов и строк.
libaom-av1, напротив, известен своей медлительностью, особенно в однопоточном режиме. Его многопоточность слабо оптимизирована, что делает его менее пригодным для массового использования.
Применение и экосистема
libaom-av1 — идеален для задач, где важна максимальная эффективность сжатия, а время кодирования не критично (например, перекодирование фильмов).
SVT-AV1 — выбор для live-стриминга, медиасерверов (например, Nimble Streamer), облачных транскодеров и любых сценариев, где важна масштабируемость и скорость.
ВЫВОД
Выбирайте libaom-av1, если вам нужно максимальное качество и вы готовы ждать.
Выбирайте SVT-AV1, если важна скорость, масштабируемость и производительность в реальных условиях.
SVT-AV1 считается более «практичным» кодировщиком будущего, тогда как libaom-av1 остаётся «золотым стандартом» для измерения качества.
-
В последнее время стал жать видео в AV1 через #ffmpeg и #HandBrake. Из трёх кодировщиков: libsvtav1, libaom-av1 и librav1e стабильно работает первый, хорошо и эффективнее жмёт маленькие видео по сравнению с распространённым H265, но пытаюсь ужать видео в 2,2 ГБ и размер его только увеличивается 🙄
Обратился к интернету и вот результатыСравнение libsvtav1 и libaom-av1: ключевые различия
libaom-av1 — это эталонный кодировщик AV1, разработанный Альянсом открытых медиа (AOMedia), в основном при участии Google. Он ориентирован на достижение максимального качества и сжатия, часто используется как точка отсчёта при сравнении других кодировщиков. В то время как SVT-AV1 (libsvtav1) — это проект, созданный Intel и Netflix, с акцентом на высокую скорость и масштабируемость, особенно в многопоточных средах.
SVT-AV1 разработан для практических применений, включая трансляции и массовое перекодирование, где важна производительность.
Ниже приведено детальное сравнение двух кодировщиков по ключевым параметрам.Качество и эффективность сжатия
libaom-av1 традиционно считается лидером по качеству, особенно на медленных пресетах (например, cpu-used=2). В тестах с метриками вроде VMAF он может давать чуть лучшее качество при одинаковом битрейте, особенно на сложных сценах и статике. Это делает его предпочтительным для архивного перекодирования или когда качество важнее времени.
SVT-AV1 немного уступает в пиковой эффективности, но разница минимальна — «на волосок». При этом он предлагает гораздо более предсказуемое и стабильное качество на пресетах средней и высокой скорости. Благодаря оптимизациям, он эффективен даже при низких битрейтах, что важно для стриминга.
Скорость и производительность
SVT-AV1 значительно превосходит libaom-av1 по скорости кодирования, особенно на современных CPU. Например, тесты на Snapdragon 680 показали, что SVT-AV1 работает в 2–3 раза быстрее при сопоставимом качестве. Это достигается за счёт отказа от некоторых сложных функций AV1 и использования эффективной многопоточной архитектуры на основе тайлов и строк.
libaom-av1, напротив, известен своей медлительностью, особенно в однопоточном режиме. Его многопоточность слабо оптимизирована, что делает его менее пригодным для массового использования.
Применение и экосистема
libaom-av1 — идеален для задач, где важна максимальная эффективность сжатия, а время кодирования не критично (например, перекодирование фильмов).
SVT-AV1 — выбор для live-стриминга, медиасерверов (например, Nimble Streamer), облачных транскодеров и любых сценариев, где важна масштабируемость и скорость.
ВЫВОД
Выбирайте libaom-av1, если вам нужно максимальное качество и вы готовы ждать.
Выбирайте SVT-AV1, если важна скорость, масштабируемость и производительность в реальных условиях.
SVT-AV1 считается более «практичным» кодировщиком будущего, тогда как libaom-av1 остаётся «золотым стандартом» для измерения качества.
-
So I have hundreds of videos of ~1 minute recorded from my phone ~10 years ago, and they generally don’t have that great compression, nor they are stored in a modern and advanced video format.
For archiving purposes, I want to take advantage of my workstation’s mighty GPU to process them so that the quality is approximately the same, but the file size would be strongly reduced.
Nevertheless, compressing videos is terribly hard, and way more complex than compressing pictures, so I wouldn’t really know how to do this, what format to use, what codec, what bitrate, what parameters to keep an eye on, etc.
I don’t care if the compression takes a lot of time, I just want smaller but good looking videos.
Any tips? (Links to guides and tutorials are ok too)
Also, unfortunately I am forced to use Windows for this (don’t ask me why 🫠), but I know nothing about Windows because I hate it. Practical software suggestions are very much welcome, too!
#ffmpeg #help #askFedi #codec #AVI #H265 #H264 #movie #video #videoCompression #compression #encoding #HandBrake #heif #heic #avif #mp4 #mkv #Wondows
-
So I have hundreds of videos of ~1 minute recorded from my phone ~10 years ago, and they generally don’t have that great compression, nor they are stored in a modern and advanced video format.
For archiving purposes, I want to take advantage of my workstation’s mighty GPU to process them so that the quality is approximately the same, but the file size would be strongly reduced.
Nevertheless, compressing videos is terribly hard, and way more complex than compressing pictures, so I wouldn’t really know how to do this, what format to use, what codec, what bitrate, what parameters to keep an eye on, etc.
I don’t care if the compression takes a lot of time, I just want smaller but good looking videos.
Any tips? (Links to guides and tutorials are ok too)
Also, unfortunately I am forced to use Windows for this (don’t ask me why 🫠), but I know nothing about Windows because I hate it. Practical software suggestions are very much welcome, too!
#ffmpeg #help #askFedi #codec #AVI #H265 #H264 #movie #video #videoCompression #compression #encoding #HandBrake #heif #heic #avif #mp4 #mkv #Wondows
-
So I have hundreds of videos of ~1 minute recorded from my phone ~10 years ago, and they generally don’t have that great compression, nor they are stored in a modern and advanced video format.
For archiving purposes, I want to take advantage of my workstation’s mighty GPU to process them so that the quality is approximately the same, but the file size would be strongly reduced.
Nevertheless, compressing videos is terribly hard, and way more complex than compressing pictures, so I wouldn’t really know how to do this, what format to use, what codec, what bitrate, what parameters to keep an eye on, etc.
I don’t care if the compression takes a lot of time, I just want smaller but good looking videos.
Any tips? (Links to guides and tutorials are ok too)
Also, unfortunately I am forced to use Windows for this (don’t ask me why 🫠), but I know nothing about Windows because I hate it. Practical software suggestions are very much welcome, too!
#ffmpeg #help #askFedi #codec #AVI #H265 #H264 #movie #video #videoCompression #compression #encoding #HandBrake #heif #heic #avif #mp4 #mkv #Wondows
-
So I have hundreds of videos of ~1 minute recorded from my phone ~10 years ago, and they generally don’t have that great compression, nor they are stored in a modern and advanced video format.
For archiving purposes, I want to take advantage of my workstation’s mighty GPU to process them so that the quality is approximately the same, but the file size would be strongly reduced.
Nevertheless, compressing videos is terribly hard, and way more complex than compressing pictures, so I wouldn’t really know how to do this, what format to use, what codec, what bitrate, what parameters to keep an eye on, etc.
I don’t care if the compression takes a lot of time, I just want smaller but good looking videos.
Any tips? (Links to guides and tutorials are ok too)
Also, unfortunately I am forced to use Windows for this (don’t ask me why 🫠), but I know nothing about Windows because I hate it. Practical software suggestions are very much welcome, too!
#ffmpeg #help #askFedi #codec #AVI #H265 #H264 #movie #video #videoCompression #compression #encoding #HandBrake #heif #heic #avif #mp4 #mkv #Wondows
-
So I have hundreds of videos of ~1 minute recorded from my phone ~10 years ago, and they generally don’t have that great compression, nor they are stored in a modern and advanced video format.
For archiving purposes, I want to take advantage of my workstation’s mighty GPU to process them so that the quality is approximately the same, but the file size would be strongly reduced.
Nevertheless, compressing videos is terribly hard, and way more complex than compressing pictures, so I wouldn’t really know how to do this, what format to use, what codec, what bitrate, what parameters to keep an eye on, etc.
I don’t care if the compression takes a lot of time, I just want smaller but good looking videos.
Any tips? (Links to guides and tutorials are ok too)
Also, unfortunately I am forced to use Windows for this (don’t ask me why 🫠), but I know nothing about Windows because I hate it. Practical software suggestions are very much welcome, too!
#ffmpeg #help #askFedi #codec #AVI #H265 #H264 #movie #video #videoCompression #compression #encoding #HandBrake #heif #heic #avif #mp4 #mkv #Wondows
