FFAStrans forum

Hello everyone,

I noticed that all interplay threads related end without a final solution.
I see that's possible to create a standalone AAF that will work with MC but not an interplay commit routine using interplay web services.
I wonder what's the final state of art as we speak and if someone was able to sucessfuly handle commits to interplay or not ?


Thank you.
OS.

I'm currently using MediaDirector to check-in FFAStrans encoded files into interplay, however I wouldn't exclude that one day we will manage to browse the folders and check in ourselves. Anyway, so far we can't check in anything nor create a proper AVID compatible low bitrate proxy file...

@emcodem might be interested in this. I certainly am too.

FranceBB wrote: ↑Sun Aug 01, 2021 10:33 am I'm currently using MediaDirector to check-in FFAStrans encoded files into interplay, however I wouldn't exclude that one day we will manage to browse the folders and check in ourselves. Anyway, so far we can't check in anything nor create a proper AVID compatible low bitrate proxy file...

@emcodem might be interested in this. I certainly am too.

@FranceBB appreciate your feedback.

Hmm Ok.
Resink opatom package to isis or nexis and force an AAF creation is a solution however that's a lot more steps than using some other ingest software.
I was wondering if somehow the integration with interplay web services was already a possibility.
There are some PS scripts to retrieve assets data or even allow folder navigation within interplay WS so the question i guess is between the compliance of the AAF from pytoaaf with avid.
Avid proxy 800kb creation can be tricky in fact especialy when combined with hires+proxy commits to interplay.

Well, i have access to interplay production, cloux ux and a series of debug tools to parse AAF, AMT and interplay WS soap requests so if someone thinks would be useful to put this on the roadmap i can try to help.

Thanks.
OS.

Hey @mtechsup welcome to the forum and thank you for using ffastrans!

Great thread (especially the subject ), i have a feeling that good things could happen here...

mtechsup wrote: ↑Sun Aug 01, 2021 12:40 pm ... i guess is between the compliance of the AAF from pytoaaf with avid.
Avid proxy 800kb creation can be tricky in fact especialy when combined with hires+proxy commits to interplay.

Very well spotted. To be honest, until now we always missed someone with access to a dedicated development environment and the will to work on a solution.
As you very well spotted, the web services is definitely not the big thing. The reason for it is that it's documented. The aaf stuff seems to be kind of avid internal stuff. Avid does not even need to share their latest AAFSDK with the open source community. Plus i guess that even if they shared the current AAFSDK, it would still be kept internal how exactly stuff like matching hires to proxy works.
Additionally i seem to have spotted that any "interplay" related projects on github magically dissappeared pretty quickly but that might be some perspectual perspection too...

So, of course all that stuff could be engineered and developed but here is the big question for you and i assume you are an expert in AVID matters:
Do you have the feeling that if we make it and the final integration works, we could deliver the final product legally?

emcodem wrote: ↑Sun Aug 01, 2021 7:10 pm Hey @mtechsup welcome to the forum and thank you for using ffastrans!

Great thread (especially the subject ), i have a feeling that good things could happen here...

mtechsup wrote: ↑Sun Aug 01, 2021 12:40 pm ... i guess is between the compliance of the AAF from pytoaaf with avid.
Avid proxy 800kb creation can be tricky in fact especialy when combined with hires+proxy commits to interplay.

Very well spotted. To be honest, until now we always missed someone with access to a dedicated development environment and the will to work on a solution.
As you very well spotted, the web services is definitely not the big thing. The reason for it is that it's documented. The aaf stuff seems to be kind of avid internal stuff. Avid does not even need to share their latest AAFSDK with the open source community. Plus i guess that even if they shared the current AAFSDK, it would still be kept internal how exactly stuff like matching hires to proxy works.
Additionally i seem to have spotted that any "interplay" related projects on github magically dissappeared pretty quickly but that might be some perspectual perspection too...

So, of course all that stuff could be engineered and developed but here is the big question for you and i assume you are an expert in AVID matters:
Do you have the feeling that if we make it and the final integration works, we could deliver the final product legally?

Hi @emcodem, let me start by saying that I have the exact same feeling.
There are Avid stuff that from time to time is shared to the open community and all the suddently disappears. The reason why that happens i don't know.

What i know is that interplay has a public API documentation and that is how commercial software is making their integrations with interplay and cloud ux.
Be in mind that you can easily retrieve data from interplay by SOAP using Powershell for example.
I don't see nothing illegally here and documentation like i said is public.

On the other hand, Avid has their own Parter Program, called Avid Alliance that help and support those integrators. That "Alliance" is obviously payed and companies must pass over Avid scrutiny.
But i can give you a list of commercial software that don't belong to that Avid Program and do by their own integration with interplay. (This information is not a secret and can easily be found on an internet research).

