[Matroska-devel] Hi, question about the MKV tags

Santiago Jimeno sjimeno at ya.com
Wed Feb 16 13:25:34 CET 2011


Hi Steve

It doesn't exist an easy way and another difficult way of approaching to the 
work with metadata.
I see two ways:  or it is approached or it is not approached. It seems that 
up to now the election is the second.
I don't intend to make perfect programs. But when editing I have to foresee 
the problems.
And if my code doesn't foresee it when writing data will damage the file and 
I are not a dilettante.

As for the working technique I agree with you: "Start with the normal/easy 
case, and only later optimize." I have worked this way up to now.
The structure of Matroska Tags is the most complex than all Tags systems. 
But I found interesting and it added new aspects. It was worthwhile to 
attempt it.
Once I resolved the complex aspects of Tags and once I have prepared the 
added/changed data I had to write them.
This was then the work normal/easy.
The outline of ApplyChanges in pseudo-code is:

If Hastag (previous tag)
    If HasDelete
        Delete (2 locations)
    else if HasChanges
        if Size < = Old Size + padding
            Write  + padding (2 locations)
        else
            Write at end
Else (No Tag)
    if HasChanges (New)
        Write at end

This code works perfectly and without errors.
Now it was necessary to expand it with Pictures. And in that point we are.

>From the simple previous code, I pass to study the possibilities and I meet 
with 32.
If I don't want to damage the file I should not leave to contemplate any, 
although it is not very used:
If there is Tags, Pictures or not
If Delete or Change/Add for each one
2 Locations (before and after cluster) for each one
And I only think about the possibility to use padding that there is just 
after (still not other VOID elements ).

The code, if there is only Attachments, would be identical to the previous 
one. But now there are two separate blocks.
You try to group them in combinations of two elements and to include them on 
outline above. The proportion grows in a geometric way. It is still more 
complex than the supposed complexity of Tags structure that made desist to 
so much people, and also much more than what Mosu said about SekHead-Void. I 
wonder if it would be this the reason of desisting.

I have not invented any problem. They were and are there.
I have limited to point out them and to propose possible alternative 
according my working experience with other Tags system.
And I don't also think that to point out them is pessimistic. That depends 
on each person's character.
As these were delicate aspects of Matroska structure (it seems not 
understood), I told you we treated them in private if you had interest.
If I wrote again to the mail list is because you requested it to me.

What to do? I think about several options
1- Work with what there is and just as it is (obviating and ignoring the 
problems)
2- Study background problem, isolating him and to expose it to the community
3- Propose possible alternative or changes (mistaken or not)
4- Implement Tags and to leave Pictures (some app would work with Pictures 
and others with Tags (?))
5- Abandon the work

I had opted for 2 and 3. But I should maybe choose another option.

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 8:49 PM
Subject: Re: [Matroska-devel] Hi, question about the MKV tags


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).

Steve

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
> implemented
> 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
> messages.
> 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>
>> wrote:
>>>
>>> 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
>>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>>> Read Matroska-Devel on GMane:
>>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>>
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>> Read Matroska-Devel on GMane:
>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
Matroska-devel at lists.matroska.org
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: 
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel





More information about the Matroska-devel mailing list