Interlaced und NTSC, MAL Wieder (!!)
 

Hallo zusammen,

das Thema Interlaced und NTSC läßt mich einfach nicht los.
Ich habe immer wieder Movies, wo folgendes Bild in DVD2AVI auftaucht:


http://www.digitalfaq.com/archives/error.gif

Was zum Teufel hat das zu bedeuten? Ich kann selbst nach mehrfachem Suchen keine Artefakte, in welcher Form auch immer, finden.

Ich habe schon das Experiment gemacht, das Projekt mal mit "Forced Film" und mal ohne abzuspeichern. Das ohne "Forced Film" gespeicherte Projekt wurde mit dem Interlaced Script von Boulder bearbeitet. Das mit "Forced Film" gespeicherte Projekt (also 23,97 fps) wurde mit dem MA Script von Kwag bearbeitet.

Ergebnis:

Beide Samples waren qualitativ gleich gut (bei gleichem CQ 60).
Das Sample mit 29,97 und Interlaced Script von Boulder war ca. 20 MB groß.
Das Sample mit 23,97 und MA Script von Kwag war ca. 25 MB groß.

Ich wüße nun zu gern wo ich dran bin und wie ich diese Dinge weiter behandeln kann. Ich werde bis dahin alles wo Interlaced steht mit 29,97 speichern und mit dem Script von Boulder behandeln.

Ich hoffe der Incredible liest das hier ;)

Gruß,
Zaks

Und ob der das liest! ;-)

Also, du hast schon recht, normalerweise kann man sich auf die Kamm-Effekte verlassen, aber bei NTSC spielt ja auch noch die Framerate ne Rolle :!:

Was ich überhaupt nicht kapiere ist, das ein von dir 23.976 enkodierter Film mehr Endgrösse hat, als ein 29.976!! Das macht technisch keinen Sinn, denn 29.976 sind mehr Bildinformationen!

Und ... sind beide gleich synchron???? 8O

8O Synchron?

Also ehrlich gesagt hab ich mich darum noch nicht gekümmert.
Ich teste das Script immer erst in VDub und da war alles in Ordnung.
Ich arbeite übrigens nach dieser Methode :
http://www.kvcd.net/forum/viewtopic.php?t=2663

Was mich verwunderte ist natürlich das, wie von Dir gesagt, ein Film mit 23,976 kleiner sein sollte als mit 29.976. :!:
Ich werde heute noch einen Test machen, vorausgesetzt ich erwische wieder so ein fieses SVCD Teil. :!:

Gruß,
Zaks

Ja genau. So wie ich zaks verstanden habe, hat er aber mit zwei unterschiedlichen scripten getestet, einmal von Kwag und einmal von Boulder.
Welche Version von DVD2AVI benutzt Du?
Leider gibt es immer noch sehr viele Fehler bei der Erkennung von PAL-movies. Ich verlasse mich nie auf diese Angaben...

Meine DVD2AVI Version: 1.77.3dg1.0.0RC2
war hier im Forum, DVD2AVI Abteilung gepostet.

Leider habe ich im Moment kein Movie mit 29,97 NTSC / Interlaced.
Aber mein DVD2AVI hat mir ein 25 fps / Interlaced Video angegeben,
so etwas habe ich auch nicht gesehen. Gibts das überhaupt? Auch hier keine Artefakte zu sehen :!:

@Krassi: Auf welche Angaben verläßt Du Dich? Was nimmst Du zum checken?

Gruß,
Zaks

Gibt's schon, ist aber sehr selten.
Ich mache sehr wenig mit NTSC, hole mir die Informationen aber wenn benötigt aus VirtualDub(Mod) 8)

Ähm, .. wass den nun, wir reden hier doch über ein -so wie oben gezeigtes- 29.976 vermeintlich NTSC interlaced movie!?

Also verlassen tut sich hier keiner auf Angaben von manchen Applikationen ;-)
Das Auge beim gucken des Filmes (via AVS incl. Mpeg2source Zeile und nix sonst) in Vdub lügt nicht, und wenn etwas Zeilenbasiert ist, also interlaced, dann merkst du das bei schnellen Scenen sofort.

Als der Liebe Gott seinen schlechten Tag hatte, hat er zwei Dinge erschaffen!:

1. Alice Schwarzer!!!!!!
2. NTSC!!

Die Unterschiede von progressivem NTSC und interlaced NTSC sind enorm im Vergleich zu PAL interlaced und progressive, daher auch meine Skepsis bzgl der komischen Filegrössen. Daher tippe ich auf 23.976 FPS in deiner source als "real", welche eben durch die versch. Skripte eine untersch. Filegrösse bekommen haben ... hmmmmm.


Du kannst zu 99% davon ausgehen (bei vernünftigen NTSC DVDs) dass bei Blockbuster Filmen, welche ja auch meist auf Film und nicht auf Video aufgenommen sind, ... eine FPS von 23.976 als "real" vorliegt, welche dann einen Pulldown Flag verpasst bekommen hat, damits der Player als 29,976 dann abspielt (pulldowned while play!).
Ebenso auch die Anzeige von "Interlaced" .... diese Bedeutet bei Blockbuster movies fast immer, dass es sich lediglich um einen interlaced-flag handelt, welcher für den Player und sein "internes" Abspielen von vorteil ist.

Wenn du also keine "Kamm" Effekte siehst, ist da nix interlaced! Und demnach immer "real" 23.976 im Falle von NTSC ... habe es noch nie anders erlebt. Daher gibts auch keine gerippten NTSC Blockbuster Dvixe mit 29.976! Denn die stammen eben von 23.976 "real" DVDs mit Pulldown flags.

Kompliziert, nicht? Stimmt!
Ich hasse es auch, obwohl ich mittlerweile ein feeling dafür habe, was für ein Nutella drin ist, obwohl Nutella drauftseht ... :lol:

:mnkypile:

Also gut Jungs 8) , dann werd ich mich in Zukunft auf meine Augen verlassen.

Auch wenn meine Mutter immer sagt das ich schlecht sehen schon immer gut konnte.

@inc.
Das mit dem PAL Interlaced hab ich nur geschrieben, weil ich grad über so ein Ding gestolpert bin.
Ein NTSC 29,976 / Interlaced hab ich bis jetzt nicht mehr gefunden. Hab die Source nach gelungenem Encoden gelöscht.

Aber mal ehrlich, worin liegt eigentlich das Problem ein Programm zu coden, welches einen Videostream genau analysiert und niht interpretierbare Werte ausspuckt?

Gruß,
Zaks

Normalerweise ist es so, dass es nie gedacht wurde, mpeg als real interlaced zu encodieren, da filme ja eben meist auf progressivem material beruhen ... daher gabs auch lange mpeg1 als das Format für filmkodierungen. Tja und dann hat mann es erweitert ... noch ein paar Algorhythmen rein, interlacing Fähigkeiten, 3:2 pulldown, etc. ... zu Mpeg2 damit auch keiner mehr heulen konnte.
Demnach wurde auch neben dem 720x576 (PAL) auch das 704x576 mpeg2 DVD Format verabschieded, denn das hat eben den Sinn, das PAL 625 Zeilenbasierte Tv-Streams, richtig enkodiert auch auf die DVD gebrannt werden können. 8)


@ Krassi
Sag mal, was ist denn aus eurer Hammer Nacht-und-Nebel Prediction Aktion geworden??
Hatte mich da dann raus gehalten, da ich keine Zeit zum probieren hatte und jegliche Art der Zugabe "meines Senfs" eh nur Vermutungen gewesen wären .... den Taten zählen ;-)

