>>50709

>Я не стал перекодировать видео в avc, а сразу изменил разрешение на 2560x1440

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

>ты имел ввиду avc1? avc это же и есть h264, в котором мое видео итак

Да, h264 = avc = avc1 (не путать с av1), vp9 = vp09.

>Битрейт видео автоматически получился ~24000 kbpc

В принципе, нормальный битрейт, если у тебя не особо динамичный контент, но приучайся вручную указывать битрейт, а лучше crf. Поначалу будешь тыкаться, как слепой котёнок, но потом начнёшь интуитивно понимать, какое значение поставить для определённого видео.

>Ютуб выставил кодек vp09 и качество хорошее, я бы даже сказал отличное, но только при выставлении 1440p или 2160p. При 720 по-прежнему плохое, так и должно же быть?

Да, иначе быть не может. Качество видео зависит в первую очередь от битрейта, а у youtube битрейт зависит от разрешения. Конечно, при равном битрейте vp9 даёт качество немного лучше, чем avc, но это не меняет ситуацию, когда для 720p youtube выделяет жалкие ~1-2 мбит/с. Весь смысл в том, что для 1440p и выше youtube гарантированно даёт vp9 независимо от популярности канала и битрейт выше, чем для 1080p.

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

От повышения битрейта на твоей стороне битрейт на стороне youtube не повысится, но чем лучше качество исходника, тем точнее его сжатие при прочих равных. Повышать можно сколько угодно в пределах адекватных значений, но смысла в этом мало, потому что изменения минорные и при повышении сходят на нет в геометрической прогрессии. Всё зависит от твоего контента: если это очень динамичная сцена типа игры в apex legends, то битрейта нужно много, а если видеоурок по office word, то мало.

>В гугле прочитал, что слишком высокое значение нет смысла ставить, только вес файла увеличит, а качество останется прежнем.

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

>И еще такой момент, у меня монитор квадратный - 5:4, сам исходник видео в 1280x1024 (H264). Это ни каким образом не вносит коррективы при изменении разрешения до 1440?

Ну вообще, видео растянется, если ты 5:4 переведёшь в 16:9. Соотношение сторон менять не надо, но и подгонять его именно под 1440p не обязательно, ведь так ты на ровном месте теряешь попиксельную чёткость из-за некратной интерполяции. Для кратности просто умножай своё разрешение на два и перекодируй в 2560x2048, у youtube вроде не должно возникнуть с ним проблем. А если надо будет именно 1440p, то в 1800x1440.

>не понял зачем это нужно, вроде это как-то связано с разрешением

Единичку добавляют, чтобы ffmpeg сам вычислил другую сторону разрешения с сохранением соотношения сторон, но он может насчитать ерунду, так что лучше указывать самостоятельно.
>>50731
Битрейт в принципе не нужно указывать, когда контролируешь качество через crf.

Можешь перекодировать оставшиеся файлы с такими параметрами:
ffmpeg -i "input.mp4" -s 2560x2048 -c:v libx264 -crf 10 -preset slow -c:a copy "output.mp4"
Чем ниже crf, тем выше битрейт, сам подбери по конечному визуальному качеству своего контента. Пресет определяет, как долго твой комп будет пыхтеть для более качественного сжатия. Если ты очень нетерпеливый или твой комп – картошка, то можешь повысить пресет на medium или fast. Звуковая дорожка не перекодируется, потому что не нужно, но если очень нужно (хотя не нужно), то -c:a aac -vbr 5. А вообще, если комп не картошка, заведомо для youtube лучше изначально записывать видео в высоком разрешении и с высоким битрейтом. Например, в OBS Studio, там есть расширенные настройки записи. А обрезать запись без перекодирования потом удобно в Avidemux, выбирая copy для видео и аудио. Там самое главное обрезать начало именно по ключевому кадру, а конец можно в произвольном месте.

>>50688
>>50738

>sudo dmesg

