2010-01-30 22:26:47 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2010-01-30 22:26:47 +00:00
|
|
|
*
|
stream: change license to LGPL
All relevant authors have agreed.
There are two exceptions, patches by authors who could not be reached.
This commit tries to remove their copyright.
a0f08fbe: messes with the seeking code corner cases. The EOF flag logic
was changed at some point, and always had a flaky history (see e.g.
347cf972 50274ca3 70411f27 5999efb9 0d5e6084 ff08d0c3 2e2f77e3 de5566f0
9554a844, all which happened after that patch, MPlayer ones without that
patch). I claim that all of the copyright the patch might have added is
gone. Except the message in stream_seek(), which this commit removes.
The other code removed/changed in stream_seek() is probably not from
that patch, but it doesn't hurt to be sure, and also makes it more
readable. (It might change the behavior so that sometimes the eof flag
is set after a seek, but it doesn't matter here.)
2aa6acd9: it looks like the seek_forward() modified by this patch was
later moved to stream.c and renamed to stream_skip_read() in a790f2133.
(Looking closer at it, it was actually modified again a bunch of times,
fixing the logic.) I rewrote it in this commit. The code ended up rather
similar, which probably could lead to doubts whether this was done
properly, but I guess the reader of this will just have to believe me. I
knew what stream_skip_read() was supposed to do (which was reinforced
when I tried to replace it on the caller side), without reading the
pre-existing code in detail. I had to "relearn" the logic how buf_pos
and bug_len work - it was actually easy to see from stream_read_char()
how to skip the data, essentially by generalizing its logic from 1 byte
to N bytes. From the old code I only "used" the fact that it's obviously
a while(len>0) look, that has to call stream_fill_buffer repeatedly to
make progress. At first I actually didn't use stream_fill_buffer_by(),
but the variant without _by, but readded it when I checked why the old
code used it (see cd7ec016e7). This has to be good enough. In the end,
it's hard to argue that this could be implemented in a way not using
such a loop.
Other than this, I could add the usual remarks about how this code was
not modularized in the past, and how stream.c contained DVD code, and
how this was later modularized, moving the copyright to other files, and
so on. Also, if someone wrote a stream module, and was not asked about
LGPL relicensing, we don't consider the entry in stream_list[]
copyrightable.
2017-06-19 14:07:42 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2010-01-30 22:26:47 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 22:26:47 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
stream: change license to LGPL
All relevant authors have agreed.
There are two exceptions, patches by authors who could not be reached.
This commit tries to remove their copyright.
a0f08fbe: messes with the seeking code corner cases. The EOF flag logic
was changed at some point, and always had a flaky history (see e.g.
347cf972 50274ca3 70411f27 5999efb9 0d5e6084 ff08d0c3 2e2f77e3 de5566f0
9554a844, all which happened after that patch, MPlayer ones without that
patch). I claim that all of the copyright the patch might have added is
gone. Except the message in stream_seek(), which this commit removes.
The other code removed/changed in stream_seek() is probably not from
that patch, but it doesn't hurt to be sure, and also makes it more
readable. (It might change the behavior so that sometimes the eof flag
is set after a seek, but it doesn't matter here.)
2aa6acd9: it looks like the seek_forward() modified by this patch was
later moved to stream.c and renamed to stream_skip_read() in a790f2133.
(Looking closer at it, it was actually modified again a bunch of times,
fixing the logic.) I rewrote it in this commit. The code ended up rather
similar, which probably could lead to doubts whether this was done
properly, but I guess the reader of this will just have to believe me. I
knew what stream_skip_read() was supposed to do (which was reinforced
when I tried to replace it on the caller side), without reading the
pre-existing code in detail. I had to "relearn" the logic how buf_pos
and bug_len work - it was actually easy to see from stream_read_char()
how to skip the data, essentially by generalizing its logic from 1 byte
to N bytes. From the old code I only "used" the fact that it's obviously
a while(len>0) look, that has to call stream_fill_buffer repeatedly to
make progress. At first I actually didn't use stream_fill_buffer_by(),
but the variant without _by, but readded it when I checked why the old
code used it (see cd7ec016e7). This has to be good enough. In the end,
it's hard to argue that this could be implemented in a way not using
such a loop.
Other than this, I could add the usual remarks about how this code was
not modularized in the past, and how stream.c contained DVD code, and
how this was later modularized, moving the copyright to other files, and
so on. Also, if someone wrote a stream module, and was not asked about
LGPL relicensing, we don't consider the entry in stream_list[]
copyrightable.
2017-06-19 14:07:42 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-01-30 22:26:47 +00:00
|
|
|
*
|
stream: change license to LGPL
All relevant authors have agreed.
There are two exceptions, patches by authors who could not be reached.
This commit tries to remove their copyright.
a0f08fbe: messes with the seeking code corner cases. The EOF flag logic
was changed at some point, and always had a flaky history (see e.g.
347cf972 50274ca3 70411f27 5999efb9 0d5e6084 ff08d0c3 2e2f77e3 de5566f0
9554a844, all which happened after that patch, MPlayer ones without that
patch). I claim that all of the copyright the patch might have added is
gone. Except the message in stream_seek(), which this commit removes.
The other code removed/changed in stream_seek() is probably not from
that patch, but it doesn't hurt to be sure, and also makes it more
readable. (It might change the behavior so that sometimes the eof flag
is set after a seek, but it doesn't matter here.)
2aa6acd9: it looks like the seek_forward() modified by this patch was
later moved to stream.c and renamed to stream_skip_read() in a790f2133.
(Looking closer at it, it was actually modified again a bunch of times,
fixing the logic.) I rewrote it in this commit. The code ended up rather
similar, which probably could lead to doubts whether this was done
properly, but I guess the reader of this will just have to believe me. I
knew what stream_skip_read() was supposed to do (which was reinforced
when I tried to replace it on the caller side), without reading the
pre-existing code in detail. I had to "relearn" the logic how buf_pos
and bug_len work - it was actually easy to see from stream_read_char()
how to skip the data, essentially by generalizing its logic from 1 byte
to N bytes. From the old code I only "used" the fact that it's obviously
a while(len>0) look, that has to call stream_fill_buffer repeatedly to
make progress. At first I actually didn't use stream_fill_buffer_by(),
but the variant without _by, but readded it when I checked why the old
code used it (see cd7ec016e7). This has to be good enough. In the end,
it's hard to argue that this could be implemented in a way not using
such a loop.
Other than this, I could add the usual remarks about how this code was
not modularized in the past, and how stream.c contained DVD code, and
how this was later modularized, moving the copyright to other files, and
so on. Also, if someone wrote a stream module, and was not asked about
LGPL relicensing, we don't consider the entry in stream_list[]
copyrightable.
2017-06-19 14:07:42 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2010-01-30 22:26:47 +00:00
|
|
|
*/
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#ifndef MPLAYER_STREAM_H
|
|
|
|
#define MPLAYER_STREAM_H
|
2001-04-22 16:56:20 +00:00
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2012-11-17 17:12:13 +00:00
|
|
|
#include <stdbool.h>
|
2010-11-02 01:17:41 +00:00
|
|
|
#include <stdio.h>
|
2002-09-15 22:38:01 +00:00
|
|
|
#include <string.h>
|
2002-01-07 09:22:01 +00:00
|
|
|
#include <inttypes.h>
|
2002-03-23 21:52:13 +00:00
|
|
|
#include <sys/types.h>
|
2010-03-06 07:24:41 +00:00
|
|
|
#include <fcntl.h>
|
|
|
|
|
2014-08-29 10:09:04 +00:00
|
|
|
#include "misc/bstr.h"
|
2011-02-25 16:10:00 +00:00
|
|
|
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
// Minimum guaranteed buffer and seek-back size. For any reads <= of this size,
|
|
|
|
// it's guaranteed that you can seek back by <= of this size again.
|
2002-09-15 22:38:01 +00:00
|
|
|
#define STREAM_BUFFER_SIZE 2048
|
|
|
|
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
// flags for stream_open_ext (this includes STREAM_READ and STREAM_WRITE)
|
|
|
|
|
2013-06-06 18:39:53 +00:00
|
|
|
// stream->mode
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
#define STREAM_READ 0
|
|
|
|
#define STREAM_WRITE (1 << 0)
|
2013-06-06 18:39:53 +00:00
|
|
|
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
#define STREAM_SILENT (1 << 1)
|
|
|
|
|
|
|
|
// Origin value for "security". This is an integer within the flags bit-field.
|
|
|
|
#define STREAM_ORIGIN_DIRECT (1 << 2) // passed from cmdline or loadfile
|
|
|
|
#define STREAM_ORIGIN_FS (2 << 2) // referenced from playlist on unix FS
|
|
|
|
#define STREAM_ORIGIN_NET (3 << 2) // referenced from playlist on network
|
|
|
|
#define STREAM_ORIGIN_UNSAFE (4 << 2) // from a grotesque source
|
|
|
|
|
|
|
|
#define STREAM_ORIGIN_MASK (7 << 2) // for extracting origin value from flags
|
|
|
|
|
|
|
|
// end flags for stream_open_ext (the naming convention sucks)
|
2013-08-25 20:50:16 +00:00
|
|
|
|
2014-08-31 17:49:39 +00:00
|
|
|
#define STREAM_UNSAFE -3
|
2013-08-25 20:50:16 +00:00
|
|
|
#define STREAM_NO_MATCH -2
|
2007-08-28 22:38:45 +00:00
|
|
|
#define STREAM_UNSUPPORTED -1
|
2003-04-02 16:25:07 +00:00
|
|
|
#define STREAM_ERROR 0
|
|
|
|
#define STREAM_OK 1
|
|
|
|
|
2013-10-02 19:19:16 +00:00
|
|
|
enum stream_ctrl {
|
2014-12-13 19:25:31 +00:00
|
|
|
// Certain network protocols
|
|
|
|
STREAM_CTRL_AVSEEK,
|
|
|
|
STREAM_CTRL_HAS_AVSEEK,
|
|
|
|
STREAM_CTRL_GET_METADATA,
|
|
|
|
|
2019-10-02 22:22:18 +00:00
|
|
|
// Optical discs (internal interface between streams and demux_disc)
|
|
|
|
STREAM_CTRL_GET_TIME_LENGTH,
|
|
|
|
STREAM_CTRL_GET_DVD_INFO,
|
|
|
|
STREAM_CTRL_GET_DISC_NAME,
|
|
|
|
STREAM_CTRL_GET_NUM_CHAPTERS,
|
|
|
|
STREAM_CTRL_GET_CURRENT_TIME,
|
|
|
|
STREAM_CTRL_GET_CHAPTER_TIME,
|
|
|
|
STREAM_CTRL_SEEK_TO_TIME,
|
|
|
|
STREAM_CTRL_GET_ASPECT_RATIO,
|
|
|
|
STREAM_CTRL_GET_NUM_ANGLES,
|
|
|
|
STREAM_CTRL_GET_ANGLE,
|
|
|
|
STREAM_CTRL_SET_ANGLE,
|
|
|
|
STREAM_CTRL_GET_NUM_TITLES,
|
|
|
|
STREAM_CTRL_GET_TITLE_LENGTH, // double* (in: title number, out: len)
|
|
|
|
STREAM_CTRL_GET_LANG,
|
|
|
|
STREAM_CTRL_GET_CURRENT_TITLE,
|
|
|
|
STREAM_CTRL_SET_CURRENT_TITLE,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct stream_lang_req {
|
|
|
|
int type; // STREAM_AUDIO, STREAM_SUB
|
|
|
|
int id;
|
|
|
|
char name[50];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct stream_dvd_info_req {
|
|
|
|
unsigned int palette[16];
|
|
|
|
int num_subs;
|
2013-10-02 19:19:16 +00:00
|
|
|
};
|
2003-04-02 16:25:07 +00:00
|
|
|
|
2014-07-30 00:21:35 +00:00
|
|
|
// for STREAM_CTRL_AVSEEK
|
|
|
|
struct stream_avseek {
|
|
|
|
int stream_index;
|
|
|
|
int64_t timestamp;
|
|
|
|
int flags;
|
|
|
|
};
|
|
|
|
|
2008-04-24 02:49:44 +00:00
|
|
|
struct stream;
|
2019-09-28 22:45:41 +00:00
|
|
|
struct stream_open_args;
|
2003-04-02 16:25:07 +00:00
|
|
|
typedef struct stream_info_st {
|
2013-01-24 16:43:07 +00:00
|
|
|
const char *name;
|
2013-06-06 18:39:53 +00:00
|
|
|
// opts is set from ->opts
|
2014-05-24 12:06:13 +00:00
|
|
|
int (*open)(struct stream *st);
|
2019-06-19 14:48:46 +00:00
|
|
|
// Alternative to open(). Only either open() or open2() can be set.
|
2019-09-28 22:45:41 +00:00
|
|
|
int (*open2)(struct stream *st, struct stream_open_args *args);
|
2014-06-10 21:56:05 +00:00
|
|
|
const char *const *protocols;
|
2014-08-31 22:12:47 +00:00
|
|
|
bool can_write; // correctly checks for READ/WRITE modes
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
int stream_origin; // 0 or set of STREAM_ORIGIN_*; if 0, the same origin
|
|
|
|
// is set, or the stream's open() function handles it
|
2003-04-02 16:25:07 +00:00
|
|
|
} stream_info_t;
|
|
|
|
|
2008-04-24 02:49:44 +00:00
|
|
|
typedef struct stream {
|
2013-08-02 15:02:34 +00:00
|
|
|
const struct stream_info_st *info;
|
|
|
|
|
2013-01-24 16:43:07 +00:00
|
|
|
// Read
|
2019-11-07 14:28:50 +00:00
|
|
|
int (*fill_buffer)(struct stream *s, void *buffer, int max_len);
|
2013-01-24 16:43:07 +00:00
|
|
|
// Write
|
2019-11-07 14:28:50 +00:00
|
|
|
int (*write_buffer)(struct stream *s, void *buffer, int len);
|
2013-01-24 16:43:07 +00:00
|
|
|
// Seek
|
|
|
|
int (*seek)(struct stream *s, int64_t pos);
|
2019-11-07 14:54:34 +00:00
|
|
|
// Total stream size in bytes (negative if unavailable)
|
|
|
|
int64_t (*get_size)(struct stream *s);
|
2013-01-24 16:43:07 +00:00
|
|
|
// Control
|
|
|
|
int (*control)(struct stream *s, int cmd, void *arg);
|
|
|
|
// Close
|
|
|
|
void (*close)(struct stream *s);
|
|
|
|
|
2014-05-24 12:04:09 +00:00
|
|
|
int64_t pos;
|
2019-11-14 11:59:14 +00:00
|
|
|
int eof; // valid only after read calls that returned a short result
|
2013-01-24 16:43:07 +00:00
|
|
|
int mode; //STREAM_READ or STREAM_WRITE
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
int stream_origin; // any STREAM_ORIGIN_*
|
2013-01-24 16:43:07 +00:00
|
|
|
void *priv; // used for DVD, TV, RTSP etc
|
2013-08-02 15:02:34 +00:00
|
|
|
char *url; // filename/url (possibly including protocol prefix)
|
|
|
|
char *path; // filename (url without protocol prefix)
|
2013-01-24 16:43:07 +00:00
|
|
|
char *mime_type; // when HTTP streaming is used
|
2013-07-11 19:10:42 +00:00
|
|
|
char *demuxer; // request demuxer to be used
|
2013-01-24 16:43:07 +00:00
|
|
|
char *lavf_type; // name of expected demuxer type for lavf
|
2015-02-06 20:32:44 +00:00
|
|
|
bool streaming : 1; // known to be a network stream if true
|
2014-05-24 12:04:09 +00:00
|
|
|
bool seekable : 1; // presence of general byte seeking support
|
|
|
|
bool fast_skip : 1; // consider stream fast enough to fw-seek by skipping
|
stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
2019-12-20 08:41:42 +00:00
|
|
|
bool is_network : 1; // I really don't know what this is for
|
2017-02-02 17:24:27 +00:00
|
|
|
bool is_local_file : 1; // from the filesystem
|
|
|
|
bool is_directory : 1; // directory on the filesystem
|
2016-12-04 22:15:31 +00:00
|
|
|
bool access_references : 1; // open other streams
|
2013-12-21 19:36:45 +00:00
|
|
|
struct mp_log *log;
|
|
|
|
struct mpv_global *global;
|
2013-05-11 20:19:33 +00:00
|
|
|
|
stream: redo playback abort handling
This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.
The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.
libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.
There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.
As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
2014-09-13 12:23:08 +00:00
|
|
|
struct mp_cancel *cancel; // cancellation notification
|
|
|
|
|
2018-09-01 11:04:45 +00:00
|
|
|
// Read statistic for fill_buffer calls. All bytes read by fill_buffer() are
|
|
|
|
// added to this. The user can reset this as needed.
|
|
|
|
uint64_t total_unbuffered_read_bytes;
|
2019-11-07 15:05:27 +00:00
|
|
|
// Seek statistics. The user can reset this as needed.
|
|
|
|
uint64_t total_stream_seeks;
|
2018-09-01 11:04:45 +00:00
|
|
|
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
// Buffer size requested by user; s->buffer may have a different size
|
|
|
|
int requested_buffer_size;
|
|
|
|
|
|
|
|
// This is a ring buffer. It is reset only on seeks (or when buffers are
|
|
|
|
// dropped). Otherwise old contents always stay valid.
|
|
|
|
// The valid buffer is from buf_start to buf_end; buf_end can be larger
|
2019-11-07 13:49:41 +00:00
|
|
|
// than the buffer size (requires wrap around). buf_cur is a value in the
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
// range [buf_start, buf_end].
|
|
|
|
// When reading more data from the stream, buf_start is advanced as old
|
|
|
|
// data is overwritten with new data.
|
|
|
|
// Example:
|
|
|
|
// 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
|
|
|
// +===========================+---------------------------+
|
|
|
|
// + 05 06 07 08 | 01 02 03 04 + 05 06 07 08 | 01 02 03 04 +
|
|
|
|
// +===========================+---------------------------+
|
|
|
|
// ^ buf_start (4) | |
|
|
|
|
// | ^ buf_end (12 % 8 => 4)
|
|
|
|
// ^ buf_cur (9 % 8 => 1)
|
2019-11-07 13:49:41 +00:00
|
|
|
// Here, the entire 8 byte buffer is filled, i.e. buf_end - buf_start = 8.
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
// buffer_mask == 7, so (x & buffer_mask) == (x % buffer_size)
|
|
|
|
unsigned int buf_start; // index of oldest byte in buffer (is <= buffer_mask)
|
|
|
|
unsigned int buf_cur; // current read pos (can be > buffer_mask)
|
|
|
|
unsigned int buf_end; // end position (can be > buffer_mask)
|
|
|
|
|
|
|
|
unsigned int buffer_mask; // buffer_size-1, where buffer_size == 2**n
|
2018-10-02 17:57:01 +00:00
|
|
|
uint8_t *buffer;
|
2001-04-22 16:56:20 +00:00
|
|
|
} stream_t;
|
|
|
|
|
2019-11-07 13:49:41 +00:00
|
|
|
// Non-inline version of stream_read_char().
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
int stream_read_char_fallback(stream_t *s);
|
2010-02-21 23:30:34 +00:00
|
|
|
|
2019-11-07 14:28:50 +00:00
|
|
|
int stream_write_buffer(stream_t *s, void *buf, int len);
|
2001-07-31 23:18:16 +00:00
|
|
|
|
2013-01-24 16:43:07 +00:00
|
|
|
inline static int stream_read_char(stream_t *s)
|
|
|
|
{
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
return s->buf_cur < s->buf_end
|
|
|
|
? s->buffer[(s->buf_cur++) & s->buffer_mask]
|
|
|
|
: stream_read_char_fallback(s);
|
2001-04-22 16:56:20 +00:00
|
|
|
}
|
|
|
|
|
2013-08-25 18:40:21 +00:00
|
|
|
int stream_skip_bom(struct stream *s);
|
2006-03-16 14:42:51 +00:00
|
|
|
|
2013-01-24 16:43:07 +00:00
|
|
|
inline static int64_t stream_tell(stream_t *s)
|
|
|
|
{
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
return s->pos + s->buf_cur - s->buf_end;
|
2001-04-22 16:56:20 +00:00
|
|
|
}
|
|
|
|
|
2019-11-14 11:59:14 +00:00
|
|
|
bool stream_seek_skip(stream_t *s, int64_t pos);
|
2015-02-06 20:15:21 +00:00
|
|
|
bool stream_seek(stream_t *s, int64_t pos);
|
2019-11-07 14:28:50 +00:00
|
|
|
int stream_read(stream_t *s, void *mem, int total);
|
|
|
|
int stream_read_partial(stream_t *s, void *buf, int buf_size);
|
|
|
|
int stream_read_peek(stream_t *s, void *buf, int buf_size);
|
2013-12-13 23:51:00 +00:00
|
|
|
void stream_drop_buffers(stream_t *s);
|
2015-08-17 22:10:54 +00:00
|
|
|
int64_t stream_get_size(stream_t *s);
|
2001-04-22 16:56:20 +00:00
|
|
|
|
2013-12-21 19:36:45 +00:00
|
|
|
struct mpv_global;
|
2013-06-11 10:16:42 +00:00
|
|
|
|
2011-02-25 16:10:00 +00:00
|
|
|
struct bstr stream_read_complete(struct stream *s, void *talloc_ctx,
|
2013-06-11 10:16:42 +00:00
|
|
|
int max_size);
|
2015-03-27 12:27:40 +00:00
|
|
|
struct bstr stream_read_file(const char *filename, void *talloc_ctx,
|
|
|
|
struct mpv_global *global, int max_size);
|
2006-03-01 21:56:30 +00:00
|
|
|
int stream_control(stream_t *s, int cmd, void *arg);
|
2001-04-22 16:56:20 +00:00
|
|
|
void free_stream(stream_t *s);
|
2019-09-28 22:45:41 +00:00
|
|
|
|
|
|
|
struct stream_open_args {
|
|
|
|
struct mpv_global *global;
|
|
|
|
struct mp_cancel *cancel; // aborting stream access (used directly)
|
|
|
|
const char *url;
|
|
|
|
int flags; // STREAM_READ etc.
|
|
|
|
const stream_info_t *sinfo; // NULL = autoprobe, otherwise force stream impl.
|
|
|
|
void *special_arg; // specific to impl., use only with sinfo
|
|
|
|
};
|
|
|
|
|
|
|
|
int stream_create_with_args(struct stream_open_args *args, struct stream **ret);
|
stream: redo playback abort handling
This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.
The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.
libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.
There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.
As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
2014-09-13 12:23:08 +00:00
|
|
|
struct stream *stream_create(const char *url, int flags,
|
|
|
|
struct mp_cancel *c, struct mpv_global *global);
|
2013-12-21 19:36:45 +00:00
|
|
|
stream_t *open_output_stream(const char *filename, struct mpv_global *global);
|
2011-02-10 10:15:21 +00:00
|
|
|
|
2013-08-02 15:03:30 +00:00
|
|
|
void mp_url_unescape_inplace(char *buf);
|
2013-08-25 20:58:29 +00:00
|
|
|
char *mp_url_escape(void *talloc_ctx, const char *s, const char *ok);
|
2013-08-02 15:03:30 +00:00
|
|
|
|
2019-06-19 14:48:46 +00:00
|
|
|
// stream_memory.c
|
|
|
|
struct stream *stream_memory_open(struct mpv_global *global, void *data, int len);
|
|
|
|
|
2019-06-19 17:24:01 +00:00
|
|
|
// stream_concat.c
|
|
|
|
struct stream *stream_concat_open(struct mpv_global *global, struct mp_cancel *c,
|
|
|
|
struct stream **streams, int num_streams);
|
|
|
|
|
2014-01-08 20:46:42 +00:00
|
|
|
// stream_file.c
|
|
|
|
char *mp_file_url_to_filename(void *talloc_ctx, bstr url);
|
2014-09-25 21:38:23 +00:00
|
|
|
char *mp_file_get_path(void *talloc_ctx, bstr url);
|
2014-01-08 20:46:42 +00:00
|
|
|
|
2014-10-14 19:01:30 +00:00
|
|
|
// stream_lavf.c
|
|
|
|
struct AVDictionary;
|
|
|
|
void mp_setup_av_network_options(struct AVDictionary **dict,
|
2019-11-14 12:46:03 +00:00
|
|
|
const char *target_fmt,
|
2014-10-14 19:01:30 +00:00
|
|
|
struct mpv_global *global,
|
2016-09-06 18:09:56 +00:00
|
|
|
struct mp_log *log);
|
2014-10-14 19:01:30 +00:00
|
|
|
|
2014-06-30 10:49:01 +00:00
|
|
|
void stream_print_proto_list(struct mp_log *log);
|
2015-05-23 13:26:55 +00:00
|
|
|
char **stream_get_proto_list(void);
|
2016-08-07 16:10:05 +00:00
|
|
|
bool stream_has_proto(const char *proto);
|
2014-06-30 10:49:01 +00:00
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_STREAM_H */
|