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)
