[Bernhard G.]

Hello,

I have extreme good experience with the
Gefen VGA Audio To HDMI Scaler
https://www.gefen.com/kvm/dproduct.jsp?prod_id=8915
and it’s for an affordable price.

It converts any VGA framerate and resolution + Audio
to a standard HDMI video signal.

Best regards,
Bernhard

[Bernhard G.]

Hello,

recently I read and tested the workaround for using FCP-X with NAS shares:
https://fcp.co/forum/7-how-to-tutorials/1083-getting-fcp-x-to-recognize-network-drives

I also read Apple’s Whitepaper on FCP-X and XSan:
https://support.apple.com/kb/HT5084

The current workaround for NAS is to create a disk image with Disk Utilities,
put it on the NAS and mount it, so FCP-X recognizes it as local Volume.
The procedure for multiple users with XSan is to soft-import from the
original media folder in event ‘A’ into another event ‘B’ – not really convincing.

When testing the NAS workaround I had an idea:

What, if Apple would make the workaround procedure a standard, but
– from a well designed GUI inside FCP-X for creating and mounting/unmounting the images

– calling those images (still *.dmg files) “Final Cut Library“;
but hiding the “dmg” appendix;
and giving those Final Cut Libraries their own well designed icon

– replacing also the XSan dialoge by the new GUI

– with the capability to mount a “Final Cut Library” from within FCP-X as
read/write exclusive (others could’nd mount it at all)
read/write (others could mount as “read only”)
read only

I was inspired by SANmp’s GUI for permissions handling and
by Media100’s GUI for handling of volumes.

Benefits:
– it would’nd interfere with Apple’s philosophy of events and projects
– for Apple it would be easy to implement (their own technology from Disk Utilities)
– we could create such images whereever we want to (NAS, SAN, DAS, local)
– we could create as many images we like to
(basically we could handle such an image as our new project ‘project’ file)
– we could have all data for a film project in one Library
– we would have more control which projects and events are displayed
– Teamwork: Apps like Motion, Compressor or Logic could mount the library with different permissions;
think of a Library mounted “read/write”, so other FCP-X user coul’nd write to it,
but a Motion user would be permitted to mount it and to write animation data / results

Disadvatages:
– solution adds one more level of file structure complexity
(we will need to become familiar with either way; think of Smoke)
– if we want to access the movie files we would need to mount the volume
(but if it works from Finder, the disadvantage would be small; please think of the old iMovie!)

I already wrote most of this into the Apple feedback form.

Best regards,
Bernhard

[Bernhard G.]

[Jeremy Garchow] “You know AVC-Intra belongs to Panasonic, right?”

This is the crucial question here. Does AVC-I really belong to Panasonic?
– It has been standardized by the SMPTE.
– Furthermore it is an encoding variant of the H.264 profile High 10 Intra and High 4:2:2 Intra.

Please does anyone here know for sure, what legal status AVC-I has?

Best regards,
Bernhard

[Bernhard G.]

Jeremy,

I was very surprised to read in the GV-4095M White Paper
“AVC-Intra for HD-Editing and Production”, Pg.7
that AVC-I seems to be more robust than ProRes and DNxHD!

In fact this has changed my mind. I have to admit that I
wasn’t that fan of AVC-I because it has been developed
by a camera manufacturer – therefor I’m naturally skeptical;
(thought I do very appreciate the fair-priced AVC-I Cams
Panasonic has produced in recent years).

But I don’t want to exchange one set of restrictions
(ProRes in Software interoperability) through another
(AVC-I in Hardware interoperability).

Put simply:
AVC-Ultra needs to become an Open Standard!
Software AND Hardware.

Best regards,
Bernhard

[Bernhard G.]

Jeremy,

the first reason I thought of is, x264 is the best H.264 encoder.
If AVC-I becomes the new ProRes, I’m simply afraid
while every NLE would be able to encode to AVC-I relying
on different AVC-I SDKs, that there would still be
quality differences between implementations.
Definitely won’t like to see arguments like “We encode AVC-I better than …”
With ProRes, consistent quality could be guaranteed. We need less complexity,
not more.