26.260071] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[ 165.502618] systemd-journald[187]: File /var/log/journal/bfe193fd9d144188bc1ddc4130fc068c/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
[ 169.433381] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio.
[ 169.433389] iwlwifi 0000:03:00.0: reporting RF_KILL (radio disabled)
[ 169.438154] iwlwifi 0000:03:00.0: Not sending command - RF KILL
[ 169.562109] usb 2-2: USB disconnect, device number 3
[ 171.413015] iwlwifi 0000:03:00.0: RF_KILL bit toggled to enable radio.
[ 171.413026] iwlwifi 0000:03:00.0: reporting RF_KILL (radio enabled)
[ 171.428609] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[ 171.578750] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[ 171.932049] usb 2-2: new full-speed USB device number 4 using uhci_hcd
[ 172.104070] usb 2-2: New USB device found, idVendor=0a5c, idProduct=2145, bcdDevice= 3.99
[ 172.104083] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 172.104087] usb 2-2: Product: ThinkPad Bluetooth with Enhanced Data Rate II
[ 172.104090] usb 2-2: Manufacturer: Lenovo Computer Corp
[ 174.502592] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[ 174.654095] iwlwifi 0000:03:00.0: Radio type=0x0-0x2-0x0
[ 174.743548] wls1: authenticate with 3c:67:fb:51:39:5d (local address=00:21:6a:75:27:06)
[ 174.743558] wls1: send auth to 3c:67:fb:51:39:5d (try 1/3)
[ 174.752500] wls1: authenticated
[ 174.753014] wls1: associate with 3c:67:fb:51:39:5d (try 1/3)
[ 174.760025] wls1: RX AssocResp from 3c:67:fb:51:39:5d (capab=0x411 status=0 aid=1)
[ 174.769032] wls1: associated

>>51445
Задача твоя несложная, сотню статей и обсуждений по запросу «объединение двух провайдеров» нарыть нетрудно. Там же будет описано, что именно понимается под «объединением», и почему с одного IP-адреса (или через одно соединение с конкретным портом на нём) по привычным протоколам ты будешь качать только через одно из них. А вот несколько быстрых пиров в торренте раскидает по двум каналам, и загружены будут оба, главное, чтобы было, чем.

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

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

Однако, если у тебя есть настраиваемая тобой система на одном конце и настраиваемая тобой система на другом конце, ты можешь делать всё, что угодно, хоть скриптами на bash через netcat трафик распихивать. Предположим, ты покупаешь виртуалочку с гигабитным соединением (без сносочек о том, что оно делится на 1500 клиентов), возможностью как угодно настраивать сеть, и хостинг-провайдеру на самом деле пофиг, что ты будешь 200 мегабит в обе стороны занимать периодически. Тогда нам ничто не мешает объединить два канала между тобой и этим сервером, чтобы дальше трафик шёл к внешним серверам совершенно нормальным образом уже с его внешнего адреса. Сначала настроим одно VPN-соединение между одной парой виртуальных интерфейсов на клиенте и сервере, использующее физический интерфейс к одному провайдеру, потом второе, использующее другой канал, потом на обеих сторонах объединим эти интерфейсы так, как будто обе системы виртуально стоят рядом и связаны двумя кабелями. Дальше на сервере трафик пойдёт через NAT наружу, как и с обычным VPN. Вот пример:
https://serverfault.com/questions/977589/how-to-bond-two-multiple-internet-connections-for-increased-speed-and-failover

Также можно посмотреть на оверлейные сети вроде nebula, tailscale и прочих, возможно, кто-то из коробки поддерживает объединение каналов.

Ещё есть https://www.openmptcprouter.com/

Учти, что вместо OpenVPN, вероятно, придётся использовать другой протокол. Также надо понимать, что гигабит на провайдере не означает, что соединения с другими континентами будут выжимать гигабит, их фактическая скорость зависит от загрузки провайдеров по пути и настроек деления канала между соединениями.