[vlc-devel] [PATCH 1/4] mkv/demux: fix 17567: null-pointer dereference in EnsureDuration

[Filip Roséen]

Hi,

I think we can agree on the fact that we do not agree about the
semantics of how to treat unread clusters of unknown size.

My primary objective was to fix the crash, if you want to change the
semantics of `EnsureDuration` (which you approved in the previous
patch-set) I will not be overly excited, but as long as the crash is
fixed.. it's better than nothing.

Thanks,\
Filip Roséen

On 2016-11-02 09:50, Steve Lhomme wrote:

> If the source is not being update/appended while reading (a finite
> size file) then you know where the end is and you can fully parse the
> file.

Of course, when the stream is fully exhausted we can seek back to the
beginning and play the file; but my reasoning is precisely not to
exhaust a stream where an non-finite cluster is present.


> That has nothing to do with the fact the muxer didn't know the end
> when it wrote the data.

The fact that the *muxer* did not know, or was not clever enough to
fill in that piece of data after the cluster was created, should not
cause us to potentially run into issues where playback does not start
within a reasonable amount of time, or not at all, because we are
waiting for `EnsureDuration` to finish.

I rather eliminate all *false-positives* and not exhaust clusters
where the size is inherently unknown, than to start running through
the stream (when we have no idea where we will stop).

> So far we rely on STREAM_CAN_FASTSEEK in EnsureDuration to tell in
> which case we are. It may not be perfect but that's closer to not
> parsing the duration for a fully written file.

`EnsureDuration` is a **hack** to get a duration for files that does
not include such in its metadata, and with that I don't think we
should invoke usage of this hack in places where we cannot prove (to
`100%`) that the stream actually is finite (if the size of a cluster
is not there, nothing states that we will get to the end).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161102/5b6d03de/attachment.html>