Hi, Jouni Karvo wrote: > > Please enable vdr-xine's PTS logger by changing the if (0) in > > cXineDevice::PlayCommon3() (xineDevice.c:1018) into a if (1). > > OK. > > > All pts* values should always step forward or stay at the same value. > > The d* values show the difference to xine's metronom and should > > typically be > 60000. > > Well, they are when xine plays normally. Then something else happens: > > When the sound (and shortly after video) disappears, first dA may jump to > a high value. Then it starts getting smaller, and then: Well, I've reformatted the output a little bit to show you what happens: deltaV ptsVideo deltaAV ptsAudio deltaA deltaDisc 8470619536 -87835 -87835 8470531701 43200 19440 19440 8470551141 111595 111595 8470662736 19440 -92155 -92155 8470570581 43200 17280 17280 8470587861 118075 118075 8470705936 19440 -98635 -98635 8470607301 Columns ptsVideo and ptsAudio show you the PTS seen on PES packets with the specified content. deltaV and deltaA show the difference in PTS of consecutive packets of the specified type. Finally, deltaAV shows the difference between two consecutive packets of different type and deltaDisc results in the difference of two consecutive packets. A few words how xine works: xine's metronom dictates when audio frames respecitively video images need to be sent to the hardware. Therefore the metronom generates virtual presentation time stamps (vpts). vpts and the PTS of the stream are related and differ by vpts_offset. vpts_offset is calculated when xine's demuxer sees the first PTS of the stream and later, when the demuxer sees the PTS of stream jump. A typical jump happens when the 33 bit PTS counter overflows which happens about every 26.5 hours. When the demuxer indicates a discontinuity, a special buffer element is put on both the video and the audio fifo. Then when audio and video decoder process this element, both decoders wait for the other to reach this state too. At this point, all packets with PTS before the jump have been processed and it is now safe to compute vpts_offset with the new PTS when the jump was detected. After that, any further PTS after the wrap will be transformed into a vpts that is continuous (vpts is a 64 bit counter and doesn't see a wrap in a humans life). demux_mpeg_pes's wrap detection code considered the wrap of video PTS and audio PTS independently. I. e., it indicated a discontinuity when either deltaV or deltaA where larger then WRAP_THRESHOLD (default 120000). The code relied on the wrap to happen on consecutive audio and video packets, i. e. it didn't work properly in the case where after a video discontinuity an audio packet with a PTS value before the wrap was seen. The example below shows this more clearly (PTS is considered to be just a single digit): works for: V7 A7 V8 V9 A9 V0 V1 A1 V2 V3 A3 didn't work: V7 V8 A7 V9 V0 A9 V1 V2 A1 V3 V4 In such a case an audio jump was detected and output was hold for about 26.5 hours. As it was almost impossible to reorder audio and video packets in a way that the original constraint of the code was fulfilled, I've modified the wrap detection code in demux_mpeg_pes for vdr-xine-0.7.3: it nolonger determines the wrap by independently looking on audio respectively video PTSs. Instead it simply looks on the delta of two consecutive PTS values (see column deltaDisc in the above table). This fixed the problem for my sample stream where a real wrap happend. Let's repeat the above example: works for: V7_A7_V8_V9_A9:V0_V1_A1_V2_V3_A3 works for: V7_V8_A7_V9:V0:A9:V1_V2_A1_V3_V4 Legend: _ indicates a delta below WRAP_THRESHOLD and : a delta above this value. Now, up to three discontinuities are indicated to xine's metronom to properly decode the area V9:V0:A9:V1. To come back to your problem: when you read about demuxing you'll find that there is a typical delta between audio and video of up to 700 ms which corresponds to 63000 pts. So I thought the default WRAP_THRESHOLD of 120000 pts would be ok to not trigger any false discontinuities. As you wrote below, a larger value seems to fix your problem. Would you please be so kind and try 150000 (= 5/3 seconds) and if this doesn't solve the issue 180000 (= 2 seconds). As this value typically serves for detecting a PTS wrap, it would also be ok to choose a really larger value up to 2^31. > Even negative. In this example, when dA goes to approx -100000, dV > goes also negative. At this phase, the "bad frame" messages appear: This is the effect of xine seeking the stream to catch up. Negative values indicate that xine want's already display frames that vdr-xine has not even got from VDR to send it to xine. One could take this number as latency time of the connection VDR -- vdr-xine -- xine. > > You might also want to play with xine's demuxer. Locate WRAP_THRESHOLD > > in xine-lib/src/demuxers/demux_mpeg_pes.c:54 and reduce this value to > > 90000 (i. e. smaller than the above reported diff). Feel free to > > experiment with this value, e. g. increase it. > > With 90000, the problem is still there. Putting 50000 makes this > problem much worse. With 200000, the dA seems to depend on the > channel (mux?). For "YLE TV1", it seems mainly float around 30000, while "the Voice" > shows around 70000 (the same as with YLE and WRAP_THRESHOLD 120000). > > I'll keep the 200000 for a while now and see how it looks like. It is true that the total buffer differs from channel to channel. There is even a difference when you switch to the same channel again. It has to do with xine seeking to skip the PTS difference between the first audio and video packet. vdr-xine's extra buffering tries to compensate this effect but the resulting buffer still differs. vdr-xine-0.7.4 will have a new softstart algorithm that takes into account the absolute buffer established. And it may also take into account the latency of the connection to further reduce the number of dropped frames when switching channels. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx
