Кодирование VP9 с ffmpeg

[sdf]

Собрал из git ffmpeg c поддержкой VP9. Сборка не вызвала никаких проблем. Но вот при кодировании

(Нажмите, чтобы показать/скрыть)

ffmpeg -i "/home/.../1.mkv"  -t 00:00:10 -vcodec libvpx-vp9 -b:v 500k -ar 44100 -b:a 128k -ac 2 -strict -2 2.webm
ffmpeg version N-55222-g18d7074 Copyright (c) 2000-2013 the FFmpeg developers
  built on Aug  4 2013 16:35:44 with gcc 4.7 (Ubuntu/Linaro 4.7.3-1ubuntu1)
  configuration: --enable-libvpx
  libavutil      52. 40.100 / 52. 40.100
  libavcodec     55. 20.100 / 55. 20.100
  libavformat    55. 13.101 / 55. 13.101
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 82.100 /  3. 82.100
  libswscale      2.  4.100 /  2.  4.100
  libswresample   0. 17.103 /  0. 17.103
Input #0, matroska,webm, from '/home/.../1.mkv':
  Metadata:
    creation_time   : 2013-04-12 15:04:47
  Duration: 01:32:34.48, start: 0.000000, bitrate: 2198 kb/s
    Stream #0:0: Video: h264 (High), yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
    Stream #0:1: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s (default)
[libvpx-vp9 @ 0x1d90860] v1.2.0-3362-g35abb70
[libvpx-vp9 @ 0x1d90860] Failed to set VP8E_SET_TOKEN_PARTITIONS codec control: Unspecified internal error
Output #0, webm, to '2.webm':
  Metadata:
    encoder         : Lavf55.13.101
    Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 1024x576 [SAR 1:1 DAR 16:9], q=-1--1, 500 kb/s, 1k tbn, 25 tbc (default)
    Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> libvpx-vp9)
  Stream #0:1 -> #0:1 (ac3 -> vorbis)
Press [q] to stop, [?] for help
frame=   26 fps=2.2 q=0.0 size=       4kB time=00:00:01.27 bitrate=  28.7kbits/sframe=   27 fps=1.1 q=0.0 size=       5kB time=00:00:01.27 bitrate=  30.7kbits/s

И в итоге файл размером 58к, в котором 53к на звук и 5к на видео. Что не так в моих настройках?

[sdf]

В итоге все норм, просто ffmpeg с июля использует двухпроходное кодирование для VP9 (2-pass). Если это необходимо выделю эту тему в решенные и в список "временных" вопросов о кодированиии VP9 с помощью ffmpeg.

[arch!ver]

что не так в моих настройках?

< -b:v 500k > с таким битрейтом вы не получите более или менее качественный результат. Рекомендуется не менее 1000k. А со стандартными разрешениями типа:
4:3 - 720x576, 640x480
или
16:9 - 720x400, 640x360
рекомендуются - 2000k...

[sdf]

Вообще на текущий момент это тестовый кодек, еще не утвержден и официально нигде не используется. Он очень медленный и пригоден лишь для файлов по 10-20 сек, ведь на каждый кадр он тратит по несколько секунд 100% ЗАГРУЗКИ ОДНОГО ЯДРА для 720p, а многопоточность еще не реализована и сам кодек не оптимизирован; на текущий момент разработчики работают над качеством. По поводу битрейта: на doom9 есть тема, в ней обсуждается этот кодек, так один из форумчан выложил фото от кодирования 1080p(FullHD) VP9 с 300 кбит/с и для сравнения с наилучшими настройками в x264, разница просто громадная. Собственно я просто тестирую кодек, а никак не перекодировываю свои видео. Пока это бесмысленно, на один фильм уйдет 1.5 месяца, а смартфон его все равно не прочитает.

[arch!ver]

По поводу битрейта: на doom9 есть тема, в ней обсуждается этот кодек, так один из форумчан выложил фото от кодирования 1080p(FullHD) VP9 с 300 кбит/с и для сравнения с наилучшими настройками в x264, разница просто громадная.

- Это фейк! - гарантия. Эксперементальный кодек, которые недопилен и сильно уступает x264 просто физически не сможет сделать видео фуллайчди с битрейтом 300k да ещё и лучше чем x264   Вас разводят, уверяю - типичный пиарский развод - 100% гарантии...
К тому же разговор идёт о ВИДЕО, а не о статичном фото, которое даже MPEG4-ISO/IEC и то воспроизводит прекрасно при соответствующих настройках...