Most of the players, even the old Avid's Airspeed save a local AAF and from time to time push the AAF onto interplay's so beside the ability to send data to interplay you will also need to assure that the AAF is compliant with interplay.
There are 2 ways of commiting data to interplay, at the beginning / end of each ingest, or through a time routine every X seconds. (Since AMT v2 this routine is already made by design).
An AAF may play correctly with MC as standalone but may not work if injected to interplay using web services.
So, bottom line there are 2 things to have in mind, the correct creation of the AAF, using AAFSDK, Avid Media Toolkit or any other and the ability to write through interplay web services.
You can even have more of this if you read through interplay to be able to export media from it.

Having access to a valid AAF is not a problem, so the question persists is this something meant to be on the roadmap?

About Avid proxy creation, if the encoder writes media as is expect, and the AAF schema structure carries out that data correctly, you can easily checkin both, hires and proxy at once.

Forget about the roadmap, this kind of stuff needs very special attention, it is not something that we can just do whenever we like to do it but it needs someone like you (with the needed resources) to be done.

For start, we should make clear here about the term "public (API)". It is likely that what you identify as the "public" API of Avid is not really public as in "for everyone" but more like for "non for avid internal use only" - public is kind of a common term for 3rdparty API but it does not directly map to any legal or license related stuff. At this moment i assume that the interplay API is protected by either license terms or even by NDA - and i also assume that this is the reason why all published stuff on github dissappears after short time.
So, until this is clear (which might require an official statement from avid to ffastrans), let's concentrate on what we can actually do without the need to care about the legal side:

One way or the other, what we can and should maybe concentrate on is to be able to generate AAF's that are compatible with Interplay.
Just to recap:
-) In first place, and this is what literally everyone else does, one should use the AMT in order to assure that the generated stuff is compatible
-) At the same time, the AMT is not only slow but also incompatible to many formats, so to say it can be pain in the ass for certain usecases (like ingest )
-) AMT is definitely not free plus we do not want to use it anyways, so it would be needed to reverse engineer the current aaf files and modify the only aaf sdk we currently have, namely pyaaf2

So, in my mind, how we start is to just debug where the aaf's from pyaaf2 are creating troubles and correct them accordingly. Unfortunately we need to do this on our own as the creator of pyaaf2 is not very active on it anymore. But that's at least possible.

Before we are going to start, we should elaborate if it makes sense to re-engineer the AAF or if it is more like avid is changing their stuff internally so frequently that this dont make sense. As i personally dont have any avid around, i can only guess and my guess would be that their aaf stuff is progressing but kind of mostly always backwards compatible - which would bring us into a situation that whenever we got it running as desired once, it should work for many, many years.
What do you think?

So to go on with this, we need to get out first if there is an issue with the current aaf. (leaving proxy workflow aside for now)
To be honest, i was under the impression that it already works as it is for at least @taner maybe he can attend here and tell us about it?

To chime in on this: I have the feeling that the Interplay exchange aaf is pretty static and it is not changed frequently. Most of the 3rd party solutions use the webservice/aaf and it would be a nightmare to maintain compatibility accross several platforms and that would also show in the compatibility matrixes. Furthermore avid is moving away from the classic Interplay soap stuff towards the newer MediaCentral API.

I could also participate in this. Currently running an ffastrans/MediaDirector hybrid ingest solution. I have admin access to Interplay, I wrote several java based utility that communicate with interplay via the web services, reverse enginered the isis soap and the new nexis rest apis for my own use. I have an Interplay webservices development licence from avid /not worth much, not a lot of info there/ I am no programmer in any, way just a creative IT development guy at a broadcaster, who gets the job done.

I forgot that I am also ACSR Elite certified so I can get some more inside stuff from AVID but not much more.

Hi Richy,
we were making some progress with Emcodem on Interplay but we stopped as the only systems I manage are the ones in production and we didn't really want to make weird SOAP test calls to a running system as we didn't know how it could react, but it looks like you have everything we need.
Now Emcodem is currently enjoying the sun, lying on a beach all day, away from the PC, but as soon as he's gonna be back we're gonna talk and I think you can very much expect a PM with further instructions on how you can get in contact with us via a private chat and what you can do to help us test the new implementation.

FranceBB wrote: ↑Wed Aug 18, 2021 11:14 am Hi Richy,
we were making some progress with Emcodem on Interplay but we stopped as the only systems I manage are the ones in production and we didn't really want to make weird SOAP test calls to a running system as we didn't know how it could react, but it looks like you have everything we need.
Now Emcodem is currently enjoying the sun, lying on a beach all day, away from the PC, but as soon as he's gonna be back we're gonna talk and I think you can very much expect a PM with further instructions on how you can get in contact with us via a private chat and what you can do to help us test the new implementation.

Good Evening ,
To bring the issue back. What we are missing to do the interplay checking is the AAF and a Webservice API right?