TS-Doctor 2.0 www.cypheros.de

Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - Djfe

Seiten: [1] 2 3 ... 116
1
Plauder-Ecke / Re: UHD1 trotz HD+ verschlüsselt?
« am: Juni 26, 2019, 21:44:47 »
wir hatten HD+ für ein paar Monate geschenkt bekommen (mit Modul), ich glaub für den neuen Fernseher

naja, jedenfalls danke für die Antworten :)

Bin auch gespannt, was aus dem "Spaß" wird ^^
Sky ist ja vor einigen Jahren auf reines DVB-S2 gewechselt (SD mit H.264), das hat denen sicher einiges an Geld gespart.
Vlt. machen die HD+ Sender das auch irgendwann ^^
(wenn die ÖR auf HD/DVB-S2 only wechseln dürften die Zuschauerzahlen dafür doch groß genug sein)

2
Plauder-Ecke / Re: UHD1 trotz HD+ verschlüsselt?
« am: Juni 18, 2019, 09:17:55 »
Danke für die Antwort

Ich hab eben noch in Erfahrung gebracht, dass mein Vater hd+ hat auslaufen lassen, also vlt. liegt es auch daran.
Obwohl RTL, Pro7 und Co. in HD noch einwandfrei klappen.
ich schau mal nach, ob ich das genaue Datum noch in Erfahrung bringen kann.

3
Plauder-Ecke / UHD1 trotz HD+ verschlüsselt?
« am: Juni 18, 2019, 06:29:12 »
Hallo :)
war lange nicht mehr hier,

Ich hab eine Frage zum Astra Testsender UHD1 und vielleicht könnt ihr mir dabei ja helfen:
Während des Free Fensters (tagsüber, der EPGslot heißt so) kann den Sender jeder aufnehmen und schauen.

Außerhalb des Free Fensters sollte er verschlüsselt sein, aber für alle HD+ Kunden sollte er weiterhin schaubar sein. (https://www.hd-plus.de/themen/uhdtv)

Ich hab ihn mal Abends nach 20Uhr mit meiner VU+ Solo2 (nur HD-fähig) aufgenommen, um dann im Nachhinein am PC festzustellen, dass das Bild offenbar verschlüsselt ist. (der Ton ist unverschlüsselt und lässt sich mit VLC abspielen)

Ist das Bild wirklich verschlüsselt oder gibt es hier irgendein anderes Problem, dass daher rührt, dass die Solo2 kein UHD darstellen kann?
Oder ist das Format irgendwie modifiziert und das VTI image/der TSD kommen damit nicht klar?

die Aufnahmen von tagsüber (UHD und HLG HDR) lassen sich einwandfrei abspielen, im TSD öffnen usw.

bei der Aufnahme vom Abend meldet TSD: die Aufnahme ist verschlüsselt. und ffmpeg kann keine Codec Parameter (wie Auflösung, HDR usw.) aus dem Stream herauslesen, nur dass es hevc ist.

Die Aufnahme kann ich gerne bereitstellen, falls jemand Interesse hat.
Habt ihr euch den Sender schonmal angesehen? Im Gegensatz zum SES Testsender, ist der hier etwas mehr als nur Test, da laufen tatsächlich Dokus und andere Programme.

Ich bin zufällig über das Aftermovie vom Tomorrowland 2018 gestolpert, als es dort im Free Fenster lief. Abends sollte das laut EPG wiederholt werden, ist dann leider nichts drauß geworden.
Das Video ist natürlich auch auf YouTube, nur eben in deutlich schlechterer Qualität und nicht in HDR https://www.youtube.com/watch?v=HkyVTxH2fIM
(wobei ich mir nicht sicher bin, ob das wirklich HDR war, das wollte ich dann später nachschauen, das HLG HDR der BBC ist ja zu SDR (8bit) rückwärtskompatibel)

Grüße,
Djfe

4
TS-Doctor 2.x / Re: Audio-Problem bei DVB-T2 HD (ARD-Sender)
« am: Januar 30, 2018, 10:04:48 »
MPC-HC benutzt Hardwarebeschleunigung (basiert auf den LAV Filters, die der Doc auch einsetzt)
und er kriegt das Bild besser hin als VLC (bei Nvidia Grafikkarten werden die TV Helligkeitslevel per default häufig nicht auf PC Level skaliert, sodass das Bild ausgewaschen aussieht)

Was ich mir immer mal geben wollte, ist mpv:
https://mpv.io/

Erfordert aber, dass man per Kommandozeile/Configfiles statt GUI konfiguriert, hab ich gelesen.

Vlt. bringt ja jemand mal ne GUI für den Zweck raus.

5
ist Stille nicht = ungewünschte Pakete weglassen, das ein Transportstrom bereits Synchronität garantiert?
so könnte man wenigstens Ton unabhängig vom Video schneiden
was etwas genauer ist, auch wenn nur auf Tonpaketebene

ja, neu zu encoden wäre schön, aber muss man doch nicht, oder?

6
Radio Eriwan antwortet: im Prinzip ja, aber...  ;D

1) der Doc analysiert bislang noch gar nicht die Audioinhalte. Da müssten also erstmal ein paar neue Dekoder her, damit die Daten dann auch in unkomprimierter Form zwecks Vergleich vorliegen.
Er sprach gerade vom Hexeditor ;) (d.h. in Binary form, es ist also kein decoder von Nöten, ist bloß fraglich, bei wievielen Sendern das der Fall ist und bei welchen Audiocodecs; nur wenn irgendwelche Audioeffekte am Schnittübergang sind, ist es eigentlich sicher, dass da vom Sender neu encodiert wurde, ansonsten liegt's daran wie sich die Techniker des Senders entscheiden)

2) und schon sehen wir uns einer Vielzahl von Formaten gegenüber, von denen die Mehrkanal Dinger nun nicht wirklich trivial zu vergleichen sind.

