Videos From Handbrake Not Supported?

Interesting question!

Did you find an alternative/solution in the meantime?

(Have you tried MPEG Streamclip.app instead of Handbrake for eexample?)

I tried handbrake and had similar problems. In the end, I used iMovie to do the editing and exported to iPad format at 640 x 480 resolution. Those videos work out at around 12MB per minute.

Michi.

Any video experts out there who can shed some light on a solution?

Basically, your HandBrake work flow (whatever preset you are using) includes settings that iBooks Author recognizes as not conforming to QT standards. As a result, the app refuses to allow import even though the video would play correctly. (Apple security checks working overtime again.)

I have 30 videos to include in my ibook. The videos were edited in Final Cut Express and exported with Quicktime. The videos are an average of 90 seconds in length. The initial export produces files upwards of 200 - 500 MB or more. So the next step is to run them through Handbrake, which is somehow able to produce a video that is the correct size for an iPad screen, but with a target file size around 12 MB per minute of running length.

This implies you want to target your file average Audio + Video data rate to approximately 1600 Kbps. Knowing this, you could export directly from FCE to an H.264/AAC file using the "Movie to MPEG-4" (places data in an MP4 file container) or "Movie to QuickTime Movie" (places data in an MOV file container) export option that will pass iBA "security checks" once the data is re-wrapped in an M4V file container.

If you elect to use the "Movie to MPEG-4" option, then manually change the MP4 file extension to MOV in the Finder and proceed as if the file was exported using the "Movie to QuickTime Movie" export option. Next open the "MOV" file in the Subler utility and add the Audio and Video tracks to the Subler work window. When the track "Add" window closes, save the track data to a new file container which will be M4V by default. The new M4V file should now be both import compatible with iBA and also be of a file size you want.

I think your Handbrake files probably have something added to the resource fork that causes iBA to reject them even though they are technically the right format. In general Apple needs to make working with videos easier. We shouldn't have to encode them twice just to get them in the app. Any H.264 rendered file should work without opening that in QT and then exporting it again.

Because of that it's best NOT to use H.264 the first time around but rather a lossless format like Animation or something else... then let QT do the crunching one time. PITA but for now that's what I've observed.

I think your Handbrake files probably have something added to the resource fork that causes iBA to reject them even though they are technically the right format. In general Apple needs to make working with videos easier. We shouldn't have to encode them twice just to get them in the app. Any H.264 rendered file should work without opening that in QT and then exporting it again.

You don't have to "export" the content twice. The problem is that Apple has removed the generic H.264 export option that previously provided direct export to an M4V file container employing user specified settings and replaced it the the current device targeted presets which provide no user options whatsoever. Thus, users who wish to continue to export to H.264 using custom settings now have to use the QT 7 Pro (FCE/FCP/GarageBand) "Movie to MPEG-4" option which places the data in an MP4 file container or the "Movie to QuickTime Movie" option which places the data in an MOV file cotainer to create custom encoded H.264/AAC files. (I.e., the only other current option is to use any of the device presets which may or may not provide file size desired by the OP here.) So it is still possible to directly create the H.264/AAC data that is compatible with iBA in a single export step, but it ends up in a file container that iBA doesn't like. Thus, the only remaining requirement to make the exported content iBA compatible is to place it in an M4V file container without resorting to a second export. That is where the Subler utility comes in. It has the ability to copy H.264/AAC data to an M4V container that is then recognized by iBA which will then allow file import to your project. This process is very fast—especially for the short 90 second files mentioned by the OP.

Because of that it's best NOT to use H.264 the first time around but rather a lossless format like Animation or something else... then let QT do the crunching one time. PITA but for now that's what I've observed.

I disagree. If the file is being edited and has to be custom compressed for import to iBA, then compress the data only once and avoid any potential for quality degredation.

Jon: That last part sounds like you agree with me, not disagree. 🙂 I am advocating not compressing the data more than once.

Are you saying when I create an H.264 (m4v) rendered file in another Mac app... and it doesnt' work in iBA... and I then create another file with QT Export, that the file content is not being re-compressed or re-rendered in ANY way but instead is just being encapsulated in a video container? If so then I'd agree what you're sayign is OK as far as "first renders".

But if QT recompresses the data in any way, it's probably better in your video source app to render out the first time to a non-lossy or close-to-non-lossy format (assuming the size is acceptable), then let QT create the M4V for using in iBA.

That last part sounds like you agree with me, not disagree. 🙂 I am advocating not compressing the data more than once.

Not at all. You suggested the OP export his edited content to a high data rate/low loss compression format and then re-compress that file to an iBA targeted compression format—i.e., two separate re-compressions. I say, if you are already in the the editing application (e.g., QT 7 Pro, FCE, FCP, or GarageBand) like FCE in this case, then perform the custom settings export and have done with it. (I.e., perform a singe export.) Since the data is now correctly formated for iBA and the file size is what the OP wanted, you now only have to place the data in an iBA acceptable file container. And, since iBA won't accept a file extension added by the user at the Finder level, you must actually re-wrap the data in a "real" M4V file container before iBA will accept it.

Are you saying when I create an H.264 (m4v) rendered file in another Mac app... and it doesnt' work in iBA... and I then create another file with QT Export, that the file content is not being re-compressed or re-rendered in ANY way but instead is just being encapsulated in a video container? If so then I'd agree what you're sayign is OK as far as "first renders".

You will have to be more specific here. If you are, for instance, using QT 7 Pro to remove incompatible data tracks (e.g., an AC3 secondary audio track), then you have the option of either re-compressing or not re-compressing the data. (I.e., deleting the AC3 track and then using the "Save As..." option will save the data to a new MOV file container without re-compressing the data while most "Export" options other than "Movie to MPEG-4" with video passthrough turned on will re-compress the video data. I also specifically stated that Subler would have to be used to "copy" iBA compatible H.264/AAC content from an MOV file container to an M4V file container without recompressing either the H.264 video or the AAC audio. I never said anything about re-processing/re-compressing/re-exporting a file in any QT app a second time. In fact, I went out of my way to indicate that this is what I wanted to avoid here.

But if QT recompresses the data in any way, it's probably better in your video source app to render out the first time to a non-lossy or close-to-non-lossy format (assuming the size is acceptable), then let QT create the M4V for using in iBA.

Why are you so obsessed with recompressing the data? If the source file is already iBA compatible and your edits are limited to trims, then edit it in the native iBA compatible compression format and do not recompress the output file. If the source file is not already iBA compatible, then edit it in the "file native" compression format if already QT edit compatible and then export it once to a preset or custom iBA compatible compression format. If the source file is not in a QT edit compatible compression format and/or your editing process requires more than simple trims (e.g., compositing multiple compression formats), then, and only then, re-compress the file(s) to a common high data rate/low loss compression format for editing purposes and re-compress the edited content to final iBA compatible target format. Since the OP specified that he was editing in FCE, the source compression format is already of no consequence here since the OP will be exporting the file to a custom data rate in order to create files having a specific target file size. In all instances other than starting with a non-edit compatibe compression format or editing/compositing multiple formats requiring re-rendering, there should be no need to re-compress the file more than once if you plan your work flow in advance and use the correct applications properly.