M1 Max and Handbrake = kind of slow?

[aUsern@me]

The quality of the output is dictated by the quality of hardware encoder being used.

This is somewhat new info for me.

However, if you do get a Studio (or maybe as part of your testing in the Apple Store) give it a go and maybe you'll be pleasantly surprised.

Will do. Thanks again for taking the time to do the testing and the explanation.

I'm really curious, what is the application for re-encoding H.264 files to H.265 with the subsequent loss of quality? Is it just to reduce disc storage requirements for personal use?

I rarely go from H.264 to H.265, but if done correctly the quality loss should be nearly imperceptible. And the storage savings can be substantial. For 1080, you can fairly easily knock a 1/3 off the file size without degradation. Forty percent isn't unreasonable. For 4K, H.265 makes mass storage much more feasible.

If you have a large media library, the storage savings could really add up.

 

[PianoPro]

I rarely go from H.264 to H.265, but if done correctly the quality loss should be nearly imperceptible. And the storage savings can be substantial. For 1080, you can fairly easily knock a 1/3 off the file size without degradation. Forty percent isn't unreasonable. For 4K, H.265 makes mass storage much more feasible.

If you have a large media library, the storage savings could really add up.

I've never tried going from H.264 (or VC-1) to H.265, which is why I asked. I'm really skeptical about the quality degradation, but I've never seen that myself. So I will have to give that a try now. (Years ago I was involved in the design of some early 1080i/720p MPEG broadcast encoders.) But 4K Blu-ray is already H.265 so I'm not sure what you are doing there except perhaps re-encoding with more compression?

 

[eddie_ducking]

I've never tried going from H.264 (or VC-1) to H.265, which is why I asked. I'm really skeptical about the quality degradation, but I've never seen that myself. So I will have to give that a try now. (Years ago I was involved in the design of some early 1080i/720p MPEG broadcast encoders.) But 4K Blu-ray is already H.265 so I'm not sure what you are doing there except perhaps re-encoding with more compression?

I know to the professional eye there has to be degradation but personally, I can't tell and I'm guessing none of my family can otherwise something would have been said. I'm only doing 1080p H.264 (or DVD) -> H.265-10bit, I'm leaving anything that's already H.265 be (at present, though it might change in the future). I only did a few tests to H.265 (8bit) and didn't like the results as much as the 10bit so stuck with the 10. It might have been that increasing the CQ value for the 8bit would have worked but I just stuck with the 10, I'm not disappointed.

And yes, in my case, it's mostly to save NAS space. I'll soon be able to turn one of them off, since usage has dropped by over 50% (which should help with the leccy bills) . It's also had a noticeable effect on the loadings and available bandwidth on the wireless when multiple streams being played.

 

[aUsern@me]

This probably isn’t the best place to update Handbrake, VTB vs software, quality tests but since it started here, and it’s related to the Studio, this is where I’m placing it.

Per eddie_ducking’s suggestion, I finally made it back to the Apple Store to do some more tests. I really wanted to evaluate the quality of VideoToolBox on the Studio M1 Max (32GB, 24 GPU). I’m pretty much just itching for an excuse to buy one.

preemptive TLDR:
VideoToolbox on the M1 Max is crazy fast, but the quality just isn’t nearly good as software H.265. And, if you compensate by bumping up the quality, you might as well just stick with software H.264.

The M1 Max Pro flew through the renders, we’re talking 350+ fps. And though the Apple Store was loud, the machine itself seemed quiet. I checked activity monitor and during the encodes, the CPUs were around 650% while the GPU was only around 15%, which I found surprising. I thought it would be pushing the GPUs much more.

So the Studio Max was fast and quiet, but the resulting files are not very good - at least when compared to software. Caveat, nobody watches videos or movies this way. That is, I took a single frame and pixel peeped at various encode settings. When you’re actually watching this stuff as a video, the quality is much more fluid.

That said, the differences at similar megabits per second were very noticeable to me. I tried to choose a challenging frame, lots of shadows, high and low contrast, a lot of texture and color gradation. All tests were done using Handbrake 1.5.1 and their recommended benchmark file, “Tears of Steel.” This is frame 3:35:15 at 100%.

As a normal baseline, for HEVC content, I try and hit 2.5 - 3.0 Mbps for 8-bit, 1080p. “Tears of Steel,” is 1920x800 so 2.5 Mbps should result in a better-quality-than-I-normally-do encode.

