You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Urig

Professional

  • "Urig" started this thread

Posts: 1,222

Location: Kassel

  • Send private message

1

Sunday, February 20th 2011, 9:40pm

[ANNOUNCE] naludump-0.1 - NALU fill data Patch

Hallo Portal,

Ich hab die endgültige Version 0.1 meines h.264 nalu fill data removal Tools + Patch veröffetlicht.

Der Patch löscht NALU fill data aus h.264 Streams während der Aufnahme. Die Videostruktur wird dabei weitgehend beibehalten, nur TS-Pakete, die komplett aus NALU fill bestehen, werden entfernt. Auf HD-Kanälen mit fixer Videobandbreite kann das 40-60% der Dateigröße einsparen, ohne Bildinformationen zu verlieren.

Der Patch wird unter Einstellungen -> Aufnahmen aktiviert, und kann für einzelne Aufnahmen mit dem Schlüsselwort NALUDUMP und NALUKEEP aktiviert bzw. deaktiviert werden.

Vom Standalone-Tool gibt es auch eine überarbeitete Version, die die gleichen Buffer-Routinen wie der Patch verwendet, sonst aber identische Dateien erzeugen sollte.

Für weitere Details siehe Vorgänger-Posts:
TSDoctor für VDR? - Filler Data Entfernen
[ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool

Patch / Quelltext gibt's hier:

http://www.udo-richter.de/vdr/naludump.html

Gruß,

Udo

2

Monday, February 21st 2011, 8:19am

Yeah...vielen Dank!

Gruß
iNOB

Mein VDR

Hartware: Gehäuse: Ahanix MCE 302, Mobo: Kontron 986LCD-M/mITX, CPU: Intel Core2 Duo Mobile T7400 2,16GHz, 2GB RAM, SAT: Digital Devices DuoFlex S2 miniPCIe, Graka: ASUS EN210 Silent 1GD3, 4x2TB 3,5" WD HD, 1x DVD-Brenner Pioneer, Atric IR-Einschalter+Empfänger, FB One-For-All URC-7960, SoundGraph iMON LCD ( MFP5I, 15c2:0038 )
Weichware: Wheezy (x86_64), Kernel 3.8.13, NVidia v337.12, VDR 2.1.6 gepatched

Paulaner

Professional

Posts: 920

Location: Märkisch-Oderland

  • Send private message

3

Thursday, March 10th 2011, 8:58am

RE: [ANNOUNCE] naludump-0.1 - NALU fill data Patch

Quoted

Original von Urig
Der Patch wird unter Einstellungen -> Aufnahmen aktiviert, und kann für einzelne Aufnahmen mit dem Schlüsselwort NALUDUMP und NALUKEEP aktiviert bzw. deaktiviert werden.

Hallo Udo,
ich habe gestern einen Test mit Deinem "NALU fill data Patch" gemacht.
Hat erst einmal einwandfrei geklappt mit einer Aufnahme von Arte-HD, wo ca. 30% Speicherplatz eingespart wurden. Suuper! :]

Ich habe die Patch-Version gewählt und unter "Aufnahmen" den NALU dump aktiviert.
Meine Frage ist, wie hast Du das gemeint, mit dem Schlüsselwort "NALUDUMP" bzw. "NALUKEEP"? Wo und wie muss ich die einstellen?

Paulaner

meine aktuelle Hard- und Software

Hardware: . . . . . Asus P8Z77-V_LX, Intel i5-2500, 4GB DDR3, Grafik Zotac Zone Edition GT630, 1x Single-DVB-TBS8922, 1x Dual-DVB-TBS6981, 2x WD20EFRX, 6,4"-TFT-Display
Produktiv-VDR: . . yaVDR-0.5 - Kernel 3.11.0 - vdr-2.0.x - nvidia-331 . . . . . . . . . . . .Fernbed.: Philips SBC RU760 . . . . . LCD-FullHD-TV: Philips 47PFL9732
Reserve-VDR: . . . . yaVDR-0.5 - Kernel 3.2.0 - vdr-2.0.x - nvidia-331 auf Extra-Partition vom Produktiv-VDR, falls der Produktiv-VDR wiedermal kaputt gespielt wurde! :-)

Urig

Professional

  • "Urig" started this thread

Posts: 1,222

Location: Kassel

  • Send private message

4

