Class HandlerBox, CalculateSize method error ?


it seems CalculateSize method in HandlerBox class does not take into account that Name has and extra 0 (Null terminated string), so that you must add 1 to "Encoding.UTF8.GetByteCount(Name)", isn't?

Thanks for your job!



jclary wrote Mar 26, 2013 at 5:33 PM

The trailing null at the end of a final string value in a box is optional. Running past the box length is a sufficient delimiter so it saves a byte for every box that ends with a string value. In most of the sample files I've got, trailing nulls are not present so I used that convention in all final string values. It's one of the few situations where the library potentially writes out different than it read in.

I've considered storing which was read in and doing the same on the write out. I also considered making it a global option on write.

If you think it's important to do something like that, let me know.

If you know of a player that cares, let me know which one. The optional nature of it has existed since well before the ISO format was derived from the Apple MOV format so everyone should support it.

jclary wrote Mar 26, 2013 at 5:41 PM

Oh, and you'll note the SaveToStream() override uses WriteUTF8String() rather than WriteNullTerminatedUTF8String(). If you change it yourself, you should change which write extension it uses. You should be able to find all cases like this by searching for uses of WriteUTF8String.

The ReadFromStream() override uses ReadNullTerminatedUTF8String() extension which handles the EndOfStreamException raised by the ConstrainedStream. You could alter ReadNullTerminatedUTF8String() to add an out parameter or something to tell you which was in the original stream.

wrote Mar 26, 2013 at 5:46 PM

jclary wrote Mar 26, 2013 at 7:13 PM

By the way, this appears to be a convention not specification. The QT format notes repeatedly that 0 length strings at the end of an atom can be either 0 or simply not present but doesn't say anything specific about non-zero strings. I can't find any mention of it at all in the ISO spec though I want to double-check the errata/addenda because I could have sworn I saw something somewhere about this when I first started getting all the exceptions trying to read trailing strings.

I'll do some more research later tonight and take another look at all my sample files to see what the best default behavior should be.

logtheta wrote Mar 27, 2013 at 8:54 AM

many thanks for your answer.
It's one of the few situations where the library potentially writes out different than it read in.
That's the main point, if you just read and save, you have a different result. At the moment I am interested in a HTML5 player so there is no problem playing file without trailing null. What I can say is that transcoding systems like Carbon Coder will add the trailing null, so I will try to be compliance with this behaviour. I am trying to write a very similar lib in C++ and I found BMFF as a very good point to start. My aim is to split files (specifying markIn/markOut) and to create fragments for a custom stream. I am trying to deal with stts, ctts, stsc and so on in order to obtain a frame accurate splitted files but internal "formulas" to recalculate tables are not always clear :(. Do you have any suggestions please?

Thanks again.