Beta version of vdr with dvb-s2 support

Zitat

Original von ollo
ich habe Deinen Patch mal eingebaut und 2 Aufnahmen gemacht und diese dann versucht mit dem MPlayer abzuspielen:

MPlayer hat derzeit keinen Code, der in PES-Paketen H.264 Videodaten erkennen würde. Leider gibt es im PES-Header auch kein Flag, um soetwas anzuzeigen.
Es würde also nur ein statistischer Ansatz helfen, so wie ihn MPlayer verwendet, um PES von ES zu unterscheiden. In H.264 kommt kein "Startcode" außerhalb des Bereichs [1..19] vor, wohingegen der Picture-Startcode von MPEG z. B. 0 ist oder Sequence-Startcode und dergleichen oberhalb von 0xaf liegen.

Bye.

Hi,

Zitat

Original von egal
jo, ebenfalls EInsFestivalHD aufgenommen;
auch xine (1.1.7) erkennt kein video.

Habe mal die "primary_picture_type" (oder so) bytes mit "00" hinter der AUD-Kennung "09" auf > "0x00" geändert, also anstatt "00 00 01 09 00" z.B. "00 00 01 09 10";
dann erkennt xine die Aufnahme und spielt sie komplett ab.

Verstehe ich nicht.

/soft/bin/xine --verbose=2 -V xxmc -A alsa -L --post vdr_video --post vdr_audio --post upmix_mono --post upmix "/video/@EinsFestival_HD/2007-08-26.19.05.50.50.rec/001.vdr#demux:mpeg_pes" -D

spielt hier problemlos. Ist aber xine-lib-1.1.8-pre + vdr-xine-0.7.11-Patch (in 1.2-pre ist bereits alles "all inclusive"), doch hat sich da seit 1.1.7 nichts mehr getan (soweit ich mich erinnere).

Bye.

Hi,

Zitat

Original von rnissl
Hi,

Verstehe ich nicht.

Code

/soft/bin/xine --verbose=2 -V xxmc -A alsa -L --post vdr_video --post vdr_audio --post upmix_mono --post upmix "/video/@EinsFestival_HD/2007-08-26.19.05.50.50.rec/001.vdr#demux:mpeg_pes" -D

spielt hier problemlos. Ist aber xine-lib-1.1.8-pre + vdr-xine-0.7.11-Patch (in 1.2-pre ist bereits alles "all inclusive"), doch hat sich da seit 1.1.7 nichts mehr getan (soweit ich mich erinnere).

Alles anzeigen

So, hab mal xine-1.2pre (1.1.90) installiert (vdr-xine-0.7.11-Patch finde ich net), gleiches Ergebnis:

Zitat

# xine --verbose=2 -V xv efhd-funztnet.vdr
Dies ist xine (X11 gui) - Ein freier Video-Player v0.99.5.
(c) 2000-2007 Das xine Team.
Kompiliert mit xine Bibliothek 1.1.90 (1.1.90hg)
xine Bibliothek, Version 1.1.90 (1.1.90hg) gefunden.
<...>
ebml: invalid EBML ID size (0x0) at position 1
ebml: invalid master element
load_plugins: probing demux 'mpeg_block'
load_plugins: probing demux 'mpeg_pes'
xine: Demultiplexer-Plugin gefunden: mpeg pes demux plugin
audio discontinuity #1, type is 0, disc_off 0
waiting for in_discontinuity update #1
video discontinuity #1, type is 0, disc_off 0
vpts adjusted with prebuffer to 44105
load_plugins: plugin ffmpegvideo will be used for video streamtype 4d.
av_offset=0 pts
spu_offset=0 pts
xine_play
video discontinuity #2, type is 2, disc_off 4351770038
waiting for audio discontinuity #2
audio discontinuity #2, type is 2, disc_off 4351770038
waiting for in_discontinuity update #2
ffmpeg_video_dec: error decompressing frame
[h264 @ 0xb6713fb4]non existing PPS referenced
[h264 @ 0xb6713fb4]decode_slice_header error
[h264 @ 0xb6713fb4]no frame!
ffmpeg_video_dec: error decompressing frame
[h264 @ 0xb6713fb4]non existing PPS referenced
[h264 @ 0xb6713fb4]decode_slice_header error
[h264 @ 0xb6713fb4]no frame!

<... usw. bis zum fileende>

Alles anzeigen

Hier mal die Aufnahme

Hi,

Zitat

Original von egal
Habe mal die "primary_picture_type" (oder so) bytes mit "00" hinter der AUD-Kennung "09" auf > "0x00" geändert, also anstatt "00 00 01 09 00" z.B. "00 00 01 09 10";
dann erkennt xine die Aufnahme und spielt sie komplett ab.

Ja gut dass man ein fleißiges Unterbewustsein hat: es hat die ganze Nacht gearbeitet und mir am Morgen unterbreitet, dass ich rbsp_railing_bits() vergessen hatte. Das ist nämlich die 10, wie du mir oben gezeigt hast, aber gestern hab' ich das nicht überrissen.

Die zu ändernden Codeteile lauten dann:

// enter primary_pic_type into AUD
        Data[ PesPayloadOffset + 4 ] |= primary_pic_type << 5;

// add an AUD in H.264 mode when not present in stream
  if (h264Parser && !audSeen) {
     pesHeader[pesHeaderLen++] = 0x00;
     pesHeader[pesHeaderLen++] = 0x00;
     pesHeader[pesHeaderLen++] = 0x01;
     pesHeader[pesHeaderLen++] = 0x09; // access unit delimiter
     pesHeader[pesHeaderLen++] = 0x10; // will be filled later
     }

Bye.

Hi,

Zitat

Original von egal
So, hab mal xine-1.2pre (1.1.90) installiert (vdr-xine-0.7.11-Patch finde ich net), gleiches Ergebnis.

Hier mal die Aufnahme

Hhm, die Aufnahme spielt hier problemlos, ist aber -- wie bereits festgestellt -- falsch. Dass sie spielt liegt wohl am recht alten FFmpeg der xine-lib-1.1.8-pre.

Nutzt xine-lib-1.2-pre nicht das bereits im System installierte FFmpeg?

Den vdr-xine-0.7.11-Patch kannst du noch nicht finden, da er noch nicht veröffentlicht ist. Er wird nur benötigt, wenn xine-lib-1.1.8-pre verwendet werden soll.

Man hat mich informiert, dass es demnächst CoreAVC-Unterstützung für xine-lib-1.2-pre geben soll. Ein erster Hack soll bereits funktioniert haben -- jetzt wäre also der "clean rewrite" dran.

Bye.

Hi,

hier mal Reinhards aktuelle vdr-1.5.9-h264-Patches für vdr-1.4.7.
(Achtung: Änderung an der channels.conf sind nicht mehr rückwärtskompatibel)

Die Aufnahmen auf EInsFestival HD sehen soweit ganz gut aus;
zumind. xine spielt das ordentlich (im Rahmen meiner Uni-CoreCPU) ab.

Audio-Resync nur zu Beginn des Trailer-Loops, liegt wohl am Sender.

Hi,

Zitat

Original von egal
hier mal Reinhards aktuelle vdr-1.5.9-h264-Patches für vdr-1.4.7.
(Achtung: Änderung an der channels.conf sind nicht mehr rückwärtskompatibel)

Um das etwas zu erläutern: H.264 Kanäle werden durch addieren von 10000 zur eigentlichen VPID [0..8191] gekennzeichnet. Sonst hat sich an der channels.conf nichts geändert. Kann ein ungepatchter VDR-1.4.x so eine channels.conf dann nicht mehr laden?

Zitat

Original von egal
Die Aufnahmen auf EInsFestival HD sehen soweit ganz gut aus;
zumind. xine spielt das ordentlich (im Rahmen meiner Uni-CoreCPU) ab.

Wäre schon nett, wenn das jemand mal mit einer ordentlichen CPU testen würde. Das soll kein Vorwurf sein -- ich war selber auch zu faul, den P4 2.8 GHz HT von 09/2003 gegen was modernes auszutauschen.

Bye.

Ich habe hier Core Duo 2 zum spielen...aber ich brauche vdr-xine... sobald vdr-xine-0.7.11-Patch kommt, probiere ich alles

Also ich hab hier softdevice laufen (nutzt ja ffmpeg zur dekodierung). Mein Core2Duo E4500 mit 1GB RAM bringt HD1 (ist hier im Kabel) Ruckelfrei bei ca. 50% Last auf meinen 37" Toshiba LCD.

Mangels DVB-S kann ich leider EFHD nicht testen.
Meine Apple H.264 Trailer laufen jedoch ruckelfrei. Demzufolge sollte ein Core2Duo unter 2GHz locker ausreichen (vorausgesetzt, DirectFB, vidix oder was anderes beschleunigendes ist im Einsatz).

Zitat

Original von neumann2k
Also ich hab hier softdevice laufen (nutzt ja ffmpeg zur dekodierung). Mein Core2Duo E4500 mit 1GB RAM bringt HD1 (ist hier im Kabel) Ruckelfrei bei ca. 50% Last auf meinen 37" Toshiba LCD.

Du glücklicher. Ich bin hier am kämpfen, aber mit vdr-1.5.9 und Reinhards patches aus der ml klappt es viel schlechter als mit der vdr-1.5.5 version von Anfang Juli.
Also:
vdr-1.5.5: DVB-S mit Bild und Ton; DVB-S2 nur Ton.

@900 DVB-S2 |-)
ASTRA HD+:11915:hM8S0Z0:S19.2E:27500:1279:1283:0:0:131:0:6:0
ASTRA HD;BetaDigital:12722:hC23M5S1Z35:S19.2E:22000:10767+767:768=deu:0:0:10202:1:1119:0
ANIXE HD;BetaDigital:12722:hC23M5S1Z35:S19.2E:22000:11023+1023:0;1027=deu:0:0:10203:1:1119:0
ProSieben;ProSiebenSat.1:12544:hC56M2S0Z0:S19.2E:22000:511:512=deu;515=deu:33:0:17501:1:1107:0
ProSieben HD;ProSiebenSat.1:12722:hC23M5S1Z35:S19.2E:22000:10255+255:0;259=deu:0:0:10200:1:1119:0
SAT.1;ProSiebenSat.1:12544:hC56M2S0Z0:S19.2E:22000:255:256=deu;259=deu:32:32:17500:1:1107:0
Sat.1 HD;ProSiebenSat.1:12722:hC23M5S1Z35:S19.2E:22000:10511+511:0;515=deu:0:0:10201:1:1119:0
:@950 HDTV channels
EinsFestival HD;ARD:12422:hC34S0Z0:S19.2E:27500:11601+1601:0:0:0:28396:1:1201:0
:@1001 DVB-S
Das Erste;ARD:11837:hC34S0Z0:S19.2E:27500:101:102=deu,103=2ch;106=dd:104:0:28106:1:1101:0
ZDF;ZDFvision:11954:hS0Z0:S19.2E:27500:110:120=deu,121=2ch;125=dd:130:0:28006:1:1079:0
3sat;ZDFvision:11954:hS0Z0:S19.2E:27500:210:220=deu,221=2ch;225=dd:230:0:28007:1:1079

Aus dmesg:

[ 2678.416000] stb0899_read_status: Delivery system DVB-S2
[ 2678.416000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf340], Data=[0x00000003]
[ 2678.416000] stb0899_read_status: UWP & CSM Lock ! ---> DVB-S2 FE_HAS_CARRIER
[ 2678.416000] _stb0899_read_reg: Reg=[0xf619], data=13
[ 2678.416000] _stb0899_read_reg: Reg=[0xf6ff], data=00
[ 2678.416000] stb0899_read_status: Packet Delineator Locked ! -----> DVB-S2 FE_HAS_LOCK
[ 2678.416000] stb0899_read_status: Packet Delineator found SYNC ! -----> DVB-S2 FE_HAS_SYNC
[ 2678.416000] stb0899_get_params: Get DVB-S2 params
[ 2678.416000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf370], Data=[0x00000000]
[ 2678.416000] stb0899_track: Lock Lost=[0x00]

Mit vdr-1.5.9 und den ml patches vom 29.08 von Reinhard: DVB-S Kanal nicht verfügbar; DVB-S2