Видео - это не статичное фото - это совершенно другой принцип кодирования материала, в котором барьер 1000k и ниже ещё ни кто не преодлолевал со стандартными настройками и тем более отличным качетвом при высоком разрешении..., а тем более с движущимися сценами...

[peregrine]

archiver, VP9 не уступает x264, там ещё очень многое можно усовершенствовать, просто нужны большие вычислительные мощности, но то, что сырой и недоделаный кодек что-то может сжать я не верю, так как пока он у меня не завёлся, падает с ошибкой, что не может

[libvpx-vp9 @ 0x361daa0] v1.2.0
[libvpx-vp9 @ 0x361daa0] Failed to set VP8E_SET_TOKEN_PARTITIONS codec control: Unspecified internal error
[webm @ 0x3602880] Only VP8,VP9 video and Vorbis,Opus(experimental, use -strict -2) audio and WebVTT subtitles are supported for WebM.

Как и у ТС, вот только судя по следующей теме от вывода ошибки ему удалось избавиться, а до создания нормального файла дело так и не дошло.

[arch!ver]

peregrine,
Мы говорим о битрейте, а не об уступании одного кодека другому. Политика битрейта не может быть изменена на столько кардинально - ибо есть такое понятие как "разумный предел" особенно минимальный... Разговор идёт о снижении веса файла, при том же битрейте, а не про снижение битрейта - "ниже плинтуса с шикарным качеством ".
Можно подсчитать минимальное колличество необходимых бит для вывода движущихся сцен 1920х1080 пикселей с приемлемым колличеством бит на пиксел, ну допустим - поделить это где то на 2, так как инфа выводится чаще всего полукадрами. И - высчитать этот минимальный барьер, а затем сравнить его с восприятием своего зрительного аппарата, - ибо он является окончательной "госприёмкой", а не цифры
VP9 уступает x264, но не многим (я преувеличил ) - и чуть больше уступает x265 (процентов 5-10%). И продвигается он в силу желания мультемедиа ресурсов избежать патентов и выплат - эта, основная цель этого кодека, а не качество...
Т.е фактически этот кодек заточен на НЭТ, на потоковое видео, и использовании его именно там...
А в домашних условиях можно смело продолжать использовать x264 c максимальными настройками и даже - новый x265 (если он вообще где то есть)
Пользователь решил продолжить мысль 07 Августа 2013, 22:43:35:

от вывода ошибки ему удалось избавиться, а до создания нормального файла дело так и не дошло.

Уважаемый Сокол, ну а вам есть куда торопиться?... Пусть допиливают, а там и посмотрим детально, - уже на "созревший" результат, а не на сетевые сплетни...

[peregrine]

archiver, интересно потыкать, есть ли видимый прогресс, кроме как бредни в интернете. Пока как не работал (падал с дампом памяти месяц назад), так и падает до сих пор. Вывод - пилят на коленке и очень медленно, не взлетит или взлетит через 10 лет, когда морально устареет. Потолок сжатия видео ещё очень далек, так как практически каждый кадр похож на предыдущий, только вычислительные мощности нужны огромные, так как если написать более плотно жмущий алгоритм от него будет столько же пользы, как от paq8 (Жмёт JPG в архив без потери качества на 25%, но сжимает одну фотку час и использует до 16 Гб оперативки, жмёт текст в нескольо раз лучше RAR или 7Zip, но сжимает 1 мегабайт текста за час)...

[arch!ver]

archiver, интересно потыкать, есть ли видимый прогресс, кроме как бредни в интернете.

Не, ну тут вооще без вопросов - потыкать это святое! ... Просто я уже как то - натыкался - утомило, передохну пожалуй на удовлетворяющем результате с x264

[sdf]

В общем методом костылей (т.е. сконвертировал видеофайл в rawvideo) и сравнил с x264 и оригиналом. До HD 720p смотреть особо нечего, картинка почти одинакова, разница в том где и сколько артефактов, делал в разных битрейтах; как и говорили разработчики на низких разрешениях ничего не ждите. 720p, 1080p на вид с x264 схожи при одинаковом битрейте, я бы даже сказал x264 чуть лучше, но я не знаю какие настройки были использованы в ffmpeg, бо кодирует намного быстрее vpxenc с настройкой --good.