Try mxf2raw sample-bmx.mxf instead as that will avoid the ERRORs above. That file is no longer available, but the container and codec ULs look correct.
I'm a little unsure whether the file is FULL_FRAME or MIXED_FIELDS. In fact, even after reading the ST-377 doc, I'm still not sure what the difference is. Both of them specify that all lines are stored as one frame - so what is the difference?
This file is PAL but it has 608 lines (32 added for vertical blanking lines)
If you can help me figure out what I need to change to make this work it would be great.
Interlacing and field order
This writer's understanding is that, when the source footage is interlaced, V210 encoding does not group together all the odd and even lines as they would be grouped in the two fields that make up a video frame on, say, a videotape. All V210 pixel data is presented in a left-right, top-down order that could be called progressive. To put it another way, for interlaced picture data, the tape presents alternate lines in the two fields that make up a frame: line 1, line 3, line 5, etc., and then line 2, line 4, line 6, etc. In contrast, V210 encodes the data as line 1, line 2, line 3, line 4, line 5, line 6, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to process a v210 video file produced by Sony Server (MXF SDK), and am getting the following error.
[root@localhost ~]# bmxtranswrap sample-bmx.mxf
Warning: Track 0 has unknown essence type
Warning: Ignoring track 0 (essence type 'picture essence')
ERROR: 'mxf_disk_file_open_new(filename.c_str(), &mxf_file)' check failed
ERROR: near AppMXFFileFactory.cpp:125
ERROR: BMX exception caught: 'mxf_disk_file_open_new(filename.c_str(), &mxf_file)' check failed
The container ui is 06 0E 2B 34 04 01 01 01 0D 01 03 01 02 05 01 05
and the codec ui is 06 0E 2B 34 04 01 01 0A 04 01 02 01 01 02 02 01
I have a small sample file (~150MB) available here
http://ft.efxmagic.com/index.php/s/mOEURJ8qhbQvPKj
Can you pls let me know if it would be possible for you to support this.
Kind Regards
Swami
Try
mxf2raw sample-bmx.mxf
instead as that will avoid the ERRORs above. That file is no longer available, but the container and codec ULs look correct.The code that checks for support is at https://sourceforge.net/p/bmxlib/bmx/ci/master/tree/src/mxf_helper/UncCDCIMXFDescriptorHelper.cpp#l143. If your file doesn't meet those constraints (labels, display dimensions, frame rate, frame layout) then you will need to modify the code.
Philip
Hi Philip,
The sample file is here
https://gofile.io/d/kw5JYY
I'm a little unsure whether the file is FULL_FRAME or MIXED_FIELDS. In fact, even after reading the ST-377 doc, I'm still not sure what the difference is. Both of them specify that all lines are stored as one frame - so what is the difference?
This file is PAL but it has 608 lines (32 added for vertical blanking lines)
If you can help me figure out what I need to change to make this work it would be great.
Some useful info about v210 is available on the Library of Congess site
https://www.loc.gov/preservation/digital/formats/fdd/fdd000353.shtml
Interlacing and field order
This writer's understanding is that, when the source footage is interlaced, V210 encoding does not group together all the odd and even lines as they would be grouped in the two fields that make up a video frame on, say, a videotape. All V210 pixel data is presented in a left-right, top-down order that could be called progressive. To put it another way, for interlaced picture data, the tape presents alternate lines in the two fields that make up a frame: line 1, line 3, line 5, etc., and then line 2, line 4, line 6, etc. In contrast, V210 encodes the data as line 1, line 2, line 3, line 4, line 5, line 6, etc.