:@900 DVB-S2 |-)
ASTRA HD+:11915:h:S19.2E:27500:1279:1283:0:0:131:0:6:0
ProSieben HD:12722:h:S19.2E:22000:255:0;259=deu:0:0:10200:0:1119:0
Sat.1 HD:12722:h:S19.2E:22000:511:0;515=deu:0:0:10201:0:1119:0
:@1001 DVB-S
Das Erste;ARD:11837:hC34:S19.2E:27500:10101+101:102=deu,103=2ch;106=dd:104:6:28106:1:1101:0
ZDF;ZDFvision:11954:hC34:S19.2E:27500:110:120=deu,121=2ch;125=dd:130:6:28006:1:1079:0
rbb Berlin;ARD:12110:hC34:S19.2E:27500:601:602=deu:604:6:28206:1:1073:0
hr-fernsehen;ARD:11837:hC34:S19.2E:27500:301:302=deu:304:6:28108:1:1101:0
:@1250 HDTV channels
EinsFestival HD;ARD:12422:hC34:S19.2E:27500:11601+1601:0:0:0:28396:1:1201:0

Aus dmesg:

[ 3510.356000] stb0899_read_status: Delivery system DVB-S2
[ 3510.356000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf340], Data=[0x00000000]
[ 3510.368000] stb0899_read_status: Delivery system DVB-S2
[ 3510.368000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf340], Data=[0x00000000]
[ 3510.380000] stb0899_read_status: Delivery system DVB-S2
[ 3510.380000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf340], Data=[0x00000000]
[ 3510.392000] stb0899_read_status: Delivery system DVB-S2
[ 3510.392000] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x00000400], Offset=[0xf340], Data=[0x00000000]

Der Treiber ist in beiden Fällen der von Manu http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2
mit dem diff von Marco vom 11.7. (tt3200.diff; 34451 Bytes)

Hab das Gefühl ein s..d..... Fehler gemacht zu haben :-((

Stefan

Hallo Stefan,

hast du die Änderungen für die Frontend-API mit in den Vdr 1.5.9 übernommen?

Ansonsten schau dir mal die Modulationsparameter an.

Mit Reinhard's Patch alleine läuft die TT 3200 nicht.

bis dann LordZodiac

Hi,

Zitat

Original von LordZodiac
hast du die Änderungen für die Frontend-API mit in den Vdr 1.5.9 übernommen?

Ansonsten schau dir mal die Modulationsparameter an.

Mit Reinhard's Patch alleine läuft die TT 3200 nicht.

Da hab ich wieder was angerichtet -- blos weil ich mich nicht mit anderer Leute guter Arbeit schmücken wollte.

Um den DVB-S2 Support beizubehalten dürfen nur die Änderungen am Makefile, remux.c und h264parser.[ch] übernommen werden (wenn der Patch auf einen separaten "vanilla" VDR-1.5.9 angewendet wurde).

Bye.

Zitat

Original von LordZodiac
Hallo Stefan,

hast du die Änderungen für die Frontend-API mit in den Vdr 1.5.9 übernommen?

2.ter Versuch, den Ersten hat der Kernel beendet, indem irgend welche Prozesse gekillt wurden :-(( (der memory overcommit Bug im Kernel lebt wohl am längsten).

Aug 31 20:25:18 jarada [ 4284.480000] Out of memory: kill process 7228 (bash) score 51095 or a child
Aug 31 20:25:18 jarada [ 4284.480000] Killed process 8746 (vdr)
Aug 31 20:25:18 jarada [ 4284.484000] Out of memory: kill process 7228 (bash) score 43804 or a child
Aug 31 20:25:18 jarada [ 4284.484000] Killed process 8747 (vdr)

Ich habe aus dem tar-file mit "vdr-1.5.6-remux264-dvbs2.patch" den remux Teil rausgeschnitten und aus Reinhards patch nur Makefile, remux.[ch] und h264*.[ch] verwendet. Damit ist es aber insgesamt schlechter als gestern mit nem älteren gepachten Treiber.

Aug 31 20:24:54 jarada [ 4259.336000] lowmem_reserve[]: 0 0 1013
Aug 31 20:24:54 jarada vdr: [8762] ERROR: driver buffer overflow on device 1
Aug 31 20:24:54 jarada vdr: [8762] ERROR: driver buffer overflow on device 1
Aug 31 20:24:55 jarada [ 4259.336000] HighMem free:120kB min:128kB low:260kB high:396kB active:126140kB inactive:0kB present:129732kB pages_scanned:507342 all_unreclaimable? yes
Aug 31 20:24:55 jarada [ 4259.336000] lowmem_reserve[]: 0 0 0

Aber ich hab jetzt mal nen kleinen Test via streamdev -> mplayer gemacht, und da hab ich Bild und Ton ;;;-). Der X2 3800+ EE ist zu langsam, da mplayer single-threaded ist und nur ein Kern jeweils auf 100% war. Bei "EinsFestival" in der Aufnahme von vorhin sagen sowohl ffplay als auch mplayer "ton ja", "video no".

Stefan

Hey Stephan,

ist zwar mega offtopic hier, aber kann es sein, dass ich mit vidix ein
viel schöneres Bild mit meiner Radeon bekomme ? Das Bild ist heller, sieht viel viel besser auf meinem LCD aus.

Vidix läuft mit xineliboutput, aber nicht mit softdevice. Woran kann das liegen? Softdevice sagt nur:

Aug 31 21:47:10 (none) vdr: [2853] initializing plugin: softdevice (0.4.0): A software emulated MPEG2 device
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] DirectColor FB found
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] xres = 1920 yres= 1080
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] line length = 7680
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] bpp = 32
Aug 31 21:47:10 (none) vdr: [2861] section handler thread started (pid=2853, tid=2861)
Aug 31 21:47:10 (none) vdr: [2860] tuner on device 2 thread started (pid=2853, tid=2860)
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] vidix version: 100
Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] Couldn't find working VIDIX driver exiting

xineliboutput läuft wie gesagt mit vidix.

Zitat

Original von neumann2k
Hey Stephan,

ist zwar mega offtopic hier,

Ja, .. aber

Zitat

Aug 31 21:47:10 (none) vdr: [2853] [cVidixVideoOut] Couldn't find working VIDIX driver exiting

Schau mal in config.h (von softdevice) nach, wie da "VIDIX_DIR" gesetzt ist und welche Dateien in diesem Verzeichnis sind, bei mir:

-rwxr-xr-x 1 root root 16084 Mar 31 20:58 cyberblade_vid.so
-rwxr-xr-x 1 root root  9227 Mar 31 20:58 genfb_vid.so
-rwxr-xr-x 1 root root 24425 Mar 31 20:58 mach64_vid.so
-rwxr-xr-x 1 root root 16376 Mar 31 20:58 mga_crtc2_vid.so
-rwxr-xr-x 1 root root 14580 Mar 31 20:58 mga_tv_vid.so
-rwxr-xr-x 1 root root 14981 Mar 31 20:58 mga_vid.so
-rwxr-xr-x 1 root root 16719 Mar 31 20:58 nvidia_vid.so
-rwxr-xr-x 1 root root  9935 Mar 31 20:58 pm2_vid.so
-rwxr-xr-x 1 root root 15695 Mar 31 20:58 pm3_vid.so
-rwxr-xr-x 1 root root 42538 Mar 31 20:58 radeon_vid.so
-rwxr-xr-x 1 root root 38101 Mar 31 20:58 rage128_vid.so
-rwxr-xr-x 1 root root 16305 Mar 31 20:58 savage_vid.so
-rwxr-xr-x 1 root root 27396 Mar 31 20:58 sis_vid.so
-rwxr-xr-x 1 root root 13151 Mar 31 20:58 unichrome_vid.so

Wenn's daran nicht liegen sollte, dann mach mal nen separaten Thread auf.

Stefan

Zitat

Vidix läuft mit xineliboutput, aber nicht mit softdevice. Woran kann das liegen?

Der Möglichkeiten gibts da einige:
VDR als Root zu laufen?
Softdevice mit Vidix übersetzt?
Hast du nen Framebuffer Treiber geladen den Vidix per Softdevice nutzen kann?

Hi,

ich hab vidix neu drübergebügelt und jetzt läuft es, komisch...

Scheinbar gibts bei vidix nen problem mit 1080p clips/sendern.

