FFAStrans forum

Hi Ghtais,
first of all emcodem is right in the sense that what I'm about to post should not be used as it's gonna make a GOP Structure which is... well... not exactly correct and compliant with the standard, but I feel like I should fulfill what I promised you yesterday evening before watching the Chelsea game on the telly, which is how to lie to MediaInfo and co and show GOP: Closed.
which lead to:



Now, of course emcodem is gonna warn you about the fact that you shouldn't be using this and that if you take a look at the GOP structure it's not gonna be compliant, but I felt like you deserved to know and decide yourself whether to give it a shot or not.

Yeah.. this is showing the closest thing we were able to get out of ffmpeg when trying to create xdcamhd with closed GOP. The whole topic was being under investigation about a year ago or such.

We noticed that when setting ffmpeg to output closed GOP, the GOP is IPBB instead of IBBP and after some research it seemed to turn out that ffmpeg is just not able to create IBBP in closed GOP, or at least we didnt find any hint that anyone ever got this to work (This is e.g. the reason why in all files from current xdcamhd processor start with an IPBB GOP too: the first GOP is closed and ffmpeg cannot do it better; and only the first GOP is closed, all others are open).

Now, it is one thing to have a bunch of GOP's not following the IBBP requirement but i am not sure if it is a good idea to have all GOPs different to what the standard wants. Even if it will play on some or most playout ports, there is a chance that some XDCAMHD applications are not prepared for it.
Additionally, wile experimenting with this, it turned out that there were pretty big differences in encoding quality with those ffmpeg closed vs openGOP versions but we stopped investigating because we realized that we will not be able to get the wanted IBBP structure.

Anyway, for your usecase ghtais, this could actually be a match because Baton will basically not complain about xdcam compatibility issues with the IPBB Gops, so it could be worth a try to strip the unneeded stuff from franks commandline, add the missing audios and send it over for your customers' QC.

On another topic, i was under the impression that we deal with an already encoded file here, e.g. i was not aware that ffastrans encoded the original file because in that case you could just set the correct start timecode too or what im i missing here?

Hi guys !

many thanks for your suggestions and works. It seems that we cannot achieve what my broadcaster wants with FFmpeg. I cannot deliver uncompliant XDcam or poor quality video so I have to find an other way to encode my file. I know that Vantage is ok but too much expensive ... maybe AME can do the job, I will see.

@Emcodem : you're right, Avid encode the file and I rewrapp using BMX in a FFAstrans workflow. I opened a case at AVID but I thing they don't care ... encoding Closed GOP XDcam with header TC is not considered as essential

Ghtais wrote: ↑Wed Oct 27, 2021 8:46 pm I know that Vantage is NOT ok

There, I fixed it for you eheheheh
(You're in the FFAStrans forum )

FranceBB wrote: ↑Wed Oct 27, 2021 10:25 pm

Ghtais wrote: ↑Wed Oct 27, 2021 8:46 pm I know that Vantage is NOT ok

There, I fixed it for you eheheheh
(You're in the FFAStrans forum )

I think They use mainconcept as so many others do.
We could do that too but it's a buying thing... i guess it would be like a few hundred dollars per user but not sure about it, maybe it's even like we pay one time a few thousands and then everyone can have it . I'd really like to be able to offer this to users but unless someone asks for it i'll not investigate further

Emcodem,

can you develop quickly how we can integrated the mainconcept Mpeg 2 SDK in FFAstrans ?
Noob question : is it a kind of CMD software that we could drive in a commandline processor ?
if it delivers exactly the right format that my broadcaster asks for a few hundred dollars, it could interested me... in the same time it avoid me to buy a vantage heheheh

Thats exactly my thinking. The mainconcept stuff is not only of higher quality but it should also be faster than the ffmpeg mpeg2 encoder, so it could really be interesting for professional ffastrans users.

Well for a first simple implementation we wouldn't really need to do much, the example programs that mainconcept delivers along with their SDK already do what we want.
The workflow would need to encode the video into a video only m2v stream first and then in a second step, wrap the video and audios into the final mxf stream (thats how the good old carboncoder produced xdcam actually hehe).

The m2v creation would use ffmpeg to decode the video from source and inline pipe the decoded frames to the mainconcept.exe which directly encodes the XDCAMHD. I just tested this using the example program that comes with mainconcept MPEG2 encoder sdk and it worked on first try (surprisingly)

From the past, i know that working with mainconcept can be tedious, they would most likely force us to implement some licensing mechanism and give them a monthly report about the number of sold licenses.
Same would probably go if you just buy the mainconcept SDK yourself, they'd force you to equip the final product with a licensing mechanism and you'd pay per host where it's used.

Anyway, as i now know that it's really, really easy to include this from a technical perspective, i'll contact and ask them about if and how they can imagine to proceed

Hi emcodem

thank you for informations. We are producer here and I just want to encode my master file with Mpeg2 closed GOP and deliver to the broadcaster. Its not the same case as you for FFAstrans; Do you really think that They can ask me for monthly licencing ?
Or do you mean you (FFAstrans team) deal with mainconcept and I will have to purchase licence from you (FFAStrans team) ?

I have seen that I can ask for a 60 days trial version. Before asking that, I want to be sure that I can easily integrated it to FFAstrans.

Let me know what thez answer

Bye

Hehe no its not about monthly payment but a monthly report how much licenses of software has been sold. (so they want us to report monthly that we sold 0 licenses this month) - After all, when you buy an SDK, it is assumed that you "sell" the final product, or when you use it internally in the company, you have to report to how many copies you rolled out to how many new servers this month.

Anyway, maybe it all changed meanwhile. You can go for their demo, it doesnt really have consequences except maybe a salesman asking you if you wanna buy

Meanwile we posted them a message asking for their ideas how ffastrans users could benefit from their stuff, let's see what they reply.

Aye Ghtais,

so mainconcept answered and they'd need one to pay a fee of about 2.5K base price just for the SDK (without anyone actually using the codecs) and then each and every Host that runs the resulting program would need to be licensed for - as i said before one to a few hundred - depending on the number of new hosts that are licensed per year (i'd expect <10 new per year hehe).
So after all, it would be best if we as ffastrans could license the base SDK and users only have to pay per license... but you know, there come different problems with that as ffastrans has no company nor money Sure we thought about alternatives for you (for the last 10 years hehe) but this is one of the cheapest when it comes to multiple hosts need to use the mainconcept encoding.

Anyway, this discussion (and you cannot imagine how long it was), caused us to work on the yet unclear topics, as there are (in bold)

1) When doing Closed GOP, we can only do IPBB instead of IBBP

Strictly speaking, this violates the RDD9 standard, in a similar way than "Smartrendered Files" from Adobe Premiere files sections do. Still, they should usually pass through the usual suspect QC checks and more important they seem to be accepted by Sony XDCAM Driver as well as they play on playout. Also, each and every XDCAMHD File that one encodes Today using ffastrans contains the same GOP structure for the FIRST GOP, but even worse in the files we produce today, the First GOP is shortened to 10 instead of 12 frames. Also, the number of P and B frames in IPBB is the same as in IBBP, as well as the frame sizes match very well.
@FranceBB anyway wanted to open a feature request ticket about it in order to see if we finally can sort this out in ffmpeg. But it is unlikely that someone takes care about it for free because it is a rare professional topic. Here some impresson from the ffmpeg-user list regarding that topic: https://ffmpeg-user.ffmpeg.narkive.com/ ... -structure

2) the encoder quality was believed to drop down using closed gop

Ok, so by investing many hours checking out about the quality, we recognized that 2) was actually just a rumour and the quality with closed GOP does not really differ from the quality of open GOP with ffastrans. There are many parameters in ffastrans set to enhance the quality, so a command like @FranceBB posted above will not lead to a compareable result, too many optimisations are missing.

So what about mainconcept now?
On my way testing out the encoding quality, i noticed that mainconcept seems to run faster and deliver slightly better quality than any test we ran with ffmpeg, so honestly if i went big on utilizing ffastrans as a user producing XDCAMHD, i'd probably go for the mainconcept approach just to get out the best and to get started "immediately" instead of waiting for someone to maybe enhance ffmpeg. This especially when the encoded files are subject to be edited further on instead of being the finally played out master file. The GOP structure was of course the expected IBBP.


And whats the Final conclusion?
Anyway, here is the outcome of the last days work, it will only work when the source file already has 8 tracks/each 1 channel, one would need some workflow logic to support more audio layouts.
As you need to transcode anyways because of the "Avid cannot encode closed" problem, we get rid of the previous timecode topic automatically. I strongly believe that this should pass your customers QC, chances that they detect the IPBB GOP are pretty low but still given.

• Closed GOP XDCAMHD 1080i25, IPBB structure

• Best picture quality we were yet able to get out

• Wrapped in BMX container (in a single run)

• Ready to use in Commandline Processor

• Limited to accepting sources with 8 audio tracks/each 1 channel (if you need support other source layouts, there is some workflow logic needed to decide the audio map)