The documentation and code-usage state that streams cannot have that
control fail, only some types of demuxes can.
From the demuxer documentation:
> /** Retrieves the PTS delay (roughly the default buffer duration).
> * Can fail only if synchronous and <b>not</b> an access-demuxer. The
> * underlying input stream then determines the PTS delay.
> *
> * arg1= vlc_tick_t * */
> DEMUX_GET_PTS_DELAY = 0x101,
From the stream documentation:
> STREAM_GET_PTS_DELAY = 0x101,/**< arg1= vlc_tick_t* res=cannot fail */
This patch reflects this behavior in the stream API.
We read 32 bits, we skip exactly 8 bytes. We don't need to know
the storage size where we put the value.
From C11 7.20.1.1:
The typedef name uintN_t designates an unsigned integer type with width N and no padding bits.
It is not used in POSIX systems. On other system it probably don't make a
difference anymore, only Windows has actual useful values for
VLC_THREAD_PRIORITY_XXX. The synchronization is more important than having some
threads called more often than others.
The extra 32 octets are only needed if a certain flag is set.
The size constraint is on the max amount that GetDWLE can return which doesn't
have any limit in the specs:
https://mutagen-specs.readthedocs.io/en/latest/apev2/apev2.html
A different check on the size we actually allow to keep (MAX_TAG_SIZE) in
memory is done elsewhere and doesn't belong in the header size reporter.
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.
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
Originally all access plugins were guaranteed to handle
ACCESS_CAN_FASTSEEK one way or the other. Now that demux and access
plugins use the same capability, this assumption no longer holds.
This fixes an unitialized read.
When the prefetch buffer is filled, when the buffer offset is 0 and when a seek
is done past the buffer length, history can be bigger than buffer_length.
This could lead to a read corruption but not a buffer overflow since the size
of the circular buffer is not impacted by this bug.