On 19.06.2017 10:28, wm4 wrote:
On Mon, 19 Jun 2017 09:38:19 +0200
Tobias Rapp <t.r...@noa-archive.com> wrote:

On 19.06.2017 02:04, 21na...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to