As you can see, the 2.6 Mbps software encode (2, RF 24.5 in Handbrake) looks good. There’s definitely degradation. But I’m fairly confident that there’s little chance I’d notice while watching at 24 fps. The resulting file was 239 MB for 12 minutes. The original H.264 file (1) is 584 MB.

The 2.6 Mbps VTB encode (3, CF 46) looks really bad in comparison. There’s very noticeable texture loss and blurring. The bricks have lost significant detail and the atmospheric light in the leaves is blurry mess. So I bumped up the quality.

At 3.6 Mbps, the VTB encode (4, CF 56) is still not as good. Though the differences aren’t as drastic. Still the software encode is sharper with less texture blurring.

At 4.0 Mbps, the VTB encode (5, CF 58) starts being actually comparable. It’s till not as sharp as the 2.6 Mbps software encode, but I think it handles the gradations better.

But now we’re at a file that 54% larger.

Out of curiosity, I decided to try and produce a 370 MB H.264 re-encode (6) and compare it to the 370 MB CF 58 VTB encode. My 9700K did this at 115 FPS, which is still quite a bit slower than the M1 Max’s 360+ fps. But is still 2x as fast as my normal ≈60 fps H.265 encodes.

The quality of the H.264 re-encode at 4.1 Mbps is nearly indistinguishable from the original file and it’s just a little bit bigger than the best (5) VTB H.265 encode.

Now, some (a lot?) of you looking at the comparisons, may not see much difference at all. It’s harder to see the differences when viewing side by side. But, if you take the time to clip the images and place them on top of the original, the differences are much more drastic. But even if you don’t take the time to clip and overlay the images, it’s very obvious (to me, at least) that 3 and 4 are unacceptable. Five isn’t quite as good as 2 and it’s 50% larger in size - though it did encode 6x faster. Six is nearly perfect, and encoded very quickly while being just a little bit bigger than 5.

 

[arw]

I'm really curious, what is the application for re-encoding H.264 files to H.265 with the subsequent loss of quality? Is it just to reduce disc storage requirements for personal use?

Must be. A high drawback compared to a simple remux given the low storage prices and additional computing effort.
In OP‘s case it‘s simply used as a benchmarking tool.
edit: of course, if you just consume your media on a smaller TV or tablet, a noticeable size reduction justifies a (not-so-noticeable) decrease in quality.

 

[PianoPro]

Must be. A high drawback compared to a simple remux given the low storage prices and additional computing effort.
In OP‘s case it‘s simply used as a benchmarking tool.
edit: of course, if you just consume your media on a smaller TV or tablet, a noticeable size reduction justifies a (not-so-noticeable) decrease in quality.

Yeah, I suspected it was to view on a tablet or phone or something small. I can't imagine giving up video quality to re-compress previously compressed video for quality viewing. I'd never do that for my home theater projection system or even for my 85" family room TV. Just transfer to a video server in a mkv container instead with no degradation of video quality.

 

[aUsern@me]

I can't imagine giving up video quality to re-compress previously compressed video for quality viewing. Just transfer to a video server in a mkv container instead with no degradation of video quality.

Well sure, if you have unlimited storage space or a small library.

Re-encoding, if done well, can save tremendous amounts of disk space with no functional loss in quality. Just take a look at the image I posted. Even going from H.264 to H.264 again can save tremendous space (+33% savings in the example) without a noticeable loss in image quality. And that's taking just one frame and really scrutinizing it. If you're watching it normally, there's no way you could ever tell the difference.

I'd be willing to bet there's no way you could tell the difference between a good HEVC encode and the H.264 "original" during a normal viewing - except the HEVC file would take up 40%+ less space.

 

[PianoPro]

Well sure, if you have unlimited storage space or a small library.

Re-encoding, if done well, can save tremendous amounts of disk space with no functional loss in quality. ...

I'd be willing to bet there's no way you could tell the difference between a good HEVC encode and the H.264 "original" during a normal viewing - except the HEVC file would take up 40%+ less space.

Are you watching on a 120" or even a 100" screen in a state of the art home theater? I haven't specifically tried re-compressing H.264 Blu-ray (or VC-1 Blu-ray) to HEVC, but I'd be very, very surprised to not see significant decoding/re-encoding artifacts, which I've seen in trials re-encoding any compressed format to H.264.

Anyway, the cost of 50 TB (my current size) of disc space for a video server is less than $1K, which is perhaps 5% or less of the cost of the original Blu-ray's and HD-DVDs being put on a server. (Approximately 30 discs per TB, 50 TB's for 1500 discs, $15 average original disc cost. $22,500 total disc cost.)

