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

Santiago Jimeno sjimeno at ya.com
Tue Feb 15 22:53:08 CET 2011


Hi Pavel

I know remuxing file is a possible solution. I have never questioned it. But 
this cannot make it everybody.
It is also necessary to keep in mind the number of files to process and the 
time of process.

My goal is to make an editor that can be managed by everybody. Showing and 
editing Tags in a simple way for people that don't know about Matroska 
functionality and much less about XML .
AdingTags by means of a XML file is easy with mkvmerge and besides making it 
well, also remuxing file. But this is only in the hand of some developers 
that know XML, and not all. Plus, it is not useful to make what is already 
made.

In any event if I point out the problems it is because I am working on it. 
Some of them I have already given practical solution in my code and some 
suggestions have been accepted.

Regards. Santiago

----- Original Message ----- 
From: "Pavel Koshevoy" <pkoshevoy at gmail.com>
To: <matroska-devel at lists.matroska.org>
Sent: Tuesday, February 15, 2011 9:11 PM
Subject: Re: [Matroska-devel] Hi, question about the MKV tags


Hi,

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

I've taken the implementation of my goal pretty far by creating a 3-pass
muxer:
   1 -- remove all void elements so no space is wasted, calculate
element positions
   2 -- optimize number of bytes required to encode element position
variable length integers
   3 -- write the file

     Pavel.

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

_______________________________________________
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