Грамотный кодинг видео в Linux

Вопросы, приемы и проблемы обработки видео

Модератор: Модераторы разделов

Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
13.04.2008 05:15
Странно. Выглядит как проблемы при установке аудио настроек. Можно ли выбрать vorbis после загрузки видео файла?

Да. Более того - его можно выгрузить с этим форматом без проблем.
Спасибо сказали:
Аватара пользователя
Nerr
Сообщения: 65

Re: Грамотный кодинг видео в Linux

Сообщение Nerr »

И еще вот вопрос. Avidemux2 показывает в топе 177% CPU, а mplayer максимум 99%
-lavdopts threads=2 пробовал, без изменений
Проц Prescott (гипертрединг), ядро linux smp
моежет такое быть что mplayer не выжимает все из проца? или выдается неправильную инфа в топ?
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

MAA писал(а):
13.04.2008 11:39
Идет преобразование в 50p с уменьшением вертикального разрешения в половину. Выполняются фильтры/ресайзы и пр. Затем 50p интерполируется обратно.
Это осложняет работу кодека, и возможно ему понадобится больше времени для обработки. Но почему от этого размер должен страдать, мне не понятно...

768x576@25fps и 768x288@50fps очень разные вещи с точки зрения сжатия.
MAA писал(а):
13.04.2008 11:39
Да нет, речь не про такие плееры. Речь про самые, что ни на есть обычные плееры, которые вообще деинтерлейсить не будут. А будут выводить черезстрочку на черезстрочный дисплей (телевизор).

Черезстрочных устройств с каждым годом меньше, не вписываются они в цифровую эпоху. Я уже и забыл, когда последний раз черезстрочность на мониторе видел. Сейчас только телевизоры остались и то ненадолго.
MAA писал(а):
13.04.2008 11:39
ps. Может когда-нибудь производители видеокамер откажутся от черезстрочки вообще и будут выпускать, скажем 1920x1080@50p / 1920x1080@25p. Хотите, берите 50p - будет живость, не хотите - береите 25p, будет кинематографический motion blur.
И всем будет жить легче, и людям, и кодекам, и железу

ИМХО все видео камеры давно уже прогресивные и черезстрочность получается либо за счет понижения fps (50->25) либо вообще видео процессором. Сейчас многие производят камеры 30fsp прогресива, что имхо, разумный компромисс для домашнего видео.
MAA писал(а):
13.04.2008 21:08
kreator, что означает двойка? почему Avidemux2

Точно не скажу - давно это было, ещё до того, как я участвовал в разработке. Вторая версия была весьма сырая и скорее всего это было сделано для удобства - можно установить обе, в одно (первой) работать, а вторую тестировать. Изначально проект носил другое название, но не могу вспомнить ...
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT писал(а):
13.04.2008 23:59
kreator писал(а):
13.04.2008 05:15
Странно. Выглядит как проблемы при установке аудио настроек. Можно ли выбрать vorbis после загрузки видео файла?

Да. Более того - его можно выгрузить с этим форматом без проблем.

Покажи мне всё что в консоли остается после падения. На других файлах тоже самое?

p.s. Меня долго не было, что значит "Бывшие модераторы"? И Topper'а что-то не видно ...
Спасибо сказали:
Аватара пользователя
sspphheerraa
Сообщения: 1375
ОС: Gentoo

Re: Грамотный кодинг видео в Linux

Сообщение sspphheerraa »

zxxxc писал(а):
13.04.2008 22:29
avidemux'ом и делаю, но может есть какой более правильный вариант?

"более правильный" это как? :)
делай тем, результат которого тебя устроит
В Avidemux IMHO просто легче.

zxxxc писал(а):
13.04.2008 22:29
Хотя IMHO, стоит ли?
да, 1080p комп не тянет

Понимаешь, компу плевать на разрешение, для него является значимым интенсивность потока передаваемой информации. Если комп не тянет, значит эту интенсивность нужно уменьшить. Можно понижением разрешения, можно просто снижением битрейта. Последнее IMHO лучше.

kreator писал(а):
14.04.2008 05:31
768x576@25fps и 768x288@50fps очень разные вещи с точки зрения сжатия.

Почему? Из-за того, что от снимка к снимку изображение гуляет вверх-вниз на 1 строку, в результате чего сложнее высчитывать P/B кадры?
kreator писал(а):
14.04.2008 05:31
Черезстрочных устройств с каждым годом меньше, не вписываются они в цифровую эпоху. Я уже и забыл, когда последний раз черезстрочность на мониторе видел. Сейчас только телевизоры остались и то ненадолго.
MAA писал(а):
13.04.2008 11:39
ps. Может когда-нибудь производители видеокамер откажутся от черезстрочки вообще и будут выпускать, скажем 1920x1080@50p / 1920x1080@25p. Хотите, берите 50p - будет живость, не хотите - береите 25p, будет кинематографический motion blur.
И всем будет жить легче, и людям, и кодекам, и железу

