Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Richard, Many thanks for your continued support and assistance. I will test your patch when I return home. A week or two ago I tried to isolate a recording that was going out of sync, so that I could send it to Oliver. The problem I found is that it didn't do it all the time! If I spotted a recording that had gone out of sync and then rewound a bit to see where the sync problem started, the problem was corrected. I tried this a few times and couldn't isolate a single start and end point that I could cut to send. Of course, I cannot do this on live TV.. What I do not understand and perhaps you could help me with, is that you say that there is a problem with the firmware, yet there are entries in the log from VDR saying that it is dropping x bytes to sync on the next audio frame... This suggests to me that VDR is doing *something* with respect to audio synchronisation. Why then is the problem always reported as being an issue with the firmware? Kind Regards, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ff card tt dvb-s 2300
Hello, I am getting ts continuity errors in vdr with my tt 2300. Since 3 weeks I am trying to optimize my system. Now there is the Question of signal Problems. I did not have any problems with my other telestar receiver so I did not check the signal before. Femon shows the folowing on RTL on astra 19,2. status 1f | signal ac7c | snr d6dd | ber 1200 | unc | FE_HAS_LOCK status 1f | signal ac73 | snr d6dd | ber | unc | FE_HAS_LOCK status 1f | signal ac7b | snr d6f2 | ber | unc | FE_HAS_LOCK status 1f | signal ac7c | snr d73a | ber | unc | FE_HAS_LOCK status 1f | signal ac7d | snr d719 | ber | unc | FE_HAS_LOCK status 1f | signal ac77 | snr d6fb | ber | unc | FE_HAS_LOCK status 1f | signal ac67 | snr d6e6 | ber | unc | FE_HAS_LOCK status 1f | signal adb8 | snr d6f8 | ber | unc | FE_HAS_LOCK status 1f | signal ac74 | snr d70d | ber | unc | FE_HAS_LOCK status 1f | signal ac78 | snr d6dd | ber | unc | FE_HAS_LOCK status 1f | signal ac5e | snr d6e3 | ber | unc | FE_HAS_LOCK Are these values ok or not? Can someone compare these output with the same card? Thanks -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ff card tt dvb-s 2300
On Wednesday 21 February 2007 12:33, Halim Sahin wrote: > Hello, > > I am getting ts continuity errors in vdr with my tt 2300. > Since 3 weeks I am trying to optimize my system. > Now there is the Question of signal Problems. > I did not have any problems with my other telestar receiver so I did not > check the signal before. > Femon shows the folowing on RTL on astra 19,2. > status 1f | signal ac7c | snr d6dd | ber 1200 | unc | > FE_HAS_LOCK > status 1f | signal ac73 | snr d6dd | ber | unc | > FE_HAS_LOCK > status 1f | signal ac7b | snr d6f2 | ber | unc | > > > Are these values ok or not? > Can someone compare these output with the same card? > Thanks Hello, I have similar values (tt 2300): status 1f | signal aef8 | snr d66e | ber | unc | FE_HAS_LOCK status 1f | signal aef4 | snr d680 | ber | unc | FE_HAS_LOCK status 1f | signal aefb | snr d62f | ber | unc | FE_HAS_LOCK status 1f | signal aef1 | snr d62f | ber | unc | FE_HAS_LOCK Are you sure this is a signal problem? Are you getting these problems at all transponders? Try to check dependency of errors on bitrate of video/audio. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ff card tt dvb-s 2300
Hello, > > I have similar values (tt 2300): > status 1f | signal aef8 | snr d66e | ber | unc | FE_HAS_LOCK > status 1f | signal aef4 | snr d680 | ber | unc | FE_HAS_LOCK > status 1f | signal aefb | snr d62f | ber | unc | FE_HAS_LOCK > status 1f | signal aef1 | snr d62f | ber | unc | FE_HAS_LOCK > > Are you sure this is a signal problem? Are you getting these problems at all > transponders? > Try to check dependency of errors on bitrate of video/audio. > HMM what do you mean? I am getting these errors on all transponders. Sometimes there are no errors for 15 minutes. Sometimes there are errors for 4 minutes etc. I read a lot of stuff in vdr-portal and tested many driver firmware combinations. The last thing was the signal but if you are right and these femon output lines are ok I have no ideas what to test now. Again my skystar2 in my other pC works fine. The telestar receiver works fine only the tt card doesn't. Please help. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ff card tt dvb-s 2300
On Wednesday 21 February 2007 14:03, Halim Sahin wrote: > Hello, > > HMM what do you mean? > I am getting these errors on all transponders. I meant to test as well on channel with high bitrate as german channels as well as on some channels with lower bitrate (<2Mbps, for ex. Q TV SHOP @12148H). Are you using for output some sw decoder like softdevice, xine etc. or are you using TV output from card? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ff card tt dvb-s 2300
Hi, On Mi, Feb 21, 2007 at 02:20:15 +0100, bastlir wrote: > On Wednesday 21 February 2007 14:03, Halim Sahin wrote: > > Hello, > > > > HMM what do you mean? > > I am getting these errors on all transponders. > > I meant to test as well on channel with high bitrate as german channels as > well as on some channels with lower bitrate (<2Mbps, for ex. Q TV SHOP > @12148H). > Are you using for output some sw decoder like softdevice, xine etc. or are > you > using TV output from card? > kI am using the tv output of the ff-card. High or low bitrates makes no difference. There are dropouts on all transponders. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ff card tt dvb-s 2300
On Wednesday 21 February 2007 14:33, Halim Sahin wrote: > Hi, > > On Mi, Feb 21, 2007 at 02:20:15 +0100, bastlir wrote: > > On Wednesday 21 February 2007 14:03, Halim Sahin wrote: > > > Hello, > > > > > > HMM what do you mean? > > > I am getting these errors on all transponders. > > > > I meant to test as well on channel with high bitrate as german channels > > as well as on some channels with lower bitrate (<2Mbps, for ex. Q TV SHOP > > @12148H). > > Are you using for output some sw decoder like softdevice, xine etc. or > > are you using TV output from card? > > kI am using the tv output of the ff-card. > High or low bitrates makes no difference. > There are dropouts on all transponders. > > Halim So I'm sorry I don't know how to help you. I sometimes have similar problems, but only on specific channels (channels I'm normally not interested in) - this was the reason of my question. Regards ___ 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)
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 on VDR's command line to turn on debug log messages: Feb 20 21:41:14 video vdr: [27499] TS continuity error (1) Feb 20 21:41:15 video vdr: [27499] cTS2PES got 0 TS errors, 1 TS continuity errors 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 also checked that I had activated the line in remux.c. And I now that I have used that remux.c while compiling because it is the same that I used your patch against. So I do not know why there is no TS continuity errors on log. Sad to say, I can hardly help you further as lost TS packets can be caused by a couple of reasons: - Dish alignment - Weather conditions - Cabling - Interference with DECT telephones - DMA/PCI mainboard issues - High system load / latency - DVB driver issues I am in cable so dish can not be the problem, nor the weather. Cabling is one (including the operators cables) and I suspect a hw issue (or DMA/PCI) as I have sata drives. Telephones can always be a problem but I do not think that this often. High load is not a possibility unless vdr is causing the load :) And ofcourse there is the driver. But mostly I suspect the cable operators cables because even the analog picture is not too good and I get cAudioRepacker skipped messages on my other vdr also (but after fifth simultaneous recording). Ofcource the firmware is the same. I think I must try the older fw on the other to see if it makes any difference. As you can see, VDR just picks up what survived the above stages. I had lost TS packets over and over just after replacing my PATA drive by a SATA drive to have the PATA one sent in for repair. I've contacted the dvb-mailing list and got driver patches for larger DMA buffers. Extremely large buffers seemed to fix the problem but not completely. After the PATA drive returned from repair, I've removed the SATA drive and -- you won't believe it -- everything worked out of the box as before, even with default drivers (I won't blame here SATA in general -- this is just my personal experience at that time with certain hardware). This is why I am using different mb model and a pata drive on a new vdr I am just building for a friend. I will inform you about how that one works. BTW: You may wonder why you do not get these messages when watching live TV with a FF card. The answer is simple: the TS packets never leave the card in this case, so VDR has no way to report such an issue for example in case where the problem would be related to dish alignment. I have no problems with the live TV. Never had any problems with that. Anyway thanks for your input and support. \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] mplayer does not work properly
Hi, I have couple of video clips that fail to work properly via VDR. First ones playback is very jerky (23.976fps) via VDR but no problem played back on PC. Second one does not play sound from the clip but the sound from the channel that was being viewed before playback. I've tried mplayer.sh 0.8.6 and 0.8.7. mplayer itself is version 1.0rc1. Haven't tried trunk version because there did not seem to be fixes related to audio or jerkiness. Anyone else with similar problems? 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? Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] writing plugins 101
Hi. Anyone know a good reference on how to write VDR plugins? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] writing plugins 101
Hi, Do you know the PLUGINS.html file in vdr's source tree? Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mplayer does not work properly
On Wed, 21 Feb 2007 20:32:02 +0200 Pasi Juppo <[EMAIL PROTECTED]> wrote: > Hi, > > I have couple of video clips that fail to work properly via VDR. First > ones playback is very jerky (23.976fps) via VDR but no problem played > back on PC. When playing back 24 fps video on an FF-card or any other PAL TV-output device, jerkiness is quite expected. You need to speed up the playback by a factor of 25/24~=1.0417, which can be done with the -speed option in MPlayer. Audio pitch will rise slightly, so if that bothers you, use an external LADSPA filter to compensate (see: http://mark.santaniello.net/archives/260). The NTSC/PAL speed setting should be handled automatically in the mplayer.sh script, but have you configured NTSC="false" in mplayer.sh.conf? > Second one does not play sound from the clip but the sound from the > channel that was being viewed before playback. MPlayer probably has problems with the audio codec used in the clip. Updating to latest SVN could help. If not, try other players and identify the audio codec. If the codec should be supported, take a look at the mplayer -v output and perhaps upload a sample somewhere. > I've tried mplayer.sh 0.8.6 and 0.8.7. mplayer itself is version 1.0rc1. > Haven't tried trunk version because there did not seem to be fixes > related to audio or jerkiness. Did you actually read through the SVN logs from the last 4 months? Quite an accomplishment. ;) Anyway, most of the codec-related stuff is in FFmpeg/libavcodec, which is in a separate repository. > Anyone else with similar problems? > > 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? Regards, Niko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mplayer does not work properly
> On Wed, 21 Feb 2007 20:32:02 +0200 > Pasi Juppo <[EMAIL PROTECTED]> wrote: >> >> I have couple of video clips that fail to work properly via VDR. First >> ones playback is very jerky (23.976fps) via VDR but no problem played >> back on PC. > > When playing back 24 fps video on an FF-card or any other PAL TV-output > device, jerkiness is quite expected. You need to speed up the playback > by a factor of 25/24~=1.0417, which can be done with the -speed option > in MPlayer. Audio pitch will rise slightly, so if that bothers you, use > an external LADSPA filter to compensate > (see: http://mark.santaniello.net/archives/260). > > The NTSC/PAL speed setting should be handled automatically in the > mplayer.sh script, but have you configured NTSC="false" in > mplayer.sh.conf? Yes. The config should be ok. I don't recall have such a problems with previous version (0.9.x). >> Second one does not play sound from the clip but the sound from the >> channel that was being viewed before playback. > > MPlayer probably has problems with the audio codec used in the clip. > Updating to latest SVN could help. If not, try other players and > identify the audio codec. If the codec should be supported, take a look > at the mplayer -v output and perhaps upload a sample somewhere. Strange that it works fine on the server and both have the same setup of codecs. Have to check further. >> I've tried mplayer.sh 0.8.6 and 0.8.7. mplayer itself is version 1.0rc1. >> Haven't tried trunk version because there did not seem to be fixes >> related to audio or jerkiness. > > Did you actually read through the SVN logs from the last 4 months? > Quite an accomplishment. ;) Anyway, most of the codec-related stuff is > in FFmpeg/libavcodec, which is in a separate repository. Sure.. not :-) No, I just checked the ChangeLog. Checking of all files history would have been extreme.. >> Anyone else with similar problems? >> >> 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. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mplayer does not work properly
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. > >> 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. Niko ___ 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, Morfsta wrote: > What I do not understand and perhaps you could help me with, is that you > say that there is a problem with the firmware, yet there are entries in > the log from VDR > saying that it is dropping x bytes to sync on the next audio frame... > This suggests to me that VDR is doing *something* with respect to audio > synchronisation. Why then is the problem always reported as being an > issue with the firmware? As I tried to explain already, VDR doesn't see the TS packets when you for example just watch live TV on a FF card (i. e. no recording running in background), and the watched channel is available via the FF card. When VDR runs a transfer thread e. g. when a budget card supplies a channel that is to be watched on a FF card or when VDR is recording, then the TS packets travel through cAudioRepacker and sync messages are reported. What happens when e. g. a TS packet gets lost in an audio stream? Consider the following TS packets numbered Tx. An even and an odd numbered packed shall build an audio frame (i. e., the length information at the beginning of an audio packet shall report a length which suits with this assumption) which is stored in a PES packet numbered Pxy: T0 T1 T2 T3 T4 T5 T6 T7 \ / \ / \ / \ / P01 P23 P45 P67 Now assume that T3 gets lost: T0 T1 T2 T4 T5 T6 T7 \ / \ / \ / P01 P24 P67 According to the length information, cAudioRepacker bundles T2 and T4 into PES packet P24. As the tail of this audio packet is incorrect, playing it might result in some noise. cAudioRepacker will go out of sync when reading packet T5 as it doesn't find an audio frame sync marker and starts skipping bytes until it reaches T6. There it finds the audio frame sync marker and reports that syncing skipped some bytes. After that it continues it's work normally. BTW: just in case you have a look at the code, please keep in mind that this explanation has been simplified for clarity -- the real work is done differently. What's the result of the above process? In the error case, you will only get 3 audio packets and moreover, if you simply concat them, you will replay packet P67 at the point in time where the original packet P45 would have been replayed. If one uses the same technique for video packets and frames it is obvious, that audio and video are nolonger in sync with each other. The issue is solved by adding a so called presentation time stamp (PTS) to some PES packets. Let's assume that packet P01 has a PTS of 0 and packet P67 has a PTS of 6. When replaying, the PTS of packet P01 is stored internally and according to the length information of the audio packet, the internal counter is advanced by 2. The next packet P24 doesn't have a PTS value so it is assumed it would have the PTS value of the internal counter which is 2 at that time. This packet is simply output and the internal counter is advanced by 2, resulting in 4. Now, when packet P67 is arriving, a PTS of 6 is read, but the internal counter just shows 4, which means that there is a gap of duration 2 which needs to be filled for example with silence to stay in sync. After that packet P67 is replayed. Keeping audio and video in sync is done by using similar PTS values on both video and audio PES packets. Consider two buffers for decoded audio and video frames. The frames in each buffer were assigned either the PTS value contained in the PES packet or the internally determined PTS value (e. g. in the sample above, for the audio frame in packet P24 a PTS value of 2 was determined). It's now quite easy to replay audio and video in sync by introducing the so called system time counter STC, which shall periodically advance by one -- in the above example starting at 0. To replay audio and video frames in sync, those frames need to be taken from the buffers and presented to the user which have an assigned PTS value less than the current STC value. BTW: this was a simplified explanation how xine manages sync of audio and video while replaying. 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. Please keep in mind that the last paragraph was just a guess -- I do not want to blame anybody with this email. Bye. -- Dipl.-Inform. (FH) Rei
Re: [vdr] writing plugins 101
Simon Baxter a écrit : Hi. Anyone know a good reference on how to write VDR plugins? If you understand french : http://famillejacques.free.fr/vdr/articles/vdr-05/ Jean-Claude ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
