Re: [vdr] vdr Digest, Vol 72, Issue 30
hello, sorry for just jumpin in. haven't read the whole thread, and i don't know all details, i just want to say: my current (ya)vdr: - asus at3iont-t (deluxe, for extern 19V) attached to my flat, sound over hdmi - it has serial port, and one pci-e. - mc-1200 case (but built-in remote not really working yet) the only noise is now coming from my harddrives, as this machine currently is more than a video player. so an ssd would make this machine completly silent. sometimes the cpu heat is nearly 60C°, but as i said, i do more than just watching tv and hd movies. in this case, the machine gets instable. xbmc can play 1080p, but more details i can't say, for i have not that knowledge... -- Brain fried - core dumped. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Collecting patches for vdr-xine-0.9.4
On Lunes, 17 de Enero de 2011 21:37:06 Reinhard Nissl escribió: > Hi, > > it looks like I can find more time this week to work on vdr-xine. > > I've seen some patches for vdr-xine-0.9.3 (and xine-lib) in the > mailing list which address so far unsupported audio formats if I > recall correctly, as vdr-xine still uses PES and my c*Repackers. > > I'd like to invite you to send them again to me (privately). A > sample recording would be appreciated too. > > Bye. Attached are two patches to play dolby digital plus audio with vdr-xine. One for vdr-xine and another for xine-lib. There is an aditional patch to play dolby digital plus audio with xine-lib and a ts file. Jose Alberto diff -ur xine-0.9.3/vdr172remux.c xine-0.9.3.new/vdr172remux.c --- xine-0.9.3/vdr172remux.c 2009-04-12 13:52:32.0 +0200 +++ xine-0.9.3.new/vdr172remux.c 2010-09-29 01:58:34.79803 +0200 @@ -1703,8 +1703,20 @@ const uchar *Payload = Data + PesPayloadOffset; const int PayloadCount = Count - PesPayloadOffset; + bool ac3; + int framesize; + unsigned short size; - if (Data[3] == 0xBD && PayloadCount >= 9 && ((Payload[0] & 0xF0) == 0x80) && Payload[4] == 0x0B && Payload[5] == 0x77 && frameSizes[Payload[8]] > 0) { + if (PayloadCount < 10) + return -1; + ac3 = ((Payload[9] >> 3) & 0x1f) <= 10; + if ( ac3) + framesize = frameSizes[Payload[8]]; + else { + size = Payload[7] + Payload[6] * 256; + framesize = ((size & 0x07FF) + 1) << 1; + } + if (Data[3] == 0xBD && ((Payload[0] & 0xF0) == 0x80) && Payload[4] == 0x0B && Payload[5] == 0x77 && framesize > 0) { if (TrackIndex) *TrackIndex = Payload[0] - 0x80; @@ -1860,6 +1872,7 @@ int done = 6 + 3 + Data[8]; int todo = Count - done; const uchar *data = Data + done; + unsigned short size; // look for 0x0B 0x77 while (todo > 0) { @@ -1906,7 +1919,12 @@ state++; continue; case get_length: - ac3todo = 2 * frameSizes[*data]; + if (((*(data + 1) >> 3) & 0x1f) <= 10) + ac3todo = 2 * frameSizes[*data]; + else { + size = chk2 + chk1 * 256; + ac3todo = ((size & 0x07FF) + 1) << 1; + } // frameSizeCode was invalid => restart searching if (ac3todo <= 0) { // reset PES header instead of using a wrong one @@ -1971,6 +1989,10 @@ int cDolbyRepacker::BreakAt(const uchar *Data, int Count) { + bool ac3; + int framesize; + unsigned short size; + if (initiallySyncing) return -1; // fill the packet buffer completely until we have synced once // enough data for test? @@ -1984,12 +2006,20 @@ if (ac3todo > 0) return headerLen + ac3todo; // enough data for test? - if (Count < headerLen + 5) + if (Count < headerLen + 6) return -1; const uchar *data = Data + headerLen; // break after ac3 frame? - if (data[0] == 0x0B && data[1] == 0x77 && frameSizes[data[4]] > 0) - return headerLen + 2 * frameSizes[data[4]]; + ac3 = ((data[5] >> 3) & 0x1f) <= 10; + if ( ac3) + framesize = 2 * frameSizes[data[4]]; + else { + size = data[3] + data[2] * 256; + framesize = ((size & 0x07FF) + 1) << 1; + } + if (data[0] == 0x0B && data[1] == 0x77 && framesize > 0) + return headerLen + framesize; + return -1; } diff -r 9679028a161b src/demuxers/demux_mpeg_pes.c --- a/src/demuxers/demux_mpeg_pes.c Wed Jul 21 15:52:00 2010 + +++ b/src/demuxers/demux_mpeg_pes.c Tue Sep 21 00:54:22 2010 +0200 @@ -103,6 +103,7 @@ uint8_t preview_data[ MAX_PREVIEW_SIZE ]; off_t preview_size, preview_done; + uint8_t preview_eac3; } demux_mpeg_pes_t ; typedef struct { @@ -931,10 +932,21 @@ buf->content = p+4; buf->size = this->packet_len-4; - if (track & 0x8) { -buf->type = BUF_AUDIO_DTS + (track & 0x07); /* DVDs only have 8 tracks */ + if (((p[9] >> 3) & 0x1f) <= 10) { +if (track & 0x8) { + buf->type = BUF_AUDIO_DTS + (track & 0x07); /* DVDs only have 8 tracks */ +} else { + buf->type = BUF_AUDIO_A52 + track; +} } else { -buf->type = BUF_AUDIO_A52 + track; +buf->type = BUF_AUDIO_EAC3; +if (this->preview_eac3 < 2) + this->preview_eac3++; +if (this->preview_eac3 == 1) + buf->decoder_flags = BUF_FLAG_HEADER | BUF_FLAG_FRAME_END; +else { + buf->decoder_flags |= BUF_FLAG_FRAME_END; +} } buf->pts = this->pts; if( !this->preview_mode ) @@ -1548,6 +1560,7 @@ */ this->last_cell_time = 0; this->send_newpts = 1; + this->preview_eac3 = 0; if( !playing ) { this->buf_flag_seek = 0; diff -r 03d01d484189 src/demuxers/demux_ts.c --- a/src/demuxers/demux_ts.c Thu Sep 23 18:19:29 2010 +0100 +++ b/src/demuxers/demux_ts.c Sun Oct 03 23:47:39
[vdr] Collecting patches for vdr-xine-0.9.4
Hi, it looks like I can find more time this week to work on vdr-xine. I've seen some patches for vdr-xine-0.9.3 (and xine-lib) in the mailing list which address so far unsupported audio formats if I recall correctly, as vdr-xine still uses PES and my c*Repackers. I'd like to invite you to send them again to me (privately). A sample recording would be appreciated too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, 16 Jan 2011 10:46:27 -0800 VDR User wrote: > On Sun, Jan 16, 2011 at 10:22 AM, Tony Houghton wrote: > > >> Maybe a better idea is to not assume anything at all, but rather > >> actually look up real life data or just buy one and see for yourself > >> (as I did). There's no reason to take guesses about any of this > >> stuff, plenty of users have posts their results and specs at various > >> forums. A good place to start would be nvnews.net and read the thread > >> "VDPAU testing tool". > > > > The results don't give the right information to determine how well a > > card can handle 1080i. > > You apparently don't know the results come from analyzing actual > playback of actual samples of actual content. Yes, the data tells you > exactly what kind of performance you can expect since it's generated > from actual use cases. Again, stop assuming everything and turning > your nose up at first-hand experience. I've ran those tests myself, > obviously know what deinterlacers I'm using, and have watched plenty > of content seeing the result with my own eyes from the hardware we're > talking about. Additionally I've done the same with various hardware > configurations.. What you're telling people simply doesn't agree with > reality. I've attached the results of qvdpautest on my desktop PC. Some of the examples appeared to have no more than 2 or 3 frames. Does the test generate a 'realistic' stream using the same few source frames over and over again? Even if it does, it seems a rather narrow sample. The MIXER results show unrealistically high fps. Evidently the deinterlacing is not being performed at the same time as decoding in these tests. I suppose it's easy enough to caclulate the frame rate of both operations combined for a worst case, but how do you know to what extent they can be performed in parallel? qvdpautest 0.5.1 AMD Athlon(tm) II X4 620 Processor NVIDIA GPU GeForce 9800 GTX+ (G92) at PCI:1:0:0 (GPU-0) VDPAU API version : 1 VDPAU implementation : NVIDIA VDPAU Driver Shared Library 260.19.21 Thu Nov 4 21:46:12 PDT 2010 SURFACE GET BITS: 968.203 M/s SURFACE PUT BITS: 1021.38 M/s MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 154 frames/s H264 DECODING (1920x1080): 45 frames/s H264 DECODING (1280x720): 99 frames/s VC1 DECODING (1440x1080): 122 frames/s MIXER WEAVE (1920x1080): 2785 frames/s MIXER BOB (1920x1080): 4807 fields/s MIXER TEMPORAL (1920x1080): 1235 fields/s MIXER TEMPORAL + IVTC (1920x1080): 756 fields/s MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 1629 fields/s MIXER TEMPORAL_SPATIAL (1920x1080): 485 fields/s MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 387 fields/s MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 538 fields/s MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 1682 fields/s MULTITHREADED MPEG DECODING (1920x1080): 75 frames/s MULTITHREADED MIXER TEMPORAL (1920x1080): 1032 fields/s ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr