PCIe lane confusion
- Thread starter Nicolai
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
While that's true for movies, the story is a little different for hardware accelerated transcoding of 4K timelapse movies, from .CR2 files. It provides a rather good quality of encoding the .CR2 to .JPEG and then onto .mov. I'm having a hard time seeing the difference between software and hardware encoded in that particular setup, that also makes up 90% of the movie requirements I do have for encoding.
I'm not entirely sure why a timelapse movie would be any better/worse in quality than a regular movie in a software vs. hardware encoder fight. As long as you don't care about encoding efficiency/time, you can always eke higher quality out of a well-optimised software codec than you can out of a hardware encoder at any given bitrate since software codecs can handle complexity much more easily. I don't have much experience with x265, but x264 is a spectacularly well-optimised software codec.
I don't know about the CR2 format but it seems odd you'd use a format like JPEG as an intermediary, unless you're using it in a lossless mode. JPEG compression itself will introduce compression artefacts itself which are themselves frequently hard to compress.
Regardless, as far as hardware vs. software encoding being transparent for your use case, chances are your bitrate is high enough and/or the rate of change in your timelapse are small enough for the common deficiencies of hardware encoders not to become obvious.
Besides the point though (other than for technical argument, the best kind of argument
) - if quicksync's good enough for you then it's good enough for you...!
I don't know about the CR2 format but it seems odd you'd use a format like JPEG as an intermediary, unless you're using it in a lossless mode. JPEG compression itself will introduce compression artefacts itself which are themselves frequently hard to compress.
Regardless, as far as hardware vs. software encoding being transparent for your use case, chances are your bitrate is high enough and/or the rate of change in your timelapse are small enough for the common deficiencies of hardware encoders not to become obvious.
Besides the point though (other than for technical argument, the best kind of argument
) - if quicksync's good enough for you then it's good enough for you...!I do use lossless compression, and I use it as intermediary, because the .CR2 files can't be read by Quick Sync and they hold all kinds of information that's just going to slow down the encoding, without contributing to quality (possively or negatively). Timelapse movies tend to have a different quality in hardware encoding, because of the source material being individual pictures. I can't tell you why that affects the quality of the encoding, but somehow it does.
I do have good experiences with H.264, it's a very good codec, but the H.265 have some significant benefits, such as better compression algorithm and improved quality, at the same bit rate compared to AVC compressions and it supports up to 8K.
The initial rendering of the videos is also intended to be handled by a workstation, QuickSync is only intended for transcoding if it's going to be needed, that way I don't have to invest in a power hungry CPU for a NAS.
I have no experience using x265, but I used x264 before starting encoding on an Nvidia GPU and lately also the Quick Sync for when I'm doing a 4K timelapse video. x264 works really well, but with the right parameters, hardware encoding yields a rather good result too. At least in my experience, especially with the newer APUs.
I might give x265 a go, once I get a better workstation, this old thing will not be able to handle that in a reasonable time.