Hi!
The newest firmware for FF cards did not completely fix the AV desync problems for me.
Can you provide a sample recording where A/V sync fails with the current firmware?
Oh, well. Turns out that I had somehow failed to install the new firmware properly. My test patch is possibly not needed at all.
Ville
Ville Rannikko kirjoitti:
Hi!
The newest firmware for FF cards did not completely fix the AV
desync > problems
for me.
Can you provide a sample recording where A/V sync fails with the current firmware?
Oh, well. Turns out that I had somehow failed to install the new firmware properly. My test patch is possibly not needed at all.
I still have experienced AV sync problem with the new fw. The problem is that I can not reproduce the problem. Replaying the video again does not usually give the same result. The sync problem I've experienced with this new fw is just a slight out of sync, less than half a second, but it is noticeable. I can not really say yet how the problem occurs, what are the circumstances. I must check if pausing or jumping causes it or is it something changes in the video. Its nowadays so rare :) I was so used to have it :)
\Kartsa
Ville Rannikko kirjoitti:
Hi!
The newest firmware for FF cards did not completely fix the AV
desync > problems
for me.
Can you provide a sample recording where A/V sync fails with the current firmware?
I was just watching an Idols Extra recorded today and there were multiple out of sync situations that were allways fixed by a 10s backwards jump. I could not see anything in the picture (like periods of black etc.) that would cause this. To make the best of this I should make the whole recording available somewhere because I would not know what to take out of it. And that is not very convenient because of the size of the file.
This is what was in the log if this is at all relevant.
Feb 1 21:20:48 vdr: [2635] replay /srv/vdr/Idols_Extra/2007-02-01.20.59.50.99.rec Feb 1 21:20:59 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:20:59 vdr: [3955] cAudioRepacker(0xC0): skipped 134 bytes to sync on next audio frame Feb 1 21:22:09 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:22:09 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes while syncing on next audio frame Feb 1 21:25:37 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:25:37 vdr: [3955] cAudioRepacker(0xC0): skipped 84 bytes to sync on next audio frame Feb 1 21:26:14 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes to sync on next audio frame Feb 1 21:26:45 vdr: [3955] cAudioRepacker(0xC0): skipped 476 bytes while syncing on next audio frame Feb 1 21:32:45 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:32:45 vdr: [3955] cAudioRepacker(0xC0): skipped 502 bytes while syncing on next audio frame Feb 1 21:34:52 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:34:52 vdr: [3955] cAudioRepacker(0xC0): skipped 232 bytes while syncing on next audio frame Feb 1 21:36:55 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:36:55 vdr: [3955] cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame Feb 1 21:38:06 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:38:06 vdr: [3955] cAudioRepacker(0xC0): skipped 468 bytes while syncing on next audio frame Feb 1 21:40:00 vdr: [2635] timer 22 (5 2059-2140 'Idols Extra') stop
As you can see the recording was on the way as I was watching it.
I've removed two channel events and one ntp event from the log output.
Hi,
Kartsa wrote:
This is what was in the log if this is at all relevant.
Feb 1 21:20:48 vdr: [2635] replay /srv/vdr/Idols_Extra/2007-02-01.20.59.50.99.rec Feb 1 21:20:59 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:20:59 vdr: [3955] cAudioRepacker(0xC0): skipped 134 bytes to sync on next audio frame Feb 1 21:22:09 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:22:09 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes while syncing on next audio frame Feb 1 21:25:37 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:25:37 vdr: [3955] cAudioRepacker(0xC0): skipped 84 bytes to sync on next audio frame Feb 1 21:26:14 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes to sync on next audio frame Feb 1 21:26:45 vdr: [3955] cAudioRepacker(0xC0): skipped 476 bytes while syncing on next audio frame Feb 1 21:32:45 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:32:45 vdr: [3955] cAudioRepacker(0xC0): skipped 502 bytes while syncing on next audio frame Feb 1 21:34:52 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:34:52 vdr: [3955] cAudioRepacker(0xC0): skipped 232 bytes while syncing on next audio frame Feb 1 21:36:55 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:36:55 vdr: [3955] cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame Feb 1 21:38:06 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:38:06 vdr: [3955] cAudioRepacker(0xC0): skipped 468 bytes while syncing on next audio frame Feb 1 21:40:00 vdr: [2635] timer 22 (5 2059-2140 'Idols Extra') stop
As you can see the recording was on the way as I was watching it.
If you can reproduce this behaviour, would you please activate the following line in remux.c:
dsyslog("TS continuity error (%d)", ccCounter);
The cRepacker messages might be a result of lost TS packets, which should be reported by the above line.
Another issue might be, that the audio frames do not contain any length information. Please modify the line
*FrameSize = 0;
in cAudioRepacker::IsValidAudioHeader to
{ *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); }
for getting this situation reported.
Bye.
Reinhard Nissl kirjoitti:
If you can reproduce this behaviour, would you please activate the following line in remux.c:
dsyslog("TS continuity error (%d)", ccCounter);
I will try with the recording if the problem reappears and then activate that line.
The cRepacker messages might be a result of lost TS packets, which should be reported by the above line.
Another issue might be, that the audio frames do not contain any length information. Please modify the line
*FrameSize = 0;in cAudioRepacker::IsValidAudioHeader to
{ *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); }
for getting this situation reported.
Should I do both these changes at the same time or separately?
\Kartsa
I lose sync on live tv as well as recordings and get the following in /var/log/messages.
Feb 3 19:04:18 morfsta vdr: [6714] 1 cRepacker messages suppressed Feb 3 19:04:18 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 584 bytes while syncing on next audio frame Feb 3 19:04:18 morfsta vdr: [3470] 1 cRepacker messages suppressed Feb 3 19:04:18 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 584 bytes while syncing on next audio frame Feb 3 19:04:32 morfsta vdr: [6714] 1 cRepacker messages suppressed Feb 3 19:04:32 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 3 19:04:32 morfsta vdr: [3470] 1 cRepacker messages suppressed Feb 3 19:04:32 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
I made the mods to VDR as you suggested but haven't seen either entry in the log file yet.
I want to try and isolate a recording sample shortly to give to Oliver, but obviously there is nothing I can do about the live sync problem (you're welcome to visit my house if you like!!!)
Regards
Morfsta
On 2/1/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Kartsa wrote:
Should I do both these changes at the same time or separately?
I think you may apply both changes at the same time.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I also applied both of those changes and have not yet seen either of the errors in the log.
I do have thosa same log entrys as morfsta especially if I have more than two recordings going on while I am watching a previous recording.
\Kartsa
Morfsta kirjoitti:
I lose sync on live tv as well as recordings and get the following in /var/log/messages.
Feb 3 19:04:18 morfsta vdr: [6714] 1 cRepacker messages suppressed Feb 3 19:04:18 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 584 bytes while syncing on next audio frame Feb 3 19:04:18 morfsta vdr: [3470] 1 cRepacker messages suppressed Feb 3 19:04:18 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 584 bytes while syncing on next audio frame Feb 3 19:04:32 morfsta vdr: [6714] 1 cRepacker messages suppressed Feb 3 19:04:32 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 3 19:04:32 morfsta vdr: [3470] 1 cRepacker messages suppressed Feb 3 19:04:32 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
I made the mods to VDR as you suggested but haven't seen either entry in the log file yet.
I want to try and isolate a recording sample shortly to give to Oliver, but obviously there is nothing I can do about the live sync problem (you're welcome to visit my house if you like!!!)
Regards
Morfsta
On 2/1/07, *Reinhard Nissl* <rnissl@gmx.de mailto:rnissl@gmx.de> wrote:
Hi, Kartsa wrote: > Should I do both these changes at the same time or separately? I think you may apply both changes at the same time.
Hi,
Kartsa wrote:
I also applied both of those changes and have not yet seen either of the errors in the log.
I do have thosa same log entrys as morfsta especially if I have more than two recordings going on while I am watching a previous recording.
\Kartsa
Morfsta kirjoitti:
I made the mods to VDR as you suggested but haven't seen either entry in the log file yet.
I've just checked remux.c: the c...Repacker messages are logged using esyslog() while the suggested changes use dsyslog().
So either change dsyslog() to esyslog() or check the commandline of VDR whether it includes "-l 3" (log debug messages) and depending on your system setup, debug messages might get logged to a different file.
Bye.
Reinhard Nissl kirjoitti:
I also applied both of those changes and have not yet seen either of the errors in the log.
I do have thosa same log entrys as morfsta especially if I have more than two recordings going on while I am watching a previous recording.
\Kartsa
Morfsta kirjoitti:
I made the mods to VDR as you suggested but haven't seen either entry in the log file yet.
I've just checked remux.c: the c...Repacker messages are logged using esyslog() while the suggested changes use dsyslog().
So either change dsyslog() to esyslog() or check the commandline of VDR whether it includes "-l 3" (log debug messages) and depending on your system setup, debug messages might get logged to a different file.
So I added "-l 3" to my vdr commandline since it was much easier :) Lets see if there starts to be log entrys.
Allthough I did mention earlier having out of sync problems while watching a recording I noticed that if I rewieved the same recording with no other recordings going on there were no sync problems. Also I tried watching the same recording on another vdr over the network there were no sync problems even if there were recordings going on in the source vdr. But as soon as there were recordings going on in the vdr that I was using for watching out of sync started to appear. And I used nfs not streaming.
\Kartsa
Lots of TS Continuity Errors in the messages file.
Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 5 08:26:14 morfsta vdr: [19772] TS continuity error (9) Feb 5 08:29:41 morfsta vdr: [8806] channel 2 (BBC TWO) event Mon 05.02.200708:30-08:40 'Bob the Builder: Project Build It' status 4 Feb 5 08:31:27 morfsta vdr: [19772] TS continuity error (14) Feb 5 08:33:23 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:33:23 morfsta vdr: [19772] TS continuity error (12) Feb 5 08:33:23 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 745 bytes to sync on next audio frame Feb 5 08:39:00 morfsta vdr: [8810] EPGSearch: timer conflict check started Feb 5 08:39:00 morfsta vdr: [8810] EPGSearch: timer conflict check finished Feb 5 08:39:52 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:39:52 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 5 08:40:54 morfsta vdr: [19772] TS continuity error (12) Feb 5 08:40:54 morfsta vdr: [19772] TS continuity error (10)
Regards,
Morfsta
On 2/4/07, Kartsa kari@kniivila.com wrote:
Reinhard Nissl kirjoitti:
I also applied both of those changes and have not yet seen either of
the
errors in the log.
I do have thosa same log entrys as morfsta especially if I have more than two recordings going on while I am watching a previous recording.
\Kartsa
Morfsta kirjoitti:
I made the mods to VDR as you suggested but haven't seen either entry in the log file yet.
I've just checked remux.c: the c...Repacker messages are logged using esyslog() while the suggested changes use dsyslog().
So either change dsyslog() to esyslog() or check the commandline of VDR whether it includes "-l 3" (log debug messages) and depending on your system setup, debug messages might get logged to a different file.
So I added "-l 3" to my vdr commandline since it was much easier :) Lets see if there starts to be log entrys.
Allthough I did mention earlier having out of sync problems while watching a recording I noticed that if I rewieved the same recording with no other recordings going on there were no sync problems. Also I tried watching the same recording on another vdr over the network there were no sync problems even if there were recordings going on in the source vdr. But as soon as there were recordings going on in the vdr that I was using for watching out of sync started to appear. And I used nfs not streaming.
\Kartsa
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Morfsta wrote:
Lots of TS Continuity Errors in the messages file.
Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
Sad to say, I'm happy that this is not a bug in cAudioRepacker.
So what can you do about this TS continuity errors? First of all, this error means that at least one TS packet got lost, most likely by the fact that the card's hardware buffers where overrun. A overrun can happen when for example the kernel is busy with other things and doesn't react to the cards signalling (e. g. IRQ) in time.
Several months ago, I had my PATA harddrive sent in for repair and substituted it by a SATA model. The result was, that I wasn't able to take a single VDR recording on my P4 2.8 GHz without TS continuity errors. When I got the PATA drive back and removed the SATA model, the TS errors were gone.
So I'd say this is a hardware/driver/configuration issue -- but not necessarily in the DVB area. I hope, someone else can give you further hints.
Bye.
Reinhard,
Thanks for your help and description.
Can anyone help me track down what might be the problem? I built my own kernel could a setting there be a problem? What settings are recommended for type of IO scheduler, timer frequency, etc? Anyone else have a similar problem and can recommend a fix?
Cheers,
Morfsta
On 2/5/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Morfsta wrote:
Lots of TS Continuity Errors in the messages file.
Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
Sad to say, I'm happy that this is not a bug in cAudioRepacker.
So what can you do about this TS continuity errors? First of all, this error means that at least one TS packet got lost, most likely by the fact that the card's hardware buffers where overrun. A overrun can happen when for example the kernel is busy with other things and doesn't react to the cards signalling (e. g. IRQ) in time.
Several months ago, I had my PATA harddrive sent in for repair and substituted it by a SATA model. The result was, that I wasn't able to take a single VDR recording on my P4 2.8 GHz without TS continuity errors. When I got the PATA drive back and removed the SATA model, the TS errors were gone.
So I'd say this is a hardware/driver/configuration issue -- but not necessarily in the DVB area. I hope, someone else can give you further hints.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
I have looked into this further. It appears that I only get the TS continuity errors when using my budget DVB-T card to view live TV.. They do not appear when using my FF DVB-S card.
Does this shed any light on things? The DVB-T stream is less robust that DVB-S, but the picture does not generally break up regularly or appear to suffer any major problems. Could it be a problem with my Hauppauge budget DVB-T card?
SWITCH TO SATELLITE CHANNEL: -
Feb 9 10:42:08 morfsta vdr: [25446] switching to channel 166 Feb 9 10:42:08 morfsta vdr: [25446] retuning due to modification of channel 166 Feb 9 10:42:08 morfsta vdr: [25446] switching to channel 166 Feb 9 10:44:47 morfsta vdr: [25446] cleaning up schedules data Feb 9 10:45:00 morfsta vdr: [25540] EPGSearch: timer conflict check started Feb 9 10:45:00 morfsta vdr: [25540] EPGSearch: timer conflict check finished Feb 9 10:51:01 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 10:50-11:00 'Boo!' status 4 Feb 9 11:02:12 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 11:00-11:15 'SMarteenies' status 4 Feb 9 11:09:19 morfsta vdr: [25446] cleaning up id3 cache Feb 9 11:15:00 morfsta vdr: [25540] EPGSearch: timer conflict check started Feb 9 11:15:00 morfsta vdr: [25540] EPGSearch: timer conflict check finished Feb 9 11:17:32 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 11:15-11:45 'Teletubbies' status 4
SWITCH TO FREEVIEW DVB-T CHANNEL: -
Feb 9 11:35:55 morfsta vdr: [25446] switching to channel 1 Feb 9 11:35:57 morfsta vdr: [25536] channel 2 (BBC TWO) event Fri 09.02.2007 11:20-11:40 'Schools: Focus' status 4 Feb 9 11:35:57 morfsta vdr: [25536] channel 1 (BBC ONE) event Fri 09.02.2007 11:00-11:45 'To Buy or Not to Buy' status 4 Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (15) Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (1) Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (9)
I generally only get sync problems on live DVB-T broadcasts (as well as all recordings).
Hope this helps,
Regards,
Morfsta
On 2/5/07, Morfsta morfsta@gmail.com wrote:
Reinhard,
Thanks for your help and description.
Can anyone help me track down what might be the problem? I built my own kernel could a setting there be a problem? What settings are recommended for type of IO scheduler, timer frequency, etc? Anyone else have a similar problem and can recommend a fix?
Cheers,
Morfsta
On 2/5/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Morfsta wrote:
Lots of TS Continuity Errors in the messages file.
Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
Sad to say, I'm happy that this is not a bug in cAudioRepacker.
So what can you do about this TS continuity errors? First of all, this error means that at least one TS packet got lost, most likely by the fact that the card's hardware buffers where overrun. A overrun can happen when for example the kernel is busy with other things and doesn't
react to the cards signalling (e. g. IRQ) in time.
Several months ago, I had my PATA harddrive sent in for repair and substituted it by a SATA model. The result was, that I wasn't able to take a single VDR recording on my P4 2.8 GHz without TS continuity errors. When I got the PATA drive back and removed the SATA model, the TS errors were gone.
So I'd say this is a hardware/driver/configuration issue -- but not necessarily in the DVB area. I hope, someone else can give you further hints.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I haven't got any continuity errors. Atleast not yet after four timered recordings. Also I have not replayed any recording.
\Kartsa
Morfsta kirjoitti:
Lots of TS Continuity Errors in the messages file.
Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 5 08:26:14 morfsta vdr: [19772] TS continuity error (9) Feb 5 08:29:41 morfsta vdr: [8806] channel 2 (BBC TWO) event Mon 05.02.2007 08:30-08:40 'Bob the Builder: Project Build It' status 4 Feb 5 08:31:27 morfsta vdr: [19772] TS continuity error (14) Feb 5 08:33:23 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:33:23 morfsta vdr: [19772] TS continuity error (12) Feb 5 08:33:23 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 745 bytes to sync on next audio frame Feb 5 08:39:00 morfsta vdr: [8810] EPGSearch: timer conflict check started Feb 5 08:39:00 morfsta vdr: [8810] EPGSearch: timer conflict check finished Feb 5 08:39:52 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:39:52 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Feb 5 08:40:54 morfsta vdr: [19772] TS continuity error (12) Feb 5 08:40:54 morfsta vdr: [19772] TS continuity error (10)
Regards,
Morfsta
Reinhard Nissl kirjoitti:
Hi,
Kartsa wrote:
Should I do both these changes at the same time or separately?
I think you may apply both changes at the same time.
Bye.
So I would like to raise this one up again. After applying the two changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still get these lines in log (and -l 3 in vdr startup)
vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on next audio frame
Why does these skipping of bytes appear?
And there still occurs AV sync problem from time to time.
\Kartsa
Hi,
Kartsa wrote:
So I would like to raise this one up again. After applying the two changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still get these lines in log (and -l 3 in vdr startup)
vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on next audio frame
Why does these skipping of bytes appear?
When do you get these lines?
They are OK just after starting a recording or starting transfer mode.
cAudioRepacker tries to suppress this message while initially syncing but as the sync pattern is allowed to appear as audio frame data, it is likely that cAudioRepacker get's in sync by mistake.
After having synced, cAudioRepacker uses the indicated frame length as a guide when looking for the next audio packet. If the sync pattern isn't found at the guided position, it will seek for it and report the number of bytes skipped to find it.
This procedure is executed all over the time and once cAudioRepacker has found a real sync pattern, the indicated frame length will guide cAudioRepacker precisely to the next audio frame.
Bye.
Reinhard Nissl kirjoitti:
Hi,
Kartsa wrote:
So I would like to raise this one up again. After applying the two changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still get these lines in log (and -l 3 in vdr startup)
vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next audio frame vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on next audio frame
Why does these skipping of bytes appear?
When do you get these lines?
They are OK just after starting a recording or starting transfer mode.
cAudioRepacker tries to suppress this message while initially syncing but as the sync pattern is allowed to appear as audio frame data, it is likely that cAudioRepacker get's in sync by mistake.
After having synced, cAudioRepacker uses the indicated frame length as a guide when looking for the next audio packet. If the sync pattern isn't found at the guided position, it will seek for it and report the number of bytes skipped to find it.
This procedure is executed all over the time and once cAudioRepacker has found a real sync pattern, the indicated frame length will guide cAudioRepacker precisely to the next audio frame.
Bye.
Ok, here is a snapshot of my log. There is no replay going during this time but a coupleof recordings are as can be seen. I've stripped channel events.
Feb 18 17:14:00 kari vdr: [2670] timer 3 (6 1714-1754 'Str<F6>ms<F6>') start Feb 18 17:14:00 kari vdr: [2670] record /srv/vdr/Str<F6>ms<F6>/2007-02-18.17.14.50.99.rec Feb 18 17:17:02 kari vdr: [3600] cAudioRepacker(0xC0): skipped 284 bytes while syncing on next audio frame Feb 18 17:19:02 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:19:02 kari vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame Feb 18 17:20:25 kari vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next audio frame Feb 18 17:21:28 kari vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on next audio frame Feb 18 17:22:56 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:22:56 kari vdr: [3600] cAudioRepacker(0xC0): skipped 376 bytes to sync on next audio frame Feb 18 17:23:37 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:23:37 kari vdr: [3600] cAudioRepacker(0xC0): skipped 536 bytes to sync on next audio frame Feb 18 17:26:36 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:26:36 kari vdr: [3600] cAudioRepacker(0xC0): skipped 112 bytes to sync on next audio frame Feb 18 17:27:21 kari vdr: [3600] cAudioRepacker(0xC0): skipped 304 bytes to sync on next audio frame Feb 18 17:30:37 kari vdr: [3600] cAudioRepacker(0xC0): skipped 352 bytes to sync on next audio frame Feb 18 17:34:41 kari vdr: [3600] cAudioRepacker(0xC0): skipped 304 bytes to sync on next audio frame Feb 18 17:38:13 kari vdr: [3600] 2 cRepacker messages suppressed Feb 18 17:38:13 kari vdr: [3600] cAudioRepacker(0xC0): skipped 112 bytes to sync on next audio frame Feb 18 17:39:07 kari vdr: [3600] cAudioRepacker(0xC0): skipped 112 bytes to sync on next audio frame Feb 18 17:40:00 kari vdr: [2670] timer 4 (4 1659-1740 'Teinityt<F6>n kasvatusopas') stop Feb 18 17:40:20 kari vdr: [3600] cAudioRepacker(0xC0): skipped 204 bytes while syncing on next audio frame Feb 18 17:41:00 kari vdr: [2899] EPGSearch: timer conflict check started Feb 18 17:41:00 kari vdr: [2899] EPGSearch: timer conflict check finished Feb 18 17:41:23 kari vdr: [2670] deleting timer 4 (4 1659-1740 'Teinityt<F6>n kasvatusopas') Feb 18 17:41:37 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:41:37 kari vdr: [3600] cAudioRepacker(0xC0): skipped 176 bytes to sync on next audio frame Feb 18 17:43:04 kari vdr: [3600] cAudioRepacker(0xC0): skipped 188 bytes while syncing on next audio frame Feb 18 17:44:33 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:44:33 kari vdr: [3600] cAudioRepacker(0xC0): skipped 300 bytes while syncing on next audio frame Feb 18 17:45:37 kari vdr: [3600] 2 cRepacker messages suppressed Feb 18 17:45:37 kari vdr: [3600] cAudioRepacker(0xC0): skipped 296 bytes to sync on next audio frame Feb 18 17:47:55 kari vdr: [3600] cAudioRepacker(0xC0): skipped 664 bytes to sync on next audio frame Feb 18 17:51:00 kari vdr: [3600] 1 cRepacker messages suppressed Feb 18 17:51:00 kari vdr: [3600] cAudioRepacker(0xC0): skipped 528 bytes to sync on next audio frame Feb 18 17:51:56 kari vdr: [3600] cAudioRepacker(0xC0): skipped 112 bytes to sync on next audio frame Feb 18 17:53:03 kari vdr: [3600] cAudioRepacker(0xC0): skipped 608 bytes to sync on next audio frame Feb 18 17:54:00 kari vdr: [2670] timer 3 (6 1714-1754 'Str<F6>ms<F6>') stop Feb 18 17:55:23 kari vdr: [2670] deleting timer 3 (6 1714-1754 'Str<F6>ms<F6>')
My log is actually full of these.
\Kartsa
Hi,
Kartsa wrote:
My log is actually full of these.
The attached patch adds a TS packet logger to cAudioRepacker, which stores the last 1000 TS packets that led to synchronization of cAudioRepacker into a file to /video.
In your logfile you'll then find lines like the following:
Feb 19 21:41:36 video vdr: [9413] cAudioRepacker(0xC1): skipped 24 bytes to sync on next audio frame Feb 19 21:41:36 video vdr: [9413] cTSLogger: dumping to file '/video/ts_9353_9413_0xC1_000_12_12.log'
Please provide me some of these files which were dumped in the "middle" of a recording. If size matters, you may reduce the number of packets to 100.
Bye.
Hi,
Kartsa wrote:
My log is actually full of these.
The attached patch adds a TS packet logger to cAudioRepacker, which stores the last 1000 TS packets that led to synchronization of cAudioRepacker into a file to /video.
In your logfile you'll then find lines like the following:
Feb 19 21:41:36 video vdr: [9413] cAudioRepacker(0xC1): skipped 24 bytes to sync on next audio frame Feb 19 21:41:36 video vdr: [9413] cTSLogger: dumping to file '/video/ts_9353_9413_0xC1_000_12_12.log'
Please provide me some of these files which were dumped in the "middle" of a recording. If size matters, you may reduce the number of packets to 100.
Bye.
Hi,
Reinhard Nissl wrote:
Please provide me some of these files which were dumped in the "middle" of a recording. If size matters, you may reduce the number of packets to 100.
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
will give you something like the lines below (I've croped the long lines here for readability). Just have a look a the marked column:
v v 02d06c 47 02 94 13 24 84 c0 8b 02d128 47 02 94 14 44 91 b9 1b 02d1e4 47 02 94 15 a5 ab ab a1 02d2a0 47 02 94 16 40 b4 0c c2 02d35c 47 02 94 17 5d c5 6b 5f 02d418 47 02 94 18 72 5c 3e 84 02d4d4 47 02 94 19 05 81 b4 7e 02d590 47 02 94 1a 95 ba dc 2c 02d64c 47 02 94 1b 86 86 fe 12 02d708 47 02 94 1c 2b 22 a6 d9 02d7c4 47 02 94 1d b9 b5 e2 6d 02d880 47 02 94 1e e4 6e 11 17 02d93c 47 02 94 1f 90 00 00 00 02d9f8 47 02 94 10 ca 1b 20 ed 02dab4 47 02 94 11 55 d5 c6 73 02db70 47 02 94 10 e8 69 4d 5a 02dc2c 47 02 94 11 d8 e5 9a 69 02dce8 47 02 94 12 ac 2a 65 ba 02dda4 47 02 94 13 62 35 d1 c4 02de60 ^ ^
This nibble represents the TS continuity counter. It cycles properly from 0 to 9 and a to f throughout the file. But near the end the following sequence appears:
e f 0 1 . . . . . . . . . . . . . . 0 1 2 3
The dot's indicate at least the missing TS packets with counter values:
_ _ _ _ 2 3 4 5 6 7 8 9 a b c d e f _ _ _ _
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
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
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).
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. But when you start a recording for example on a single FF card system, TS packets will then be sent to VDR for the recording and for live TV, so if you continue to watch the recorded channel, you'll typically get the cRepacker messages twice for different threads.
Bye.
OK, so Karsta and I are suffering dropped TS packets. I know for sure that my DVB-T signal is not perfect so it is likely to occasionally lose some TS packets (freeview in the UK is susceptible to all sorts of interference from cars, motorbikes, DECT, etc) however, saying there is nothing that we can do about this because you don't have a *perfect* DVB signal surely isn't the right answer! My TV copes perfectly well with dropped packets and doesn't go out of sync, as does my freeview box. Surely if some TS packets are dropped this shouldn't result in a loss of sync, the system should resync the audio and continue as before?? It can't be right to say, well we lost some data, so we can't recover until you change channels up and down, or fastforward/rewind by 1 minute!
I have spent the last 2 weeks trying different combinations, playing with my kernel settings, trying USB DVB-T devices rather than the PCI and it makes absolutely no difference. The TS continuity errors do not go away so I am convinced it is simply that DVB-T is not as robust as other signals such as DVB-S or DVB-C. However, VDR should be able to cope and resync with lost data.
Regards,
Morfsta
Hi,
Morfsta wrote:
OK, so Karsta and I are suffering dropped TS packets. I know for sure that my DVB-T signal is not perfect so it is likely to occasionally lose some TS packets (freeview in the UK is susceptible to all sorts of interference from cars, motorbikes, DECT, etc) however, saying there is nothing that we can do about this because you don't have a *perfect* DVB signal surely isn't the right answer! My TV copes perfectly well with
Well, what I wanted to say is that I cannot help you any further at this point. You have to check your hardware/driver whether there is a chance to minimize packet loss. You did this already as you wrote below -- fine.
dropped packets and doesn't go out of sync, as does my freeview box. Surely if some TS packets are dropped this shouldn't result in a loss of sync, the system should resync the audio and continue as before?? It can't be right to say, well we lost some data, so we can't recover until you change channels up and down, or fastforward/rewind by 1 minute!
You are right -- but don't you think that this thread got a bit off topic? I've replied in this thread because there were cAudioRepacker messages and as I've contributed this code to VDR I just wanted to make sure that it works correctly in this case. Let's now come back to the topic and concentrate on the AV sync issue.
I have spent the last 2 weeks trying different combinations, playing with my kernel settings, trying USB DVB-T devices rather than the PCI and it makes absolutely no difference. The TS continuity errors do not go away so I am convinced it is simply that DVB-T is not as robust as other signals such as DVB-S or DVB-C. However, VDR should be able to cope and resync with lost data.
Well, basically this is not a matter of VDR but of the FF card's firmware. For example, I do not own a FF card and do not see this AV sync issue with xine, even when I intentionally drop TS packets by the attached patch.
I'd like users of FF cards to test this patch. If this triggers AV sync issues, firmware developers are invited to fix this issue.
Feel free to modify this patch to better simulate real TS packet losses like bursts of 16 frames.
BE WARNED: *** do not use this patch on a production system ***
Bye.
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
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.
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
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 werner@suse.de 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.
On Thu, Feb 22, 2007 at 06:18:11PM +0000, Morfsta wrote:
Hi Werner,
Any idea when you will be able to release the new firmware for testing?
I'm just testing the stuff in real live on my productions system ;) Knock on wood that this stays stable ...
Werner
Hi Werner,
Were there problems?
Morfsta
On 2/23/07, Dr. Werner Fink werner@suse.de wrote:
On Thu, Feb 22, 2007 at 06:18:11PM +0000, Morfsta wrote:
Hi Werner,
Any idea when you will be able to release the new firmware for testing?
I'm just testing the stuff in real live on my productions system ;) Knock on wood that this stays stable ...
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
On Sun, Mar 04, 2007 at 12:42:11PM +0000, Morfsta wrote:
Hi Werner,
Were there problems?
Beside a small problem of Video underruns during change from AC3 to Mpeg-Audio and at the start of a replay, I see no problems. At least the problem with broken Mpeg-Audio frames are gone. Hopefully I've something ready at this evening :^)
Werner
On 2/23/07, Dr. Werner Fink werner@suse.de wrote:
On Thu, Feb 22, 2007 at 06:18:11PM +0000, Morfsta wrote:
Hi Werner,
Any idea when you will be able to release the new firmware for testing?
I'm just testing the stuff in real live on my productions system ;) Knock on wood that this stays stable ...
Werner
On 3/7/07, Dr. Werner Fink werner@suse.de wrote:
AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958
German language howtos are useless to all us english-speaking vdr users (and there are a LOT of us!). Perhaps someone can bother to translate.
Thanks.
VDR User wrote:
On 3/7/07, *Dr. Werner Fink* <werner@suse.de mailto:werner@suse.de> wrote:
AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 <http://www.vdr-portal.de/board/thread.php?threadid=1958>German language howtos are useless to all us english-speaking vdr users (and there are a LOT of us!). Perhaps someone can bother to translate.
Thanks.
how about this
http://www.linuxtv.org/vdrwiki/index.php/Bitstreamout-plugin
Hi Werner and List, On Mi, Mär 07, 2007 at 04:36:12 +0100, Dr. Werner Fink wrote:
Beside a small problem of Video underruns during change from AC3 to Mpeg-Audio and at the start of a replay, I see no problems. At least the problem with broken Mpeg-Audio frames are gone. Hopefully I've something ready at this evening :^)
Is this the mentioned firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
What is the current status of the dvb firmware? Are you planning to release a new version? BR. Halim
On Sat, Mar 15, 2008 at 03:12:49PM +0100, Halim Sahin wrote:
Hi Werner and List, On Mi, Mär 07, 2007 at 04:36:12 +0100, Dr. Werner Fink wrote:
Beside a small problem of Video underruns during change from AC3 to Mpeg-Audio and at the start of a replay, I see no problems. At least the problem with broken Mpeg-Audio frames are gone. Hopefully I've something ready at this evening :^)
Is this the mentioned firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
What is the current status of the dvb firmware? Are you planning to release a new version?
I'm currently very busy with my little daughter most free time but I'm also working on the firmware. It has taken some time and will take some time.
Werner
On Mon, Mar 17, 2008 at 6:19 AM, Dr. Werner Fink werner@suse.de wrote:
I'm currently very busy with my little daughter most free time but I'm also working on the firmware. It has taken some time and will take some time.
This is why it's a shame more people aren't allowed to help code. The problem could have been solve years ago. Well at least we should be thankful Werner does any work at all because otherwise all hope would be dead.
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.
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
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
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
-
Dr. Werner Fink -
Halim Sahin -
Kartsa -
Lars Bläser -
Morfsta -
Reinhard Nissl -
VDR User -
Ville Rannikko