| Age | Commit message (Collapse) | Author |
|---|
|
(Cset 1a0447486a13 broke things differently.)
|
|
|
|
|
|
This has a side effect: versions older than 1.1.10 do not unescape, so
"#save:foo%23.ts" will result in a file named "foo%23.ts".
Front end maintainers, beware :-)
|
|
This was broken in 1.1.8 when #subtitle:/file was fixed.
|
|
|
|
(transplanted from 4988e864d1a9db84756668ea33a9f6860ded879e)
--HG--
extra : transplant_source : I%88%E8d%D1%A9%DB%84ufh%EA3%A9%F6%86%0D%ED%87%9E
|
|
supply decoded frames.
There can still be scheduling delays which may let the number of
frames ready for displaying to drop below frame drop limit just
for a short period of time.
Therefore the changes remember that the decoder should have been
asked to drop some frames but do not actually have the decoder to
drop some frames. When the situation has improved at the next time
when the check is performed, the remembered frame drop is canceled
or otherwise (when the number of frames is still below frame drop
limit) executed.
(transplanted from b016e80a8206a56ba3996021bacff88b8ba44621)
--HG--
extra : transplant_source : %B0%16%E8%0A%82%06%A5k%A3%99%60%21%BA%CF%F8%8B%8B%A4F%21
|
|
allocated frames.
The current code uses a hard coded frame drop limit of 3 and
doesn't adhere to it's documentation when testing whether frames
shall be dropped. As a result frame drop limit is actually 4,
which means that the decoder is asked to drop some frames when
the number of frames waiting for displaying is less then 4.
Consider a video out device like xxmc which only supplies 8
frames. For MPEG2 decoding, two frames will be used by the
decoder (for the current frame and the forward reference frame)
and two further frames will be used in the video out loop (the
current and the previous frame) so that at any given time (under
perfect conditions) there will be 4 frames waiting to be displayed.
But when there are delays in scheduling, it might happen that
there are only 3 frames ready for displaying and thus will result
in asking the decoder to drop frames.
The changes therefore determine the maximum frame drop limit in
dependence of the number of allocated frames and make the
detection work like documented. In the above scenario, the maximum
number actually used for frame drop limit will then be 2 which
allows to compensate some scheduling delays without causing the
decoder to drop frames.
(transplanted from 2936fd493eafe3f176f2e791340167513b4e8048)
--HG--
extra : transplant_source : %296%FDI%3E%AF%E3%F1v%F2%E7%914%01gQ%3BN%80H
|
|
available.
Usually it's a good idea to avoid reallocating frames especially
when a deinterlacer needs a different format than the decoder, as
this would then happen all the time.
But when there is only a limited number of frames available, then
even a single frame which is not scheduled at frame allocation may
let the number of frames ready for displaying drop below frame
drop limit and thus resulting in unnecessary frame drops.
(transplanted from 235058555243755d3aebff03d898f1a5b94ff95e)
--HG--
extra : transplant_source : %23PXURCu%5D%3A%EB%FF%03%D8%98%F1%A5%B9O%F9%5E
|
|
drops.
When a video out device provides only a little number of video
frames, the video decoder should be scheduled immediately to
provide a decoded frame as soon as possible. Otherwise, the
number of available frames for displaying may go below frame
drop limit and thus resulting in unnecessary frame drops.
(transplanted from 33960e92decd90e6010d904476f9d45b1173153a)
--HG--
extra : transplant_source : 3%96%0E%92%DE%CD%90%E6%01%0D%90Dv%F9%D4%5B%11s%15%3A
|
|
|
|
I watch a lot of movies with subtitles and I need "vobsub subtitles"
work in xine, then I decide to write this patch.
It may support SSA tags for all text subtiles (ssa, ass, srt, ...)
This patch :
1. Remove all SSA tags from stream (they are ugly : {\a6})
2. Handle some of them (b, i, a, an, pos). The other ones control
colours, shadow, animation, ... I can't make them work in an easy way.
3. Correct wrap algorithm which have minors bugs (we can see them only
with SSA patch...)
Modified files :
libsputext/demux_sputext.c
just remove unneeded code (which remove some of SSA-tags)
libsputext/xine_sputext_decoder.c
the main modified file.
video_out/video_out_xshm.c
video_out/video_out_xv.c
xine-engine/video_out.h
get video output (position and size). See below.
1.
Removing SSA tags is done in ogm_render_line_internal() like for
html-like tags. (this was done in the previous version of xine)
2.
b(bold) and i(italic) are implemented like html-ones, in
ogm_render_line_internal().
The other tags this patch support are :
aX : alignment in SSA-code
anX : alignment in numpad code
pos(X,Y) : position, depend on alignment
For those ones, I need in first a full-screen OSD, not a five lines one.
Then, I need to remember where the last subtitle was drawn, in order to
erase it. At last, I need a translation function to convert subtitle
coordinates in screen coordinates.
For this last point, I first write a full-screen translation (don't care
about blacks borders), but it's not really good: the 'pos' tag is
sometime used to point out something in the video. (Moreover, ASS spec
say we have to draw subtitle on the video)
For doing this, I need the real video output size and position, which
are only know by the video output driver! Then I had 4 VO properties
(in xine-engine/video_out.h) for video driver could give us those
informations.
I implement it only in xshm and xv drivers (I can't test other ones).
If video driver can't give us those informations, the patch fallback in
a full-screen translation.
3.
there was 3 problem with the wrap algorithm :
1. It was in double: exactly the same, twice. Look like a merge problem.
I remove one and all work fine.
2. It want to cut string in equivalent display length but it cut it in
equivalent byte length. In most cases, this is the same, but if we have
UTF-8 chars or long SSA-tags (which will not be displayed) the result is
strange.
3. If we have a too-long part (in bytes) of the string without spaces
(bad subtitle file or long SSA-code), the algorithm don't know what to
do. (this case is not handled)
I re-write the wrap algorithm to correct those problems. Note that my
version is slower than previous one : working with bytes is really
faster than computing text-length. Maybe I should had to propose an
other patch for this part...
|
|
Some instances of "key colour" remain; ffmpeg is unmodified.
This change has caused two strings with two translations to collide (the
strings have become identical since some instances already used "colour").
I have therefore arbitrarily dropped the first of the differing translations,
the one for the string at src/video_out/video_out_directfb.c:1365.
|
|
|
|
img->stream->video_fifo can be 0
|
|
--HG--
extra : transplant_source : %15%CD%0B%2C%F2g%03%B9%25%D4%B2%8BQ%1F%EB%BB%8F%28%9B%C8
|
|
handle that case
|
|
In ao_loop only read the first buffer and remove it from the fifo only when the
buffer has been written or is about to be discarded. This fixes the race between
ao_loop and ao_close for good. Now fifo_remove_int may signal empty again right
after removing the last buffer from the fifo.
|
|
but only when a read was requested and the fifo is empty.
Rationale: ao_close uses fifo_wait_empty to make sure all buffers were written
to the driver before it calls close on the driver. But if empty is already
signaled when ao_loop just reads the next buffer then ao_close might close the
driver before ao_loop has a chance to send the buffer to the driver.
|
|
buf must be != NULL because of the while(!fifo->first) before and the buf->next after
|
|
|
|
|
|
It changes some "defined (__FreeBSD__)" into "defined (__FreeBSD_kernel__)"
and "__FreeBSD_version" into "__FreeBSD_kernel_version".
The changes are performed on places, where feature of kernel is tested. On
some other places, feature of userland/libc is tested, on them "defined
(__FreeBSD__)" remains.
As proposed, include/configure.h cause __FreeBSD_kernel__ be defined if
__FreeBSD__ is defined.
--HG--
extra : transplant_source : %25%96K%05%E4Y%B15%94%60%15%FE1%8Ah%26Xy%8C/
|
|
|
|
discard all buffers before calling fifo_wait_empty
|
|
|
|
(transplanted from 3bea001775a81a2c784e000794ea5cc6d34dc40d)
--HG--
extra : transplant_source : %3B%EA%00%17u%A8%1A%2CxN%00%07%94%EA%5C%C6%D3M%C4%0D
|
|
--HG--
extra : transplant_source : %E0%D0%C5%8B%BEU%DD%24%5D7%1F%ADV%AD%EB%23%CBU%80%EB
|
|
For contributed code, leave whatever the version we last synced for is using
to make simpler future syncs.
|
|
Seen in an AVI in the wild; apparently generated by mencoder.
|
|
Actually, audio_decoder_loop stores audio streams in ascending buffer type
order. So, for example a stream with buffer type BUF_AUDIO_A52|channel_num
will always be stored in audio_track_map array before any mpegaudio stream.
This breaks the stream order known by TS demuxer and so a user can get a52
french audio when selecting "deu" ! Bad again. This patch fixes that.
|
|
|
|
According to bug 1773769, this breaks foo->open().
The fix (as used in Ville Skyttä's patch, which doesn't cover all cases) is
to replace this with (foo->open)().
This patch was generated using
sed -i -re 's/(([[:alnum:]_]+(->|\.))+open) ?\(/(\1) (/' `grep '[>.]open \?(' include -rIl`
One change (in a comment) is not committed.
|
|
The cause was that the resampling code was using only the samples in the buffer
but not really handling the transition between two buffers (which it would
handle completely independently). The new code remembers the last sample from
the previous buffer and uses it in the resampling. We therefore end up one
sample behind and without the clicks.
|
|
Intent is to allow front ends to rename their old, badly-named, config items.
|
|
to connections list
|
|
Without copying stream up, _x_post_restore_video_frame() will reset the
native frame's stream to the value at _x_post_intercept_video_frame(),
which is typically NULL. This behaviour differs from normal frame
processing, i. e. without postprocessing.
Copying the stream up reveals that stream refcounting was missing
in several postprocessing functions, which is hereby added.
--HG--
extra : transplant_source : I%F1%0B%86%B5%5E%5D%10_6%BC%B6%BCPZ%11%04y%83/
|
|
show() in osd.c uses realloc in an effort to minimise the amount of
memory actually used for rle objects. In practice, this caused xine to
fragment memory, and gradually use more and more RAM (measured over a
period of 24 to 72 hours).
Change osd.c to allocate the maximum amount of memory it could need;
because it touches this memory in a linear fashion, lazy page allocation
will ensure that most of the memory used is needed. Further, because
this makes the per-drawing allocations the same size, it avoids virtual
address space fragmentation.
|
|
When running DVB subtitles for a long period of time (over 24 hours), we
noticed a slow leak of memory. This patch removes one cause of leakage
for us.
|
|
When using DVB subtitles on an SMP machine, we see occasional lockups, which
appear to be caused by one thread acquiring the same ticket twice. Fix this,
by preventing acquire() and release() from blocking if the current thread has
already acquired the ticket.
Code sequences like the following can still block in all acquires and
releases:
ticket->acquire(...)
/* Do something */
ticket->release(...)
However, code sequences like the following, which used to deadlock if ticket
was revoked at just the wrong moment, now succeed:
ticket->acquire(...)
/* Do something */
ticket->acquire(...) /* This acquire cannot block */
/* Do something */
ticket->release(...) /* This release cannot block */
/* Do something */
ticket->release(...)
Without this patch, the inner acquire() and release() calls could block if
ticket was revoked at the wrong time. revoke() would not unblock the blocking
acquire until there have been as many release()s as acquire()s, which cannot
happen.
|
|
|
|
of the file.
|
|
Solaris definitions.
|
|
|
|
|
|
|
|
|
|
close the driver on a return value <0
|
|
|
