Каскадный · [ Стандартный ] · Линейный+ Еще один информационник - MKInfo, (обновлено 3 июня 2012 г., версия 1.0.12 beta)

[19w85]

2 19w85:
В твоем примере на самом деле (если верить MediaInfo) 24 аудиотрека и 32 субтитровых. Я искусственно ограничиваю максимальное количество треков до 20 для аудио и субов и до 10 для наборов чаптеров. Вот не думал что делают таких монстров как этот. Не проблема увеличить лимит до 50.

Не, у меня нет таких монстров (ну а лимит на количество треков, думаю если и стоит увеличивать, то только если это не сказывается на быстродействии программы). Этого монстра я искусственно создал, многократно добавляя одни и те же дороги через mkvmerge. Мне просто хотелось посмотреть, как будут влезать названия этих переключателей, когда цифры треков двузначные. Типа "Audio 11 / 20"
==============================================
И вот еще что, мне кажется было бы нагляднее видеть сразу количество потоков, не раскрывая список, а то, например, отображается "Audio 3" и непонятно есть ли еще дорожки на которые стоит переключить или нету.
Хотелось бы в таком случае в названии видеть "Audio 3 / 4", а еще лучше формат поменять на "Audio 3 (4)"...просто обычно в скобках отображают общее количество, это и привычнее и визуально более понятно.

[starsoft]

2 19w85: Ну так если бы не твой масшаб ты бы увидел что так и есть - в поле комбо-бокса показывается то же, что и в списке "Audio N / NN". А в скобках или через дробь - нет правил, дело вкуса. Могу и поменять - мне пофиг.

[19w85]

А в скобках или через дробь - нет правил, дело вкуса.

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

Могу и поменять - мне пофиг.

Было бы отлично, в скобках легче воспринимать при беглом взгляде.

[c930]

starsoft
А портабл ссылку можно тоже обновить?

[starsoft]

2 c930: Можно, тока уже завтра Хотя портабл каждый может себе сделать - просто взять 2 файла (exe и dll) из проинсталлированной проги.

[c930]

Теперь у менЯ текст в поле Frame size не помещается (для анаморфных видео):



Предлагаю левую колонку расширить на необходимую ширину за счёт правой (Size и FPS), там вроде запас ширины имеется.
В основном GUI окно масштабируется, там не так критично, а в альтернативном нет.

Информацию по типу развертки... добавлю, но не на основную панель, а в Additional Video Info

Жалко, этим уж я точно не буду пользоваться, весь смысл теряется, только в случае единовременной необходимости для конкретного файла. Проще уж MediaInfo запустить будет, хотя его представление мне не нравится. Да ещё он гад размер окна не запоминает.

ассоциировать в TotalCommander-е для желаемых типов файлов на кнопку Alt+F3...

starsoft, а ты сам пользуешься TotalCommanderом?
А то давно уж хотел у тебя спросить - как на счёт написать плагины соответствующие, типов WDX и WLX.
Было бы удобно при работе с множеством файлов.

[19w85]

Теперь у менЯ текст в поле Frame size не помещается (для анаморфных видео):

Приятно, что и при обычном масштабе может что-то не влезать
Скачал эти файлы, которые на скринах (для семплов тяжеловаты по размеру, пары секунд бы хватило) и проверил как у меня не влезает, практически точно также, ни лучше, а главное не хуже:
http://s002.youpic.su/pictures/1316030400/...8cef82f8f11.png
http://s002.youpic.su/pictures/1316030400/...f64036dafeb.png

Предлагаю левую колонку расширить на необходимую ширину за счёт правой (Size и FPS), там вроде запас ширины имеется.

А я предлагаю не урезать поля Size и FPS, а урезать ширину бесполезного разделяющего интервала между концом поля "Frame size" и надписью "FPS".

[starsoft]

2 c930: У тебя же нет проблем с масшабом-размером, почему ты пользуешься альтернативным gui? пользуйся основным и растягивай окно в стороны до нужных размеров - все поля и будут видны.

как на счёт написать плагины соответствующие, типов WDX и WLX

Так а зачем? Вписываться в lister со всеми его ограничениями не вижу смысла - и по Alt+F3 работает прекрасно, зато не мешает какому-нибудь play-плагину для листера проиграть файл. А контентный плагин - я честно говоря и не пользуюсь такими, по мне кроме мульти-переименования его и пользовать негде. А для этого инфа должна выглядеть гораздо компактней и, значит, менее читаемой. И тут на вкус и цвет у всех разные фломастеры.

