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] How to record H.264 stream in VDR?
Hi, dvb wrote: No luck with this patch (1.4.1 1.4.3) :( they(tv company) use MPEG2 ID in H.264 stream PID found: 512 (0x0200) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] Oct 20 18:40:09 testbox vdr: [17201] switching to channel 11 Oct 20 18:40:39 testbox vdr: [17881] ERROR: video data stream broken Just an idea: maybe you should disable cVideoRepacker. See remux.c #define TEST_cVideoRepacker. cVideoRepacker can currently only parse MPEG1 and MPEG2 video streams. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[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
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
[vdr] Can xineliboutput and dxr3 coexist?
Hi, I've got VDR (1.4.3) running on a machine by my TV and have just been playing with the xineliboutput plugin to stream vdr over the network. Everything works well on its own but I'd like to be able to have someone watching TV on one channel via the dxr3 and someone else watching a recording on the network via xineliboutput. Is this possible? Currently, if I install the xineliboutput plugin then there is no longer any output to the TV via the dxr3. Thanks Glyn ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can xineliboutput and dxr3 coexist?
En/na Glyn Edwards ha escrit: Hi, I've got VDR (1.4.3) running on a machine by my TV and have just been playing with the xineliboutput plugin to stream vdr over the network. Everything works well on its own but I'd like to be able to have someone watching TV on one channel via the dxr3 and someone else watching a recording on the network via xineliboutput. Is this possible? Currently, if I install the xineliboutput plugin then there is no longer any output to the TV via the dxr3. I don't know how xineliboutput works, but I'm currently using a dxr3 and xine (with the network patches). When xine is used (i.e. the client connects) it becomes the primary device and there's no more output on the dxr3, when xine disconnects output resumes on the dxr3. If you want to see two different channels, one on the dxr3 and another one via xine (or xineliboutput?) I'm afraid you have to use streamdev server and a different vdr instance as a streamdev client. I don't know the current status of streamdev though, and if what you're asking is possible to do with a recording (probably yes if both vdr instances share the same video directory). Bye -- - Yo también quiero una Europa libre de Patentes de Software - - I want a Software Patents Free Europe too! And you? - --- EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es signature.asc Description: OpenPGP digital signature ___ 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] Can xineliboutput and dxr3 coexist?
Glyn Edwards wrote: I've got VDR (1.4.3) running on a machine by my TV and have just been playing with the xineliboutput plugin to stream vdr over the network. Everything works well on its own but I'd like to be able to have someone watching TV on one channel via the dxr3 and someone else watching a recording on the network via xineliboutput. Is this possible? Currently, if I install the xineliboutput plugin then there is no longer any output to the TV via the dxr3. For me it works, if I use the --primary switch on xineliboutput. However, I have a FF card. I can watch normally on the FF card as long as no xineliboutput client connects, and I can watch remotely with the xineliboutput client. Since VDR can only handle one primary device, you cannot use both at the same time of course. 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
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
[vdr] xinelibout Overscan doesn't work with local frontend
Seems that when runnin xinelibout with local frontend Overscan crop doesn't work. If I run remote frontend vdr-sxfe it crops just right. I'm running vdr-1.4.3-2 and xineliboutput-1.0.0pre6 -Pxineliboutput --local=sxfe --video=xv --remote=37890 -- Jussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
