[Matroska-devel] Hi, question about the MKV tags
slhomme at matroska.org
Tue Feb 15 20:49:42 CET 2011
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:
Matroska association Chairman
More information about the Matroska-devel