So I wouldn't do that unless it was for viewing on a very small screen or other casual viewing, not a home theater. Just not a significant cost. Not trying to tell you what to do, just expressing why I wouldn't.

 

[aUsern@me]

Are you watching on a 120" or even a 100" screen in a state of the art home theater? I haven't specifically tried re-compressing H.264 Blu-ray (or VC-1 Blu-ray) to HEVC, but I'd be very, very surprised to not see significant decoding/re-encoding artifacts, which I've seen in trials re-encoding any compressed format to H.264.

Prepare to very very surprised?

Again, just look at the image I posted. That's examining a single still frame at 100%. A couple of those stills are very similar to the original. I'd call them almost functionally identical as a still. If they were moving there's no way you would notice the difference. It's like insisting that lossless audio is better than a 256 Kbps AAC file. Sure it is, but for the vast majority of situations there's no functional difference. An original will always be better, but that can be taken to the absurd. Nobody stores using uncompressed video. Nobody uses mpeg2 anymore. H.264 is very good, but H.265 is simply more efficient.

Re-encoding isn't for everyone's home situation. Personally, I don't have the time for my media library. But I do recognize that it would save me a ton of space.

 

[PianoPro]

Prepare to very very surprised?

Again, just look at the image I posted. That's examining a single still frame at 100%. A couple of those stills are very similar to the original. I'd call them almost functionally identical as a still. If they were moving there's no way you would notice the difference. It's like insisting that lossless audio is better than a 256 Kbps AAC file. Sure it is, but for the vast majority of situations there's no functional difference. An original will always be better, but that can be taken to the absurd. Nobody stores using uncompressed video. Nobody uses mpeg2 anymore. H.264 is very good, but H.265 is simply more efficient.

Re-encoding isn't for everyone's home situation. Personally, I don't have the time for my media library. But I do recognize that it would save me a ton of space.

I can't think of a worse way of assessing the quality of video than to look at a still frame. And I have no interest in reducing the amount of disc space needed for a video server since the cost is trivial compared to the original video content.

But it wasn't my purpose to argue with you about the quality. If it is satisfactory for your use that's all that matters.

 

[SimplePanda]

I'm really curious, what is the application for re-encoding H.264 files to H.265 with the subsequent loss of quality? Is it just to reduce disc storage requirements for personal use?

Older thread but I'll chime in: In my case, I'm backing up my Blu-ray disc collection to my NAS (which also lets me watch any of my discs on Plex). The Plex app on the Apple TV 4K has some issues playing VC-1 encoded Blu-ray MKVs. For those discs, a straight remux of the BD content isn't watchable.

So, I'm re-encoding my VC-1 discs as HEVC (with all audio tracks in passthrough). They play perfectly and deliver watchable/comparable quality to VC-1 at about 50% of the bitrate (typically ~15Mbps for a 30Mbps VC-1 1080p disc). The Apple TV can play these files with hardware acceleration/decode (unlike VC-1), and they work perfectly.

The original BD/MKV remux files are going into a "Backup" folder and the re-encoded HEVC files are in my Plex library for watching. Ironically, this is costing me more space but, as many point out, space is cheap.

 

[aUsern@me]

They play perfectly and deliver watchable/comparable quality to VC-1 at about 50% of the bitrate (typically ~15Mbps for a 30Mbps VC-1 1080p disc).

So without actually seeing your files, I'm guessing that ≈ 15 Mbps is going to be functionally identical. Even though space is cheap, you could go a lot lower on your bit rate and still achieve amazing quality.

Lower your bitrate to 10 Mbps and prove it to yourself. Despite what PianoPro thinks, comparing a challenging individual still frame from the original to your compressed files really is a true litmus test. Logically, if you can't spot the differences in the still, there's no way you'll notice the differences at 24 fps.

From what I've observed, using software HEVC encoding, 2.5 Mbps for 8 bit, 1080p offers really good quality. Five Mbps would be nearly identical to the original. If you're using VTB at 15 Mbps, I'm positive you're getting fantastic quality. But I'm also pretty certain you could just use software H.264 and get the same fantastic quality, at the same bit rates, and it would be less resource intensive on playback.

Not that Netflix is necessarily the pinnacle of quality, but I think I read that they target 3-4 Mbps for their 1080p HEVC streams.

