Увидел свет (https://github.com/mpv-player/mpv/releases/tag/v0.14.0) выпуск открытого видеоплеера MPV 0.14 (http://mpv.io/), в 2011 году ответвившегося от кодовой базы проекта MPlayer2 (https://www.opennet.me/opennews/art.shtml?num=30005). В MPV основное внимание уделяется разработке новых возможностей и обеспечению постоянного бэкпортирования новшеств из репозиториев MPlayer и MPlayer2, не заботясь о сохранении совместимости с MPlayer. Код MPV распространяется (https://github.com/mpv-player/mpv) под лицензией GPLv2.В новой версии
- Проведена чистка кодовой базы, в рамках которой пекращена поддержка платформы Windows XP, удалён старый парсер субтитров и прекращена поддержка старых Linux PVR;
- В систему вывода через OpenGL (vo_opengl) добавлен экспериментальный бэкенд dxinterop, который формирует вывод при помощи OpenGL, но выводит его на экран через API Direct3D;- В vo_opengl добавлена начальная поддержка развиваемого в Google графического движка ANGLE (http://code.google.com/p/angleproject/) (Almost Native Graphics Layer Engine);
- Для платформы Windows реализована настройка icc-profile-auto и добавлена поддержка отображения на панели индикатора выполнения операции;
- Добавлены новые свойства estimated-display-fps и vsync-ratio; - В vo_opengl добавлена возможность изменения настройки LOOKUP_TEXTURE_SIZE.
URL: https://github.com/mpv-player/mpv/releases
Новость: http://www.opennet.me/opennews/art.shtml?num=43512
> основное внимание уделяется разработке новых возможностей и обеспечению постоянного бэкпортирования новшеств из репозиториев MPlayer и MPlayer2
> бэкпортирования новшеств из MPlayer2Он несколько лет назад закрылся. Чего они так внимательно из него бекпортируют?
Это, наверное, как с ffmpeg-mt, которого уже много лет как нет, но во всех новостях FFmpeg по-прежнему упоминается. Традиция такая :).
Да ладно, просто скопировали старую новость. Но вообще следует убрать, уже не актуально.
Вроде в Arch продолжают добавлять патчи в пакет с MPlayer2 и репозитории c MPlayer2 от homebrew по-немногу обновляется на GitHub: https://github.com/astiob/mplayer2
> Merge almost all branches into 'all'Я б не рискнул этим пользоваться.
> Чего они так внимательно из него бекпортируют?Они? Да если заглянуть в комиты mpv, то это фильм одного актёра. Ну и изредка ещё одного, ответственного за youtube.
Поцоны, как 10 бит видео в mkv-контейнере конвертировать в 8 бит? mpv хардварно декодить десяточку не умеет.
А причём тут mpv? Я вообще не знаю ни одного компьютерного видеоядра (в мобилках есть), которое умеет 10 бит декодировать.
Не при чём, просто я смотрю в нём. Хочется, чтобы нагружало проц меньше.
В мобилках тоже нет.
Знаю только за айфоны. В 5S уже есть.
Почему это? Их не так мало, но зависит от кодека. Для HEVC 10bpp режим в базовых спецификациях, поэтому почти все чипы, поддерживающие декодирование HEVC умеют и 10bpp (хотя есть исключения). Напр. Geforce GTX950, GTX960 и более новые (в т.ч. под линуксом через VDPAU, начиная с vdpau 1.0). У Intel это графика Skylake и выше.Мобильные SoC вообще практически все текущие умеют HEVC 10bpp (Mali V550 и выше, RockChip RK3288 и выше, PowerVR D5500 и выше; а вот Qualcomm запоздали, там HEVC 10bpp будет только начиная со Snapdragon 820).
Поддержку H264 10bpp добавлять не спешат, т.к. это была очень опциональная спефицикация и в отличие от HEVC 10bpp не использовалась ни в каком лицензионном контенте, да и поезд ушел, сейчас HEVC считается актуальным кодеком на будущее. Поэтому почти всегда заявляя о поддержке 10bpp имеют ввиду именно HEVC, а H264 10bpp при этом может и не поддерживаться (напр. http://www.cnx-software.com/2015/09/15/hisilicon-hi3798c-v20.../).
Что, к слову сказать, куда лучше, чем если было бы наоборот - HEVC настолько требователен к ресурсам, что без аппаратной поддержки его использовать крайне сложно... На 4K 10bpp HEVC загнется практически любой процессор, а если еще и 60fps, то *вообще* любой из существующих. А аппаратные декодеры спокойно воспроизводят такое.
Говорят, что профили 2 и 3 (10 и 12 бит) VP9 телевизоры тоже умеют. И программный декодер ffvp9 очень быстр, я 8K 24fps без дропов смотрел, с 16K уже 8 ядер в полку. 4K 60fps должен взять без особых проблем.
Про последние жифорсы не знал. Спасибо за инфу. Уже сузил круг претендентов на следующую видеокарту.
Не за что - главное, правильно понимать "последние" (смотреть поколение или хотя бы дату выхода, а не номер модели). Т.е. 950/960 это более новые карты, чем 970/980, которые не умеют HEVC.
(это как у AMD, Radeon R9 285 более новый и умеет больше, чем Radeon R9 290, а Radeon R9 370 вообще самый старый по поколению из этих трех).
ffmpeg.
Только времени займёт дофига.
Это понятно, что ffmpeg. Больше конкретная команда интересует.
ffmpeg -i in.mkv -с:v libx264 -format +yuv420p -qscale 0 -c:a copy out.mkv
> -qscale 0Т.е. 1.
для новых версий -vcodec и -acodec вместо -c:v и -c:a
Ман-то открой, наркоман, предже чем кукарекать подобные глупости.
-vcodec и -acodec — это алиасы совместимости к новой опции -c[:id_потока].
Тоже смотрел всякие эти 10-бит анимэ в MPC-HC под виндой. А что там особенного то? Кажет как всё остальное. Может мне виндусятнику объяснит кто? И почему только анимэ в таком формате я видел? И почему предупреждают в раздачах, что это 10-бит, типа, будьте осторожны? У меня просто всё кажет обычно - биты-кульбиты.
> А что там особенного то?Переобразования при кодировании и декодировании производятся с большей точностью, в результате для передачи градиентов без бандинга (лесенки) и тёмных областей без квадратов надо меньше битрейта.
> И почему только анимэ в таком формате я видел?Потому что:
— ирл градиенты без текстур встречаются реже;
— большинство видеокамер даёт шум, в результате чего на градиентах сам собой получается дизеринг;
— зрители (и релизеры рипов) фильмов в большинстве своём технически менее подкованы, и воспроизведение новых форматов у них чаще вызывает проблемы. До сих пор значительное количество фильмов выкладывается в xvid/avi, в то время как аниме кодировать в этот формат перестали лет 10 назад.
>> mpv хардварно декодить десяточку не умеет.
>> mpv
>> хардварноник как бы намекает
Он не очень удобный
Зато быстрый.
Неудобный только дефолтный псевдо GUI, в остальном все отлично.
есть такая же тулза как livestreamer только на node.js ?
> прекращена поддержка старых Linux PVRчто это такое?
Personal Video Recorder?
Такая проблема. Если в параметре передаю ссылку на ютубовский плейлист, в которой содержаться первый видеоролик из этого плейлиста, такая схема по умолчанию на ютубе, то у меня открывается только этот видеоролик. Параметр с плейлистом игнорируется.
mpv https://www.youtube.com/watch?v=-TqYul6LOyQ&list=PL5FMLPRj1j...
Что бы открыть именно плейлист, приходится вручную удалить из ссылки этот видеоролик, тогда загружается плейлист.
mpv https://www.youtube.com/watch?list=PL5FMLPRj1j6IChoB7nBKYNjC...
Можно ли как-то в настройках или в параметрах mpv задать, что бы он загружал плейлист по первой команде без модификации ссылки?
Это вроде дефолтное поведение youtube-dl.
> Это вроде дефолтное поведение youtube-dl.А в youtube-dl параметрами или конфигом это можно как-то исправить?
--no-playlist Download only the video, if the URL refers
to a video and a playlist.
--yes-playlist Download the playlist, if the URL refers to
a video and a playlist.
Спасибо, но и эта опция игнорируется, хотя логично ей быть по умолчанию.
Запостил баг. https://github.com/rg3/youtube-dl/issues/7867P.S. Оказывается амперсанд нужно экранировать.
mpv https://www.youtube.com/watch?v=-TqYul6LOyQ\&list=PL5FM...
> P.S. Оказывается амперсанд нужно экранировать.Я тебе сейчас еще больше удивлю - если почитать мануал, книжку или хотя бы какой гайд для чайников к используемому шеллу, то можно избежать многих граблей при его использовании, например узнав какие спецсимволы он использует, что они значат и какие варианты их экранирования существуют.
> Это вроде дефолтное поведение youtube-dl.Да нет, как оказалось, это именно косяк mpv.
https://github.com/mpv-player/mpv/issues/2592
Не косяк, просто настройка по умолчанию. Вот здесь аргументы разработчиков:
https://github.com/mpv-player/mpv/issues/1400#issuecomment-6...
А вот оно в коде:
https://github.com/mpv-player/mpv/blob/v0.14.0/player/lua/yt...
> Не косяк, просто настройка по умолчанию. Вот здесь аргументы разработчиков:
> https://github.com/mpv-player/mpv/issues/1400#issuecomment-6...
> А вот оно в коде:
> https://github.com/mpv-player/mpv/blob/v0.14.0/player/lua/yt...Спасибо за ссылки на аргументы.
Я что-то то ли не могу верно перевести вот это, начиная с and not the one
> mpv would always load the entire playlist and start playing the first video of the list and not the one that was actually linked if we didn't disable playlist resolving for "mixed" URLs.А так аргументы пользователей мне кажутся более весомыми. Ютуб отдаёт их в таком формате, и их очень удобно копировать из браузера, и совсем не удобно каждый раз редактировать. youtube-dl позволяет работать с таким форматом, но mpv непонятно зачем это отменяет и предлагает править каждый раз ссылки вручную или переопределить в конфиге ихний костыль. Зачем и какое это преимущество даёт, мне не понятно.
>Я что-то то ли не могу верно перевести вот это, начиная с and not the oneyoutube-dl с опцией --yes-playlist возвращает плейлист целиком и проигрывание в mpv начнётся с первого видео в плэйлисте. Нужен дополнительный код, который бы парсил параметры index/v, который пока никто не написал.
mpv --ytdl-raw-options=yes-playlist=Только проигрывание начнётся с первого видео. Можно исправить с помощью дополнительного ",playlist-start=D", номер из query-параметра index.
> mpv --ytdl-raw-options=yes-playlist=Спасибо, хотел с самого начала сделать именно так, не получалось из-за отсутствия знака = на конце опции для флагов, что я не сразу понял и нащёл в мане, но это всё равно не помогло. Запостил баг https://github.com/rg3/youtube-dl/issues/7867
>Только проигрывание начнётся с первого видео. Можно исправить с помощью дополнительного
> ",playlist-start=D", номер из query-параметра index.Спасибо за совет, с этим я уже тоже сталкивался, решал аналогичным образом.
P.S. Оказывается амперсанд нужно экранировать
mpv https://www.youtube.com/watch?v=-TqYul6LOyQ\&list=PL5FM...P.S. Запостил баг теперь к mpv https://github.com/mpv-player/mpv/issues/2592
SMPlayer теперь на MPV и работает лучше, чем сам MPV и настроек миллион и гуи отличный.
http:// smplayer.sourceforge.net/ru/downloads
А вот VLC стал плох и блюраи не крутит, а SMPlayer всё крутит и без багов.
Я не понимаю разработчиков VLC, было время когда их плеер был лучшим, но время идёт, а его развитие стоит на месте. Очень жаль.Проект разрабатывался для трансляции видео, для видеозаписи, для видеонаблюдения итп, но через 15 лет разработки, элементарные функции для этих дел с его использованием приходится писать на шеле - обвязки, а сам он практически ничего не умеет.
Мне не ясна политика этого проекта.Для Андроида подобные приложения уже гораздо лучше.
> но время идёт, а его развитие стоит на месте. Очень жаль.Ну, разработка там идёт. Но на каком уровне? Вот последние 2 месяца там вообще дедлок в мастере. Главный сделал комит, у него всё пашет. Да, дедлок не воспроизводится 100%. Помощник главного пытается его исправить (т.к. на андроиде воспроизводимость получше). Сначала главный вообще сопротивлялся, но потом, кажись, понял, в чём дело. Выходит, что у них там даже база шатается. Про фичи даже не знаю. А посмотришь имена функций, куча локов, хозяинов локов, ничё не понятно. Никакой большой блоксхемы, какие потоки, и как данные между декодером, отображателем плавают не нашёл. Из диалога главного и помощника о асинхронно-синхронном процессе видно, что и они сами уже не совсем видят всю картинку, не говоря уже о других, которые хотели бы поковыряться.
А вообще, был уверен, что VLC - это комьюнити проект. А выходит, что это почти приватный опен-соурс. Т.е. главный жёстко комментируют чужие патчи, а свои просто комитит (дедлок? - не верю, да и если даже, то всё к лучшему). Вон даже никто из 5 главных разработчиков Golang не комитит свои патчи (за очень редким исключением): они должны пройти ревью и только коллега может закомитить.
на фоне ванильного mp - оба форка смотрятся Чудовищно.
но учитывая Кто их пилит - оно и неудвиительно.