Andrew Kimery
Forum Replies Created
-
[Oliver Peters] “However, the Japanese are already venturing into those areas. So it’s not 2023. “
NHK is always tinkering, and HD existed for decades before it finally found traction (for various reasons) in the early 2000’s.
8K is around the corner so Apple is talking about 8K. 16K is around the corner from 8K and Avid is talking about that because they are trying to shake the stigma of being an old, broken down NLE that only exists due to favorable market inertia. I don’t doubt that when 16K is actually around the corner that Apple will talk about it’s 16K ability and how it’s based on the latest tech (as opposed to the ‘old’ 16K tech used by *those other guys*). 😉
-
[Oliver Peters] “BTW – I realize no one here wants to hear this, but with Apple focusing on 8K video with a 16-bit float pipeline, they are already behind the eight-ball in terms of where the industry could be headed. For example, Avid is being re-coded as 32-bit float with 16K project sizes possible. Also an uncompressed version of DNx and ACES workflow support.”
I know people like the Gretzky/puck quote, but it is possible to skate too far ahead of the puck. I mean, hypothetically if 16K projects start becoming a common thing in 2023, and other NLEs have 32-bit 16K support in 2021, does it matter that Avid had it in 2019?
-
[Bill Davis] “This is simply NO different than when VHS tape, Betacam, DC-2000 backup cartridges, Syquist data disks or ANY other legacy technology fell out of favor. “
It’s kinda different in that we are talking about data, not physical media. A VHS tape is physically incompatible with a DVD player or a DigiBeta deck. There is no physical incompatibility with codecs. It’s just whether or not the software maker wants to support it. For example, there is an entire cottage industry ‘saving’ old video games via emulation even though the physical consoles and/or old computers that the games were originally designed for have largely gone the way of the Dodo.
With that being said though, archiving for data doesn’t really exist like it does for physical media. Archiving for data is really a perpetual migration of data to contemporary codecs/formats and storage mediums so that it remains accessible. This is why when one does their initial ingest one shouldn’t use a heavily compressed codec like low bit rate H.264 because eventually that crap H.264 file will have to be transcoded into another codec for compatibility. And then another, and then another, and then another for decades or even centuries (assuming humanity makes it that long).
-
The potential is obviously there, but how much will it cost? How quickly will Apple expand support to other codecs? Will there be APIs so any third party can program for it? If Afterburner is a super-niche product how many third parties will actively support it?
I don’t doubt the performance of Afterburner, but the perceived cost/benefit is going to determine whether or not it’s a ‘game changer’ or just a really expensive piece of niche hardware for what’s widely seen as an already expensive workstation.
-
[Bill Davis] “Not sure how it could be.
The whole point of an FPGA is that you can easily re-configure it to point it at accelerating other types of footage handling if your needs or formats shift.
As such, I’d expect this approach would have an extremely long life expectancy.”
Until off the shelf computers can achieve ‘good enough’ results w/o needing to buy special-purpose hardware that requires specific support in order to be utilized.
That was the gist of the desktop video revolution was it not?
-
I’d say find the best editor you can that you think mesh well with you and with the project and also find a member of the Kainga Iwi to act as a producer on the film to help during the edit.
But as Mark already mentioned, you’ve already gone in as an outsider and shot everything so you should be open the the chance that a lot of what you shot is ‘wrong’, from a Kainga Iwi perspective might need to be scrapped.
Also, who is your audience for this film? Do you want to show it to non-Kainga Iwi so they better understand the plight of the Kainga Iwi? Is it for Kainga Iwi?
-
My guess is that it’ll look like a big MacMini on the outside and have the iMac Pro guts on the inside. It’ll have more ThB 3 USB-C ports (and busses) and maybe come in a dual CPU flavor. I don’t see Apple giving internal expansion so everything (GPUs, storage, I/O cards, fiber, etc.,) will happen via ThB 3.
-
I wonder if the Bandersnatch team consulted w/a of the big RPG video game makers on how to organize branching storylines? I think Oblivion had something like 50 or 60 hours of voice acting.
-
I’ll preface this with saying that compression isn’t my specialty, but this is my understanding of why things can work differently depending on if you are using an inter-frame or an intra-frame codec.
[Bret Williams] “Yes very familiar. Here’s a new one though. I’m able to trim an h264 clip in Quicktime Player (everybody knows you can trim and edit in QT Player, right? ) and paste it to a new player and it seems I now have a standalone trimmed h264 clip. No transcoding seems to have occurred. “
When you save it you’ll create new media though right? And if the H.264 is inter-frame (inter-frame is most common, but the H.264 spec does allow for all I-frame/intra-frame variants such as AVC-Intra) then it will have to be re-encoded AFAIK.
Ex:
Original Inter-frame clip created from I, P and B frames: IBBBBPBBBBPBBBBIEdited Inter-frame clip: BBBBBBBB
An inter-frame clip cannot be all B-frames (B-frames contain the least amount of image information and rely on past frames and future frames to rebuild a complete picture) so it needs to be re-encoded to create I and P frames (I-frames are the only frames that contain a complete picture, P-frames rely on info from past frames to formulate a complete picture).
New (re-encoded) Inter-frame clip: IBBBBPBBBI
The obvious problem is that the new I-frames and the P-frames were created from the lower quality B-frames (garbage in/garbage out). This is one reason why generational loss can happen so quickly in inter-frame codecs.
By contrast, if you are working with an intra-frame codec:
Original Intra-frame clip created from all I-frames: IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
Edited Intra-frame clip: IIIIIIIIIIIIIIIIIIII
New Intra-frame clip (no re-encoding needed): IIIIIIIIIIIIIIIIIIII
Since each frame is a discreet, wholly self-contained image there is no compression ‘cadence’ to be fixed, so no re-encoding is needed. Think of it like reaching into a folder containing an image sequence and only grabbing the frames that you need, then placing them in a new order in the destination folder.
It’s not that you can’t trim inter-frame media, it’s that I don’t think you can perform a consolidate *and* trim function with inter-frame media due to the nature of it’s compression.
Avid MC and FCP Legend had the option to consolidate and trim media (assuming it was intra-frame). PPro only has the option to Collect media (no trimming) or Consolidate and Transcode (allows for trimming). I thought previous versions of PPro allowed for Avid-style consolidation w/trimming but maybe I’m mistaken. X, w/out third party support, will just consolidate media. I’m not sure where Lightworks and Resolve stand with this.
With that being said, Adobe does have a feature called Smart Rendering which means certain codecs (all Intra-frame codecs AFAIK) won’t be re-rendered upon export as long as your source media settings match your export settings. I think it means that, for example, if you are working with 1080p60 ProRes HQ files, you select Transcode and trim in PPro and your transcode settings are 1080p60 ProRes HQ then PPro will perform an Avid/FCP Legend-style consolidate and trim w/o any transcoding/re-encoding (even though you’ve picked the “transcode” option in PPro. Never tried it first hand though (just basing this off of how Adobe describes its Smart Render feature).
-
[greg janza] “Thank you for this thread. It seems amazing that a feature that has been around for so many years in Avid is still nowhere near ready for prime time in most other NLE’s. Premiere is also horribly inadequate for creating a consolidated archive.
Why is this feature so hard to duplicate in any other system?”
It’s hard, it’s not a ‘sexy’ feature, and it inherently puts restrictions on how media is managed/accessed which might annoy end users. For example, back in the day, one of the most common complaints from FCPs editors about Avid was about media management. “Why can’t I just drag and drop media from any Finder window into Avid MC like I can in FCP? Why does Avid rename my files and put them all into one, big folder?”
Yet being able to drag and drop media into a FCP project willy-nilly (and FCP not really having any inherent internal asset management) is a big reason why FCP’s Media Manager was nicknamed the Media Mangler (though to be fair, it got better over the years).
A still ongoing problem with PPro is the creation of duplicate media when you are swapping timelines between projects even if both projects contain identical media. In defense of PPro, how is it supposed to know if the file AppleBanna_1.mov that already resides inside of Project A and the file AppleBanna_1.mov, which is contained in a timeline being imported from Project B, is the exact same file or two different files that just have the same name?
PPro gives you the option to add unique meta data to each clip upon ingest to help combat this problem, that requires a more organized approach to media ingestion and dissemination which may/may not sit will with users. As they say, you can’t have your cake and eat it too, and there’s no such thing as a free lunch.
Even with Avid’s AMA you give up the robustness of having Avid MC manage the media in it’s database in exchange for the convenience of managing it (or not managing it) yourself outside of Avid.