Sunday, March 13th 2011, 1:13pm

Zwei Anwendungen: Erstens, du bist besorgt, der Patch könnte die Aufnahme deiner Lieblingsserie ruinieren: Dann machst du zwei Aufnahmen, eine nach "Meine Serie~Aufnahme", die zweite nach "Meine Serie~Aufnahme NALUKEEP". Die erste ist gefiltert, die zweite ungefiltert.

Zweitens, du bist ein Weichei, und hast den Patch sicherheitshalber deaktiviert. Dann kannst du zum Ausprobieren deine Serie einmal als "Meine Serie~Aufnahme NALUDUMP" und einmal als "Meine Serie~Aufnahme" aufnehmen. Wieder ist die erste gefiltert, die zweite - und alle normalen Aufnahmen - ungefiltert.

Gruß,

Udo

KiLLERHOLiC

Intermediate

Posts: 157

Location: Österreich

  • Send private message

5

Sunday, April 3rd 2011, 10:40am

Nachdem ich diesen Thread gestern zufällig entdeckt habe hab ich meinen VDR (von 1.7.13 auf 1.7.17) auf den neuesten Stand gebracht und deinen Patch gleich angewendet.
Zum testen hab ich 10 Minuten von ORF 1 HD mit aktiviertem und ohne aktiviertem Patch aufgenommen (waren 2 Zeitgleiche Aufnahmen, also selber Inhalt). Der Unterschied waren 35MB. Hab mir die kleinere Datei mit VLC angesehen und konnte keine Fehler entdecken. Funktioniert also perfekt (und auch mit VDR 1.7.17)! Danke!
Debian 6, Gigabyte GA-M720-US3, 6GB DDR2-RAM, 1x500GB, 4x1TB, 1x1,5TB, AMD Athlon II X4 620 @ 1,1Volt, 3x Terratec Cinergy 1200 DVB-C, 1x Satelco Easywatch DVB-C, onboard 1GBit Lan
VDR-1.7.22, Plugins: EPG-Search, Streamdev-Server, control , wirbelscan

Posts: 4,706

Location: Main-Spessart

  • Send private message

6

Sunday, April 3rd 2011, 10:42am

Hat ORF überhaupt NALU-Füll-Daten?

Klingt ehr danach, als ob du einfach einen minimalen Versatz zwischen den Aufnahmen hast.
VDR4Arch-Next --> Lian-Li PC-C37B | Gigabyte GA-MA78LMT-US2H | AMD Athlon II X2 250 | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

KiLLERHOLiC

Intermediate

Posts: 157

Location: Österreich

  • Send private message

7

Sunday, April 3rd 2011, 10:56am

Hat ORF überhaupt NALU-Füll-Daten?

