Actually, audio_decoder_loop stores audio streams in ascending buffer type order. So, for example a stream with buffer type BUF_AUDIO_A52|channel_num will always be stored in audio_track_map array before any mpegaudio stream. This breaks the stream order known by TS demuxer and so a user can get a52 french audio when selecting "deu" ! Bad again. This patch fixes that.
According to bug 1773769, this breaks foo->open().
The fix (as used in Ville Skyttä's patch, which doesn't cover all cases) is
to replace this with (foo->open)().
This patch was generated using
sed -i -re 's/(([[:alnum:]_]+(->|\.))+open) ?\(/(\1) (/' `grep '[>.]open \?(' include -rIl`
One change (in a comment) is not committed.
The cause was that the resampling code was using only the samples in the buffer but not really handling the transition between two buffers (which it would handle completely independently). The new code remembers the last sample from the previous buffer and uses it in the resampling. We therefore end up one sample behind and without the clicks.
Intent is to allow front ends to rename their old, badly-named, config items.
Without copying stream up, _x_post_restore_video_frame() will reset the native frame's stream to the value at _x_post_intercept_video_frame(), which is typically NULL. This behaviour differs from normal frame processing, i. e. without postprocessing. Copying the stream up reveals that stream refcounting was missing in several postprocessing functions, which is hereby added. --HG-- extra : transplant_source : I%F1%0B%86%B5%5E%5D%10_6%BC%B6%BCPZ%11%04y%83/
show() in osd.c uses realloc in an effort to minimise the amount of memory actually used for rle objects. In practice, this caused xine to fragment memory, and gradually use more and more RAM (measured over a period of 24 to 72 hours). Change osd.c to allocate the maximum amount of memory it could need; because it touches this memory in a linear fashion, lazy page allocation will ensure that most of the memory used is needed. Further, because this makes the per-drawing allocations the same size, it avoids virtual address space fragmentation.
When running DVB subtitles for a long period of time (over 24 hours), we noticed a slow leak of memory. This patch removes one cause of leakage for us.
When using DVB subtitles on an SMP machine, we see occasional lockups, which appear to be caused by one thread acquiring the same ticket twice. Fix this, by preventing acquire() and release() from blocking if the current thread has already acquired the ticket. Code sequences like the following can still block in all acquires and releases: ticket->acquire(...) /* Do something */ ticket->release(...) However, code sequences like the following, which used to deadlock if ticket was revoked at just the wrong moment, now succeed: ticket->acquire(...) /* Do something */ ticket->acquire(...) /* This acquire cannot block */ /* Do something */ ticket->release(...) /* This release cannot block */ /* Do something */ ticket->release(...) Without this patch, the inner acquire() and release() calls could block if ticket was revoked at the wrong time. revoke() would not unblock the blocking acquire until there have been as many release()s as acquire()s, which cannot happen.