Скажи - а по чему для тебя так важен тип развертки? Мне кажется что 99% файлов матрешки всегда в прогрессиве, а редкие исключения (сделанные камкодерами) и так понятно что интерлейсные. Из этой логики я и выкинул инфу в "дополнительную" - если нужно убедиться, то не лень нажать на меню.

[xfiles]

Мне кажется что 99% файлов матрешки всегда в прогрессиве, а редкие исключения (сделанные камкодерами) и так понятно что интерлейсные.

Ну, на самом деле, не надо забывать о записях потока со спутника и иных цифровых TV трансляциях, которых с каждым днем становиться все больше и больше.

[19w85]

2 c930: У тебя же нет проблем с масшабом-размером, почему ты пользуешься альтернативным gui? пользуйся основным и растягивай окно в стороны до нужных размеров - все поля и будут видны.

Хм, а зачем отсылать на дефолтовый gui? Альтернативный gui получился просто замечательный.
Полагаю, так же как и я, человек оценил, что видеть сразу три аудио-дороги, гораздо удобнее, чем одну Даже если вопрос с масштабом не стоит.

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

[starsoft]

а в чем проблема уменьшить этот самый интервал между полями, который я предлагал выше

Потому что этого все равно не хватит чтобы всегда вместить информацию по анаморфу.

[19w85]

а в чем проблема уменьшить этот самый интервал между полями, который я предлагал выше

Потому что этого все равно не хватит чтобы всегда вместить информацию по анаморфу.

Пространство этого интервала между полями очень большое, оно запросто покроет невлезающие 3 цифры из самого худшего варианта приведенного выше, т.е. для:

1074x496 (2.2:1) @ 688x496

Самый наиширокий вариант анаморфа (все-все цифры разрешения 4х-значные) в этом найденном мною примере:


Если интервал между полями почти убрать, то всего лишь чуть-чуть придется урезать ширину поля FPS, чтобы влез даже 4х-значный вариант.
Семпл 4-значного примера: http://multi-up.com/557988

P.S. Еще предлагаю убрать ненужные пробелы до и после @
Тогда вообще возможно можно будет обойтись одним лишь уменьшением интервала.
Инфа по анаморфу нужна, и та капля что не влезает, её тут запросто можно уместить, т.к. места и вариантов тут просто вагон. Это даже на глаз видно.
=============================================
Только сейчас заметил...а почему идет анаморфированное разрешение на 1ом месте?
Должно же быть "Реальное разрешение@Анаморфированное". Потому что логично именно так, фейковому разрешению не место в самом начале строки.

[c930]

для семплов тяжеловаты по размеру, пары секунд бы хватило

Сколько starsoft просил отщипнуть, столько и отрезал. Мне не жалко.

А я предлагаю не урезать поля Size и FPS, а урезать ширину бесполезного разделяющего интервала между концом поля "Frame size" и надписью "FPS".

Разделяющий интервал не бесполезный, он необходим! Также как и отступы (по возможности) внутри поля спереди и сзади информации. Для хорошего зрительного восприятия, чтоб GUI гармонично выглядел. Отступы в полях Size и FPS имеют большой запас, их бы я и сократил (не до нуля конечно) в первую очередь и расширил левую колонку. Ну а уж если не хватит всё равно места, то уж тогда интервал между колонками стал сокращать, информация важнее. Если starsoft вдруг надумает изменять ширину, то надеюсь что он сделает чтоб всё было сбалансировано.

+ Предлагаю также в поле Size области General Information число, означающее размер файла в байтах (что в скобках) выводить с разделителями (пробелом) меду триадами разрядов, для лучшего восприятия. Запас места есть.
Т.е вместо (12586325147 bytes) сделать так: (12 586 325 147 bytes).

+ Ещё: в сокращённых единицах измерения байты обозначить заглавной буквой, т.е. B, MB, а биты - строчной (в общем как сейчас Mbps, kbps).
Чтобы путаницы не было.

+ А также добавить пробел между значением параметра и единицами измерения (там где отсутствует).

Еще предлагаю убрать ненужные пробелы до и после @

