Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
On Wed, Feb 21, 2007 at 11:12:43PM +0100, Reinhard Nissl wrote: > > Actually, I don't know how this is done in the case of a FF card and > what the firmware has to do in this regard. A guess -- which could > explain the issues you see -- would be that sync is not maintained > continuously. So after having maintained sync for some time, audio and > video frames are simply taken out of some FIFOs at a constant rate and > presented to the user -- this should keep audio and video in sync as > originally maintained. But when then for example an audio frame gets > lost due to a lost TS packet, audio and video get out of sync as the > lost packet brakes filling the FIFOs at a constant rate. When you try to > reproduce this effect by seeking back in the recording, then sync is > maintained actively and you don't see this issue again at that position > in the recording. If the resulting Mpeg-Audio stream is broken in such a way that the HW-Decoder runs into trouble from which it can not recover the Audio HW_buffer gets emptied very fast which .. in fact .. results in a silent but very fast video sequence. For the next firmware I've added a dectection of such an unrecoverable audio decoder error to restart the audio decoder as fast as possible. Btw: With xine and mplayer I hear a short noise and nothing happen with the running picture. Maybe the mplay software decoder its self has some checking about the Mpeg-Audio stream and the AV synchronization does not depend on the audio PTS. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi, On Mi, Feb 21, 2007 at 07:59:18 +0200, Kartsa wrote: > Reinhard Nissl kirjoitti: > >I had a look into the files you've provided me. It looks like some TS > >packets get lost. You can simply check this on your own: > > > > od -Ax -t x1 -w188 -v ts_10973_11079_0xC0_004_116796_1000.log \ > > | tail -n 20 | less -S > > > >I wonder why you didn't get lines like the following in your logfile > >after enabling the earlier mentioned source lines and specifying > > > > -l 3 > > > This has been very illuminating. Maybe I made some mistake with the > logging because there really is no TS continuity error in the log. I > definitely have -l 3 on commandline (just checked with ps -ef). And I Under debian Systems you must look in to /var/log/syslog and not in to /var/log/messages. It depends on your syslog configuration. Maybe it helps. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Halim Sahin kirjoitti: This has been very illuminating. Maybe I made some mistake with the logging because there really is no TS continuity error in the log. I definitely have -l 3 on commandline (just checked with ps -ef). And I Under debian Systems you must look in to /var/log/syslog and not in to /var/log/messages. It depends on your syslog configuration. Maybe it helps. Thanks, but in FC it is /var/log/messages :) And everything else is in messages file. There is no syslog file. But it has to be something to do with where the messages are at least trying to be written. Maybe I'll figure it out some day :) \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mplayer does not work properly
Niko Mikkila wrote: > On Wed, 21 Feb 2007 22:58:57 +0200 > Pasi Juppo <[EMAIL PROTECTED]> wrote: > >> Strange that it works fine on the server and both have the same setup of >> codecs. Have to check further. > > It could also be that the clip has AC3 or DTS audio, and MPlayer is > configured to handle them in a different way (passthrough). Can't think > of any other reason for the problem. Usually AC3 and DTS works just fine. Stream is sent to amplifier who decodes it. But, I need to check this further when I have more time.. Also, there seems to be DVD support in trunk version of the mplayer. Any idea whether mplayer plugin will support DVD in the near future? >>> Have you tried the current support in mplayer.sh? >> >> No, I was under impression that DVD menu navigation is not supported. >> Have to recheck this too then. > > Well, there's no navigation support, but personally I prefer the MPlayer way > :) > Don't know how it works with the MPlayer plugin though, that's why I asked. Ah, you mean hardcore way. OK, it's not really bad but sometimes (well, seldom actually) menus are good (varies a lot between movies). I'll check this anyway again. I've been using DVD plugin but the picture quality is far from good. I've been thinking of Xine with xinelibout due to good deinterlace features but if mplayer supports this then I can still use FF card with mpegpes output (I still have normal TV). Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi Werner, Any idea when you will be able to release the new firmware for testing? Kind Regards, Morfsta On 2/22/07, Dr. Werner Fink <[EMAIL PROTECTED]> wrote: For the next firmware I've added a dectection of such an unrecoverable audio decoder error to restart the audio decoder as fast as possible. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi, Dr. Werner Fink wrote: > On Wed, Feb 21, 2007 at 11:12:43PM +0100, Reinhard Nissl wrote: > >> Actually, I don't know how this is done in the case of a FF card and >> what the firmware has to do in this regard. A guess -- which could >> explain the issues you see -- would be that sync is not maintained >> continuously. So after having maintained sync for some time, audio and >> video frames are simply taken out of some FIFOs at a constant rate and >> presented to the user -- this should keep audio and video in sync as >> originally maintained. But when then for example an audio frame gets >> lost due to a lost TS packet, audio and video get out of sync as the >> lost packet brakes filling the FIFOs at a constant rate. When you try to >> reproduce this effect by seeking back in the recording, then sync is >> maintained actively and you don't see this issue again at that position >> in the recording. > > If the resulting Mpeg-Audio stream is broken in such a way that > the HW-Decoder runs into trouble from which it can not recover > the Audio HW_buffer gets emptied very fast which .. in fact .. > results in a silent but very fast video sequence. For the next > firmware I've added a dectection of such an unrecoverable audio > decoder error to restart the audio decoder as fast as possible. > > Btw: With xine and mplayer I hear a short noise and nothing > happen with the running picture. Maybe the mplay software > decoder its self has some checking about the Mpeg-Audio stream > and the AV synchronization does not depend on the audio PTS. Well, in xine it works like that: The demuxer thread reads the PES packets from the input stream, determines whether the packet is audio respectively video, get's an empty buffer from either the audio respectively video input buffer pool, fills the buffer with the PES payload, transfers PTS from the PES packet to the buffer when PTS is available in the PES packet and puts the buffer into the audio respectively video input FIFO of the decoders. Audio and video is decoded by different threads. Each one takes a buffer from its input FIFO, stores the contained PTS value internally when one is available to have it ready when the next access unit (= an audio respectively video frame) is started. The buffer's data is decoded into the current access unit's output buffer. When a new access unit starts, the current output buffer is put into the audio respectively video output FIFO and a new output buffer is allocated from the audio respectively video output buffer pool. When a PTS value is available, the PTS value is transferred into the current access unit's output buffer. Otherwise, the PTS value of the last access unit's output buffer is incremented by the last access unit's duration (= either audio respectively video frame duration) and transferred instead. As a result each decoded audio respectively video frame has now a PTS value assigned to it (to be precise, transferring the PTS value translates it into an internal representation which is used next). Audio and video presentation is done by different threads. Each one takes an output buffer (= access unit (= audio respectively video frame)) from its associated decoder output FIFO, reads the PTS value and compares it to the STC which is provided by the so called metronom. When PTS is larger than STC, the video output thread simply sleeps until PTS is less or equal to STC and when it awakes, it writes the output buffer into the graphics card's video memory. The audio output thread behaves similar, although it has to generate silence audio data for the sound card in the case where sleeping for a longer time would cause the sound card's input buffer to underrun. So from the above explanation, I don't think that AV synchronization doesn't depend on the audio PTS -- at least in the case of xine. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR recording speeds up during playback
I'm posting this now on this list, because got no reaction from dvb-list. I noticed a weird problem with last weeks Mythbusters episode VDR recording. The playback suddenly speeded up like fastforward and it is repeatable. I've seen this once earlier also, but thought that it was caused by bad reception, but this time the were no visible errors on the recording. Here's the clip (22MB): http://kotisivu.suomi.net/izero/mythbusters.tar Tested with VDR 1.4.5 and firmware versions 261a, 261f, 2622 and F12623 testversion (normally in use). Not repeatable when played with VLC on OS X. My Setup: P3 700MHz 256 MB RAM Technotrend DVB-C FF 2.1 + CICAM with Conax Technotrend DVB-C FF 2.1 Fedora Core 5 2.6.16-1.2157_FC5 kernel VDR 1.4.5,+streamdev,ttxtsubs,subtitles,tvonscreen,text2skin, burn,wapd,osdteletext,mp3,femon -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
