| Age | Commit message (Collapse) | Author |
|---|
|
--HG--
extra : rebase_source : ce0547448abc3011feea54401c3e46702fbe6f11
|
|
|
|
VDR 1.7.5 requires that STC should be near to a previously transmitted PTS
value. We cannot hold this requirement immediately after a discontinuity
as the currently displayed image's vpts time (which originated before the
discontinuity) will be transformed to STC by applying the new vpts offset
established at discontinuity.
Therefore, a queue of vpts offset pairs is created and at discontinuity
the current offset is stored there in combination with the vpts value
up to which it has to be used. When retrieving a STC value, we lookup
the offset to use from current vpts and therefore get a STC near to an
originating PTS value.
As VDR requires this quality of STC values also for its trickspeed modes,
it is nolonger possible to simply set PTS of incoming frames to 0 to
schedule them just after the previous frame. Therefore a discontinuity is
generated for each frame in trickspeed mode, which allows us to schedule
each frame immediately after the previous one while there may be gaps in
PTS values. As a result the above mentioned code will take care to provide
proper STC values even in VDR's trickspeed modes.
|
|
input_vdr's RPC thread needs to lock frontend. But frontend is also locked
during xine_open() and xine_play(). xine_play() furthermore waits up to 10
seconds for the decoder to return the first frame. So it is unlikely that
the RPC thread can lock the frontend to execute VDR's commands before VDR
sends the first frame. Finally the RPC thread gave up locking the frontend
after 5 seconds and the connect to VDR failed.
To fix this issue, the RPC commands during startup phase are now handled
by the thread which has called xine_open() as it already owns the frontend
lock.
|
|
|
|
vdr-xine used a padding packet to push out any remaining data before
input_vdr executed "clear" to drop that data. But depending on the way
how input_vdr is connected to vdr-xine it could happen that the padding
packet reached input_vdr after executing "clear" and therefore "clear"
didn't work as expected.
To fix this issue, sync points are introduced by making the padding
packets "unique" in the stream. input_vdr will now drop all data up to
the sync point packet. So even if the padding packet arrives later than
the "clear" command, only data following the sync point will be fed to
the demuxer.
--HG--
extra : transplant_source : %A1%5E%8C%E1vmW%98D%1EW%A7%AF%B4V%5D%84%26%D0%DA
|
|
|
|
|
|
Several files were renamed for consistency.
--HG--
rename : include/xine/input_vdr.h => include/xine/vdr.h
rename : src/vdr/post_vdr.c => src/vdr/combined_vdr.c
rename : src/vdr/post_vdr.h => src/vdr/combined_vdr.h
|
