REG /?
Add: REG ADD KeyName [{/v ValueName | /ve}] [/t Type] [/f]
Delete: REG DELETE KeyName [{/v ValueName | /ve | /va}] [/f]
To add a new DWORD (32-bit) value entry named AppInfo with value of 1 on a remote computer, use the following example:
REG ADD \\ComputerName\HKLM\Software\MySubkey /v AppInfo /t REG_DWORD /d 1
To add a new Binary Value entry named Data with data of fe340ead, use the following example:
REG ADD HKLM\Software\MySubkey /v Data /t REG_BINARY /d fe340ead
Вот теперь вы сами неизбежно требуете mediainfo, а это можно было сделать сразу.Мне он нужен для того, чтобы определить, требуется ли человеку дополнительно сжимать файлы, или он может их просто объединить. На изначальный вопрос "сжать максимально без потери качества" ответ внизу уже есть, осталось уточнить.
ffmpeg -i input_from_concat -c copy output.ts
практика показывает, что повторение тех же параметров сжатия, что у исходника, далеко не всегда ведёт к чему-то приемлемомуRGB весит в несколько раз больше, чем YUV, при этом новой информации от выставления RGB появиться не может, и сжатие лучше работать не начнет. Так что в случае с YUV (по крайней мере 4:2:0) исходником "-pix_fmt yuv420p" - простой багфикс для FFV1.
x265 - если оборудование поддерживает декодинг на аппартном уровнеЯ думаю, что для целей архива это не обязательно, человеку нужно минимизировать размер файла и ему не жалко времени. В таком случае, когда архив понадобится, его можно в крайнем случае разжать во что-нибудь попроще за пару (десятков) минут, если аппаратное воспроизведение не поддерживается, либо найти телефон\ноутбук\etc с поддержкой H265. А вот место должно сэкономиться.
Я лично предпочитаю не aac, а vorbis, но как я понимаю звіука там может и не бытьДа, звука может не быть, об этом я не подумал. А вот vorbis вроде как не влезет в один контейнер с H265, или я не прав?