ИМХО все видео камеры давно уже прогресивные и черезстрочность получается либо за счет понижения fps (50->25) либо вообще видео процессором. Сейчас многие производят камеры 30fsp прогресива, что имхо, разумный компромисс для домашнего видео.

Да, черезстрочки потихоньку умирают. Но все же их еще достаточно.
Что касается видеокамер, то все DV видеокамеры с объектива получают прогрессив 50 fps (60 - американки). А далее из четного кадра отбрасывается нижнее поле, из нечетного - верхнее (в современных HD видеокамерах добавлены еще режимы 25/30(p), нативные, т.е. не "отобранные"). Преобразования действительно делаются уже электроникой. На хоботе даже когда-то один умелец описывал алгоритм перепайки схемы, чтобы убрать это "отбрасывание".
Но дело не в этом. То, что определиться с разверткой надо сразу (как ты ранее говорил) я полностью согласен. Но IMHO вот это "сразу" должно быть еще на этапе съемки. Т.е. если нет жесткого аппаратного ограничения на ширину потока передаваемой информации (а ведь черезстрочку ввели именно из-за таких ограничений), то снимать все в прогрессиве. Худ. фильмы - на кинопленку, с последующим ее покадровым сканированием. Для дома - 30p. ...не могу сказать является ли это компромисом, т.к. еще не приходилось видеть нативные 30p. Теоретически - в полне может быть.
Ну, а если уж снят фильм в черезстрочке, а хочется прогрессива и при этом хорошего качества, то IMHO лучше уж сразу поискать его в HD.
Sspphheerraa
Спасибо сказали:
Аватара пользователя
Nerr
Сообщения: 65

Re: Грамотный кодинг видео в Linux

Сообщение Nerr »

Код: Выделить всё

"более правильный" это как? smile.gif
делай тем, результат которого тебя устроит
В Avidemux IMHO просто легче.

Avidemux пока плохо работает с матрешкой (если кодировать в нее). В частности рассинхронизация звука с изображением.
Спасибо сказали:
Аватара пользователя
sspphheerraa
Сообщения: 1375
ОС: Gentoo

Re: Грамотный кодинг видео в Linux

Сообщение sspphheerraa »

бери mp4
Sspphheerraa
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
14.04.2008 05:43
Покажи мне всё что в консоли остается после падения. На других файлах тоже самое?

У меня по-моему что-то с кодеком vorbis. Оно выгружает но звука нет. Твой пресет падает возможно из-за того что прежде чем кодировать обычно я в фильтрах аудио выставляю mixer в позицию stereo, ибо с no change оно ругается "The number of channels is greater than what the selected audio codec can do. Either change codec or use the mixer filter to have less channels.". В любом случае, могу ли я попросить тебя сделать пресет с audio в позиции copy? Всё равно я звук не очень люблю пережимать ;)
kreator писал(а):
14.04.2008 05:43
p.s. Меня долго не было, что значит "Бывшие модераторы"? И Topper'а что-то не видно ...

То и значит. Срок годности, наверное, кончился. Topper уже очень давно не появлялся тут, что и как с ним я не знаю, мы не особо знакомы были.
Спасибо сказали:
Аватара пользователя
Nerr
Сообщения: 65

Re: Грамотный кодинг видео в Linux

Сообщение Nerr »

MAA писал(а):
14.04.2008 20:35
бери mp4

вот и пакую в mp4, но хотелось бы в матрешку..
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

MAA писал(а):
14.04.2008 16:23
Понимаешь, компу плевать на разрешение, для него является значимым интенсивность потока передаваемой информации. Если комп не тянет, значит эту интенсивность нужно уменьшить. Можно понижением разрешения, можно просто снижением битрейта. Последнее IMHO лучше.

Нанрузка на проц от разрешения зависит гораздо больше, чем от битрейта.
MAA писал(а):
14.04.2008 16:23
Почему? Из-за того, что от снимка к снимку изображение гуляет вверх-вниз на 1 строку, в результате чего сложнее высчитывать P/B кадры?

В большинстве случаев, эффективность сжатия выше при больших разрешениях, так как можно использовать меньшее количество блоков большого размера - можно сглаживать/интерполировать большие куски и векторов движения меньше - ведь блоков меньше.
MAA писал(а):
14.04.2008 16:23
Но дело не в этом. То, что определиться с разверткой надо сразу (как ты ранее говорил) я полностью согласен. Но IMHO вот это "сразу" должно быть еще на этапе съемки. Т.е. если нет жесткого аппаратного ограничения на ширину потока передаваемой информации (а ведь черезстрочку ввели именно из-за таких ограничений), то снимать все в прогрессиве. Худ. фильмы - на кинопленку, с последующим ее покадровым сканированием. Для дома - 30p. ...не могу сказать является ли это компромисом, т.к. еще не приходилось видеть нативные 30p. Теоретически - в полне может быть.

