Да. Более того - его можно выгрузить с этим форматом без проблем.
Грамотный кодинг видео в Linux
Модератор: Модераторы разделов
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
-
- Сообщения: 65
Re: Грамотный кодинг видео в Linux
И еще вот вопрос. Avidemux2 показывает в топе 177% CPU, а mplayer максимум 99%
-lavdopts threads=2 пробовал, без изменений
Проц Prescott (гипертрединг), ядро linux smp
моежет такое быть что mplayer не выжимает все из проца? или выдается неправильную инфа в топ?
-lavdopts threads=2 пробовал, без изменений
Проц Prescott (гипертрединг), ядро linux smp
моежет такое быть что mplayer не выжимает все из проца? или выдается неправильную инфа в топ?
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
MAA писал(а): ↑13.04.2008 11:39Идет преобразование в 50p с уменьшением вертикального разрешения в половину. Выполняются фильтры/ресайзы и пр. Затем 50p интерполируется обратно.
Это осложняет работу кодека, и возможно ему понадобится больше времени для обработки. Но почему от этого размер должен страдать, мне не понятно...
768x576@25fps и 768x288@50fps очень разные вещи с точки зрения сжатия.
Черезстрочных устройств с каждым годом меньше, не вписываются они в цифровую эпоху. Я уже и забыл, когда последний раз черезстрочность на мониторе видел. Сейчас только телевизоры остались и то ненадолго.
MAA писал(а): ↑13.04.2008 11:39ps. Может когда-нибудь производители видеокамер откажутся от черезстрочки вообще и будут выпускать, скажем 1920x1080@50p / 1920x1080@25p. Хотите, берите 50p - будет живость, не хотите - береите 25p, будет кинематографический motion blur.
И всем будет жить легче, и людям, и кодекам, и железу
ИМХО все видео камеры давно уже прогресивные и черезстрочность получается либо за счет понижения fps (50->25) либо вообще видео процессором. Сейчас многие производят камеры 30fsp прогресива, что имхо, разумный компромисс для домашнего видео.
Точно не скажу - давно это было, ещё до того, как я участвовал в разработке. Вторая версия была весьма сырая и скорее всего это было сделано для удобства - можно установить обе, в одно (первой) работать, а вторую тестировать. Изначально проект носил другое название, но не могу вспомнить ...
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
Покажи мне всё что в консоли остается после падения. На других файлах тоже самое?
p.s. Меня долго не было, что значит "Бывшие модераторы"? И Topper'а что-то не видно ...
-
- Сообщения: 1375
- ОС: Gentoo
Re: Грамотный кодинг видео в Linux
"более правильный" это как?
делай тем, результат которого тебя устроит
В Avidemux IMHO просто легче.
Понимаешь, компу плевать на разрешение, для него является значимым интенсивность потока передаваемой информации. Если комп не тянет, значит эту интенсивность нужно уменьшить. Можно понижением разрешения, можно просто снижением битрейта. Последнее IMHO лучше.
Почему? Из-за того, что от снимка к снимку изображение гуляет вверх-вниз на 1 строку, в результате чего сложнее высчитывать P/B кадры?
kreator писал(а): ↑14.04.2008 05:31Черезстрочных устройств с каждым годом меньше, не вписываются они в цифровую эпоху. Я уже и забыл, когда последний раз черезстрочность на мониторе видел. Сейчас только телевизоры остались и то ненадолго.
MAA писал(а): ↑13.04.2008 11:39ps. Может когда-нибудь производители видеокамер откажутся от черезстрочки вообще и будут выпускать, скажем 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
-
- Сообщения: 65
Re: Грамотный кодинг видео в Linux
Код: Выделить всё
"более правильный" это как? smile.gif
делай тем, результат которого тебя устроит
В Avidemux IMHO просто легче.
Avidemux пока плохо работает с матрешкой (если кодировать в нее). В частности рассинхронизация звука с изображением.
-
- Сообщения: 1375
- ОС: Gentoo
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
У меня по-моему что-то с кодеком 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? Всё равно я звук не очень люблю пережимать
То и значит. Срок годности, наверное, кончился. Topper уже очень давно не появлялся тут, что и как с ним я не знаю, мы не особо знакомы были.
-
- Сообщения: 65
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
Нанрузка на проц от разрешения зависит гораздо больше, чем от битрейта.
В большинстве случаев, эффективность сжатия выше при больших разрешениях, так как можно использовать меньшее количество блоков большого размера - можно сглаживать/интерполировать большие куски и векторов движения меньше - ведь блоков меньше.
MAA писал(а): ↑14.04.2008 16:23Но дело не в этом. То, что определиться с разверткой надо сразу (как ты ранее говорил) я полностью согласен. Но IMHO вот это "сразу" должно быть еще на этапе съемки. Т.е. если нет жесткого аппаратного ограничения на ширину потока передаваемой информации (а ведь черезстрочку ввели именно из-за таких ограничений), то снимать все в прогрессиве. Худ. фильмы - на кинопленку, с последующим ее покадровым сканированием. Для дома - 30p. ...не могу сказать является ли это компромисом, т.к. еще не приходилось видеть нативные 30p. Теоретически - в полне может быть.
Согласен. Снимать или писать звук в проф целях нужно с максимальным возможным качеством имеющейся технической базы и понижать только перед записью на конечный носитель. Это как минимум позволит уменьшить цифровые потери при каждой промежуточной обработке.
Я почти не смотрю мейнстрим, лет семь назад зацепило авторское кино, так и не отпустило Там о техническом качестве во многих случаях говорить не приходится: малый бюджет, многие сняты 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).
Пресет сделал - аудио не трогает вообще. Но всё же покажи вывод консоли после падения, может получится поправить.
А я грешным делом подумал, что модерацию отменили
У вас нет необходимых прав для просмотра вложений в этом сообщении.
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Не вопрос. Собственно вот:
Код:
[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 та же история.
-
- Сообщения: 1375
- ОС: Gentoo
Re: Грамотный кодинг видео в Linux
Но ведь и качество гораздо больше зависит от разрешения. Я вобщем-то исхожу из принципов минимальной его потери (да и дозировать уменьшение битрейта гораздо легче).
А на счет нагрузки проца - это его работа... нагружаться (за что ж деньги плочены? ), а наше дело видеть качество, а не артефакты.
IMHO если проц не тянет, стоит попробовать уменьшить битрейт на 15-20-25%. Если после этого потянет (с нагрузкой ~90%, к примеру) - то так и оставить. Когда-нибудь купите проц по мощнее и удельная загрузка будет меньше, а вот съэкономленного качества уже не вернете. Но если проц все равно не тянет, то тогда уже можно думать и об уменьшении картинки (с тем же битрейтом).
Мдааа, борьба противоположностей (филос.): размер ~ качество. Больше макроблок - меньше детализация, и т.д.
В общем, IMHO здесь искать компромис надо исходя из каких-то других причин.
kreator писал(а): ↑15.04.2008 03:49MAA писал(а): ↑14.04.2008 16:23Но дело не в этом. То, что определиться с разверткой надо сразу (как ты ранее говорил) я полностью согласен. Но IMHO вот это "сразу" должно быть еще на этапе съемки. Т.е. если нет жесткого аппаратного ограничения на ширину потока передаваемой информации (а ведь черезстрочку ввели именно из-за таких ограничений), то снимать все в прогрессиве. Худ. фильмы - на кинопленку, с последующим ее покадровым сканированием. Для дома - 30p. ...не могу сказать является ли это компромисом, т.к. еще не приходилось видеть нативные 30p. Теоретически - в полне может быть.
Согласен. Снимать или писать звук в проф целях нужно с максимальным возможным качеством имеющейся технической базы и понижать только перед записью на конечный носитель. Это как минимум позволит уменьшить цифровые потери при каждой промежуточной обработке.
Ну я вообще-то говорил про картинку. Проф. кинопленка имеет очень большое разрешение (дискретность изображения), мы как-то считали... получался эквивалент грубо говоря 70-80 мегапикселей. И использовать ее в качестве источника для дальнейшей обработки очень даже можно.
Раз уж упомянул про звук, то может просвятишь как делают старые фильмы (например, "Чужой", "Хищник") в HD качестве. С самим видео понятно, - берут с кинопленки, где берут качественный звук? Ведь когда их снимали еще не было цифры, а аналоговые носители звуковой записи наверняка бы уже "зашумились".
(спрашиваю, потому что не знаю)
Так тогда качество вообще превыше всего... о размере я бы не думал.
ага, и мул
Дык, нет, тему ж кто-то прилепил
Sspphheerraa
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
CnupT
Ну вот и прояснилось: у тебя версия по x64, у меня - x32. В моём случае параметры x264 занимают 188 байт, в твоём 192. Осталось толко найти, какой из параметров вырастает на четыре байта. Сохрани проект с установленым x264, но без изменения его (x264) настроек и приложи к следующему посту.
Качество не изменяется, так как размер блока выбирается исходя из изображения и настроек качества. Просто при уменьшении разрешения, приходится использовать мелкие блоки там, где могли быть большие.
Пленка вся очень разная, зерно пленки с высокой светочувствительностью достаточно большое. На старых фильмах, зерно видно даже на разрешении 768x576 (если шумодавом не прошлись).
http://rus.625-net.ru/cinema/2007/02/cifproizv.htm
Вообще рекомендую 625-net.ru всем, кто интересуется проф видео и звукорежиссурой, очень много ценного материала.
Это смотря как и на что писать, сейчас есть много 24-х битных ремастеров старых рок и джаз записей, которые по качеству лучше многих современных.
В кино ещё проще, так как можно частично озвучить заново.
Грубо говоря (да простят меня авторы нетленных творений), авторское кино можно разделить на идейное и созерцательное. Я больше отдаю предпочтение первой категории, но вполне понимаю и людей, которые восхищаются мастерством света и тени. Конечно деление очень грубое, в каждом работе есть и то и другое, просто в разном соотношении. Одна из самых впечатлявших меня работ, была снята в 1978 году далеко не на лучшее оборудование, плохой перевод и сжата доблестными пиратами в 1gb на два часа в mpeg2. Но тем не менее этого оказалось достаточно, что бы изменить мои взгляды на многое.
Ну вот и прояснилось: у тебя версия по x64, у меня - x32. В моём случае параметры x264 занимают 188 байт, в твоём 192. Осталось толко найти, какой из параметров вырастает на четыре байта. Сохрани проект с установленым x264, но без изменения его (x264) настроек и приложи к следующему посту.
Качество не изменяется, так как размер блока выбирается исходя из изображения и настроек качества. Просто при уменьшении разрешения, приходится использовать мелкие блоки там, где могли быть большие.
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-х битных ремастеров старых рок и джаз записей, которые по качеству лучше многих современных.
В кино ещё проще, так как можно частично озвучить заново.
Грубо говоря (да простят меня авторы нетленных творений), авторское кино можно разделить на идейное и созерцательное. Я больше отдаю предпочтение первой категории, но вполне понимаю и людей, которые восхищаются мастерством света и тени. Конечно деление очень грубое, в каждом работе есть и то и другое, просто в разном соотношении. Одна из самых впечатлявших меня работ, была снята в 1978 году далеко не на лучшее оборудование, плохой перевод и сжата доблестными пиратами в 1gb на два часа в mpeg2. Но тем не менее этого оказалось достаточно, что бы изменить мои взгляды на многое.
Спасибо сказали:
-
- Сообщения: 1375
- ОС: Gentoo
Re: Грамотный кодинг видео в Linux
-> и разрешения, которое обычно при сравнениях подразумевается константой.
В нашем же случае константа - качество, т.е. мы в обоих случаях не должны терять ни движения (какие-либо векторы), ни детализацию (не получать сглаживание) статичных объектов. И количество блоков, должно быть пропорционально разрешению. Если, скажем, в одной области кадра на низком разрешении одно количество блоков, а на кадре с высоким разрешение (в той же обрасти) меньше, то здесь явно теряется качество (оно уже не константа). Но с другой стороны качество понятие субъективное, и для разных людей эта "константа" будет варьировать.
Т.е. если качество не меняется, то удельное количество блоков для определенной области должно быть пропорционально.
ps Еще одно утверждение по поводу черезстрочки (как всегда IMHO).
Воспроизведение черезстрочки на прогрессиве, самое близкое к нативному интерлейсному дисплею, было бы воспроизведением в режиме 50p, но чтоб на каждом кадре предыдущее поле показывалось с уменьшенной где-то до 25% яркостью.
Sspphheerraa
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
CnupT
Исправил, пробуй.
Не блоков, а деталей. Колличество блоков подбирается под заданную детальность, а не на оборот.
Представь: есть кусок плоского неба описанного блоком 8x8, в соседнем блоке тучка. Немного уменьшаем изображение, тучка немного залезла в наш блок 8x8. Для сохранения детальности приходится делать вместо одного блока три (8x4,4x4,4x4). Чем больше уменьшаем, тем плотнее детали и мельче блоки.
Интересная мысль ... Что-то вроде имитации инертности телевизионного люминофора. Но, имхо, этот эффект будет мало отличатся от интерполяции 25p в 50p с соответствующими коэффициентами.
Исправил, пробуй.
Не блоков, а деталей. Колличество блоков подбирается под заданную детальность, а не на оборот.
Представь: есть кусок плоского неба описанного блоком 8x8, в соседнем блоке тучка. Немного уменьшаем изображение, тучка немного залезла в наш блок 8x8. Для сохранения детальности приходится делать вместо одного блока три (8x4,4x4,4x4). Чем больше уменьшаем, тем плотнее детали и мельче блоки.
MAA писал(а): ↑16.04.2008 20:03ps Еще одно утверждение по поводу черезстрочки (как всегда IMHO).
Воспроизведение черезстрочки на прогрессиве, самое близкое к нативному интерлейсному дисплею, было бы воспроизведением в режиме 50p, но чтоб на каждом кадре предыдущее поле показывалось с уменьшенной где-то до 25% яркостью.
Интересная мысль ... Что-то вроде имитации инертности телевизионного люминофора. Но, имхо, этот эффект будет мало отличатся от интерполяции 25p в 50p с соответствующими коэффициентами.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Попробовал. Программа тупо виснет при сохранении. Если в фильтрах Vorbis выставить gone mode в позицию none проблема решается.
Вторая проблема заключается в том что avidemux кодирует файл с отставанием по звуку. Игрался с настройками, но результата нет. Mencoder не косячит с этим файлом. На других файлах не испытывал.
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
Она не виснет, она думает Gain mode: -3dB проводит нормализацию уровня звука по уровню -3dB. Если этого не делать, то звук при переводе 5.1 в стерео будет тихий. Ранее там было окно прогресса, mean его удалил так как оно не вписывалась в планы по отделению движка от UI, я ему сразу сказал, что пользователей это будет вводить в заблуждение, но он отложил это для 2.4 и забыл
Пробуй mkv Рассинхронизация равномерная или в начале всё нормально, а в конце сильно расходится?
-
- Сообщения: 65
Re: Грамотный кодинг видео в Linux
Я делал так, сначала Avidemux"ом кодил в x264 и mp4, потом выдирал дорожку с оригинала, а потом при помощи mkvmerge совмещал видеопоток с mp4 файла с дорожкой оригинала, на выходе получал матрешка файл с нормальной синхронизацией звука
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Побывал, то же самое.
Равномерная.
Судя по всему это единственный способ, так и сделаю.
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Ничего не получилось, способ не работает. Причины таковы, что avidemux при конвертации, по крайней мере, в x264 и xvid немного "ускоряет" видео и звук, соотвественно, отстаёт. Нет разницы, в avidemux их мультиплексировать или же в штатной тулзе mkv.
Какие будут мнения?
-
- Сообщения: 384
- ОС: LFS
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Я не знаю. А как этот момент продиагностировать можно? Просто на глаз реально видно как фрагмент видео быстрей проходит на кодированном по отношению к оригиналу.
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Определил что 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
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Рано радовался. Видео получается длиннее по отношению к оригиналу, соотвественно и звук запаздывает. Но начинается это не с самого начала, а к середине ближе. Перепробовал множество возможных решений - ни одно не помогло.
Складываю руки и записываю диски в оригинальном качестве.
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
CnupT
Это бывает редко, но иногда избежать рассинхронизацию очень сложно.
Если ничего не помогает, то я запускаю mplayer и на ходу подгоняю синхронизацию. Затем устанавливаю полученное значение в mkvmerge. В man mkvmerge есть примеры по теме.
Это бывает редко, но иногда избежать рассинхронизацию очень сложно.
Если ничего не помогает, то я запускаю mplayer и на ходу подгоняю синхронизацию. Затем устанавливаю полученное значение в mkvmerge. В man mkvmerge есть примеры по теме.
-
- Бывший модератор
- Сообщения: 2062
- Статус: No Place for RTFM Here…
- ОС: Mac OS X
Re: Грамотный кодинг видео в Linux
Не получится. Аналогично можно использовать опцию Shift в Avidemux. Звук начинает рассинхронизацию постепенно усиливая эффект по истечению времени. Если в начале фильма он равномерно идёт с видео, то потом ситуация начинает искажаться в худшую сторону. В конце фильма звук бежит впереди картинки секунд на семь.
-
- Сообщения: 384
- ОС: LFS
Re: Грамотный кодинг видео в Linux
Я ведь не зря ман упомянул
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
-
- Сообщения: 65
Re: Грамотный кодинг видео в Linux
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
не помогает
-
- Сообщения: 384
- ОС: LFS