schon irgendwie, überschaubar ist die Anzahl aber trotzdem:
mp2/mpeg
ac3/Dolby Digital
eac3
aac

und Mehrkanalvarianten der obigen Formate (vor allem ac3)

3) Der Ton wird üblicherweise VOR dem Bild gesendet. Im Moment wird immer nur nach dem Bildinhalt geschnitten (sonst gäbe es ja hässliche Artefakte), auch bei einer absoluten Wiederholung kann man nicht sicher davon ausgehen, dass die Pakete sowohl im Inhalt, als auch in der Position im Stream wirklich identisch sind.

hier müsste man also ggf. die Schnittstelle neu muxen/sortieren und jeden Stream einzeln schneiden

ist auf jedenfall aktuell ein (wenn auch kleines) Problem:
es tritt immermal wieder auf, dass Ton am Schnitt fehlt oder übrig bleibt, obwohl der Schnitt Bildsynchron war

4) die Sender sorgen schon dafür, dass auch der Ton nicht ungeschoren bleibt. Man denke nur an den hässlichen PING! bei Pro 7 ein paar Sekunden nach Beginn der Wiederholung nach einem Werbeblock. (meist ist der PING! genau da, wo die Wiederholung eigentlich zuende ist und der "Nettofilm" weitergeht.) Würde Dir den ganzen schönen Vergleich zunichte machen...

OK ignorier, was ich weiter oben gesagt habe, hast du ja schon hier getan ^^

