see e967f81f6a.
note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.
In the access modules, we would like to be able to send file properties such as size directly
to the input item. But no reference to this item is accessible.
This field will allow you to retrieve the item created by the function.
libarchive 3.4.0 adds support for RAR 5.0. See
https://www.rarlab.com/technote.htm#rarsign for description of signatures.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
As we might be able to recover from a libarchive fatal error (by
resetting the handle to an appropriate state), there is no need for us
to disable controls completely.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
As a seek should be successful even if the requested position is
outside the bounds of the input, there is no need for us to reset the
state of the libarchive reader immediately after seeking fails,
instead we rely on the fact that future reads will return EOF, and
that the reader will have to seek to a proper position in order to
continue reading (causing a libarchive reset).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The previous implementation would not reset the read position if
someone tried to seek outside the current buffer, causing the module
to signal EOF on subsequent reads, which is of course false.
These changes makes sure that we do our best to reset back to the
original position, preventing a premature EOF.
Close#20540
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
In order for us to start over, such as a failed attempt of
dumb-seeking, we must reset the state of our extractor as if we just
opened the file.
This helper accomplishes that while also making sure that all
associated variables are back in a proper state.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
If we are unable to exit the current source-stream (be that for
whatever reason), we should not ignore the error as it /may/ have
fatal consequences down the road.
Better safe than sorry.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The same check is correctly implemented in archive.c:DirectoryOpen,
but is missing from ExtractorOpen - resulting in a null-pointer
dereference if a libarchive handle fails to be created.
fixes: #18133
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
If the libarchive_exit_cb is called due to clean-up (because we are
dead), there is no point in seeking back to zero. It might even fail
if our source module reacts to vlc_killed (such as
stream_filter/cache_read).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
There are paths that can be skipped if we are closing down the module,
and some should even be explicitly avoided.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Given that p_sys->p_obj is yet to be initialized with the value of the
obj, the implementation should use the latter (given that the former
will be zero-initialized, but nothing more).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
These changes introduces a new module type named stream_extractor. The
added documentation should explain when such module should be used,
but in short it allows for extraction of data within a stream,
effectively resulting in a new stream that refers to the extracted
data.
Interaction with the stream-extractor shall never happen directly,
instead the module-backend is written in a way so that it exposes a
stream_t to the public.
[ access ] -> [ stream_t ] -> [ stream consumer ]
'- [ stream extractor ]
Future changes are necessary in order to make modules of this type
usable in practice, but has been split into individual commits so that
the changes are easier to follow.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
