Загрузка потоковых файлов на самом деле очень проста, обычно используется самая простая команда:
wget URL -O 输出文件名
Лучше всего указать здесь имя выходного файла, иначе загруженное имя файла может быть очень странным, что приведет к ошибкам распознавания формата или другим проблемам.
Однако, если вы используете эту команду напрямую, может возникнуть ситуация:
$ wget https://xxx.xxx.com/.... -O 1.flv
[2] 60387
[3] 60388
[4] 60389
-bash: 1.flv: command not found
[3]- Done sign=xxxxxxxxxxxxxxxxxxx
[4]+ Done abr_pts=-1800
$
正在把输出重定向至 “wget-log.1”。
Это связано с тем, что многие URL-адреса потоковой передачи имеют различные параметры (запросы) для указания другой информации, например, идентификации человека, который посетил.Если вы удалите некоторые параметры, ссылка станет бесполезной. Разделителем для параметров URL является &
, но этот символ используется &
во bash
многих оболочках для обозначения разделителя для последовательно выполняемых команд, поэтому это заставляет оболочку разграничивать входные команды там, где они нам не нужны.
В настоящее время мы можем &
добавить обратную косую черту впереди \
, чтобы оболочка воспринимала ее как простой символ, &
а не как разделитель команд. Но после этого некоторые другие символы также могут вызывать некоторые проблемы, поэтому самый простой и эффективный способ — добавить его "
и превратить в строку.
Поскольку оболочка обрабатывает строку от "
начала до конца "
, чтобы распознать строку, любые символы в ней распознаются как простые символы. В это время вводится следующая команда:
$ wget "https://xxx.xxx.com/...." -O 1.flv
--2023-06-02 03:57:01-- https://xxx.xxx.com/....
正在解析主机 [隐去的细节]
正在连接 [隐去的细节]|IP|:xxx... 已连接。
已发出 HTTP 请求,正在等待回应... 200 OK
长度:未指定 [video/格式]
正在保存至: “1.flv”
1.flv [ <=> ] 1.80M 159KB/s
Вы видите, что загрузка идет нормально.Скорость загрузки также скорость кода.Если загрузка прервется, скачанная часть будет сохранена.
Однако после загрузки и записи, если вы столкнулись с такими проблемами, что вы не можете перетаскивать индикатор выполнения или не можете добиться успеха каждый раз, когда вы его воспроизводите, рекомендуется использовать инструмент транскодирования ffmpeg
для однократного преобразования кода. конверсия немного выше, чем стабильная скорость загрузки 12. Просто удвойте ее.
Обновление 2023-06-06: Обнаружено, что можно использовать -c:v copy
для получения и применения настроек исходного видео, включая битрейт. Таким образом, команду можно записать:
$ ffmpeg -hwaccel videotoolbox -i in.flv -c:v h264_videotoolbox -c:v copy out.mp4
Этот метод использования исходных настроек может увеличить скорость транскодирования примерно в десять раз, поэтому лучше всего использовать этот:
Еще одним преимуществом транскодирования является то, что некоторые живые push-потоки заканчиваются спустя много времени после их загрузки, но на этот раз учитывается информация о видео, а данных нет. Если вы перетащите индикатор выполнения в это место, воспроизведение видео автоматически прекратится. Эта проблема может быть исправлена путем перекодирования.
Есть две причины для установки немного большей скорости передачи данных:
- Потому что если формат конвертировать, то могут быть потери;
- Потому что битрейт видео не постоянен, а колеблется в пределах диапазона. Если смотреть только на скорость в определенный момент, а эта скорость далека от среднего битрейта, то самый высокий битрейт может превышать допустимое отклонение
ffmpeg
, и оно может быть небольшим.
У кого-то здесь может возникнуть вопрос: Почему именно 12 раз? Разве это не должно быть 8x? Потому что 1 Byte = 8 bit
.
Причина, по которой здесь 12 раз, заключается в том, что скорость загрузки считается плоской这个时段下载的文件大小/这个时段间隔
. KB/s
Однако wget
фактический интервал частоты обновления составляет не 1 секунду, а загружаемые файлы передаются не непрерывно, а сегмент за сегментом, что приводит к wget
сильным колебаниям отображаемой скорости загрузки, а иногда разрыв дисплея может удваиваться. Используется 12 раз 1.5x8=12
, это относительно скомпрометированное значение, если вы не в своей тарелке, вы можете увеличить его.
Так что лучше рассчитывать вручную после загрузки, но некоторые видео не открываются, и информация о видео не видна, поэтому приходится рассуждать по скорости загрузки.
Если вы чувствуете то же, что и я: разве вы не говорили, что фактическая продолжительность видео может быть короче, чем продолжительность в информации о видео, может ли это компенсировать это колебание?
Я пробовал это, если рассчитанное вручную видео с битрейтом 3000K установлено на битрейт 2000K, тогда будет относительно большая потеря качества изображения (видимая невооруженным глазом). Вот сравнение (3000К слева, 2000К справа):
Видно, что волосы 2000K имеют гораздо более размытое ощущение (хотя поначалу это не очень ясно, потому что битрейт наружных якорей относительно низкий, но это более размыто). Для более подробного сравнения битрейта, пожалуйста, обратитесь к заключительной части сравнения тестов ffmpeg
в другой моей статье «Как установить на macOS (не нужно компилировать, устанавливать или варить), использовать ffmpeg для перекодирования и как использовать аппаратное ускорение» .
Некоторые люди могут быть обеспокоены, когда вычисляют кодовую скорость вручную: многие программы очень серьезны в соответствии с информатикой 1KB = 1000 Byte
, 1 KiB = 1024 Byte
потому что большинство Unix-подобных систем имеют основание 1000, и многие люди все еще работают в промышленных средах. Но некоторые программисты не видят разницы, или поскольку они в основном разрабатывают программы для Windows, они следуют 1KB = 1024 Byte
настройкам Windows. Так какой из них следует использовать для расчета?
Я удостоверился wget
и установил ffmpeg
в соответствии с информатикой 1KB = 1000 Byte
. 1 KiB = 1024 Byte
И на K
этом уровне разница между ними относительно невелика и может быть в основном проигнорирована. Так что если вы используете ffmpeg
относительно известную программу для транскодирования командной строки, то не беспокойтесь об этой проблеме и 1KB = 1000 Byte
считайте по этой базе.
Но если вы используете ПО на Windows, то велика вероятность, что расчет 1KB = 1024 Byte
производится по базовой системе. Тем не менее, используется некоторое программное обеспечение KiB
или MiB
программное обеспечение такого типа устройства, поэтому просто 1 KiB = 1024 Byte
рассчитывайте в соответствии с ним (например, «Запись и вещание станции B Ji»).
Надеюсь помочь нуждающимся~