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
