stop trying to read random atoms

GCC and Linux do not agree on the underlying type -long or long long-
for fixed size 64-bits integer on 64-bits architectures.

...like other access plugins already do. The input thread does not care
if the original psz_demux value is overriden.

datatype was changed assuming a cable private type 0x82
without even parsing other registration types.
In that case, it was breaking HDMV which also uses 0x82
for DTS audio.

introduced by 7e3dcdd0

refs #7127

in a way to get rid of most limits checks.
Fixes the corner case where i_rest was always 0 and
the index kept incrementing (source of prev oob access)

Close #6649

Ref #6649

Fixes #10533

Ref #6649

Arccos FTW
Ref #6649

Arccos protection system!
Ref #6649

Signed-off-by: Rafaël Carré <funman@videolan.org>

Some tools differ significantly between micro revisions.
Signed-off-by: Rafaël Carré <funman@videolan.org>

If first chunk is greater than first samples duration, the
data is never read/sent.
(segmented mp4 related, demux tries to read 100ms (CLOCK_FREQ/10)
- [0] duration=133ms media time=-1ms) rate=1.0
- [1] duration=667034ms media time=66ms) rate=1.0

refs #11162

it is never enabled

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Tristan Matthews <le.businessman@gmail.com>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>