Is there a point in using QuickTime Player's 'maximum' quality for streaming Hi8 analog tapes?

I recently tested this. I'd not use the "new" QuickTime Player in any setting because it forces deinterlacing with mean/blend mode. So users might want that, though.

I'd use either the an old Mac with built in Firewire and import with the old iMovie v4-6 as DV-encoded interlaced rectangular pixels that the user can then post-process and re-encode as desired. Importing with Final Cut Pro works in Sequoia with FW-Thunderbolt-USB-C adapters but unlike old iMovie, FCP can not be forced NOT to break bad tape spots into multiple scenes, see below. I have all my old DV/D8 tapes archived as .dv files with old iMovie v4-6 and I have used Final Cut Pro or ffmpeg to post-process those old .dv movies in later macOS like Sequoia. The old QuickTime Player Pro 7 (works in Mojave but no longer sold) has "Device Native" import option and Final Cut Pro import the same way as DV encoded .mov.

The old .dv files are about 12 GB/hour (about 216 MB/minute). I'd currently edit and re-encode them to square pixels with "bob" deinterlaced double frame rate (PAL 720x576 scaled to 788x576 and cropped to 768x576 and 25 to 50 fps) as 10-bit about 5-10 Mb/s H.265 and AAC wrapped as .mp4.

Transfer from Mini DV video camera has gh… - Apple Community

Final Cut Pro 10.7-11.0 imports 720x576 25 fps bottom field first interlaced, overall 30.5 Mb/s, timecode .mov (DV, 16 bit 48.0 kHz 1536 kb/s PCM Little / Signed) from that PAL camcorder (4:3). My old .dv files archived from iMovie 1.0.2-6.0.3 are essentially the same except .dv, overall 28.8 Mb/s, no timecode and PCM Big / Signed. New clip at each scene break.

So I'd recommend FCP import for the quality I am used to, although that must be deinterlaced for computer playback unless longer shutterspeed was used making the footage essentially progressive.

On the other hand, QuickTime Player.app 10.5 (Mojave, Sonoma, Sequoia) "Maximum" setting imports 702x576 25 fps, overall 40.3 Mb/s, timecode .mov, ProRes 422, 16 bit 48.0 kHz 1536 kb/s PCM Big / Signed, and "High" setting imports 585x480, overall 4351 kb/s, timecode .mov, AVC, 48.0 kHz 320 kb/s AAC, both as progressive.

When booted to Mojave or earlier, the old QuickTime Player 7 Pro "Device Native" setting imports 720x576 25 fps bottom field first interlaced, overall 30.5 Mb/s, timecode .mov (DV, 16 bit 48.0 kHz 1536 kb/s PCM Little / Signed) from that PAL camcorder (4:3). All scenes are imported to the same .mov (no automatic new clip at each scene break).

cjp987 wrote:

I just compared a video captured with "Maximum" quality to the same video compressed with the H.264. The compressed version looks way better. The original is grainy while the compressed looks very crisp. I guess there is a lot of correction that goes on during the compression that makes it look better. They both suffer from what I guess you would call ghosting or doubling of the image when there is movement. I thought this is what deinterlacing was suppose to correct.

QT Player "Maximum" (PAL, I guess NTSC is slightly different) is the original tape resolution 702x576 with very large ProRes codec so it is meant for further editing and re-encoding.

QT Player "High" (PAL) is somewhat "worse" 585x480 resolution already with small H.264 codec so it is meant for delivery.

As you discovered, QT Player deinterlaces both so there is that "ghosting" in moving scenes.