Also, die Unwägbarkeiten sind einfach zu groß. Das Feature würde ewig Rechenzeit ziehen, mit bescheiderem oder gar gar keinem sinnvollen Ergebnis...

 >:( THUMBS DOWN!  >:(

sinnvoll implementiert würde es keine Rechenzeit ziehen, insbesondere, weil sich Audio schneller decodieren und analysieren lässt und das noch dazu in einem eigenen Thread
ggf. macht man die Analyse auch nur an den eh schon gefundenen Schnittstellen

oder man nimmt gleich die Audiospur, um z.B. Lautstärkeänderungen/Ping usw. zu erkennen
und vergleicht nur noch an den gefundenen Schnittstellen das Bild, um dort dann noch korrekt im Video schneiden zu können

aktuell ist ja auch ein Problem:
wir können den Wechsel von 5.1 nach Stereo und zurück erkennen
geschnitten wird aber trotzdem nach dem Bild (I-Frame oder so) (vermute ich)
heißt: es wird immer ein Stück Stereo mit in der Aufnahme bleiben oder ein Stück vom 5.1 Ton fehlen, obwohl man danach gesucht hat

generell wäre es nice, anhand einer Waveform schneiden zu können.

Dass das nicht so ohne weiteres geht, wegen der Lizenzprobleme, ist mir aber bekannt :/

Könnte Cypheros einfach den LAV als Audio-Decoder nutzen, oder würde das Lizenz-Probleme geben?

@Cypheros hast du das schonmal versucht? wie schwierig ist es da mit dem LAV, Synchronität zu halten? (also dass die Timestamps noch stimmen, der LAV ist ja für die Wiedergabe optimiert)

7
Plauder-Ecke / Re: Dateien aus fertiger Liste ausschließen
« am: April 17, 2017, 10:56:50 »
Mach dich am besten mal ein wenig mit powershell vertraut ;)
dem Nachfolger der Kommandozeile in Windows
das löst dein Problem im Handumdrehen (der Reim entstand zufällig)

Was ist powershell?
Blogpost mit genau deinem Problem
Wie man Kriterien angibt, die bestimmte Dateien ausschließen
Extensive Beschreibung des get-childitem Komnandos

8
Plauder-Ecke / Re: ATSC 3.0
« am: April 17, 2017, 10:44:08 »
scheinst tatsächlich Recht zu haben :O

https://www.thebroadcastbridge.com/content/entry/6229/atsc-3.0-details-explained-part-4

die denken sich ipv6 alleine klappt nicht und wollen sich erstmal den Aufwand sparen den dualen Ansatz zu standardisieren

v6 soll dann in 3.1 oder 3.2 folgen

atsc 3 soll ja so designed worden sein, dass es leicht erweiterbar ist, aber bei einem essenziellen Teil wie IP bin ich mir unsicher, ob das funktioniert

https://www.thebroadcastbridge.com/content/entry/6229/atsc-3.0-details-explained-part-4

9
Plauder-Ecke / Re: ATSC 3.0
« am: April 16, 2017, 10:46:56 »
Ich versteh immernoch nicht was das mit dem Fersehstandard atsc zu tun haben soll?
der unterstützt doch ipv6...

klar sollte ipv4 langsam sterben

aber wo steht, dass ein neues globales Netz auf Basis von ipv4 erstellt wird?

10
Plauder-Ecke / Re: ATSC 3.0
« am: April 16, 2017, 07:53:47 »
Wo hast du denn die letzte Info her? :D

11
Plauder-Ecke / Re: ATSC 3.0
« am: April 16, 2017, 00:50:15 »
Entschuldigung aber wir reden hier aneinander vorbei :D

das soll der neue Fersehstandard in den USA werden, auch für Broadcast über SAT!

nix (reines) streaming
das ist nur ein nettes Gimmick/bzw. die wollen das beste beider Welten vermischen

ip =/ Internet

Filme geb ich mir auch nicht unbedingt übers Handy, aber normales Fernsehen/Nachrichten, warum nicht?
und wie gesagt: Handys sind nur ein zusätzliches Gerät
warum kein Fernsehen abends beim Camping auf dem Tablet
oder Abends mit dem Handy im Bett

das geht schon

desweiteren
für 24/7 abrufbare Nachrichten wäre unicast beispielsweise doch sehr geeignet
ist eben die stärkere Vermischung von hbbtv mit Fernsehen

man könnte sogar Filme vorab zum Schauen downloaden über SAT, falls die sowas umsetzen
der Standard könnte sowas unterstützen

genug Leute melden sich über Internet an
dann wird über einen datachannel der Film in überechtzeit gebroadcasted und vom Receiver aufgezeichnet, um ihn später wiedergeben zu können (ausgedachter Anwendungsfall)

zu dem was du sagtest:

Netflix hab ich bisher nur bei Kollegen benutzt

kennt eigentlich jemand von euch die Variante von Sky, taugt die was?
die haben wegen pay TV doch sicher mehr Lizenzen, oder?

13
Plauder-Ecke / Re: ATSC 3.0
« am: April 15, 2017, 23:42:37 »
Wenn ich das richtig lese wollen die über SAT, Cable und Antenne IP senden (eine Richtung)

und DVB-H ist gescheitert als es noch keine Smartphones/Tablets gab (auf so einem kleinen Nokia oder Autofernseher will doch niemand fernsehen) und die Bitrate und der Codec waren auch nicht sonderlich gut
ich bin sicher, das die daraus (mit)gelernt haben (die atsc kuck sich sicher auch die dvb an)

Wenn ich die richtig verstehe, soll das dann auch wenn überhaupt normales Antennenfernsehen sein, was sowas als zusätzliche Zielgruppe ansprechen soll

damit das funktioniert, will man auch VoD unterstützen

und multicast im Internet funktioniert, es müssen nur die middleboxen mitspielen
wenn Internet und Fernsehen beide über Kabel kommen, ist sogar dieselbe Firma dafür zuständig, dass die Daten ankommen

und über Kabel klappt multicasting mit Sicherheit noch besser, zumindest vermute ich das, da dort kein pppoe genutzt wird wie bei DSL (da wird der traffic dann nur noch im Rechenzentrum aufgesplittet, bei Kabel sogar noch zwischen dir und deinem Nachbarn)

die Anbieter sparen also vermutlich Berge an dupliziertem Traffic

dass es trotzdem nicht an echtes broadcasting rankommt ist klar

was genau draus wird und ob es aufgeht: ich bin gespannt

14
Plauder-Ecke / ATSC 3.0
« am: April 15, 2017, 16:10:09 »
Hab mir gerade folgenden Artikel durchgelesen:
http://atsc.org/newsletter/atsc-3-0-where-we-stand/#.WPIa5J5CSAN

Dachte das könnte auch andere hier interessieren.

Zielgeräte umfassen im neuen Standard auch Smartphones/Tablets.

Die Übertragung wird über IP mit UDP/TCP und ISO BMFF laufen. (Angleichung, weg von Transportstreams, hin zu dem was eh schon alle sprechen: IP)
letzteres scheint eine Art paketisiertes (aufgeteilt chunks) mov/mp4 zu sein

sowohl multicast als auch unicast sollen möglich sein, vlt. senden die manche der Streams auch übers Internet
Standard wäre derselbe, aber es wäre uneingeschränkt VoD möglich und nur der Empfangsweg würde sich unterscheiden

Codec ist wie zu erwarten hevc
von SD über interlaced bis hin zu 4k progressive 120fps scheint alles unterstützt zu werden

Es soll/wird inkompatibel zum bisherigen Standard sein
man will wohl einmal neu anfangen und ungehindert spezifizieren.

In Südkorea wird ATSC 3.0 anscheinend seit Februar diesen Jahres bereits ausgestrahlt.

Wann die USA folgen, ist mir nicht bekannt.

Bin gespannt, ob die DVB plant, irgendwann ebenfalls von Mpeg2 wegzumigrieren.
So skeptisch, wie aktuell soviele zu sein scheinen, was neue Standards betrifft, könnte ich mir aber eine derartige Umstellung hierzulande erstmal noch nicht vorstellen.
und hevc wird ja schon über diverse Kanäle gesendet

15
Plauder-Ecke / Re: Hat eine DVB-T2 HD Aufnahme keine I-Frames?
« am: März 20, 2017, 04:23:53 »
Man muss bei hevc also im Worst-case tatsächlich bis 2 GOPs (-1) abwarten, um decodieren zu können? klingt wirklich ungünstig

und sorgt (vermute ich) dafür, dass man wirklich nur noch genau auf I-Frames schneiden kann (Anfang und Ende müssen I-Frames sein)
(für weiteres müsste man vlt. decodieren und analysieren, was nicht lohnt)

(Hoffentlich fängt dann nicht noch jemand damit an, wie die BBC, zwischen IDR und I-Frames zu unterscheiden)

Kleinigkeit am Rande:
@Cypheros ist dir aufgefallen, dass im Log H.264 (HEVC) statt H.265 (HEVC) steht?


Offtopic:
hat schon jemand Zeit gehabt das Progressive Full HD mit den entsprechenden Sendern über Satellit zu vergleichen?
(bei den öffentlich-rechtlichen erwarte ich nach den Ankündigungen aktuell nur upscaling, die privaten könnten aber besser aussehen, vorausgesetzt die Quelle beim Sender wurde nicht zwischenzeitlich interlaced und deinterlaced, um der Abläufe willen)

Seiten: [1] 2 3 ... 116

www.cypheros.de