By: Chester (lamchester.delete@this.gmail.com), November 19, 2020 3:45 pm
Room: Moderated Discussions
Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 3:04 pm wrote:
> Chester (lamchester.delete@this.gmil.com) on November 18, 2020 2:06 pm wrote:
> >
> > 1000 kbps is way too low for any res today. Youtube isn't exactly the champion of quality. They recommend
> > 5 mbps for 720p30, and 8 mbps for 1080p30. You can push a bit lower if you need to save every last
> > bit, but I've never liked the results for say, 3.5 mbps w/720p30. 1000 kbps is ridiculous.
> >
> Oh sure, it will give you bad video quality and always had. But, and that is what is important here, it doesn't
> particularly change the character of the encoding. Well, if it was 4000 kbps, a bit more time would be spent
> in CABAC and a bit less in the motion search, prediction and so on SIMD functions. But I don't think it will
> be a huge shift in the character, for that you would likely have to raise the bitrate much, much higher.
Well yeah, I find 10 mbps for 1080p generally means I'm not annoyed by artifacts.
> So while I dislike that as a choice of bitrate for encoding, I don't see a problem with it when benchmarking.
> It's completely insignificant issue, compared to the beyond ridiculous decision to run just compiled
> C code and not compiling with assembly. The devs would tell you to FO. They hated when Linux distro
> packagers failed to compile with yasm, because it made their software look super bad.
So ideally we'd have a realistic bitrate and a x264 compiled with assembly. Yeah, I agree, and that's what other review sites are doing already.
> Chester (lamchester.delete@this.gmil.com) on November 18, 2020 2:06 pm wrote:
> >
> > 1000 kbps is way too low for any res today. Youtube isn't exactly the champion of quality. They recommend
> > 5 mbps for 720p30, and 8 mbps for 1080p30. You can push a bit lower if you need to save every last
> > bit, but I've never liked the results for say, 3.5 mbps w/720p30. 1000 kbps is ridiculous.
> >
> Oh sure, it will give you bad video quality and always had. But, and that is what is important here, it doesn't
> particularly change the character of the encoding. Well, if it was 4000 kbps, a bit more time would be spent
> in CABAC and a bit less in the motion search, prediction and so on SIMD functions. But I don't think it will
> be a huge shift in the character, for that you would likely have to raise the bitrate much, much higher.
Well yeah, I find 10 mbps for 1080p generally means I'm not annoyed by artifacts.
> So while I dislike that as a choice of bitrate for encoding, I don't see a problem with it when benchmarking.
> It's completely insignificant issue, compared to the beyond ridiculous decision to run just compiled
> C code and not compiling with assembly. The devs would tell you to FO. They hated when Linux distro
> packagers failed to compile with yasm, because it made their software look super bad.
So ideally we'd have a realistic bitrate and a x264 compiled with assembly. Yeah, I agree, and that's what other review sites are doing already.