Ich hatte leider nicht mehr so viel Zeit, um noch mehr zu testen :roll: Meine Todo-Liste ist noch voll, die von Kwag umfasst schon viel zu viele Seiten :lol:
Wir sind damals zur Folgerung gekommen, dass dieser Art der Prediction sich lohnt, da das Ergebnis besser ist als bisher. Allerdings wird es dann keinen Zeitvorteil geben. Dies gilt für niedrige durchschnittliche Bitraten mit wenig "Varianz", d.h min-Rate ca. bei 700 und max bei 2000.
Bei höheren Bitraten z.B. für KDVD ist das Problem etwas grösser und die Länge des Samples muss deutlich grösser ausfallen. Ich nutze ausschliesslich KDVD mit min 500 und max 5000. Hierbei spielt TMPGenc eine Rolle, da bei VBR die durchschnittliche Bitrate stark eingehalten wird.
Fazit: Für KVCD brauchbar, allerdings ist hier wieder das Zeitproblem von Kwag ausschlaggebend, dies in CQMatic zu realisieren.
Sobald ich mehr Zeit habe, werde ich wieder ein paar Tests durchführen.

Das Problem (so wie ich es sehe) mit CQ matic in der jetzigen Version ist, dass immer die selben Samples genommen werden. Jeder 2te Durchlauf müsste mit einem Start-Offset von z.B. 2 Min - bzgl. Beginnen des sampelns - erfolgen.
Am Ende wird ein Durchschnitt der Predictions (offset=0 und Offset=2min) gezogen, somit hat man mehr Samples bei gleicher Predictionzeit, was die Sache was genauer macht. Den Vorschlag hatte ich KWAG auch schon via PN die letzten Tage geschrieben. Man sollte mal drüber nachdenken.

Das ist eine gute Idee.
Allerdings müsste dann der richtige CQ zweimal gesucht werden und daraus das Mittel genommen werden. Hab ich Dich so richtig verstanden :?:
Wenn ja, dann hätten wir doch einen höheren Zeitaufwand, trotz der Hälfte der Länge des samples. Der Algorithmus müsste dann doch zweimal laufen.
Wäre aber mal einen Test wert.

Yep, hast mich beinahe richtig verstanden ;-)
Wenn du momentan z.B. 6 Durchhläufe mit EINEM Offset bräuchtest, dann mit einem neueren CQmatic eben 3x mit Offset a und 3x mit Offset b, müsste hinkommen, .... und wenns eben 2 Durchläufe mehr sind, ists nicht so schlimm, wenns dafür so gut wie perfekt rauskommt ;-)

Ich nutze sehr oft bei schwierigen Filmen z.B. noch TOK und setze 2 Samples die Minute inkl. 75 Frames bei PAL, der Erste Durchlauf dauert zwar was länger, unterscheidet sich aber von den anderen kürzeren Durchläufen und daher ists eben sehr genau, da ja untersch. Sampel-Strecken verwendet wurden.

Interessant Euch zuzulesen 8)

Ich teste den CQ-Wert mit CQMatic und runde entsprechend auf *5 oder *0 auf. Klar das das Ergebnis dann etwas größer ausfällt. In der Regel jedoch nur ca. 8%, diese shrinke ich mit der ReJig GUI aus dem Doom9 Forum ein, denn bei den 8% hab ich bisher noch keine negativen Ergebnisse bobachten können.

Was haltet Ihr von dem Weg? Zumal schon überlegt wird Requant in CQmatic einzubauen.

Gruß,
Zaks

Ich würde es lieber ohne probieren. Der Qualitätsverlust mag nicht unbedingt sichtbar sein, es gibt aber immer eine Verschlechterung...
Hast Du mal mit VirtualDubmod einen Frame verglichen, den Du mit und ohne Requant gemacht hast :?:
Probier das mal an einer Stelle, an der viel Bewegung ist...
Ich würde versuchen, lieber etwas drunter zu bleiben, da 10 MB keinen so grossen Unterschied ausmachen.
Kwag hat ja überlegt, Requant in CQMatic zu integrieren, hat dies aber nach einigen Tests wohl wieder verworfen.

Zumal det Ding ja nur mit mpeg2 arbeitet, .... tja und ich enkodiere alles in mpeg1, ausgenommen interlaced captures oder 23.976 pulldowned streams, sowie natürlich K/M DVDs