[wantfly]

How to locate a frame in a mxf file by using Index table?

Is there any standard way to locate a fixed frame in a mxf file by using Index table?

[Matt Beard]

I have replied to this question in the mxf.info forum as it has a wider application than just MXFLib.

Are you instead asking how to locate using MXFLib?

[wantfly]

I have to use index table to seek a frame in a MXF file.

And I am so appreciate it that you answer it in mxf.info, but there is still a question that how can I make sure that in which partition the desired Edit is ?
Cause there are several partitions which have the identical BodySID & IndexSID?


If I use the streamoffset of essence to fix that,it seems that the efficiency is not satisified because I have to analysis every patiton which has the identical BodySID & IndexSID to get the BodyOffest.

Is there any commendatory way to do that?

[Matt Beard]

This is one of those areas of MXF where it could be made much better if we could go back and redesign it a little!

The file's RIP will tell you where all the partitions for a specific BodySID are located, but not what stream offset is at the start of that partition.

What you need to do is make an educated guess (oh dear!).

The way to do this is to assume that no body partition contains header metadata or index segments, and that no filler will be used at the start of a body partition except for KAG alignment.

Reading the header partition will tell you the byte offset of the start of essence data in the header partition (if there is any) and looking in the RIP will tell you where the header partition ends (the byte offset of the second partition in the file). This will tell you how many bytes of essence data exist in the header partition (byte offset of partition 2 minus byte offset of start of essence data in the header). This lets you know the stream offset of the first byte of essence in the next partition of the same BodySID. You know the total size of this next essence partition from the RIP (the next partition's start position minus this partition's start position).

All you need to do to work out how many bytes of essence are in the partition is to subtract the number or other bytes. This is where the guesswork comes in - you really need to assume that this number is the minimum legal value, which is either just the size of the partition pack, or the size of the partition pack and a filler to take you to the next KAG.

Working your way through the partitions in this way you should find an estimated location within the file body for the required data. However, this is only an estimated position (because you guesses that the body partitions were the smallest valid size) so you need to verify this. This means that you need to read the partition pack of the partition that you estimate contains the correct position and check the BodyOffset value. This will allow you to correct your estimated position to an exact position.

If your estimate was wrong one of two things will happen:

1) The required essence data will be slightly further on in the same partition - no problem as having the BodyOffset value will let you know exactly where

2) The required essence data is much further on, putting it in a followind partition - much less likely, but not a big problem as you just read the next partition of the same BodySID and use that BodyOffset value to locate the essence.

3) The essence should never be earlier than your estimated position unless a) you estimated wrongly, or b) one of the body partitions starts with less than the minimum number of non-essence bytes (for example it may break the KAG rules or change the KAG setting mid-file) - if this ever happens you just need to seek back to a previous partition and then go to item 1 above.

[wantfly]

Thank you very much! I am very appreciate it that I could get valuable answers from you here.

There are still some questions:
(1) This way is based on stream offset.It seems that the efficiency is not perfect. Is there any standard way based on frame?

(2) You mentioned that "The required essence data is much further on, putting it in a followind partition "in piont (2) above.
But, Is there any possibility that the required essence data is so much further that it may be in the next and next following partition rather than in the following partition?

Best Regards

[Matt Beard]

Glad to help.

1) The index table will allow you to convert from edit unit to stream offset (if the edit rate is not the same as the frame rate you will need to multiply the frame number by the ratio of edit rate to frame rate to get the edit unit number)

2) How much further on in the body the required stream offset is depends on how much non-essence data is included in each body partition. The difference between the estimated position and the actual position will be exactly the number of bytes of non-essence data from the start of the body to the actual position. This will normally only be a few index table segements, but could include some header metadata repetitions - it is unlikely that the total of all this will be more than a partition in size, but this would be possible in a very unusual file. Even if this is so the cost is simply one extra file seek and the reading of one extra sector from the file.

[wantfly]

Thank you very much!

I'm honoured to get the desired answers from you here!

There are still some problems I don't understand:

(1)How can we get the required essence data and make sure the exact partition is the estimated partition or the following partition by using the BodyOffset to verify?

Cause the BodyOffset just tell us the Byte offset of the start of the Essence Container data in the partition , it don't indicate where the required essence data is.

(2)What is the boundary of "slightly further" and "much further "?
These could be comparative or absolute concept.

(3) You mentioned that "total size of this next essence partition from the RIP (the next partition's start position minus this partition's start position)" in your reply.

The total size will tell us how many bytes of essence data exist in this partition(the total size minus this partition's Body Offset), and this is the exact number.

And according to these size of essence data exist in all partitions before the estimated partition,we know the location within the file body for the required data(the sum of those size).


So why should we assume that no body partition contains header metadata or index segments ? Is it necessary?


Or you mean that we can get the estimated partiton by using the total size of the partition minus the size of partition pack(because it is a fixed length), then compare it (the estimated StreamOffset ) with the StreamOffset of the desired EU.
Am I right?