The old QT Player 7 "Device Native" is the original tape resolution 720x576 (yes, also 702x576 is original but I won't go to tech details here) with largish DV codec so it is meant for further editing and re-encoding. But it preserves interlacing so there are interlacing "stripes" or "ghosting" or "neither visual glitch" in moving scenes depending how it is viewed (in VLC etc) or deinterlaced and re-encoded for delivery (in Handbrake, Shutter Encoder, Final Cut Pro, ffmpeg etc). Naturally I prefer the last option (and do a "bob" deinterlace which preserves both interlacing fields in 25 fps PAL and outputs it as double frame rate 50 fps). The new QT Player makes that impossible because it deinterlaces as "ghosting" method when importing no matter what. So I personally would avoid that and use other apps to import DV/D8 tapes (old QT Player 7, old iMovie v4-6, Final Cut Pro etc).

cjp987 wrote:

So what happens if you take an H.264 encoded video and do further editing (just clipping or splicing of video clips). Does the decode/re-encode process further degrade the video?

H.264 is a delivery format not really meant for further editing but that has not stopped people doing that.

Yes, H.264 can be losslessly be cut and trimmed with straight cuts, but only "to the GOP" or group of pictures that usually happen at about 1-8 second intervals. Apps like QT Player cut to those GOP I-frames and just hide the non-cuttable I&P frames that some apps like Avidemux can then reveal.

Any further editing needs lossy re-encoding. And repeating that leads to "generation loss" and even more quality loss.

On the other hand, the much larger ProRes files can be edited frame accurately because it is, erm, an editing format with much less compression so it is not meant for delivery.

Interlacing (and rectangular pixels, and NTSC 30/1.001 ≈29.97 frame rate) are a nuisance from the past when ancient cathode ray tube TV's and technology still needed such clever tricks.

Interlaced footage has two temporally different lines with a field rate of 50 (PAL) or 60 (NTSC) that together make frames at half of the field rate. But in moving scenes they are different and if you put them on top of each other you get that ghosting or stripes depending how you view it.

New TV's and computer screens are not interlaced but progressive so those ugly interlacing lines must somehow be removed from the same frame. One common option is just to delete the other line and maybe interpolate its contents. The other "Bob Weaver Deinterlacing Filter" method is to preserve both lines, interpolate and double the frame rate with slightly smoother motion.

cjp987 wrote:

It looks like by default my camera recorded in 12-bit:

So it 16-bit, but 32000 Hz???

s16le seems to indicate that one channel of 32 kHz stereo audio is stored in a 16-bit container in the DV stream but there is room for another such channel because only 32 kHz was used. 48 kHz would have occupied all that space with better quality.

(le = little-endian (Intel CPU default most commonly used) while be would be big endian (Motorola processor which old Macs used) -- refers to Jonathan Swift, who in Gulliver's Travels (1726) used them to describe the opposing positions of two factions in the nation of Lilliput. The Big-Endians, who broke their boiled eggs at the big end, rebelled against the king, who demanded that his subjects break their eggs at the little end.)

The factory default 12-bit audio option in DV/D8 camcorders is "historical" now and was not very useful even then.

Use 16-bit single stereo (2 tracks) unless you intend to perfom in-camera "overdubs" (assuming your camera supports this - many do not) in which case 12-bit means there's "room" in the signal for an extra stereo pair for a voiceover or music.

Modern editing software has more or less obviated the need to record 12-bit audio when shooting video but some apps might produce audio glitches or audio sync issues with 12-bit 32 kHz audio. You can convert to 48 kHz to but you can't restore 16-bit 48 KHz audio quality.

LPCM/WAV bitrate is 1536kb/s ONLY when the sampling rate is 48KHz and the quantization is 16bit (16bits x 48000Hz x 2, the 2 is for 2-channel). A 12bit, 32KHz, 2-ch WAV file will have a bitrate of 768kb/s (12 x 32000 x 2). These specs were chosen for DV so that two of the latter can fit in the space occupied by one of the former (choosing 12bit setting in the audio in a DV/D8 camcorder affords TWO 2-ch pairs, as against only one for the 16bit setting).

iMovie v1-6 has a setting to split scenes into smaller clips if there is a break in the timecode (i.e. the recording was halted). If that setting is turned off, iMovie v5-6 no longer has a maximum clip size of 2 GB (=9 minutes 27 seconds) previous versions had. I guess some versions did not add a file suffix .dv to its Media files (you can just grab the imported DV movies from the iMovie project folder or ctrl-click and open the project package later versions use, and archive them).

Various iMovie 1-6 versions had various irritating bugs but I had workflows to avoid them. Let me know if you plan to use some version so I can dig a memo for it.

In the past I used MPEG Streamclip (great app that runs up to Mojave) to deinterlace and export as compressed .mp4. So one great and easy option is to use that and call it a day because MPEG Streamclip handles the gory details like converting rectangular DV pixels to square pixels etc behind the scenes very nicely and accurately.

MPEG Streamclip can drill also into the newer iMovie project package, open the tiny reference .mov that contains the movie the user has edited, and export THAT as .mp4. Very handy.

But MPEG Streamclip does not support bob deinterlacing and I felt bad about throwing 50% off from the input so I now use ffmpeg for that and IMO the quality is good and better than with FCP (but not much better compared to MPEG Streamclip output with much less fuss).

Other options are to use Handbrake or Shutter Encoder (I have not tried to use VLC for this) to convert .dv to .mp4 but there are numerous options to choose from while MPEG Streamclip has a cleaner interface. Shutter Encoder can also run cookbook-style readily made ffmpeg commands via its GUI which is great for people who are afraid using the Terminal.

Importing as .dv or .mov with the DV codec is lossless (*) compared to the original DV/D8 tape so just use that for archiving (* bad tape spots and other hiccups while importing are flies in the ointment so there might be a few dropped frames per hour, though).

If the old Mac with built-in Firewire works, you might try the oldie and goodie QuickTime Player 7 with its "Device Native" import setting (it works up to Mojave). QuickTime Player 7 "Pro" licenses are no longer sold and I have not tried if that is needed for importing, though.

Download QuickTime Player 7 for Mac OS X v10.6.3 - Apple Support

But proceed with the new QuickTime Player and see if the quality is OK for your needs.

FWIW I no longer bother burning video-DVDs. They are clumsy to use and optical media and devices are being phased out. I have lots of old video-DVDs made with iMovie and iDVD collecting dust. Instead, I store old home movies as .mp4 movies on computer drive archives and copy them to iPads for viewing or thumb drives to view on smart TVs.

cjp987 wrote:

without "clip per scene" enabled, the clip size will be 1hr. I can't find any way to control that.

Just pause the import so a new clip will be created when you re-start import. You might want to rewind the tape slightly before starting re-import so the are no skipped frames in between.

In the past I created around 9 minute clips for the archive by editing the material in iMovie and exporting selected clips from iMovie as a single .dv file (some versions had issues making that step non-lossy so I had to avoid certain workflows that caused that). But in your situation that is a clumsy approach that takes too much time and extra effort.

You usually join the clips in the editing phase and export them as .mp4 so joining .dv files is usually not needed. But AFAIR MPEG Streamclip can losslessly join .dv files (works up to Mojave).

http://www.squared5.com/

It seems you use iMovie 5, right? Below is a link to my iMovie HD 5 memo .html -- download it (via the downward arrow at top right, you do not need to login to Dropbox), and open or drop it on the web browser to read it (the link might be deleted here but it should be in your email. I have similar memos also for iMovie 4 and 6). It is just a memo about all possible issues that might cause problems -- generally I liked old iMovie.

https://www.dropbox.com/scl/fi/vfggx8zklimbpp0espexl/iMovie_HD_5_bugs.html?rlkey=7u39dkmyxy8syu7qbept44r8d&dl=0

While you are at it I'd recommend renaming the imported .dv clips with a date in YYYY-MMDD-hhmm-ss.dv format (1998-0601-1200-00.dv etc, including seconds. Just use your best guess about the old date) so it is then easier to add metadata dates and other metadata to the exported .mp4 movies.

Movie dates and Photos.app - Apple Community

cjp987 wrote:

With 4:3 NTSC scale 720x480 to 648x480 and then crop to the final 640x480.

I understand you are trying to crop the artifact at the bottom of the image

No, that relates to converting rectangular DV pixels to square pixels which computer monitors use. If that is not done, then circles will not be circles but ovals in the output.

Ignoring the artifact issue, I thought going from 720x480 to 640x480 was how the scaling (rectangular pixels to square) was normally done.

Just scaling to 640x480 is the often used quick and dirty way of doing that. The aspect ratio error goes unnoticed unless looked for.

Another way to reach the same goal with 4:3 NTSC 720x480 DV is to crop 4+5 pixels from both sides to 711x480 and then scale to 640x480.

Read all the gory technical details in the link above. Just a snippet from that page about NTSC which is even more weird than in PAL:

"525/59.94 systems have a line length of 63+5/9 (63.555...) µs, of which 52+59/90 (52.6555...) µs is the "active" part that contains actual image information. (The rest is reserved for horizontal blanking.)

52+59/90 µs × 13.5 MHz = 710.85 samples (pixels) per scanline.

In the vertical direction, there are 484 complete scanlines and 2 half lines. As above, all of them get digitized and half lines will be treated as if their missing other half belonged to the active picture, giving a total of 486 scanlines.

Thus, the active image area at 13.5 MHz sampling is 710.85×486 pixels. This is the actual area that forms the 4:3 (or anamorphic 16:9) frame.

However, we cannot use partial pixels in any practical video work. Therefore, the number 710.85 needs to be rounded up to 711, and we get a 711×486 pixel frame instead.

711 samples equals to 52+2/3 (52.666...) µs at 13.5 MHz, so the rounded-to-the-nearest-pixel active area is a little bit wider than it ideally ought to be. Fortunately, the difference of 0.0111... µs is (for all practical purposes) insignificant, and well within the tolerances of NTSC-M specifications. [snip]"

cjp987 wrote:

"start a new clip at each scene break" option, but that only seems to impact Digital8 tapes. Hi8 tapes start a new clip at 1hr no matter what the setting.

Yes, originally analog footage does not have those timebreaks in DV stream that can automatically split scenes into clips. The same happened when I used my old Sony TRV320E D8 to digitize my old VHS tapes and when I borrowed the camcorder so a friend so she could digitize her Hi8 tapes on-the-fly with that D8 camcorder to iMovie.

I have archived all my original VHS and D8 tapes as max 2 GB (max 9 min 27 sec) clips as an old habit and because larger clips are clumsy to handle (especially in the past with slow HDD drives). So pick anything between 10-65 min as a clip size. I'd not split even D8 footage into numerous small scene clips but edit and trim them later, if necessary (trimming as straight cuts and exporting as DV is lossless although in some iMovie versions it was not lossless with certain workflows I learned to avoid). Welcome to the rabbit hole of movie editing.

By straight cuts I mean simple trims and cuts with no pixel edits that would need re-encoding.

That artifact in the bottom of analog footage is normal analog "head switching" that was usually hidden in old TVs with their "overscan" feature.

Because old tape technology was not that exact, the same happens in both sides of at least VHS footage due to "blanking etc". The actual PAL image area is 702x576 although the whole rectangular pixel PAL frame is 720x576. There are several slightly different ways to scale those rectangular pixels to square pixels (so round objects remain round on a computer screen) but I have used the figures from the article below by scaling 4:3 PAL 720x576 to 788x576 and the cropped that to the final 768x576. With 4:3 NTSC scale 720x480 to 648x480 and then crop to the final 640x480. With 16:9 different numbers must be used.

DV/D8 footage does not have those analog artifacts and the image area covers to whole frame including the sides. So using those standard scaling and cropping will slightly crop real image. So the user could omit the final crop but that yields a nonstandard resolution that usually does not matter much though.

http://web.archive.org/web/20140218044518/http://lipas.uwasa.fi/~f76998/video/conversion/