A lot of what is acceptable, or even nearly identical, compression can be very file dependent. For instance, HEVC just butchers old film grain. By the time you find an acceptable bit rate, you probably won't be saving much space at all. But for most "modern" films, software HEVC at 5 Mbps produces excellent results. IMO, for most situations, anything above 7-8 Mbps for 8 bit, 1080p, HEVC software encodes is simply wasting space.

 

[aUsern@me]

However, for a 1-pass vtb encode, I settled on 15Mbps as transparent enough that I can watch a file and not be annoyed.

You will definitely not be wanting for quality, under any circumstances that I can think of, at 15 Mbps.

8Mbps software HEVC @ 2-pass could be fine in 2-pass, depending on the content, sure.

2-pass produces worse quality than single pass.

 

[PianoPro]

"Despite what PianoPro thinks, comparing a challenging individual still frame from the original to your compressed files really is a true litmus test."

I'm not trying to start an argument, and whatever you think is good enough quality is all that really matters for your own use. So I won't continue to comment about it. But as someone that has designed professional broadcast video encoding/decoding/deinterlacing/scaling algorithms and equipment, that is just completely false.

 

[PianoPro]

The Plex app on the Apple TV 4K has some issues playing VC-1 encoded Blu-ray MKVs. For those discs, a straight remux of the BD content isn't watchable.

I don't recall ever seeing a problem with VC-1 on Apple TV 4K. Would you list a few common titles that have this problem? If I don't have one of them I could get one and try it. Have you seen the same problem with InFuse as Plex?

 

[SimplePanda]

I don't recall ever seeing a problem with VC-1 on Apple TV 4K. Would you list a few common titles that have this problem? If I don't have one of them I could get one and try it. Have you seen the same problem with InFuse as Plex?

First two VC-1 MKV's in my backup library are my 25th Anniversary Edition of Back to the Future, and Baraka. Both start dropping frames randomly and lose audio/video sync. You can usually see dropped frames within 5 minutes of playback.

I can restore sync and view the "stuttered" parts of the playback by simply pausing, skipping back, and playing; so the issue isn't in the encoding itself and the player is fully capable of playing the video.

The MKV's are simply the original Blu-ray media ripped and remuxed to MKV with all audio, video, and subtitle data in full passthrough mode. So it's definitely not the media or encodes. The fact that I can skip back/forward and see the "problem areas" on repeat suggests it's also not the packaging/muxing.

It looks like a memory leak, perhaps. I've got a ticket open with Plex's iOS team (they have logs, demo clips, etc from me and are looking into it). There appears to be no issue on the first generation Apple TV 4K (A10X based), but my second generation (A12 based) stutters reliably. No issues with playback on any other media or app.

No ETA for a fix, so in the meantime I'm just converting all those VC-1 encodes to HEVC.

 

[PianoPro]

First two VC-1 MKV's in my backup library are my 25th Anniversary Edition of Back to the Future, and Baraka. Both start dropping frames randomly and lose audio/video sync. You can usually see dropped frames within 5 minutes of playback.

Dang I have the Ultimate Edition (4K and 1080p) of BttF, which I believe has the 30th Anniversary 1080p versions because they are H.264 not VC-1. I don't have Baraka (no interest in that one). Anything else, because I don't want to buy another set of BttF?

There appears to be no issue on the first generation Apple TV 4K (A10X based), but my second generation (A12 based) stutters reliably. No issues with playback on any other media or app.

That is interesting. My AppleTV 4K is the 1st gen, so if you only see a problem with the 2nd gen that would explain why I have never seen a VC-1 problem (I have many backed up, including HD-DVDs). But if you want me to check any on my 1st gen ATV 4K tell me some more titles you have problems with.

Let us know if Plex resolves this. Do you see the same problem with InFuse?

 

[SimplePanda]

Let us know if Plex resolves this. Do you see the same problem with InFuse?

Files all work fine with InFuse. I think this is one of the reasons Plex support escalated it as a bug to engineering. Files play fine in VLC, InFuse, etc.

Other titles that stuttered for me: Serenity, Natural Born Killers, BTTF 2. I haven't tested many more as it just felt like a VC-1 problem that I can reproduce. Indeed, every VC-1 title I've tried has had issues; some more pronounced than others.

 

[aUsern@me]

This is almost always incorrect.

A 2-pass encode with an upper rate cap that is reasonably above your average will almost always give you better results than a single pass encode.

