Handle the severely broken headers QuickTime Streaming Server sends.
Instead of ending the header with \r\n\r\n it ends with
\r\n<4 byte MP3 header>\r\n.
And programs like wget just silently accept this without even
printing a warning!!
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35988 b3059339-0415-0410-9bf9-f77b7e298cf2
Note: see previous commit.
Support broken icy-metaint response from QuickTime Streaming Server.
The full version string is "QuickTime Streaming Server 6.1.0/532".
It sends a HTTP response header that contains an MP3 header!
Fixes bug #2133.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35987 b3059339-0415-0410-9bf9-f77b7e298cf2
Note that in mpv, "http://" is mapped to ffmpeg currently, and this
code is unused by default.
Clean up ifdefs so they make sense even if none or multiple are defined.
Also choose Linux as fallback case instead of failing, this
allows the code to compile e.g. on Android.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35971 b3059339-0415-0410-9bf9-f77b7e298cf2
Commit 546ae23 fixed aspect ratio if the DisplayWidth or DisplayHeight
elements were missing. However, some bogus files [1] can have these
elements present in the file, but set to 0. Use 1:1 pixel aspect for
such files.
[1] https://ffmpeg.org/trac/ffmpeg/ticket/2424
The main problem with video PTS was that it wasn't very useful when
playing audio files with cover art. Using the audio time instead was an
obvious solution. Unfortunately, this leads to "inexact" reporting of
the playback time in paused mode, and audio is always ahead by small,
essentially random amounts of time ahead. This is possibly because the
times reported by AOs are not entirely accurate when paused (see commit
9b3bf76).
Switch back to video PTS, and use a simpler way to deal with the cover
art case: if the video has ended, use the audio PTS.
Also see commit f9a259e (and the commits referenced from there).
Trying to step over a segment boundary didn't work, and the video was
stuck at the end of the current chapter. At this point, both video and
audio of the segment has ended, and the segment switching code is going
to call seek() to go to the next segment (the part of the code in
run_playloop that uses end_is_chapter). However, this seek() is not
called if playback is paused, and the framestepping code always paused
before this code is run.
Move the framestepping code below the chapter switching code. The added
restart_playback condition makes sure the code is called only after at
least one video frame has been shown. Also don't reset the framestep
counter after seek. It's not needed, and removing it prevents full
unpausing when stepping over a segment boundary.
This also terminates playback when frame stepping at the end of the
file. The --keep-open option can be used to get the old behavior.
It is now possible to show images and videos with alpha information correctly.
This was disalbed before, because there was a bug that made black parts of
videos also transparent.
The OSX part of the Apple Remote was unmaintained for a long time and was not
working anymore. I tried to update the cookies to what the current versions of
OS X expect without much luck. I decided to remove it since Apple is not
including the IR receiver anymore in new hardware and it's clear that wifi
based remotes are the way to go.
A third party iOS app should be used in it's place. In the future we could look
into having a dedicated iOS Remote Control app like VLC and XBMC do.
The Linux side (`appleir.c`) was relatively tidy but it looks like LIRC can be
configured to work with any version of Apple Remote [1] and is more maintained.
[1] LIRC Apple Remote configs: http://lirc.sourceforge.net/remotes/apple/
Commit ac1c5e6 (demux_mkv: improve robustness against broken files)
added code to skip to the next cluster on error conditions. However,
reaching normal EOF triggers this code as well, so explicitly check
for EOF before this happens. Note that the EOF flag is only set _after_
reading the last byte, so EOF needs to be checked after the fact. (Or
in other words, we must check for EOF after the ebml_read_id() call.)
(To answer the question why reading packets actually reaches EOF, even
if there's the seek index between the last packet and the end of the
file: the cluster reading code skips the seeking related EBML elements
as normal part of operation, so it hits EOF gracefully when trying to
find the next cluster.)
Drawing the bar with vector drawings (instead with characters from the
OSD font) offers more flexibility and looks better. This also adds
chapter marks to the OSD bar, which are visible as small triangles on
the top and bottom inner border of the bar.
Change the default position of the OSD bar below the center of the
screen. This is less annoying than putting the bar directly into the
center of the view, where it obscures the video. The new position is
not quite on the bottom of the screen to avoid collisions with
subtitles.
The old centered position can be forced with ``--osd-bar-align-y=0``.
Also make it possible to change the OSD bar width/height with the new
--osd-bar-w and --osd-bar-h options.
It's possible that the new OSD bar renders much slower than the old
one. There are two reasons for this: 1. the character based bar
allowed libass to cache each character, while the vector drawing forces
it to redraw every time the bar position changes. 2., the bar position
is updated at a much higher granularity (the bar position is passed
along as float instead of as integer in the range 0-100, so the bar
will be updated on every single video frame).
The previous attempt was missing some code paths, so there were still
shaders generated that triggered the shader compilation error. Fix it
instead by special handling USE_CONV in the shader.
By the way, the shader compiler did not accept:
#if defined(USE_CONV) && (USE_CONV == ...)
In my opinion this should be perfectly fine, but it gives the same
error as before. So test USE_CONV separately with #ifndef.
The OSX shader compiler was giving this error:
ERROR: 0:235: '' : syntax error incorrect preprocessor directive
on this line:
[235] #if USE_CONV == CONV_PLANAR
USE_CONV was undefined in some cases. The expected behavior is that the
shader preprocessor interprets this as branch not taken (AFAIK exactly
as in C), which is probably what the standard would dictate. This is
possible an OSX bug. But admittedly, I'm not sure whether this is really
standard behavior (in C or GLSL), and doing this is extremely weird at
best, so make sure that USE_CONV is always defined.
Should fix behavior on OSX.
Allows playing video with alpha information on X11, as long as the video
contains alpha and the window manager does compositing. See vo.rst.
Whether a window can be transparent is decided by the choice of the X
Visual used for window creation. Unfortunately, there's no direct way to
request such a Visual through the GLX or the X API, and use of the
XRender extension is required to find out whether a Visual implies a
framebuffer with alpha used by XRender (see for example [1]). Instead of
depending on the XRender wrapper library (which would require annoying
configure checks, even though XRender is virtually always supported),
use a simple heuristics to find out whether a Visual has alpha. Since
getting it wrong just means an optional feature will not work as
expected, we consider this ok.
[1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl-rendering-context-with-transparent-background/9215724#9215724
When displaying YUV with alpha plane (an extremely rare special case),
we didn't upload the alpha plane, because we don't do anything with it.
This actually created some annoying special cases, so upload the alpha
planes as well, even if they're unused.
This is a bit cleaner. Also don't repeat the chroma shift calculations
over and over, but store the image size instead, which is simpler and
will give us a chance to fix display of non-mod-2 image sizes.
gl_video.c contains all rendering code, gl_lcms.c the .icc loader and
creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is
reduced to interfacing between the various parts.
Do this instead of stuffing all x11/cocoa/win32/wayland specific code
into gl_common.c. The cocoa specific parts could probably go directly
into cocoa_common.m, possibly same with wayland.
Also redo how the list of backends is managed. Get rid of the GLTYPE_
constants. Instead of having a big switch() on GLTYPE_, each backend
entry has a function pointer to setup the MPGLContext callback (e.g.
mpgl_set_backend_x11()).
Makes the code a bit simpler to follow, at least in the "modern"
decoding path (update_video_nocorrect_pts() is used with old demuxers,
which don't return proper packets and need further parsing, so this code
looks less simple now).
Fixes test7.mkv from the Matroska test file collection, as well as some
real broken files I've found in the wild. (Unfortunately, true recovery
requires resetting the decoders and playback state with a manual seek,
but it's still better than just exiting.)
If there are broken EBML elements, try harder to skip them correctly.
Do this by searching for the next cluster element. The cluster element
intentionally has a long ID, so it's a suitable element for
resynchronizing (mkvmerge does something similar).
We know that data is corrupt if the ID or length fields of an element
are malformed. Additionally, if skipping an unknown element goes past
the end of the file, we assume it's corrupt and undo the seek. Do this
because it often happens that corrupt data is interpreted as correct
EBML elements. Since these elements will have a ridiculous values in
their length fields due to the large value range that is possible
(0-2^56-2), they will go past the end of the file. So instead of
skipping them (which would result in playback termination), try to
find the next cluster instead. (We still skip unknown elements that
are within the file, as this is needed for correct operation. Also, we
first execute the seek, because we don't really know where the file
ends. Doing it this way is better for unseekable streams too, because
it will still work in the non-error case.)
This is done as special case in the packet reading function only. On
the other hand, that's the only part of the file that's read after
initialization is done.
Fixes test4.mkv from the Matroska test file collection.
demux_mkv_open() contains a loop that reads header elements. It starts
by reading the EBML element ID with ebml_read_id(). If there is broken
data in the header, ebml_read_id() might return EBML_ID_INVALID.
However, that is not handled specially, and the code for handling
unknown tags is invoked. This reads the EBML element length in order to
skip data, which, if the EBML ID is broken, is entirely random. This
caused a seek beyond the end of the file, making the demuxer fail.
So don't skip any data if the EBML ID was invalid, and simply try to
read the next element. ebml_read_id() reads at least one byte, so the
parsing loop won't get stuck.
All in all this is rather questionable, but since this affects error
situations only, makes behavior a bit more robust (no random seeks), and
actually fixes at least one sample, it's ok.
libavformat's demuxer handled this.
There were complaints that ${fps} was printed as e.g. "23.98" instead of
"23.976". Since there's no way to format floats exactly _and_ in a user-
friendly way, just change the default precision for printing floats.
Prevents the status line from being printed. Otherwise, the status line
is always printed due to --frames=1, and it's visible on the terminal
because it's printed to stderr.
This way it's possible to retrieve correct information about video, like
actual width/height, which in general are available only after at least
one frame has been sent to the video output, such as dwidth/dheight.
mpv_identify.sh becomes a bit slower, because we let it decode enough
audio and video to fill the audio buffers and to send one frame to the
video output. Also, --playing-msg isn't shown anymore with --frames=0
(could be fixed by special-casing it, should this break any use cases).
Note that in some corner cases, like when the demuxer for some reason
returns lots of audio packets but no video packets at the start, but
video actually starts later, the --playing-msg will still be output
before video starts.
This has the same (useless) definition as frame stepping in audio-only
mode: one frame means one playloop iteration. (It's relatively useless,
because one playloop iteration has a random duration. But it makes
--frames=1 work, which is useful again.)
Add new properties "dwidth" and "dheight", which contain the video
size as known by the VO (not necessarily what the VO makes out of them,
i.e. without window scaling and panscan).
