?

Log in

No account? Create an account
Ни о какой безапелляционности в моих высказываниях не может быть и речи! [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

немного об уважении к пользователю [сент. 23, 2005|08:11 pm]
Anatoly Vorobey
Не знаю, получится ли вкратце объяснить, но история поучительная (для программистов в основном, наверное).

Разнообразных форматов видео-файлов существует сейчас огромное количество. Как правило, видео-файл включает в себя информацию о картинке, определённым образом сжатую (видео-поток), информацию о звуке, определённым образом сжатую (аудио-поток); кроме того, они должны быть
соответствующим образом синхронизированы и сохранены вместе внутри одного файла. На всё это - способ сжатия видео, способ сжатия аудио, способ их соединения вместе (называется muxing или multiplexing) - существует множество разных стандартов и алгоритмов. Кроме того, либо в самом видео-файле, либо в отдельных файлах могут присутствовать субтитры; они могут быть записаны как в виде текстового потока, определённым образом синхронизированного с секундами видео-потока, так и в качестве отдельных картинок, тоже синхронизированных. На всё это тоже есть штук 5 разных популярных стандартов.

В сети, особенно в сетях файлообмена P2P, существует огромное количество разнообразных файлов, записанных с применением десятков таких разных стандартов. Всё это надо как-то проигрывать и показывать пользователям, на экранах компьютеров, телевизоров и проекторов. Под Windows большинство пользователей запускают Windows Media Player, но для того, чтобы он читал большинство популярных в сети форматов, нужно сгрузить и установить в него множество разных плагинов, которые называются "кодеки" (codec). Под Линуксом существует много разных библиотек и относительно немного больших удобных программ, которые умеют понимать и показывать почти все форматы.

Две самые популярные из этих программ под Линуксом (а также другими юниксами) - mplayer и xine. Оба - очень хорошие программы, с множеством полезных опций, умеющие показывать практически всё, что можно найти или создать. Принято считать, однако, что mplayer, с одной стороны, несколько более развит технически, т.е. умеет показывать некоторые вещи, которые xine не берёт (и мой личный опыт это подтверждает), но, с другой стороны, очень недружелюбен к пользователям. Даже графический интерфейс в нём по умолчанию не компилируется (хотя есть), а его разработчики славятся грубым и злобным отношениям к пользователям, которые задают всякие вопросы на почтовых рассылках или в других форумах.

Вот простой, и вместе с тем несколько поучительный, по-моему, пример такого пренебрежительного отношения к пользователю со стороны программы mplayer, причём совершенно глупого и неоправданного; из моего личного опыта.


Представьте себе, что вы запускаете программу, прося её показать какой-то, например, фильм, и потом выбираете опцию "Full screen" (кнопка f в программах mplayer и xine, есть, кроме того, и опция в меню и в командной строке), чтобы расширить картинку до максимума. В моём случае картинка идёт на подключенный к компьютеру телевизор, но многие смотрят фильмы прямо на мониторах, если это достаточно удобно; полезная опция, одним словом.

Когда вы выбираете эту опцию, программа "забирает" себе всё пространство экрана, и пытается расширить картинку до максимума так, чтобы она в него влезла. Но если вы смотрите широкоформатный фильм, и даже некоторые TV-форматные записи, то после такого расширения у вас всё равно останется "лишнее пространство" снизу и сверху кадра: отношение ширины к высоте больше у кадра фильма, чем у вашего монитора (точнее, чем у разрешения вашего монитора, например, 640x480 или 800x600).

Например, предположим, что у кадра фильма отношение ширины к высоте составляет 1.85:1, а ваш монитор находится в разрешении 800x600. Тогда после того, как картинка расширится до предела, её высота будет составлять 800/1.85 = 432 пикселя, т.е. полоса в 168 пикселей высотой будет оставаться неиспользованной - точнее, обычно две полосы, 84 сверху и 84 снизу кадра.

Обычно это не стоит и упоминания - просто цена просмотра широкоформатного фильма; но если у вас к фильму есть субтитры, логично было бы попросить, чтобы программа выдавала их как раз в эту неиспользованную чёрную полосу ниже кадра, чтобы они не налегали на саму картинку - это очень удобно. И, в конце концов, ясно, что у программы техническая возможность это сделать есть (кроме тех случаев, когда субтитры не идут отдельным потоком или файлом, а "вшиты" прямо в тело картинки заранее - тут уж ничего не поделаешь).

Программа xine это делает сама по умолчанию. Тут всё очень просто: если запустить её и переключить в full-screen режим, она просто начинает писать субтитры в нижнюю часть экрана, а не в нижнюю часть кадра, который стоит посреди экрана; и всё отлично. А вот mplayer так не умеет; если запустить его и сделать full-screen режим, он продолжает писать субтитры в нижнюю часть кадра, оставляя чёрную полосу ниже неиспользованной. И это очень раздражает: ведь есть уже это место, ясно, что он может - но не пишет.

Почему так получается? Когда я перевожу программу в режим full-screen, я как бы заставляю её разграничить два понятия, которые в обычном режиме у неё совпадают: понятие прямоугольника на экране, куда проецируется картинка, и понятия прямоугольника на экране, который программа контролирует. В режиме full-screen программа "занимает" весь экран, закрывая чёрным цветом даже те его части, которые не попадают в область расширенной картинки. Но при этом, очевидно, внутри программы xine эта более широкая область существует в качестве отдельного понятия - понятия области, где программа может что-то рисовать, даже если она выходит за пределы кадра. А во внутренностях mplayer этого нет, он не умеет рисовать нечто, относящееся к фильму, за пределами прямоугольника кадра фильма. Для его модуля-"проектора" существует только этот прямоугольник кадра; "зачернение" оставшихся полос в режиме full-screen происходит где-то в другом месте, и информация об этом не передаётся модулю-"проектору".

Мораль ясна: в этой области внутренний дизайн xine продуман явно лучше внутреннего дизайна mplayer, и это отражается на том, что может и чего не может сделать пользователь, самым непосредственным образом.

Но это ещё не всё. На самом деле в mplayer есть возможность сделать то же самое, но несколько другим способом. Перед тем, как раскодированная и расширенная до нужного размера картинка "поступает" на передачу на экран к модулю-"проектору", mplayer позволяет пропустить её через множество разного рода фильтров, в которых можно задать (в командной строке) всякие простые визуальные эффекты и преобразования. Одна из таких опций - возможность искусственно "расширить" кадр за счёт чёрных полос, не меняя его содержимое. Тогда получается вот что: кадр, скажем, сам размером 800x432, но путём искусственого добавления тёмных полос сверху и снизу я превращаю его в кадр размером 800x600, и в таком виде он поступает к модулю-"проектору"; он, как и раньше, умеет добавлять субтитры только в нижнюю часть самого кадра, как он его видит, но эта нижняя часть теперь находится в добавленной чёрной полосе.

Дело в том, однако, что разобраться с этой опцией - нетривиально, и не приходится рассчитывать на то, что средний пользователь эту проблему одолеет. Она выглядит примерно так:

mplayer -vf expand=0:-168:0:84 [имя файла]

Здесь "-vf" означает "видео фильтр", "expand" - название фильтра, потом идут четыре числа, первые два объясняют, насколько расширять кадр - 0 в ширину, -168 в высоту (минус означает здесь, что это добавочная высота, а не общая конечная высота), потом ещё два числа, означающие, где надо ставить первоначальную картинку внутри расширенной — '84' означает, что она сдвигается на 84 пикселя ниже верхней границы расширенного кадра, и поэтому добавленная высота в 168 пикселей делится на две полосы в 84 пикселя вверху и внизу.

И после этого всё работает! Но можете вы себе представить, что человек, не разбирающийся совершенно в компьютерах, а просто желающий посмотреть фильм, сможет это правильно наладить? Я не могу.

И глупо тут то, что ведь всё это совершенно тривиально было бы сделать автоматически или хотя бы с помощью отдельной простой опции. Пусть mplayer не умеет, как xine, писать в область экрана, лежащую вне кадра; всё равно, этот видео-фильтр "expand" можно было бы наладить автоматически после того, как пользователь нажимает кнопку "f". Зачем заставлять его вычислять все эти числа (168, 84) и правильно их писать в командной строке? У самой программы все эти данные уже есть. В крайнем случае, если трудно поставить фильтр, когда программа уже показывает фильм, можно было бы сделать дополнительную опцию, что-то вроде -fullsub, и если она есть в командной строке, то mplayer сам вычисляет всё, что нужно, и налаживает фильтр. Но нет, философия этой программы и её создателей - плевать на пользователя, не стоит делать никаких "косметических" изменений, которые облегчили бы ему жизнь. И на практике это выражается в том, что mplayer'ом пользуются только те, кто могут сами разобраться в мириадах сложных опций и плохой документации. А жаль, потому что с технической точки зрения программа действительно отличная.

Всё.
СсылкаОтветить

Comments:
[User Picture]From: keen
2005-09-23 05:34 pm
Вот ты зануда-то! :)