Согласен. Снимать или писать звук в проф целях нужно с максимальным возможным качеством имеющейся технической базы и понижать только перед записью на конечный носитель. Это как минимум позволит уменьшить цифровые потери при каждой промежуточной обработке.
MAA писал(а):
14.04.2008 16:23
Ну, а если уж снят фильм в черезстрочке, а хочется прогрессива и при этом хорошего качества, то IMHO лучше уж сразу поискать его в HD.

Я почти не смотрю мейнстрим, лет семь назад зацепило авторское кино, так и не отпустило :) Там о техническом качестве во многих случаях говорить не приходится: малый бюджет, многие сняты 30-50 лет назад. Хорошо хоть торент спасает, а то коммерсанты либо не возят, либо ценник ломят :(

CnupT писал(а):
14.04.2008 21:38
У меня по-моему что-то с кодеком vorbis. Оно выгружает но звука нет. Твой пресет падает возможно из-за того что прежде чем кодировать обычно я в фильтрах аудио выставляю mixer в позицию stereo, ибо с no change оно ругается "The number of channels is greater than what the selected audio codec can do. Either change codec or use the mixer filter to have less channels.". В любом случае, могу ли я попросить тебя сделать пресет с audio в позиции copy?

Если выгружать только звук без видео, то vorbis не будет воспроизводится, так как в отличие от mp3 его нужно заворачивать в ogg, чего avidemux пока не делает.
Но кодировать многоканальный звук он должен, как и все прочие кодеки в avidemux (исключая mp3/mp2).
Пресет сделал - аудио не трогает вообще. Но всё же покажи вывод консоли после падения, может получится поправить.
CnupT писал(а):
14.04.2008 21:38
То и значит. Срок годности, наверное, кончился.

А я грешным делом подумал, что модерацию отменили :)
Вложения
x264.js.bz2
(441 байт) 36 скачиваний
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
15.04.2008 03:49
Но всё же покажи вывод консоли после падения, может получится поправить.

Не вопрос. Собственно вот:

Код:

[cnupt@linux ~]$ avidemux2_gtk ************************* Avidemux v2.4.1 ************************* http://www.avidemux.org Code : Mean, JSC, Gruntster GFX : Nestor Di , nestordi@augcyl.org Design : Jakub Misak FreeBSD : Anish Mistry, amistry@am-productions.biz Audio : Mihail Zenkov MacOsX : Kuisathaverat Win32 : Gruntster Compiler: GCC 4.2.3 Build Target: Linux (x86-64) User Interface: GTK+ (2.12.9) Large file available: 1 offset Initialising prefs Directory /home/cnupt/.avidemux exists.Good. Using /home/cnupt/.avidemux as base directory for prefs/jobs/... Preferences found and loaded [cpuCaps]Checking CPU capabilities MMX detected 3DNOW detected MMXEXT detected SSE detected SSE2 detected [cpuCaps]End of CPU capabilities check (cpuMask :ffffffff) Registering Encoders ********************* MJPEG encoder registered Xvid-4 encoder registered FFmpeg encoder registered 3 encoder(s) registered [SDL] Version: 1.2.13 [SDL] Initialisation succeeded [SDL] Video Driver: x11 [Locale] setlocale LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8 [Locale] Textdomain was messages [Locale] Textdomain is now avidemux [Locale] Files for avidemux appear to be in /usr/share/locale [Locale] Test: _File Initializing Dithering tables [xvid] Initializing global Xvid 4 [xvid] Build: xvid-1.1.3 [xvid] SIMD supported: (80) /usr/share/themes/Quark/gtk-2.0/gtkrc:742: Unable to locate image file in pixmap_path: "stepper-up-prelight.png" /usr/share/themes/Quark/gtk-2.0/gtkrc:746: Background image options specified without filename /usr/share/themes/Quark/gtk-2.0/gtkrc:782: Unable to locate image file in pixmap_path: "stepper-down-prelight.png" /usr/share/themes/Quark/gtk-2.0/gtkrc:786: Background image options specified without filename /usr/share/themes/Quark/gtk-2.0/gtkrc:822: Unable to locate image file in pixmap_path: "stepper-right-prelight.png" /usr/share/themes/Quark/gtk-2.0/gtkrc:826: Background image options specified without filename /usr/share/themes/Quark/gtk-2.0/gtkrc:862: Unable to locate image file in pixmap_path: "stepper-left-prelight.png" /usr/share/themes/Quark/gtk-2.0/gtkrc:866: Background image options specified without filename Found 19 video encoder Found 9 audio encoder Found 13 Format Directory /home/cnupt/.avidemux/custom exists.Good. Found 1 custom scripts, adding them Menu built The screen seems to be 1024 x 768 px Initializing postproc Deleting post proc updating post proc Enabled type:3 strength:3 Registering Filters ********************* Using dummy audio device Spidermonkey initialized. No crash file (/home/cnupt/.avidemux/crash.js) 594d4441 -> 594d4441 New mpeg index file detected.. opening d2v file : /home/cnupt/video/rip/nge/nge_1-6.vob.idx For file :/home/cnupt/video/rip/nge/nge_1-6.vob Pic :720x480, 29970 fps #Gop :16838 #Img :201692 Creating mpeg PS demuxer main Pid: E0 There was several files, but dont append was forced Simple loading: file: /home/cnupt/video/rip/nge/nge_1-6.vob, size: 7593494528 found 1 files Done Dropping 1 last B/P frames Creating start sequence (14).. 0000 : ...і-.а$.н#.... 00 00 01 b3 2d 01 e0 24 17 ed 23 82 10 10 10 12 0010 : ................ 10 12 16 16 16 16 16 16 1a 18 1a 1a 1a 1a 1a 1a 0020 : ........"""..... 1a 1a 1a 1a 1a 1c 1c 1c 22 22 22 1a 1a 1a 18 18 0030 : .. 1a 1a Image :7471, seqLen : 150 seq 0 0 1 b3 Reordering mpeg frames Renumbered Gop 1 /16838 opening dmx file for audio track : /home/cnupt/video/rip/nge/nge_1-6.vob.idx Creating mpeg PS demuxer main Pid: FF00 There was several files, but dont append was forced Simple loading: file: /home/cnupt/video/rip/nge/nge_1-6.vob, size: 7593494528 found 1 files Done Building index with 16838 sync points Filling audio header Audio index loaded, probing... Probing track:0, pid: 0 pes:0 Syncing on 16384 Sync found at offset 0 Syncing on 16384 Sync found at offset 0 Probing track:1, pid: 0 pes:1 Syncing on 16384 Sync found at offset 0 Syncing on 16384 Sync found at offset 0 DMX audio initialized (403722240 bytes) With 16838 sync point Mpeg index file successfully read The video codec has some extradata (150 bytes) 0000 : ...і-.а$.н#.... 00 00 01 b3 2d 01 e0 24 17 ed 23 82 10 10 10 12 0010 : ................ 10 12 16 16 16 16 16 16 1a 18 1a 1a 1a 1a 1a 1a 0020 : ........"""..... 1a 1a 1a 1a 1a 1c 1c 1c 22 22 22 1a 1a 1a 18 18 0030 : .. ""$ $""""&&( 1a 1a 20 20 22 22 24 20 24 22 22 22 22 26 26 28 0040 : ((00..88:DDS.... 28 28 30 30 2e 2e 38 38 3a 44 44 53 08 08 08 08 0050 : ................ 08 08 09 09 09 09 09 09 09 09 09 09 09 09 09 09 0060 : ................ 09 09 09 09 09 09 09 09 0a 0a 0a 0a 0a 0a 0a 0a 0070 : ................ 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0080 : ...............µ 0a 0a 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 00 00 01 b5 0090 : ..... 14 82 00 01 00 00 Deleting post proc Initializing postproc Deleting post proc updating post proc Enabled type:3 strength:3 [Editor] Duration in seconds: 6729, in samples: 323028640 Decoder FCC: MPEG (4745504D) Searching decoder (720 x 480, extradataSize:150)... using Mpeg1/2 codec (libmpeg2) Initializing MPEG2 decoder 720 x 480 YV12 open called Done checking for B-Frames... Seq found YV12 setup called **********YV12 setup fbuf called : 720 x 480 (0) **********YV12 setup fbuf called : 720 x 480 (1) **********YV12 setup fbuf called : 720 x 480 (2) * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # Mmm this appear to have b-frame... And the index is ok Frames re-ordered, B-frame friendly now :) End of B-frame check Editor :Audio streamer initialized Audio codec: AC3 No accelerated IMDCT transform found [GTK] Changing size to 720 480 [GTK] Changing size to 720 480 [GTK] Changing size to 720 480 ** conf updated ** Spidermonkey compiling "/home/cnupt/.avidemux/custom/x264_vorbis.js"...Done. Spidermonkey executing "/home/cnupt/.avidemux/custom/x264_vorbis.js"...Deleting post proc updating post proc Enabled type:7 strength:5 Adding Filter "2"... Adding Filter "39"... Codec ... [codec]X264 [conf ]AQ=23 [xtra ]188 00 00 00 00 00 00 00 00 00 00 00 00 28 00 00 00 1e 00 00 00 3c 00 00 00 0a 00 00 00 33 00 00 00 04 00 00 00 03 00 00 00 28 00 00 00 19 00 00 00 f4 01 00 00 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 04 00 00 00 10 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ff ff ff ff ff ff ff ff 01 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 33 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a 00 00 00 Codec X264 found Updating codec conf is AQ Codec:x264 h264 encoder Expected :192 got:188 Saving crash file to /home/cnupt/.avidemux/crash.js **Saving script project ** Conf size : 192 *********** BACKTRACK ************** Frame 0: avidemux2_gtk(ADM_backTrack+0x4b) [0x8ef1fb] Frame 1: avidemux2_gtk(_Z17videoCodecSetConfPcjPh+0x64) [0x5ecd74] <videoCodecSetConf>() Frame 2: avidemux2_gtk(_Z24loadVideoCodecConfStringPc+0x94) [0x5ed014] <loadVideoCodecConfString>() Frame 3: avidemux2_gtk(_ZN19ADM_JSAvidemuxVideo5CodecEP9JSContextP8JSObjectjPlS4_+0x134) [0x4e4424] <>() Frame 4: avidemux2_gtk(js_Invoke+0x5ed) [0x512abd] Frame 5: avidemux2_gtk(js_Interpret+0x2eff) [0x515d5f] Frame 6: avidemux2_gtk(js_Execute+0x33f) [0x5202ef] Frame 7: avidemux2_gtk(JS_ExecuteScript+0x1e) [0x4ea76e] Frame 8: avidemux2_gtk(_Z15parseECMAScriptPKc+0x71) [0x4e2741] <parseECMAScript>() Frame 9: avidemux2_gtk(_Z17A_parseECMAScriptPKc+0x1a) [0x4b28ba] <A_parseECMAScript>() Frame 10: avidemux2_gtk(_Z12HandleAction6Action+0xad) [0x4b4d1d] <HandleAction>() Frame 11: avidemux2_gtk(_Z11guiCallbackP12_GtkMenuItemPv+0x20) [0x8d3530] <guiCallback>(_GtkMenuItem,) Frame 12: /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x16d) [0x2ad17260207d] Frame 13: /usr/lib/libgobject-2.0.so.0 [0x2ad172614c98] Frame 14: /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7f0) [0x2ad172616110] Frame 15: /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x2ad172616603] Frame 16: /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_activate+0x6b) [0x2ad17150730b] Frame 17: /usr/lib/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0xfd) [0x2ad1713fafed] Frame 18: /usr/lib/libgtk-x11-2.0.so.0 [0x2ad1713fccc5] Frame 19: /usr/lib/libgtk-x11-2.0.so.0 [0x2ad1713ee488] *********** BACKTRACK ************** Memory stat: Images stat: ___________ Max memory consumed (MB) : 7473 Current memory consumed (MB) : 7473 Max image used : 16 Cur image used : 16 Cleaning up yv12close called Deleting post proc Waiting for Spidermonkey to finish... Cleaning up Spidermonkey. [SDL] Quitting... End of cleanup Images stat: ___________ Max memory consumed (MB) : 7473 Current memory consumed (MB) : 1012 Max image used : 16 Cur image used : 2 Global mem stat ______________ Memory consumed: 1 (MB) Goodbye...

С файлом x264.js та же история.
Спасибо сказали:
Аватара пользователя
sspphheerraa
Сообщения: 1375
ОС: Gentoo

Re: Грамотный кодинг видео в Linux

Сообщение sspphheerraa »

kreator писал(а):
15.04.2008 03:49
MAA писал(а):
14.04.2008 16:23
Понимаешь, компу плевать на разрешение, для него является значимым интенсивность потока передаваемой информации. Если комп не тянет, значит эту интенсивность нужно уменьшить. Можно понижением разрешения, можно просто снижением битрейта. Последнее IMHO лучше.

Нанрузка на проц от разрешения зависит гораздо больше, чем от битрейта.

Но ведь и качество гораздо больше зависит от разрешения. Я вобщем-то исхожу из принципов минимальной его потери (да и дозировать уменьшение битрейта гораздо легче).
А на счет нагрузки проца - это его работа... нагружаться (за что ж деньги плочены? :) ), а наше дело видеть качество, а не артефакты.
IMHO если проц не тянет, стоит попробовать уменьшить битрейт на 15-20-25%. Если после этого потянет (с нагрузкой ~90%, к примеру) - то так и оставить. Когда-нибудь купите проц по мощнее и удельная загрузка будет меньше, а вот съэкономленного качества уже не вернете. Но если проц все равно не тянет, то тогда уже можно думать и об уменьшении картинки (с тем же битрейтом).

kreator писал(а):
15.04.2008 03:49
MAA писал(а):
14.04.2008 16:23
Почему? Из-за того, что от снимка к снимку изображение гуляет вверх-вниз на 1 строку, в результате чего сложнее высчитывать P/B кадры?

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

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

kreator писал(а):
15.04.2008 03:49
MAA писал(а):
14.04.2008 16:23
Но дело не в этом. То, что определиться с разверткой надо сразу (как ты ранее говорил) я полностью согласен. Но IMHO вот это "сразу" должно быть еще на этапе съемки. Т.е. если нет жесткого аппаратного ограничения на ширину потока передаваемой информации (а ведь черезстрочку ввели именно из-за таких ограничений), то снимать все в прогрессиве. Худ. фильмы - на кинопленку, с последующим ее покадровым сканированием. Для дома - 30p. ...не могу сказать является ли это компромисом, т.к. еще не приходилось видеть нативные 30p. Теоретически - в полне может быть.

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

Ну я вообще-то говорил про картинку. Проф. кинопленка имеет очень большое разрешение (дискретность изображения), мы как-то считали... получался эквивалент грубо говоря 70-80 мегапикселей. И использовать ее в качестве источника для дальнейшей обработки очень даже можно.
Раз уж упомянул про звук, то может просвятишь как делают старые фильмы (например, "Чужой", "Хищник") в HD качестве. С самим видео понятно, - берут с кинопленки, где берут качественный звук? Ведь когда их снимали еще не было цифры, а аналоговые носители звуковой записи наверняка бы уже "зашумились".
(спрашиваю, потому что не знаю)

kreator писал(а):
15.04.2008 03:49
MAA писал(а):
14.04.2008 16:23
Ну, а если уж снят фильм в черезстрочке, а хочется прогрессива и при этом хорошего качества, то IMHO лучше уж сразу поискать его в HD.

Я почти не смотрю мейнстрим, лет семь назад зацепило авторское кино, так и не отпустило :) Там о техническом качестве во многих случаях говорить не приходится: малый бюджет, многие сняты 30-50 лет назад.

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

kreator писал(а):
15.04.2008 03:49
Хорошо хоть торент спасает

ага, и мул

kreator писал(а):
15.04.2008 03:49
А я грешным делом подумал, что модерацию отменили :)

Дык, нет, тему ж кто-то прилепил :)
Sspphheerraa
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT
Ну вот и прояснилось: у тебя версия по x64, у меня - x32. В моём случае параметры x264 занимают 188 байт, в твоём 192. Осталось толко найти, какой из параметров вырастает на четыре байта. Сохрани проект с установленым x264, но без изменения его (x264) настроек и приложи к следующему посту.

MAA писал(а):
15.04.2008 20:03
Мдааа, борьба противоположностей (филос.): размер ~ качество. Больше макроблок - меньше детализация, и т.д.

Качество не изменяется, так как размер блока выбирается исходя из изображения и настроек качества. Просто при уменьшении разрешения, приходится использовать мелкие блоки там, где могли быть большие.
MAA писал(а):
15.04.2008 20:03
Ну я вообще-то говорил про картинку. Проф. кинопленка имеет очень большое разрешение (дискретность изображения), мы как-то считали... получался эквивалент грубо говоря 70-80 мегапикселей. И использовать ее в качестве источника для дальнейшей обработки очень даже можно.

Пленка вся очень разная, зерно пленки с высокой светочувствительностью достаточно большое. На старых фильмах, зерно видно даже на разрешении 768x576 (если шумодавом не прошлись).
http://rus.625-net.ru/cinema/2007/02/cifproizv.htm

Вообще рекомендую 625-net.ru всем, кто интересуется проф видео и звукорежиссурой, очень много ценного материала.

MAA писал(а):
15.04.2008 20:03
Раз уж упомянул про звук, то может просвятишь как делают старые фильмы (например, "Чужой", "Хищник") в HD качестве. С самим видео понятно, - берут с кинопленки, где берут качественный звук? Ведь когда их снимали еще не было цифры, а аналоговые носители звуковой записи наверняка бы уже "зашумились".
(спрашиваю, потому что не знаю)

Это смотря как и на что писать, сейчас есть много 24-х битных ремастеров старых рок и джаз записей, которые по качеству лучше многих современных.
В кино ещё проще, так как можно частично озвучить заново.
MAA писал(а):
15.04.2008 20:03
Так тогда качество вообще превыше всего... о размере я бы не думал.

Грубо говоря (да простят меня авторы нетленных творений), авторское кино можно разделить на идейное и созерцательное. Я больше отдаю предпочтение первой категории, но вполне понимаю и людей, которые восхищаются мастерством света и тени. Конечно деление очень грубое, в каждом работе есть и то и другое, просто в разном соотношении. Одна из самых впечатлявших меня работ, была снята в 1978 году далеко не на лучшее оборудование, плохой перевод и сжата доблестными пиратами в 1gb на два часа в mpeg2. Но тем не менее этого оказалось достаточно, что бы изменить мои взгляды на многое.
Спасибо сказали:
Аватара пользователя
sspphheerraa
Сообщения: 1375
ОС: Gentoo

Re: Грамотный кодинг видео в Linux

Сообщение sspphheerraa »

kreator писал(а):
16.04.2008 03:57
размер блока выбирается исходя из изображения и настроек качества

-> и разрешения, которое обычно при сравнениях подразумевается константой.
В нашем же случае константа - качество, т.е. мы в обоих случаях не должны терять ни движения (какие-либо векторы), ни детализацию (не получать сглаживание) статичных объектов. И количество блоков, должно быть пропорционально разрешению. Если, скажем, в одной области кадра на низком разрешении одно количество блоков, а на кадре с высоким разрешение (в той же обрасти) меньше, то здесь явно теряется качество (оно уже не константа). Но с другой стороны качество понятие субъективное, и для разных людей эта "константа" будет варьировать.
Т.е. если качество не меняется, то удельное количество блоков для определенной области должно быть пропорционально.


ps Еще одно утверждение по поводу черезстрочки (как всегда IMHO).
Воспроизведение черезстрочки на прогрессиве, самое близкое к нативному интерлейсному дисплею, было бы воспроизведением в режиме 50p, но чтоб на каждом кадре предыдущее поле показывалось с уменьшенной где-то до 25% яркостью.
Sspphheerraa
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
16.04.2008 03:57
Сохрани проект с установленым x264, но без изменения его (x264) настроек и приложи к следующему посту.

Готово.
myproject.tar.gz
(621 байт) 32 скачивания
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT
Исправил, пробуй.

MAA писал(а):
16.04.2008 20:03
Т.е. если качество не меняется, то удельное количество блоков для определенной области должно быть пропорционально.

Не блоков, а деталей. Колличество блоков подбирается под заданную детальность, а не на оборот.
Представь: есть кусок плоского неба описанного блоком 8x8, в соседнем блоке тучка. Немного уменьшаем изображение, тучка немного залезла в наш блок 8x8. Для сохранения детальности приходится делать вместо одного блока три (8x4,4x4,4x4). Чем больше уменьшаем, тем плотнее детали и мельче блоки.
MAA писал(а):
16.04.2008 20:03
ps Еще одно утверждение по поводу черезстрочки (как всегда IMHO).
Воспроизведение черезстрочки на прогрессиве, самое близкое к нативному интерлейсному дисплею, было бы воспроизведением в режиме 50p, но чтоб на каждом кадре предыдущее поле показывалось с уменьшенной где-то до 25% яркостью.

Интересная мысль ... Что-то вроде имитации инертности телевизионного люминофора. Но, имхо, этот эффект будет мало отличатся от интерполяции 25p в 50p с соответствующими коэффициентами.
Вложения
x264_vorbis_x64.js.bz2
(807 байт) 28 скачиваний
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
17.04.2008 03:16
Исправил, пробуй.

Попробовал. Программа тупо виснет при сохранении. Если в фильтрах Vorbis выставить gone mode в позицию none проблема решается.
Вторая проблема заключается в том что avidemux кодирует файл с отставанием по звуку. Игрался с настройками, но результата нет. Mencoder не косячит с этим файлом. На других файлах не испытывал.
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT писал(а):
19.04.2008 22:13
Попробовал. Программа тупо виснет при сохранении. Если в фильтрах Vorbis выставить gone mode в позицию none проблема решается.

Она не виснет, она думает :) Gain mode: -3dB проводит нормализацию уровня звука по уровню -3dB. Если этого не делать, то звук при переводе 5.1 в стерео будет тихий. Ранее там было окно прогресса, mean его удалил так как оно не вписывалась в планы по отделению движка от UI, я ему сразу сказал, что пользователей это будет вводить в заблуждение, но он отложил это для 2.4 и забыл ;)
CnupT писал(а):
19.04.2008 22:13
Вторая проблема заключается в том что avidemux кодирует файл с отставанием по звуку. Игрался с настройками, но результата нет. Mencoder не косячит с этим файлом. На других файлах не испытывал.

Пробуй mkv ;) Рассинхронизация равномерная или в начале всё нормально, а в конце сильно расходится?
Спасибо сказали:
Аватара пользователя
Nerr
Сообщения: 65

Re: Грамотный кодинг видео в Linux

Сообщение Nerr »

Я делал так, сначала Avidemux"ом кодил в x264 и mp4, потом выдирал дорожку с оригинала, а потом при помощи mkvmerge совмещал видеопоток с mp4 файла с дорожкой оригинала, на выходе получал матрешка файл с нормальной синхронизацией звука
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
20.04.2008 01:21
Пробуй mkv

Побывал, то же самое.
kreator писал(а):
20.04.2008 01:21
Рассинхронизация равномерная или в начале всё нормально, а в конце сильно расходится?

Равномерная.
zxxxc писал(а):
20.04.2008 01:47
Я делал так, сначала Avidemux"ом кодил в x264 и mp4, потом выдирал дорожку с оригинала, а потом при помощи mkvmerge совмещал видеопоток с mp4 файла с дорожкой оригинала, на выходе получал матрешка файл с нормальной синхронизацией звука

Судя по всему это единственный способ, так и сделаю.
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

CnupT писал(а):
20.04.2008 02:23
Судя по всему это единственный способ, так и сделаю.

Ничего не получилось, способ не работает. Причины таковы, что avidemux при конвертации, по крайней мере, в x264 и xvid немного "ускоряет" видео и звук, соотвественно, отстаёт. Нет разницы, в avidemux их мультиплексировать или же в штатной тулзе mkv.

Какие будут мнения?
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT писал(а):
21.04.2008 22:39
немного "ускоряет" видео

Это как? Изменяет frame rate или колличество кадров?
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
22.04.2008 01:13
Изменяет frame rate или колличество кадров?

Я не знаю. А как этот момент продиагностировать можно? Просто на глаз реально видно как фрагмент видео быстрей проходит на кодированном по отношению к оригиналу.
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
22.04.2008 01:13
Это как? Изменяет frame rate или колличество кадров?

Определил что frame rate, запустил исходный файл и на выводе получил строку:

Код: Выделить всё

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

Далее, полез в меню Video -> Frame Rate и указал там 24.000. Тестовый кусок отставал по отношению к оригиналу на 1 долю секунды. Думаю, проблема решена.

А вот и официальный вердикт:
It means that Avidemux cannot tell the difference between FILM and NTSC. So if the MPEG looks progressive (not interlaced) and obvious desync appears (and gets worse and worse), use Video->Frame Rate and set it to 23.976
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

CnupT писал(а):
23.04.2008 22:03
Думаю, проблема решена.

Рано радовался. Видео получается длиннее по отношению к оригиналу, соотвественно и звук запаздывает. Но начинается это не с самого начала, а к середине ближе. Перепробовал множество возможных решений - ни одно не помогло.

Складываю руки и записываю диски в оригинальном качестве.
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

CnupT
Это бывает редко, но иногда избежать рассинхронизацию очень сложно.
Если ничего не помогает, то я запускаю mplayer и на ходу подгоняю синхронизацию. Затем устанавливаю полученное значение в mkvmerge. В man mkvmerge есть примеры по теме.
Спасибо сказали:
Аватара пользователя
Snupt
Бывший модератор
Сообщения: 2062
Статус: No Place for RTFM Here…
ОС: Mac OS X
Контактная информация:

Re: Грамотный кодинг видео в Linux

Сообщение Snupt »

kreator писал(а):
30.04.2008 04:20
Если ничего не помогает, то я запускаю mplayer и на ходу подгоняю синхронизацию

Не получится. Аналогично можно использовать опцию Shift в Avidemux. Звук начинает рассинхронизацию постепенно усиливая эффект по истечению времени. Если в начале фильма он равномерно идёт с видео, то потом ситуация начинает искажаться в худшую сторону. В конце фильма звук бежит впереди картинки секунд на семь.
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

Я ведь не зря ман упомянул ;)
Some movies start synced correctly but slowly drift out of sync. For these kind of movies you can specify a delay factor that is applied to all timestamps - no data is added or removed. So if you make that factor too big or too small you'll get bad results. An example is that an episode I transcoded was 0.2 seconds out of sync at the end of the movie which was 77340 frames long. At 29.97fps 0.2 seconds correspond to approx. 6 frames. So I did

$ mkvmerge -o goodsync.mkv -y 23456:0,77346/77340 outofsync.mkv
Спасибо сказали:
Аватара пользователя
Nerr
Сообщения: 65

Re: Грамотный кодинг видео в Linux

Сообщение Nerr »

kreator писал(а):
02.05.2008 01:11
Я ведь не зря ман упомянул ;)
Some movies start synced correctly but slowly drift out of sync. For these kind of movies you can specify a delay factor that is applied to all timestamps - no data is added or removed. So if you make that factor too big or too small you'll get bad results. An example is that an episode I transcoded was 0.2 seconds out of sync at the end of the movie which was 77340 frames long. At 29.97fps 0.2 seconds correspond to approx. 6 frames. So I did

$ mkvmerge -o goodsync.mkv -y 23456:0,77346/77340 outofsync.mkv


не помогает
Спасибо сказали:
kreator
Сообщения: 384
ОС: LFS

Re: Грамотный кодинг видео в Linux

Сообщение kreator »

zxxxc писал(а):
03.05.2008 17:31
не помогает

А мне помогает :)
Опиши подробно как употреблял.
Спасибо сказали:
Ответить