Versuch, ein HDTV Trailer abzuspielen (Aplle Trailer, 1080p)

22:51:06.0991 D [2724] [VideoOut] reset: sync info: repF = 137, drpF = 0, totF = 1082
Drop Packet PTS: 0
#Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test':
Duration: 00:02:30.2, start: 0.000000, bitrate: 9053 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 1920x800, 23.98 fps(r)
Stream #0.1(eng): Audio: aac, 44100 Hz, stereo
Stream #0.2(eng): Data: tmcd / 0x64636D74
allocating buffer format orig->format 0
22:51:07.0009 D [2726] [softdevice-audio]: Xrun (at least 0.224 ms long)
22:51:07.0018 I [2725] [cVidixVideoOut] Video changed format to 1920x800
22:51:07.0018 E [2725] [cVidixVideoOut] Can't configure playback: Function not implemented exiting

Mit DirectFB läuft er.

Gleiches beim umschalten auf HD1:

22:52:54.0445 I [2753] [cVidixVideoOut] Video changed format to 1920x1088
22:52:54.0445 E [2753] [cVidixVideoOut] Can't configure playback: Function not implemented exiting

Kannst Du hier dran was drehen?

Zitat

Original von tr500

Der Möglichkeiten gibts da einige:
VDR als Root zu laufen?
Softdevice mit Vidix übersetzt?
Hast du nen Framebuffer Treiber geladen den Vidix per Softdevice nutzen kann?

3 mal Ja. Lösung siehe weiter unten. Jetzt hör ich aber auf, hier den Thread zuzumüllen.

:moin,

inzwichen habe ich mal das aktuelle vdr-xine installiert und kann damit auch die HDTV Sender sehen - allerdings kommt bei EinsFestivalHD kein Ton?! Bei Astra HD kommt anfangs ein Ton, der aber schnell stottert und dann gnaz abbricht. Ok, wahrscheinlich ist einfach mein System zu lahm (Athlon-XP@2.2GHz). Ich bekomme perodisch folgendes um die Ohren gehauen:

+++ CLEAR(1a)
=== CLEAR(1.1)
=== CLEAR(1.2)
=== CLEAR(1.3)
=== CLEAR(1.4)
=== CLEAR(1.5)
--- CLEAR(1a)
+++ CLEAR(1b)
=== CLEAR(1.1)
=== CLEAR(1.2)
=== CLEAR(1.3)
=== CLEAR(1.4)
=== CLEAR(1.5)
--- CLEAR(1b)
bad_frame
bad_frame
bad_frame
bad_frame
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
bad_frame
bad_frame
bad_frame

Gruß, ollo

Hi,

Zitat

Original von ollo
inzwichen habe ich mal das aktuelle vdr-xine installiert und kann damit auch die HDTV Sender sehen - allerdings kommt bei EinsFestivalHD kein Ton?! Bei Astra HD kommt anfangs ein Ton, der aber schnell stottert und dann gnaz abbricht. Ok, wahrscheinlich ist einfach mein System zu lahm (Athlon-XP@2.2GHz). Ich bekomme perodisch folgendes um die Ohren gehauen:

Diff

+++ CLEAR(1a)
=== CLEAR(1.1)
=== CLEAR(1.2)
=== CLEAR(1.3)
=== CLEAR(1.4)
=== CLEAR(1.5)
--- CLEAR(1a)
+++ CLEAR(1b)
=== CLEAR(1.1)
=== CLEAR(1.2)
=== CLEAR(1.3)
=== CLEAR(1.4)
=== CLEAR(1.5)
--- CLEAR(1b)
bad_frame
bad_frame
bad_frame
bad_frame
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
[h264 @ 0xb67f1914]non existing PPS referenced
[h264 @ 0xb67f1914]decode_slice_header error
bad_frame
bad_frame
bad_frame
bad_frame

Alles anzeigen

Ja, wenn das System nicht mithalten kann, dann stehen im VDR-Log auch jede Menge "possible buffer overflow ... bytes dropped". Ich hätte das vielleicht etwas schöner lösen sollen -- dann gäb's öfter ein Clear() aber letztendlich wäre das Resultat ähnlich.

Bye.