| Age | Commit message (Collapse) | Author |
|---|
|
Such broken wrong-extension wrong-MIME-type lists exist in the wild...
|
|
|
|
|
|
--HG--
extra : transplant_source : %0D7%2B%AC%15%14%B6%E9%7F%F0%A7%E2%EC%D3t3%9A%B29%9E
|
|
Noticed by Thomas Koeller <tkoeller@users.sourceforge.net>.
|
|
|
|
versions 0.10.6+
Note: the old code divided the frequency by 62.5. But, the ivtv driver
expects a different format. I changed the implementation in input_pvr such
that the frequency can be given as provided by cable companies, multiplied by
1000: e.g. 503250 for 503.250 MHz.
|
|
--HG--
extra : transplant_source : %00%11%94ZZG%2A%A0%2A%3B%DA%CDx%AC%02%A8%E8%C3%DF%A5
|
|
|
|
|
|
|
|
|
|
(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
|
|
(transplanted from ce2ba83d5b347bb670e4aaa17a9fbcf21d87a811)
--HG--
extra : transplant_source : %CE%2B%A8%3D%5B4%7B%B6p%E4%AA%A1z%9F%BC%F2%1D%87%A8%11
|
|
(transplanted from 65ffd061414c05cbc368e130d1783a2efdc5b75e)
--HG--
extra : transplant_source : e%FF%D0aAL%05%CB%C3h%E10%D1x%3A.%FD%C5%B7%5E
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
(transplanted from c7cc5ff1e184791683ba13bdc54c53b5887e6587)
--HG--
extra : transplant_source : %C7%CC_%F1%E1%84y%16%83%BA%13%BD%C5LS%B5%88%7Ee%87
|
|
(transplanted from 659598a5840c6d8745dc629e83971782d32e814e)
--HG--
extra : transplant_source : e%95%98%A5%84%0Cm%87E%DCb%9E%83%97%17%82%D3.%81N
|
|
|
|
According to specification the center offset components are
signed integers.
|
|
|
|
|
|
|
|
Both options tweak FFmpeg for the sake of decoding speed. The first one
skips the loop filter for certain frames while the latter allows FFmpeg
to violate the codec's specification. Both options may lead to artefacts.
|
|
|
|
/usr/bin/totem-video-thumbnailer -s 128 ssh://user@hosts/path/to/video.ext
Will segfault.
All the time.
--HG--
extra : transplant_source : H%1EU%A5%3C%E6r%976%AA%C3%92%E5l%C7w%92dg.
|
|
|
|
This way, bigger audio chunks won't make the demuxer fail.
Fixes bug #6.
|
|
ivtv now requires the video device to be re-opened when the input is changed.
|
|
|
|
|
|
What this patch does is replace the token buffer of static size in
xml_parser_get_node with a malloced buffer. If the lexer notices, that it
needs more size it just increases the size of this buffer by factor two and
tries again. This may not be very elegant, but it works.
node_name and property_name are dynamically-sized too.
|
|
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...
|
|
|
|
|
|
Optionally depend on packages from debian-multimedia.
|
|
|
|
|
|
(transplanted from c139cfe735874922208d936c8e49bbfa532ed2ec)
--HG--
extra : transplant_source : %C19%CF%E75%87I%22%20%8D%93l%8EI%BB%FAS.%D2%EC
|
|
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.
|
|
|
|
|
|
|
|
This make it possible to use the DJB accelerated FFT when using the external a52dec liba52 library.
--HG--
extra : transplant_source : %03Y%0F%8C%F0%05%EE%F7%5E%2B%A9u%7D%96%F8%D2%13%CD%F4%9D
|
|
|
|
|
|
|
