Das geht natürlich ebenso in Avisynth: mit LaTo's "SmoothAdjust.dll", Filter "SmoothCurve". Freie Kurvenanpassung, inklusive Smoothing/Dithering für die expandierten bzw. komprimierten Level-Bereiche. Weiß nicht ob der Edius das auch kann? 
Youtube Videos ... bitte mal 'ne Meinung abgeben
-
-
Der DGIndexNV kann leider noch keine MP4-Container
Eigentlich sollte er das aber inzwischen können.
-
Zitat
Das geht natürlich ebenso in Avisynth:
Das ist mir bekannt,hab ja auch geschrieben dass es aber etwas umständlich ist....Script anpassen...VDub starten,Sichten....Aha....Script ändern...aah nun ists okay.Habs erst vor ein paar Tagen probiert.
http://frupic.frubar.net/fullsize/29008
war ein Gefrickel.......bis die beiden Balken Li+re nicht mehr gelbfarben angezeigt wurden.Aber das
ZitatLaTo's "SmoothAdjust.dll",
kannte ich noch nicht.Cool.Freie Kurvenanpassung ist natürlich in Edius schon möglich.Das Schöne hier,ich kanns gleichzeitig auch auf einem Sichtgerät überprüfen und da wo die Mausspitze verweilt wird mir auch genau das Level angezeigt.Ansicht vorher und nachher.
-
Ja, dass freie Kurven möglich sind ist schon klar. Is' ja kein so großes Ding. Ich hatte das Dithering gemeint. Einfaches Beispiel: wenn eine Graustufentreppe 20,21,22,23 per Kurvenabflachung auf die Hälfte zusammengestaucht wird, dann haste statt 4 Bereiche nur noch 2 Bereiche (z.B. 20&21~> 20, 22&23~> 21). Information geht verloren. Wenn SmoothAdjust mit Dithering arbeitet, dann haste nach dem auf-die-Hälfte-Zusammenstauchen immer noch 4 Bereiche. 20->20, 21->(Dithering-Mix aus 20+21), 22->21, 23->(Dithering-Mix aus 21+22). Und andersrum bei Tonwert-Spreizung: Wenn man einen Kurventeil z.B. auf 400% Steigung anhebt, dann entstehen da "Löcher" im Histogram. 0->0, 1->4, 2->8, 3->12 usw, und nix dazwischen. Ein unstetes Histogram, wodurch oft auch "Banding" sichtbar werden kann. SmoothAdjust kann das vermindern, indem die lokalen Gradienten abgeschätzt, und dann diese "Löcher" im Histogram entsprechend aufgefüllt werden.
Eben solche Kleinigkeiten und Nebensächlichkeiten. Und ich hatte mich halt gefragt, ob der Edius das auch .... oder doch eher nicht.
-
Bei dem Test ist mir gerade aufgefallen, das meine erstellten MP4-Videos via DirectShowSource() nur graue Frames zurückliefern. Jemand ´ne Ahnung warum?
Man braucht für DirectShow für jedes Format einen passenden Source-/Splitter-Filter und einen kompatiblen Decoder-Filter für jeden Inhalt. Und wenn die Quelldatei unvollständig ist (z.B. fehlende Indexblöcke im Kontainer), muss man unter Umständen auch noch lineares Decodieren erzwingen (seekzero=true).
Um zu prüfen, welche DirectShow-Filter verwendet werden, und ob dabei vielleicht einer ist, dem nicht zu trauen wäre, kann man GraphStudio verwenden.
Der DGIndexNV kann leider noch keine MP4-Container ... geht das mit irgendeinem anderen Parser?
FFmpegSource2, vermutlich auch LSMASHSource (gerade entdeckt).
Aber ja, DGDecNV sollte eigentlich...
Changes.txt
CodeBuild 2044 ---------- * Added MP4 container support. ... -
Zitat
Eben solche Kleinigkeiten und Nebensächlichkeiten. Und ich hatte mich halt gefragt, ob der Edius das auch .... oder doch eher nicht.
""Nebensächlichkeiten""...wohl eher "Feinheiten"...wenn ichs richtig verstanden habe,macht das Dithering,Edius automatisch.
Zitat"Banding"
wohl kaum bei solchem Material.[analog Captures]
-
Schade ... wie befürchtet mach der recode bei YT den crf24 und leider auch einen crf22 kaputt ... ist und bleibt wohl nie eine gute Idee rauschen zu encoden ... egal wie gut das im ursprünglichen Video ausgesehen hat
Wofür braucht ihr die Kurvenanpassung eigentlich ... nur für analoges Material?
... MP4's in DirectShow ... "Microsoft DTV-DVD Video Decoder" ...
****update*** habs gerade mit Win7DSFilterTweaker totgehauen das Microsoft-Ding ... nu geht auch DirectShowSource() wiederDie "Build 2044" von DGDecNV kann meine MP4-Container nicht lesen ... uaah ... der parsed die zwar, sagt aber er hätte keine Frames gefunden ... Zitat:
"Found NALU type 22, len 19762 undefined, ignore NALU, moving on"
"data partitioning not implemented"
"invalid sps -> pic_order_cnt_type = 3"
"Error: pic_order_cnt_type != 1"die kommen in dieser Reihenfolge 2-3 mal, dann semmelt er ab.
Was soll der Käse?
Liegt das an meinem mux? ... ich muxe mit mp4box (die is allerdings auch schon was älter).
Womit schneidet ihr eigentlich MP4 (möglichst verlustfrei, recode nur an den Schnittpunkten oder ohne am GOP)?
Meine MPG2 hab ich früher immer mit MPEG-VCR geschnitten ... das ging super schnell und ohne nerviges demux/mux/recode.
-
Wenn DGIndexNV ein MP4 nicht verarbeiten kann, wird das Donald Graft sicherlich interessieren (mit kürzerer Beispieldatei zum Herunterladen).
Was das Schneiden von MP4 angeht: Such mal nach "smart rendering" (und dazu noch "avc" oder "h.264"), aber erwarte eine Enttäuschung... AVC ist nun mal um Größenordnungen komplexer als MPEG2. GOPs können nicht nur länger sein, die Abhängigkeiten zwischen enthaltenen Frames sind auch deutlich stärker, und für optimale Kompatibilität müssen auch viel mehr Nebenbedingungen wiederhergestellt werden.
-
Zitat
Wofür braucht ihr die Kurvenanpassung eigentlich ... nur für analoges Material?
nein,natürlich nicht.War ja nur ein Beispiel weil ichs grad in Arbeit habe und Vieles capturen muss.Was das Schneiden von MP4 angeht hat ja LigH schon beschrieben.
Im allerschlimmsten Falle codiere ichs in einen Intermediate und schnipple dann.Ev.ist das was
http://www.fame-ring.com/smart_cutter.html
Leider nicht kostenlos.Nachtrag:
Obiges Tool verglichen mit Machete und Videoredo TV Suite V.4...gewinnt Letzteres.
Editier-Genauigkeit....Frame- oder Gop genau.
Editiermodus Schnitt- oder Scenen-genau.
Gibts in Deutsch,Englisch und Francais.
Hat man die 2.oder 3.letzte Version [ 4.20.7.635/4.20.7.629] und will updaten auf die neue V.4.21.1.655 kann man wieder einen Batzen loswerden. -
Wenn DGIndexNV ein MP4 nicht verarbeiten kann, wird das Donald Graft sicherlich interessieren ...
Ups ... erwischt ... da müßt ich erstmal "spenden"
Videoredo TV Suite V.4
Die Beschreibung auf der Homepage sieht vielversprechend aus (die vom Smart-Cutter allerdings auch) ... mhmmm ... für "ab und zu mal hobbyschneiden" ist das recht viel Geld ...
Warum gewinnt VideoReDo? ... sind da noch extra features mit drin? Ich brauch nämlich nur den schnöden SchnittSodele ... mein template steht ... hier ist der Link: http://www.youtube.com/watch?v=7u3oGPAYHJM
Die Bewertung:
Original (720p, 3,35GB) 100%
UploadFile (1152p, 818MB) 95% (hauptsächlich geht etwas an Schärfe verlohren)
YT "Original" (453MB) 90% (minimales wabern bei hohem Detailgrad in großer Entfernung, minimale halos, Closeups noch nahezu perfekt)
YT "1080p" (179MB) 80% (weiteres 10% degrading wie bei "Original", leichte Kantenbildung bei closeups)
YT "720p" (92,8MB) 50% (starkes wabern, hoher detailverlust, halos minimal, Closeups im Verhältnis ok)
YT "360p" (21,8MB) 5% (On-The-Fly DivX capture mit 1000kbit vom VHS Rekorder der Oma ... würg
)*die %-Angaben sollen meine subjektives Qualitätsempfinden zum Original darstellen
Alles unter 1080p würde ich mir nur auf meinem alten Rückpro angucken ... 720 ist mir schon zu schlecht ... die 360p braucht niemand
.Ich bin erstaunt, wie gut der x264 so einen bandbreiten-limitierten recode bei den Closeups und bei Verhältnismäßig Aufwendigen Details (Wasser, Spritzer, Bäume/Planzen) noch hinkriegt.
Wenn die das wabern stabilisieren könnten, dann würde das beim gucken garnicht so in den Augen brennen :ani_lol:Das finale Script sieht jetzt so aus:
Code
Alles anzeigenLoadPlugin("c:\Program Files\AviSynth\plugins.manual\FFT3DGPU.dll") AVIsource("d:\Storage\Work\Dxtory\TESV 2013-03-13 22-33-44-888.avi") Levels(0, 1.2, 230, 0, 255) FFT3DGPU(sigma=1.5, bt=4, bw=32, bh=32, ow=16, oh=16) Lanczos4Resize(2048,1152) Sharpen(0.79)Kodiert mit (altem) x264 bei CRF 18 (wie Anfangs beschrieben).
Ich hätte nicht gedacht, das man trotz gezwungenem upscaling, YT-re-encode und limitierter Bitrate noch solche Ergebnisse auf YT erzielen kann ... und das, obwohl die Testszene recht brutal ist, was Komplexität angeht.
***Korrektur:
Hab gerade nochmal mit ausgeschlafenem Kopf die Videos verglichen ... Ich schmeiss mich weg ... durch das upscaling (Lanczos4Resize ist 1000x besser als der blöde resize von DirectShow/MPC) und das anschließende sharpen, sieht das UploadFile gefühlte 10% besser aus, als das original.
Dementsprechend ist beim YT "Original" sogut wie kein Unterschied zum eigentlichen Capture mehr vorhanden.
Die 1080p liegen dann bei 90% und die 720p bei 60% ... dem 360p würd ich dann vielleicht noch maximal 10% geben wollen.Supi ... jetzt noch 'nen Check machen, ob man überhaupt hochskalieren muss ... bin gerade dabei, zwei Varianten der Original-Auflösung (720p) hoch zu laden ... mal gucken, was YT daraus macht.
-
Smart-Cutter ist pfui ... VideoReDo konnte ich nocht nicht ausprobieren ... aber ich freunde mich gerade mit Avidemux an.
Die sind schon ganz schön weit gekommen ... die ersten Versionen hatte ich mal zwischen ... die waren auch pfui bah :zunge: ... aktuelle Version ist schnell und schneidet verlustfrei an I-Frames (synchron inkl. aac) direkt wieder nach .MP4.
Das geht damit ratzfatz (inkl. Strg+S :ja: ) ... und da ich P/B bei Lets-Plays eigentlich nicht cutten muss (glaub ich zumindest
) geb ich Sohnemann das teil in die Hand. -
So ... der stinknormale sharpen mit 0.79 produziert ebenfalls Artefakte ... daraus schließe ich, das es von "OK" bis zu dem häßlichen blurring einen maximal möglicher Detailsgrad bei gegebener Bitrate pro Auflösung gibt.
Neuer Ansatz ... bereits gegengecheckt ... stimmt ... grins ... das ist soo krank ...
bitte nicht hauen ...
Code
Alles anzeigenLoadPlugin("c:\Program Files\AviSynth\plugins.manual\FFT3DGPU.dll") AVIsource("d:\Storage\Work\Dxtory\TESV 2013-03-13 22-33-44-888.avi") # Correct brightness of YV12-Dxtory captures Levels(0, 1.2, 230, 0, 255) # Because the forced YouTube re-encode uses a lower bitrate than needed for a high detail capture (above 720p), # many details will be lost and converted to blurring artefacts in the final video. # To keep a reasonable amount of detail, we limit them to the maximum wich could be re-encoded (by YT) without # producing artefacts in scences with high complexity. (last.height > 720) ? Lanczos4Resize(1280,720) : last # Temporal stabilization (prevents bitrate comsumption from flickering structures) FFT3DGPU(sigma=1.5, bt=4, bw=32, bh=32, ow=16, oh=16) # Upscaling (forces YT to re-encode with higher bitrates) # Beside storing an (nearly) Original version on YT, this forces their re-encode to downscale our upload. # It ends up in videos wich are well-balanced in detail-level and smoothing. Lanczos4Resize(2048,1152) # Over-Sharpen: maintaining details/DOF Sharpen(1.0)dafür komm ich in die Hölle
Aber egal ... das sieht bombastisch aus!!!
Noch ein Nachtrag:
Hab das gerade nochmal gegen einen 1080p upload gechecked ... das bringt ein wenig mehr feine Details (nur bei wenig motion) hervor, führt aber in den unteren Auflösungen zu wesentlich mehr Artefakten. Das nervigste daran finde ich, ist das hin und herschalten des Codecs bei movement und stehenden szenen.
Das Script taugt übrigens auch hervorragend für "normale" Filme (nicht vergessen die Level-Korrektur rauszunehmen ).
Getestet hab ich das mit einem SD-Video (Lost in Space) und einem HD-Video (Hellboy 2).
Bei den Filmen kann ich das Ergebnis mit dem "Overscale-Upload" bestätigen. Dort entstehen ebenfalls mehr Artefakte, wenn nur die native Auflösung hochgepumpt wird. -
Die verschiedenen Encodes von youtube sind halt in verschiedenen Qualitäten encodiert. Darum bekommst du bei 720p auch grundsätzlich immer weniger Qualität als bei Original.
Original ist halt deren beste Encode.
Aber auch Youtube benutzt keine fixe Bitrate. Youtube benutzt ebenfalls ein quantizerbasiertes Encoding.
Aber du scheinst hier ja bissl experimentiert zu haben. Bin da sehr skeptisch, hatte mal mit TemporalSoften probiert. Das hat zwar die Blocksichtbarkeit geringer gemacht, allerdings auch mehr geschmiert und weniger Detail aufgrund von Tempsoften.
Aber ich guck den Thread gleich mal ohne überfliegen durch. Bin gespannt ob da echt was bringt. Auf hellen Szenen hab ich mit original eig. kaum bis keine Probleme, aber mich stört der massive Qualitätsabfall auf Dunkelheit. Der ist echt extrem bei denen.
Allerdings werd ich kein Levels anwenden. Bei mir ist die Helligkeit exakt die selbige wie aufm PC. -
Bei Auflösungen ab 720p macht der Tempsoften mit "moderaten" Einstellungen (wie in dem Script da oben) kaum was "kaputt" ... aber "kleine flackernde Pixel" werden ein wenig stabilisiert.
Gegen den Detailverlust beim downsizing hilft der Lancos und der Sharpen sehr gut ... da in solch rein digitalem Material kein "Rauschen" enthalten ist, wirds dadurch auch nicht unnatürlich.
Aber was ich viel besser finde, als die Auflösung "original", ist die Tatsache, das die niedrigeren Auflösungen von so einem hochskalierten Upload immens profitieren ... die 1080er sehen klasse aus und die 720er kann man sich auch noch halbwegs angucken.
So ein Video in "original-Auflösung" zu gucken ist eher was für Großstadtleitungen
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!