Не согласен по вышеупомянутой причине (для лучшего восприятия), по возможности хотелось бы оставить. Тем более, что в правой колонке запаса места хватает.

Только сейчас заметил...а почему идет анаморфированное разрешение на 1ом месте?Должно же быть "Реальное разрешение@Анаморфированное". Потому что логично именно так, фейковому разрешению не место в самом начале строки.

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

У тебя же нет проблем с масшабом-размером, почему ты пользуешься альтернативным gui? пользуйся основным и растягивай окно в стороны до нужных размеров - все поля и будут видны.

Альтернативный мне больше нравится: одновременно выводится больше нужной информации, не нужно щёлкать переключателями - всё под рукой.
Кроме того размер окошка стабилен, все поля имеют своё неизменное местоположение - при сравнении разных видеофайлов удобно. Ничего не прыгает.

по Alt+F3 работает прекрасно, зато не мешает какому-нибудь play-плагину для листера проиграть файл.

А я не пользуюсь (как показала практика) плагинами для просмотра видео. Недавний опрос Какой плагин просмотра видео вы предпочитаете использовать?, на который я наткнулся на сайте командера, в поисках того какие сейчас есть WDX плагины для видео (прежде чем закинуть удочку тебе) подтверждает, что и многие не пользуются. Хотя возможность м.б. полезна для просмотра кучи мелких видеофайлов в режиме Quick view. Но она никуда не денется, можно ведь плагины переключать, или их приоритет.

А информационным листер-плагином удобно было бы пользоваться, на мой взгляд, в том же режиме Quick view: в одной панели у тебя список видеофайлов (которые можно при необходимости отсортировать и отфильтровать средствами командера), а в другой инфо, наподобие как в GUI сабжа. Перемещаешься по файлам и смотришь параметры - на мой взгляд очень удобно. В GUI сабжа конечно тоже можно листать файлы, но он их как-то сам выбирает. В каком порядке. В командере всё гораздо удобнее было бы.

А контентный плагин - я честно говоря и не пользуюсь такими, по мне кроме мульти-переименования его и пользовать негде.

Ответ под спойлером!

Для мультипереименования я WDX-плагинами не пользуюсь (ничего не имею против, просто на практике пока не требовалось). А WDX-плагин хотелось бы для использовании инфо в пользовательских колонках. Для просмотра параметров кучи файлов удобно. Опять же гибкость настройки видов отображения. Плагин может выдавать кучу всевозможных параметров видео, а ты выбрал только необходимые (даже для данной конкретной задачи) или всего один-два нужных параметра.
Например нужно мне найти файлы с чересстрочной развёрткой в дереве каталогов. Я создал пользовательскую колонку с этим параметром, нажал CTRL+B или CTRL+SHIFT+B для показа всех файлов в дереве или в выбранных подкатарогах, отобразил эту колонку - опа, всё видно. Можно по этой колонке отсортировать и все необходимые файлы будут рядышком. В последних версиях командера можно по двум колонкам (возможно нескольким) сортировать. Например, вывел колонки Тип развёртки и Вертикальное разрешение, отсортировал по ним - и вот у тебя рядышком все видеофайлы с определённым типом развёртки и отсортированные по вертикальному разрешению.

А сейчас мне чтоб найти, например, видеофайлы с чересстрочной развёрткой нужно вручную все файлы перебрать, для каждого слазить в меню Options затем в подменю Additional Video Info, закрыть подменю... Короче загнёшся.

Или вот более расширенный пример и другое использование WDX-плагина:
нужно такие файлы найти в разных каталогах на разных дисках.
- Лезем в сервис Поиск файлов,
- в поле Место поиска указываем пути (в простейшем случае - имена логических дисков),
- задаём маску, например, *.mkv,
- на вкладке Плагины ставим галку Поиск с плагинами, выбираем наш плагин и нужные параметры, например:
Тип развёртки - Чересстрочная, Вертикальное разрешение > 720 (параметры можно объединять логически).
- Ждём результатов поиска, и вот на панели имеем все искомы файлы.
Их можно дополнительно отсортировать, например по тому же разрешению или др. параметру с помощью этого же плагина, выведя нужный параметр в пользовательскую колонку.

