Ich fürchte, das wird schwierig. Diese Fehlermeldung gibt leider nicht viele Hinweise auf die tatsächliche Ursache. Es kann eventuell mit (unnötig automatisch?) geladenen AviSynth-Plugins zusammenhängen, die beim Freigeben des AviSynth-Skriptes am Ende des Durchlaufes Probleme bereiten.
Läuft der HC-Encoder durch, wenn keinerlei Plugins (außer dem zum Laden des Quellvideos) verwendet werden? Ansonsten ist mir nicht bekannt, dass dieses Programm durch irgend welche Bedingungen instabil wäre.
ConvertToYV12 ist nicht nötig, weil AVCSource eh schon YV12 erzeugt ... ansonsten ist da auch nichts ungewöhnliches.
Hast du sehr viele DLLs und sonstiges im AviSynth-Plugins-Verzeichnis? Wahrscheinlich ja, wenn du kein 'LoadPlugin("DGAVCDecode.dll")' benötigst... Sollte man eventuell vermeiden. Die werden dort nämlich alle automatisch geladen, das kann Probleme bringen. Vor allem, wenn darin auch DLLs, die nicht AviSynth-Plugins sind, mit dabei sind.
Es könnte vielleicht auch helfen, mehr Hauptspeicher zu reservieren: 'SetMemoryMax(64)'. Auch sollte man die DGA-Datei noch mal neu erzeugen, wenn die DGAVCDec-Version aktualisiert wurde.
Eventuell könnte auch eine DGAVCDec-Version mal nicht ganz stabil sein. Oder es hilft, ein paar (Milli-) Sekunden am Ende des AVC-Streams von der Indexierung auszulassen (in DGAVCIndex.exe ein GOP vor dem Ende auf den "]"-Button klicken)...
Die Treppchen würde ich gern mal sehen... ein Ausschnitt eines kleinen Bildbereiches, der es besonders auffällig demonstriert, würde schon reichen:
AviSynth-Skript in VirtualDubMod öffnen, passende Szene suchen, [Umsch]+[1] (= "!") drücken, als PNG speichern, bearbeiten (zurechtschneiden - dafür reicht schon z.B. IrfanView: Maus mit gedrückter linker Taste über den Bereich ziehen, [Strg]+[Y]="Freistellen", speichern als PNG), und an die nächste Antwort im Beitrag anhängen.
AviSynth und VirtualDub(Mod) sind 32-bit-Anwendungen, so wie auch die meisten AviSynth-Plugins. Unter einem 64-bit-Betriebssystem sollte eigentlich alles im Kompatibilitätsmodus laufen ... aber wer nicht gerade mehr als 3 GB RAM hat, braucht eigentlich nicht unbedingt ein 64-bit-Windows.
Ob man ConvertToYV12 verwendet oder nicht, ist relativ egal, wenn der Clip vorher schon YV12 war: ConvertYV12 wird dann einfach nichts tun (weil überflüssig). Stört also technisch nicht wirklich. Notwendig wäre es nur, wenn man Filter verwendet, die im Ergebnis eventuell mal was anderes als YV12 erzeugen könnten. Bei AviSource oder MPEG2Source(upScale) wäre das denkbar. Aber AVCSource bietet hier eigentlich keine Wahl.
Soweit ich sehe - ein sauberes Bild, anamorph gestaucht (das ist richtig so - der HC kriegt genau das, was er soll; erst der Fernseher entzerrt das wieder). Allerdings ganz schön scharf, besonders in der einen Haarsträhne zu sehen... vielleicht zu scharf für MPEG2? -- Jetzt zum Vergleich mal den gleichen Ausschnitt aus dem encodierten MPEG2-Video daneben (selbiges via DGMPGDec in AviSynth geladen, wird auch wieder gestaucht aussehen).
Ich hatte dir ja empfohlen, eben gerade nicht die schärferen Resize-Funktionen (wie Lanczos oder Bicubic) zu verwenden. Und du hast genau das mit voller Überzeugung getan ... na, warum nicht. Man kann nicht alles theoretisch erklären, manches muss man einfach mal ausprobieren, und auch die schlechten Ergebnisse mal sehen, um vergleichen zu können.
Was im Original gut aussieht, muss in der Kopie nicht genau so gut aussehen, vor allem nicht bei beschränkter Bitrate für ein Encodingverfahren, das eben typische Artefakte zeigt, wenn die Quantisierung mal nicht minimal sein darf. Mit einem etwas weicheren Bild, wie von GaussResize erzeugt, würde ein nachfolgender MPEG2-Encoder vielleicht weniger störende Artefakte bringen. Was zu probieren wäre... 
__
23,976 fps und 576 Zeilen passen nicht zusammen... PAL hat 576 Zeilen, aber 25,0 fps; NTSC hat 29,97 fps - ließe sich per Telecine aus 23,976-fps-Film erzeugen, dann aber mit 480 Zeilen Höhe.
...anamorph gestaucht (das ist richtig so - der HC kriegt genau das, was er soll; erst der Fernseher entzerrt das wieder).
Zitat von Willensstark
Hier nochmal die encoder settings:
...
aspect ratio: 16:9
...
Das finde ich jetzt ungewöhnlich. Er resized doch schon im AVISynth-Script so, dass das Ergebnis anamorph gestaucht ist. Heißt für mich der HC soll das was vom Script kommt im PAR 1:1 encoden und nicht nochmal 16:9.
Zumindest mache ich das so.
greets
LTJ
hier wird der Encoder nur angewiesen, im MPEG auch das 16:9 Flag zu setzen und damit das Video als 16:9 zu markieren. Natürlich encodiert er mit PAR 1:1 (720x576).
BJ1
OK.
Allerdings scheint das aber nicht notwendig zu sein. Denn spätestens beim Authoring wird das PAR-Flag automatisch passend zu dem angelegten Projekt-Typ gesetzt.
greets
LTJ
Doch, das ist sinnvoll. Das AR-Flag im MPEG2-Video sollte doch bitteschön gleich von Anfang an stimmen, noch bevor es in das Authoringtool importiert wird. Dann stimmen beide überein (sowohl im Video in den VOBs, als auch in der IFO durch das Authoringtool).
__
PAR — P = Pixel oder Picture? Schwer zu unterscheiden. Daher in ISO/IEC 13818 (MPEG-2):
DAR — D = Display: Wiedergabe des Gesamtbildes, Seitenverhältnis des Gesamtbildes (4:3 / 16:9)
SAR — S = Sample: Element des Gesamtbildes, Seitenverhältnis des Bildpunktes (1:1, 11:12, 11:16)
Nicht zwingend vorgeschrieben, aber meiner Meinung nach nützlich, um den Unterschied zu verstehen, was denn hier ins Verhältnis gesetzt wird.
...Denn spätestens beim Authoring wird das PAR-Flag automatisch passend zu dem angelegten Projekt-Typ gesetzt.
Nein, das PAR (Pixel Aspect Ratio) bleibt am PC innerhalb der Verarbeitungskette immer gleich (1:1) - außer ich resize natürlich nichtproportional (blödes Wort).
Ein HDTV mit 1920x1080 ist exakt 16:9 (1920/16*9=1080). Hier ist PAR = DAR. Soll das auf DVD, muss "unproportional" auf 720x576 resized werden. Das PAR dieses Bildes ist nun 5:4, dem Ausgabegerät muss ich aber mitteilen, ob das Bild denn auf 4:3 (768x576 Bildpunkte) oder 16:9 (1024x576 Bildpunkte) gestreckt werden soll. Dafür ist das DAR-Flag im MPEG da.
Ein "richtiges" DVD-Authoring-Programm erwartet korrekt markierten Input. Ein als 16:9 geflaggtes MPEG wird es auch wieder als solches ausgeben.
BJ1
Doch, das ist sinnvoll. Das AR-Flag im MPEG2-Video sollte doch bitteschön gleich von Anfang an stimmen, noch bevor es in das Authoringtool importiert wird. Dann stimmen beide überein (sowohl im Video in den VOBs, als auch in der IFO durch das Authoringtool).
__PAR — P = Pixel oder Picture? Schwer zu unterscheiden. Daher in ISO/IEC 13818 (MPEG-2):
DAR — D = Display: Wiedergabe des Gesamtbildes, Seitenverhältnis des Gesamtbildes (4:3 / 16:9)
SAR — S = Sample: Element des Gesamtbildes, Seitenverhältnis des Bildpunktes (1:1, 11:12, 11:16)
Nicht zwingend vorgeschrieben, aber meiner Meinung nach nützlich, um den Unterschied zu verstehen, was denn hier ins Verhältnis gesetzt wird.
Ich hab jetzt nochmal nachgeschaut. Es gilt nach ITU-T H.262 für MPEG2 für das 4 Bit AR-Flag "aspect_ratio_information" im Sequence Header:
[Blockierte Grafik: http://img2.abload.de/img/ar-mpeg2fn6y.jpg]
Also im Grunde so wie du es auch geschrieben hast und wie das bei unserem Fr_An auf der Homepage auch beschrieben steht.
Was die Entzerrung während der Wiedergabe angeht, so muss laut dieser Recommendation - wenn ich das halbwegs richtig übersetzt habe - ein Zuspielgerät, für den Fall, dass die volle TV-Bildfläche
[Blockierte Grafik: http://www.abload.de/img/sde_not_present6l6r.png]
genutzt wird, nach
[Blockierte Grafik: http://www.abload.de/img/sar-formel7qt5.png]
und resultierender Tabelle (PAL):
| SAR | DAR |
-----------------------------------|
704 x 576 | 1:1 | - |
| 11:12 | 3:4 |
| 11:16 | 9:16 |
| 1100:1989 | 100:221 |
---------------------------------- |
720 x 576 | 1:1 | - |
| 15:16 | 3:4 |
| 45:64 | 9:16 |
| 125:221 | 100:221 |
-----------------------------------|für sowohl 704x576 und 720x576 für PAL
immer auf 1024 (16:9) bzw. immer auf 768 (4:3) in horizontaler Richtung gestreckt werden.
Nein, das PAR (Pixel Aspect Ratio) bleibt am PC innerhalb der Verarbeitungskette immer gleich (1:1)
Das ist mir klar.
Ein HDTV mit 1920x1080 ist exakt 16:9 (1920/16*9=1080). Hier ist PAR = DAR. Soll das auf DVD, muss "unproportional" auf 720x576 resized werden.
Das ist mir klar.
Zitat von BJ1Das PAR dieses Bildes ist nun 5:4, dem Ausgabegerät muss ich aber mitteilen, ob das Bild denn auf 4:3 (768x576 Bildpunkte) oder 16:9 (1024x576 Bildpunkte) gestreckt werden soll.
Das ist mir klar.
Zitat von BJ1Dafür ist das DAR-Flag im MPEG da.
Ein "richtiges" DVD-Authoring-Programm erwartet korrekt markierten Input. Ein als 16:9 geflaggtes MPEG wird es auch wieder als solches ausgeben.
Eigentlich geht es nur um diesen Punkt. Dieser ist strittig, denn:
Anmerkung:
Bei Transportstreams (*.TS) könnte es tatsächlich sein, dass das Flag nötig ist, bin aber gerade nicht sicher ob da nicht vielleicht auch im PES-Header ein paar Bits für reserviert sind. Und natürlich immer dann, wenn es direkt um Elementary Streams geht, die nicht weiterverarbeitet werden.
Die gaanz einfache Frage am Ende ist also:
Warum genau "sollte doch bitteschön gleich von Anfang an" (Ligh) das Flag für eine DVD gesetzt werden? Es gibt keinen wirklichen Grund.
Genau wie es bei der MPEG4-Geschichte auch keinen wirklichen Grund dafür gibt, wenn am Ende ein vollwertiger Film mit Audio, Subtitles, Chapters etc. gebaut wird, da muss auch immer ein Container her und da gehört dann das Flag rein. Ein vernünftiger Player kann das dann auch wieder auslesen und ist nicht auf das Flag im Bitstream angewiesen. Mosu lässt das Flag beim Muxen mit mkvmerge bei MKV glaube ich sogar auch rausfliegen, wenn man nicht explizit mitteilt, dass es erhalten werden soll. Aber ich schweife ab ...
greets
LTJ
...wenn ich den HC mit einem DAR=SAR von 1:1 encoden lasse, sollte im Sequence-Header die Bitfolge 0001 für "aspect_ratio_information" stehen (ungetestet). DVDMaestro (benutze ich noch immer) nimmt das Material trotzdem an. (Wie siehts mit DVDLab aus, weiß das jemand?)
DVDlab zeigt das im ES gesetzte DAR an (4:3 oder 16:9). Im zum VTS gehörenden IFO wird die DAR des ersten zum VTS gehörenden PGC gesetzt. Daher warnt DVDlab auch beim Erstellen von VTS mit gemischten ARs, lässt das Erstellen aber trotzdem zu.
Anmerkung:
Bei Transportstreams (*.TS) könnte es tatsächlich sein, dass das Flag nötig ist, bin aber gerade nicht sicher ob da nicht vielleicht auch im PES-Header ein paar Bits für reserviert sind. Und natürlich immer dann, wenn es direkt um Elementary Streams geht, die nicht weiterverarbeitet werden.Die gaanz einfache Frage am Ende ist also:
Warum genau "sollte doch bitteschön gleich von Anfang an" (Ligh) das Flag für eine DVD gesetzt werden? Es gibt keinen wirklichen Grund.
Letztendlich hast Du Dir die Frage mit der obigen Anmerkung bereits beantwortet. Und irgendwann im Bearbeitungsprozeß musst Du es setzen.
BJ1
@ Wille:
Spruce ist tot. DVD Maestro ist zwar ein nach DVD-Spezifikation korrekt arbeitendes Programm; nach der Entwicklung von Windows als Betriebssystem, auf dem es laufen soll, jedoch völlig veraltet - es kann Multimedia-Möglichkeiten von Windows XP oder Vista nicht mehr nutzen.
Aktuelle, moderne DVD-Authoringtools wären u.a. MediaChance DVDlab im kommerziellen Bereich, sowie die skriptgesteuerte Freeware DVDAuthor mit ihren GUIs.
@ LTJ:
MPEG-2 propagiert "Generic AR" (DAR für volle Bildfläche). Das ist die Theorie. Was die Praxis angeht, kann ich leider nicht viel mitreden, aber wenn festgestellt wird, dass viele DVD-Player ihr Video laut IRU-R BT.601 ausgeben (oder sind es die Fernseher, die es so darstellen?), dann ist das eben ein experimentell ermittelter Fakt...
Es mag auch Fakt sein, dass die DVD-Player sich bei der Entzerrung nach den Flags in der IFO richten. Nur werden diese Flags ja vom Authoring-Tool erzeugt, und das wird beim Importieren des Videos wohl zunächst mal das Seitenverhältnis aus dem Video auslesen. Wenn es darin falsch steht, muss also der Authoring-Mitarbeiter das Seitenverhältnis manuell korrigieren. Wenn das Authoring-Tool so etwas überhaupt erlaubt. Also - warum nicht auf korrekte Flags im Video achten?
Professionelle Studio-Authoringtools haben jedenfalls ordnungsgemäße Flags im Videostrom erwartet (z.B. Sonic DVD Creator 2.x), und erst gar kein MPEG2-Video angenommen, das nicht laut DVD-Spezifikationen mit DAR 4:3 oder DAR 16:9, sondern mit SAR 1:1 encodiert wurde.
Übrigens - was meinst du mit "DAR=SAR von 1:1"?! -- DAR 1:1 hieße 576x576 Pixel als "entzerrte" Wiedergabe.
Zitat von LigHÜbrigens - was meinst du mit "DAR=SAR von 1:1"?!
Das ist natürlich Quatsch. SAR von 1:1 muss es heißen. Ich war wohl ein wenig neben der Spur durch
Ein HDTV mit 1920x1080 ist exakt 16:9 (1920/16*9=1080). Hier ist PAR = DAR.
Wahscheinlich hat sich BJ1 auch nur vertippt. Für HDTV muss es heißen PAR = 1:1 und DAR=16:9.
------
Zitat von LigHNur werden diese Flags ja vom Authoring-Tool erzeugt, und das wird beim Importieren des Videos wohl zunächst mal das Seitenverhältnis aus dem Video auslesen.
OK.
Allerdings scheint das aber nicht notwendig zu sein. Denn spätestens beim Authoring wird das PAR-Flag automatisch passend zu dem angelegten Projekt-Typ gesetzt.
Hiermit meinte ich, dass mit der Wahl des Projekttyps automatisch für das Authoringprogramm (zumindest scheint das bei Spruce DVD-Maestro so zu sein) schon klar ist, was in der IFO zu stehen hat. Das Auslesen des Flags ist ja dann nicht mehr nötig und es muss nur noch die tatsächliche Höhe und Breite des Quellvideos auf Konformität geprüft werden.
Andererseits:
Zitat von LigHProfessionelle Studio-Authoringtools haben jedenfalls ordnungsgemäße Flags im Videostrom erwartet (z.B. Sonic DVD Creator 2.x), und erst gar kein MPEG2-Video angenommen, das nicht laut DVD-Spezifikationen mit DAR 4:3 oder DAR 16:9, sondern mit SAR 1:1 encodiert wurde.
DVDlab zeigt das im ES gesetzte DAR an (4:3 oder 16:9).
Habt ihr denn tatsächlich überhaupt mal Streams getestet die mit einem SAR-Flag von 1:1 encodet wurden oder sind das Vermutungen?
Ich will aber gar nicht streiten und auch keine Haarspalterei betreiben.
Man könnte das tatsächlich mal einfach ausprobieren, indem man den HC mit SAR 1:1 encoden lässt und schaut ob auch andere Authoringprogramme diese Streams akzeptieren. Zudem könnte man auch mal den 4-Bit-Wert vor und nach Authoring aus dem ES auslesen und schauen ob die Authoringtools selbst patchen (falls der Stream akzeptiert wird) oder den IFO-Eintrag vorab generieren.
Spruce ist tot. DVD Maestro ist zwar ein nach DVD-Spezifikation korrekt arbeitendes Programm; nach der Entwicklung von Windows als Betriebssystem, auf dem es laufen soll, jedoch völlig veraltet - es kann Multimedia-Möglichkeiten von Windows XP oder Vista nicht mehr nutzen.
Das verstehe ich nicht. Es arbeitet korrekt! -> Ist doch Klasse.
Welche Multimedia-Möglichkeiten sollen denn da groß ausgeschöft werden? 
Das Programm soll eine DVD produzieren und nichts weiter und das kann es.
Natürlich möchte ich damit nicht abstreiten, dass DVDLab und Sonics Authoringtool und andere im Gegensatz zu DVDMaestro, was die Möglichkeiten und den Komfort angeht zeitlich auf der Höhe sind. 
Zitat von LigHMPEG-2 propagiert "Generic AR" (DAR für volle Bildfläche). Das ist die Theorie. Was die Praxis angeht, kann ich leider nicht viel mitreden, aber wenn festgestellt wird, dass viele DVD-Player ihr Video laut IRU-R BT.601 ausgeben (oder sind es die Fernseher, die es so darstellen?), dann ist das eben ein experimentell ermittelter Fakt...
Ich glaube jetzt sind wir wieder hier
http://encodingwissen.de/spezial/itur-bt601.html#generisch
und hier
http://encodingwissen.de/spezial/itur-bt601.html#diskussion
angekommen.
Das weiß ich nämlich jetzt auch nicht genau. Entzerrt der DVD-Player und der TV stellt einfach das 1:1 dar, was er vom Player bekommt oder schickt der Player das Flag weiter zum TV und der resized?
Wenn Ersteres:
Hat der DVD-Player den SAR-Faktor (Welchen Generic oder ITU?) einprogrammiert und bekommt ein DAR-Flag oder umgekehrt.
Wenn Zweiteres:
Hat der TV den SAR-Faktor (Welchen Generic oder ITU?) einprogrammiert und bekommt ein DAR-Flag oder umgekehrt.
Ich vermute der SAR Faktor ist einprogrammiert, denn in IFOs finde ich nur DAR-Angaben. Und das von Gerät zu Gerät völlig durchmischt zwischen Generic und ITU, wobei es deshalb niemals ein generelles Richtig oder Falsch gibt.
Irgendwie dreht sich gerade alles 
greets
LTJ
Hi
passt vileicht nicht hir her aber ich frage dennoch mal :
Kann mir mal wer sagen wie man in einem h.264 file nachträglich chapters setzten kann ?
ich meine die dinger wo man immer von Sceene zu Sceene springen kann .
Weil ich hatte mir nen h.264 mit HCEncoder für ne DVD fertig gemacht dann mit ReJig die vobs machen lassen - mit Nero gebrannt . kann Normal vorspulen x2,x4,x8x16 u.s.w.
aber eben nicht bis nur nächsten Szeene springen .
Wenn ich diese Chapters mit welchen Proggi auch immer machen kann wäre es besser die zumachen nach dem Encoden oder vorher ??
MFG
Digitale
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
