| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
In attempt to simplify the audio event thread, this can now be moved out.
|
|
|
|
|
| |
If these error conditions are triggered, the called function will have already
output a sufficiently informantive error message.
|
|
|
|
|
| |
In get_device_desc, don't alloc the return value until we know there
wasn't an error.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, PulseAudio accepts any combination of sample format, sample
rate, channel count/map. Sometimes it does not. For example, the channel
rate or channel count have fixed maximum values. We should not fail
fatally in such cases, but attempt to fall back to a working format.
We could just send pass an "unset" format to Pulse, but this is not too
attractive. Pulse could use a format which we do not support, and also
doing so much for an obscure corner case is not reasonable. So just pick
a format that is very likely supported.
This still could fail at runtime (the stream could fail instead of going
to the ready state), but this sounds also too complicated. In
particular, it doesn't look like pulse will tell us the cause of the
stream failure. (Or maybe it does - but I didn't find anything.)
Last but not least, our fallback could be less dumb, and e.g. try to fix
only one of samplerate or channel count first to reduce the loss, but
this is also not particularly worthy the effort.
Fixes #2654.
|
|
|
|
|
|
|
| |
pa_format_info_valid() does not do this. (Although there is a proposed
patch on the PulseAudio mailing list.)
See #2654.
|
|
|
|
| |
No real functional changes.
|
|
|
|
| |
Helps with testing.
|
|
|
|
|
| |
Since the MMAL video renderer component supports exactly what we need,
it's pretty simple.
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, the firmware will ignore pixel_x/pixel_y if the numeric
value of them gets too high (even if they indicate square pixel aspect
ratio). Even worse, the destination rectangle is ignored completely,
and the video frame is simply stretched to the screen. I suspect this
is an overflow or weird sanity check within the firmware.
Work it around by limiting the fields to 16000, which is an arbitrary
but apparently working limit.
|
|
|
|
| |
Fixes #2677
|
| |
|
|
|
|
|
|
|
|
| |
There are a lot of incorrectly encoded subtitles with .ass extension
and non-ass subtitles (srt, ssa) with such extension, so we need to
try codepage detection even for .ass.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given 5.1(side), this lets it pick 5.1 from [5.1, 7.1]. Which was
probably the original intention of this replacement stuff. Until now,
the opposite was done in some cases.
Keep the old heuristic if the replacement is not perfect. This would
mean that a subset of the channel layout is an inexact equivalent, but
not all of it.
(My conclusion is that audio output APIs should be designed to simply
take any channel layout, like the PulseAudio API does.)
|
|
|
|
|
| |
Rather than creating a new string from the device instance. This will allow
moving the change_init to the main thread before the device is loaded.
|
| |
|
|
|
|
| |
This is no longer required by anything else
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unify and clean up listing and selection. Use common enumerator code for both
operations to avoid duplication or inconsistencies.
Maintain, but significatnly simplify manual device selection by id, name or
number. This actually fixes loading by name which didn't really work before
since the "name" displayed by --audio-device=help differed from that used to
match the selection, which used the device "description" instead.
Save the selected deviceID in the private structure for later loading. This will
permit moving the device selection into the main thread in a future commit.
|
|
|
|
|
|
|
|
|
| |
GLSL in GLES 2.0 did not have line continuation in its preprocessor.
This broke shader compilation. It also broke subtitle rendering in
vo_rpi, which reuses some of the OpenGL code.
Line continuation was finally added in GLES 3.0, which is perhaps the
reason why ANGLE accepted it.
|
|
|
|
| |
This affects only the codepath which forcibly disables any ASS tags.
|
|
|
|
| |
Fixes #2661
|
| |
|
|
|
|
|
|
|
|
| |
When using --start with timeline/ordered chapters, then the
timeline_switch_to_time() function will look at playback_initialized
whether to rselect the currently selected streams on the demuxer level.
So we need to set this field to true at an earlier stage during
initialization, and in particular before the code for --start is called.
|
|
|
|
| |
Seriously, why do users do this?
|
|
|
|
|
|
|
|
| |
Apparently it's only wine where the qpc_position returned by
IAudioClock_GetPosition can be overflowed. So actually do the rescaling
correctly, but throw away the result if it looks unreasonable.
this fixes a regression in 5afa68835ade9f21f9c709f791319bf9d2e35265
|
|
|
|
| |
It's indeed completely useless. Pointed out in #2647.
|
|
|
|
| |
Merry christmas, or whatever the fuck is going on right now.
|
| |
|
|
|
|
|
|
| |
This didn't make too much sense, and just made seeking slower. Strictly
suggest the decoder to drop a frame if its PTS is before the seek
target.
|
|
|
|
|
|
|
| |
EBML_ID_VOID might occur at any level, see:
https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown
This change prevents "Corrupt file detected" errors on completely valid
files.
|
| |
|
|
|
|
|
|
| |
In particular, the player inserts af_scaletempo by default now when
changing speed, so the suggestion to add this was missleading and
counter-productive.
|
|
|
|
| |
Both variants work, but the ones with "-" are preferred now.
|
|
|
|
|
|
|
|
| |
Slightly change how it is decided when a new packet should be read.
Switch to demux_read_packet_async(), and let the player "wait properly"
until required subtitle packets arrive, instead of blocking everything.
Move distinguishing the cases of passive and active reading into the
demuxer, where it belongs.
|
|
|
|
|
| |
Just a simplification. This packet list lost its function a dozen of
commits ago or so.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just so I can remove a few lines from dec_sub.c.
This is slightly inelegant, as the whole subtitle file has to be read
into memory, converted at once in memory, and then provided to
libavformat in an awkward way by creating a memory stream instead of
using demuxer->stream. It also won't be possible to force the charset on
subtitles in binary container formats - but this wasn't exposed before,
and we just hope this won't be ever needed. (One motivation was fixing
broken files with non-UTF8 muxed.) It also won't be possible to change
the charset on the fly, but this was not exposed either.
|
|
|
|
| |
Preparation for the next commit.
|
| |
|
|
|
|
|
|
|
|
| |
Just simplify by removing parts not needed anymore. This includes
merging dec_sub allocation and initialization (since things making
initialization complicated were removed), or format support queries (it
simply tries to create a decoder, and if that fails, tries the next
one).
|
|
|
|
|
|
|
|
|
| |
So that the video FPs is not required at initialization, and can be set
later.
(As for whether this MicroDVD crap is worth the trouble to handle it
"correctly": MicroDVD files are unfortunately still around, and in at
least one case using the video FPS seemed to help indeed.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always preroll by default if the cue (index) information indicates
overlapping subtitles.
Increase the amount of maximum data it will skip to get such subtitles
to 10 seconds. Since the index information can reliably tell whether
reading earlier is needed, the maximum should be rarely actually used,
thus we can set it high. On the other hand, the "old" prerolling
mechanism always has to skip the maximum amount of data; thus the method
using the index gets its own option to control the maximum amount of
data to skip.
(As more and more files With newer mkvtoolnix versions are muxed, and
with this new and hopefully sane default established, these options can
probably be removed in the future.)
|
| |
|
|
|
|
| |
Meh. Fixes #2639.
|
|
|
|
|
|
|
|
|
| |
Untested, but should be fine. Broken by commit 0a0bb905.
Also fix the include statement in context_rpi.c, which caused another
compilation failure. Also untested. (Because I'm lazy.)
Fixes #2638.
|
|
|
|
| |
See #2637.
|
|
|
|
|
|
| |
Commit f24ba544 wasn't an equivalent change.
(This shit needs some sort of automated tests.)
|
|
|
|
|
| |
lrint() pretty much does what ROUND() is supposed to do, but it's more
precise.
|
|
|
|
|
|
|
| |
Keeping ASS_Renderers around for a potentially large number of subtitle
tracks could lead to excessive memory usage, especially since the libass
cache is broken (caches even unneeded data), and might consume up to
~500MB of memory for no reason.
|
|
|
|
|
|
|
| |
This includes the case of switching ordered chapter boundaries. It will
now be recreated on each timeline part switch. This shouldn't be much of
a problem with modern libass. (Older libass versions use fontconfig for
memory fonts, and will be very slow to reinitialize memory fonts.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 6d9cb893, subtitle state doesn't survive timeline switches
(ordered chapters etc.). So there is no point in caching the state per
sh_stream anymore (which would be required to deal with multiple
segments). Move the cache to struct track.
(Whether it's worth caching the subtitle state just for the situation
when subtitle tracks get reselected is questionable. But for now, it's
nice to have the subtitles immediately show up when reselecting a
subtitle.)
|
|
|
|
| |
Should fix #2635 (untested).
|
|
|
|
|
|
|
|
|
| |
For files with only 1 chapter, the "cycle" command was ignored. Reenable
it, but don't let it terminate playback of the file.
For the full story, see #2550.
Fixes #2550.
|
|
|
|
|
|
|
| |
OK, this made the --sub-paths and --audio-file-paths synonyms, which is
not what we wanted. Actually restrict the type of file loaded as well.
Really fixes #2632.
|
|
|
|
|
|
|
|
| |
Requested. It works like --sub-paths. This will also load audio files
from a "audio" sub directory in the config file (because the same code
as for subtitles is used, and it also had such a feature).
Fixes #2632.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When crossing timeline boundaries (such as switching to a new segment or
chapter with ordered chapters), clear the internal text subtitle list.
This breaks the sub-seek command, but is otherwise not too harmful.
Fixes Sub-OC-test-final7.mkv. (The internal text subtitle list is
basically a cache to make subtitles show up at the right time when
seeking back.)
I suspect this was caused by 76fcef61. The sample file times subtitles
slightly before the video frame when it should show up. This is to avoid
problems with subtitles showing up a frame later than intended. It also
means that a subtitle which is supposed to show up on the start of a
timeline part boundary actually might first be shown in a different
part. Since we now manipulate the packet timestamps, instead of
manipulating timestamps after the subtitle decoder, this means this
subtitle event would have 2 timestamps, which our code of course does
not handle.
If the two parts come one after another, this would actually work (since
the subtitle would have the same timestamps in the old and new part),
but it breaks if the new part (which follows the old part in the
physical file) is has a completely different start time in the timeline.
Essentially, the trick used to time subtitles correctly is incompatible
with the way we cache subtitles (to make them survive seeks).
The simple solution is just clearing the cached subtitles when crossing
chapter boundaries.
|
|
|
|
|
|
|
|
|
| |
See #2609:
"When eof is reached it would be shown on the OSD and in the console.
Next try seeking to the middle. Seeking to the middle of the file will
only result in the OSD message being updated. Lua seems to fail to
observe the change in the property until the video is unpaused."
|
|
|
|
| |
Meh.
|
|
|
|
|
|
|
|
|
|
| |
Merge blend_src8_alpha and blend_src16_alpha into blend_src_alpha, and
the same for blend_const_alpha.
One thing that changes is that the vertical loop is now shared for both
code paths.
I think this is slightly easier to read, and it's a bit shorter as well.
|
|
|
|
|
|
| |
The "accurate" one always has been enabled, and I can't find much
evidence that the "inaccurate" one is much faster on my particular
machine anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the need to define IMGFMT_GBRAP, which fixes compilation
with the current Libav release.
This also makes it automatically pick up a GBRP format with the same bit
width. (Unfortunately, it seems libswscale does not support conversion
to AV_PIX_FMT_GBRAP16, so our code falls back to 8 bit, removing
precision for video covered by subtitles in cases this code is used.)
Also, when the source video is e.g. 10 bit YUV, upsample to 16 bit.
Whether this is good or bad, it fixes behavior with alpha. Although I'm
not sure if the alpha range is really correct ([0,2^16-1] vs.
[0,255*256]). Keep in mind that libswscale doesn't even agree with the
way we do it.
|
|
|
|
|
| |
GLSL below version 1.30 does not support mix() with a boolean
interpolation value. Use ?: instead. Untested, but probably works.
|
|
|
|
|
|
|
|
|
|
|
| |
This actually treats destination alpha correctly, and gives much better
results than before. I don't know if this is perfectly correct yet,
though. Slight difference with vo_opengl behavior suggests it might not
be.
Note that this does not affect VOs with true alpha support. vo_opengl
does not use this code at all, and does the alpha calculations in OpenGL
instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 1a6f3c56 added a fallback for the case when C11 TLS was not
available, but GCC TLS was. But it forget to enable VAAPI EGL interop in
the build system in this case.
Just remove the build system check. Should someone find a compiler that
works on Linux and does not support GCC extensions or C11, it will still
compile and just fail to init at runtime.
Actually fixes #2631 (hopefully).
|
|
|
|
| |
It was total crap.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, |