It's back but is "Better Quality" any better?

So the absence of "Better Quality" in the "Computer" output setting in FCP 10.6 was an error.



I have never noticed any improvement when using it but I could be wrong.


Has anyone got any spare moments to test it out? Remember you will have to use clips with movement to show any possible difference.



Posted on Nov 16, 2021 7:45 AM

Reply
Question marked as Top-ranking reply

Posted on Nov 16, 2021 9:09 AM

The differences are absolutely negligible. I looked at it with a videographer, frame by frame. There's a lot of movement in the video, small objects in motion, a lot of motion blur, but no pixelization anywhere that we saw. The titles are sharp. The dots on the i are perfectly round with no jaggies even when zoomed in. I exported ProRes, H.264 Faster, and H.264 Better. All three were identical for all practical purposes. I thought the ProRes was slightly sharper, and could see that it would stand up better if it had to be reprocessed.


This was a 4K commercial, rendered, that was 35 seconds long. On a 2020 M1 MBP, ProRes exported in 31 seconds at 4.94 GB. Faster took 44 seconds and was 221.3 MB. Better took one minute 51 at 212.5 MB.

13 replies
Question marked as Top-ranking reply

Nov 16, 2021 9:09 AM in response to Ian R. Brown

The differences are absolutely negligible. I looked at it with a videographer, frame by frame. There's a lot of movement in the video, small objects in motion, a lot of motion blur, but no pixelization anywhere that we saw. The titles are sharp. The dots on the i are perfectly round with no jaggies even when zoomed in. I exported ProRes, H.264 Faster, and H.264 Better. All three were identical for all practical purposes. I thought the ProRes was slightly sharper, and could see that it would stand up better if it had to be reprocessed.


This was a 4K commercial, rendered, that was 35 seconds long. On a 2020 M1 MBP, ProRes exported in 31 seconds at 4.94 GB. Faster took 44 seconds and was 221.3 MB. Better took one minute 51 at 212.5 MB.

Nov 17, 2021 11:30 PM in response to Ian R. Brown

Previously I suspected that Faster used GPU while Better only CPU. But at least now FCP 10.6.1 seems to use GPU for both. For 1920x1080 Apple Devices .m4v was about 10 MB/s for both while Computer .mp4 is for some reason about 20 MB/s for both.


I have now switched to HEVC where there are not those options. But there I have to decide between fast 8-bit GPU and very slow 10-bit CPU (Mac mini 2018). Previously I have noticed that sometimes 10-bit HEVC is needed to suppress ugly gradations in water etc. And at least in one earlier 4K project the 8-bit HEVC had noticeable artifacts at chapter points depending where at the GOP the chapter happened to be while 10-bit was fine. I'll test this later with v10.6.1.

Nov 18, 2021 6:11 PM in response to Ian R. Brown

Ian, you could run ffprobe on the clip. This creates a very verbose output so try it on a short clip.

$ ffprobe -i inputfile -select_streams v:0 -show_frames 

and then look for pict_type

[FRAME]
media_type=video
stream_index=1
key_frame=0
pkt_pts=904
pkt_pts_time=0.030133
pkt_dts=904
pkt_dts_time=0.030133
best_effort_timestamp=904
best_effort_timestamp_time=0.030133
pkt_duration=1001
pkt_duration_time=0.033367
pkt_pos=54327
pkt_size=738
width=480
height=324
pix_fmt=yuvj420p
sample_aspect_ratio=N/A

pict_type=B

coded_picture_number=2
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
color_range=pc
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]
[FRAME]...

Nov 24, 2021 2:19 AM in response to Ian R. Brown

To inspect the GOP pattern I have used Avidemux and checked the frame type just by right/left arrow keys (frame to frame) or up/down arrow keys (I frame to I frame) or the corresponding buttons.


ffprobe can show the same info but the overwhelming output must usually be somehow filtered or the user can search a certain pattern like "[FRAME]" in the Terminal.


For example: QuickTime Player may show image artifacts when you scrub the timeline unless every I-frame is also an IDR (Instantaneous Decoder Refresh) frame i.e. pict_type=I and key_frame=1.


You can install ffmpeg and the bundled ffprobe with either Homebrew (faster to install and maybe more user friendly) or MacPorts (might be more robust and kosher for the purists). Both have good installation instructions although some basic UNIX skills might be needed.


https://brew.sh


https://www.macports.org/


ffprobe experts can chime in but I have stumbled on the following related commands:


Long output, frames separated by [FRAME] and [/FRAME] tags:


ffprobe -i movie.m4v -select_streams v:0 -show_frames


Save all I frames as .png. If the framerate is 30 then an image name of "out75.png" corresponds to a timestamp of 75/30 = 2.50 seconds. You can add -r 1000 if you want numbers to represent milliseconds:


ffmpeg -skip_frame nokey -i movie.m4v -vsync 0 -frame_pts true out%d.png


Display the timestamp for each keyframe:


ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 movie.m4v | awk -F',' '/K/ {print $1}'


ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pkt_pts_time -of csv=print_section=0 movie.m4v


Show keyframes:


ffprobe -show_entries frame=pict_type movie.m4v -of flat | grep I


Show key_frame=1/0 -- long output:


ffprobe -show_frames movie.m4v | grep key_frame


Nov 16, 2021 9:28 AM in response to Tom Wolsky

That sounds a pretty comprehensive test.


Most viewers won't be viewing on such a high quality screen at such a close distance.


Furthermore, as the video is skipping past during normal playback they will have no opportunity to detect even a fair amount of difference.


I endeavour to produce sharp, accurately coloured images and it dismays me when people insist on viewing them on badly adjusted TVs or even at an angle to the screen instead of head on.


Perhaps we shouldn't bother about quality .............

Nov 24, 2021 4:00 AM in response to Matti Haveri

Thanks for the details Matti but one line of your answer scares the proverbial out of me!


"Both have good installation instructions although some basic UNIX skills might be needed."


When I clicked on the Homebrew website, the sentences were simple and calm but I didn't understand a word they were saying. The fear of destroying my computers by ignorantly delving into Terminal is a very real one.


So I will probably stick with looking at. individual frames in Avidemux.


I have also discovered that it is excellent for doing a quick trim of a video.

Nov 24, 2021 4:11 AM in response to Ian R. Brown

> quick trim of a video


Previously I used 32-bit MPEG Streamclip to losslessly trim raw drone .mp4 footage for archive use in Mojave. Then searched a substitute for 64-bit macOS and found Avidemux with is a nice app for this. But also QuickTime Player seems to work well for this although it does not show I frames and allow edit to the GOP like MPEG Streamclip and Avidemux so there might always remain some extra frames in the output.

Nov 18, 2021 11:28 AM in response to Matti Haveri

> 4K project the 8-bit HEVC had noticeable artifacts at chapter points depending where at the GOP the chapter happened to be while 10-bit was fine. I'll test this later with v10.6.1.


This FCP 10.5.4 and Compressor 4.5.4 flaw seems to have been fixed and is no longer seen in FCP 10.6.1 and Compressor 4.6.


...


4K HEVC at 25 fps has the following repeating GOP pattern (checked with Avidemux):


IBPBPBPBPBPBPBPBPBPBPBPBPBPBPBP [31 frames, I + BP x15]

IBPBPBPBPBPBPBPBPBPBPBPBPBPBP [29 frames, I + BP x14]


Previously in FCP 10.5.4, if the chapter marker happens to be on a P frame, then the previous would-be-B frame becomes a P frame so that there are two adjacent PP frames -- the latter P frame and the remaining PB pairs then all have those blocky artifacts until the next I frame clears the movie until it happens again.


But in FCP 10.6.1 (and compressor 4.6) this does not happen anymore! If the chapter marker happens to be on a P frame, also now the previous would-be-B frame becomes a P frame but the chapter marker frame is now I frame followed by regular GOP pattern with no artifacts. (If the chapter marker is on a would-be-B frame, it is changed to I frame followed by regular GOP pattern with no artifacts).


https://discussions.apple.com/thread/252840042

Nov 19, 2021 8:14 AM in response to terryb

I used Avidemux 2.7.8 to check the GOP pattern -- it can show the movie and the IBP frames (at bottom left a buggy P frame is reported).



http://avidemux.sourceforge.net


Thanks for the reminder about ffprobe, here is its output for that same buggy P frame which in macOS 11.6.1 is an OK I frame:


ffprobe -i 4K_HEVC_08-bit_chapters.m4v -select_streams v:0 -show_frames 
[...]
[FRAME]
media_type=video
stream_index=1
key_frame=0
pkt_pts=2002
pkt_pts_time=0.066733
pkt_dts=2002
pkt_dts_time=0.066733
best_effort_timestamp=2002
best_effort_timestamp_time=0.066733
pkt_duration=1001
pkt_duration_time=0.033367
pkt_pos=217479
pkt_size=73849
width=3840
height=2160
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=P
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]
[...]


BTW, it seems this 4K 8-bit chapter marker artifact was fixed in macOS 11 rather than in FCP because now in macOS 11.6.1 there are no such artifacts in the old FCP 10.5.4 4K 8-bit output anymore.


4K 10-bit output is different because there are only I frames followed by a bunch of B frames with no P frames.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

It's back but is "Better Quality" any better?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.