How to handle so called pre-charged frames (XDCAM HD) in FFAStrans

[Silicon]

Nop

[Silicon]

Hi emcodem
Your workflow works as expected! I'll perform more thorough tests, but so far so good.
I have aquestions to last point of your disclaimer.
"... workflow only works 100% correct with:
-) omneon files
-) other files that have NO Origin/Rollout should be fine too
-) BUT files from other Vendors that have Origin/Rollout might work differently than omneon so the duration and starttc could be wrong for those."

What other vendors are creating MXF files with Origin/Rollout frames included?

THANKS A LOT!

[emcodem]

Ok good to know, thanks!
Well the feature to set Origin Value and shorten the actual Duration (Rollout) is mostly needed whenever you deal with OpenGop (e.g. most hardware Encoders do OpenGop) and you want to extract just a specific portion from the stream. So e.g. K2 Servers can deliver Origin/Rollout when you set an in/outpoint in a clip they recorded and export it.. As they are not able to do Software Rendering for the First, shortened GOP where your inpoint is, they just use Origin to tell the decoder that it cannot decode the first 2 B-Frames of the GOP because they point to the I-Frame of a GOP that is just not available anymore (so first GOP carries actually defect Frames from MPEG2 Structural perspective).
On the other hand e.g. Archiving Systems that allow you to unarchive just a portion of an archived Clip can do exactly the same, especially Systems that use Opencube (e.g. IBM Admira) instead of their own MXF Framework (opencube delivers an API for Partial restore and the vendor might have thought it is not neccessary or a bad idea to implement a Rendering of the first and last shortened GOP).

EVS for example uses Opencube but as they do not work with XDCAMHD natively, they do software encoding of the portion you want to export, so they do not produce Origin/Rollout.

As i had some time to dig into this topic, you can throw any further question at me

[EDIT] i just noticed accidently that even the mighty BMX can produce files with Origin/Rollout... i was not yet aware of this.

[Silicon]

Hi emcodem
Thanks for detailed explanation and for your time you're spending to solve my problem ... I really appreciate it.
I believe that all forum members will agree with me when I say, that level of support, which you guys (developers) are providing to us (users) is outstanding.

I have implemented your workflow into my production workflow and starting from tomorrow I'll test it in production.

[emcodem]

test it in production.

Good joke

Haha no worries, the work has already been done long before you asked the question. All i do is to share the R&D results with you.
To be honest, i'd like to have some tool that is able to "smartly render" only the first and last GOP (where the last GOP, so the Rollout is the major issue) of such files but I'd need it to happen "while" they are being recorded from Omneon or being written from "De-Archive System". The rest of the file shall be just unmodified, so no processing on the actual pictures is done (like decode/encode). The idea is to "normalize" such kind of files in a way that we dont loose quality and dont spend processing power but at the same time "normalize" the mxf flavour in a way that usual tools can handle it.

I know how to do that but i dont have the funding currently for it, but when i have it and it is proven to work in production, i'll share it here

What i gave to you is currently considered to be kind of a quick and dirty workaround, but as the future file formats might be I-frame only, my chiefs do not assign the task to me to come up with a sophisticated solution.

Unfortunately, i don't know any clean way how to add this to ffastrans natively at this very moment.

One question that comes to my mind is, what is your "output" format, i hope it is not xdcamhd again?

[Silicon]

Hi emcodem
Yeah it would be great to have a “smart render” solution for this precharge / rollout frames But I can imagine it would consume a lot of manpower to develop it.

As for your last question: unfortunately yes, the target codec is again XDCAM HD422, because my target (news) production system is Sony Sonaps, which is based on XDCAM family of codecs (quite strict). But fortunately the Omneon recorded clips are not so frequent source comparing to other sources.

[emcodem]

It's a shame that you transcode the whole file just for getting rid of the origin and rollout.
From experience, the manpower it takes to do just the tool that gets the job done correctly is not the big effort, a few days and it's done. The problem is always to get the changes in ffmpeg and or BMX back to the original source code... you know, change it in a way that is really useful and future proof. Its a really interesting topic for me but still only (high end) professionals benefit from it so i guess i'd rather work on ffastrans base related topics in my free time