Re: [vdr] Jittering while playing recording with xinelibout
Am Sun, 7 Oct 2012 14:27:20 +0200 schrieb AlexW honda...@gmx.de: |While playing this converted files in xinelibout, I can see everytime |jittering. (vdr-1.7.31/xinelibout with latest git) | |At the moment I do not know, whats causing this. | Problem seems to be xine-lib. (engine.decoder_priorities.mpeg2) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Jittering while playing recording with xinelibout
Hi list, I am trying to convert .vob to .ts with different tools. Every new generated .ts file plays fine with vlc. While playing this converted files in xinelibout, I can see everytime jittering. (vdr-1.7.31/xinelibout with latest git) Sample: http://www.russle.net/vomp/misc/1.ts.gz At the moment I do not know, whats causing this. Can anybody confirm this? Any Ideas? Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
Hi,
attached is a small patch which I find very useful.
It extends the (Re)PlayButton.
If no last viewed recording was set (mostly after restart of vdr) and
you press the Play Button all Recordings will be shown.
Would be nice, if it find's a way into the main vdr.
BR,
Alex
--- vdr.c.orig 2012-09-24 14:43:04.0 +0200
+++ vdr.c 2012-10-03 10:11:26.775120496 +0200
@@ -1238,6 +1238,9 @@
cControl::Shutdown();
cControl::Launch(new cReplayControl);
}
+ else {
+ DirectMainFunction(osRecordings);
+ }
break;
default:break;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR frontend device: Xtreamer
On 12/06/2009 04:18 PM, Theunis Potgieter wrote: 2009/12/1 alexw al...@undercover.mine.nu mailto:al...@undercover.mine.nu On 11/29/2009 04:13 PM, Theunis Potgieter wrote: 2009/11/27 alexwal...@undercover.mine.nu mailto:al...@undercover.mine.nu: Hi, I do. Do you use an Xtreamer device as a frontend, what are you using to achive this? I am using a PCH-A110 device with vdr-ui running on a separate server (for better integration). Channels are served using the standard streamdev plugin. The only drawback is the necessity to quit (close) the running stream and go back to the vdr-ui selection page each time you want to change to another channel. I have managed to build a jsp playlist with all VDR channels, but channel change is not quick enough to bring a good `surfing` experience with this method. Using xineliboutput you can watch the `live` stream and change channel without quitting the player but the mono pmt parser fails sometime to get the new pids (tested with soft and hard demuxerm. m2ts and pes container). I am convinced that this is the best way to have an acceptable switching time between 2 channels reusing existing player with low key/remote dev (directfb keyb app to redirect remote key to VDR app). I tried this with vdr-1.7.9 and as soon as I switch the channel the Xtreamer device stops. I still need to press stop and play again. Are you using the cvs version of the plugin? If not, you should give it a try. There is a fix which send a new PMT with relevant pids each time a channel is performed. You can verify using a tool like dvbsnoop. If the screen is still black, it is a problem of the PCH player. Even if the new channel is not playing, going back to previous one must show the proper picture. ___ 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] VDR frontend device: Xtreamer
On 11/29/2009 04:13 PM, Theunis Potgieter wrote: 2009/11/27 alexwal...@undercover.mine.nu: Hi, I do. Do you use an Xtreamer device as a frontend, what are you using to achive this? I am using a PCH-A110 device with vdr-ui running on a separate server (for better integration). Channels are served using the standard streamdev plugin. The only drawback is the necessity to quit (close) the running stream and go back to the vdr-ui selection page each time you want to change to another channel. I have managed to build a jsp playlist with all VDR channels, but channel change is not quick enough to bring a good `surfing` experience with this method. Using xineliboutput you can watch the `live` stream and change channel without quitting the player but the mono pmt parser fails sometime to get the new pids (tested with soft and hard demuxerm. m2ts and pes container). I am convinced that this is the best way to have an acceptable switching time between 2 channels reusing existing player with low key/remote dev (directfb keyb app to redirect remote key to VDR app). Alex On 11/27/2009 09:55 AM, Michael Stepanov wrote: I'd like to know if somebody uses any networked media player as VDR client On Fri, Nov 27, 2009 at 9:59 AM, Theunis Potgieter theunis.potgie...@gmail.com wrote: Hi guys, I've recently bought an Xtreamer device www.xtreamer.net (apparently a mvix product). I would just like to know if anybody else got it working with streamdev-server plugin on vdr-1.6.0? Thanks Theunis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Cheers, Michael ___ 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 ___ 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] VDR frontend device: Xtreamer
Hi, I do. Alex On 11/27/2009 09:55 AM, Michael Stepanov wrote: I'd like to know if somebody uses any networked media player as VDR client On Fri, Nov 27, 2009 at 9:59 AM, Theunis Potgieter theunis.potgie...@gmail.com mailto:theunis.potgie...@gmail.com wrote: Hi guys, I've recently bought an Xtreamer device www.xtreamer.net http://www.xtreamer.net (apparently a mvix product). I would just like to know if anybody else got it working with streamdev-server plugin on vdr-1.6.0? Thanks Theunis ___ vdr mailing list vdr@linuxtv.org mailto:vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Cheers, Michael ___ 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] Black screen on some channels with vdr 1.7.6
Hi,
You can also add one more case :
case 0x19: // advanced codec HD digital television service
Rgds,
Alex
Marek Hajduk wrote:
I made recording with vdr 1.7.7 and prewious patches.
I get picture with several errors. Here:
http://rapidshare.com/files/229350889/2009-05-05.10.45.1220-0.rec.tar.gz.html
BR
Marky
Marek Hajduk píše v Út 05. 05. 2009 v 10:41 +0200:
I have tu confirm, that I used both patches and it now works-I get
picture. But picture has errors.
BR
Marky
Ales Jurik píše v Út 05. 05. 2009 v 09:59 +0200:
On Tuesday 05 of May 2009, Klaus Schmidinger wrote:
On 05/05/09 00:04, Ales Jurik wrote:
...
Many thanks, it seems to works (with type of 2), but it is necessary to
set Update channels to no.
Please try this:
--- remux.c 2009/05/03 14:43:25 2.20
+++ remux.c 2009/05/05 07:27:21
@@ -795,6 +795,7 @@
scanner = 8;
scanner |= Data[i];
switch (type) {
+case 0x01: // MPEG 1 video
case 0x02: // MPEG 2 video
if (scanner == 0x0100) { // Picture Start
Code if (synced Processed)
With this you should be able to turn Update channels on again.
Klaus
Thanks for pointing me to the problem. But for working it it was necessary
to
add these two changes more:
--- remux.c 2009-05-05 09:44:01.0 +0200
+++ remux.c 2009-05-05 09:50:56.854167360 +0200
@@ -481,6 +481,7 @@ void cPatPmtParser::ParsePmt(const uchar
for (SI::Loop::Iterator it; Pmt.streamLoop.getNext(stream, it); ) {
dbgpatpmt( stream type = %02X, pid = %d,
stream.getStreamType(), stream.getPid());
switch (stream.getStreamType()) {
+ case 0x01: // MPEG1
case 0x02: // STREAMTYPE_13818_VIDEO
case 0x1B: // MPEG4
vpid = stream.getPid();
@@ -702,7 +703,7 @@ cFrameDetector::cFrameDetector(int Pid,
newFrame = independentFrame = false;
numPtsValues = 0;
numIFrames = 0;
- isVideo = type == 0x02 || type == 0x1B; // MPEG 2 or MPEG 4
+ isVideo = type == 0x01 || type == 0x02 || type == 0x1B; // MPEG 1,2 or 4
frameDuration = 0;
framesInPayloadUnit = framesPerPayloadUnit = 0;
payloadUnitOfFrame = 0;
Now it seems to works as on older vdr versions (with PES), but video
discontinuities are still present on Spektrum (as on many other channels
from
other providers). On STB's these discontinuities are not present in video.
Thanks and BR,
Ales
___
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
___
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] Possibly corrupt stream for VDR frontends in 1.7.4?
Hi, In your capture file, I can see the PAT insertion have a bad TS continuity counter. But his should not prevent from getting the PMT and decoding the stream. PID: 0118x continuity errors (PAT) PID: 97 OK (PMT) PID: 51111x continuity errors (VIDEO) PID: 5158x continuity errors (AUDIO) PID: 18 OK (EIT) PID: 2687 OK PID: 2736 OK PID: 4070 OK PID: 5663 OK It seems that you are loosing packets from your DVB frontends/receiver. Is your computer overloaded during the transmission? Is your DVB card or network card is using shared IRQ? Did you play with the PCI bus latency value? Could you please try the latest VDR version 1.7.5. I made some HD h264 streaming tests with a popcorn hour as client device over a wifi network and the video plays perfectly smooth with the 1.7.5 VDR version. With version 1.7.4 the video was jerky due to TS error on video stream. Cheers, Alex Artem Makhutov wrote: Hello, alexw schrieb: Hi, Could you please check the TS continuity with dvbsnoop when using streamdev or xineliboutput over the network? If not please make a network recording (~ 5 minutes) for both case. 1) Streamdev wget -q -O - http://vdr ip:3000/TS/channel streamdev.ts 2) Xineliboutput (xineliboutput will use the current channel) wget -q -O - http://vdr ip:37890/ xineliboutput.ts If you want to use dvbsnoop pipe the output instead of redirecting to file with: wget cmd | dvbsnoop -nph -s ts -tssubdecode -if - After it is a matter of analysing. I have uploaded a corrupt stream: http://www.makhutov.org/downloads/vdr/streamdev3.ts (wget -q -O - http://192.168.10.2:3000/TS/S19.2E-1-1007-4901.ts streamdev3.ts) What helps is increasing the buffers in .xine/config, but this does not solve the issues: engine.buffers.audio_num_buffers:5000 engine.buffers.video_num_buffers:1 Thanks, Artem ___ 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] Possibly corrupt stream for VDR frontends in 1.7.4?
Artem Makhutov wrote: Hello, currently watching HDTV channels using a VDR frontend (streamdev and xineliboutput - current CVS builds) is impossible for me. Watching the recordings (1.ts) using xine (with VDPAU) works like a charm. I am wondering if there could be a bug in how VDR is presenting the TS data to the frontends. I have just a corrupt video and audio using both plugins. I have also glitches in MPEG2 streams some times, which do not occour when watching the .ts recording directly. Can somebody validate this? Thanks, Artem PS: I saw similar problems while testing the multicast output of streamdev. The STBs I have used for playback did not liked 1500 bytes large packets which streamdev had send out (Xine had no problems in playing them back). When streamdev was changed to send 1316 (7*188) bytes packets the problem was solved for the STBs. Maybe there is something similar with VDR 1.7.4? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi, Could you please check the TS continuity with dvbsnoop when using streamdev or xineliboutput over the network? If not please make a network recording (~ 5 minutes) for both case. 1) Streamdev wget -q -O - http://vdr ip:3000/TS/channel streamdev.ts 2) Xineliboutput (xineliboutput will use the current channel) wget -q -O - http://vdr ip:37890/ xineliboutput.ts If you want to use dvbsnoop pipe the output instead of redirecting to file with: wget cmd | dvbsnoop -nph -s ts -tssubdecode -if - After it is a matter of analysing. Rgds, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Popcorn as VDR frontend
Hi Johan, You have a good approach. I am using the vdr-ui frontend right now which uses the TS from streamdev to feed the mono player. I managed to have a compiled version of the xine lib but I failed to use it due to deep code cutting to get it running. As far as I have understood you succeed to have xine library available on your PCH. Making an adaptation of the OSD layer should then not be a big issue. The complexity will reside in the video stream handling as you have already mentioned. Digging into other projects or starting a discussion in the networkedmediatank can bring a lot of of knowledge here. This project sounds very interesting to me. If you need some help, I would be pleased to provide my support. Regards, Alex Johan Andersson wrote: I need some advise on routes to look into on the subject. First, thank you Klaus and all for a great PVR. I have tried a lot of others like Myth, MediaPortal, GBPVR etc, but the silent menusystems are hopelessly inferior to having all menus on OSD. Me and my family have used VDR for 2+ years now and we are all happy with it. I am not bleeding edge VDR with DVB-T in Sweden being SDTV and we have only one TV-set although I'm running client/server xineliboutpout with a dedicated frontend machine. I bought myself a PCH with the idea of using it instead of my PC VDR frontend. With some effort and googling I got xineliboutputs vdr-fbfe (with xinelib et.al) cross compiled and runnable on the PCH. However AFAIK, the directfb usage in xinelib is based on pixelmaps written to a dfb surface, all mpeg decode is done in software, this is suboptimal on the PCH along with sound being a problem. Running vdr-fbfe on PCH says 'DFBGetSurface() not supported' and exits. It seems people have looked into streamdev instead. I like my VDR OSD though on the TV-set, am I wrong in believing that is a nono with streamdev? Now PCH has an 'IAdvancedMediaProvider' extension to directfb seemingly allowing the mpeg-stream to be sent directly to the hardware, thereby including both video and audio, it is sadly not fully documented in the headers released by Syabas... The most promising option as I see it is to slash down vdr-fbfe to only display the 'osd_command' data on a PCH DFB layer without video capability and stream 'normally' to PCH using ideally the xineliboutputs servers ability to supply for example an http stream. The hope being that the 'vdr-fbfe' application can access directfb concurrently and have the OSD displayed ontop of the video layer. Before I dig deeper into this I would like to ask the community what has been tried and what routes do you see as most viable? I know of some other PCH frontend software for GBPVR Myth, ie vomp and mvcpmx(?) but they seem to return me to the world of silent menus, not a place I want to be. /Johan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
Hi, Yes, I confirm this. With the latest firmware, the memory leakage is gone and the PCH can be used more than 20 min ;-) There is still an issue with the anamorphic parameter. The WSS info is not properly taken into account for the first 16:9 stream played. If you press the zoom factor you will come back to the gaya GUI and next time you want to play a video, it will crash the NMT. The work around consists to play another video type before (mkv/avi...). Otherwise using it as a VDR frontend works perfectly. Cheers, Alex Frank Schmirler wrote: On Mon, 9 Mar 2009 15:23:51 +0100, Tomáš Skočdopole wrote This week I switched to vdr-1.7.4 and streamdev-cvs (both without any patches). Its better than vdr-1.7.0 and streamdev-1.3.4 but popcornhour still sometimes freezes (while watching SD /HDTV channels) and power off from electrical network is needed. On German VDR portal (http://www.vdr-portal.de/board/thread.php?postid=795607#post795607) someone reported that things got much better after updating PCH A-110 firmware to the 2009-02-26 release. Changelog indicates: - Fixed TS with stream6 as teletext playback cause out of memory That would be a reasonable explanation for having to powercycle PCH... Regards, Frank ___ 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] Small VDR-streamdev patch for Popcorn Hour NMT
alexw schrieb: Hi, Yes, I confirm this. With the latest firmware, the memory leakage is gone and the PCH can be used more than 20 min ;-) There is still an issue with the anamorphic parameter. The WSS info is not properly taken into account for the first 16:9 stream played. If you press the zoom factor you will come back to the gaya GUI and next time you want to play a video, it will crash the NMT. The work around consists to play another video type before (mkv/avi...). Otherwise using it as a VDR frontend works perfectly. Cheers, Alex ___ 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] Popcorn as VDR frontend
Hi, VDR-UI uses mono to play the stream. It is impossible for the moment to switch from one channel to another without going back to VDR-UI. I can imagine a workaround that consists of using a playlist instead of a stream URL. But direct channel selection will still not be possible (example: switching from channel 1 to channel 5 directly). Having the full frontend will also bring all the plugin flexibility back to the NMT :o) And recording/cutting/marks/realtime EPG/time shifting... as well Alex jori.hamalai...@teliasonera.com wrote: Before I dig deeper into this I would like to ask the community what has been tried Have you tried vdr-ui, it is a cgi-binary ran on PCH to fetch EPG from VDR and using streamdev to stream. http://www.popcornforum.de/showthread.php?tid=5201pid=71288 and what routes do you see as most viable? Well this sounds the best option for full VDR front-end if recordings work as well.. ___ 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] PMT in multiple TS packet bug
Hi, I did check the TS stream with dvbsnoop and it is not containing corrupted TS packets. Apparently VDR is able to parse the PMT the first time the data buffer is used. Then, it seems to loose the sync inside the payload. I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. http://alexw.org.lu/upload/pmt.pid.132.ts Regards, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
Hi Mika, I have already applied the mentioned patch ;-) But unfortunately it does not solve the issue. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537) Thanks for having spotted that. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote: On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. Hum - PID 132 is a french dolby track, not a PMT PID... Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Frank, good shot. VDR is trying to parse PID 132 as if it was a PMT !!! I have added a log message inside device.c and I have found that patPmtParser.PmtPid() returns pid 132 as PMT. The error can be localized in the patPmtParser.PmtPid function. It is a good progress. PAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0 isNITPid = 0 service id = 132, pid = 132 [5832] PMT PID = 132 PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0 pcr = 120 stream type = 02, pid = 120 stream type = 04, pid = 130 'fra' stream type = 04, pid = 131 'eng' stream type = 04, pid = 133 'deu' stream type = 06, pid = 132 AC3 'fra' [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] PMT PID = 132 [5846] ERROR: can't parse PMT ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote: On 20.01.2009 16:01, Frank Schmirler wrote: On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. Hum - PID 132 is a french dolby track, not a PMT PID... VDR uses the (fixed) pseudo PMT pid 0x0084, which is 132. This was taken from some patch that implemented PAT/PMT handling (don't remember which one it was, maybe it was even the code from reel multimedia - not sure if I've missed mentioning that in the CONTRIBUTORS file). Anyway, I was already wondering if simply using some fixed PMT pid was such a good idea. What if some other stream uses exactly that pid? Apparently this is the case in this example. I confirm, we ran into this special situation. So I guess it will be necessary to first collect all pids and then check whether the default pseudo PMT pid is still free, and if not, incresase it until a free one is found... Too difficult because a low repetition rate PID can be ommitted by the collector. (DTD pid for example) Why not taking the real PMT pid to create the pseudo PID for the PAT? At the moment I do not really understand why this mechanism is needed in transfer mode. Alex 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
[vdr] PMT in multiple TS packet bug
Hi Klaus,
I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still
present in version 1.7.3 but the behaviour is worst because it segfaults.
First I found out that 2 lines where added in the ParsePmt method.
Data += Data[0] + 1; // this is the first packet
Length -= Data[0] + 1;
At the moment I don't know exactly what is the meaning of this 2 operations.
The second line can result in a negative Length which is the reason of the
segfault.
Could you kindly explain the offset drift? In a single section PMT (99.9% of
the time) Data[0] is always equal to 0 and we skip the first byte. Length is
reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to
skip more than a section is not possible in the actual context.
I have done a quick and dirty hack to prevent the segfault:
--- remux.c_ori 2009-01-16 21:05:46.0 +0100
+++ remux.c 2009-01-17 13:34:17.0 +0100
@@ -361,6 +361,7 @@
if (pmtSize == 0) {
Data += Data[0] + 1; // this is the first packet
Length -= Data[0] + 1;
+ if ( Length 0 ) Length = 0;
if (SectionLength(Data, Length) Length) {
if (Length = int(sizeof(pmt))) {
memcpy(pmt, Data, Length);
the second step will be to have the parsing of multiple section allowed. At
the moment when the data size exceed the section size (max 4096), PMT cannot
be parsed.
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: can't parse PMT
[] ERROR: PMT section length too big (4176 byte)!
[] ERROR: can't parse PMT
Regards,
Alex
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
I have already tested the inversion. Reducing the length and after moving to the new offset. This change does not solve the issue. The Length variable can still decrease to a negative value. What happen when the byte offset is greater than 188? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
Yes Frank you are right. The problem is coming from bad CRC in the PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data should be skipped. @Klaus: will you look at this enhancement before rolling out 1.7.4? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
On Tuesday 01 April 2008 01:05:37 Artur Skawina wrote: Alexw wrote: Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log: vdr: [3836] dvbplayer thread started (pid=3643, tid=3836) vdr: [3836] resuming replay at index 1950 (0:01:18.01) vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837) vdr: [3836] SetBrokenLink: no GOP header found in video packet vdr: [3836] setting audio track to 1 (0) vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr' unexpect stop of replay vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837) vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836) vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418 vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627 vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE: 13354 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE: 10286 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE: 31495 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576 vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE: 0 jump: 0 ra: 12582912 vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618) vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617) Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this. Sometimes it take a long time to occur, sometimes not. Did this start after applying my patch, or did it happen in the past too? Does it always happen at a certain position? Specific stream or bitrate? I don't recall ever having a similar problem, the number 524288 looks a bit suspicious... It has been happening in the past. It is not related to the position in the stream nor to the bitrate. It seems to be related to the fact the dvbplayer is starving at this time. I am suspicious about blocking IO read somewhere. I did look at the requested read size and notice that big chunk request are linked to the playback freeze. vdr: [23223] trigger read with 23176 vdr: [23223] trigger read with 52353 vdr: [23223] trigger read with 21065 vdr: [23223] trigger read with 22996 vdr: [23223] trigger read with 51949 vdr: [23223] trigger read with 27058 vdr: [23223] trigger read with 24513 vdr: [23223] trigger read with 50280 vdr: [23223] trigger read with 18108 vdr: [23223] trigger read with 20406 vdr: [23223] trigger read with 101168 -- picture freeze vdr: [23223] trigger read with 20742 vdr: [23223] trigger read with 20922 vdr: [23223] trigger read with 49968 vdr: [23223] trigger read with 21879 vdr: [23223] trigger read with 21630 vdr: [23223] trigger read with 56692 vdr: [23223] trigger read with 24832 vdr: [23223] trigger read with 23184 vdr: [23223] trigger read with 59373 vdr: [23223] trigger read with 24832 vdr: [23223] trigger read with 25949 vdr: [23223] trigger read with 62326 vdr: [23223] trigger read with 27614 vdr: [23223] trigger read with 25029 vdr: [23223] trigger read with 56620 vdr: [23223] trigger read with 27066 vdr: [23223] trigger read with 22845 vdr: [23223] trigger read with 112627 -- picture freeze vdr: [23223] trigger read with 29840 As you can see the requested size is increasing until it reaches the max buf. This is also a period with freezes in the video (late delivery). Do these problems (0-sized reads) occur only near the end of a program being recorded? No, you can experience a stop in the middle of a recording. Also, I see from the above that the readahead code needs to be more aggressive: vdr: [5627] WANT: fd: 25 1188531493 .. 1188861741 SIZE: 330248 [... small reads...] vdr: [5627] READ: fd: 25 1188616808 .. 1189141096 SIZE: 524288 jump: 0 ra: 12582912 the readahead window does not cover the area which is being read later -- this certainly is likely to stall playback. I'll fix this (i did not expect such a large difference in read request sizes.) The attached patch makes the readahead window grow much faster, this will cause more I/O at the start of playback, but should handle cases like the one above better. If it works correctly all the ranges mentioned in READ: lines should be inside the preceding WANT: range and the playback shouldn't stall. I am reaching the maximum readahead window faster (almost 10s after playback starts) with the new patch. vdr: [15502] WANT: fd: 26 1004377827 .. 1015728543 SIZE: 11350716 vdr: [15502] WANT: fd: 26 1004535337 .. 1015998967 SIZE: 11463630 vdr: [15502] WANT
Re: [vdr] Problems playing ongoing recordings?
Artur Skawina a écrit : alexw wrote: On Friday 28 March 2008 14:52:38 alexw wrote: On Thursday 27 March 2008 18:22:35 Artur Skawina wrote: VDR User wrote: On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. I was referring to playing a finished recording and playing a file that is currently being extended by the server vdr -- alexw said that doesn't work well for him. It should, unless the disk and/or fs can't handle the two data streams concurrently, while keeping the latency low enough. I'm assuming the vdr server in powerful enough to handle the load, yes. My setup is a little bit more complicated as it is using a share drive on both machine. The two local disks are only CF. The file server is compose of 4x SATA II 500GB in raid 5 (total ~1.5 TB available) piloted by a promise controller and a fully idle 3 GHz P4 CPU. The throughput or the sustained write/read access is not a bottleneck. Here is a quick ASCII art drawing: /-- 100M --[AP]~ WIFI 54Mb ~[vdr client/FF]-[TV] [switch]--- 100M ---[CIFS/fileserver] \-- 100M -- [vdr server/B2C2]-DVB-S+DVB-T This evening I will test the provided patch. Using the patch provided by Artur, playing a finished/ongoing recording is smoother than before. Thank you for testing (and for enabling the extra logging). Does smoother than before mean that there is some improvement, but the playback still isn't perfect? The fact that the recorder hangs on to the last 4M of the stream and the data is appended in large chunks can cause problems when timeshifting by just a few seconds -- the player could try to access the not yet written data. This should only happen at the very end of an ongoing recording, within 4M of EOF (depending on the bitrate usually a couple of seconds after the live program arrived). The playback is really improved, especially when doing timeshift recording. I will try to identify the reason why I am having (sporadic) freezes. Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log: vdr: [3836] dvbplayer thread started (pid=3643, tid=3836) vdr: [3836] resuming replay at index 1950 (0:01:18.01) vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837) vdr: [3836] SetBrokenLink: no GOP header found in video packet vdr: [3836] setting audio track to 1 (0) vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr' unexpect stop of replay vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837) vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836) - vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418 vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627 vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE: 13354 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE: 10286 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE: 31495 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576 vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE: 0 jump: 0 ra: 12582912 vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618) vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617) Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this. Sometimes it take a long time to occur, sometimes not. - vdr: [5627] READ: fd: 25 1188203807 .. 1188214024 SIZE: 10217 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188214024 .. 1188226152 SIZE: 12128 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188226152 .. 1188267411 SIZE: 41259 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188267411 .. 1188503927 SIZE: 236516 vdr: [5627] READ: fd: 25 1188267411 .. 1188278781 SIZE: 11370 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188278781 .. 1188292400 SIZE: 13619 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188292400 .. 1188335024 SIZE: 42624 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188335024 .. 1188589175 SIZE: 254151 vdr: [5627] READ: fd: 25 1188335024 .. 1188344461 SIZE: 9437 jump
Re: [vdr] Problems playing ongoing recordings?
On Thursday 27 March 2008 18:22:35 Artur Skawina wrote: VDR User wrote: On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. I was referring to playing a finished recording and playing a file that is currently being extended by the server vdr -- alexw said that doesn't work well for him. It should, unless the disk and/or fs can't handle the two data streams concurrently, while keeping the latency low enough. I'm assuming the vdr server in powerful enough to handle the load, yes. artur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi, My setup is a little bit more complicated as it is using a share drive on both machine. The two local disks are only CF. The file server is compose of 4x SATA II 500GB in raid 5 (total ~1.5 TB available) piloted by a promise controller and a fully idle 3 GHz P4 CPU. The throughput or the sustained write/read access is not a bottleneck. Here is a quick ASCII art drawing: /-- 100M --[AP]~ WIFI 54Mb ~[vdr client/FF]-[TV] | [switch]--- 100M ---[CIFS/fileserver] | \-- 100M -- [vdr server/B2C2]-DVB-S+DVB-T This evening I will test the provided patch. Rgds, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
On Wednesday 26 March 2008 21:51:06 VDR User wrote: On Wed, Mar 26, 2008 at 12:03 PM, Artur Skawina [EMAIL PROTECTED] wrote: kind of hard to describe something you no longer remember... ;) I _think_ the issue was some kind of stuttering playback; it didn't happen always, but often enough that one day i decided to see if writing the stream in much larger chunks would help. It did; never seen it since. The only time I've heard about people having stuttering playback of recordings was when DMA wasn't turned on for their harddrive(s). Other then that, I don't know what to tell you. I playback recordings while they're still recording all the time and never experienced any problems. Maybe someone else can comment about this but otherwise it seems to be a dead topic. Artur is right. I am using the following VDR setup: 2 VDR machines in client(FF)/server(budget) mode (thank to streamdev) over wifi. The video folder is shared over the network in CIFS (aka Samba). Actually replaying VDR recording is not smooth all the time and the timeshifting on the client side is not working at all. Recording on the server and playing on the client at the same time result in smooth and freeze cycle with lip sync issue. Watching live programs is perfect. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Streaming service (UDP streamdev and DLNA plugin)
Dear VDR users, I did try to get info about 2 projects discussed here and in dvb forum in the past. At the moment I did not find any good status information. 1) The UDP client/server implementation for the streamdev plugin. It was planned to reduce the number of ack sent by the client on a wifi link. 2) The UPNP (DLNA) plugin implementation to turn VDR into a full IPTV server. If someone has more information Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
On Wednesday 14 November 2007 13:19:39 Pasi Kärkkäinen wrote: On Tue, Nov 13, 2007 at 03:41:05PM +0100, alexw wrote: On Tuesday 13 November 2007 15:16:32 Graziano Pavone wrote: Hi, Using my PS3 as a vdr client is also my target. But I experienced bad (de-)interlacing when watching SD TV using SD output (even with right resolution). I am now waiting the new HV xorg driver to have more control on the video than the already available fb blit mechanism. I did rewrite the fb driver of xinelib to enhace it with ps3 blit functionality and virtual fb but it did not improve the output quality. By the way, the PS3 have a colorspace issue to display the OSD with proper color palette under the fb. (X is not affected by this) Actually I am using streamdev and xineliboutput together. Xineliboutput is good to pilot the server side from any linux based system. Streamdev + FF card + vdr is the best deal for client device (I am using this solution over wifi and it works like a charm) Streamdev + m3u patch is ideal to use VLC with playlist and allow Win OS to access the TV programs. Hi, I would like to use my PS3 as vdr client as well. I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..) Can you give more details of what are you using on your PS3? Thanks, Graziano Sure, Standard FC 7 (I will soon upgrade it to FC 8) modified version of iwconfig to allow wpa-psk(2) to work Xine-lib cvs (v1.1.6) vdr-sxfe or vdr-fbfe as needed The PS3 is connected to a SD TV set. As you can see it is not something complicated. Apparently when trying the same thing with HD (720p/1080p) television gives better result. (talking about picture quality) To enhance the picture quality on a SD TV you can deinterlace in sw before displaying the picture. The drawback is that an interlaced source is de-interlaced then interlaced again to coop with PAL standard. If you do that (deinterlace, then interlace again) you lose half of the framerate if you're using normal plugins for deinterlacing.. interlaced tv is 50/60 fields/sec, and after deinterlacing you usually end up with 25/30 frames/sec.. half of the motion/movement information just disappeared. end result is that your live video (series,sports,news) starts to look like jerky and shaky.. If you have interlaced output best option would be to display each field as it comes in (1:1).. then you would get best possible quality. If you have progressive display device, then best option is to use full-fps deinterlacing, meaning 50 fields/sec ends up 50 frames/sec, or even 100 frames/sec containing all the motion/movement info.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi, I did test 1:1 output (PAL 720x576 - 720x576) but due to bad VSYNC the output is shaky. The kernel API provided for the vsync is not working very well with SD content. Unfortunately I do not have a progressive display. Rgds, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
On Tuesday 13 November 2007 13:50:42 mike lewis wrote: On Nov 13, 2007 7:12 PM, [EMAIL PROTECTED] wrote: mike lewis [EMAIL PROTECTED] writes: Hi, I've used vdr-xine, and I've used xinelibout for vdr. I've just ogt a general question, as they both seem to have similar functionality (or at least they both satisfy my need for a software client head to vdr. What's the driver for vdr-xine? I've heard people say xinelibout is better because it is more stable. But, whats the reality? If you've used both you should be able to compare them, shouldn't you ? Well no, as I used them in the past and my media box died; and my memory isn't all that good.. so now I'm re-assessing my new solution based on running linux on a ps3; and I can't compare them until I've installed them both... Which is basically what I want to avoid ;-). I've also used both. Now i'm only using xineliboutput because (just facts, no attack !) - it has support for network without patching for longer - it doesn't require me to recompile libxine - network features are more advanced - i can have more that one frontend watching/sharing the same channel. - now i just aptitude install libxine1-xvdr to install the client side. Yes, the support for users like me on something like ubuntu is one reason why i'm likely to go down the path xinelibout. Obviously the two plugins are both great plugins. And, Reinhard you do a really good job providing patches for vdr xine ! Thanks a lot. I guess the hidden question was have you ever considered to merge the two projects ?, wasn't it ? :) Well no, my question probably should have been: whats the difference between the two plugins; if I'm using either simply as a software headend (similar to softdevice, but not permanently on) is their any feature which would drive the selection of xinelibout over vdr-xine? My question would be: one vdr, one xineliboutput plugin, 2 dvb cards, 2 independant frontends displaying different channels(+osd and stuff) without streamdev, has it been considered ? :) I think the answer there is to use one vdr per head-end. Thanks for jumping on board the QA session! hehe.' Mick ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi, Using my PS3 as a vdr client is also my target. But I experienced bad (de-)interlacing when watching SD TV using SD output (even with right resolution). I am now waiting the new HV xorg driver to have more control on the video than the already available fb blit mechanism. I did rewrite the fb driver of xinelib to enhace it with ps3 blit functionality and virtual fb but it did not improve the output quality. By the way, the PS3 have a colorspace issue to display the OSD with proper color palette under the fb. (X is not affected by this) Actually I am using streamdev and xineliboutput together. Xineliboutput is good to pilot the server side from any linux based system. Streamdev + FF card + vdr is the best deal for client device (I am using this solution over wifi and it works like a charm) Streamdev + m3u patch is ideal to use VLC with playlist and allow Win OS to access the TV programs. If you want to start developping good SD support for the PS3 I would be pleased to provide some help. Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
On Tuesday 13 November 2007 15:51:06 Graziano Pavone wrote: Sure, Standard FC 7 (I will soon upgrade it to FC 8) modified version of iwconfig to allow wpa-psk(2) to work Xine-lib cvs (v1.1.6) vdr-sxfe or vdr-fbfe as needed I'm using Ubuntu, with wired ethernet. connection So both framebuffer and xorg with xineliboutput are working? Did you compile them yourself, or there are binaries qavailable for Fedora? What about CPU usage. Is the PS3 able to display everything smoothly (with and without the OSD)? I am compiling everything myself because I need to apply some patch to enable new features. (kernel side, library side). But if you want to avoid hacking the system you need to find a ppc repository containing VDR packages, especially xinelibouput plugin. Yes, the PS3 is able to display both video and OSD smoothly. As I said earlier the SD picture quality is really not optimum. May be someone can comment 720p or 1080p outputs? The PS3 is connected to a SD TV set. As you can see it is not something complicated. Apparently when trying the same thing with HD (720p/1080p) television gives better result. (talking about picture quality) To enhance the picture quality on a SD TV you can deinterlace in sw before displaying the picture. The drawback is that an interlaced source is de-interlaced then interlaced again to coop with PAL standard. My PS3 is connected to a 720p display, so this should not be a problem... if it's not a problem for CPU usage... You are a lucky guy ;-) Is your TV able to upscale SD content or do you plan to do the up-scaling job in software? I did put this project on hold until better fb or xv support is popping up ;-) May be you will also be interested to have a look here: http://forums.ps2dev.org/viewtopic.php?t=8364postdays=0postorder=ascst art=0 thanks for all the informations!! You're welcome. Ciao, Graziano ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.5.x + streamdev issue
Hi, I am using VDR 1.5.2 in a streamdev only environment. With the vanilla CVS version of streamdev I am receiving a channel picture after every 2 channel switches. I did a bug report and schmirl did post a quick fix. Unfortunately it is not 100% perfect and time to time the picture does not pop up on the screen. Is anyone else experiencing such behavior? Mantis bug tracking system: http://www.vdr-developer.org/mantisbt/view.php?id=255 Cheers, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
