Quicktime > Encode selected video files > greater compatibility

I record a 720p video on my iPad Pro/iOS 11.3.1 and copy it over to my Mac mini/MacOS 10.13.4.

I then right click on the video file and choose Encode selected video files with Setting: 480p and Encode for: Greater compatibility. File is encoded.

When I go to play the encoded file, the video is static, like a photo, but audio is played, as expected.

I've searched for an answer to this problem, to no avail. So posting question here.

I would recommend doing some troubleshooting on the file/workflow. While there are many places to start, I tend to favor beginning with the final output file and working back up the workflow to determine where/how the problem entered the picture and then correcting the issue. (This assumes you have already confirmed there was nothing wrong with original file uploaded to your Mini—e.g., the source video is not a "live" photo or was somehow turned into some sort of a "podcast/slideshow" before re-encoding the data.)

Normally, I would open the output file in VLC to see if it plays the same as in the QT X Player app. If it does, I would ensure that both VLC and the QT X confirm the video track is encoded as H.264 (AVC) data with normal frame and data rates and not as a single JPG (or similar compressed) frame being rendered for the entire duration of the file. If the file plays the same in both apps, compression format is correct, and stats for the video track all appear normal, then I would suspect you have a problem with the source file as uploaded to the Mini or (worst case scenario) your macOS might be corrupted.

If you've reached this point, I would check the source file to see if plays correctly and/or has a normally encoded HEVC (H.265) or AVC (H.264) video track. Compare it with the stats of the original file still on your iPad. If they are the same, I might try re-installing the macOS. If different, check the differences to see if this is causing the conversion problem. This last may sound a bit vague and if you are unsure how to do this, you may wish to upload the files to the internet so that someone else here can perform examinations and/or run further tests. It might also help to know the specific workflow used to transfer the video from the iPad to the Mini, as well as, how the video is "managed"—e.g., is it imported into Photos, has it been exported by any app as part of your transfer/management workflow, what format are you using for iPad recording, what is the device transfer format setting, etc?

Thanks for the detailed response; much appreciated. I am no SME when it comes this stuff...

I copied the original file from iPad to Mac using Dropbox. (I do not know how to find the video file stats on the iPad...)

Once copied to the Mac, both video and audio play as expected in QT.

Using the MacOS feature to encode the video to a different size results in a file that, as said above, has a static picture yet audio plays. I installed VLC per your recommendation and the file plays the same in VLC, i.e., static picture, audio fine.

However, if I use VLC to convert the video, the output file plays fine in both QT and VLC.

Here are some screenshots of the metadata for 3 files. The Original, MacOSConverted, and VLCConverted.

Thanks for the updated details. The fact that neither QTX nor VLC can play the file but VLC can still re-encode the file to a version that will play indicates the issue is a playback problem—i.e., the "greater compatibility" file version still retains all of the properly encoded video data but, for some reason, can't/won't play it.

Here are some screenshots of the metadata for 3 files. The Original, MacOSConverted, and VLCConverted.

Excellent. All of the stats are normal—albeit based on change in dimensions and/or encode data rate. What do you think of the quality of the VLC re-encoded file? Am trying to get a feel for the minimum level of quality you are willing to accept in relation to the size of the file you seek to achieve. Basically, the higher the data rate of the encode, the better the quality but you have to remember that the size of the file is directly proportional to the file's data. While this may sound confusing, all I am trying to do is assess the value of your using an alternative workflow to create smaller high quality files which I assume you need for some special purpose such as sharing with others, posting to the internet, emailing, etc.

I don't think I would go through reinstalling MacOS for this. Maybe it's specific to 10.13.4? I will ask a friend to try and repro this on a downlevel version of 10.13...

Don't believe this is actually called for at this time. What we are seeing here may be the result of a security update or in a change to the manner in which the data is wrapped/stored in the file container. If possible, provide a URL link to a DropBox copy of the "greater compatibility" version of the file. Want to check encode settings and file container stats to see if anything has been changed by recent macOS updates. Also want to see if simply copying the data from this file to a new file container "fixes" the problem. As an alternate workflow, would suggest you install and use the free HandBrake app if not already available on your system. This app has easy presets that will likely meet your needs to downsample the resolution of your 720p files while maximizing high quality at lower data rates, as well as, allowing more experienced users to employ manual setting to fine tune output as needed.

Again, ty, Jon, for reaching out. Looking forward to hearing your thoughts on the file info above.

My pleasure. The question was interesting and results may provide added insight into recent macOS changes.

The backstory is: I test mobile apps. When I find a problem, I have to grab video to illustrate the problem. File size limit is 10MB for attachments. I usually use Handbrake to resize videos but was playing around with Automator to create a service that could be used to resize videos ~60 seconds long. (~90MB for a 60 second 720p video shot with my iPad.) Got the automator service to work, but saw the issue of video not playing. That's when I tried the built in service to encode videos (basically exactly what the automator service was calling anyway...).

So its only automator service files that have this issue or does a manually processed file have the same problem?

When I use Handbrake, I set the bitrate to 1000 and it gets the video down to under 10MB. (Usually 5-9MB depending on the video length.) But Handbrake is a pain to use in some ways b/c you have to set the output directory every time you change the source directory. There might be a way to do that, but I haven't found it yet.

Strange! My output directory remains the same no matter what volume directory I source.

I was excited by the potential of using the MacOS encoder to streamline the workflow, but at this point it seems like it's not 'doable.'

Would still like to see a sample "static" playing file produced by your workflow to see if the is a setting/container change resulting in the "static" issue. It need not be one of your actual work files.

I'm going to give VLC a shot to resize videos. If nothing else comes from my post, your clueing me into VLC will have been worth it.

Have come to distrust VLC on some occasions as it sometimes reorders frames in video produced by certain other apps.

Insert Video btn is greyed out... here's a dropbox link to an example of the 'static' video:

Downloaded the file and got the same playback results. Copying data to new MOV, MP4, or M4V file container did not change results. Changing Profile/Level container info did not allow playback. So at this point I ran some tests on some of my own files. The only way I can duplicate your problem is to try and convert an HEVC source using the "greater compatibility" macOS option. Based on these results, I have two quick questions for you:

1. What iPad recording format are you using?

2. Was the source file used for the "successful" VLC conversion the original source file or the "greater compatibility" macOS converted file?

If you iPad is set to record using the HEVC compression format and you are transferring HEVC files to your Mac Mini, then that would explain why the macOS encode option failed. (I.e., it does not appear to support any HEVC transcoding capabilities at this time.) On the other hand, if you use VLC (or HandBrake) to convert the same file, it will convert successfully because both apps employ the FFmpeg codec package which includes the x265 (HEVC) codec support. If this is the problem, then simply change your iPad record setting to record using the H.264 codec and repeat your test workflow. Alternately, use a transfer workflow that allows you to continue to record HEVC iPad video but automatically transcodes the transfer files to H.264 automatically when the appropriate iPad transfer setting is properly set to do so—e.g. AirDrop transfers.

Good Luck.

So I set it to Most Compatible. Recorded video, copied to Mac. Manually converted using MacOS encoder. (Not Automator Service.) Same problem. Bounced iPad. Tried again... same thing.

Strange. On my iMac, the H.264 files convert and play normally. Only the HEVC sourced files convert to static 480p videos.

Duplicate response deleted

Duplicate response deleted.