Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings, I was thinking about what could be done. As of now, I have been using xine with my FF card to fix the problem. But, if I use xine, then even live tv is played back over software. The problem was never with live tv, only playing back recordings. What if the mplayer plugin was modified to replace the default vdr playback for recordings. It currently works as is, but it has problems with split files (ie; 001.vdr, 002.vdr, etc.). Also, it would be nice if there was an option to replace the default playback in vdr for recordings (so we wouldnt have to select the mplayer plugin first every time). Just a suggestion, but using mplayer over mpegpes would definitely be a better solution for fixing the a/v desync instead of having to use xine for everything (since there never was a problem with live tv).
Best Regards.
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
Klaus
On 20.10.2006 15.09, "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
Well here in Finland the channels at least where I've seen this to happen are two commercial channels (MTV3 and Nelonen). I don't remember seeing those problems with non-commercial channels (YLE's channels).
The a/v sync problems usually occur when commercial break ends and program continues. But it happens also in the spots where there has been commercial break in the original broadcast but not in here.
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I preserved an example clip of this with length of 3 minutes and there is four desync spots in it. So it is not directly related to commercial breaks. I think this happens almost on every recording made from these two channels.
Audio is normal MPEG.
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards.
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
Cheers,
Udo
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards.
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
This theory sounds reasonable. Any idea on a way to fix it? The biggest question is if it can be fixed from within VDR's source code or if it would require an additional firmware/driver revision. I have given up hope on it. The only way I know of that is reliable is using software decoding.
Best Regards.
C.Y.M wrote:
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards.
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
This theory sounds reasonable. Any idea on a way to fix it? The biggest question is if it can be fixed from within VDR's source code or if it would require an additional firmware/driver revision. I have given up hope on it. The only way I know of that is reliable is using software decoding.
But, the biggest question is.. why does the ONLY happen when playing back recordings??
Best Regards.
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards.
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
Does it also occur with the latest test firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
If yes, please provide short sample clips. Please verify that the clips are not damaged, i.e. they play fine with mplayer or xine.
Oliver
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
Does it also occur with the latest test firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
If yes, please provide short sample clips. Please verify that the clips are not damaged, i.e. they play fine with mplayer or xine.
Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with.
Best Regards.
On 21 Oct 2006, at 20:22, C.Y.M wrote:
Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with.
Could anyone with this problem see if they have high cpu utilization in the dvbplayer.c thread when the sync problems occur?
Torgeir Veimo wrote:
On 21 Oct 2006, at 20:22, C.Y.M wrote:
Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with.
Could anyone with this problem see if they have high cpu utilization in the dvbplayer.c thread when the sync problems occur?
Are you thinking that mplayer might be dropping bad frames more efficiently than VDR? Is it possible that VDR is not dropping the bad frames properly, thus causing dvbplayer.c to struggle when processing/forwarding the video to the FF DVB card? This is the command used when playing back DVB compliant VDR recordings to a FF card with mplayer:
mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr
Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem.
Best Regards.
On 10/22/06, C.Y.M syphir@syphir.sytes.net wrote:
Are you thinking that mplayer might be dropping bad frames more efficiently than VDR? Is it possible that VDR is not dropping the bad frames properly, thus causing dvbplayer.c to struggle when processing/forwarding the video to the FF DVB card? This is the command used when playing back DVB compliant VDR recordings to a FF card with mplayer:
mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr
Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem.
Best Regards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Certainly I think the problem is that VDR is not properly doing sync, especially with DVB transmissions that are prone to error (e.g. DVB-T). I have tried virtually all of the hotplug firmwares and followed the DVB CVS driver for the last few months and it doesn't make any difference. I also use the cards digital output as well as the analogue out and it doesn't make any difference there is always sync problems, especially after a glitch in the stream. I think that VDR should regularly check and resync the audio to the video, if it doesn't already. If it does, then there is a problem in the process as it gets it wrong.
Regards,
Morfsta
Morfsta wrote:
Certainly I think the problem is that VDR is not properly doing sync,
In a way, I agree. VDR does not sync at all. Never.
Simplified, here's what the VDR playback really does:
- Read data from file in frame-sized chunks into read buffers - If the DVB driver accepts data, read a frame from buffers - Filter the PES packets for current video and audio track - Write the packets into the DVB device.
Thats all. VDR just delivers the data stream as fast as the DVB device accepts it. The DVB devices do all the syncing and timing.
And thats why I think that this is a firmware issue, not a VDR issue, simply because VDR does almost nothing to the video.
Cheers,
Udo
In 453B6F89.5090104@gmx.de, Udo Richter wrote:
Thats all. VDR just delivers the data stream as fast as the DVB device accepts it. The DVB devices do all the syncing and timing.
And thats why I think that this is a firmware issue, not a VDR issue, simply because VDR does almost nothing to the video.
But didn't the people experiencing the problem say it works OK with mplayer, but not VDR, everything else being equal? So perhaps the problem is that VDR isn't doing anything whereas mplayer can detect potential problems and alter the stream somehow?
I would suspect that the problem streams have the packets interleaved with quite a lot of delay between the video and audio. Normally a decoder should be able to correct that by reading PTS etc, but perhaps if VDR just feeds the stream as it encounters it to the DVB card it overwhelms its buffers whereas mplayer does its own buffering beforehand and presents packets to the decoder with the audio packets much closer to the video packets with the same PTS.
Adding my 2 cents, in the hope that others more knowledgable may be able to reproduce the problem.
Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio sync when doing multiple "yellow button skips" to jump through commercial breaks, where there is a 30-50% chance the audio will be out after this. Doing a "green button skip" backwards almost always corrects it.
Regards,
Richard
Richard Scobie wrote:
Adding my 2 cents, in the hope that others more knowledgable may be able to reproduce the problem.
Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio sync when doing multiple "yellow button skips" to jump through commercial breaks, where there is a 30-50% chance the audio will be out after this. Doing a "green button skip" backwards almost always corrects it.
hear, hear, same here.
I am sure this is more widespread than people imagine. I know that everyone I talk to has this issue. But most don't participate on the ML. There are forums that have talked bout it all over. Most of us have just as said, gotten used to it and assumed it will never be addressed. So I too am glad to see it being discussed once again, and do hope there can be a resolution. I wish I understood more about how it all pieced together to help.
Lauri Tischler wrote:
Richard Scobie wrote:
Adding my 2 cents, in the hope that others more knowledgable may be able to reproduce the problem.
Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio sync when doing multiple "yellow button skips" to jump through commercial breaks, where there is a 30-50% chance the audio will be out after this. Doing a "green button skip" backwards almost always corrects it.
hear, hear, same here.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Chad Flynt wrote:
I am sure this is more widespread than people imagine. I know that everyone I talk to has this issue. But most don't participate on the ML. There are forums that have talked bout it all over. Most of us have just as said, gotten used to it and assumed it will never be addressed. So I too am glad to see it being discussed once again, and do hope there can be a resolution. I wish I understood more about how it all pieced together to help.
The problem seems extra prevalent when watching cartoons. I would assume that many of the frames are repeated the same during the voice over and because they're using "stack" compression, they won't send any empty (null) frames. This is why the A/V desync is so terrible whenever I try to watch the Simpsons.
Best Regards.
C.Y.M wrote:
mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr
Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem.
Definitely not just that. My playback issue already disappears when using the most simple command line: mplayer -vo mpegpes -ao mpegpes 001.vdr.
And just for completeness: No serious CPU load when playing back with VDR or mplayer.
Cheers,
Udo
Udo Richter wrote:
C.Y.M wrote:
mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr
Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem.
Definitely not just that. My playback issue already disappears when using the most simple command line: mplayer -vo mpegpes -ao mpegpes 001.vdr.
And just for completeness: No serious CPU load when playing back with VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end.
Thanks everyone for chiming in on this one. I really hope that this time we can stop passing the buck and just git'r done. :)
Best Regards.
On 22 Oct 2006, at 22:33, C.Y.M wrote:
And just for completeness: No serious CPU load when playing back with VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end.
The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try.
Torgeir Veimo wrote:
On 22 Oct 2006, at 22:33, C.Y.M wrote:
And just for completeness: No serious CPU load when playing back with VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end.
The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try.
I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card.
Best Regards.
On 22 Oct 2006, at 22:56, C.Y.M wrote:
Torgeir Veimo wrote:
On 22 Oct 2006, at 22:33, C.Y.M wrote:
And just for completeness: No serious CPU load when playing back with VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end.
The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try.
I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card.
I wasn't talking about using different decoding software, I was talking about trying some other piece of code thant dvbplayer.c to read the recording from disk and feeding the hardware decoder. The softplay plugin is such a different playback mechanism (but I can't guarrantee that it works with an FF card). My thesis is that there are issues with dvbplayer.c, which only show under certain circumstances. One such ciscumstance is using a budget card with softdevice playback of recordings, and a powerfull cpu.
C.Y.M wrote:
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
Does it also occur with the latest test firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
If yes, please provide short sample clips. Please verify that the clips are not damaged, i.e. they play fine with mplayer or xine.
Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with.
Best Regards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
It can't be a firmware issue at all if Mplayer and VDR are both using the same firmware, and 1 works and the other doesn't, to me that completely rules out the firmware.
On 21.10.2006 15.58, "Oliver Endriss" o.endriss@gmx.de wrote:
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards.
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate.
Does it also occur with the latest test firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2
If yes, please provide short sample clips. Please verify that the clips are not damaged, i.e. they play fine with mplayer or xine.
Oliver
Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar
80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
Tero Siironen wrote:
Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar
80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
I've checked your recording. Lost "The other 48 days" - surely one of the worst episodes for me too, because the fade-to-black on every day break.
Your recording however runs relatively fine on my FF (r1.6 firmware f22623) card. There's noticeable audio stuttering after the fade-to-black scenes, but audio desync is only small, though noticeable.
Demultiplexing with ProjectX throws 11649 of errors like this:
!> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / true / false)
pos is changing, the rest seems always the same.
I then re-muxed the elementary streams and converted them back to VDR, and the resulting video played fine again. So this issue seems to be some problem on the PES packaging layer.
In contrast, my recording issue cannot be fixed by re-muxing, and has more noticeable audio desync, its probably a totally different issue. The dev's already have a sample file.
Cheers,
Udo
Udo Richter wrote:
Tero Siironen wrote:
Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar
80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
I've checked your recording. Lost "The other 48 days" - surely one of the worst episodes for me too, because the fade-to-black on every day break.
Your recording however runs relatively fine on my FF (r1.6 firmware f22623) card. There's noticeable audio stuttering after the fade-to-black scenes, but audio desync is only small, though noticeable.
Demultiplexing with ProjectX throws 11649 of errors like this:
!> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / true / false)
pos is changing, the rest seems always the same.
I then re-muxed the elementary streams and converted them back to VDR, and the resulting video played fine again. So this issue seems to be some problem on the PES packaging layer.
In contrast, my recording issue cannot be fixed by re-muxing, and has more noticeable audio desync, its probably a totally different issue. The dev's already have a sample file.
It is postulated that vdr takes whatever it gets and shoves it into the playback buffers of the a/v decoder in whatever order it is in. In live TV this is rate-limited meaning the clocking source is the network and the network transmits at whatever rate it needs to and the decoder decodes it. So, let us say that time is "x". If video is transmitted faster than rate "x", and audio also is transmitted faster than time "x", then we get a xrun. I think that's understood. But, if video is transmitted faster, then slower, then faster, then slower etc, but drifts around time "x", and is not sent to the decoder at any other speed than "x", then the decoder gets a constant smooth stream. Because if it takes x+3 ms to play something, the input stream on livetv won't overfill its buffer because the next run will be x-3 ms and so the extra time is made up. This is very easily seen with variable framerates and bitrates. Audio also might be doing the same thing, where it send at spurts rather than a steady stream. Now if audio and video are both spurting along, where do you find a common time?
IRL, time is constant. But on playback if vdr doesn't clock its data, then desync is quite possible. For example, if there's nothing to "change" for a few video frames, because they're using "stack" compression they won't send an empty frame. So, consider this blackout time in "Lost". The theory is that problems are occurring because they're not sending empty null frames. Also, if they're clocking on video, not audio. You will get your sync problems because you're missing bits. Does VDR store the pcr pid in the recordings? Is the pcr used during playback to clock the data?
Best Regards.
C.Y.M wrote:
IRL, time is constant. But on playback if vdr doesn't clock its data, then desync is quite possible. For example, if there's nothing to "change" for a few video frames, because they're using "stack" compression they won't send an empty frame. So, consider this blackout time in "Lost". The theory is that problems are occurring because they're not sending empty null frames. Also, if they're clocking on video, not audio.
Out of curiosity, I've tried recording one of these flirt phone ad channels, that only send still pictures at extremely low data rates. Playback seemed to be fine more or less, though a/v sync is hard to notice there. The recording length and the video playback speed was more or less correct however.
Another hint: If frames are completely missing in the recording, they also don't account for VDR's absolute recording position and recording length. If there are enough of them, this should be noticeable.
Does VDR store the pcr pid in the recordings? Is the pcr used during playback to clock the data?
Recordings are pure PES packet sequences of video and audio PES packets. PCR is not recorded. On playback, the PES packets are forwarded to the DVB driver without further modification. IMHO the playback sync only uses the PTS of the PES packets, however thats just guessing.
I'm not sure if the PES repacker does anything on recording or if PCR is used only on live. There are not much German channels with PCR on Astra anyway.
(look for VPID with nnn+nnn form in channels.conf)
Cheers,
Udo
Recordings are pure PES packet sequences of video and audio PES packets. PCR is not recorded. On playback, the PES packets are forwarded to the DVB driver without further modification. IMHO the playback sync only uses the PTS of the PES packets, however thats just guessing.
If PCR is ignored that violates spec. If frames are missing, I would consider that a pretty huge bug.
I'm not sure if the PES repacker does anything on recording or if PCR is used only on live. There are not much German channels with PCR on Astra anyway.
(look for VPID with nnn+nnn form in channels.conf)
Best Regards.
Udo Richter wrote:
Demultiplexing with ProjectX throws 11649 of errors like this:
!> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / true / false)
pos is changing, the rest seems always the same.
This message is always displayed when the ttxtsubtitles plugin is installed. But I had this problems also far before I re-setup my VDR with the subtitles plug-in (see my other post).
Jörg
Udo Richter wrote:
Tero Siironen wrote:
Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar
80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
Demultiplexing with ProjectX throws 11649 of errors like this: !> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / true / false) pos is changing, the rest seems always the same.
I then re-muxed the elementary streams and converted them back to VDR, and the resulting video played fine again. So this issue seems to be some problem on the PES packaging layer.
I've done some more analysis on the file using dvbsnoop and checked the PES packet timings. Audio frame packets are present every 24ms, video packets are present every 40ms. All packets are present, no packets dropped. So much for stacked frames, at least on the PES layer every frame is present.
In the stream, the audio packets are ahead of the video packets, on average by 470ms. (min: 137ms, max: 905ms.) This seems to be well inside the tolerance that the DVB driver can handle.
The only disturbance I've noticed is a slight jitter in the PTS values of the audio packets, they are sometimes off by +/- 1, thats 0.01ms. I don't know whether the driver ignores such slight offsets, but I guess it probably does, esp. since it seems to never sync anyway.
Cheers,
Udo
Udo Richter wrote:
Udo Richter wrote:
Tero Siironen wrote:
Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar
80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
The only disturbance I've noticed is a slight jitter in the PTS values of the audio packets, they are sometimes off by +/- 1, thats 0.01ms. I don't know whether the driver ignores such slight offsets, but I guess it probably does, esp. since it seems to never sync anyway.
So much for that theory. I've wrote an experimental patch to VDR to fix this specific stream, but playback is the same, even with the fixed PTS jitter. :(
Cheers,
Udo
First, I too want to express my gratitude & appreciation towards the people actively persuing a once & for all fix to this problem! So what about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists? It seems that the majority opinion is this is in fact a vdr issue rather than a firmware issue but whats the opinion of the person who develops the firmware (if anyone knows)?
On 11/12/06, Udo Richter udo_richter@gmx.de wrote:
Udo Richter wrote: So much for that theory. I've wrote an experimental patch to VDR to fix this specific stream, but playback is the same, even with the fixed PTS jitter. :(
Cheers,
Udo
VDR User wrote:
about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists?
I don't think that it is that easy. Its just educated guessing, but I assume that the mpeg data is going a long way through the mplayer core, through demultiplexers, resyncers, multiplexers, playback control and lots of more stuff. Thats probably several thousand lines of code that need to be reviewed, rewritten and integrated into VDR. Thats a huge task, and its probably easier to re-implement every step mplayer does in VDR from scratch.
It seems that the majority opinion is this is in fact a vdr issue rather than a firmware issue
Once again, I don't agree. VDR does almost nothing on playback. VDR recordings are streams of PES packets, and the DVB driver accepts PES packets for playback. The only thing VDR does is to drop video packets into the video interface and audio packets into the audio interface.
(If there wouldn't be the need to separate video from audio, you could probably simply do cat 001.vdr > /dev/dvb/adaper0/video0 and it would play.)
Cheers,
Udo
Tero Siironen wrote:
On 20.10.2006 15.09, "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
Well here in Finland the channels at least where I've seen this to happen are two commercial channels (MTV3 and Nelonen). I don't remember seeing those problems with non-commercial channels (YLE's channels).
The a/v sync problems usually occur when commercial break ends and program continues. But it happens also in the spots where there has been commercial break in the original broadcast but not in here.
However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I preserved an example clip of this with length of 3 minutes and there is four desync spots in it. So it is not directly related to commercial breaks. I think this happens almost on every recording made from these two channels.
Audio is normal MPEG.
I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards. My guess is that it is firmware/driver related. But, since only a handful of people have the source code to the firmware, it is virtually impossible to fix. we could work around it by using mplayer with mpegpes to playback the problematic recordings and live tv is never an issue. I would just like another way of playing back the recordings in VDR w/o having to rely on the firmware of the FF card that nobody can fix.
Best Regards.
C.Y.M wrote:
... [ problem with A/V desync ] I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards.
I'm not sure what you mean here. Budget cards can't replay, so it's clear that this problem can't happen with them.
Or are you saying that this only happens with recordings made from FF cards, and not with recordings made from budget cards? Both, of course, replayed via a FF card.
Klaus
Klaus Schmidinger wrote:
C.Y.M wrote:
... [ problem with A/V desync ] I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards.
I'm not sure what you mean here. Budget cards can't replay, so it's clear that this problem can't happen with them.
Or are you saying that this only happens with recordings made from FF cards, and not with recordings made from budget cards? Both, of course, replayed via a FF card.
What I was trying to say is that the recordings are not damaged. They seem to playback fine with a software decoder on both FF and budget cards. I think that Udo has brought up a very good point about why mplayer is "immune" to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card.
BR.
C.Y.M wrote:
Klaus Schmidinger wrote:
C.Y.M wrote:
... [ problem with A/V desync ] I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards.
I'm not sure what you mean here. Budget cards can't replay, so it's clear that this problem can't happen with them.
Or are you saying that this only happens with recordings made from FF cards, and not with recordings made from budget cards? Both, of course, replayed via a FF card.
What I was trying to say is that the recordings are not damaged. They seem to playback fine with a software decoder on both FF and budget cards.
There you go again: a software decoder *can't* replay "on a budget card". This is just nonsense (sorry, no offense).
I think that Udo has brought up a very good point about why mplayer is "immune" to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card.
What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know what to do differently - but apparenty mplayer does some magic, so if this can be found out, it might help.
Klaus
Klaus Schmidinger wrote:
C.Y.M wrote:
Klaus Schmidinger wrote:
C.Y.M wrote:
... [ problem with A/V desync ] I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards.
I'm not sure what you mean here. Budget cards can't replay, so it's clear that this problem can't happen with them.
Or are you saying that this only happens with recordings made from FF cards, and not with recordings made from budget cards? Both, of course, replayed via a FF card.
What I was trying to say is that the recordings are not damaged. They seem to playback fine with a software decoder on both FF and budget cards.
There you go again: a software decoder *can't* replay "on a budget card". This is just nonsense (sorry, no offense).
OK, I understand what you are saying because nothing outputs through a budget card. What I meant to say is that a recording from a budget card and a recording from a FF card both play the same when using a software decoder such as xine.
I think that Udo has brought up a very good point about why mplayer is "immune" to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card.
What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know what to do differently - but apparenty mplayer does some magic, so if this can be found out, it might help.
ACK. I hope that someone who understands the mpegpes code in mplayer can shed some light on this. What kind of repacking is mplayer doing that fixes this problem. It is definitely not transcoding the video. All it is doing is forwarding the video to the dvb card via mpegpes.
Best Regards.
On 21 Oct 2006, at 11:36, C.Y.M wrote:
I think that Udo has brought up a very good point about why mplayer is "immune" to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card.
What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know what to do differently - but apparenty mplayer does some magic, so if this can be found out, it might help.
ACK. I hope that someone who understands the mpegpes code in mplayer can shed some light on this. What kind of repacking is mplayer doing that fixes this problem. It is definitely not transcoding the video. All it is doing is forwarding the video to the dvb card via mpegpes.
Maybe this is related to a problem encountered with too fast processors and recording playback on softdevice? The problem seems to be too much processor time being spent in dvbplayer.c, resulting in frame dropouts every other second.
I am sure it has something to do with North American systems, it happens with regular or AC3 audio. And doesn't seem to matter on the channel. Doesn't affect live at all just on playback. And as mentioned, if you use Mplayer or such all is fine. Only if you are playing back via the default VDR playback through the card. The fix is always to rewind just a sec and start playing again and usually you are good, till the next desync heh.
Klaus Schmidinger wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
I also have A/V desyncs. This is with one TT-DVB-T (and a TT-DVB-C, most of the time we record and watch via the DVB-T card).
In most cases it is bad reception. Pausing and restarting the video fixes it - most of the time - but sometimes I have to switch back to live TV and restart the video.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
There is no AC3 involved - just plain replay via FBAS and audio out of the TT card.
Cheers, Juri
Juri Haberland wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
I also have A/V desyncs. This is with one TT-DVB-T (and a TT-DVB-C, most of the time we record and watch via the DVB-T card).
In most cases it is bad reception. Pausing and restarting the video fixes it - most of the time - but sometimes I have to switch back to live TV and restart the video.
Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3?
There is no AC3 involved - just plain replay via FBAS and audio out of the TT card.
The A/V desync problem would not be so critical if it corrected itself with some type of time code. In fact, even playing bad recordings back with some kind of software decoder can give you a desync once in a while, but the difference is that the software method fixes the desync automatically (without having to fast forward or rewind to the next GOP). Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format. The CPU usage would be very minimal and I would not need to install X-windows or some type of framebuffer. I am just talking about regular MPEG audio/video. It doesn't seem like it would "that" hard to modify the mplayer plugin for just this purpose. In fact, it already works. But there are a few minor issues with it.
1) Mplayer can not get the correct seek time when playing back VDR recordings for some reason (causing the time bar to show incorrect values). 2) Mplayer can not handle playing back split files (ie; 001.vdr, 002.vdr). As of now each one must be selected individually. 3) Sometimes when playing back a video with mplayer (using only a single FF card in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So, if a timer should happen to go off in VDR while you are playing back a video with mplayer, VDR will crash when attempting to start recording with the timer.
Best Regards.
C.Y.M wrote:
Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format.
This leaves the question: If the video is already in DVB compatible mpeg2 format, what does mplayer do before forwarding the data stream to the DVB card, that VDR does not? Basically, VDR just forwards the whole data stream to the DVB driver. If mplayer is immune against stream desyncing, then they must do some repacking/fixing to the data stream that helps the DVB hardware on decoding.
- Mplayer can not get the correct seek time when playing back VDR recordings
for some reason (causing the time bar to show incorrect values).
For proper seeking, a program must be able to read the index.vdr file. Everything else is educated guessing.
- Sometimes when playing back a video with mplayer (using only a single FF card
in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So, if a timer should happen to go off in VDR while you are playing back a video with mplayer, VDR will crash when attempting to start recording with the timer.
Only one program can use the DVB card. And if mplayer uses it, then VDR cannot.
Cheers,
Udo
Udo Richter wrote:
C.Y.M wrote:
Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format.
This leaves the question: If the video is already in DVB compatible mpeg2 format, what does mplayer do before forwarding the data stream to the DVB card, that VDR does not? Basically, VDR just forwards the whole data stream to the DVB driver. If mplayer is immune against stream desyncing, then they must do some repacking/fixing to the data stream that helps the DVB hardware on decoding.
If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmmmmmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :) This has been back and forth for a long long time with the drivers development team and Klaus. hehe.
Best Regards.
C.Y.M wrote:
If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmmmmmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :)
I wouldn't go that far. For this concrete case, since it is limited to one specific channel, there's a good chance that the encoding of the channel breaks some standards limitation. There's also most likely nothing wrong on VDR, as VDR is basically just forwarding data streams. If mplayer does a better job, then its probably more like a bug workaround. Generally, things would be a lot better if the driver/firmware would do A/V resyncing constantly and not just at playback start. That way, A/V desync wouldn't built up, and desync would only happen for a short time.
Cheers,
Udo
Udo Richter wrote:
C.Y.M wrote:
If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmmmmmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :)
I wouldn't go that far. For this concrete case, since it is limited to one specific channel, there's a good chance that the encoding of the channel breaks some standards limitation. There's also most likely nothing wrong on VDR, as VDR is basically just forwarding data streams. If mplayer does a better job, then its probably more like a bug workaround. Generally, things would be a lot better if the driver/firmware would do A/V resyncing constantly and not just at playback start. That way, A/V desync wouldn't built up, and desync would only happen for a short time.
How come you make the conclusion that this is limited to one specific channel? To my understanding there are multiple channels where this problem occurs.
The best to start solving this problem is to try to figure out what happens with the recordings that are correct but still cause desync problems. This has been suggested already by many readers. Since it seems that only few people have access to the firmware source code the debugging is quite limited..
Br, Pasi
Pasi Juppo wrote:
How come you make the conclusion that this is limited to one specific channel? To my understanding there are multiple channels where this problem occurs.
Just talking about the case that I've reported. I experience such issues only very rarely, and mostly related to bad reception. The reported issue related to blackness is very specific to this channel.
Cheers,
Udo
Udo Richter wrote:
Just talking about the case that I've reported. I experience such issues only very rarely, and mostly related to bad reception. The reported issue related to blackness is very specific to this channel.
Do you mean that this is e.g. just related to ATV+? Does Lost on ProSieben play without problems? This problems also appeared with 24 from ATV+ (also black fades on counter jumps). Anybody commenting if there are also problems with 24 recordings from RTL2?
I can also see some sync problems e.g. when I have cut a recording from Sat1. During playback, VDR often gets out of sync directly after a cut point so that I have to press "rewind" and "play" to get it back in sync again. I think that I have also seen some weird sync behaviour after jumping within a recording of e.g. WDR - pressing "rewind" and "play" also does help here.
Maybe this problem also is connected to recent problems with xinelibout and DVB-T: Switching to the ARD transponder here near Munich, the A/V sync sometimes takes about 20 seconds to get right, while other channels give instant sound. Everyone who wants to test it could take a look at the latest Kanotix version where VDR, xinelibout and some channels.confs are included so that it can be started directly from the live CD without installing.
With kind regards
Jörg
On Mon, 23 Oct 2006 17:49:38 +0200 Joerg Knitter joerg.knitter@gmx.de wrote:
Udo Richter wrote:
Just talking about the case that I've reported. I experience such issues only very rarely, and mostly related to bad reception. The reported issue related to blackness is very specific to this channel.
Do you mean that this is e.g. just related to ATV+? Does Lost on ProSieben play without problems? This problems also appeared with 24 from ATV+ (also black fades on counter jumps). Anybody commenting if there are also problems with 24 recordings from RTL2?
If it can help to better pinpoint the problem, I have same symptoms, and same cause (loss of audio/video sync on black fades - dark scenes) with almost all recordings of C.S.I from Fox Crime - Sky Italia and a lot of Battlestar Galactica episodes from Fox - Sky Italia in the last two years. I do not have the same symptoms from other Sky Italia recordings, mainly sport events. One factor that can compound the problem is that the channels I am recording are encrypted and the decoding is done through a real smartcard, real subscription connected to a serial smartcard reader. I'll try to isolate a couple of recordings and pass them through mplayer to check whether they come out clear. I do not have the dropouts when I burn the recordings to dvd with the burn plugin, but I am digressing.
Cheers
Mattia
I just want to say that I, and many others not on the ml, are thankful this problem is finally being seriously addressed! It's very much appreciated that work is currently being done to discover and resolve the a/v sync problems once and for all! Many of us have just gotten used to the idea it would never be fixed but seeing this new activity happening makes people optimistic again.
On behalf of myself and everyone else who've hassled with this problem, thanks to all contributors! Your work is greatly appreciated!
I will chime in again and also state this has nothing to do with 1 particular channel. This, at least in North America, happens no matter what channel it is on. I can't recall any live TV ever being affected, but every recording I have has desync issues if I play straight through VDR on a FF card, some worse than others mind you, but every one gets out of sync. I don't know if it is an NTSC thing or what. I am willing to accept that if it is, but the problem still stands. But it sounds as if it happens on PAL systems as well from all those that have chimed in. I am in no way ungrateful for everything VDR has done and all the development from others, but this problem has been brought up many times in the past and ends up getting dropped as mentioned. Mainly, obviously due to the fact the developers can't reproduce it. But it isn't just Mplayer that plays fine, Xine plays fine as well. Both of these outputting via the FF Card. So, not just going full software mode. So that's 2 different playback devices that bypass whatever bugs or whatnot you might be mentioning. It is only when playing back through whatever VDR is using. It may very well be passing it straight through and the others aren't. But that is what we are trying to find out. And find out if there is a way that we can have an option if anything to choose playback a different way. I am not a programmer, so I don't know the ins or outs of how this can be accomplished, but being as so many others are now complaining about it, there has to be some way of figuring this out. Thanks for any insight you have on looking into this problem.
Pasi Juppo wrote:
Udo Richter wrote:
C.Y.M wrote:
If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmmmmmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :)
I wouldn't go that far. For this concrete case, since it is limited to one specific channel, there's a good chance that the encoding of the channel breaks some standards limitation. There's also most likely nothing wrong on VDR, as VDR is basically just forwarding data streams. If mplayer does a better job, then its probably more like a bug workaround. Generally, things would be a lot better if the driver/firmware would do A/V resyncing constantly and not just at playback start. That way, A/V desync wouldn't built up, and desync would only happen for a short time.
How come you make the conclusion that this is limited to one specific channel? To my understanding there are multiple channels where this problem occurs.
The best to start solving this problem is to try to figure out what happens with the recordings that are correct but still cause desync problems. This has been suggested already by many readers. Since it seems that only few people have access to the firmware source code the debugging is quite limited..
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
The way I understand it, the shows are sent as mpeg2, VDR decodes to raw data and stores as xxx.vdr files? which then need a special player that dosn't seem to work correctly to play these now much larger files which eat up a lot more space. So why not store them as mpeg files? A more common format which seems to have more options to play back and which work better? What format do DVD's use? What do you gain by converting to xxx.vdr aside from not needing to decode on playback? Which would be an advantage if the system worked and it didn't requre more complexities to convert back to mpeg for recording to a dvd. Also mpeg is a lossy compression, so data is lost converting back and forth.
----- Original Message ----- From: "C.Y.M" syphir@syphir.sytes.net To: "VDR Mailing List" vdr@linuxtv.org Sent: Friday, October 20, 2006 5:14 PM Subject: Re: [vdr] FF card A/V sync suggestion
Juri Haberland wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to
solve the a/v
desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
Klaus Schmidinger wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
There is one more issue, that seems to be related. On some recordings, here RTL Television with AC3 playback, sometimes single frames seem to be skipped during playback. I watched a recording of "Alarm für Cobra 11" yesterday and could identify at least 6 little jumps.
I have isolated a 20 MByte part of this recording where this effect was clear to see - I can send it by seperated mails or upload it somewhere if someone gives me an URL.
The weird thing: Playing those isolated scenes does not show the effect as people can see if they play the whole recording from the beginning, but rewinding the short clip to a certain point makes it possible to reproduce the problem. And again: This just happens when playing back the AC3 audio track.
With kind regards
Jörg
Joerg Knitter wrote:
Klaus Schmidinger wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync.
There is one more issue, that seems to be related. On some recordings, here RTL Television with AC3 playback, sometimes single frames seem to be skipped during playback. I watched a recording of "Alarm für Cobra 11" yesterday and could identify at least 6 little jumps.
I have isolated a 20 MByte part of this recording where this effect was clear to see - I can send it by seperated mails or upload it somewhere if someone gives me an URL.
The weird thing: Playing those isolated scenes does not show the effect as people can see if they play the whole recording from the beginning, but rewinding the short clip to a certain point makes it possible to reproduce the problem. And again: This just happens when playing back the AC3 audio track.
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
Best Regards.
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
Torgeir Veimo wrote:
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
Despite of the lost frame, the playback seems to be in sync. On the other side, I havent heard any jumps in sound yet. This could only be possible when the timing of audio and video would be different and the software would try to keep video and audio in sync by dropping sometimes a single video frames. On the other side, if the same recording works when playing back video with the MP2 track, it looks like a buffering or packaging issue, as if in this case the DD packages would not fit into a certain time scale.
With kind regards
Jörg
Torgeir Veimo schrieb:
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
Since mplayer is open source , someone who is able to do changes on that should contact someone at mplayer/xine. I think Nico Sabbi is working on dvb area on mplayer side. Further i think mplayer is checking very closely sync issues. For most stations the video stream should fulfil the task of the PCR stream, but here people that really know what they are talking about should step in ;) Furthermore mplayer-dvb list might be applicable.
Steffen
Torgeir Veimo wrote:
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
From what I understand, it could be either video or audio that is using
"stacked" data. Either a video frame that does not "change" or perhaps a few seconds of silence on the audio track could trigger this.
Best Regards.
Hadn't heard any more on this, did anyone get ahold of the mplayer source or the softplay source to find out how things are working in it? Just didn't want the subject to get dropped again heh.
C.Y.M wrote:
Torgeir Veimo wrote:
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
From what I understand, it could be either video or audio that is using
"stacked" data. Either a video frame that does not "change" or perhaps a few seconds of silence on the audio track could trigger this.
Best Regards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE?
Even the sync on live BBC1 on DVB-T in the UK drifts regularly out of sync and the only way to fix it is to channel change, this is with the latest CVS drivers and the latest firmware. Older firmware seems to improve things.
Regards,
Morfsta
On 10/27/06, Chad Flynt hoochster@sofnet.com wrote:
Hadn't heard any more on this, did anyone get ahold of the mplayer source or the softplay source to find out how things are working in it? Just didn't want the subject to get dropped again heh.
C.Y.M wrote:
Torgeir Veimo wrote:
On 24 Oct 2006, at 12:44, C.Y.M wrote:
Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm.
So you're certain that it's always picture frames being dropped, causing audio to be behind the video?
From what I understand, it could be either video or audio that is using
"stacked" data. Either a video frame that does not "change" or perhaps a
few
seconds of silence on the audio track could trigger this.
Best Regards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger wrote:
Morfsta wrote:
I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE?
I'm not working on this, because ATM I wouldn't know what to do.
Any comments on C.Y.M's point that PCR should be recorded/used? -> http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html
As far as I understand this, VDR ignores the TS-layer PCR timing data (which, as far as I understand this, controls the raw data rate fed to the decoders) and the syncing is done by DVB driver/firmware based on the timing information in the underlying PES headers. Since the DVB playback also works on PES layer and accepts data on all-you-can-eat base, I'm not sure whether feeding the DVB device on PCR based data rates would help, or how PCR should be forwarded to the DVB hardware.
Cheers,
Udo
Please don't let this die again! It's a bug that really should be fixed, even if it takes a little extra effort to get it figured out! Mplayer being opensource should help in seeing what exactly it does that vdr fails to do.
I really wish I was a C coder right now. :)
Udo Richter wrote:
Klaus Schmidinger wrote:
Morfsta wrote:
I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE?
I'm not working on this, because ATM I wouldn't know what to do.
Any comments on C.Y.M's point that PCR should be recorded/used? -> http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html
As far as I understand this, VDR ignores the TS-layer PCR timing data (which, as far as I understand this, controls the raw data rate fed to the decoders) and the syncing is done by DVB driver/firmware based on the timing information in the underlying PES headers. Since the DVB playback also works on PES layer and accepts data on all-you-can-eat base, I'm not sure whether feeding the DVB device on PCR based data rates would help, or how PCR should be forwarded to the DVB hardware.
I'm afraid my knowledge here is too limited. If somebody can come up with an idea of how additional timing information should be inserted in the PES data, let's hear it.
Generally I don't think that VDR should have to to anything regarding A/V sync during replay. It simply feeds the data to the device as fast as the device can take it, and syncing audio and video is the device's job. Maybe mplayer just generates additional PES headers for this?
Klaus
Klaus Schmidinger wrote:
Udo Richter wrote:
Klaus Schmidinger wrote:
Morfsta wrote:
I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE?
I'm not working on this, because ATM I wouldn't know what to do.
Any comments on C.Y.M's point that PCR should be recorded/used? -> http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html
As far as I understand this, VDR ignores the TS-layer PCR timing data (which, as far as I understand this, controls the raw data rate fed to the decoders) and the syncing is done by DVB driver/firmware based on the timing information in the underlying PES headers. Since the DVB playback also works on PES layer and accepts data on all-you-can-eat base, I'm not sure whether feeding the DVB device on PCR based data rates would help, or how PCR should be forwarded to the DVB hardware.
I'm afraid my knowledge here is too limited. If somebody can come up with an idea of how additional timing information should be inserted in the PES data, let's hear it.
Imho there is no need to add anything to the PES data format.
In live mode PCR is required to synchronize the internal clock of the decoder to the master clock of the transmitter.
In replay mode the clock of the decoder is running free, i.e. it is the master clock. No need for a PCR or something like that.
Generally I don't think that VDR should have to to anything regarding A/V sync during replay. It simply feeds the data to the device as fast as the device can take it, and syncing audio and video is the device's job. Maybe mplayer just generates additional PES headers for this?
Does mplayer really play PES data 'as is'? Afaik it recodes data to MPEG-1.(?)
Afaics it is a firmware/driver problem. It should be fixed there. Werner is currently working on a modified A/V sync code. We will see whether is improves things. Please be patient.
Oliver
Oliver Endriss wrote:
Does mplayer really play PES data 'as is'? Afaik it recodes data to MPEG-1.(?)
From CPU load on my machine, mplayer cannot do much with the signal. The CPU load is even lower than the VDR load when playing back 001.vdr. And even decoding in sotware would out-run my machine.
But I guess they decode the PES stream into two ES streams with additional timing, and re-pack it to a new PES stream.
Which leads to the open question, does the firmware/driver get confused by slight jitter in PTS values of audio PES packets? Or is this compensated?
Cheers,
Udo
Udo Richter wrote:
Oliver Endriss wrote:
Does mplayer really play PES data 'as is'? Afaik it recodes data to MPEG-1.(?)
From CPU load on my machine, mplayer cannot do much with the signal. The CPU load is even lower than the VDR load when playing back 001.vdr. And even decoding in sotware would out-run my machine.
But I guess they decode the PES stream into two ES streams with additional timing, and re-pack it to a new PES stream.
Would it be very difficult to duplicate this in VDR? I would love to start trying out code. My programming skills are just not good enough to start implementing this task. But, once there is some framework, I can get by trying things out.
Which leads to the open question, does the firmware/driver get confused by slight jitter in PTS values of audio PES packets? Or is this compensated?
What if the reception goes out for long periods of time and the sync becomes really bad? The firmware must have more limitations than a software solution?
Best Regards.
N.B. Thanks to everyone that is looking into this further!
On 31 Oct 2006, at 13:36, C.Y.M wrote:
But I guess they decode the PES stream into two ES streams with additional timing, and re-pack it to a new PES stream.
Guessing doesn't really help, maybe you should ask on the mplayer mailing list what they do with recorded vdr files?
If this were a firmware/driver problem then wouldn't the problem exist regardless of the playback software? The fact that vdr has playback sync problems whereas mplayer doesn't when playing back the same file suggests it's a vdr problem... But this has already been covered.
On 10/30/06, Oliver Endriss o.endriss@gmx.de wrote:
Afaics it is a firmware/driver problem. It should be fixed there. Werner is currently working on a modified A/V sync code. We will see whether is improves things. Please be patient.
Oliver
I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help?
I asked a couple specific questions and included some quotes from other posts to provide an idea of what we're looking at as the cause. I can't tell you what the exact problem is because we're still trying to figure
that
out... And a good place to start is by comparing the differences between the software that has the problem and software that doesn't. We're trying to figure out what mplayer does, if anything, with regards to repacking, the pes layer, pcr data, etc. during the "playback" of a VDR
"recording".
nothing particular: the pes packetization is as standard as you can get, except that IIRC there's a timestamp on every single frame, rather than once every 0.5-0.7 seconds; this fact alone can make a lot of difference during playback. Does the desync that you are experiencing get worse with time or does it regularly decrease and next increase?
I'm not sure if it's been answered yet, but I thought I'd throw this out:
mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime.
Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice.
I know it's probably what most of you didn't want to hear, but I figured you guys would want to know.
whoman421
On 11/3/06, VDR User user.vdr@gmail.com wrote:
I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help?
I asked a couple specific questions and included some quotes from other posts to provide an idea of what we're looking at as the cause. I can't tell you what the exact problem is because we're still trying to figure
that
out... And a good place to start is by comparing the differences
between
the software that has the problem and software that doesn't. We're trying to figure out what mplayer does, if anything, with regards to repacking, the pes layer, pcr data, etc. during the "playback" of a VDR
"recording".
nothing particular: the pes packetization is as standard as you can get, except that IIRC there's a timestamp on every single frame, rather than once every 0.5-0.7 seconds; this fact alone can make a lot of difference during playback. Does the desync that you are experiencing get worse with time or does it regularly decrease and next increase?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
whoMAN wrote:
mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime.
Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice.
Once again, this is impossible. Really.
My CPU is a VIA C3-600 CPU, and its really too slow to transcode *anything*. If I force transcodung with -vf lavc=1000, the CPU load is 99% and the video plays at 40% original speed only. Just decoding the mpeg2 stream eats up 75% CPU alone, without audio and without displaying.
Without forcing transcoding, the CPU load is 10% and no frames get dropped. This is roughly 25 times faster than with lavc=1000.
Cheers,
Udo
whoMAN schrieb:
I'm not sure if it's been answered yet, but I thought I'd throw this out:
mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime.
Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice.
I know it's probably what most of you didn't want to hear, but I figured you guys would want to know.
whoman421
Thats plain wrong. Anything that can be feed directly, will not be transcoded. And i can see mplayer taking ressources , if mplayer is transcoding. Not everybody has a core duo 6600 ;)
On 10/31/06, Oliver Endriss o.endriss@gmx.de wrote:
Afaics it is a firmware/driver problem. It should be fixed there. Werner is currently working on a modified A/V sync code. We will see whether is improves things. Please be patient.
Oliver
Any news on this Oliver or Werner? Any update would be appreciated, sync is still a major problem for many users...
Morfsta
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
thanks
marco
-------------------------------------------------- AMMEC - Accessible Multimedia Entertainment Center
http://www.ammec.de Email: Marco Skambraks marco@ammec.de
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Oliver
I felt real optimistic after such a long thread on the subject but it seems to have died off again with no real resolve (that I'm aware of). I thought people had finally agreed that the problem was in vdr, something it wasn't doing that it should be to preserve sync. Unfortunately it seems I misunderstood and there is still (or was rather) whether it's a vdr or firmware issue.
Logic still says that if mplayer can play vdr recordings just fine without losing sync, but vdr can't, the problem is with vdr, not the firmware. To troubleshoot you compare the differences between working & not working, then factor out the things they have in common. In this case, the same firmware and drivers are used, thus not where the problem lays.
Although no progress has been made (again, that I'm aware of), I still appreciate the time & effort of all who participated in the other thread!
VDR User wrote: ...
Logic still says that if mplayer can play vdr recordings just fine without losing sync, but vdr can't, the problem is with vdr, not the firmware.
That's only correct if you ignore specifications. Maybe VDR is behaving according to the specified interface and the firmware fails. Maybe mplayer is working around firmware bugs by behaving differently - which may or may not be according to the specified interface.
What we can agree upon is the fact that the problem *can* be solved within the application program. IMHO, the fact that mplayer works where VDR does not proves just that, but not more.
However, if VDR behaves 100% according to specification, the problem *should* be solved in the driver and/or firmware, because that would fix all programs that also behave 100% according to specification and fail.
If fixing it where it should be fixed turns out to be too difficult, it might still be a good idea to fix it in VDR.
Carsten.
You make things sound promising again, thanks for the reply! And of course I agree with your points fully. At any rate the issue still remains and has once again seemed to be left unresolved.
A question for Oliver Endriss (if you read this).. Can you confirm that the firmware abides fully to specification?
Thanks guys.
Marco Skambraks wrote
On 11/30/06, Carsten Koch Carsten.Koch@icem.com wrote:
VDR User wrote: ...
Logic still says that if mplayer can play vdr recordings just fine without losing sync, but vdr can't, the problem is with vdr, not the firmware.
That's only correct if you ignore specifications. Maybe VDR is behaving according to the specified interface and the firmware fails. Maybe mplayer is working around firmware bugs by behaving differently - which may or may not be according to the specified interface.
What we can agree upon is the fact that the problem *can* be solved within the application program. IMHO, the fact that mplayer works where VDR does not proves just that, but not more.
However, if VDR behaves 100% according to specification, the problem *should* be solved in the driver and/or firmware, because that would fix all programs that also behave 100% according to specification and fail.
If fixing it where it should be fixed turns out to be too difficult, it might still be a good idea to fix it in VDR.
Carsten.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
VDR User wrote:
Can you confirm that the firmware abides fully to specification?
I'm pretty sure that it doesn't. Neither do mplayer, vdr and the DVB driver. All complex programs have bugs... ;-)
CU Oliver
Carsten Koch wrote:
Maybe VDR is behaving according to the specified interface and the firmware fails. Maybe mplayer is working around firmware bugs by behaving differently - which may or may not be according to the specified interface.
What we can agree upon is the fact that the problem *can* be solved within the application program. IMHO, the fact that mplayer works where VDR does not proves just that, but not more.
However, if VDR behaves 100% according to specification, the problem *should* be solved in the driver and/or firmware, because that would fix all programs that also behave 100% according to specification and fail.
If fixing it where it should be fixed turns out to be too difficult, it might still be a good idea to fix it in VDR.
Has anyone been able to identify the differences in the MPEG data if (a) mplayer (b) vdr play the sample stream?
Imho that's the key to the problem.
Oliver
On Friday 01 December 2006 03:04, Oliver Endriss wrote:
Carsten Koch wrote:
Has anyone been able to identify the differences in the MPEG data if (a) mplayer (b) vdr play the sample stream?
My understanding of playback via mplayer is, that mplayer uses its included synchronization logic. That means it demultiplexes its input (evtually transforms it to mpeg-1/2), then synchronizes it, and multiplexes it to pes. That means the FF-Card receives a synchron stream.
I think moving that synchronizing logic out of software-playback devices into vdr will solve that problem (and also other problems like audio near cutting marks).
VDR however for now just forwards recorded data to FF-Card without ensuring any time-conditions.
Matthias
Hello, On Fr, Dez 01, 2006 at 10:46:15 +0100, Matthias Schwarzott wrote:
On Friday 01 December 2006 03:04, Oliver Endriss wrote:
Carsten Koch wrote:
Has anyone been able to identify the differences in the MPEG data if (a) mplayer (b) vdr play the sample stream?
My understanding of playback via mplayer is, that mplayer uses its included synchronization logic.
ACK.
That means it demultiplexes its input (evtually transforms it to mpeg-1/2), then synchronizes it, and multiplexes it to pes. That means the FF-Card receives a synchron stream.
Check your cpu-load during mplayer-playback. Mplayer does not transcode something to mpeg1/2 etc because the cpuload is near 0.
Best regards Halim
On Friday 01 December 2006 10:59, Halim Sahin wrote:
Hello,
On Fr, Dez 01, 2006 at 10:46:15 +0100, Matthias Schwarzott wrote:
On Friday 01 December 2006 03:04, Oliver Endriss wrote:
Carsten Koch wrote:
Has anyone been able to identify the differences in the MPEG data if (a) mplayer (b) vdr play the sample stream?
My understanding of playback via mplayer is, that mplayer uses its included synchronization logic.
ACK.
That means it demultiplexes its input (evtually transforms it to mpeg-1/2), then synchronizes it, and multiplexes it to pes. That means the FF-Card receives a synchron stream.
Check your cpu-load during mplayer-playback. Mplayer does not transcode something to mpeg1/2 etc because the cpuload is near 0.
Ack. For playback of vdr-recordings you are right. I meant it can be eventually transcoded (playback of non mpeg2-files).
Matthias
hi, On Fri, 1 Dec 2006, Matthias Schwarzott wrote:
Ack. For playback of vdr-recordings you are right. I meant it can be eventually transcoded (playback of non mpeg2-files).
OK, but the question is: why can mplayer playback a vdr-recording without a/v sync problems with a minimal load of almost NULL?
vdr itself is not able to playback the same recording without a/v sync problems
vdr together with softdevice does not have this problem
so, is it a ttpci-firmware bug or a vdr-playback problem
if we compare softdevice and FF card it looks like a ttpci-firmware problem, but if we compare mplayer-ttpci-firmware and vdr-ttpci-firmware it looks like a vdr playback problem
maybe it's both - a problem with the firmware and also a playback problem of vdr and maybe softdevice is able to identify/correct the a/v sync stuff
I hope one of the dvb/vdr specialists will find the reason for that
hopefully in the near future :-)
marco
Matthias
-- Matthias Schwarzott Gentoo Developer http://www.gentoo.org
-------------------------------------------------- AMMEC - Accessible Multimedia Entertainment Center
http://www.ammec.de Email: Marco Skambraks marco@ammec.de
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
On 1/19/07, Oliver Endriss o.endriss@gmx.de wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
Thanks for the heads up on this! Do you happen to know what exactly the problem turned out to be and what was done to fix it? Also, for those of us who don't speak german, could you translate what he is saying in his post? I've downloaded the archive but there's a lot more than just a firmware file in there, are we supposed to apply all the patches too or?
Cheers!
mailto:o.endriss@gmx.de> wrote:
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
I can confirm that the two known issues ('Lost' on ATV and 'Lost' sample by Tero) both play smooth and properly synced for me. Thanks for the great work!
VDR User wrote:
Also, for those of us who don't speak german, could you translate what he is saying in his post?
Under http://www.suse.de/~werner/test_av-f12623.tar.bz2 there is a new test version with number F12623. Changes are: At live TV, switching faster and more stable from one channel to another. Faster syncing of AC3 at live TV, and the problem with underruns should be solved. For replay mpeg audio and AC3 should synchronize cleanly, only the change from AC3 to an mpeg track may be a bit rough.
I've downloaded the archive but there's a lot more than just a firmware file in there, are we supposed to apply all the patches too or?
I've just copied the dvb-ttpci-01.fw and replaced the existing one, works fine. (kernel 2.6)
Cheers,
Udo
On 20 Jan 2007, at 11:12, Udo Richter wrote:
mailto:o.endriss@gmx.de> wrote:
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
I can confirm that the two known issues ('Lost' on ATV and 'Lost' sample by Tero) both play smooth and properly synced for me. Thanks for the great work!
Is this FW for all FF cards on the market?
On la, 2007-01-20 at 12:12 +0100, Udo Richter wrote:
I can confirm that the two known issues ('Lost' on ATV and 'Lost' sample by Tero) both play smooth and properly synced for me. Thanks for the great work!
Just tested and I can confirm this too. Lost, Prison Break, everything that used to suffer from this problem seems to work now :)
hi, now, I tested the new firmware it looks good - fast-forward and jumps in the dvd-plugin is now working almost perfect
receiving and replaying recordings is working correctly
I use a tt c2300 (nexus-ca)
thanks Werner and Oliver - good job guys :-)
marco
On Fri, 19 Jan 2007, Oliver Endriss wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
--
VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------------------------------------------- AMMEC - Accessible Multimedia Entertainment Center
http://www.ammec.de Email: Marco Skambraks marco@ammec.de
Hi,
I added the new firmware last night and previously I even had problems with sync on live tv (had to chan+ chan- to fix) on freeview in the UK as well as the dreaded recording sync problem. Up till now I haven't seen it happen again (even watching the same programme on the same channel as last weekend for 90 minutes, when there was lots of sync problems) so hopefully (touch wood) the problem is finally fixed!
Anyway, I'd like to give a big thank-you to Werner and Oliver for all their hardwork, its clear that they have had to work for quite some time following the thread when it first begun in December. So, thanks guys - its really appreciated as this for me has been the biggest problem with using VDR to date and is the only reason why it isn't perfect.
I really hope that in a weeks time the sync is still fine! :-)
Cheers!
Morfsta
On 1/22/07, Marco Skambraks marco@ammec.de wrote:
hi, now, I tested the new firmware it looks good - fast-forward and jumps in the dvd-plugin is now working almost perfect
receiving and replaying recordings is working correctly
I use a tt c2300 (nexus-ca)
thanks Werner and Oliver - good job guys :-)
marco
On Fri, 19 Jan 2007, Oliver Endriss wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
--
VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AMMEC - Accessible Multimedia Entertainment Center
http://www.ammec.de Email: Marco Skambraks marco@ammec.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I've tested the new fw also and no sync problems has occurred.
Although I was hoping that this would have corrected my stuttering problem also. Every now and then replayed video stops for a second or so and begins stuttering for some seconds and then continues normally. With earlier fw it usually caused A/V sync problem but now syncing is fine. This is not repeatable meaning that the problem does not occur if I rewind (or jump) and replay the same moment. Some time ago I had a PIII 550MHz system and in it the stuttering could continue indefinitely (or in the end of the recording :). After an upgrade of hw (new mb and amd 3000+ sempron) the stuttering lasts only a few seconds.
I have vdr-1.4.4, FF card (v2.1), subtitle plugin and burn plugin.
\Kartsa
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Marco Skambraks Sent: 22. tammikuuta 2007 11:31 To: vdr@linuxtv.org Subject: Re: [vdr] FF card A/V sync - in progress?
hi, now, I tested the new firmware it looks good - fast-forward and jumps in the dvd-plugin is now working almost perfect
receiving and replaying recordings is working correctly
I use a tt c2300 (nexus-ca)
thanks Werner and Oliver - good job guys :-)
marco
On Fri, 19 Jan 2007, Oliver Endriss wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See
http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
--
VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AMMEC - Accessible Multimedia Entertainment Center
http://www.ammec.de Email: Marco Skambraks marco@ammec.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-----Original Message----- Subject: Re: [vdr] FF card A/V sync - in progress?
:). After an upgrade of hw (new mb and amd 3000+ sempron)
the stuttering
lasts only a few seconds.
you have DMA enabled for your harddisk?
Thanks. I have to check this. Now that you mentioned it I think I've read about this DMA thing earlier :)
Kartsa wrote:
I've tested the new fw also and no sync problems has occurred.
Although I was hoping that this would have corrected my stuttering problem also. Every now and then replayed video stops for a second or so and begins stuttering for some seconds and then continues normally. With earlier fw it usually caused A/V sync problem but now syncing is fine. This is not repeatable meaning that the problem does not occur if I rewind (or jump) and replay the same moment. Some time ago I had a PIII 550MHz system and in it the stuttering could continue indefinitely (or in the end of the recording :). After an upgrade of hw (new mb and amd 3000+ sempron) the stuttering lasts only a few seconds.
From the symptoms you describe it seems very likely that your system
has a bottleneck between VDR and the data.
Is your VDR reading from local disks or via NFS? Are other things running on your machine that could make your disks busy? Do you have DMA enabled on your disks?
BTW: I am also experiencing the same problems every now and then. I have S.M.A.R.T. enabled on all my disks and I am wondering if these "hickups" come from automatic self diagnostics?
Maybe larger replay buffers in VDR would help?
I am _assuming_ that this line
#define PLAYERBUFSIZE MEGABYTE(1)
in dvbplayer.c defines the buffer size? Klaus, can you confirm this?
Kartsa, since the problem occurs quite often in your setup: Could you try to change the above line to
#define PLAYERBUFSIZE MEGABYTE(64)
and let us know if the problem still occurs?
Thanks, Carsten.
Kartsa wrote:
I've tested the new fw also and no sync problems has occurred.
Although I was hoping that this would have corrected my
stuttering problem
also. Every now and then replayed video stops for a second
or so and begins
stuttering for some seconds and then continues normally.
With earlier fw it
usually caused A/V sync problem but now syncing is fine. This is not repeatable meaning that the problem does not occur if I
rewind (or jump) and
replay the same moment. Some time ago I had a PIII 550MHz
system and in it
the stuttering could continue indefinitely (or in the end
of the recording
:). After an upgrade of hw (new mb and amd 3000+ sempron)
the stuttering
lasts only a few seconds.
From the symptoms you describe it seems very likely that your system
has a bottleneck between VDR and the data.
Is your VDR reading from local disks or via NFS? Are other things running on your machine that could make your disks busy? Do you have DMA enabled on your disks?
VDR is reading from local disks which are SATA disks (on my old hw SATA was on a PCI card and on new its on mb). VDR is the only thing running that should cause any disk activity (besides normal sytem prosesses and sshd) and the system is running on a different disk which resides in PATA channel. I have to check whether or not I've got DMA enabled.
BTW: I am also experiencing the same problems every now and then. I have S.M.A.R.T. enabled on all my disks and I am wondering if these "hickups" come from automatic self diagnostics?
I've got S.M.A.R.T. also enabled. But I doubt that it should make this big impact. I've tested recording from 9 channels at the same time and having a recording replaying with no stuttering but I did not make a long test. Maybe I should. The funny thing is that I made the test with my older hw :)
Maybe larger replay buffers in VDR would help?
I am _assuming_ that this line
#define PLAYERBUFSIZE MEGABYTE(1)
in dvbplayer.c defines the buffer size? Klaus, can you confirm this?
Kartsa, since the problem occurs quite often in your setup: Could you try to change the above line to
#define PLAYERBUFSIZE MEGABYTE(64)
and let us know if the problem still occurs?
I have a yum installed environment, that is I have not compiled vdr my self. I do have another machine on which I could do the compilation but it has a different version of VDR :/ I would be forced to either create the same environment on my test machine for compilation or update all my vdr related sw on my vdr box. Maybe I could do the first one. This will take some days to get done and verified the effect.
\Kartsa
Carsten Koch kirjoitti:
Is your VDR reading from local disks or via NFS? Are other things running on your machine that could make your disks busy? Do you have DMA enabled on your disks?
Btw. is there an easy way to see this from the logs because my vdr box is situated in a difficult place where I can easily get only by ssh?
I found this for the non recording disks VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:DMA hda: 30015216 sectors (15367 MB) w/512KiB Cache, CHS=29777/16/63, UDMA(66) hdd: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
and this for the recording disks ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD400 irq 169 ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xD802 bmdma 0xD408 irq 169 ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 ata1.00: configured for UDMA/133 ata2.00: ATA-7, max UDMA7, 156368016 sectors: LBA48 ata2.00: configured for UDMA/133
I assume this means DMA is enabled.
\Kartsa
On Mon, Jan 22, 2007 at 06:16:05PM +0200, Kartsa wrote:
Btw. is there an easy way to see this from the logs because my vdr box is situated in a difficult place where I can easily get only by ssh?
#hdparm -d /dev/hda
To enable it, use
#hdparm -d 1 /dev/hda
For what it is worth, here are the hdparm settings for my hard disk (Western Digital Caviar SE WD3000JB-00KFA0, Parallel ATA):
#hdparm /dev/hda
/dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 36481/255/63, sectors = 586072368, start = 0
Like you, I am cursed by the VIA chipset, but luckily I haven't experienced any DMA lockups, which have been reported for many generations of VIA hardware. Every now and then, the system must be completely powered off, because something apparently in the PCI controller gets misconfigured so badly that Linux panics or hangs at boot. The system reset or soft power-off won't help in this situation. Also, the system must be rebooted in order for nvram-wakeup to work, and Wake-on-LAN often ceases to work. This is an Intel Celeron 900 MHz on an MSI 694T Pro motherboard: http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=...
If everything else fails, try a hard power-off.
Marko
Marko Mäkelä kirjoitti:
On Mon, Jan 22, 2007 at 06:16:05PM +0200, Kartsa wrote:
Btw. is there an easy way to see this from the logs because my vdr box is situated in a difficult place where I can easily get only by ssh?
#hdparm -d /dev/hda
To enable it, use
#hdparm -d 1 /dev/hda
This does not seem to work with sata drives. It gives hdparm -d 1 /dev/sda /dev/sda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Inappropriate ioctl for device
Like you, I am cursed by the VIA chipset, but luckily I haven't experienced any DMA lockups, which have been reported for many generations of VIA hardware. Every now and then, the system must be completely powered off, because something apparently in the PCI controller gets misconfigured so badly that Linux panics or hangs at boot. The system reset or soft power-off won't help in this situation. Also, the system must be rebooted in order for nvram-wakeup to work, and Wake-on-LAN often ceases to work. This is an Intel Celeron 900 MHz on an MSI 694T Pro motherboard: http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=...
I have nvram-installed and it shuts down the box every night.
\Kartsa
Kartsa kirjoitti:
Marko Mäkelä kirjoitti:
On Mon, Jan 22, 2007 at 06:16:05PM +0200, Kartsa wrote:
Btw. is there an easy way to see this from the logs because my vdr box is situated in a difficult place where I can easily get only by ssh?
#hdparm -d /dev/hda
To enable it, use
#hdparm -d 1 /dev/hda
This does not seem to work with sata drives. It gives hdparm -d 1 /dev/sda /dev/sda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Inappropriate ioctl for device
Like you, I am cursed by the VIA chipset, but luckily I haven't experienced any DMA lockups, which have been reported for many generations of VIA hardware. Every now and then, the system must be completely powered off, because something apparently in the PCI controller gets misconfigured so badly that Linux panics or hangs at boot. The system reset or soft power-off won't help in this situation. Also, the system must be rebooted in order for nvram-wakeup to work, and Wake-on-LAN often ceases to work. This is an Intel Celeron 900 MHz on an MSI 694T Pro motherboard: http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=...
I have nvram-installed and it shuts down the box every night.
So, hdparm did no good. I have been running vdr now for a couple days with
#define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c
and for now it seems like better as in no stuttering. But I am still testing it.
\Kartsa
Marko Mäkelä kirjoitti:
On Sat, Jan 27, 2007 at 11:56:56PM +0200, Kartsa wrote:
So, hdparm did no good.
Did you try sdparm? Serial ATA looks like SCSI to some tools.
Nope, because there was no sdparm. For some reason did not think to check if such exists at all :)
This is what sdparm gives but I don't have the knowledge to find dma specific info in this. I see that there is something about dma but is it enabled or not??
sdparm --long /dev/sda /dev/sda: ATA ST3200822AS 3.01 Direct access device specific parameters: WP=0 DPOFUA=0 Read write error recovery [rw] mode page: AWRE 1 Automatic write reallocation enabled ARRE 1 Automatic read reallocation enabled PER 0 Post error Caching (SBC) [ca] mode page: WCE 1 Write cache enable RCD 0 Read cache disable Control [co] mode page: SWP 0 Software write protect
sdparm --long /dev/sdb /dev/sdb: ATA SAMSUNG SP0812C SU10 Direct access device specific parameters: WP=0 DPOFUA=0 Read write error recovery [rw] mode page: AWRE 1 Automatic write reallocation enabled ARRE 1 Automatic read reallocation enabled PER 0 Post error Caching (SBC) [ca] mode page: WCE 1 Write cache enable RCD 0 Read cache disable Control [co] mode page: SWP 0 Software write protect
\Kartsa
Kartsa wrote: ...
So, hdparm did no good. I have been running vdr now for a couple days with
Try hdparm -I /dev/sda
on my system, it says ... DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 ... which I interpret as: "this device suuports mdma0-udma6 and is currently running in udma6 mode.".
Carsten.
Carsten Koch kirjoitti:
Kartsa wrote: ...
So, hdparm did no good. I have been running vdr now for a couple days with
Try hdparm -I /dev/sda
on my system, it says ... DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 ... which I interpret as: "this device suuports mdma0-udma6 and is currently running in udma6 mode.".
I got for first disk ... DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 ... and for second ... DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7 ...
This would propably mean that both my sata disks are dma enabled.
\Kartsa
Kartsa kirjoitti:
I have been running vdr now for a couple days with
#define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c
and for now it seems like better as in no stuttering. But I am still testing it.
Okey, I've had this setting in action for a week or so now and it is definitely better. There is still sometimes some stuttering but it is so suttle that it is barely noticeable. With MEGABYTE(1) the video occasionally stopped for a second and then stuttered for about 5 seconds and then resumed normal operation (with lesser cpu it could be stuttering to the end of the recording).
Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier.
\Kartsa
Kartsa wrote:
Kartsa kirjoitti:
I have been running vdr now for a couple days with
#define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c
and for now it seems like better as in no stuttering. But I am still testing it.
Okey, I've had this setting in action for a week or so now and it is definitely better. There is still sometimes some stuttering but it is so suttle that it is barely noticeable. With MEGABYTE(1) the video occasionally stopped for a second and then stuttered for about 5 seconds and then resumed normal operation (with lesser cpu it could be stuttering to the end of the recording).
As mentioned earlier in this thread, I had also sometimes noticed a similar effect "video halts for a few seconds, then resumes and stutters for a few seconds". After recommending it to you, I have also increased PLAYERBUFSIZE to 64MB and I have not noticed the problem ever since.
So there is a high probability that increasing PLAYERBUFSIZE improves matters.
Maybe it should not be fixed, though, since a machine with very little RAM may suffer from thrashing if the VDR footprint is increased that much.
I wonder if it should be configurable or if there would be an automatic way of determining the "right" size (i.e. start with 1 MB, then double it on every stutter and remember the value in the setup.conf file).
Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier.
I do not think so. Maybe S.M.A.R.T., maybe hardware, but not the file system. I am using XFS on individual (mostly PATA) disks over NFS.
Carsten.
I have noticed smilar trouble:
When VDR playbacks a recording, and I pause playback and put play again, video starts playing, then stops for less than second after about 5 seconds, then plays, after two seconds stops again for one second, and then plays smoothly.
I have noticed "replay stuttering" trouble sometimes, but increasing PLAYERBUFSIZE to MEGABYTE(8) resolved the trouble.
Boguslaw Juza
Kartsa schrieb:
Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier.
My VDR is running completely via NFS and i have also this "stutter" problem especially when using timeshift. The replay hangs for some seconds and then resumes normally. This is reproducible with a vanilla vdr-1.4.5 (FuSi DVB-C, 2.6.19.2 with v4l-dvb-av7110-refactoring). When i increase PLAYERBUFSIZE in dvbplayer.c to MEGABYTE(16) the problem is gone. Perhaps i would be a good idea, as already suggested by Carsten Koch, to make this value configurable.
On 19.1.2007 22:30, "Oliver Endriss" o.endriss@gmx.de wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
I can also report A/V sync working, but also problem that might relate to this new test version of the firmware. Timer recording failed, because vdr couldn't change the channel. Logs were filled with entries below resulting recording of 0 bytes. Another two recordings earlier has worked however, so could be related or coincidence. But Wife Approval Factor just dropped dramatically :)
- logs -
/var/log/messages:
Jan 22 19:59:21 localhost vdr: [1758] timer 1 (4 1959-2110 'Huippumalli haussa') start Jan 22 19:59:21 localhost vdr: [1758] record /video/Huippumalli_haussa/2007-01-22.19.59.99.99.rec Jan 22 19:59:21 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0000 b96a ret -1 handle d099 Jan 22 19:59:21 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0000 b96a ret -1 handle d099 Jan 22 19:59:21 localhost kernel: dvb-ttpci: av7110_fw_cmd error -1 Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=4E, mask=FE): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=50, mask=F0): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=60, mask=F0): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0014 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=20, tid=70, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0000 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=0, tid=00, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0011 b96a ret -1 handle d099 Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0011 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=17, tid=42, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0010 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=16, tid=40, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0000 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=0, tid=00, mask=FF): Operation not permitted Jan 22 19:59:25 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 00d7 b96a ret -1 handle ffff Jan 22 19:59:25 localhost vdr: [1758] ERROR (dvbdevice.c,683): Operation not permitted Jan 22 19:59:25 localhost vdr: [1758] ERROR: can't set PID 215 on device 2 Jan 22 19:59:26 localhost vdr: [1758] timer 1 (4 1959-2110 'Huippumalli haussa') stop . . .
dmesg:
DVB (dvb_dmxdev_filter_start): could not alloc feed DVB (dvb_dmxdev_filter_start): could not alloc feed DVB (dvb_dmxdev_filter_start): could not alloc feed . . .
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.3,+streamdev,ttxtsubs,subtitles,tvonscreen,text2skin, burn,wapd,osdteletext,mp3,femon
On 1/23/07, Tero Siironen izero79@gmail.com wrote:
I can also report A/V sync working, but also problem that might relate to this new test version of the firmware. Timer recording failed, because vdr couldn't change the channel. Logs were filled with entries below resulting recording of 0 bytes. Another two recordings earlier has worked however, so could be related or coincidence. But Wife Approval Factor just dropped dramatically :)
I don't think this is coincidence as I too have has timer recording failures since installing the new a/v sync-fixed firmware. This is definitely something that should be looked into!
VDR User kirjoitti:
On 1/23/07, *Tero Siironen* <izero79@gmail.com mailto:izero79@gmail.com> wrote:
I can also report A/V sync working, but also problem that might relate to this new test version of the firmware. Timer recording failed, because vdr couldn't change the channel. Logs were filled with entries below resulting recording of 0 bytes. Another two recordings earlier has worked however, so could be related or coincidence. But Wife Approval Factor just dropped dramatically :)I don't think this is coincidence as I too have has timer recording failures since installing the new a/v sync-fixed firmware. This is definitely something that should be looked into!
Could this be related to some sw or hw issue? I have had this new fw for a few days now and about 20+ succesfull recordings and no failures.
I've got vdr 1.4.4, burn 0.0.009, subtitles 0.4.0, femon 1.1.0, mplayer 0.9.15 and vompserver 0.2.5. And on the hw side AMD Sempron 3000+, 512MB, TT DVB-C FF 2.1, DVB-C budget, FC6, kernel 2.6.18-1.2849.
\Kartsa
2007/1/23, Kartsa kari@kniivila.com:
Could this be related to some sw or hw issue? I have had this new fw for a few days now and about 20+ succesfull recordings and no failures.
I've got vdr 1.4.4, burn 0.0.009, subtitles 0.4.0, femon 1.1.0, mplayer 0.9.15 and vompserver 0.2.5. And on the hw side AMD Sempron 3000+, 512MB, TT DVB-C FF 2.1, DVB-C budget, FC6, kernel 2.6.18-1.2849.
Well, like I said I cannot confirm that this was because of the new firmware, and I've made two successful timer recordings on Sunday. But on the other hand this was the very first time that recording failed (excluding human errors) with my new setup, built in last July and about 1-5 recordings every week.
I now updated vdr and plugins and added more error recovery to it. So we'll see.
Tero Siironen wrote:
On 19.1.2007 22:30, "Oliver Endriss" o.endriss@gmx.de wrote:
Oliver Endriss wrote:
Marco Skambraks wrote:
hi,
are there any new information about the FF a/v sync problem? is the firmware development still in progress?
Sorry, no success yet.
Werner fixed the A/V sync problem. Please test firmware f12623. See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692
Oliver
I can also report A/V sync working, but also problem that might relate to this new test version of the firmware. Timer recording failed, because vdr couldn't change the channel. Logs were filled with entries below resulting recording of 0 bytes. Another two recordings earlier has worked however, so could be related or coincidence. But Wife Approval Factor just dropped dramatically :)
- logs -
/var/log/messages:
Jan 22 19:59:21 localhost vdr: [1758] timer 1 (4 1959-2110 'Huippumalli haussa') start
^^^^^^^^^^^^^^^^^^ ...
I can fully understand why WAF is lower :-)
Anyway, I can report also that A/V sync problem does not seem to be bothering anymore. Excellent work!
It was actually strange to watch 24-series episode when I didn't have to jump back and forth every now and then. I just got so used to the annoying factor someway..
Br, Pasi
Pasi Juppo wrote:
Anyway, I can report also that A/V sync problem does not seem to be bothering anymore. Excellent work!
I was a bit too hasty. Sync got lost once while watching Pako (Prison Break). However, it was nicer than earlier. Sync was out of sync but the video and audio played nicely - just out of sync. Previously audio was making cracking noise time to time.
Br, Pasi
Hi Pasi,
Perhaps you could cut the clip and send it to Oliver and Werner for further testing and debugging?
I do still have sync problems too with live TV and freeview, but it is not as bad as it was. I don't understand though why no-one else seems to have sync problems with live TV, so I have rolled back to an older driver for my DVB-T card (TDA-100045) as I changed a year ago and that might have been when it started, but I changed the AV7110 firmware at the same time. I'll see if it improves things.
Regards,
Morfsta
On 1/23/07, Pasi Juppo pasi.juppo@iki.fi wrote:
Pasi Juppo wrote:
Anyway, I can report also that A/V sync problem does not seem to be bothering anymore. Excellent work!
I was a bit too hasty. Sync got lost once while watching Pako (Prison Break). However, it was nicer than earlier. Sync was out of sync but the video and audio played nicely - just out of sync. Previously audio was making cracking noise time to time.
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Unfortunately I deleted the episode immediately after I had watched it (I seldom save any episodes anyway). But if this happens again I'll make a clip for futher evaluation.
I don't recall having ever problems with audio sync in live TV. I'm using TT FF v1.5 (iirc) and also TT1500 budget.
Br, Pasi
Morfsta wrote:
Hi Pasi,
Perhaps you could cut the clip and send it to Oliver and Werner for further testing and debugging?
I do still have sync problems too with live TV and freeview, but it is not as bad as it was. I don't understand though why no-one else seems to have sync problems with live TV, so I have rolled back to an older driver for my DVB-T card (TDA-100045) as I changed a year ago and that might have been when it started, but I changed the AV7110 firmware at the same time. I'll see if it improves things.
Regards,
Morfsta
On 1/23/07, *Pasi Juppo* <pasi.juppo@iki.fi mailto:pasi.juppo@iki.fi> wrote:
Pasi Juppo wrote: > Anyway, I can report also that A/V sync problem does not seem to be > bothering anymore. Excellent work! I was a bit too hasty. Sync got lost once while watching Pako (Prison Break). However, it was nicer than earlier. Sync was out of sync but the video and audio played nicely - just out of sync. Previously audio was making cracking noise time to time. Br, Pasi _______________________________________________ vdr mailing list vdr@linuxtv.org <mailto:vdr@linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I'm afraid my knowledge here is too limited. If somebody can come up with an idea of how additional timing information should be inserted in the PES data, let's hear it.
I'm quite sure this is not the point to work witht.
Generally I don't think that VDR should have to to anything regarding A/V sync during replay. It simply feeds the data to the device as fast as the device can take it, and syncing audio and video is the device's job. Maybe mplayer just generates additional PES headers for this?
xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ?
Petri Hintukainen wrote:
xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ?
For the tero sample from this thread, I've demultiplexed it with projectx and re-muxed it to VDR, and it was playing fine. It must be on the PES layer. The only thing I've noticed was a slight +/-1 jitter in the PTS timecode of the audio track.
Cheers,
Udo
Thanks for not giving up on this yet guys.
Udo Richter wrote:
Petri Hintukainen wrote:
xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ?
For the tero sample from this thread, I've demultiplexed it with projectx and re-muxed it to VDR, and it was playing fine. It must be on the PES layer. The only thing I've noticed was a slight +/-1 jitter in the PTS timecode of the audio track.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Boguslaw Juza -
C.Y.M -
Carsten Koch -
Chad Flynt -
clemens kirchgatterer -
Halim Sahin -
Heikki Manninen -
Joerg Knitter -
Juri Haberland -
Kartsa -
Klaus Schmidinger -
Lauri Tischler -
Marco Skambraks -
Marko Mäkelä -
Matthias Schwarzott -
matthieu castet -
Mattia Rossi -
Morfsta -
Oliver Endriss -
Pasi Juppo -
Pertti Kosunen -
Petri Hintukainen -
Richard Scobie -
Stefan Hußfeldt -
Steffen Barszus -
Tero Siironen -
Timothy D. Lenz -
Tony Houghton -
Torgeir Veimo -
Udo Richter -
VDR User -
whoMAN