Klingt ehr danach, als ob du einfach einen minimalen Versatz zwischen den Aufnahmen hast.
Nein, die Aufnahmen waren gleich lang und fingen auch gleichzeitig an.
Siehe auch hier: [ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool
Debian 6, Gigabyte GA-M720-US3, 6GB DDR2-RAM, 1x500GB, 4x1TB, 1x1,5TB, AMD Athlon II X4 620 @ 1,1Volt, 3x Terratec Cinergy 1200 DVB-C, 1x Satelco Easywatch DVB-C, onboard 1GBit Lan
VDR-1.7.22, Plugins: EPG-Search, Streamdev-Server, control , wirbelscan

Posts: 4,706

Location: Main-Spessart

  • Send private message

8

Sunday, April 3rd 2011, 11:00am

OK, ich dachte immer, das nur die deutschen ÖRs NALU haben.
VDR4Arch-Next --> Lian-Li PC-C37B | Gigabyte GA-MA78LMT-US2H | AMD Athlon II X2 250 | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

jsffm

Professional

Posts: 1,498

Location: Frankfurt/M

  • Send private message

9

Sunday, April 3rd 2011, 11:31am

ORF hat NALU-Füll Daten, aber etwas weniger.

Mein VDR

VDR1 Mediaportal mit QVT-Board, Intel 810 Chipsatz, Pentium III 1,1 Ghz, 256 Mb Ram, WDC WD5000AAKB, DVB-S TT 1.5, Nova-S, Digidish 33, Gentoo Kernel 2.6.31, VDR 1.4.7
VDR2 Asrock M3N78D, Athlon X2 240e, 8 Gb Ram, Geforce GT 430, SL DVB-T, AirStar 2, MSI DIGIVOX Duo, PVR 350, Gentoo Kernel 3.10.17, VDR 2.0.6, softhddevice
VDR3 MC-1200, M3N78-EM, Athlon X2 235e, 2G Ram, WD20EARS, Mystique SaTiX-S2 Dual (v2), TT Budget S2-1600, Nova-TD Stick, Gentoo Kernel 3.9.11-r1, VDR 2.0.4, softhddevice
TV TX-37LZD85F, AV VSX-S500 - Consono 35


vdr-User-# 755 to_h264 chk_r

10

Sunday, April 3rd 2011, 11:57am

OK, ich dachte immer, das nur die deutschen ÖRs NALU haben.

Die Füll-Daten werden in unterschiedlichen Ausprägungen alle europäischen Sender haben, die nach der EBU Empfehlung in 720p senden. Aber selbst Aufnahmen von ServusTV HD (1920x1080i) enthalten Füll-Daten, sehr wenig, sind aber vorhanden ...

Regards
fnu
Gib HD+/CI+ keine Chance! >> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610, 4GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, L4M Twin S2 (V5.6)/FlexS2 (4x DVB-S2), rt Unicable®, CIR, Ubuntu LTS 12.04.4, VDR 2.1.6 (x64, 44W)
[²] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH61CR, G540, 2GB DDR3, WD10EADS 1TB, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP, rt Unicable®, mceusb, Ubuntu Trusty, VDR 2.1.6 (x64, 40W)
[³] Cooler Master Elite 360, Xilence SPS-XP250.SFX (250W), Intel DH77KC, Xeon E3-1245v2, 8GB DDR3, Intel 313 SSD 24GB (Sys & HostCache), HP SA P400 256MB BBWC, 4x WD7500BPXX@Backpl., L4M Twin S2 (V5.4), VMWare ESXi 5.5 (6 VM)(x64, 45W)

11

Wednesday, February 22nd 2012, 1:50pm

Hallo Udo,

die Möglichkeit die 720p Aufnahmen auf im Schnit 55% zu schrumpfen finde ich genial und nutze sie seit ca. einem Jahr durch durch das externe Programm. Seit vdr-1.7.22 nutze ich den patch (aus dem g2v-extpatch von Helau). Beides funktioniert innerhalb des VDR problemlos. Auch xbmc und vlc haben keine Probleme.

Da ich aber dies Aufnahmen gerne auch auf einem Tegra2 Tablett nutzen möchte, wandele ich mit Handbrake:

Source code

1
HandBrakeCLI -i $i  -o $DESTDIR/$(basename $i ts)m4v  -e x264 -q 20.0 -a 1 -E faac -B 128 -6 stereo -R Auto -D 3.0 -f mp4 --loose-anamorphic --modulus 16 -m -x ref=4:deblock=-2,-1:mixed-refs=0:analyse=some -w 1280 -X 1280 -Y 720 --crop autocrop --large-file >> /var/log/transcode.log 2>&1


Jetzt wirds magisch: Aufnahmen, die ich ohne vdr-patch hinterher mit naludump schrumpfe funktionieren problemlos - Aufnahmen die mit dem Patch gleich beim Aufnehmen geschrumpft werden (und die im vdr, xbmc und vlc problemlos laufen) erzeugen in handbrake folgende Fehler:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
[13:36:25] sync: adding 86 ms of silence to audio 6020  start 112970065, next 112962240
Encoding: task 1 of 1, 100.00 %[13:36:25] sync: audio 6020 time went backwards 0 ms, dropped 4 frames (next 113091840, current 113091840)
[13:36:25] sync: video time didn't advance - dropped 6 frames (delta 117 ms, current 113212911, next 113213122, dur 211)
Encoding: task 1 of 1, 100.00 %[13:36:25] sync: adding 114 ms of silence to audio 6020  start 113197202, next 113186880
Encoding: task 1 of 1, 100.00 %[13:36:26] sync: audio 6020 time went backwards 0 ms, dropped 15 frames (next 113267520, current 113267520)
[13:36:26] sync: video time didn't advance - dropped 17 frames (delta 324 ms, current 113382270, next 113383660, dur 1390)
Encoding: task 1 of 1, 100.00 %[13:36:26] sync: audio 6020 time went backwards 0 ms, dropped 13 frames (next 113407920, current 113407920)
[13:36:26] sync: video time didn't advance - dropped 17 frames (delta 331 ms, current 113527409, next 113528214, dur 805)
Encoding: task 1 of 1, 100.00 %[13:36:26] sync: audio 6020 time went backwards 0 ms, dropped 13 frames (next 113552640, current 113552640)
[13:36:26] sync: video time didn't advance - dropped 18 frames (delta 342 ms, current 113674058, next 113675656, dur 1598)
Encoding: task 1 of 1, 100.00 %[13:36:27] sync: audio 6020 time went backwards 0 ms, dropped 6 frames (next 113697360, current 113697360)
[13:36:27] sync: video time didn't advance - dropped 8 frames (delta 159 ms, current 113817869, next 113817879, dur 10)
Encoding: task 1 of 1, 100.00 %[13:36:27] sync: audio 6020 time went backwards 0 ms, dropped 15 frames (next 113857200, current 113857200)
[13:36:27] sync: video time didn't advance - dropped 18 frames (delta 359 ms, current 113976513, next 113976562, dur 49)
Encoding: task 1 of 1, 100.00 %[13:36:41] sync: audio 6020 time went backwards 0 ms, dropped 13 frames (next 117712800, current 117712800)
[13:36:41] sync: video time didn't advance - dropped 16 frames (delta 310 ms, current 117830762, next 117831591, dur 829)
[13:36:41] sync: adding 100 ms of silence to audio 6020  start 117797486, next 117788400
Encoding: task 1 of 1, 100.00 %[13:36:41] sync: audio 6020 time went backwards 0 ms, dropped 15 frames (next 117866160, current 117866160)
[13:36:41] sync: video time didn't advance - dropped 17 frames (delta 325 ms, current 117982554, next 117983860, dur 1306)
Encoding: task 1 of 1, 100.00 %[13:36:41] sync: adding 83 ms of silence to audio 6020  start 117944929, next 117937440
[13:36:41] sync: audio 6020 time went backwards 0 ms, dropped 8 frames (next 118015200, current 118015200)
Encoding: task 1 of 1, 100.00 %[13:36:41] sync: video time didn't advance - dropped 8 frames (delta 152 ms, current 118129996, next 118130652, dur 656)
Encoding: task 1 of 1, 100.00 %[13:36:42] sync: audio 6020 time went backwards 0 ms, dropped 15 frames (next 118170720, current 118170720)
[13:36:42] sync: video time didn't advance - dropped 18 frames (delta 359 ms, current 118289345, next 118289421, dur 76)
Encoding: task 1 of 1, 100.00 %[13:36:42] sync: audio 6020 time went backwards 0 ms, dropped 16 frames (next 118311120, current 118311120)
[13:36:42] sync: video time didn't advance - dropped 19 frames (delta 365 ms, current 118428863, next 118430170, dur 1307)
Encoding: task 1 of 1, 100.00 %[13:36:43] sync: audio 6020 time went backwards 0 ms, dropped 16 frames (next 118449360, current 118449360)
Encoding: task 1 of 1, 100.00 %[13:36:43] sync: video time didn't advance - dropped 19 frames (delta 370 ms, current 118566779, next 118567617, dur 838)
Encoding: task 1 of 1, 100.00 %[13:36:43] sync: audio 6020 time went backwards 0 ms, dropped 17 frames (next 118587600, current 118587600)
[13:36:43] sync: video time didn't advance - dropped 19 frames (delta 375 ms, current 118703372, next 118703821, dur 449)
Encoding: task 1 of 1, 100.00 %[13:36:43] sync: audio 6020 time went backwards 0 ms, dropped 17 frames (next 118723680, current 118723680)
Encoding: task 1 of 1, 100.00 %[13:36:44] sync: video time didn't advance - dropped 19 frames (delta 378 ms, current 118838869, next 118838998, dur 129)
[13:36:44] sync: audio 6020 time went backwards 0 ms, dropped 2 frames (next 118790640, current 118790640)
Encoding: task 1 of 1, 100.00 %[13:36:44] sync: audio 6020 time went backwards 0 ms, dropped 16 frames (next 118855440, current 118855440)
[13:36:44] sync: video time didn't advance - dropped 20 frames (delta 381 ms, current 118973463, next 118975127, dur 1664)
[13:36:44] hb_ts_stream_decode - eof
[13:36:44] stream: 70191 good frames, 0 errors (0%)
[13:36:44] reader: done. 419 scr changes
[13:36:44] sync: audio 6020 time went backwards 0 ms, dropped 2 frames (next 118924560, current 118924560)
Encoding: task 1 of 1, 100.00 %[13:36:45] work: average encoding speed for job is 140.512665 fps
Encoding: task 1 of 1, 100.00 %[13:36:45] sync: got 66212 frames, 60990 expected
[13:36:45] h264-decoder done: 70166 frames, 0 decoder errors, 0 drops
[13:36:45] render: 33083 frames output, 33139 dropped and 10 duped for CFR/PFR
[13:36:45] render: lost time: 0 (0 frames)
[13:36:45] render: gained time: 0 (0 frames) (0 not accounted for)
Das resultierende Video ist nicht mehr guckbar - da springen und ruckeln die Bilder und der Soundtrack scheint von einem Scratcher auf Crack zu stammen.

Nach meinem nicht vorhandenen Verständinis nach, passiert im naludump das gleiche wie im patch, aber da irre ich wohl, da ich das zu 100% reproduzieren kann.

Zu den Versionen

Patch: g2v-ext von Helau
naludump: 0.1 von Deiner Seite

Gruß, Ingo
gen2vdr v3, Asus M4N78 Pro, 4GB 1033, Haupauge WinTV Nova-HD S2, CineS2, z.Z. Asus gts450silent
Der wichtigste Befehl der Welt: /_config/bin/g2v_log.sh -v

mini73

Moderator

Posts: 5,085

Location: Flensburg

  • Send private message

12

Wednesday, February 22nd 2012, 3:54pm

Moin!

Könnte es sein, dass du den nalustripper-Patch von MartenR benutzt und nicht den naludump-Patch von Udo?
Vergleich doch mal bitte den Patch-Source.

Lars.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

13

Thursday, February 23rd 2012, 9:23am

Hi,

@lars: Du hast recht. Im ext-patch ist anderer nalu Code. Zu meiner Schande muss ich gestehen, dass ich den Patch von Udo mit dem externen Programm von Udo verglichen habe - aber keinen Blick in die Sourcen des gepatchten VDR geworfen habe...

@udo: vergiss mein Posting, sorry.

Gruß, Ingo
gen2vdr v3, Asus M4N78 Pro, 4GB 1033, Haupauge WinTV Nova-HD S2, CineS2, z.Z. Asus gts450silent
Der wichtigste Befehl der Welt: /_config/bin/g2v_log.sh -v

14

Friday, February 24th 2012, 7:06pm

Was bedeuten eigentlich diese Meldungen im syslog? Die hatte ich bei einem Test, bei dem auf einer S2-1600 eine Aufnahme lief, und die andere S2-1600 mittels ezap fortlaufend durch die Sender gezappt hat. Ich wollte wissen, ob das Zappen der einen die andere Karte negativ beeinflusst. Da ich diese Meldungen sonst nicht habe, nehme ich an, dass sie zeigen, dass der Stream tatsächlich gestört wurde, oder?

Source code

1
2
3
4
5
6
7
8
9
10
11
12
Feb 24 15:52:02 vdr vdr: [7628] cNaluDumper: TS continuity offset 8
Feb 24 16:01:44 vdr vdr: [7628] cNaluDumper: Unexpected NALU fill data: f7
Feb 24 16:01:44 vdr vdr: [7628] cNaluDumper: TS continuity offset 1
Feb 24 16:01:44 vdr vdr: [7628] cNaluDumper: TS continuity offset 12
Feb 24 16:03:15 vdr vdr: [7628] cNaluDumper: TS continuity offset 13
Feb 24 16:03:15 vdr vdr: [7628] cNaluDumper: TS continuity offset 13
Feb 24 17:17:59 vdr vdr: [7628] cNaluDumper: Unexpected NALU fill data: bf
Feb 24 17:17:59 vdr vdr: [7628] cNaluDumper: TS continuity offset 14
Feb 24 17:17:59 vdr vdr: [7628] cNaluDumper: TS continuity offset 15
Feb 24 17:17:59 vdr vdr: [7628] cNaluDumper: TS continuity offset 15
Feb 24 17:58:46 vdr vdr: [7628] cNaluDumper: TS continuity offset 7
Feb 24 17:59:34 vdr vdr: [7628] cNaluDumper: TS continuity offset 2

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.12.17 + BER/UNC-Patch für stv090x, nvidia 334.21, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

Urig

Professional

  • "Urig" started this thread

Posts: 1,222

Location: Kassel

  • Send private message

15

Saturday, March 3rd 2012, 4:50pm

Das sind zumindest Auffälligkeiten im TS-Strom. Continuity offset weist darauf hin, dass die TS-Pakete nicht aufsteigend durchnummeriert sind, was normalerweise als Hinweis gezählt wird, dass Pakete verloren gegangen sind, und Unexpected NALU fill data überprüft, ob die Fülldaten auch schön brav 0xFF Bytes sind, wie vorgeschrieben. Hier sind durch das Weglassen von TS-Paketen wohl Nutzdaten in den Fill-Block gerutscht, naludump bricht dann sofort das dumpen dieses Fill-Blocks ab.

Gruß,

Udo

berndb

Intermediate

Posts: 419

Location: Frankfurt am Main

  • Send private message

16

Monday, November 26th 2012, 11:34pm

Gibt es für den vdr-1.7.32 schon einen angepassten Patch?

Ich habe folgende "Rejects" bei der Datei remux.h bekommen:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
--- remux.h	2010-06-05 15:27:55.000000000 +0200
+++ remux.h	2011-02-20 17:42:38.000000000 +0100
@@ -105,6 +110,11 @@
   return p[3] & TS_CONT_CNT_MASK;
 }
 
+inline void TsSetContinuityCounter(uchar *p, int Counter)
+{
+  p[3] = (p[3] & ~TS_CONT_CNT_MASK) | (Counter & TS_CONT_CNT_MASK);
+}
+
 inline int TsGetAdaptationField(const uchar *p)
 {
   return TsHasAdaptationField(p) ? p[5] : 0x00;
@@ -114,6 +124,7 @@
 
 int64_t TsGetPts(const uchar *p, int l);
 void TsSetTeiOnBrokenPackets(uchar *p, int l);
+void TsExtendAdaptionField(unsigned char *Packet, int ToLength);
 
 // Some PES handling tools:
 // The following functions that take a pointer to PES data all assume that

Habe das zwar irgendwie per Hand nun so reingefummelt, dass zumindest das ganze fehlerfrei kompiliert - aber als C(++) Analphabet weiß ich nicht, was ich da eigentlich tue ...
Mystique SaTiX-S2 Sky PCI auf PIII,
Technotrend TT 1600 auf PIII

17

Tuesday, November 27th 2012, 10:01am

@berndb

IMHO brauchts das gar nimmer, der Gewinn geht gegen null seit der großen Transponder Umstellung im März/April 2012, zumindest bei mir mit DVB-S2. Ich habe den Patch zwar noch drin aber abgeschaltet und siehe da, das ein oder andere kleine seltene Phänomen beim Setzen und Verschieben von Schnittmarken ist auch verschwunden ... ^^

Regards
fnu
Gib HD+/CI+ keine Chance! >> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610, 4GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, L4M Twin S2 (V5.6)/FlexS2 (4x DVB-S2), rt Unicable®, CIR, Ubuntu LTS 12.04.4, VDR 2.1.6 (x64, 44W)
[²] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH61CR, G540, 2GB DDR3, WD10EADS 1TB, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP, rt Unicable®, mceusb, Ubuntu Trusty, VDR 2.1.6 (x64, 40W)
[³] Cooler Master Elite 360, Xilence SPS-XP250.SFX (250W), Intel DH77KC, Xeon E3-1245v2, 8GB DDR3, Intel 313 SSD 24GB (Sys & HostCache), HP SA P400 256MB BBWC, 4x WD7500BPXX@Backpl., L4M Twin S2 (V5.4), VMWare ESXi 5.5 (6 VM)(x64, 45W)

18

Tuesday, November 27th 2012, 2:40pm

der Gewinn geht gegen null
Je nach Sender spart man immer noch bis zu 26%!

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
grep -e "NALU fill dumper:" messages
Oct  6 01:10:00 vdr vdr: [4053] NALU fill dumper: 2231797 of 59135979 packets dropped, 3%
Oct 11 22:55:00 vdr vdr: [4048] NALU fill dumper: 0 of 36575750 packets dropped, 0%
Oct 12 00:34:13 vdr vdr: [4048] NALU fill dumper: 151495 of 75189032 packets dropped, 0%
Oct 12 01:03:29 vdr vdr: [4048] NALU fill dumper: 12240584 of 46665265 packets dropped, 26%
Oct 12 02:40:00 vdr vdr: [4048] NALU fill dumper: 0 of 70200118 packets dropped, 0%
Oct 13 08:05:00 vdr vdr: [4058] NALU fill dumper: 4494679 of 38916460 packets dropped, 11%
Oct 13 22:32:00 vdr vdr: [4033] NALU fill dumper: 11613472 of 59747784 packets dropped, 19%
Oct 17 19:40:02 vdr vdr: [4070] NALU fill dumper: 0 of 22645423 packets dropped, 0%
Oct 18 00:20:00 vdr vdr: [4003] NALU fill dumper: 850687 of 39829613 packets dropped, 2%
Oct 25 02:45:56 vdr vdr: [1531] NALU fill dumper: 0 of 32114210 packets dropped, 0%
Oct 25 16:15:00 vdr vdr: [1516] NALU fill dumper: 0 of 43011574 packets dropped, 0%
Oct 26 03:00:00 vdr vdr: [1583] NALU fill dumper: 0 of 79270602 packets dropped, 0%
Oct 27 08:05:00 vdr vdr: [1535] NALU fill dumper: 5954239 of 38632317 packets dropped, 15%
Oct 30 22:10:30 vdr vdr: [3612] NALU fill dumper: 523813 of 64989145 packets dropped, 0%
Oct 31 20:20:00 vdr vdr: [3607] NALU fill dumper: 0 of 40757888 packets dropped, 0%
Nov  1 00:20:00 vdr vdr: [3656] NALU fill dumper: 5604732 of 37993565 packets dropped, 14%
Nov  1 01:25:00 vdr vdr: [3656] NALU fill dumper: 4028446 of 73333496 packets dropped, 5%
Nov  2 02:10:00 vdr vdr: [3602] NALU fill dumper: 991145 of 78867457 packets dropped, 1%
Nov  2 02:50:00 vdr vdr: [3602] NALU fill dumper: 0 of 74744760 packets dropped, 0%
Nov  2 21:15:13 vdr vdr: [3980] NALU fill dumper: 33727 of 8653147 packets dropped, 0%
Nov  7 20:20:00 vdr vdr: [3609] NALU fill dumper: 0 of 40756115 packets dropped, 0%
Nov  8 00:20:00 vdr vdr: [3616] NALU fill dumper: 1809636 of 39288943 packets dropped, 4%
Nov  9 02:00:00 vdr vdr: [3648] NALU fill dumper: 0 of 79259502 packets dropped, 0%
Nov  9 02:45:00 vdr vdr: [3648] NALU fill dumper: 0 of 72479876 packets dropped, 0%
Nov 13 01:40:00 vdr vdr: [3601] NALU fill dumper: 2676087 of 80507019 packets dropped, 3%
Nov 13 03:35:06 vdr vdr: [3601] NALU fill dumper: 0 of 5578778 packets dropped, 0%
Nov 13 22:10:00 vdr vdr: [3609] NALU fill dumper: 470580 of 11168551 packets dropped, 4%
Nov 14 02:20:00 vdr vdr: [3623] NALU fill dumper: 1852044 of 80284221 packets dropped, 2%
Nov 14 20:20:00 vdr vdr: [3615] NALU fill dumper: 0 of 40756661 packets dropped, 0%
Nov 15 00:20:00 vdr vdr: [3627] NALU fill dumper: 3625285 of 39164226 packets dropped, 9%
Nov 15 03:05:00 vdr vdr: [3603] NALU fill dumper: 0 of 40759494 packets dropped, 0%
Nov 16 02:45:00 vdr vdr: [3627] NALU fill dumper: 0 of 70202341 packets dropped, 0%
Nov 17 00:41:49 vdr vdr: [3613] NALU fill dumper: 259961 of 28982873 packets dropped, 0%
Nov 17 23:00:00 vdr vdr: [3627] NALU fill dumper: 1496733 of 93327057 packets dropped, 1%
Nov 21 05:50:00 vdr vdr: [3634] NALU fill dumper: 10479329 of 100661742 packets dropped, 10%
Nov 21 20:20:00 vdr vdr: [3619] NALU fill dumper: 0 of 40762131 packets dropped, 0%
Nov 21 23:00:00 vdr vdr: [3619] NALU fill dumper: 1663701 of 82316103 packets dropped, 2%
Nov 22 00:20:00 vdr vdr: [3619] NALU fill dumper: 1499869 of 39436610 packets dropped, 3%
Nov 23 01:57:47 vdr vdr: [3641] NALU fill dumper: 0 of 51072585 packets dropped, 0%
Nov 23 02:55:00 vdr vdr: [3641] NALU fill dumper: 0 of 25887825 packets dropped, 0%
Nov 23 22:45:00 vdr vdr: [3611] NALU fill dumper: 13221809 of 72794671 packets dropped, 18%
Nov 24 01:40:00 vdr vdr: [3608] NALU fill dumper: 5239813 of 46419365 packets dropped, 11%
Nov 25 01:35:00 vdr vdr: [3638] NALU fill dumper: 2871578 of 78779525 packets dropped, 3%
Nov 26 00:25:00 vdr vdr: [3635] NALU fill dumper: 1042432 of 83200262 packets dropped, 1%
Nov 26 03:28:00 vdr vdr: [3635] NALU fill dumper: 2010849 of 93160310 packets dropped, 2%

Und Probleme mit Schnittmarken gibt es bei mir nicht.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.12.17 + BER/UNC-Patch für stv090x, nvidia 334.21, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

19

Tuesday, November 27th 2012, 11:25pm

Je nach Sender spart man immer noch bis zu 26%!

Ja, es gibt leider immer noch Aussreisser nach oben, war vmtl. irgendeine Upscale Ausstrahlung, oder irgendwas mit schwarzen Rändern. Aber ich hatte auch geschrieben "geht gegen null" und nicht "ist null", lesen und verstehen ... ?(

Deine Statistik zeigt ziemlich gut was ich meine, der Aufwand lohnt IMHO nicht mehr, früher waren die 0% die Aussreisser und bei den 1080i Sendern mit variabler Datenrate ging eh nie viel.

Ist sicher auch eine Frage was damit macht, auf einem Server einlagern, aufnehmen/angucken/löschen oder als mkv einkochen, letztere beiden Varianten haben es im Prinzip sowieso nie benötigt.

Und Probleme mit Schnittmarken gibt es bei mir nicht.

Auch hier habe ich nix von Problemen geschrieben, sondern seltenes seltsames Verhalten beim Setzen und Verschieben von Schnittmarken, das seit dem Abschalten der Funktion nie wieder auftrat. Probleme sind was anderes ... 8)

Regards
fnu
Gib HD+/CI+ keine Chance! >> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610, 4GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, L4M Twin S2 (V5.6)/FlexS2 (4x DVB-S2), rt Unicable®, CIR, Ubuntu LTS 12.04.4, VDR 2.1.6 (x64, 44W)
[²] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH61CR, G540, 2GB DDR3, WD10EADS 1TB, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP, rt Unicable®, mceusb, Ubuntu Trusty, VDR 2.1.6 (x64, 40W)
[³] Cooler Master Elite 360, Xilence SPS-XP250.SFX (250W), Intel DH77KC, Xeon E3-1245v2, 8GB DDR3, Intel 313 SSD 24GB (Sys & HostCache), HP SA P400 256MB BBWC, 4x WD7500BPXX@Backpl., L4M Twin S2 (V5.4), VMWare ESXi 5.5 (6 VM)(x64, 45W)

berndb

Intermediate

Posts: 419

Location: Frankfurt am Main

  • Send private message

20

Wednesday, November 28th 2012, 10:24am

1% von 100 GB sind immerhin auch schon wieder 1GB.

Und seltenes seltsames Verhalten ist auch ein wenig unspezifisch, um jedenfalls mir die Lust am Patch zu verderben. Ich würde es begrüßen, wenn man den Patch weiterpflegt: Wozu braucht man Füll-Daten ohne jeden Wert auf der Platte? Der eigentliche Zweck ist doch nach der Übertragung via Satellit, um da die Bitrate konstant zu halten, erfüllt?!
Mystique SaTiX-S2 Sky PCI auf PIII,
Technotrend TT 1600 auf PIII