Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File information #24

Open
jrhooker76 opened this issue Aug 25, 2019 · 6 comments
Open

File information #24

jrhooker76 opened this issue Aug 25, 2019 · 6 comments

Comments

@jrhooker76
Copy link

Hi. I'm new to this, but I don't understand why -- after I export to hap -- my file (which works fine, I think) doesn't show me any information when I do command-i. Like, usually the size of the file and the codec is there...and it was there in the previous file that I exported from. I need to know this stuff and I don't know how else to get it. Is there a setting I'm missing?

@jrhooker76
Copy link
Author

Also, can somebody tell me why that same file works marvelously in the program I exported it for (Isadora) but AWFUL in any other program...QT and Premiere, chiefly. I'm missing something here.

@mrRay
Copy link
Contributor

mrRay commented Aug 26, 2019

for a long time, QuickTime was how the macOS played back multimedia files. QuickTime had a plugin architecture for supporting different codecs- developers could write a plugin, and anybody who installed that plugin would be able to import/read and export/write A/V files using a different codec.

a few years ago, apple decided to drop support for QuickTime, and replace it with AVFoundation. AVFoundation doesn't have a plugin architecture, and it only supports a handful of codecs that apple has decided to build into their OS. hap is not one of these codecs- if developers want to support the hap codec in macOS, they now have to build support for the codec directly into their software, using this framework.

"my file (which works fine, I think) doesn't show me any information when I do command-i"

with no plugin architecture for adding support for third-party codecs, it's simply not possible for the Finder to retrieve basic properties of media files that use the hap codec.

"Is there a setting I'm missing?"

no- the problem is that significant functionality that you made use of has been removed from the OS. you can file a bug report with apple, and that's about it. lots of people have filed reports on this issue over the last few years, and it hasn't really changed anything, but who knows! maybe yours will be the tipping point.

"Also, can somebody tell me why that same file works marvelously in the program I exported it for (Isadora) but AWFUL in any other program...QT and Premiere, chiefly. I'm missing something here."

just a guess, but...the files are probably being decompressed and processed on the CPU. the hap codec is fast because it's meant to be uploaded directly to the GPU for display and/or hardware-accelerated image processing- hap basically lets you dump video frames from your drive to your GPU with as little between the two as possible. decoding it on the CPU is substantially slower as it doesn't take advantage of any of the hardware acceleration.

@rsodre
Copy link

rsodre commented Aug 26, 2019

I always wondered, why didn't you make a .hap file format? Wouldn't using a different extension enable to implement file info, quicklook and preview?
Inside it could be exactly the same, just rename movie.mov to movie.hap to take advantage of it all.

@mrRay
Copy link
Contributor

mrRay commented Aug 29, 2019

"I always wondered, why didn't you make a .hap file format? Wouldn't using a different extension enable to implement file info, quicklook and preview?"

what would that resolve/how would that make anything better? how would this new, proprietary .hap container format work with other software/other platforms? how would it play nice with other teams that want to have their third-party codecs similarly supported in the Finder?

"Wouldn't using a different extension enable to implement file info, quicklook and preview?"

  • if you're talking about a different container format, then you wind up with movie files that aren't compatible with anything else in the OS.
  • if you're talking about the same container format, but you just want to fool the OS into thinking that it's a different kind of file, then you wind up with the same basic problem: movie files that aren't compatible with anything else in the OS.

both of these situations have two significant drawbacks that i can think of off the top of my head:

  • devs wouldn't be able to use AVFoundation to play back the files at all. as things stand now, this framework allows you to use AVFoundation to play back movies- that is, AVFoundation handles all the finer details relevant to playback (data fetching/decoding, playback tracking and control, audio support, etc), and all you have to do is add a custom AVPlayerItemOutput that vends DXT data ready for upload to a texture. this would all disappear. devs would have to roll their own playback libs, at which point you're probably better off using another playback lib entirely and skipping AVFoundation.
  • this would mislead users into thinking that video files that are fundamentally incompatible with every other app and service in the OS would "just work"- that's bad design which would cause no end of confusion and pain points for users. this is probably why nobody has bothered to write a perian-style quicklook/spotlight plugin that uses ffmpeg under the hood for video previews/metadata: great, you'd have a preview and info in the finder, but the video still wouldn't work in the overwhelming majority of mac apps.

at the end of the day, this is a very simple compatibility issue: apple decided that their OS will no longer support 3rd party A/V codecs- this is a problem they intentionally manufactured, it's been a huge issue for everybody in their ecosystem for several years now (developers and users alike), and by all appearances they intend to stay the course (a lot of people have already filed reports against this, to no avail).

if you're hell-bent on helping resolve this issue, please consider reverse-engineering apple's video plugin format (/Library/Video/Professional Video Workflow Plug-Ins) and post a public template so third-party codec devs can start creating their own plugins. until that happens, i don't see this situation improving, unfortunately.

@rsodre
Copy link

rsodre commented Aug 30, 2019

I understand we need AVFoundation to read movie files, but I don't understand anything about how codecs work, so maybe what I say is really impossible.

But in the case of a VJ that only exports HAP movies only to use with VDMX. A .mov encoded with HAP is like a black brick in Finder. That's one of the main reasons I don't switch to VDMX, how do I browse my content? But I could convert it all and optionally rename the files to .hap. A quicklook plugin could internally use AVFoundation to read the file information, thumbnail and preview. And also VDMX, it doesn't matter the name of the file, but what you do with it: send to AVFoundation. I know other apps will not understand it, but the benefit for VDMX users would be huge.

@mrRay
Copy link
Contributor

mrRay commented Sep 3, 2019

A .mov encoded with HAP is like a black brick in Finder.

  • quicklook plugins cannot preview (play back video when you press the spacebar) files that are not compatible with AVFoundation. the API just flat-out lacks the capability of displaying video unless it's compatible with AVFoundation, and to the best of my knowledge, nobody has figured out a workaround for this. you've written a quicklook plugin- you're familiar with the API, so please correct me if i'm mistaken.

  • if all you want are thumbnails for your clips in the finder, then you should check out this quicklook plugin, which has been available for many years and is easily found by googling "hap quicklook plugin" (the first hit is actually a thread on our forums discussing it):

https://github.com/lov/QLVJ

...please note that this plugin uses quicktime under the hood to generate thumbnails, so it'll only continue to work as long as quicktime is bundled with the macOS- but on a more positive note, it'll generate thumbnails for any file you have a quicktime codec for.

there are other quicklook plugins available that use ffmpeg instead of quicktime, and generate thumbnails for a wide variety of unsupported codecs and container formats- another quick google search turned up this one, which has also supported hap for a few years (and is on the list of quicklook plugins you forked):

https://github.com/Marginal/QLVideo

...and these, which also display media information, and i assume also support hap because they use ffmpeg under the hood:

https://github.com/Nyx0uf/qlMoviePreview
https://www.invisorapp.com/

beyond that, i think most of the points in my previous post stand. the issue here is that apple decided that they don't want anybody on their platform using third-party codecs, and has taken harsh steps to prevent this outside of their own proprietary applications. this is not a situation that should be addressed by half-baked workarounds from third-party devs like us- this is significant low-level functionality that apple simply refuses to allow to be used outside of their own video apps.

if you have the time and inclination to contribute to a solution for this problem, the best thing you could do to help out (besides convincing apple to open up about this :-P) would be to reverse engineer their professional video workflow plug-ins, and make a template available for public consumption. this would allow other devs to create and publish plugins that support third-party video codecs, and restore vital functionality that will be lost with the pending removal of quicktime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants