3 ms·

> It turns out, that within the silos of Apple, they do no communicate back and forth with each other. So the iTunes team read the white paper on the MOV file f

> It turns out, that within the silos of Apple, they do no communicate back and forth with each other. So the iTunes team read the white paper on the MOV file format and wrote all of their automation expecting these values to be present. Unfortunately, the team writing FCP had not updated their exporter to use these new features of the MOV. I was somewhat involved in this at Apple at the time! Your description is actually a decent description of the reality on the ground. The following may however have some misremembered details so don't take it as gospel. At the time QuickTime was migrating internally the older MacOS era subsystems to newer ones under the hood. The low level frameworks were private to QuickTime, Apple didn't ship public headers for them. Both iTMS and FCP however did use the private headers to use those frameworks directly. With iTMS they had a bespoke media ingest and export pipeline. They were calling QuickTime's private frameworks but doing their own thing with the raw samples between ingest and export. IIRC they had QuickTime branch/builds of their own because their encoder fleet didn't just jump on the latest OS and QuickTime version. FCP/Compressor were also directly using QuickTime's private frameworks but as I recall shipped their own private copies of some of them. I believe this was due to those revving with the OS rather than QuickTime's package but FCP had to support older OSes. Even QuickTime's behavior wasn't entirely consistent. Videos captured on iPhones had an assumed color space (Rec.709 IIRC) but at the time didn't write the tags into the files. QuickTime had to recognize iPhone originated files and then play them as if they were tagged then tag them if it exported (pass-thru or otherwise) those files. For other untagged input files it assumed tags based on the frame size, SD sizes were assumed to be Rec.601 if they weren't tagged and HD sizes Rec.709 if they were untagged. Of course tagged files didn't need any guessing and got the tagged behavior on playback and export. It's not necessarily that the three teams didn't talk to each other, their schedules were just wildly different cadences. While the QuickTime group was writing all the frameworks being used they were concerned mostly with the low level issues. They were also supporting iLife, iTunes (the app), and QuickTime Player/plugin releases along with a good portion of the group working on iOS as well. FCP and iTMS were just internal customers writing their own stuff using the low level frameworks.

dylan604 4y ago
Maintaining backwards compatibility with FCP makes sense, but the hubris of the iTMS team was also quite funny to me as well. They could have handled this on their end knowing that the Apple ecosystem was fractured regarding QT. They could have built Transporter to be much more tolerant of files created by FCP/Compressor to not be rejected because of these differences in Atoms within the container. Instead, many 3rd party apps had to be built/used by people instead of just handling it internally. I also relate back to their air of superiority from another situation I had with them. Their original specs called for video content originating on film to use IVTC to return the frame rate back to original progressive frames for the obvious reasons. However, they clearly were not familiar with TV/Episodic content that was originally shot on film, but edited at 29.97 with broken cadences, use of 30p graphics, and other content that was true 29.97i. There was a specific F/X series that 2 different providers had their files rejected from the show because of faulty IVTC processing. My company got involved, but iTMS said to send them the unprocessed 29.97 content because they "knew" how to handle it. They didn't, and then it landed in my lap. I processed the files and submitted them where they were approved. There was a request from iTMS to find out how they were made. Very smuggly and with a righteous smile on my face, I got to quote an answer they had provided me previously back to them, "this is a proprietary process developed by our in-house engineers." We got a lot of work because of that. It was examples like this that make me roll my eyes when FAANG types are held in such high regard. They're just humans trying to figure stuff out with people available to them. They might not actually know everything just as us mere mortals, but some of us have unique experiences that allows us to tell the emperor he's not wearing any clothes when the FAANG types issue decrees from up on high that are clearly just not right.
- giantrobot 4y ago
  Even internally I got the same sense of the iTMS team. To this day I don't know where they got that attitude from. If I were to guess it would be they had a ridiculous revenue-to-engineer ratio and got a lot of attention/praise at the executive level. Every time (for some approximation of every) their pipeline ran they generated millions of dollars in revenue. Meanwhile the QuickTime Player/plugin/QuickLook was invoked likely billions of times a year and generated revenue on a tiny fraction of those invocations. I can't say for sure but it was very annoying at times interacting with them internally. Dealing with that externally I could imagine being a complete pain in the ass.

dylan604 4y ago

Maintaining backwards compatibility with FCP makes sense, but the hubris of the iTMS team was also quite funny to me as well. They could have handled this on their end knowing that the Apple ecosystem was fractured regarding QT. They could have built Transporter to be much more tolerant of files created by FCP/Compressor to not be rejected because of these differences in Atoms within the container. Instead, many 3rd party apps had to be built/used by people instead of just handling it internally. I also relate back to their air of superiority from another situation I had with them. Their original specs called for video content originating on film to use IVTC to return the frame rate back to original progressive frames for the obvious reasons. However, they clearly were not familiar with TV/Episodic content that was originally shot on film, but edited at 29.97 with broken cadences, use of 30p graphics, and other content that was true 29.97i. There was a specific F/X series that 2 different providers had their files rejected from the show because of faulty IVTC processing. My company got involved, but iTMS said to send them the unprocessed 29.97 content because they "knew" how to handle it. They didn't, and then it landed in my lap. I processed the files and submitted them where they were approved. There was a request from iTMS to find out how they were made. Very smuggly and with a righteous smile on my face, I got to quote an answer they had provided me previously back to them, "this is a proprietary process developed by our in-house engineers." We got a lot of work because of that. It was examples like this that make me roll my eyes when FAANG types are held in such high regard. They're just humans trying to figure stuff out with people available to them. They might not actually know everything just as us mere mortals, but some of us have unique experiences that allows us to tell the emperor he's not wearing any clothes when the FAANG types issue decrees from up on high that are clearly just not right.

giantrobot 4y ago
Even internally I got the same sense of the iTMS team. To this day I don't know where they got that attitude from. If I were to guess it would be they had a ridiculous revenue-to-engineer ratio and got a lot of attention/praise at the executive level. Every time (for some approximation of every) their pipeline ran they generated millions of dollars in revenue. Meanwhile the QuickTime Player/plugin/QuickLook was invoked likely billions of times a year and generated revenue on a tiny fraction of those invocations. I can't say for sure but it was very annoying at times interacting with them internally. Dealing with that externally I could imagine being a complete pain in the ass.