As of this commit, stream_read_line() can't actually error (except in
the case the passed in buffer is 0, which never happens here). This
commit is preparation for the following commit, which checks harder
whether the read data is actually text. Before this commit, an error
was treated as end-of-file, but the data read so far was considered
valid.
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
Somehow the new parser ends up much smaller. Much of it is because we
don't parse some additional information. We just skip it, instead of
parsing it and then throwing it away.
More importantly, we use the physical order of entries, instead of
trying to sort them by entry number. Each "File" entry is followed by a
number that is supposed to be the entry number, and "File1" is first.
(Should it turn out that this is really needed, an additional field
should be added to playlist_entry, and then qsort().)
The quicktime html scripting guide suggests to wrap urls not
necesarly associated with quicktime in a .mov file.
(so that when <embed>ing videos quicktime would be forced.)
These mov files may contain several "Text Hacks".
One of these is RTSPtext.
The suggested/allowed format (as regex) is like:
RTSPtext[ \r]RTSP://url
See also p.51 of:
https://developer.apple.com/library/mac/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML.pdf
In reality there are also files like (e.g. zdfmediathek.de):
RTSPtext\nrtsp://url\n\n
Lets handle these files as a playlist with one element.
Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u
parser to drop whitespace from the trailing part of the line (will make
it work properly with windows line endings).
(I hoped that this would make MMS URIs with http instead of mmsh
prefixes work, but it doesn't. Instead, it leads to a playlist loop. So
solving this issue would require a change in ffmpeg, probably.)
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
wm4