-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make EbmlElement::HeadSize private #258
Conversation
It won't change after the initial computation.
It's a constexpr that equals 1.
Either it's 0 when we the replacement element fully replaced the EbmlVoid. Or we have a valid size.
It may be filtered out which will result in a size of 0.
Return an error since the replacement didn't happen. The result is used that way in mkvtoolnix.
Even if it would be filtered out, we want to know its actual size.
And expand/shrink the values that can be safely changed based on the context.
It's not specific to EbmlMaster.
The Head size is rarely needed and may be 0 depending on writing filter.
Hard no from me. |
There's GetDataStart() for that. Now it's available for all elements. To expand the size you can use the Get/SetSizeLength() without having to know the exact size. |
So what's the use of removing such a useful function? Apart from creating more work for me. Yes, I'm a bit salty at the moment due to the amount of churn I have to invest in order to keep MKVToolNix compile with the ever changing libs 2.0 & still keep it compatible with 1.x. So — honest question. What's gained by removing this function? |
Reducing the amount of API we have to support. We should have the bare minimum so that mkvtoolnix and VLC (and mkvalidator/mkclean) work. In this case the start of the data seems more interesting in general than the size of the head. In the end you can deduce one from the other. |
The Head size is rarely needed and may be 0 depending on writing filter.
Draft on top of #255