Presuming you're talking about "2-pass encoding" in relation to Handbrake, you're just not right. Two pass encoding is needed/used when you must hit a certain target size.

As opposed to CRF, you need to use two pass when a file can't be bigger that 1 GB, for instance. Otherwise a single-pass CRF will result in a better quality file. Given that you're forcing your frames to be collectively no bigger than 1GB, the quality simply can't be as good as a file without such constraints, i.e. single pass CRF.

"A 2-pass encode with an upper rate cap that is reasonably above your average," is the same thing as encoding at larger bit rates, which of course would produce more quality, regardless if it's 1-pass or 2-pass.

But don't take my word. From the FFmpeg FAQ:
Will two-pass provide a better quality than CRF?
No, though it does allow you to target a file size more accurately.

I'm not trying to start an argument…But as someone that has designed professional broadcast video encoding/decoding/deinterlacing/scaling algorithms and equipment, that is just completely false.

Good, you're right there's no need for an "argument," per se. But, we can certainly debate. You keep telling me I'm incorrect, but haven't put forth any reasoning.

Examining individual frames seems obvious enough to me, but I'll elaborate.
You pixel peep on one frame from the original and compare it to the re-encoded frame. Because it's not moving, you can exactly compare each individual pixel and how they interact with their neighbors. You can overlay the frames and toggle for a visual difference. You can run difference filters to get a more quantitative analysis.

You then decide that, for the setting you've chosen, weighing speed/space/quality, you've arrived at the perfect balance. Or at the very least, a "good enough" balance. If you're chosen a particularly demanding frame from a scene, and you're satisfied with the results, you will likely be satisfied with the same setting for the entire scene and less demanding scenes.

If inclined, you repeat that process for 23 more frames, or however long is needed, to convince yourself that your quality is holding up over time. Rinse, wash, repeat until you're satisfied. Frame 1 is "perfect*," fame 2 is "perfect," frame 3 is "perfect," etc… You put those frames together consecutively and you have a moving picture of the desired quality.

*perfect, acceptable, good enough, passable or whatever quality you're targeting.

 

[PianoPro]

... You keep telling me I'm incorrect, but haven't put forth any reasoning. Examining individual frames seems obvious enough to me, but I'll elaborate...

I wish I hadn't spoke up about this because I didn't mean to insult you, which it appears I may have. Again, as long as you are satisfied with the results you get from your method of analysis, then that's all you need to know. This is not a good venue for discussing the complexities of video processing (nor do I have the time to do it), a subject that has consumed most of the last 30 years of my career as a product designer and engineer.

So I will only make these LAST comments that may steer you in a direction of learning more about the subject if you care to do that. What you are missing is that video can only be understood in a 3-dimensional frequency domain - video is defined by motion (time-varying images). It's a time sequence of 2-dimensional spatial images that to preserve quality must be processed and analyzed in 3-D spatio-temporal space, not 2-D spatial space. The process of lossy video compression (all the systems we are concerned with) take advantage of the human visual system's spatio-temporal resolution limits.

Video compression literally throws away 3-dimensional frequency information (and thus suffers artifacts from aliasing in 3 non-separable [in general] frequency dimensions) to save transmission bandwidth or storage space to some accepted perceived level of video motion image quality degradation based on our visual system's 3-D spatio-temporal resolution limits. We use motion-compensated filtering and motion-compensated prediction in our compression algorithms. Therefore, you can not make comprehensively valid judgments about video image quality by analyzing only 2-D still images and ignoring the 3-D motion aliasing artifacts that result from video compression.

I will refer you to a book on this subject of video processing/analysis from my library. I picked this particular book (one of my favorites) because there are excerpts that you can read on line (the book is otherwise quite expensive and gets quite technical). It's Motion Analysis and Image Sequence Processing.

Motion Analysis and Image Sequence Processing

link.springer.com

I will quote part of a paragraph from the introduction that directly addresses what we are talking about.

Since image sequences can be viewed as being a series of still images, why are we concerned with special algorithms for image sequences? Can't we apply the vast variety of well-known processing and analysis algorithms that have been developed for still images to image sequences on a frame by frame basis? The need for algorithms especially designed for image sequences can be rationalized by the following two arguments: (i) time-varying phenomena and motion cannot be inferred from individual still pictures, and (ii) more efficient and powerful processing algorithms that utilize temporal information, such as the interframe motion vector field and temporal correlations, in addition to the spatial information can be developed for image sequences.

