-
Notifications
You must be signed in to change notification settings - Fork 17
Adding New Box Classes
essential61 edited this page Dec 23, 2019
·
1 revision
-
Paste the following into the python source code file (either iso.py or non-iso.py) and edit
<boxtype>
to match the box type you are writing a class definition for (refer to thebox_factory()
orbox_factory_non_iso()
functions to understand why naming the class using a specific convention is important). Also choose from<Mp4Box|Mp4FullBox>
to inherit from the appropriate superclass depending on whether the box incorporates version and header fields`class <BoxType>Box(<Mp4Box|Mp4FullBox>):` `def __init__(self, fp, header, parent):` `super().__init__(fp, header, parent)` `try:` `# At the point of entry into the try-block, the pointer fp will` `# be pointing to the start of the box payload` `# i.e. immediately after the header (and version + flag information if derived from FullBox)` `# replace the pass statement with statements that actually read the data` `# e.g. self.box_info['my_field'] = read_u32(fp)` `pass` `finally:` `fp.seek(self.start_of_box + self.size)`
-
Edit the code inside the
try
block of the class definition of step 1 to read the data fields appropriate for the box type.
Note:try-finally
has been adopted as a project convention even though it does not really do anything at run-time as there is noexcept
clause. The reasons for using it are:- it emphasises that the file pointer must be located at the end of the box on leaving
__init__
. - the mp4 file should parse successfully even when the class definition is incomplete.
- it is easy to cast your eye over the source code file and verify that all
__init__
end with the linefp.seek(self.start_of_box + self.size)
- it emphasises that the file pointer must be located at the end of the box on leaving