[FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?

[21naown at gmail.com]

Hello,


Simply to tell you that I no longer support my/this thread, especially 
because as Tobias said it is for an “aesthetic reason”.

wm4 has mentioned “EBML elements”, there is no such element in the 
specifications (if I am not wrong):
https://www.matroska.org/technical/specs/tagging/index.html


I will unsubscribe from this mailing list in one month after the last 
reply to this thread (so I will no longer receive messages from all the 
threads if I am not wrong) since I was here mainly for that.


Best regards.



Le 19/06/2017 à 11:37, Tobias Rapp a écrit :
> On 19.06.2017 10:28, wm4 wrote:
>> On Mon, 19 Jun 2017 09:38:19 +0200
>> Tobias Rapp <t.rapp at noa-archive.com> wrote:
>>
>>> On 19.06.2017 02:04, 21naown at gmail.com wrote:
>>>> Le 18/06/2017 à 00:57, Sasi Inguva a écrit :
>>>>> Hi,
>>>>>
>>>>> I was the one who made that change. We needed a way to obtain 
>>>>> individual
>>>>> stream durations from a  Matroska file without reading the entire 
>>>>> file. I
>>>>> don't think it adds to the file size greatly (< 50 bytes) compared 
>>>>> to the
>>>>> size of video and audio data, hence I didn't hide it under an option.
>>>>> However if u really need it I can add an option.
>>>>>
>>>>
>>>> Hello,
>>>>
>>>> Yes the size required for the tag “DURATION” is insignificant, but 
>>>> it is
>>>> preferable to have a choice with this tag like mkvmerge partially does
>>>> (because by default “--enable-durations” is enabled, maybe because 
>>>> it is
>>>> a part of “statistics-tags”, but we can disable them with
>>>> “--disable-track-statistics-tags”) and because the end user and his
>>>> software do not require it.
>>>>
>>>> Yes if you can move the tag “DURATION” as an optional tag—so an 
>>>> argument
>>>> is needed to enable it, I will be grateful to you.
>>>
>>> I disagree to this tag writing being opt-in. It requires marginal
>>> runtime and storage space resources to write a duration field. The
>>> application used for playback might change or even a new version of the
>>> same application might make use of the tag. So it would be better to
>>> enable it by default.
>>>
>>> And for the tag writing being opt-out: Maintaining code also has some
>>> cost. As far as I understand this option would just be required for 
>>> some
>>> aesthetic reason, thus I don't think it's worth adding that maintenance
>>> cost by implementing code to make this tag opt-out.
>>
>> But there's also this argument that writing these tags is silly, and
>> that mkvmerge should never have started it. Instead, there should be
>> proper EBML elements for this.
>
> If there are proper fields for it in the container and they are 
> supported by most applications, then yes: it makes no sense to 
> duplicate the value into some metadata tag.
>
> Regards,
> Tobias
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel