[xine-devel] Patches to xine for later integration of vdr-xine

[Reinhard N. <rn...@gm...>]

Hi,

while fixing a lot of things in vdr-xine-0.7.3 I've also created a 
couple of patches to xine-lib and xine-ui, as I couldn't find a 
different way to get xine-lib to behave as needed.

Please have a look into xine-lib.diff and xine-ui.diff and feel free to 
commit them to CVS ;-)

A few words about xine-lib.diff:
- added stream information about Active Format Description (TODO: 
initialize this field to -1 = AFD not present).
- VDR has got a new key named AUDIO.
- demux_mpeg_pes had problems when a PTS wrap happend. If this wrap was 
not at consecutive packets for audio and video (e. g. when both streams 
are shifted by e. g. 1 or more packets), then xine paused for about 26.5 
hours due to a audio jump (TODO: clean up duplicate variables).
- libmpeg2 reported the wrong aspect ratio as it did that without the 
knowledge of the stream beeing a mpeg2 stream. I didn't change this part 
since the last time I've asked to commit it. Meanwhile I've more 
knowledge about the structure of a video sequence and it seems that a 
cleaner approach is possible.
- libmpeg2 delayed processing of frames unneccessarily when hardware 
decoding was used. If for example just an I frame was sent to the 
decoder which finished in a sequence_end_code (= typical still image) 
then libmpeg2 was looking for the next start code before it would decode 
the sequence_end_code and thus detect that the image is finished. As the 
sequence_end_code doesn't have any associated data, I've modified 
libmpeg2 to immediately decode a sequence_end_code.
- added decoding of Active Format Description (TODO: reset stream info 
field if AFD is no more present). As AFD is related to frames, the AFD 
field should also be put into each frame to let post plugins modify 
crop_* according to the indicated active area.
- deinterlacers didn't copy crop_* to the deinterlaced_frame thus 
resulting deinterlaced HDTV frames like that: 1920x1080, 1920x1088, 
1920x1080, 1920x1088, ...
- post plugin API didn't copy crop_* too. gcc complaind about some 
pointer stuff.
- MAX_SHOWING needed to be increased to allow xine to present the 
original 5 object plus the additional 16 object supplied by vdr-xine.
- I had to turn frontend_lock into a recursive mutex to fix deadlocks 
within input_vdr. As input_vdr calls function like set_speed() it was 
likely that xine went into a deadlock when the user choose to stop the 
VDR stream at the same time. As I didn't want to use the non portable 
linux recursive mutex I've tried to provide an emulation. It works very 
stable for all the users of vdr-xine but I'm still not shure about what 
happens when a thread is cancelled that just owns the recursive mutex.
- input_vdr needs access to a couple of internal structure members. I've 
provided a bunch of wrapper functions to avoid defining XINE_INTERNAL in 
input_vdr. Among them there're the recursive mutex functions _x_rmutex_* 
which operate on the recursive mutex xine_rmutex_t.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...