Downloading streaming files is actually very simple, the simplest command usually used:
wget URL -O 输出文件名
It is best to set the output file name here, otherwise the downloaded file name may be very strange, resulting in format recognition errors or other problems.
However, if you use this command directly, there is likely to be a situation:
$ 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”。
This is because many streaming URLs have various parameters (query) to indicate other information, such as identifying the person who visited. If you delete some parameters, the link will be useless. The delimiter for URL parameters is &, but the symbol is used &in bashmany shells to denote the delimiter for sequentially executing commands, so this causes the shell to delimit input commands where we don't want them.
At this time, we can &add a backslash in front \to let the shell treat it as a simple character &, not a command separator. But after doing this, some other symbols may also cause some problems, so the easiest and most efficient way is to add it "and turn it into a string.
Since the shell processes a string from a "start to a second "end to recognize the string, any symbols in it are recognized as simple characters. At this time, the command entered is as follows:
$ 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
You can see that the download is normal. The download speed is also the code rate. If the download is interrupted, the downloaded part will be kept.
However, after downloading and recording, if you encounter such problems that you cannot drag the progress bar or may not be successful every time you play it, it is recommended to use a ffmpegtranscoding tool to convert the code once. The code rate set during the conversion is slightly higher than the stable download speed of 12 Just double it.
Update 2023-06-06: Found that you can use -c:v copyto get and apply the settings of the source video, including bitrate. So the command can be written:
$ ffmpeg -hwaccel videotoolbox -i in.flv -c:v h264_videotoolbox -c:v copy out.mp4
This method of using source settings can increase the transcoding speed by about ten times, so it is best to use this:
Another advantage of transcoding is that some live push streams end long after they are downloaded, but the video information counts this time, but there is no data. If you drag the progress bar to this place, the video playback will end automatically. This problem can be corrected by transcoding.
There are two reasons for setting the bit rate slightly larger:
- Because if the format is converted, there may be losses;
- Because the bit rate of a video is not constant, but fluctuates within a range. If you only look at the speed at a certain moment, and this rate is far from the average bit rate, the highest bit rate may exceed the
ffmpegallowable deviation, and it may be small.
Someone here may have a question: Why is it 12 times? Shouldn't it be 8x? Because 1 Byte = 8 bit.
The reason why it is 12 times here is because the download speed is 这个时段下载的文件大小/这个时段间隔then KB/sthought flat. However, wgetthe actual refresh rate interval is not 1 second, and the downloaded files are not streamed continuously, but segment by segment, which causes the wgetdisplayed download speed to fluctuate greatly, and sometimes the display gap can double. 12 times is used 1.5x8=12, it is a relatively compromised value, if you are not at ease, you can make it larger.
So it’s better to calculate by hand after downloading, but some videos can’t be opened, and the video information can’t be seen, so you have to reason according to the download speed.
If you feel the same as me: didn’t you say that the actual duration of the video may be shorter than the duration in the video information, can it offset this fluctuation?
I have tried this, if the hand-calculated 3000K bit rate video is set to 2000K bit rate, then there will be a relatively large loss of image quality (visible to the naked eye). Here's a comparison (3000K on the left, 2000K on the right):
It can be seen that the 2000K hair has a much more smudged feel (although it is not very clear at first, because the bit rate of outdoor anchors is relatively low, but this is more blurred). For a more detailed bit rate comparison, please refer to the final test comparison part ffmpegof my other article "How to install on macOS (no need to compile, install or brew), use ffmpeg to transcode, and how to use hardware acceleration" .
Some people may be worried when they calculate the code rate by hand: many software are very serious in accordance with computer science 1KB = 1000 Byte, 1 KiB = 1024 Bytebecause most Unix-like systems are base 1000, and many people still work in industrial environments. passed. But some programmers can't tell the difference, or because they mainly develop programs on Windows, they follow 1KB = 1024 Bytethe settings on Windows. So which one should be used for calculation?
I've made sure, wgetand are set ffmpegin accordance with computer science 1KB = 1000 Byte. 1 KiB = 1024 ByteAnd at Kthis level, the difference between the two is relatively small and can basically be ignored. So if you are using ffmpega relatively well-known command line transcoding software, then don’t worry about this problem, and 1KB = 1000 Bytecalculate according to this base.
But if you are using software on Windows, then there is a high probability that the 1KB = 1024 Bytecalculation is performed according to the base system. However, some software is used KiBor MiBthe software of this kind of unit, so just 1 KiB = 1024 Bytecalculate according to it (such as "B station recording and broadcasting Ji").
Hope to help those in need~