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

[Filip Roséen]

Hi,

On 2016-11-02 10:29, Steve Lhomme wrote:

> To summarize the issue, is STREAM_CAN_FASTSEEK_FORWARD needed ?

No, what one could argue is necessary is a straight-forward way to
know whether a stream has a finite size or not (which would lead to
problems in terms of implementation, since there's nothing that really
guarantees this for all/most accessors).

Also, it is not really about "seeking forward" given that we need to
exhaust (somewhat byte-wise) every cluster stumbled upon in order to
find the next one (since we cannot read the cluster header, and then
simply jump to the end of it). I am not sure how
*libmatroska*/*libebml* handles this internally.

`STREAM_CAN_FASTSEEK_FORWARD` sounds more like `STREAM_CAN_FASTSKIP`,
but I really don't think that we need more controls in that regard;
this particular issue boils down to semantics, not the current state
of `stream_t`.

> As you say, it's a way to know the duration even if it's not written
> specifically. So that's already a fringe case. If the file is
> particularly badly muxed, then too bad it's normal that it doesn't
> play quickly. But we shouldn't remove the feature of knowing the
> duration of a fully written file just to avoid to read bad files too
> much. The same applies for a file with no duration and no Cues. All
> Clusters and the whole last Cluster will need to be parsed. And that
> has nothing to do with the finite size. It has everything to do with
> how fast we can seek through all these data.

Yes, we already try to compensate for a badly muxed stream, should we
then take another step in the "let's save the muxer" direction, and
forgive it for generating clusters with a non-finite size (where the
decision to not specifying the size might actually be a valid one)?

In my opinion the theory behind my argumentation holds ground; if a
cluster has no size, expecting it to end might be practically
possible, but in theory it is not.

> So yes, f2756634ed3601fa7c00e974533f68fcbbb12d06 is wrong IMO too. I
> overlooked it.

If anything I think it should be an opt-in option if we decide to
query non-finite clusters for their duration (in order to get the
duration of the entire file).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161102/bd33c193/attachment.html>