Answered
Newbie here, this board has helped me leagues so far, thanks for that.
My request today is for those more seasoned with this sort of thing to point out any areas I might be making mistakes in, and particularly whether the end result should/should not be a surprise given the steps I've done. My objective with this is capturing and archiving a stream.
Feel free to skip to the question below, explanation to follow now:
A quick note that for the stream capture, I'm using a program which automates the process. Namely, its function is to record when there is activity on the channel, as I don't have the knowledge to write some script to automatically check whether a stream is live or not.
The source stream is of the MPEG-TS container type. That is to say, using the below, my resulting files have a .ts file extension. With the source(and output) parameters automatically handled by this program, I pass in these arguments in its FFmpeg-parameters settings:
-c:v copy -c:a copy -movflags faststart -y -f mpegts
After renaming that output by hand to let's say "file1.ts", I then use the console and execute this command:
ffmpeg -i file1.ts -c:v libx265 -crf 16 -preset slow -pix_fmt yuv420p10le -c:a aac -b:a 192k date_10bit.mp4
Here, I'm intending to re-encode the captured stream as a an HEVC/x265 file inside an .mp4 container.
- I've set the CRF value to 16 for the reasons I'm about to mention below, but at its core I'm chasing visual in-distinction to the source, and willing to pay the price in size(or so I thought)
- Preset set to slow at the reccommendation of some users, consensus seems to be for x265 quality of slow is equivalent to quality of medium when using x264
- 10bit depth, because of mention that 10bit compresses better, figured I'd give it a try
- Encoding audio to aac and 192k out of generic interest in higher quality audio availability where possible.
After many hours running, the resulting file was not visually indiscernible(didn't appear worse, as artefacts/motion issues go, but I think the 10bit command made the image noticeably more warm), and was marginally smaller than the original .ts I started with.
This was a stark lesson I'd somehow missed so far, that all re-encoding/compression(aside a CRF/QP of 0?) will always be a reduction in quality from the "source".
At day's end, my source file was 5.5GB. The x265 encode took the entire day, and popped out a file at 5.25GB. I assume because of such a low CRF namely. At any rate,
With my journey now explained:
Is all of this to be expected?
More specifically, is there(and what is) there some method to appreciably reduce file size while retaining quality- say, a CRF value of 20 or so. Currently I'm dreading the encode time, and really not seeing much positive results, so I'm inclined to accept I'll need to store the base .ts files and call it a day.
Thank you for taking the time to read.
Edit: Thank you Nmath in the comments!
