Beiträge von EVA-01

    Ich buddel den Thread mal kurz aus:

    Ich hab gerade eine ARTE Doku per TSMuxer von der Festplatte, auf die ich aufgezeichnet hab, und den mehreren .ts Files in eine m2ts konvertiert. Dabei gab mir TSMuxer folgende Meldung:

    SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
    Decoding H264 stream (track 1): Profile: Main@4.0 Resolution: 1280:720p Frame rate: 50
    H.264 stream does not contain fps field. Muxing fps=50
    Decoding AC3 stream (track 2): Bitrate: 256Kbps Sample Rate: 48KHz Channels: 2
    B-pyramid level 2 detected. Shift DTS to 3 frames

    Ich bin mal schnell meine wenigen Aufzeichnungen durchgegangen. Die, die funktioniert hat (von ARD aufgezeichnet), hatte als Meldung

    B-pyramid level 1 detected. Shift DTS to 2 frames

    Also war's vermutlich tatsächlich die B-Pyramide...?

    Und man braucht wie immer eine Sample aus dem originalen Video :)

    Das ist das originale Video. Das ist 1:1 der Stream vom Satelliten, nur halt in einen mkv Container verpackt. Ich lass die Dinger nicht als dutzende m2ts oder ts bei mir auf der HDD rumfliegen, wenn ich sie auch einfach in eine bequeme mkv muxen kann. ;)


    Danke schon mal für die Antworten, LigH. Hm, das klingt ja so, als würde der Fehler mysteriös bleiben... :(

    Nachtrag: Dieses Zittern gibt's auch nur auf dem BD-Player... wenn ich die gebrannte DVD am PC abspiele gibt's keine Probleme. Willst du trotzdem nen Ausschnitt?

    Hab mal schnell zwei kleine Clips aus der mkv geschnitten... da hat sich ja am Video im Vergleich zur m2ts nix geändert... hoffe das reicht, so richtig gleichmäßig lange Bewegungen hab ich nicht gefunden.

    http://www.megaupload.com/?d=DDVRJUA5

    Jo~

    Ich hab ein mieses Problem mit einer Aufzeichnung von ARTE HD - das Ding will sich um's Verrecken nicht ordentlich brennen lassen.
    Ich hab das Teil per DVB-S2 Receiver auf USB aufzeichnet und dann mit TSMuxeR die einzelnen m2ts gejoint. Anschließend hab ich den AC-3 Audiostream und den h264 Videostream per mkvmerge in eine mkv gepackt (mit 50 fps) um die NALU-Filler loszuwerden.
    Das Ding hab ich dann wiederum mit TSMuxeR als Blu-Ray und AVCHD gebrannt und mit meinem BD-Player (BD-P S360) abgespielt. Es ging auch, der Ton macht keine Probleme, aber das Bild hat so eine komische Mischung aus Zittern und Ruckeln. Ich kann's echt nicht genau beschreiben weil ich so ein Problem noch nie gesehen hab, aber es kommt mir so vor, als springt das Bild jede halbe Sekunde oder so mal wieder einen Frame zurück.
    Bin mittlerweile echt verzweifelt und hab keine Ahnung mehr, was ich machen soll. Eine andere HD-Aufzeichnung von ARD HD, die ich auf dieselbe Weise gebrannt hab, funktioniert problemlos. Ich kann ja auch nicht ständig testen und eine DVD-9 nach der anderen verbrennen, bis ich durch Zufall den Fehler finde. :(
    Ich hab auch die Videostreams beider Zusammenstellungen mit MediaInfo vergleichen, die sind nahezu identisch. Nur bei dem einen dieses grausige Ruckeln, bei dem anderen nichts.

    Hier mal die Info der Streams. Vielleicht fällt euch ja was auf, was BD-Player nicht mögen.

    THX Tilt, das Ding werd ich mal ausprobieren.

    @ Chetwood: Jo klar, aber blöd ist dann nur, wenn das betreffende Stück das man ausschneiden will im letzten Viertel des Films oder so ist. ;)
    Irgendwie ist diese Schnippelfunktion von mkvmerge zwar schon nett, aber trotzdem noch recht unpraktisch implementiert. Meiner Meinung nach. ^^;


    EVA-01
    Ich hätte eher gesagt, dass der Receiver genau so abspeichert, wie er den Stream bekommt. Immerhin werden alle Audiostreams, Teletext usw. mitgespeichert, obwohl diese ja nicht immer angezeigt werden. Insofern wundert es mich nicht, dass es Füllbits dazu gibt. Mich wunder eher, dass es so viele Füllbits sind. ;)

    Das wäre zumindest aus meiner Sicht aus mehreren Gründen unpraktisch.

    Zuerst einmal wird die Decodierung und Fehlerkorrektur der üblichen zyklischen Codes/Faltungscodes zur Übertraungssicherung zumeist durch die Hardware (Schieberegister können das ganz gut) erledigt. Die Konstrukteure der Receiver müssen somit nur noch einen kleinen Baustein kaufen, der bei Bedarf die Decodierung von Code X erledigt.
    D.h. der Stream geht in den Receiver rein, wird automatisch decodiert und DANN kriegt ihn erst die Software des Receivers in die Finger. Zum Abspeichern oder weitergeben an den Fernseher, die Anlage etc.
    Ferner würde es problematisch werden, wenn der Datenstrom vom Satelliten 1:1 auf der Festplatte abgelegt wird. Dann hätte man nämlich zwar (im Falle von systematischen Codes) Codewörter, aus denen man die Nachrichtenwörter direkt ablesen könnte - allerdings sind in dem Fall noch sämtliche Übertragungsfehler vorhanden. Will heißen, man hat keine Ahnung, ob die Nachrichtenwörter nun authentisch sind oder verfälscht wurden. Also müsste theoretisch beim Abspielen des Datenstroms auf der Festplatte gleichzeitig VOR dem Splitten der Container und dem Decodieren der Audio/Video-Daten noch eine zusätzliche Decodierung des Übertragungsschutzes erfolgen. Damit sämtliche, möglicherweise vorhandenen, Fehler korrigiert oder zumindest erkannt werden. Tut man das nicht, spielt man vermutlich totalen Scheiß ab - je nachdem wie gut das Signal war, das man gekriegt hat.
    Als einfaches Beispiel mal den systematischen 7,4-Hamming Code: Wir haben das Nachrichtenwort 1110 (Teil unserer Video/Audio-Streams). Mittels einer Generatormatrix (Allerdings arbeiten zyklische- und Faltungscodes mit Generatorpolynomen) erhalten wir das Codewort 0101110. Und dieses Ding wird nun über den Satelliten verschickt. Jetzt gibt's allerdings einen Übertragungsfehler und es kommt unten am Boden die Bitfolge 0101100 an. Der Decoder würde jetzt wieder diese Bitfolge mit der Generatormatrix verwurschteln und rausbekommen, dass an Stelle 6 ein Fehler vorhanden sein muss. Also muss das Nachrichtenwort 1110 heißen.
    Wenn man diesen Bitstrom aus Codewörtern jetzt einfach auf die Festplatte schmeißt und den Overhead aus Prüfbits weglässt, wird niemals erkannt werden, dass ein Fehler erfolgt ist - bis dann beim Abspielen Mist raus kommt. ;)
    Dass der Player oder Muxer oder Video-Encoder oder was auch immer selber den Fehlerschutz decodiert würde ja bedeuten, dass er Software-Algorithmen für sämtliche möglichen DVB-S/S2/C/T/T2- und was weiß ich noch für Codes vorrätig haben müsste. Und das sind Scheiße viele Codes...

    Jow...

    Ich suche schon seit längerem ein Tool zum Komfortablem Schneiden von mkv Containern. Was ich gefunden hab (z.B. avidemux oder VirtualDubMod) funktioniert bei Matroskas nur alle paar Jubeljahre und ziemlich beschissen.

    Mit mkvmerge kann ich zwar ohne Probleme Dateien zerschnippseln und auch noch wählen, was drinnen und draußen bleiben soll, aber einerseits muss ich immer die komplette Datei verwursten (wenn ich 10 Sekunden aus einem 2 Stunden Film haben will wird ja trotzdem der komplette Film in drei verschiedenen Dateien wieder rausgehauen) und andererseits hab ich keine Ahnung, ob ich mit dem Zeitstempel, den ich zum Cutten angegeben hab, jetzt auch wirklich den von mir gewünschten Keyframe/Szenenschnitt erwische.

    Also im Grunde suche ich was, das mkvs so schön schneidet wie VirtualDubMod oder avidemux dasselbe mit avis macht. :D


    EVA-01
    lol
    ARD HD befindet sich ja auch auf dem gleichen Transponder wie arte HD. Das hat System. ;)

    Ist nicht bei allen so... Ich hab zum Beispiel mal The Wrestler auf ARD HD aufgenommen, der hatte 8 oder 9 GB und nachm Muxen noch 6 oder 7. Aber Gesetz der Straße hatte mich schon geschockt. ;)

    Ich nutz eigentlich immer tsMuxer um die h264 und .ac3 aus der .ts rauszuholen und mux den Kram dann mit mkvtoolnix. Hat sich bewährt. :)


    Ich hab jetzt zwar keine Ahnung von DVB-S2 an sich, aber wie kommt ihr auf die Idee, dass beim digitalen Aufzeichnen des Datenstroms die Fehlerkorrekturbits mitgenommen werden?
    Der Videostream an sich wird wieder mit einem zyklischen Code codiert und der entstehende Stream an den Satelliten und von da aus wieder zur Erde geschickt. [strike]Dieser codierte Stream sieht allerdings NICHT so aus, dass da irgendwie z.B. 3 echte Bits und 2 Fehlerkorrekturbits rumlungern.[/strike] - Es gibt systematische und nicht systematische zyklische Codes, bei den systematischen ist das Nachrichtenwort im Codewort noch erkennbar. Das Ding ist komplett anders und wird dann wohl vom Receiver wieder in den normalen Stream dekodiert.
    Was auf der HDD ankommt dürfte eigentlich gar keine Fehlerkorrekturgeschichten enthalten weil damit ja die Video-Dekoder nichts anfangen können.
    Der tatsächliche Video/Audio-Stream wird ja in einen, sagen wir mal, Beutel gepackt und an den Satelliten geschickt. Der haut den Beutel wieder runter zur Erde. Dort kriegt der Sat-Receiver den Beutel, packt ihn aus, korrigiert die Fehler (sofern möglich) und gibt dann wieder den Video/Audio-Stream weiter.
    Wenn er die Fehlerkodierung beibehalten würde, wäre das ja vollständiger Quatsch - dann müsste ja auch noch der Fernseher "wissen", wie man nun diesen Code gegen Übertragungsfehler aufdröselt.
    Insofern dürfte auf der HDD auch nur das ankommen, was der Fernseher kriegt - den puren Video/Audio-Stream, ohne irgendwelche Kodierung gegen Übertragungsfehler.


    So als Beispiel: Wenn ihr einen Videostream aus dem Internet aufzeichnet, dann speichert ihr auch nur das Video an sich. Ohne die ADSL- oder ATM-Fehlerkorrekturcodes, die bei der Übertragung noch dazu gepackt werden.

    Dann probier doch Deine Files mit MakeMKV auf einen grossen USB Stick zu legen.
    Ev.erstmal schauen..welche

    der TV akzeptiert.

    Wie gesagt, mkv aufm TV ist kein Problem... generell funzt alles sofern's nicht irgendein abgehobenes Profil ist oder zu viele Reframes hat.

    Aber darum geht's hier nicht. Mein Vater hätte die aufgezeichneten HD-Videos nun mal gerne auf DVD, die er dann auf'm BD-Player abspielen kann, Punkt. ;)
    Weswegen es mich interessiert, wie ich das zum Laufen kriege. Bzw. warum's beim ersten Mal klappte, aber jetzt auf einmal nur Scheiße rauskommt.

    Das ist nicht für mich, sondern für meinen Vater. Der ist halt etwas konservativer und hätte den Kram gerne auf DVD. Eigentlich müsste das gar nicht sein, mein (eher sein) "freundlicher" TV hat USB-Eingang und frisst avi, mp4 und mkv (allerdings kein FLAC und DTS und ist sehr wählerisch bei den h264 Profilen - aber die aufgezeichneten TV-Sachen sind kein Problem).
    Und natürlich wird die gebrannte 720p50 DVD dann auch von einem BluRay-Player abgespielt der selbstverständlich per HDMI angebunden ist. Alles andere wäre ja Quatsch. ;)
    Ich wüsste auch gar nicht, dass DVD-Spieler DVDs mit HD-Content abspielen könnten.

    Ich fürchte, ein Ausschnitt wird wenig bringen. Die gebrannten DVDs werden nämlich spaßigerweise am PC problemlos abgespielt. :rolleyes_:
    Außerdem bin ich mittlerweile wieder in meiner Studentenwohnung, hier hab ich leider keinen BD-Player zum Testen. :/
    Was ich anbieten könnte wären die Images an sich. Hier ist schon einmal eine MediaInfo Analyse (0.7.47) der .m2ts, welche im Stream Ordner des BDMV-Verzeichnisses liegt:

    http://pastebin.de/18650

    Der Fernseher hat übrigens gestern auch in den Mode 1280x720@50 geschaltet, als ich die DVD eingelegt und abgespielt hatte. Also eine 24p Konvertierung wurde da nicht vorgenommen.

    Mal 'ne Frage...

    Ich hab damals (Ende Juni) einfach die .h264 und .ac3 genommen und mit tsMuxeR als "BluRay" gemuxt. Das Ergebnis hab ich dann mittels dieses Guides gebrannt. Also ImgBurn, dortige Einstellungen vorgenommen, die beiden Ordner auf die DVD gebrannt. Und mein BD-Player hat's anschließend ohne Probleme abgespielt.
    Jetzt hab ich dasselbe noch mal gemacht - mit zwei Filmen, einer bei ARD und einer bei ARTE aufgezeichnet. Aber nun klappt's auf einmal nicht mehr. Wird zwar vom Player abgespielt, Ton ist okay, aber das Bild ruckelt wie wild. So schätzungsweise zwei Ruckler jede Sekunde. Hat jemand eine Ahnung, woran das liegen kann? Die Rohlinge sind's nicht - einer war derselbe wie vor zwei Monaten und der andere war sogar nur ne DVD-5. :(

    Jow...

    Ich hoffe, ich bin hier richtig. Aber ich hab kein Forum gefunden, das für so 'ne Frage zuständig ist, also probier ich's mal hier. ^^;

    Ich bin mittlerweile auf madVR als Video-Renderer umgestiegen, und der Renderer hat ja die nette Fähigkeit, die Display-Modes zu wechseln um sich der Framerate anzupassen.
    Das wollte ich mir nun mal zu Nutze machen. Mein Monitor ist ein Samsung T240, Specs kann man hier nachlesen: http://www.samsung.de/de/Privatkunde…=specifications
    Dort steht nun unter Bildwiederholrate 50-85 Hz, also rein theoretisch genügend um auf 72 Hz und damit ne bessere 24p Wiedergabe zu kommen. Oder mit Glück auch 48 Hz. Ich hab zumindest im Netz Berichte von Leuten gefunden, die teilweise ältere Samsung Panels mit Nvidia GPUs zu 48 Hz "überreden" konnten.
    Aber da liegt nun mein Problem. Ich hab keine Nvidia. Ich hab dummerweise eine ATI (HD6870). Und ich kann als Bildwiederholrate auch nur die offiziellen Geschichten wählen - also 60, 50, 30 etc.
    Mit den Nvidia Treibern kann man wohl individuelle Auflösungen erstellen, z.B. 1920x1200 bei 47,xxx Hz und dann hoffen, dass es klappt - aber in meinen ATI-Treibereinstellungen habe ich absolut keine Möglichkeit gefunden, so etwas zu machen.
    Hat vielleicht jemand von euch eine Ahnung, wie ich meinen Panel 48 oder 72 Hz aufzwingen könnte...? :hm:

    Thx für alle Antworten.

    Mein Sony BD-P S360 kann rein gar nichts außer AVCHD und BluRay... ;)

    Na ja, hat aber geklappt, indem ich einfach mit TSMuxer aus den Streams eine BluRay gebaut und auf die Disc gebrannt hab. Die Einstellungen aus diesem Thread waren da sehr hilfreich.

    Außerdem muss die MKV-Kompatibilität nichts heißen. Ich hab erst letzte Woche feststellen müssen, dass mein Samsung TV (der über USB so ziemlich alles frisst, auch avi, mkv und mp4) Probleme mit mkvs hat, die mit den Standardeinstellungen von mkvmerge 4 und höher erstellt worden sind.
    MKV unterstützt wohl eine Headerkomprimierung, die in früheren mkvmerge Versionen wohl nicht unterstützt war, in neueren aber standardmäßig aktiviert ist... und der TV mag das wohl nicht.