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).
Some time ago, all old special-cased commands (like "volume 1" to change
volume by one) have been removed. These commands are still emulated
using simple text replacement. This emulation is done to not break
everyone's input.conf, especially because the input.conf provided by
standard mplayer* still uses the old commands.
Every use of a deprecated command prints a replacement warning, which
was visible only with -v. Make these warnings visible by default.
There's actually not much reason to do this, but since commands like
"volume 5 1" don't work anymore, it's better to be verbose about this.
Also simplify the replacement for "vo_fullscreen".
Normal text was set to gray foreground color. This didn't work for
terminals with white background.
Instead of setting a color for normal text, reset the color attributes.
This way, only errors and warnings are formatted differently.
Also change the default color for MSGL_HINT from bold white to yellow.
Good news: MPV worked fine even without the fixes, but pointer size
mismatch warnings aren't the nicest things to leave lying around.
Fix macro that assumed HWND is uint32_t-sized.
Win64 is also a special butterfly and is an LLP64 platform on amd64
CPUs, while all the other amd64 platforms are LP64. Cygwin decided to go
with the other platforms, and thus sizeof(long) != sizeof(int), and in
cygwin's windows headers LONG is int-sized. Fix an mp_msg that assumed
LONG is long.
In some cases (when using tune=animation as an additional option), the
N900 profile caused use of 6 reference frames, where Level 3.0 only
allows 5 reference frames. This prevented playback on the Nokia N900.
This has been fixed by always specifying refs=5.
The code modified by this commit is supposed to prevent demuxing the
whole file when cover art is present. (The problem with cover art is
that the ffmpeg libavformat API doesn't signal video EOF correctly - so
we try to read more packets to find the next video frame, which results
in demuxing and queuing the whole audio stream.)
This caused regressions for files with extremely high audio offset (see
github issue #46). MY conclusion is that this cover art crap doesn't
work, and this is just another case of completely insane ffmpeg/libav
API.
Disable the hack in all cases, unless a cover art video track is
selected. Maybe I'll handle cover art directly in the frontend later, so
that we don't have to rely on whatever libavformat does.
Unfortunately, this also makes behavior with equally insane mp4 files
with sparse video tracks worse, but this issue takes priority.
Doing 'mpv mf://*' in a file with directories would crash, because even
though directories are skipped, the corresponding file entry is just
left at NULL, leading to a segfault on access. So explicitly skip NULL
entries.
clang printed warnings like:
stream/stream.c:692:65: warning: if statement has empty body [-Wempty-body]
GET_UTF16(c, src < end - 1 ? get_le16_inc(&src) : 0,;
This macro expands to "if(cond) ;". Replace it with an empty statement
that doesn't lead to a clang warning.
This yields generally smaller files, by avoiding upscaling at all times.
This method may or may not be useful for iOS, needs testing there.
Note: this uses three instances of vf_scale:
1. Scale to target dimensions, ONLY if both are <= original video
dimensions.
2. Failing that, scale to width*<calculated height by display aspect>,
ONLY if <calculated height by display aspect> <= original video
height.
3. Failing that, scale to <calculated width by display aspect>*height.
When the test before failed, we KNOW that <calculated width by
display aspect> <= original video width.
So basically, only one of the three scalers should ever be active, as
the last two scalers only can ever have an effect if the aspect ratio
mismatches the video.
As for danger of roundoff errors:
If scaler 1 succeeded, we have won. Scalers 2 and 3 will never do
anything, because display resolution == video resolution. Here it is
crucial that no rounding of video size to display size takes place; in
other words, the target display size already MUST be even, which it is
because we pass 2 to the rounding parameter of the dsize filter.
Scaler 2 and 3 are obviously mutually exclusive, as they depend on
opposite aspect ratio conditions.
We later should put this functionality directly into vf_scale...
A recent change accidentally set the flags options to -1 (probably
confusing it with the defasult value?), which mistakenly set all flags
and rejected all option values (except 0).
The vo_x11_clearwindow_part() function assumed that the video is always
centered. Replace it with a new vo_x11_clear_background() function
instead, which essentially does the same as the old function. It takes
the video rectangle instead of just the video size, and doesn't have to
make the assumption that the video rectangle is centered.
Also make vo_x11 use it (seems advantageous).
This was probably enabled to guarantee that panscan is always reset in
windowed mode. However, the window size should be exactly the video size
in windowed mode, unless in cases where the user forcibly changed the
window size (e.g. --geometry). In the former case, panscan will have no
influence at all, and in the latter case we want it to have influence.
If that's what the user asked for, there's no reason to introduce
special cases to ignore it on fullscreen.
The old behavior is perhaps accidentally due to the fact that aspect
calculations used to be disabled in windowed mode, rather than a
deliberate decision.
The code that is changed is responsible for scaling the video size to
display size, so that the resulting video rectangle is letter-boxed
inside the display window. This is before panscan calculations, which
can actually enlarge the video and make it larger than the display size
again. (src_dst_split_scaling() in vo.c takes cares of clipping the
video size to window size.)
I'm not sure why this rounding is done, as using panscan controls can
introduce odd sizes again. The rounding has been part of the code since
the initial commit. On the other hand, this rounding can slightly
influence the aspect ratio of the displayed image to the worse. It
forces the image to be scaled by an additional pixel, without actually
correcting the display size into the other direction.
Although video sizes are usually at least aligned on 2 (and often more),
odd sizes can still happen when playing e.g. anamorphic DVDs.
Remove the additional rounding.
(Note that we still round the _source_ image position and size when the
displayed image is larger than the screen, e.g. when panscan is used.
This is needed by some VOs so that the image source rectangle starts on
full chroma pixels. Maybe this rounding should be moved to the
respective VOs, which includes at least vo_direct3d.)
Remove lots of weird logic and dead code.
The only difference is that when specifying a monitor aspect ratio, it
will always upscale and never downscale.
The draw_osd change is a bit tricky: I guess originally, there was some
intention not to second-guess the generic aspect code, but the result is
the same and the code is more confusing.
The rescaling is rather silly. vo_get_src_dst_rects() doesn't return an
uncropped image, so the texture coordinates have to be recalculated,
which looks more complicated, but is actually what the other OpenGL VOs
also do.
Tested and fixed by Stefano Pigozzi.
Instead of manually calculating aspect ratio etc., use
vo_get_src_dst_rects(). This has the advantage that we can drop some
special cases in aspect.c later.
Simplify the code, and move resizing the X images from draw_image() to a
new resize() function.
Do some other simplifications. The gXErrorFlag check was actually dead
code, even in mplayer-svn. Special-casing on WinID is not needed
anymore (we created an embedded window, and its size is updated by
x11_common.c).
I introuced this regression in 8fc0b618d5. The backend would go into
incosistent state caused by calling `vo_cocoa_fullscreen` where it wasn't
needed.
Fixes#44
This only matters for those who want to use vf_pp. The old API is marked
as deprecated, and doesn't work on Libav. It was broken on FFmpeg, but
has recently started working again - the fields in question were not un-
deprecated though. Instead you're supposed to use a new API, which does
exactly the same thing (what...?).
Also don't pass the QP table with mp_image_copy_attributes() - it
probably does more harm than it's useful.
By the way, with -vf=dlopen=TOOLS/vf_dlopen/showqscale.so, it appears
the table as output by recent FFmpeg is offset by 1 macroblock in X
direction and 2 macroblocks in Y direction, which most likely will
interfere with normal vf_pp operation. However, this is not my problem.
The only real reason for this commit is that we can finally get rid of
all libav* related deprecation warnings. (Though they are constantly
deprecating APIs, so this will not last long.)
FFmpeg recently changed how it writes Opus-in-Matroska to match
the A_OPUS/EXPERIMENTAL name that mkvmerge uses, with the caveat
that things will change and compatibility with old files can get
worked out when the spec is finalized.
This adds both A_OPUS and A_OPUS/EXPERIMENTAL so that *hopefully*
it can play both the newer files that use A_OPUS/EXPERIMENTAL, and
older ones muxed by FFmpeg that were simply A_OPUS, since this is
also what FFmpeg seems to be doing to handle the situation.
We consider FFmpeg 1.x and Libav 0.9.x releases compatible. Support
for FFmpeg 0.9.x and Libav 0.8.x is considered infeasible and has been
dropped in the previous commits. The bits that break compatibility are
mainly the CodecID renaming (trivial, but would require nasty hacks
everywhere), the avcodec_encode_video2() function (missing in older
releases, mandatory in newer ones), and the resampler changes (older
releases miss lib{av,sw}resample, newer versions removed the
libavcodec resampler).
Remove some other compatibility bits that were needed to for releases
for which we drop support.
The comment about Libav 0.9 in compat/libav.h is incorrect and should
have been 0.8 (the symbol is present in Libav 0.9).
wm4
Stefano Pigozzi
Kovensky
Alexander Preisinger
Rudolf Polzer
Stephen Hutchinson