we're using bmxtranswrap as in central importer for mxffiles for over a year now. Usually we are rewrapping op1a Files to Avid-OpAtoms and serving them over a mediaharmony-modded Samba4-Cluster and Mediatool. Every kind of codec is working and we are very happy with this setup (MC 6.5.4.5 , Transfer Manager 2.7.5).
Currently i am evaluating a new Mediacomposer 8.4 with local 3.3 TransferManager. We are accessing the same Files and Mediatool import is still fine, but when i want to send a sequence (send-to-playback), the TransferManager logs following error:
AVC Intra DHM encoder AvGenericFTPMXF::MXFUtilAVCIEncode instantiated for compression Id: 3416
Assertion "Get DisplayXOffset succeded" violated in routine "AA::Media::Media". The Violation occurred at line 242 in file ....\AA\Media.cpp.
...
TransferController::TransferError Error encountered in Session 1, Av::Playback::Sender::Sendframes 23 0
When i look into the atoms (with mxf2raw), it seems to be correct, that "DisplayXOffset" and even "DisplayYOffset" is not set in the PictrueDescriptor. Do you think it might be possible, Avid changed this to a mandatory value?
This issue seems not to be codec-dependent. It even happens with DNxHD (all 1080i25 setup)
The same sourcefiles imported with "Avid FTP-MediaBrowser" do work.
Can you (or somone else) please confirm or validate this issue?
regards
andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those are optional MXF properties with default values, but Avid might now be expecting them to be present anyway in their (internal) Avid OP-Atom format. I can't confirm or validate given that I don't have those products, but I could easily add those properties for the Avid flavour and then someone else needs to test it now works.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I already modified the sourcecode a bit, to check if this would fix the problem. I added
if (mFlavour & MXFDESC_AVID_FLAVOUR) {
cdci_descriptor->setSampledXOffset(0);
cdci_descriptor->setSampledYOffset(0);
cdci_descriptor->setDisplayXOffset(0);
cdci_descriptor->setDisplayYOffset(0);
}
to avcimxfdescriptorhelper.cpp, vc3mxfdescriptorhelper.cpp and dvmxfdescriptorhelper.cpp in function "UpdateFileDescriptor()". The DNxHD 1080p 185Mbit and the DV50 576i file is working after adding this. AVCIntra is still not sendable. But now, i have no special error anymore, only
TransferController::TransferError Error encountered in Session 1, Av::Playback::Sender::Sendframes 23 0
Would it help, if i send you an MXF (avid-atom) generated by the FTP-MediaBrowser? We continue to diff the files tomorrow.
andy
Last edit: Andreas Musch 2015-08-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, happy to take a look at files. To be clear, is it only AVCIntra which is not working and giving that error message? There have been issues with AVCIntra in Avid where it didn't handle larger than expected frame sizes - e.g. see for example this forum thread.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes AVCIntra is actually the problem.
We have many different issues with AVCIntra and Avid, mostly depending on the fact, Avid thinks there is only one valid SPS/PPS, resulting in varying chroma or luma videoeffects ;) Thats why we want to take a look at 8.4.
On 8.4 we see slightly different symptoms - but maybe with the same origin. There are AVCIntra Files which show a kind of "v-sync-problem" like in the analog world in the preview window, resulting the last macroblock-row is flipped to the screen-top and the rest of the picture is moved down.
Possibly this could be the result of a varying element data size. Theses files are even not transferable. I am going to test some AS5000 Files tomorrow. Maybe they show a different behaviour.
Most (85%) of our common AVCIntra material is created by the ingest via a big playout-server vendor. Actually we have to transcode them to DNxHD because that's the only way to get them automatically (and error-free) imported in mediatool.
edit: But adding the X and Y Offset seems to be mandatory for newer Transfermanagers than 2.7.5.... Hope somone else can validate this soon...
andy
Last edit: Andreas Musch 2015-08-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not using Transfer Manager or Media Composer but Avid's Media Toolkit (AMT). bmx rewraps MXF files for AMT that imports these files into an Interplay/ISIS system. This worked as expected until about a year ago when an AMT update (version 2.9) broke our solution. Rewrapped P2 MXF files (DV) generate the same assertions you get in your Transfer Manager workflow.
After reporting this issue to Avid's devpartner programm we were told that this change was by design in order to guarantee file compatibility with other Avid tools.
I'm still looking for a way to fix the assertions. I'll try your suggested fix.
--
Kai
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unlucky, the only way to import AVCIntra Material with bmx to 8.4 MC and 3.3 TM is to skip the SPS/PPS "--force-no-avcihead". Otherwise there will be display-errors in preview and no chance to transfer the footage. FTP-MediaBrowser does the same. Only when skipping the SPS/PPS, footage is "transferable". We first had some hope, beacause the import did work ( without color, but with "v-sync" effects )
So MC 8.4 can even NOT deal with other PPS/SPS from different codec vendors than the Panasonic ones.
But one things seems clear - the OffsetValues have to be set in newer versions. Otherwise TM will not send files. I tested the change backward with 6.5.4.5 which seems to have no compatibilty effect. (if setting the offsets would cause that older versions can not deal with footage anymore)
@KAI: I suppose TransferManger is based on AMT. Good to hear, that somone else can see the "errors"
andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info and confirmation. I've pushed a commit which adds DisplayXOffset/DisplayYOffset/SampledXOffset/SampledYOffset properties for all Avid picture essence types.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the effort.
I did a few tests with your newset commt on said configuration (Avid Mediacoposer 8.4 -> send to playback -> local Avid TransferManger Client 3.3 -> Generic_FTP) using imported DV50, DNxHD and AVCI100, transwrapped from op1a to avid style op-atom.
Looks good to me. :-)
One request/idea comes along:
Would'nt it make sense to also display Display/Sampled/X/Y/Offset in mxf2raw even if their value is 0, when these properties are present in a mxf file?
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've pushed commits which means mxf2raw will now show display_x/y_offset if they are present in the file. I haven't added sampled_x/y_offset because mxf2raw didn't show those before at all - if there is a good reason to show them then I could add them.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done some quick tests with your latest commit. Files transwrapped by this version are now accepted again by AMT and even the few AVCI files I have worked.
--
Kai
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Philip,
we're using bmxtranswrap as in central importer for mxffiles for over a year now. Usually we are rewrapping op1a Files to Avid-OpAtoms and serving them over a mediaharmony-modded Samba4-Cluster and Mediatool. Every kind of codec is working and we are very happy with this setup (MC 6.5.4.5 , Transfer Manager 2.7.5).
Currently i am evaluating a new Mediacomposer 8.4 with local 3.3 TransferManager. We are accessing the same Files and Mediatool import is still fine, but when i want to send a sequence (send-to-playback), the TransferManager logs following error:
AVC Intra DHM encoder AvGenericFTPMXF::MXFUtilAVCIEncode instantiated for compression Id: 3416
Assertion "Get DisplayXOffset succeded" violated in routine "AA::Media::Media". The Violation occurred at line 242 in file ....\AA\Media.cpp.
...
TransferController::TransferError Error encountered in Session 1, Av::Playback::Sender::Sendframes 23 0
When i look into the atoms (with mxf2raw), it seems to be correct, that "DisplayXOffset" and even "DisplayYOffset" is not set in the PictrueDescriptor. Do you think it might be possible, Avid changed this to a mandatory value?
This issue seems not to be codec-dependent. It even happens with DNxHD (all 1080i25 setup)
The same sourcefiles imported with "Avid FTP-MediaBrowser" do work.
Can you (or somone else) please confirm or validate this issue?
regards
andy
Those are optional MXF properties with default values, but Avid might now be expecting them to be present anyway in their (internal) Avid OP-Atom format. I can't confirm or validate given that I don't have those products, but I could easily add those properties for the Avid flavour and then someone else needs to test it now works.
Philip
I already modified the sourcecode a bit, to check if this would fix the problem. I added
if (mFlavour & MXFDESC_AVID_FLAVOUR) {
cdci_descriptor->setSampledXOffset(0);
cdci_descriptor->setSampledYOffset(0);
cdci_descriptor->setDisplayXOffset(0);
cdci_descriptor->setDisplayYOffset(0);
}
to avcimxfdescriptorhelper.cpp, vc3mxfdescriptorhelper.cpp and dvmxfdescriptorhelper.cpp in function "UpdateFileDescriptor()". The DNxHD 1080p 185Mbit and the DV50 576i file is working after adding this. AVCIntra is still not sendable. But now, i have no special error anymore, only
TransferController::TransferError Error encountered in Session 1, Av::Playback::Sender::Sendframes 23 0
Would it help, if i send you an MXF (avid-atom) generated by the FTP-MediaBrowser? We continue to diff the files tomorrow.
andy
Last edit: Andreas Musch 2015-08-19
Yes, happy to take a look at files. To be clear, is it only AVCIntra which is not working and giving that error message? There have been issues with AVCIntra in Avid where it didn't handle larger than expected frame sizes - e.g. see for example this forum thread.
Philip
Yes AVCIntra is actually the problem.
We have many different issues with AVCIntra and Avid, mostly depending on the fact, Avid thinks there is only one valid SPS/PPS, resulting in varying chroma or luma videoeffects ;) Thats why we want to take a look at 8.4.
On 8.4 we see slightly different symptoms - but maybe with the same origin. There are AVCIntra Files which show a kind of "v-sync-problem" like in the analog world in the preview window, resulting the last macroblock-row is flipped to the screen-top and the rest of the picture is moved down.
Possibly this could be the result of a varying element data size. Theses files are even not transferable. I am going to test some AS5000 Files tomorrow. Maybe they show a different behaviour.
Most (85%) of our common AVCIntra material is created by the ingest via a big playout-server vendor. Actually we have to transcode them to DNxHD because that's the only way to get them automatically (and error-free) imported in mediatool.
edit: But adding the X and Y Offset seems to be mandatory for newer Transfermanagers than 2.7.5.... Hope somone else can validate this soon...
andy
Last edit: Andreas Musch 2015-08-18
Hi Andreas and Philip,
I'm not using Transfer Manager or Media Composer but Avid's Media Toolkit (AMT). bmx rewraps MXF files for AMT that imports these files into an Interplay/ISIS system. This worked as expected until about a year ago when an AMT update (version 2.9) broke our solution. Rewrapped P2 MXF files (DV) generate the same assertions you get in your Transfer Manager workflow.
After reporting this issue to Avid's devpartner programm we were told that this change was by design in order to guarantee file compatibility with other Avid tools.
I'm still looking for a way to fix the assertions. I'll try your suggested fix.
--
Kai
Unlucky, the only way to import AVCIntra Material with bmx to 8.4 MC and 3.3 TM is to skip the SPS/PPS "--force-no-avcihead". Otherwise there will be display-errors in preview and no chance to transfer the footage. FTP-MediaBrowser does the same. Only when skipping the SPS/PPS, footage is "transferable". We first had some hope, beacause the import did work ( without color, but with "v-sync" effects )
So MC 8.4 can even NOT deal with other PPS/SPS from different codec vendors than the Panasonic ones.
But one things seems clear - the OffsetValues have to be set in newer versions. Otherwise TM will not send files. I tested the change backward with 6.5.4.5 which seems to have no compatibilty effect. (if setting the offsets would cause that older versions can not deal with footage anymore)
@KAI: I suppose TransferManger is based on AMT. Good to hear, that somone else can see the "errors"
andy
Thanks for the info and confirmation. I've pushed a commit which adds DisplayXOffset/DisplayYOffset/SampledXOffset/SampledYOffset properties for all Avid picture essence types.
Philip
Thanks for the effort.
I did a few tests with your newset commt on said configuration (Avid Mediacoposer 8.4 -> send to playback -> local Avid TransferManger Client 3.3 -> Generic_FTP) using imported DV50, DNxHD and AVCI100, transwrapped from op1a to avid style op-atom.
Looks good to me. :-)
One request/idea comes along:
Would'nt it make sense to also display Display/Sampled/X/Y/Offset in mxf2raw even if their value is 0, when these properties are present in a mxf file?
Michael
That should be easy enough to add, which I'll do. There might be other properties displayed by mxf2raw that could be treated the same way as well.
Philip
I've pushed commits which means mxf2raw will now show display_x/y_offset if they are present in the file. I haven't added sampled_x/y_offset because mxf2raw didn't show those before at all - if there is a good reason to show them then I could add them.
Philip
I've done some quick tests with your latest commit. Files transwrapped by this version are now accepted again by AMT and even the few AVCI files I have worked.
--
Kai