Beiträge von may24

Hm, ja, das klappt auch. Stellt man unter OSD die Nyala Schrift ein, so werden die Untertitel auch mit diesem Font angezeigt.

Was mich nur wundert ist, das das nicht unter den vsfilter Optionen (MPC -> Optionen -> Untertitel -> Standard Style) geht ...
Hintergund ist der: Media Portal benutzt die MPC Vsfilter Engine zum anzeigen der Subtitles. Auch wenn im OSD eine andere Schriftart eingestellt ist, es wird immer nur Arial benutzt ...

Hallo zusammen,

Ich verwende gerne das Font: Nyala für meine Untertitel.
Aus irgend einem Grund jedoch weigert sich der MPC die Untertitel in dieser Schriftart wiederzugeben - obwohl sie im System (Win 7 x64) installiert ist.

Die Konfiguration des MPC's steht auf "Arial" und in der Liste der verfügbaren Schriften taucht Nyala" gar nicht auf ... Ebenso diverse andere Schriftarten ...

Meine Fragen: ich habe xy-VSFilter (neuste Version) installiert, doch der kommt nur mit besagte "handvoll" an font's und scheint nicht - wie erwartet - die System-Fonts zu nutzen.
Sind diese (relativ) wenigen font's hard-coded ? Kann man welche nachinstallieren ? Gibt es eine weitere Option im MPC ?

... ich komm nicht weiter ...

Das Problem ist das sps:vui:time_scale & sps:vui:num_units_in_tick nicht immer an der selben Stelle im SPS stehen ... Nichtmal der SPS hat eine feste Größe und kann variieren.
Was soviel bedeutet wie: es müssen vorher noch einige andere Bit/Bytes analysiert werden um auf die tatsächliche Position im SPS zu kommen.
FFMpeg hat in seiner Doku die Struktur zwar abgebildet, jedoch werde ich da nicht ganz schlau draus ...

hevc_ps.c - Ab Zeile 538 ...

Zeile 642: vui->vui_timing_info_present_flag = get_bits1(gb);
Ok, ab hier wird's interessant, aber ich kann nicht erkennen wie dieses Flag "gefunden" wird.

Ich bin nicht der CPP Programmierer (komme aus dem Java Umfeld) und benötige daher etwas Hilfe den Code zu verstehen

Das Problem scheinen die Flags zu sein ...
Klar, meine Test-Streams haben unterschiedliche Settings und somit sind natürlich auch andere Optionen ein bzw. ausgeschaltet.
Doch schaut man sich den Code binär an, gibt es Verschiebungen um 2 und manchmal 4 Bits ... Was ein "Ortung" extrem schwierig macht !Das würde bedeuten, die Flags werden scheinbar nicht als int's sondern wohl als Bit's gespeichert ...

ja ... das erklärt auch das "komische offset" für den Denominator

Anmerkung: Ich habe immer "mod16" oder "mod4" in Klammern geschrieben um aufzuzeigen das es hier um ein Vielfaches von 16 o. 4 und nicht um eine Modulo Operation an dieser Stelle geht !

ok ...
Erstes Testfile mit 1000 Frames gecoded mit folgenden Settings:

"C:\Program Files (x86)\Video Tools\avs2pipemod-1.1.1\avs2pipemod.exe" -rawvideo "test.avs" | "C:\Program Files\x265\x265-2.4_37.exe" --preset slower --crf 24 --psy-rd 2.0 --psy-rdoq 10.0 --aq-mode 3 --rd 5 --me star --no-open-gop --no-sao --ctu 32 --limit-modes --input-res 1280x720 --input-depth 16 --fps 24000/1003 --output "test.h265" --input -

Wie man sofort erkennt wird nur ein SPS geschrieben. Ich habe bewusst eine völlig abstruse Geschwindigkeit genommen um die Werte besser wiederzufinden.
Hier mal ein Ausschnitt aus dem SPS mit den relevanten Bytes:

00 fa c0 00 17 70

Die ersten 2 Bytes geben den Denominator an: 0xFA -> 250 -> x4 (mod4) -> 1000
Die nächsten 2 Byte das "Offset" des Denominators (1003 kann man ja nicht durch 4 teilen ...) Nur das erste der zwei Bytes wird scheinbar ausgewertet ...
0xC0 ist zwar dezimal 192 steht aber in diesem Fall aber für 3. ( 0x40 = 1, 0x80 = 2) ... (mod64 ???)
Die letzten Bytes markieren die eigentlichen FPS: 0x1770 -> 6000 -> x4 (mod4) -> 24000

