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
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
Re: [vdr] FF card A/V sync suggestion
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 ___ 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: 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. ___ 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
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