I hope that satisfies your request for "reasoning" on this issue.

 

[aUsern@me]

PianoPro, I think you've really lost the plot.

Though I certainly can't disagree with much of the substance that you've written and quoted, it has nothing to do with what we're discussing. Were I taking a series of still photos, and then applying regular photo jpeg compression to each frame, and stitching it together you might have a point. But that's not what's happening.

We're simply trying to evaluate the different compression results of professionally developed, and thoroughly vetted, video coding formats after a file has been processed though it. Were you and I designing a VCF from scratch, we'd certainly take everything you wrote/quoted, and much more, into account. Luckily, the fine people who developed AVC and HEVC have already done that work. You do agree that AVC/HEVC already account for temporal and spatial correlations, right?

"How close are we to the original?" That's all we're asking. Answering that question is much easier by evaluating a still frame, or a series of still frames, taken from a video that's been run through a VCF that's already accounted for temporal and spatial information.

That is, in your effort to dismiss the merits of evaluating a still frame you've forgotten that the said frames have been run through the processes and methods you're attempting to use to dismiss the evaluation.

 

[PianoPro]

"How close are we to the original?" That's all we're asking. Answering that question is much easier by evaluating a still frame, or a series of still frames, taken from a video that's been run through a VCF that's already accounted for temporal and spatial information.

Astonishing! What part of the bolded words from the Motion Analysis and Image Sequence Processing quote did you not understand?

Can't we apply the vast variety of ... ANALYSIS algorithms that have been developed for still images to image sequences on a frame by frame basis? ... (i) time-varying phenomena and motion CANNOT be inferred from individual still pictures,

Analyzing "How close to the original" you are by "evaluating a still frame, or a series of still frames" is EXACTLY what that quote says CANNOT work for VIDEO (time-varying image sequences) because it does NOT evaluate time-varying phenomena and motion in video.

No more. Good day.

 

[aUsern@me]

Analyzing "How close to the original" you are by "evaluating a still frame, or a series of still frames" is EXACTLY what that quote says CANNOT work for VIDEO (time-varying image sequences) because it does NOT evaluate time-varying phenomena and motion in video.

Except that what you're failing to acknowledge is that the still image is from a video that's already been through a VCF (twice in our examples) that have already compensated for "time-varying phenomena and motion."

Your quote is arguing that analysis techniques used for photos (i.e. still images) cannot be applied to moving images. Nobody is arguing otherwise. What you're failing to realize is that in this case, the still image is directly plucked from a video that's had temporal and spatial algorithms applied to during compression.

Just answer this question: if an invidual frame has been plucked from an AVC/HEVC video, has it or has it not been already rendered considering spatial and temporal aspects of the preceding and subsequent frames?

 

[PianoPro]

So now you pose a question to me to drag me back into this exchange again?

Just answer this question: if an invidual frame has been plucked from an AVC/HEVC video, has it or has it not been already rendered considering spatial and temporal aspects of the preceding and subsequent frames?

Sure, but this is about a method to evaluate the visual quality of the compression, not about the techniques used to compress the video. You have been arguing that you can evaluate the resulting perceptual video quality with still frames. You can not see temporal artifacts looking at a still frame.

Wheels on a car can appear to spin backwards in a video. That is a gross result of temporal aliasing. Can you see that on a still frame of video? There are all kinds of temporal artifacts in compressed video that simply can not be seen by examining a still frame. Flickering, floating, mosquito noise are examples of temporal artifacts. The compression algorithms and rates used along with the spatio-temporal frequency components of the specific image sequences (video) determine the type and amount of video spatio-temporal artifacts. But you can't see, measure, or evaluate the temporal artifact quality of video on a still frame.

Again, read the previous link I gave you, or try this one (it is much less technical) if you really care to understand or learn something (which at this point I really doubt you do).

Characterizing Perceptual Artifacts in Compressed Video Streams
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.719.9892&rep=rep1&type=pdf

Here's a simple statement from that paper that directly addresses the issue of temporal artifacts.

Both spatial and temporal artifacts may exist in compressed video, where spatial artifacts refer to the distortions that can be observed in individual frames while temporal artifacts can only be seen during video playback.

 

[aUsern@me]

You can not see temporal artifacts looking at a still frame.

You absolutely can see temporal artifacts by looking at a still frame - when comparing it to the original source.
Mosquitoing is the perfect example of this. If the original frame has no mosquitoing and your compression method introduces it, how could you not notice it in a still?