| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--HG--
extra : transplant_source : %D9%DE%C7%C9%CB%D9%84%1E%A2%A0%AD%A9%E1%C27%EA%C6%E5%A3A
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : q%B3q%EEC%D4p%E7%7F%8Eb%BE%F8%81%D3c%F6%C8%1AF
|
|
Fixed bug id=2.
|
|
Fixed bug id=17.
|
|
skips the first part of the frame.
Fixed wmv playback with ffmpeg.
|
|
|
|
|
|
|
|
|
|
|
|
Typo of WORDS_BIGENDIAN in in /src/video_out/macosx/XineVOpenGLView.m. It
only affects big-endian systems (PowerPC) as it defaults to little-endian.
|
|
|
|
CVE-2008-0225; ported from mplayer changeset 22821.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In draw_subtitle(), if the given encoding is one the CJK charset, colored
typefaces functionality is disabled and subtitles are printed with the
render_text() method. Otherwise subtitles are drawn by ogm_render_line()
function.
|
|
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.
|