ABER
Nächstes testfile mit folgenden Optionen gecoded:

"C:\Program Files (x86)\Video Tools\avs2pipemod-1.1.1\avs2pipemod.exe" -rawvideo "test.avs" | "C:\Program Files\x265\x265-2.4_37.exe" --preset faster --crf 24 --repeat-headers --limit-modes --ctu 32 --input-res 1280x720 --input-depth 16 --fps 24000/1003 --output "test.h265" --input -

Diese Settings packen alle "paar Frames" einen neuen VPS/SPS/PPS in den Stream ...
Nur jetzt schaut's folgendermaßen aus:

00 3e b0 00 05 dc

Erste 2 Byte: 0x3e -> 62 -> x16 (mod16) -> 992
Zweite 2 Bytes: 0xb0 -> 176 (nur das erste Byte wird ausgewertet ... und ja, hier ist alles "big" ) Teilt man die 176 durch 16 (anstatt durch 64 wie im Beispiel oben) so bekommt man 11. Addiert man das zu 992 -> 1003
Drittes Byte Paar: 0x05dc -> 1500 -> x16 (mod16) -> 24000

Und nun die Große Preisfrage: Wo/wie bzw. an welcher Stelle wird angegeben ob nun in mod4, mod16 oder ... gearbeitet wird ?
Ums besser/komplizierter zu machen sollte man sich mal einen Stream mit dem hevcbrowser anschauen

jup, und es kommt noch schlimmer ...
Ich habe gerade ein neues Testfile erzeugt ... mit anderen Presets ... und siehe da: NICHTS passt mehr.

Nach einiger Analyse kam jetzt heraus das der (z.B.) FPS Wert nur manchmal als mod4 gespeichert ist ... er kann aber auch als mod16 gespeichert sein. (mod8 ??)
D.h. es gibt irgendwo ein Flag welches indiziert welcher Modulo gerade verwendet wird ... was natürlich unbekannt ist !

Oder weiß da jemand mehr ?

Ok, ich arbeite an einer neuen Version die den Ganzen File parsen kann ...

Dabei ist mir was aufgefallen ... Stimmt es das in HEVC die Horizontale mod2 und die Vertikale mod16 sein muss ? Oder ist hier nur meine Interpretation des Binärcodes falsch ?

Hm, macht es überhaupt Sinn einen multi-SPS check/modifier einzubauen ?

Ich meine, der einzige "use case" der mir einfällt warum man überhaupt multi VPS/SPS/PPS bräuchte, wäre beim TV wenn zwischen 4k/HD/SD umgeschaltet wird.
Vielleicht noch bei VOD ?

Hm ... ok :daumen:
und wie oft repeated der den header ... oder besser gefragt in welchem Abstand schreibt der 'nen Neuen ?

Nachtrag: so wie's ausschaut wird bei der " --repeat-headers" Option nach jedem GOP und somit vor jedem IDR Frame ein VPS, SPS, PPS und SEI_Prefix geschrieben

Hallo zusammen,

Ich hatte beim re-encoden einer Serie versehentlich 23.976 (24000/1001) anstatt 25 FPS angegeben was logischerweise zu einer gewaltigen Versatz bei Video/Audio führte.
Da ich nicht alle Episoden wieder neu coden wollte, suchte ich nach einem Programm mit dem man die FPS des Elementar-Streams ändern konnte.
Leider erfolglos.

Daher hab ich einfach selbst eins geschrieben.
https://github.com/hydra44/hevc_FPS_changer

Wer's gerne testen möchte kann sich das Python Script gerne runterladen.
Bitte Bugs und Änderungswünsche hier im Thread.

Limits:
Nur RAW-HEVC Streams werden unterstützt
Python 3.x wird benötigt
Nur single SPS Streams werden (derzeit) unterstützt ... hab leider keine multi-SPS Clips zum testen/entwickeln ...

Ein letztes:
Im Prinzip kann jeder die SW so benutzen wie er will und auch in andere Sachen integrieren ...
Daher wollte ich noch "Das Übliche" wie "Haftungsausschluss" und "License" dazu packen. Was/welche/woher nimmt man da am besten ? (Oder ist meine saloppe Formulierung in der Readme.md ausreichend :D) )

