Как сделать скриншоты оригинального размера с видео

Немаловажным в каждой видеораздаче является наличие скриншотов, причем не просто каких-то снимков с раздаваемого видео видео, а именно видео-кадров в оригинальном разрешении. То есть если фильм по характеристикам имеет разрешение 640х480, то и скриншот должен быть такого же размера, а не 512х384. Или если разрешение в DVD-Video 720х576, то скриншоты не должны быть 768х576 или какими-то иными, а должны быть именно 720х576. Исключение составляют DVD, в которых видео для экономии места сжато по ширине. Стандарт DVD-Video допускает разрешение 352х576 для PAL и 352х480 для NTSC. В этом и только в этом случае можно выложить скалированные скриншоты, которые будут 704х576 или 704х480 соответственно. Хотя можно выложить и оригинальные кадры видео, это не имеет значения, хотя оригинальные будут смотреться непрезентабельно.

Итак, как сделать скриншот оригинального размера? Я рассмотрю здесь пока 2 способа, впоследствии, возможно, добавлю другие.

Спасибо. Подскажите, пожалуйста, доступно как их размещать на роздаче.

Я уже попробовал. Кажется что-то получилось

Проще всего сделать скрины с помощью VLC плеера.
Даже с субтирами.
Проще пареной репы!

С DVD-Video, возможно, поскольку на трекере допускаются для DVD анаморфные скриншоты вместо оригинальных, а VLC Media Player делает именно такие. А вот для анаморфных рипов такие скриншоты допустимы только в качестве альтернативы, в дополнение к оригинальным,чтобы показать пользователям реальное отображение видео. Это связано с тем, что анаморфирование в MPEG-4 может быть каким угодно, поскольку он не связан жесткими ограничениями по картинке и зависит от обрезки при рипе, масштабирования и т.д. Приведу простой пример. Если с PAL все более или менее понятно многим, то с NTSC даже на DVD ситуация с анаморфированием несколько другая, например, многие впадают в ступор, увидев там оригинальное разрешение картинки 480х480 (4:3), которое при отображении растягивается до 640х480. Но даже если взять стандартный вариант 720х480 16:9. При воспроизведении плеер автоматом растянет картинку до 854х480, обеспечив нам аспект 16:9. VLC Media Player сделает скриншот именно такого размера, и для DVD он подойдет. А вот если мы при рипе сделали обрезку? Одно дело, когда мы режем черные полосы сверху и снизу, то есть по вертикали, то может получиться картинка 720х448, которая растянется до тех же 854х448 (правда, тут неясно. а был ли применен ресайз картинки до кодирования, в этом случае анаморфирование может быть другим), а другое дело, если мы режем по ширине. Есть у меня один рип с диска NTSC, картинка там 704x352, а вот растягивается она до 836x352. В случае воспроизведения такого видео VLC Media Player сделает скриншоты 836x352, а как можно проверить их корректность? Опять же ведь неизвестны параметры фильтров постобработки, накладываемых на материал. Поэтому в случае с рипами оригинальные скриншоты, соответствующие размеру картинки, обязательны и первичны, а вот уже анаморфные вторичны и необязательны, хотя, конечно, для видео с аспектом 16:9 желательны. Поэтому я бы не сказал, что проще пареной репы. К тому же совсем недавно проводил небольшой тест, как раз-таки связанный с аспектом. Вот, казалось бы, с одной стороны, VLC Media Player - свободная и развивающаяся разработка, в которой появляются новые функции и усовершенствуются старые. С другой стороны, у нас есть формат контейнера AVI, который вопреки всем предсказаниям о его скорой "смерти" до сих пор остается одним из самх популярных, как и 11-12 лет назад. Уже довольно давно четко утвержден формат надстройки OpenDML AVI. Одной из его особенностей является то, что соотношение сторон может записываться в vprp-заголовок OpenDML. Это сделано для тех случаев, когда аспект отсутствует в видео-потоке, то есть PAR там равен 1:1, это так называемые неанаморфные рипы или же когда в исходнике аспект неверен. Такое можно встретить даже на лицензионных DVD, где на рде фильмов видео умышленно кодируется с соотношением 4:3, а в IFO-файл пишется правильный аспект - 16:9. Программы для автоматического рипования считывают аспект из VOB-файлов и кодируют фильм с аспектом 4:3, что приводит к совершенному искажению картинки, в то время как плееры, следуя спецификации, считывают аспект из IFO-файла и автоматом корректируют отображение в соответствии с прочитанным оттуда. Так вот VLC Media Player, к моему великому удивлению, напрочь игнорирует OpenDML vprp-заголовок. В подавляющем большинстве случаев аспект из vprp-заголовка не так уж и нужен, поскольку аспект находится в видеопотоке, а если его там нет, то видео воспроизводится с размерами сторон, какие указаны в обычном заголовке, то есть по картинке. Правда, в этом случае мы можем наблюдать небольшое искажение соотношения сторон, вызванное тем, что округление ширины/высоты до значений, кратных 16, несет в себе небольшую погрешность. Плееры, которые считывают vprp-заголовок, автоматом корректируют аспект, расширив видео на несколько пикселей. На глаз они особой роли не играют. Но бывают и другие ситуации, когда берется рип с изначально некорректным соотношением сторон, затем кем-то исправляется без перекодирования на корректное соотношение сторон, которое пишется в vprp-заголовок. Что получается? Видео-поток остался тот же, значит, и неверный аспект там тоже присутствует. Плеер, проигнорировавший vprp-заголовок, воспроизведет файл, как будто бы его и не меняли. И только плеер, считавший значение, записанное в vprp-заголовке, автоматом скорректирует картинку так, как надо, обеспечив нам комфортный просмотр и избавив от копания в настройках при просмотре, что надо выставить такой или такой аспект при воспроизведении того или иного файла.

Я вовсе этим не хочу сказать, что VLC Media Player надо выкинуть на помойку и отказаться от него. У меня тоже его портабельная версия стоит. Правда, вот, вышеупомянутое, плюс проблемы с AAC-звуком, а также в одном из тестов на корректность отображения как раз одного из DVD, где видео-файлы были закодированы с соотношением сторон 4:3, а в IFO-файле был прописан правильный аспект 16:9, обратил внимание, что плеет кушает в среднем 25-27% ресурсов процессора, тогда как остальные участники тестов забирали, как надо - 3-7% ресурсов процессора. Впрочем, это уже совершенно другая тема. Касательно скриншотов все сказал выше.

Academic Crack Спасибо за информацию!