Age | Commit message (Collapse) | Author |
|
|
|
This way one can just run xine vdr://
|
|
|
|
implementations.
Some implementations are buggy and lock resources (for example the display or
internal data structures) in different order, which results in deadlocks.
As XVMC_LOCKDISPLAY_SAFE is not defined by default, most API functions will
now be guarded by a LockDisplay()/UnlockDisplay() pair, which imposes a lock
order at least for the resource display and hence avoids those deadlocks.
|
|
|
|
|
|
Am 04.01.2009 um 04:55 schrieb Adrian Bunk:
> ....
> In file included from ../../../src/xine-engine/xine_internal.h:33,
> from noise.c:24:
> .../../../include/xine.h:2230: warning: 'xine_tvsystem' is deprecated
> noise.c: Assembler messages:
> noise.c:155: Error: bad register name `%rax'
> noise.c:161: Error: bad register name `%rax)'
> <-- snip -->
One problem is that the configure script thinks we're running a 64-bit
system:
,----
| checking build system type... x86_64-unknown-linux-gnu
| checking host system type... x86_64-unknown-linux-gnu
| checking build system type... (cached) x86_64-unknown-linux-gnu
`----
This is bad, build and host type should be passed explicitly in
debian/rules.
|
|
the buffer
|
|
now invalid.
But as PTS values are stored in FFmpeg's decoder, there is no way to reset them to 0.
Therefore PTS tagging has been introduced. At discontinuity a tag is generated and
applied to all new PTS values. Any returned PTS value is checked for this tag and
outdated PTS values are reset to 0. When the tag appears on returned PTS values then
tagging is reset.
|
|
order.
Attaching buffer PTS, which are in decoding order, to decoded images is
simply wrong. FFmpeg meanwhile provides a way to pass PTS values through
its decoder too. As a result they get reordered to display order and can
be attached to the decoded frames.
|
|
Currently, once the tvtime plugin has locked onto a telecine pattern, it
will wait PULLDOWN_ERROR_WAIT (a hardcoded #defined value) number of frames
before switching to filmmode.
This sensitivity is excessively high (i.e. the value is too low) for certain
content -- the kind of content that was shot on film but edited in video
mode, so telecine patterns are constantly breaking (examples like Buffy,
Simpsons and Family Guy are especially egregious offenders).
The attached patch turns this constant into a modifiable post plugin
parameter called pulldown_error_wait.
Xine helpfully emits a XINE_EVENT_POST_TVTIME_FILMMODE_CHANGE event when
film mode changes (a patch I submitted some years back). With the attached
patch, a front-end can monitor the frequency of these events, and
dynamically adjust pulldown_error_wait in a sensible way.
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c
|
|
The ARGB layer is based on the idea and scratch implementation of Julian
Scheel. Each OSD object may be associated with a client ARGB buffer which
holds the content of the OSD, hence there is no need to copy the buffer
content.
So far an OSD's reference coordinate system was defined by coded video
resolution. By specifing an OSD's extent, capable hardware or software
implementations my scale an arbitrarily sized OSD to the video output
area while blending.
Additional constants have been defined to allow vo_drivers to report
their capabilities and to allow clients to check whether an OSD
implementation supports these new features.
|
|
|
|
The test stream sometimes causes the ASF demuxer to report "unknown GUID"
several times then act as if the headers have been received, with the audio
output thread waiting forever for data to be passed to it by the decoder, in
this case the ffmpeg audio decoder.
This particular hang occurs if playback is stopped before the demuxer has
decided that headers have been received (later, and we'd have the problem
which the parent cset of this cset fixes); having the demuxer control insert
empty audio buffers where it would otherwise wait forever for the audio
output thread to receive some data.
Test stream: mmsh://213.92.19.8:80/radiodeejay?MSWMExt=.asf
|
|
playback stopped.
|
|
|
|
libmms will always fail to request media with URIs containing percent-encoded
characters. This is because the path component in the MMS URI should be
decoded before it is sent to the server.
http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-MMSP%5D.pdf
(page 48)
|
|
Currently, frame grabbing aborts when requested for accelerated image formats.
By using a vo_driver provided frame procedure to retrieve image data, frame
grabbing can be implemented for accelerated frames too. In case a vo_driver
doesn't provide this functionality, _x_get_current_frame_data() no longer
aborts when it is asked to provide image data. It will drop an error message
as before and return a "green" YV12 image.
|
|
standard format.
Frame grabbing didn't work for frame image formats besides YV12 and YUY2 as decoded data
is not stored in accelarated frames. Some acceleration APIs allow to read back decoded
image data in the common standard formats mentioned above. The new procedure allows the
vo_driver to provide a way for retrieving image data which can later be utilized by
_x_get_current_frame_data() to implement frame grabbing for accelerated frames.
|
|
|
|
|
|
--HG--
rename : src/libxineadec/Makefile.am => src/audio_dec/Makefile.am
rename : src/libxinevdec/Makefile.am => src/video_dec/Makefile.am
rename : src/libmpeg2/Makefile.am => src/video_dec/libmpeg2/Makefile.am
|
|
|
|
These are known to be present in some nvidia graphics hardware.
|
|
These drivers use "NV* Video Texture" instead of "* Textured Video".
|
|
|
|
|
|
--HG--
rename : po/libxine1.pot => po/libxine2.pot
|
|
--HG--
rename : src/combined/demux_flac.c => src/combined/flac_demuxer.c
rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c
|
|
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : %A0%EE%CC%FA%D3%AF2%8B%96%1F%B1%8E%00%01%96%8E%9E%AC%93Y
|
|
|
|
network byte order to match packet CRC
|
|
|
|
|
|
in our plugins (for now).
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/xine-utils/attributes.h => include/xine/attributes.h
rename : src/xine-engine/buffer.h => include/xine/buffer.h
rename : m4/_xine.m4 => m4/types.m4
rename : po/libxine1.pot => po/libxine2.pot
rename : src/libfaad/xine_faad_decoder.c => src/audio_dec/xine_faad_decoder.c
rename : src/libspucc/cc_decoder.h => src/spu_dec/cc_decoder.h
rename : src/libspucmml/xine_cmml_decoder.c => src/spu_dec/cmml_decoder.c
rename : src/libspudec/xine_spu_decoder.c => src/spu_dec/spu_decoder.c
rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c
rename : src/libspucc/xine_cc_decoder.c => src/spu_dec/xine_cc_decoder.c
rename : src/libmpeg2/mpeg2.h => src/video_dec/libmpeg2/mpeg2.h
|
|
|
|
When it comes to FLAC audio files, seeking relies on seekpoints which are
not always present, and even when they are, sometimes it fails. Also, as far
as I can see, xine is unable to play a FLAC stream starting at an arbitrary
position.
Other players (namely mplayer) do not rely on seekpoints when they handle
FLAC files and they don't suffer from these problems.
With this patch, time-based seeking doesn't change, while position-based
seeking is completely independent from seekpoints.
|
|
|
|
- goom initialization
- matroska playing recent files with AAC
- replace free() by ffmpeg's av_free() in ff decoders
|