Hallo zusammen,

Ich habe hier ein Video mit 29.97 FPS was aber eigentlich 25 FPS hat. Leider scheint der Audio Teil aber in dieser Geschwindigkeit zu sein ...

Ein eichaches AssumFPS brachte dann Klarheit: Ja der AudioTeil passt, ist aber jetzt zu "tief" das das gesamte Video ja "gebremst" wurde.

Ich versuche nun das Ganze auszugleichen. Leider hat MeGUI keine Option 29.97 -> 25 ... Bleibt also nur TimeStretch().
Nur wie berechne ich den "Tempo" Parameter damit ich genau dieses "Slowdown" bekomme ?

Ja, das mit Sat und Sixx-HD (bzw. HD+ Programme im allgemeinen) ist so 'ne Sache ...

Ja, du brauchst eine Smat-Card um das Programm zu entschlüsseln. Und du benötigst ein spezielles CAM ... und hier wird's knifflig. Ob du ein HD+ CAM am PC überhaupt zum laufen bekommst ist fraglich. Was aber gehen soll sind Multi-CAMS ... und nein, entgegen landläufiger Meinung sind die nicht illegal ... solange sie mit einer legalen Smartcard betrieben werden.

Das schöne an der PC Lösung ist das die CI+ Restriktionen nicht greifen. Das CI+/HD+ CAM sendet z.B. Restriktion: Diese Programm darfst du nicht aufnehmen ... Aber der PC kann damit nichts anfangen und ignoriert das einfach. So kannst du ganz einfach die Sendung speichern.

Es ist überhaupt kein Problem die SAT (DVB-S2) Sachen zu konvertieren. Ich mach das seit Jahren.

Zitat von Der_Lurchi

@monarch
...
Kein Medium von Belang nutzt derzeit H.265 und von DVBT2 abgesehn, hat man gar nix davon.
...

Na da wäre ich mir aber nicht so sicher ... Jede Menge 4k Sachen (und höher) setzten auf HEVC ... Und das wär' sogar schon Standad wenn die Politik der MEPG-LA nicht so gierig wäre.
Abgesehen was da so im "Underground" gehandelt wird gibt es Test 4k TV Kanäle via SAT die in h.265 ausstrahlen und wie bereits erwähnt DVB-T2 was ja mittlerweile "Alternativlos" für den terrestrischen Empfang geworden ist ...

Zitat

Bis August kostet das Freenet nix und spätestens dann muss eine andere Lösung her, ob OTR + Zatto oder OTR + DVB-T2 ohne Freenet Abo, denn ich bezahl doch nachher nicht auch noch fürs Werbung schauen.

Wäre Satellit ne' Option für dich ?

Also ich kann bestätigen das monarc99 Ansatz funktioniert.
ffmpeg wirft zwar jede menge Warning's aber grundsätzlich geht es.

Ich hab mir mal via Hex-Editor die Files angeschaut und das sieht echt grausig aus ... da werden ja sämtliche Standard Pattern verletzt - was Header angeht - so dass es fast schon an ein Wunder grenzt das ffmpeg da überhaupt was findet

Die Knackser kommen wahrscheinlich daher das deine Box versucht Bild und Ton synchron zu halten. Wenn das "Gitter" (engl.) zu groß wird, wirft er entweder Video Frames weg, oder stopft die Stellen mit "irgendwas" ...

DBV-T(x) ist 'eh so ziemlich die schlechteste Methode Filme aufzuzeichnen die man archivieren möchte. Zu viele Störungen, das Ganze läuft zu viel/schnell aus dem Sync.
Abgesehen davon verstehe ich nicht das es überhaupt "Qualitätsstufen" gibt ?? ... Das ist ja keine analoge Sache hier ! Da sollte ja gar nichts neu-codiert werden !
Der Stream wird wie empfangen auf die "Platte" geschrieben ... und feddisch !

Und Theoretisch darf das keinen erhöhten Stromverbrauch mit sich ziehen ! Denn der Stream wird nur vom Memory auf das Speichermedium geschrieben ... die (Strom) Kosten sind dabei dermaßen gering das sie nicht in's Gewicht fallen dürfen ....
Ich glaub da ist grundsätzlich was faul bei deiner Kiste

Der_Lurchi: Ich kann dir da nicht so ganz folgen ...

HEVC Video + AAC oder auch AC3 Sound läßt sich absolut problemlos in .mkv mit der MKVtoolnix GUI muxen. Und auch nach .mp4 via mp4box (cli) gab's noch keinen nennenswerten Probleme.
Ich weiß zwar nicht was du da für 'ne Box hast, aber hexen tut die auch nicht. Und ehrlich gesagt glaub ich echt nicht das sie die empfangenen Datenströme in einen .mpg Container um-muxed. Warum auch ???
Nee, das ist zu 99.9% ein schlichter .ts (MPEG-2 Transport Stream) der aus was-weiß-ich-welchen-Gründen in Endung (Suffix) .mpg umbenannt wird. Nein, auch DVB-T2 erfindet das Rad nicht neu.
Jedoch, ohne "Schnipsel" zum testen bleibt es bei dieser Vermutung ...

Wenn du meinem letzten Eintrag folgst und mit eac3to das Ganze auseinander nimmst, so bewirkt der "-fix" Schalter das ein mögliches Audio Delay weitestgehend korrigiert wird.
Trotzdem würde ich mich nicht da 100% darauf verlassen ... Abgesehen davon wird ein Logfile angelegt indem alles nochmal drinne steht.
Wenn du neu codierst, kannst du dem Encoder das Delay mitgeben und der neue Stream sollte dann synchron zum Bild sein. Oder du gibst das Delay (positiv oder negativ) deinem Muxer mit un der schreibt es dann in den Container. So spart man sich das neu-coding, aber mitunter wird diese Information beim abspielen nicht immer berücksichtigt ... gerade SAP's tun sich bei Matroska meist schwer

Hm ...

.mpg bzw. .m2ts via DVB ... hab ich noch nie gesehen ...
Da würde ich eher mal das Suffix der Datei in .ts umbenennen und dann eac3to das Ganze auseinander nehmen lassen:

eac3to.exe -demux -fix "E:\x-downloads\gefragt gejagt.ts"

Ja, shared-dir hatte ich auch zunächst ... da es damit aber massig Probleme gab, habe ich es abgeschaltet und quasi ein Samba-Share auf mich selbst aufgemacht um sowohl mit Linux als auch mit Windows auf die selben Daten zugreifen zu können.
Dennoch gibt's da immer mal wieder Probleme das die Verzeichnisse/Dateien nicht sofort (oder nur nach F5) upgedated werden ...
Ich suche da immer noch an fine-tuning Parameter für die smb.conf ... aber das geht hier jetzt komplett am Thema vorbei

Puh ... ob das in der normaler cmd shell geht ... glaub ich nicht ... da müsstest du schon mit powershell arbeiten. Da kann ich dir aber nichts zu sagen. Windows ist nicht gerade die erste (eher latzte) Wahl wenn's um's Scripten geht.

Wie wär's mit Python ?

>>> print os.path.isfile("/etc/password.txt")
True

Hi zusammen,

sorry das es so lange gedauert hat ...

Nein, die Anzeige von Mediainfo war falsch. Es sind/waren tatsächlich 1.5 GB. Der Fehler liegt/lag daran das mein Win in einer VM läuft, und die Video Files sich auf einem Samba Mount befinden. Leider scheint es so als das der Datei-Explorer nicht immer automatisch korrekt updated wird und man erst F5 drücken muss damit's passt. Das auch Mediainfo davon betroffen ist war mir neu ...

Wie auch immer, nach einigem Suchen und noch viel mehr rumprobieren hat's nun endlich mal geklappt

LoadPlugin("C:\Program Files (x86)\Video Tools\ffms2-2.22-msvc\ffms2-2.22-msvc\x86\ffms2.dll")
LoadPlugin("C:\Program Files (x86)\Video Tools\VFRtoCFR20120730\VFRtoCFR.dll")
LoadPlugin("C:\Program Files (x86)\Video Tools\dither-1.22.1\dfttest-1.9.2\dfttest.dll")
Import("C:\Program Files (x86)\Video Tools\dither-1.22.1\dither.avsi")


v=FFVideoSource("Hunter.wmv",timecodes="Hunter.txt").VFRtoCFR(times="Hunter.txt", numfps=30000, denfps=1001, dropped=false)
a=FFAudioSource("Hunter.wmv")
AudioDub(v,a)


...

1.5 GB ... bischel gross ...