[Matroska-devel] Hi, question about the MKV tags
pkoshevoy at gmail.com
Tue Feb 15 21:11:23 CET 2011
I've been following this discussion, and I can see the issues.
I agree with Steve here, to simplify the Tags problem it is better to do
what is easy.
Placing tags are at the end the file may not be optimal for streaming,
but that is a problem that already has a solution in the form of remuxing.
Not every tool (tags editor) should attempt to solve every problem.
Personally, I know I am not interested in writing Void elements into files.
I want my mkv/webm files to be as small as possible, with no space wasted.
This is just as valid as the goal of making files easier to edit (tags,
I've taken the implementation of my goal pretty far by creating a 3-pass
1 -- remove all void elements so no space is wasted, calculate
2 -- optimize number of bytes required to encode element position
variable length integers
3 -- write the file
On 2/15/2011 12:49 PM, Steve Lhomme wrote:
> Pictures in tags solve nothing and add more combinations, because they
> are already in use today. You can't discard the past like that.
> If you want to reduce the possible case you need to handle, always
> move the tags and the attachment at the end of the segment. No one is
> forcing you to make perfect files. In fact it's usually the way
> anything is coded. Start with the normal/easy case, and only later
> optimize. All we have talked about is how to make the most optimal
> files in the trickiest conditions. But none of this is mandatory. The
> only thing mandatory is to make valid files and void past data when
> you have moved them (no doublon).
> On Tue, Feb 15, 2011 at 6:47 PM, Santiago Jimeno<sjimeno at ya.com> wrote:
>> I suppose that you now have seen the problem closely and you understand
>> better what I am meaning from my first message .
>> But you have surrendered soon.
>> I take 2 months studying and working about Matroska Tags for writing an
>> editor without remux.
>> The code is very advanced. I have prepared everithing necessary for editing
>> (reading, showing and writing of Tags and Attachments blocks and also
>> handling of SeekHead and SegmentSize)
>> I only have to finish writing one function "ApplyChanges"
>> Here, all aspects related with the Tags edition are already developed. Also
>> the relative thing to the Pictures deletion.
>> In spite of the complexity of Tags edition, with nested tags, etc, I don't
>> have problem.
>> The true difficulty is Attachments, its independencie of Tags, its size, its
>> file position and also the multiple locations that suppose the addición of
>> this for the whole.
>> Also Attachments (thanks to random apps) may have Pictures and Fonts blended
>> in any order, independently of what Order Guidelines says.
>> I summarize the situation:
>> If there is only Tags -> there are 3 edition possibilities with two
>> location combinations. Total (without repeating) 5 possibilities. Already
>> If Pics + Tags -> there are 10 edition possibilities with 4 location
>> combinations. Total (without repeating) 34 possibilities. I only have
>> written 7 of them.
>> Surely the code already written could cover 80% or more than our
>> necessities. But I should write code until for the less likely thing.
>> Example: what happens if the space after SeekHead is only of 1 byte when
>> VOID needs 2 bytes at least (ID and Length=0)
>> For this reason I am proposing the changes that I said in my previous
>> Of them, the simple integration of Pictures inside Tags would suppose an
>> enormous redución of complexity (from 34 to 5 possibilities)
>> And still less complexity if we also fix a definitive location.
>> Then: Pictures or Tags? Or both together in one block?
>> But the decision doesn't correspond me.
>> Regards. Santiago
>> ----- Original Message ----- From: "Steve Lhomme"<slhomme at matroska.org>
>> To: "Discussion about the current and future development of Matroska"
>> <matroska-devel at lists.matroska.org>
>> Sent: Tuesday, February 15, 2011 4:01 PM
>> Subject: Re: [Matroska-devel] Hi, question about the MKV tags
>>> So there is no tag support now, so you're going to use a proprietary
>>> and limited and undocumented way to do it just for yourself ? Hoping
>>> the problem of doing it the clean way will solve by itself ?
>>> On Tue, Feb 15, 2011 at 1:45 PM, Boris Juraga<boris.juraga at gmail.com>
>>>> Well from the conversation till now i have one conclusion - no proper
>>>> tags support is near, not without full remux. So i will use a
>>>> workaround i was using before trying to use the tag system. I will
>>>> create spec complying xml file containing the tags and called
>>>> tags.xml, and instead of adding it to mkvmerge as a global tags xml
>>>> file - i will add it as attachment. And it will be fixed size xml
>>>> document. I think 5KB is more than enough for tags for movie or
>>>> episode. and as it is fixed size, i will use my current tag\attachment
>>>> reader to seek to it and simply over write it with the new tags.xml.
>>>> As the files are exactly the same size no problems will occur. Simply
>>>> if the new tags are bigger than 5KB i will remux.
>>>> I cant think of a single problem with this solution, no one is reading
>>>> tags at the moment so my app will work.
>>>> Matroska-devel mailing list
>>>> Matroska-devel at lists.matroska.org
>>>> Read Matroska-Devel on GMane:
>>> Steve Lhomme
>>> Matroska association Chairman
>>> Matroska-devel mailing list
>>> Matroska-devel at lists.matroska.org
>>> Read Matroska-Devel on GMane:
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> Read Matroska-Devel on GMane:
More information about the Matroska-devel