Re: [vdr] FF card A/V sync suggestion
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 ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 [EMAIL PROTECTED] wrote: Udo Richter wrote:So much for that theory. I've wrote an experimental patch to VDR to fixthis specific stream, but playback is the same, even with the fixed PTSjitter. :(Cheers,Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. whoman421On 11/3/06, VDR User [EMAIL PROTECTED] 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 alot 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 listvdr@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
Re: [vdr] FF card A/V sync suggestion
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. It doesn't transcode MPEG2. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 -- VDR Remote Plugin 0.3.8 available at http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
if i make this, the file play fine (vdr ffcard) : mv 001.vdr _001.vdr mv index.vdr _index.vdr mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr genindex But now the file 001.vdr is 100Mb ! Am I doing something wrong? I dont seem to have any sound.. also if you move 001.vdr to _001.vdr, then the command below will not be able to find the file. :) Sorry for the typo : mplayer -vo mpegpes:001.vdr -ao mpegpes _001.vdr -- Guy Roussin ___ http://www.teledetection.fr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On Mon, 23 Oct 2006 17:49:38 +0200 Joerg Knitter [EMAIL PROTECTED] 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 -- ---MR.- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 21.10.2006 15.58, Oliver Endriss [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Hi, Timothy D. Lenz wrote: The way I understand it, the shows are sent as mpeg2, VDR decodes to raw data and stores as xxx.vdr files Now vdr file are raw data sent by the card : ie mpeg2. Have you an idea of the size of uncompressed video ? Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. Hmm... 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. Hmm... 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. Hmm... 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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
Re: [vdr] FF card A/V sync suggestion
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
Re: [vdr] FF card A/V sync suggestion
On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Tero Siironen wrote: On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Klaus Schmidinger [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Juri Haberland wrote: Klaus Schmidinger [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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. 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). For proper seeking, a program must be able to read the index.vdr file. Everything else is educated guessing. 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. Only one program can use the DVB card. And if mplayer uses it, then VDR cannot. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