The second reason is, that an open-source implementation would allow
every NLE building company to integrate this standard for minimal license fees,
and not only for import, but also for a whole workflow.

Third, an open-source implementation would perhaps allow
Hardware Manufacturers like Blackmagic and AJA to implement
the code on their ACICs. Better would be an open hardware implementation,
every camera, recorder, and Video-I/O manufacturer is allowed to use.

Or put simply:
An open-source implementation would avoid
typical restrictions we got used to know in the industry.

ProRes is relatively open and available right now,
and I’m NOT willing to give up only a tiniest bit of this freedom!

Best regards,
Bernhard

[Bernhard G.]

Somewhere I read that the team of the x264 project is working on implementing an option
to encode AVC-I. As far as I understood, the problem is the MXF container.

Perhaps AVC-I 200 and 400 could also be implemented in x264;
and adding an Alpha Channel couldn’nd be such a problem.
I think it’s not a question of technology, but how open AVC-I really is.

I definitely would prefer if there was a x264 implementation of AVC-I /200 /400.

x264 is open source, but could also be licensed commercially for a minimum fee.

I dream of a professional video future in which all professional NLEs are using x246’s AVC-I,
and not-over-expansed field recorders and cameras are available like ProRes-Tools are today.

Best regards,
Bernhard

[Bernhard G.]

Hello,

You simply have had addressed Premiere’s biggest weakness,
and PremierePro users are simply used to another workflow philosophy.

This weakness is the lack of a high-end intermediate codec.

But Adobe is aware of this problem, as has been mentioned here
by Dennis Radeke at the forums (sorry for not finding the thread at the moment).

Recently I read GrassValley’s White Paper
AVC-Intra for HD-Editing and Production
Very reasonable arguments for a an AVC-I workflow in there!
EBU also does like it.

It seems AVC-I is more robust than ProRes and DNxHD.
It’s current disadvantage is the implemented datarate of 100Mb/s,
that takes quality somewhere in between ProResLT and ProRes422.
AVC-I Class200 and Class400 should be of higher quality than ProResHQ
and ProRes4444.

Since Adobe will need to support AVC-Ultra either way,
perhaps this problem will be solved very naturally and elegantly
when released next year!

But then there arises another problem:
Please does anyone know for sure how “open” AVC-I really is?
The current modes are standardized by the SMPTE:
https://www.techstreet.com/cgi-bin/detail?doc_no=smpte%7Crp_2027_2007;product_id=1624088

But how are the chances we will see non-Panasonic Field Recorders and Cameras capturing AVC-I 200/400
as we see them today with ProRes and DNxHD?

I never ever again want to use proprietary/non-open camera codecs and proprietary recording media!
NEVER EVER!

Best regards,
Bernhard

[Bernhard G.]

[Jeff Hartman] “Methinks there is still a place for both.”

Absolutely 🙂 … two different worlds …

But it is difficult to understand that while our NLEs and Transcoding Apps are
delivering simply a mess when it comes to scaling and de-interlacing,
we actually do have the very best HW-scalers already in our computers
but aren’t able to apply them on our files, forced to do a workaround
by sending signals out of the computer to process them !?!

F I L E – B A S E D Processing is simply overdue!
This is true for every vendor of Video I/O HW.

Best regards,
Bernhard

[Bernhard G.]

[John Christie] “But we’re always hoping for more, right?”

Yes, for example for F I L E – B A S E D Processing:

Start up an app for Thunderbolt connected BMD Teranex,
Quicktime-file in; configure within app; press Start; processed Quicktime file out.

That is F I L E – B A S E D Processing.

F I L E – B A S E D Processing is the workflow for the 21st century.

Best regards,
Bernhard

PS: Have I already mentioned I would like to see
F I L E – B A S E D Processing on BMD Teranex products? 😉

[Bernhard G.]

Hello Daniel,

so MC does 16bit RGB all the time?
Is every single dissolve, filer and effect capable
to be processed at actually 16bit?

Thank You and best regards,
Bernhard