Adobe Anywhere

[Richard Cardonna]

Looks like Adobe is leaving everybody else in the dust they are in a roll. Wonder what else they got in their bag?

It’s looking like its going to be Premier world.

Richard

[Jeremy Garchow]

[Franz Bieberkopf] “Adobe “native-codec” for editing in there,”

I caught it too.

I mentioned it on Twitter and promptly got shot in the face with a negative bullet saying that the streaming codec could never be a part of a greater family of codecs like DNxHD or ProRes.

Personally, I tend to think that if they have one proprietary codec, this might be a part of other higher res codecs. I think Adobe is listening really well, and I think they might see value in not working natively all the time. It will also open up avenues between their own applications.

I just hope that with this Adobe Anywhere that seems to be tooling for bigger and badder work groups, that us little guy work groups can stand to gain a piece of this sharing development.

[Michael Gissing]

[Jeremy Garchow] ”
I mentioned it on Twitter and promptly got shot in the face with a negative bullet saying that the streaming codec could never be a part of a greater family of codecs like DNxHD or ProRes.”

A super efficient streaming codec other than h264 that is fast to encode would be more important than a production codec, looking at the big picture. Imagine the implications for delivery.

[Jeremy Garchow]

[Michael Gissing] “A super efficient streaming codec other than h264 that is fast to encode would be more important than a production codec, looking at the big picture. Imagine the implications for delivery.”

Not following, what do you mean, exactly?

[David Lawrence]

[Walter Soyka] “David, what would you envision a Mercury Render Engine doing?

I’ve been thinking a lot lately about the FCPX/Motion common renderer versus the distinct Ae/Pr renderers. I see major pros and cons with both approaches, so I’m at a bit of a loss about which one I want to write my rabid feature requests about!”

[Jeremy Garchow] “Personally, I tend to think that if they have one proprietary codec, this might be a part of other higher res codecs. I think Adobe is listening really well, and I think they might see value in not working natively all the time. It will also open up avenues between their own applications.”

Basically, I’m hoping for something like what Jeremy’s describing — a high-end finishing codec and a smart, efficient render/transcode process integrated into the application and workflow. I’d like to have better control over the render process and be able to use my render files for final output, like how it works in FCP legacy (or if not like FCP, then as efficiently as in FCP).

I understand Adobe’s difference in philosophy regarding rendering and output, but my experience is that the time saved up front doesn’t really get added back at the end. We all know how clients love to call at the very end with just one more little tweak… Really a bummer having to re-render every time for even the smallest change. This is probably my biggest feature request at the moment and I’d guess it would be for many other FCP converts as well.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl

[Michael Gissing]

At the end of post lots of time is spent converting from our production codec into mpeg files of various persuasions. H264 looks good with high compression but takes forever to render.

If Adobe have developed a high quality low data rate streaming codec that renders faster than real time so that you can view remote editing then that is really significant to reducing the bottle neck at the end of post in chugging out various mpeg based files for web and other presentation displays.

It is also encouraging to think that high quality from all our effort n production can be efficiently streamed to the home viewer.

[Jeremy Garchow]

[Michael Gissing] “At the end of post lots of time is spent converting from our production codec into mpeg files of various persuasions. H264 looks good with high compression but takes forever to render.

If Adobe have developed a high quality low data rate streaming codec that renders faster than real time so that you can view remote editing then that is really significant to reducing the bottle neck at the end of post in chugging out various mpeg based files for web and other presentation displays.

It is also encouraging to think that high quality from all our effort n production can be efficiently streamed to the home viewer.”

Hmm. You are seeing the proprietary streaming codec as a delivery codec? Interesting.

It sounds like it’s not a faster than real time codec, it’s a real time codec that’s encoded on an Nvidia GPU as soon as you hit the space bar. It needs to be efficient enough to stream to multiple users in different rooms and perhaps environments. Maybe it’ll be good enough for a delivery codec, I don’t know.

As it stands h264 can be a realtime codec with the proper hardware. Adobe Meda Encoder can crunch through programs pretty quickly and also offers parallel encoding in software.

I think a proper production codec for Adobe would be much better served than a highly compressed delivery only codec. I don’t know how much you’ve worked with Pr, but the native aspect gets old very quickly depending on what formats you are working with. A solid and robust codec for the CS would offer all kinds of efficiencies from rendering/realtime effects/conform/archive/translation. It would allow the use of cheaper hardware and not tie every room to a multiple GPUd machine.

Everyone’s workflow is different. If delivery is your bottle neck, then I could see you want a new delivery codec that encodes fast. What codecs do you typically deliver?

I have been familiarizing myself with Speedgrade as Color is truly dead. I rather like what can be achieved with it. It has some huge workflow gaps, but it’s new to the suite and they are working on it. An intermediate codec that is common to CS along with Prelude being the CS transcode hub and Dynamic Link would open a bunch of efficiencies with this process.

[David Lawrence]

[Jeremy Garchow] “I don’t know how much you’ve worked with Pr, but the native aspect gets old very quickly depending on what formats you are working with. A solid and robust codec for the CS would offer all kinds of efficiencies from rendering/realtime effects/conform/archive/translation. It would allow the use of cheaper hardware and not tie every room to a multiple GPUd machine.”

Well said. Hopefully this is high on Adobe’s priority list.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl

[Michael Gissing]

I hear what is being said about the need for a good production codec and an incremental rendering in Pr. Perhaps I am jumping the gun in presuming that the streaming codec is something new and a potential delivery codec but typically when a job is done, I make a master ProRes quiicktime and then from that I need to make small H264s to ftp to clients, plus higher quality h264s for film festivals, blu ray, plus an m2v for DVDs (but this is something that is slowly dying thankfully).

Because I have many clients interstate there is often a delay in sharing the changes and adjustments to the final in a quality that is worthwhile. Typically a producer who is thousands of miles away sends an email of changes to a grade or online from a crappy small h264 which isn’t accurately showing details like titles & graphics well. There is a delay in rendering a crunched down file that is small and efficient to stream. So I like the prospect of a client being able to interact directly with the final sequence via a cloud subscription whilst being able to quickly see at a proper resolution. I got excited to see that the demo stressed the picture quality and that there was not delay in making a change and then streaming the change.

To extrapolate that to the ability to quickly create quality delivery streams for film festival etc and also potentially broadcasters is intriguing. Broadcasters are locked into mpeg2 delivery mostly and at one stage I did look at some good real time hardware encoders. Still they demand HDCam tape but that’s another story.

[Michael Gissing]

Speedgrade. Yes very interested and I understand the current need to transcode round trip and not have dynamic linking will get old very quickly as well. So again a common working codec for both sg & Pr is important. I often have the need to collaborate with DPs or director/camera people who are interstate. Most of my work is remotely so again having the ability to conduct a grade session with this level of speed and quality is important in my case.

All in all this really pushes the choice to Adobe for my workflows and I hope that the production codec & render issues are also well resolved so that sharing a dynamic linked Pr/Speedgrade session might also be a possibility.