А на др. панели можно с помощью WLX-плагина смотреть параметры более подробно для конкретного файла в режиме Quick view. Ну или делать что угодно, например слить файлы на др. носитель.
Главное необходимые файлы найдены, что и требовалось в данном случае.
Это просто пример как можно использовать WDX-плагин.

P.S. Вот только плагинов то нет в наличии.

...Мне кажется что 99% файлов матрешки всегда в прогрессиве, а редкие исключения (сделанные камкодерами) и так понятно что интерлейсные.

В общем так, но много исключений думаю. С камкордеров вроде бывают и в прогрессиве, встречал такое.
Всякие демонстрационные видео с дисков с разным типом расвёртки бывают.
Даже вот кроме вышеупомянутых двух типов MediaInfo различает такие подвиды как PAFF и MBAFF.
Опять же, как справедливо заметил xfiles, полно всяких "спутниковых и иных цифровых TV трансляций, которых с каждым днем становиться все больше и больше". Там тоже разные типы развёртки встречаются.

Скажи - а по чему для тебя так важен тип развертки?...

Не знаю, параметр Тип развёртки мне более интересен (другие параметры из подменю Additional Video Info мне не интересны, я даже не знаю что большинство означает) гораздо больше тех же чаптеров, которые меня не интересуют практически, даже я плохо представляю что это и зачем. Видимо метки в файле для позиционирования при просмотре на "железном" плэере, но я компьютером воспроизвожу. Тем не менее я не против наличия такого поля, пусть будет.
Но я бы сократил его на одну строчку ради параметра Тип развёртки.
Тем более я раньше предложил как сэкономить эту одну строчку, но её использовали для другого :-(.
Вообще у меня нет пока проблемы с размером GUI альтернативного.

[19w85]

Разделяющий интервал не бесполезный, он необходим! Также как и отступы (по возможности) внутри поля спереди и сзади информации. Для хорошего зрительного восприятия, чтоб GUI гармонично выглядел. Отступы в полях Size и FPS имеют большой запас, их бы я и сократил (не до нуля конечно) в первую очередь и расширил левую колонку. Ну а уж если не хватит всё равно места, то уж тогда интервал между колонками стал сокращать, информация важнее. Если starsoft вдруг надумает изменять ширину, то надеюсь что он сделает чтоб всё было сбалансировано.

Интервал между колонками просто пустое место, никак неиспользующееся и ничего не дающее. Даже если его убрать полностью, то того места, на котором находится надпись " FPS : " в качестве разделителя столбцов более, чем достаточно. А вот отступ в самих полях со значениями более полезен, именно поэтому я и предлагал уменьшать его во вторую очередь.

Т.е вместо (12586325147 bytes) сделать так: (12 586 325 147 bytes).

Если так сделать, то от текущих отступов мало что останется (соотвественно, оттуда трудно будет заимстовать, хотя пока не ясно много ли вообще нужно от них позаимстовать). Для начала хотелось бы, чтобы вся инфа влезала, а пробелы - это уже роскошь.

А также добавить пробел между значением параметра и единицами измерения (там где отсутствует).

Это поддерживаю

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

Ага, и в итоге на одном и том же месте, например, имеем цифры 1920x1080 (и для настоящих 1920x1080 и для анаморфных 1440x1080). И если не приглядываться к продолжению @ то можно и не заметить анаморф. Нигде такой путаницы не встречал. Чем ТАК, уж лучше бы вообще разрешение анаморфа не отображалось.

Видимо метки в файле для позиционирования при просмотре на "железном" плэере, но я компьютером воспроизвожу.

На компьютере все видно, например, если сплиттер haali используется, то правой кнопкой мыши на его иконке в трее, и видны все названия глав. Честно говоря именно названия мне лично никогда не пригождались, а вот переход вслепую с одной главы на другую следующую/предыдущую гор. клавишами (когда главы есть) использую иногда.

Тип развёртки мне более интересен гораздо больше тех же чаптеров

Но я бы сократил его на одну строчку ради параметра Тип развёртки.

Я тоже "за" сокращение на одну строчку поля чаптеров ради "Типа развертки".
Или может можно "вписать" окошко с "типом развертки" над переключателем "menu", а его сместить пониже.

[c930]

Интервал между колонками просто пустое место, никак неиспользующееся и ничего не дающее. Даже если его убрать полностью, то того места, на котором находится надпись " FPS : " в качестве разделителя столбцов более, чем достаточно.

Нет, какой-то интервал нужен всё равно.

А вот отступ в самих полях со значениями более полезен, именно поэтому я и предлагал уменьшать его во вторую очередь.

Отступы нужны безусловно, но менее чем интервал. И в критическом случае я бы их уменьшил до нуля ради минимального интервала перед FPS :.
Обоснуй чем тебе отступы более важны. А так голословно.
На мой взгляд поле может обойтись и без отступов, хотя это и не есть гуд. Оно всё ж выделено рамкой.
А вот если перед FPS : не будет интервала, от он будет прилежать к левой колонке, а двоеточие после него будет создавать зрительный интервал - это будет очень плохо выглядеть. Нужен интервал ДО заметно больший чем двоеточие занимает.

Т.е вместо (12586325147 bytes) сделать так: (12 586 325 147 bytes).

Если так сделать, то от текущих отступов мало что останется (соотвественно, оттуда трудно будет заимстовать, хотя пока не ясно много ли вообще нужно от них позаимстовать).

Да вроде там то полно запаса.

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

Ага, и в итоге на одном и том же месте, например, имеем цифры 1920x1080 (и для настоящих 1920x1080 и для анаморфных 1440x1080). И если не приглядываться к продолжению @ то можно и не заметить анаморф. Нигде такой путаницы не встречал. Чем ТАК, уж лучше бы вообще разрешение анаморфа не отображалось.

Я не против разнести их в разные поля, но выходное (результирующее) разрешение вперёд (или выше).

а вот переход вслепую с одной главы на другую следующую/предыдущую гор. клавишами (когда главы есть) использую иногда.

А для чего это вообще? Для каких-то специфических видео с ярковыраженными главами?

Или может можно "вписать" окошко с "типом развертки" над переключателем "menu", а его сместить пониже.

Так будет нелогично, т.к. параметр относится к области Video Stream.

[19w85]

Отступы нужны безусловно, но менее чем интервал. И в критическом случае я бы их уменьшил до нуля ради минимального интервала перед FPS :.Обоснуй чем тебе отступы более важны. А так голословно.

Отступы в самом поле, помогают легче различать цифры в этом самом поле, т.е. "FPS:цифры" не сливается в кашу, а значение "цифр" обрамлено пробелами с двух сторон.

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

Интервал ДО небольшой естественно нужен. Сейчас он наверно раз в 5 раз длиннее, чем нужно.

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

Ага, и в итоге на одном и том же месте, например, имеем цифры 1920x1080 (и для настоящих 1920x1080 и для анаморфных 1440x1080). И если не приглядываться к продолжению @ то можно и не заметить анаморф. Нигде такой путаницы не встречал. Чем ТАК, уж лучше бы вообще разрешение анаморфа не отображалось.

Я не против разнести их в разные поля, но выходное (результирующее) разрешение вперёд (или выше).

Суть не в том, чтобы что-то куда-то разносить, а в том, что оригинальное (реальное) разрешение должно быть ВСЕГДА в одном месте для ВСЕХ файлов (обычных и анаморфных), дабы не было путаницы и не приходилось каждый раз тщательно высматривать файл на предмет анаморфа, чтобы не ошибиться с разрешением из-за такой рокировки. А куда деть побочное фейковое анаморфированное разрешение не так важно, это доп. инфа, к тому же не особо существенная, т.к. показывает не реальный параметр файла, а "виртуальный". К тому же при анаморфировании из меньшего разрешения получается большее, и логично, что это должно идти справа налево, а не как сейчас - наоборот, от большего к меньшему.

Да вроде там то полно запаса.

Не полно. На моем последнем скриншоте не влезало 5,5 знаков. На урезании интервала между стобцами можно съэкономить 3-4 знака. Т.е. еще 2 знака надо выиграть за счет сокращения уже отступов. Не знаю, останется ли там место под доп. пробелы (если останется, я только "за" пробелы-разделители групп цифр)

Так будет нелогично, т.к. параметр относится к области Video Stream.

Вообще говоря логичнее всего тут было бы в случае интерлейса дописывать к разрешению букву "i". По типу 1080i. Если такое возможно.
Потому что интерлейса все-таки относительно очень мало. И отдавать под него отдельное поле (которое в большинстве случаев а альтернативном GUI будет присутствовать и пустовать) - очень плохо.

А для чего это вообще? Для каких-то специфических видео с ярковыраженными главами?

...

Для обычных фильмов. Допустим по ходу просмотра понадобилось пересмотреть (допустим уточнить) уже прошедший фрагмент в начале фильма, пара нажатий, и попадаешь куда нужно. (если под рукой мышь, то ей может и тоже быстро это сделать, но я во время просмотра пользуюсь только пультом ДУ для ПК)

[c930]

Суть не в том, чтобы что-то куда-то разносить, а в том, что оригинальное (реальное) разрешение должно быть ВСЕГДА в одном месте для ВСЕХ файлов

Суть в том, что ты считаешь определяющим разрешение анаморфного кадра и соответственно сопостовляешь ЕГО с разрешением кадра в обычном фильме.
А я считаю определяющим в анаморфном видео (не с точки зрения разрешения как такового естественно, а с той позиции, какого размера кадр мы увидим в результате на экране) - выходное растянутое. И именно его и ставлю в соответствие. А разрешение анаморфного кадра считаю второстепенным параметром (в данном случае).
В этом мы и не сходимся, отсюда и спор.

В конце концов размер кадра в пикселах лишь приблизительно определяет разрешающую способность кадра (ограниченее сверху, так сказать). Так как во множестве видеоконтента разрешение дутое в той или иной степени.
В этом смысле разрешение анаморфного кадра ещё более не является основополагающим.
А результирующее - вот оно, на экране. Можно его пощюпать :-).

Вообще говоря логичнее всего тут было бы в случае интерлейса дописывать к разрешению букву "i". По типу 1080i. Если такое возможно.

Это будет очень закамуфлировано, не заметно.
Потом 1080i, 720i это уже стандартные обозначения для HD и не определяют разрешение по вертикали в чистом виде, а лишь тип развёртки. Если мы напишем, например 800i или 560i, это будет попахивать какой-то отсебятиной.
Кроме того MediaInfo различает, как я писал выше, и выдаёт в этот параметр всякие подвиды типа PAFF и MBAFF.

Потому что интерлейса все-таки относительно очень мало. И отдавать под него отдельное поле (которое в большинстве случаев а альтернативном GUI будет присутствовать и пустовать) - очень плохо.

Мало может только среди фильмов, но не видео вообще, там много.
Пустовать не будет, там будет указан тип развёртки.

[starsoft]

+ А также добавить пробел между значением параметра и единицами измерения (там где отсутствует).

А в каких полях он отсутствует?

Чтобы закончить прения по поводу представления анаморфа выскажу свою точку зрения. Поскольку программа дает информацию о файле, то первыми цифрами идут размер фрейма в исходнике, то есть в файле. А результирующее анаморфное значение действительно чисто умозрительное и дано только для ориентировки в рельных пропорциях результата при просмотре - для того чтобы его получить нужно смотреть в окне при неизменном вертикальном размере. А окно плеера может быть растянуто/сжато, а то и вообще просмотр в полноэкранном режиме - короче выходная резолюция зависит от плеера и резолюции экрана при соблюдении им пропорций анаморфа.

Мнения по разерам/положении полей я тоже понял, результат увидите в следующей версии в ближайшее время

А для чего это вообще? Для каких-то специфических видео с ярковыраженными главами?

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

[19w85]

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

[c930]

А в каких полях он отсутствует?

В полях (общий и видео) Bitrate, но только когда параметр выражен в Mbps.
Когда в kbps - имеется.

starsoft, а чем ты руководствуешься при выборе цвета шрифта значений параметров?
Вроде текстовые окрашены в синий, но не все. Какие-то в зелёный, какие-то в чёрный.
Их важностью что ли? Цветовая дифференциация по важности?

Это заметно даже при обычном масштабе...

Действительно! А я вот не замечал раньше, пока ты не сказал :-).

+ Нашёл ещё источник экономии места :-) - двоеточие не должно отделяться пробелом (по правилам пунктуации) от предшествующего ему слова.
А у нас во всех названиях полей отделено.

- Серьёзный глюк обнаружил: на файлах размером больше 4 гиг неправильно отображается размер файла в байтах (что в скобках).

Отредактировано: c930 в Суббота, 17 Сентября 2011, 5:42