Can we just use toString instead of toHTML. I know it's not pretty but until we have a better solution, we should keep everything consistent.

HTML formatting of semantic value is removed in aefb5bd

Oh wait, I was just expecting you would rename toHTML to toString as we return html for some toString calls already.

Hmm, I had assumed that toString() gives unformatted output that could be used in testual reports and possibly post formatted into HTML, MD etc. In other projects toString() and toHTML() are kept seperate for that reason with toString() always being available and toHTML()being an optional enhancement. I will look for instances where you havetoString()` returning HTML and consider that approach

I know, it's not perfect. I imagine, once (if) we have a more modern file reader app we could rewrite some of these toString conversions so that it's much more streamlined.

I am happy to leave it in string format for now - it is still readable and allows the MP4 file to be inspected. If formal toHTML() support is added in the future, I can add it into the AVS3 related boxes

I don't think we are ever going to add toHTML or possibly even toString. If we revise the file reader demo, I would expect display related stuff would be there.

Right now the important thing is that how these boxes look like in the current file reader demo. If it would be better to display some fields as a html table for example, toString would need to return that.

The output without HTML is OK.

Do we need this if we have endianness? If we access BitBuffer (or BitReader) from DataStream, we could use the endianness from there as well.

Yes, its possible to use the endianess from DataStream, but at present DataStream does not provide reading and writing of arbitrary bitlength values. Sine the structure header informs on the total number of bytes needed, it seems easier to read these into a bit based reader/writer with a seperate deserialize/serialize process into the DataStream.
If there are other MP4 boxes that would benefit from bit level read/write then we could consider adapting DataStream in the future - just don't want to be disruptive at this time.

Except for sample entries I don't think there are many boxes that would benefit from this. But in the future we might process samples to get codec specific information. At that time it could be useful to have this functionality available through the DataStream.

I'm okay with keeping BitBuffer class seperate as long as we can access it through DataStream. We could switch to bit level reading on-demand if needed.

I'm okay with keeping BitBuffer class seperate as long as we can access it through DataStream. We could switch to bit level reading on-demand if needed.

I started looking at this but felt that for the interim it was better to have a seperate bit-wise parser and not interfere with DataStream that is relied on by many classes. Some other nuances can exist as well, for example with boxes are not byte aligned (happens in transport streams with descriptors but perhaps not in ISO BMFF boxes)

I guess by the time you've started this PR (original one #456), we didn't had an easy way to test everything. As long as the tests pass on this PR (or run npm test) it should be all good.

On gpac, we have Bitstream namespace that handle both byte and bit level parsing: https://doxygen.gpac.io/group__bs__grp.html

gf_bs_read_int is all that was needed for bit level reading. Excluding the emulation prevention byte handling of course. We don't need that much stuff right now though.

If you don't want to combine BitBuffer with DataStream, or make it accesible from DataStream. We should at least make it possible to construct BitBuffer via DataStream. For example:

const ds = new DataStream(buffer)
const bs = BitBuffer.from(ds)
// Would need to handle already read bits when we use ds again

Or something like that. Just so that we won't need to copy the data beforehand. When we drop/discard the BitBuffer the state in DataStream would stay intact (the same one given to box parsers via the parse() method).

I was initially considering such an approach, but since for the current AVS3 case I knew how many bytes I would need, it was easier to grab them from DataStream and reuse a port of BitBuffer from C++ that was used elsewhere. Certainly, when an infinate (or extremely long) bitstream is needed to be parsed in a bit-by-bit manner, the approach you identify makes the most sense and when the bit reading is finished, the next byte ready would pick up an aligned 8 bits from DataStream.
Seperately, I will look into this

Precisely. I guess having this available via or compatible with DataStream would make it a very useful contribution.