(Спасибо за tech.details)
(Ответить) (Thread)
[User Picture]From: alexis_m
2005-09-23 06:20 pm
Зато ему нескучно.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: 9000
2005-09-23 05:55 pm
А ещё бывают публичные терминалы, очень часто под linux (чтобы за лицензии не платить).
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: (Anonymous)
2005-09-23 06:11 pm
А может, к нему есть отдельный frontend, который позволяет такие опции настраивать?
(Ответить) (Thread)
[User Picture]From: avva
2005-09-23 06:23 pm
Кажется, нет у него такого. И даже библиотеки нет, в которой бы была вся функциональность и к которой легко было бы написать отдельный front-end (xine именно так устроен, у него всё внутри xine-lib, а сам xine - всего лишь front-end). Но в принципе именно эту конкретную возможность можно было бы написать в виде фронт-энда командной строки даже (запустить mplayer один раз с опцией -v и нулевыми выходами, проанализировать размер картинки и проч., и составить правильную строку).
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: mikser
2005-09-23 06:53 pm
А почему бы разработчикам об этом не написать?
(Ответить) (Thread)
[User Picture]From: breqwas
2005-09-23 08:07 pm
Дык пошлют нах. И будут по-своему правы.
Но именно поэтому я, зная и очень уважая Linux, пишу эти строки из-под WinXP.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: tymofiy
2005-09-23 07:06 pm
Спасибо! в меморис.
(Ответить) (Thread)
[User Picture]From: izobr
2005-09-23 07:53 pm
Вспомнил как в промежутке между смертью старого винчестера и покупкой нового смотрел кино в Knoppix'е жонглируя дисками... Даже к одному фильму виндовые кодеки с другого диска устанавливал. Вот не помню только было ли у меня тогда два CD-ROM'а или мне удавалось отмонтировать сам диск с Knoppix'ом, короче для совсем нелинуксоида ещё это был ещё тот скилл!
(Ответить) (Thread)
From: (Anonymous)
2005-09-23 08:39 pm
Бли, вот только вчера с этим парился! В моём случае ситуация омрачается тем, что у монитора выставлено не вполне стандартное разрешение: 1280x1024, которое не соответствует пропорциям экрана (обычные четыре к трём). Мплеер (умный, зараза) это знает (кстати, интересно - откуда?) и автоматически перемасштабирует картинку, слегка растягивая по высоте, дабы сохранить натуральные пропорции. Так вот это самое масштабирование значительно затрудняет вычисление Нужных Цифирок...
(Ответить) (Thread)
[User Picture]From: vvyy
2005-10-04 11:09 am
Интересно вообще, какого он её перемасштабирует, когда значительная и я подозреваю, что бóльшая часть мониторов с таким разрешением — LCD, для которых никакого перемасштабирования для этого разрешения не требуется
(Ответить) (Parent) (Thread)
[User Picture]From: _slw
2005-09-23 09:25 pm
Я так понимаю, что воспользоваться -subpos не дает коран?
(Ответить) (Thread)
[User Picture]From: avva
2005-09-23 09:36 pm
Я так понимаю, что воспользоваться -subpos не дает коран?

