Age | Commit message (Collapse) | Author |
|
This is optional, and some systems don't support it. POSIX defines the
_POSIX_THREAD_PRIORITY_SCHEDULING to tell that support is present.
|
|
|
|
Based on patches from Roger Scott <ras351@hotmail.com>.
|
|
|
|
|
|
All the initialisation functions returning a new object instance that
was allocated through malloc() or calloc() can get the malloc
attribute so that the compiler can optimise their call.
|
|
The xine_xmalloc() function is going to be deprecated, as its
behaviour is rarely needed as such, and it's thus misused.
With this, almost all uses of xine_xmalloc() with static size (for
instance the value returned by sizeof()) or with a size that is
guaranteed not to be zero (like strlen()+1) are replaced with calls to
either calloc(1, ...) or malloc().
malloc() is used whenever the allocated memory is going to be
immediately overwritten, while calloc() is used in every other case,
as it sets the whole memory area to zero.
--HG--
extra : transplant_source : %8F%98%EC%02%1E%83%F0s%06X%83C%205Y%80%B12%CC%E1
|
|
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
|
|
img->stream->video_fifo can be 0
|
|
--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.
|
|
private structure so it's not part of the ABI.
CVS patchset: 8781
CVS date: 2007/04/01 01:03:06
|
|
still need to investigate the cause, might be due to pause when using net_buf_ctrl
CVS patchset: 8513
CVS date: 2007/01/16 16:00:26
|
|
(nothing to see here, i'm just testing xine latency in some realtime
experiments...)
CVS patchset: 8496
CVS date: 2007/01/10 20:13:14
|
|
CVS patchset: 7948
CVS date: 2006/03/25 01:26:34
|
|
For speeds < 100%, vo_loop() won't sleep for long enough. Not a problem.
For speeds > 100%, it may sleep for too long; consequently, frames may be
dropped.
(Reinhard Nissl)
CVS patchset: 7947
CVS date: 2006/03/25 01:17:44
|
|
CVS patchset: 7848
CVS date: 2006/01/27 07:46:09
|
|
CVS patchset: 7801
CVS date: 2005/11/14 23:48:19
|
|
vo_remove_from_img_buf_queue_int's timeout
* should fix segfaults when unwiring/disposing post plugins
CVS patchset: 7800
CVS date: 2005/11/14 23:12:16
|
|
in the same format as requested (avoid unnecessary free/alloc in
vo driver). up to 25% less cpu load using deinterlace with film mode.
CVS patchset: 7741
CVS date: 2005/09/24 21:51:11
|
|
"clip" thing has caused too much confusion already since these variables
define a highlight area.
- add overlay offset support to video_out.c/alphablend/vo drivers
- use overlay offset to implement proper croping of frames when vo
driver doesn't support it
- add clipping checks to alphablend to avoid buffer overflow, buffer
"underflow" and wrapping.
- increase vo api number
- note: dxr3 support is incomplete about overlay offset
CVS patchset: 7739
CVS date: 2005/09/24 19:08:26
|
|
CVS patchset: 7417
CVS date: 2005/02/14 14:04:55
|
|
CVS patchset: 7413
CVS date: 2005/02/13 22:23:41
|
|
CVS patchset: 7412
CVS date: 2005/02/13 22:14:17
|
|
stream info in xine_close
CVS patchset: 7411
CVS date: 2005/02/13 22:12:50
|
|
and backwards compatible translation
Sorry, I got a litte tired proof-reading the patch, so their might be
bugs lurking around. I will give it some further examination and
(as necessary) fixing tomorrow.
CVS patchset: 7233
CVS date: 2004/12/12 22:00:47
|
|
CVS patchset: 7076
CVS date: 2004/10/26 20:10:20
|
|
CVS patchset: 7049
CVS date: 2004/10/18 21:07:38
|
|
CVS patchset: 7042
CVS date: 2004/10/17 19:13:09
|
|
See these two threads:
http://thread.gmane.org/gmane.comp.video.xine.devel/10819
http://thread.gmane.org/gmane.comp.video.xine.devel/10424
Fixed _x_handle_stream_end __stop_internal race.
See this thread:
http://thread.gmane.org/gmane.comp.video.xine.devel/10818
If the lib is broken after this patch, you know who to blame ;-)
CVS patchset: 7036
CVS date: 2004/10/14 23:25:24
|
|
CVS patchset: 7026
CVS date: 2004/10/09 06:44:21
|
|
and this code is correctly understood by me ;)
also fall back to old behaviour (no cropping at all), if the image cannot
be cropped due to an unknown frame format
CVS patchset: 7024
CVS date: 2004/10/08 21:08:26
|
|
there is still some work to do, please report any breakages.
note: new xxmc driver tested with both nvidia and via libraries.
CVS patchset: 7007
CVS date: 2004/09/28 18:49:38
|
|
- some vo drivers support cropping natively.
(only xv and xvmc have been tested)
- add software crop fallback to video_out.c
- skip yuv2rgb processing at xshm for not yet cropped frames
(these frames are never shown)
- libmpeg2 and ffmpeg now may use crop support
- bump vo api. (changes to xvmc/xxmc will follow)
CVS patchset: 6991
CVS date: 2004/09/22 20:29:13
|
|
https://sourceforge.net/tracker/?func=detail&atid=109655&aid=947520&group_id=9655
CVS patchset: 6818
CVS date: 2004/07/19 22:45:48
|
|
fix problems of bogus frame skipping when duration changes.
CVS patchset: 6798
CVS date: 2004/07/15 21:20:06
|
|
finished event was sent to frontend before the output fifos were empty.
add a test for the number of streams attached to the output port. this will
prevent deadlocking on multi-streams scenarios where fifos don't ever get empty.
CVS patchset: 6777
CVS date: 2004/07/06 22:53:22
|
|
CVS patchset: 6775
CVS date: 2004/07/05 17:13:37
|
|
CVS patchset: 6748
CVS date: 2004/06/26 13:51:13
|
|
(fixed latest deadlock report by Stefan Holst)
CVS patchset: 6744
CVS date: 2004/06/25 16:09:31
|
|
CVS patchset: 6713
CVS date: 2004/06/19 20:07:15
|
|
http://article.gmane.org/gmane.comp.video.xine.devel/9532
it is now up to demuxers to decide what the 0..65535 position means.
demuxers tested: ogg, voc, flac, rm, asf, vqa, vob, avi, y4m, au, mov, ts, mp3, mpg, wav, ra, mve
CVS patchset: 6686
CVS date: 2004/06/13 21:28:52
|
|
Copy is_frame value in duplicate_frame vo function.
Fix the bug i've reported here:
http://news.gmane.org/navbar.php?group=gmane.comp.video.xine.devel&article=9301&next=9322&prev=9310&newsrc=,9301,9322
CVS patchset: 6631
CVS date: 2004/06/02 19:46:10
|
|
CVS patchset: 6613
CVS date: 2004/05/30 21:33:38
|
|
before, NULL could mean two things: no stream at all or a stream that does not
want to be addressed; now the latter is represented by the new XINE_ANON_STREAM
resulting changes:
* the status() functions now behave differently for NULL and XINE_ANON_STREAM
(as the commentary always implied, but this was not the case, so post
plugin rewiring went wrong, because it relies on the status() function)
* the NULL_STREAM defines in audio_out and video_out are obsolete
* update the function comments in the headers
* update the post plugin rewire functions to use the status() functions to
check, if the old port was opened and handle the new one accordingly;
this makes open_count obsolete
* change all post plugins accordingly (mostly using XINE_ANON_STREAM instead
of NULL)
additional change:
* the status() function of audio port now returns the bits/rate/mode values
of the input and not the output; this is more likely to be what a post plugin
wants
* the reimplementation of status() in the upmix plugin is obsolete
CVS patchset: 6603
CVS date: 2004/05/29 14:45:25
|
|
1 - When a first frame is still referenced, poll until there is only one reference. (with a limit, see FIRST_FRAME_MAX_POLL). This way the frame is displayed as soon as possible.
2 - When a "flush" occured, don't wait the full duration of the frame and exit the waing loop as soon as possible.
The problems have been identified and fixed using a toxine script to stress seeking. It's available here (requires toxine cvs) :
http://xine.sourceforge.net/tmattern/seek_test_1.toxine
It performs approx. 500 seeks. I have tested avi, asf, mov, mpg, mkv streams.
The engine can do a bit more than 10 seeks per second here (athlon 2.6 GHz), with all kind of streams. ;)
toxine has been improved to support a such script (env vars, and the "repeat" command), thanks to Daniel.
CVS patchset: 6585
CVS date: 2004/05/23 21:30:26
|
|
allows the code for handling this special case to actually be used
CVS patchset: 6532
CVS date: 2004/05/13 21:38:49
|
|
CVS patchset: 6497
CVS date: 2004/05/07 22:49:24
|