Since we get more and more projects that want to use the camera C300 with codec AVC Intra, we want to implement that for MXF OP-Atom files in bmxtranswrap.
Can you give us the starting points for this task, and an estimate on how much work it is?
Regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would start with sample files produced by Avid that covers the range of coding options you want to support. Check the descriptor properties Avid uses as you want to follow that exactly in your implementation. Check the file layout and see if it differs from the layout used in the existing format implementations.
It should be relatively straightforward once you have clear idea of what Avid does. After that you can take a look at the implementation in the OP-1A writer to see how to implement the same in OP-Atom. How much work it is depends on how different the format is compared to the existing ones.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am working on this for a few days now. With the changes, bmxtranswrap can convert AVC-Intra HIGH 4:2:2 (1080p) to OP-Atom.
The IndexTableSegments are identical to what Avid produces, except that "Pos Table Count" is not written by Avid. Avid also fills the essence with a bunch of zeros at the end, while bmx does not.
Avid recognizes the converted files and can play the video, no problem so far.
Next step would be interlaced and long-gop formats, but I don't have sample files for that right now.
We are looking to pull the latest from Thomas - but it would be great to know if this support is also going to get added to the main project - as it is a very common format now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thomas: Thanks again for your PR. I've reviewed and made a couple updates related to make distcheck and the Visual C++ build. Your PR and my updates have been pushed tp the phygon-avidavc branch, ready to be merged in.
Before I do that I just wanted to check a couple of things I noticed whilst reviewing the code:
There is a single Index Table entry for each frame. I guess this is because the H.264 is not field encoded (which is not supported in bmx). However, the temporal offset and key frame offset are still multiplied by 2, which suggests there are/should be 2 entries per frame. Is this what Avid produces as well? I see this when using the --no-limit-entries with MXFDump for example.
The Index Table flags are masked with 0x80 (instead of 0xf0 for example), which means the index table doesn't differrentiate I, P or B frames. Is this what Avid produces as well?
The updated code has the Index Table is segmented to avoid hitting the 16-bit size. The MPEG-2 Long GOP code had a comment about Avid ignoring the 16-bit and using the index array count (32-bit) value instead and this comment is also in the new AVC code. Is the comment true for AVC? Does Avid produce the same segmented Index Tables?
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I wrote this patch, I imported videos with Avid and compared the OP-Atom with the files created with the changed bmx library. The index table was binary idential.
Avid also created a segmented Index Table. I first tried it with a single Index Table like it was for XDCAM, but Avid did not like it. I don't remember the errors, because it was almost a year ago.
The comment is just copied from the XDCAM code. I did not check if it still applies for AVC. I guess I should have deleted it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for clarifying that the index tables are binary identical. I'll remove the comment as it doesn't matter in this case. I also need to dig up some of my comments with regards to your DNxHR branch - I'll put them in the relevant thread.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Since we get more and more projects that want to use the camera C300 with codec AVC Intra, we want to implement that for MXF OP-Atom files in bmxtranswrap.
Can you give us the starting points for this task, and an estimate on how much work it is?
Regards,
Thomas
I would start with sample files produced by Avid that covers the range of coding options you want to support. Check the descriptor properties Avid uses as you want to follow that exactly in your implementation. Check the file layout and see if it differs from the layout used in the existing format implementations.
It should be relatively straightforward once you have clear idea of what Avid does. After that you can take a look at the implementation in the OP-1A writer to see how to implement the same in OP-Atom. How much work it is depends on how different the format is compared to the existing ones.
Philip
I am working on this for a few days now. With the changes, bmxtranswrap can convert AVC-Intra HIGH 4:2:2 (1080p) to OP-Atom.
The IndexTableSegments are identical to what Avid produces, except that "Pos Table Count" is not written by Avid. Avid also fills the essence with a bunch of zeros at the end, while bmx does not.
Avid recognizes the converted files and can play the video, no problem so far.
Next step would be interlaced and long-gop formats, but I don't have sample files for that right now.
The code is here on github: https://github.com/Phygon/bmxlib-bmx/tree/AvidAVC
Last edit: Thomas Gritzan 2018-03-28
Thanks. I'll take a closer look when I get more time and comment or make suggestions if necessary.
Philip
We are looking to pull the latest from Thomas - but it would be great to know if this support is also going to get added to the main project - as it is a very common format now.
Yes, it looks fine and should be merged soon.
Philip
Thomas: Thanks again for your PR. I've reviewed and made a couple updates related to
make distcheckand the Visual C++ build. Your PR and my updates have been pushed tp the phygon-avidavc branch, ready to be merged in.Before I do that I just wanted to check a couple of things I noticed whilst reviewing the code:
--no-limit-entrieswith MXFDump for example.Philip
When I wrote this patch, I imported videos with Avid and compared the OP-Atom with the files created with the changed bmx library. The index table was binary idential.
Avid also created a segmented Index Table. I first tried it with a single Index Table like it was for XDCAM, but Avid did not like it. I don't remember the errors, because it was almost a year ago.
The comment is just copied from the XDCAM code. I did not check if it still applies for AVC. I guess I should have deleted it.
Thanks for clarifying that the index tables are binary identical. I'll remove the comment as it doesn't matter in this case. I also need to dig up some of my comments with regards to your DNxHR branch - I'll put them in the relevant thread.
Philip
Hi Thomas,
Thanks for your work getting AVC working in BMX! I've been talking a bit about this in another thread and have uploaded a sample of Long GOP H264 that was created in Avid, if that's helpful too: https://sourceforge.net/p/bmxlib/discussion/general/thread/ba7a0e51/#7ee4