Вы просто не въезжаете в тему. Без -vf expand никакой -subpos не поможет, потому что простор его выбора от 0 до 100 простирается полностью внутри картинки, не выходя за её пределы. А если уж приходится делать -vf expand, то -subpos обычно и не нужен, т.к. по умолчанию субтитры пойдут в самый низ.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: lz
2005-09-23 10:06 pm
Кто не разбирается в компьютерах, запустит по совету хорошего друга под виндой Light Alloy в связке с ffdshow и забудет навсегда про проблемы с кодеками и субтитрами
(Ответить) (Thread)
[User Picture]From: aburachil
2005-09-23 11:06 pm

Ну ни фига ж себе...

"Программа xine это делает сама по умолчанию. Тут всё очень просто: если запустить её и переключить в full-screen режим, она просто начинает писать субтитры в нижнюю часть экрана, а не в нижнюю часть кадра, который стоит посреди экрана; и всё отлично"

Интересно излагаете, однако. А вот у меня она ни фига подобного не делает (хоть ксиня и довольно новой версии) --- субтитры остаются где были. А о каких субтитрах Вы говорите? Я о тех, которые в покупных дивидюшках.
(Ответить) (Thread)
(Удалённый комментарий)
[User Picture]From: eterevsky
2005-09-24 06:37 am
Меня в mplayer'е (я пользуюсь им из под WinXP) раздражает то, что в нём не сделана на данный момент нормальная поддержка ssa-субтитров, в которых прописан стиль и позиция титров в кадре.
(Ответить) (Thread)
[User Picture]From: bespechnoepero
2005-09-24 12:23 pm
Уважение к пользователю - это то, чего нет у создателя Линукс и всех сторонников этой программы. Поэтому почти все и пользуются Виндами.
(Ответить) (Thread)
From: temcat
2005-09-24 02:42 pm
All sweeping generalizarions are wrong :-)
(Ответить) (Parent) (Thread)
[User Picture]From: jerom
2005-09-24 06:48 pm

спасибо, интересно

А может всё-таки написать им?
(Ответить) (Thread)
[User Picture]From: avva
2005-09-28 08:20 am

Re: спасибо, интересно

Да бесполезно. В случае mplayer'а.
(Ответить) (Parent) (Thread)