Version 0.9.2 XDCAM HQ encoding issues

[silicontrip]

Version 0.9.2 XDCAM HQ (35mbit) output occasionally creates incompatible files. Which need to be run through bmxtranswrap to successfully ingest into our DAM.

We haven't been able to work out the difference between the files that fail and the files that are successful.

Is it possible to force re-wrapping of the mxf files with bmxtranswrap?

Thanks
Mark

[silicontrip]

I think the problem might've been in the way that I've been converting from 50p to 50i (or 25i, silly field vs frame notation) and that resulting clips with odd number of frames was causing this issue. I'm not sure what was happening inside the XDCAM encoder that we didn't see this incorrect conversion sooner.

[admin]

So the FFAStrans generated XDCAM 35mbit files was OK before 0.9.2?

-steinar

[silicontrip]

we were using version 0.8.0 without issues. I'm pretty sure all clips were ran through bmxtranswrap after coming out of the ffmpeg encoder.
I know that when I wrote my own ffmpeg shell script to perform encoding, I had to use bmxtranswrap on the resulting files from ffmpeg.

After a workflow change, due to a recommendation in another thread, (I connected the AV/Media Decoder directly into the XDCAM Encoder) we are now experiencing this issue again.

The occurrence is rare, about 1 clip in 20 fail. And so far all of the source clips that have failed are already in the correct visual format, require no scaling, no fps conversion and no interlace conversion.

It's a puzzle as to why they aren't correctly ingested. It is likely that our DAM is exceptionally fussy about the files but running them through bmxtranswrap solves the issue.

Can I use the Custom Command Executor to run bmxtranswrap over these files?

Thanks

[admin]

I can confirm that bmxtranswrap was used on all 1440x1080 XDCAM files prior to 0.9.x. Now it's only on 1440x1080 25 Mbit files. My testing with the other formats seemed to be ok with only the ffmpeg mxf muxer but maybe it was not after all.
I think will will change the behavour of the encoder so that the user him/her self can choose to use bmxtranswrap as MXF-wrapper. Would that be OK?

You can use the bmxtranswarpper yourself in the "Command executor" node right after the encoder. Just use the %s_source% to feed the command:

%comspec% /c ""%s_ffastrans_dir%\Processors\mxf_tools\bmxtranswrap.exe" -o "X:\Path\to\my\outputfile.mxf" "%s_source%""

-steinar

[silicontrip]

Using the custom command in the mean time, is it possible to overwrite the existing file so that the deliveries processor puts the correct file in its final place?

The ffmpeg encoder is much more compliant than past versions, previously every file needed to be post processed with bmxtranswrap. Now it appears to be only source files that share the same specifications as the output.

I cannot see any difference between the failed files and the successful files. All the metadata reported by ffmpeg and by mediainfo appear to be identical. I believe it may be something to do with the GOP structure of the last GOP of the xdcam file.

An option to use bmxtranswrap would be awesome.

thank you.

[admin]

Both ffmpeg and mediainfo is insufficient in revealing all the differences between different mxf-wrappers. I can't tell if it's the GOP structure or MXF wrapping that cause the problem, but I have seen systems treating video different with different MXF wrappers even though the video essense is identical. But if bmxtranswrap solves the problem then it's probably the wrapper, not the video essense that cause the problems.

In the "Command executor" node you set the "Set %s_source% variable to:" to the same as you use as output for bmxtranswrap. This will cause the next node to use that output instead. The %s_source% is the variable FFAStrans use to store the output from every node.

-steinar

[silicontrip]

The wrapper ffmpeg produces is not necessarily the problem. The majority of clips work and ingest without issues. It's just the odd couple that don't. It would be nice to work out what these differences are.

[JohnB1]

Hi Guys,

I am using FFASTrans 0.9.4.0 and facing quite similar problems, randomly some files fail after being transcoded by XDCAM.

Will use command executer now.

I'll post back here when it works.

Regards,
John

[emcodem]

Did you set the mxf wrapper to BMX instead of ffmpeg in the XDCAM Processor?