Beiträge von LessThanJake

Zitat von LigH

- Dann wird jedes Frame ein I-Frame. Oder?! :redface:

"Intervall" ist ja eine (sich evtl. regelmäßig wiederholende) Länge. Für Zonen ist aber der Beginn wichtig - die Länge ergibt sich aus dem Beginn der nächsten Zone (oder der Länge des Video-Restes).
__

Also ich würde an den vorher bekannten Stellen Zonen definieren, die explizit mit I-Frame beginnen sollen.

OK.
-------
Ich meinte natürlich Frameintervall bestehend aus 1 Frame = 1 Zone, positioniert an der Stelle an der später geschnitten werden soll.

greets
LTJ

Zitat von LigH

Über "Zonen" kann man garantieren, dass das an den passenden Stellen klappen wird (I-Frames erzwingen).

Wenn man das Zonenintervall auf genau einen Frame setzt, wird dieses auf jeden Fall ein I-Frame an dem ich schneiden kann?
---------------
Generell zu Zonen:
Benutzt wird bspw. eine Zoneneinstellung für einen Abspann mit weißer Schrift auf schwarzem Hintergrund. Würde sich dieser Zonenschnitt durch eine sichtbare Schwarzwertänderung auswirken bzw. kann man den Übergang sehen?

greets
LTJ

Zitat von stolzi

In meinem Fall? Wie gesagt geht es mir um Videos, die ich auf eine DVD brenne. Daher ist mir egal ob nun das File 1000mb, oder 1300mb ist. Mir ist wichtiger, dass ich die zu erwartende Qualität eher voraussagen kann.

Mit dieser Aussage hast du dich eigentlich schon für den CQ-Modus entschieden.

Zitat

Ist dann nicht besser ich nehme 2-Pass-average Bitrate mit immer etwa dem selben Wert? Oder hälst du es für besser ich mache zB alle mpeg2 Videos mit 2-Pass-file size etwa halb so gross zB?

Steht eigentlich auch schon oben. Die durchschnittliche Bitrate die dir ein Bitratenrechner ausgibt, ist eben nur Durchschnitt und sagt rein garnichts über die tatsächliche Verteilung über den Film aus. Das ist wirklich abhängig von der Quelle.

Vielleicht ist dies hier noch ein hilfreicher Beitrag für dich:
http://board.gulli.com/thread/667144-…itt-codieren/#7

greets
LTJ

Zitat von Selur

Wird teilweise dazu benutzt dem Decoder zu sagen welche Version eines Encoders verwendet wird um eventuelle Bugs zu beheben.

Wenn die unverfälscht blieben, kann man also anhand diesen Eintrags Encoder und Version zuordnen. Gibt es eine Tabelle, die verschiedene Einträge zuordnet?

greets
LTJ

AVIMux_GUI spuckt über Rechtsklick auf Video -> "Information about file" auch Infos aus.
Bsp.: Elephants Dream HD-Version:

Version: 1.17.7, Aug  8 2006
-----------------------------------------------
AVI-Type: OpenDML + Legacy-Index
Writing-App                   : AVI-Mux GUI 1.17.5, Apr  5 2006  18:41:17
Title                         : n/a
resolution                    : 1920x1080
FourCC                        : MP42
biCompression value           : MP42
framerate               (strh): 24. fps
framerate               (avih): 23.9998 fps
number of frames              :     15691 (0:10:53.791)
thereof keyframes             :       326
thereof deltaframes           :     15365
thereof dropped frames        :         0
strh[0].dwLength              :     15691


MainAVIHeader.dwTotalFrames   :        39
real value                    :        39
suggested buffer size         :         0


Flags set:                    : 0x00000110
                                AVIF_HASINDEX
                                AVIF_ISINTERLEAVED
size of video stream          :      817,358,648 bytes
video data rate               : 1220 kByte/s
number of audio streams: 1
 
audio stream: 1 (Stream 1)
  bitrate                  :          448,000 Bit/s
  size of stream (strh)    :       36,614,144 units à 1 bytes
  size of stream (index)   :       36,614,144 bytes
  number of chunks         :           10,216
  format-tag               :           0x2000
  sampling rate            :           48,000
  channels                 :                5
  suggested buffer size    :            7,168
 
number of subtitles: 0
 
Open-DML index: 
  Stream: 0
      entries in super index: 3 
                     value stored in dwDuration    real value          
                     ------------------------------------------------
      entry   1:                   39                       39       OK
      entry   2:               14,961                   14,961       OK
      entry   3:                  691                      691       OK
  Stream: 1
      entries in super index: 3 
                     value stored in dwDuration    real value          
                     ------------------------------------------------
      entry   1:              103,936                  103,936       OK
      entry   2:           34,908,160               34,908,160       OK
      entry   3:            1,602,048                1,602,048       OK
 
total number of chunks: 25907
Sizes of Chunks
   up to        100 bytes:          0
   up to        250 bytes:          0
   up to        500 bytes:          0
   up to       1000 bytes:          0
   up to       2500 bytes:        480
   up to       5000 bytes:      10443
   up to      10000 bytes:        354
   up to      25000 bytes:       2843
   up to      50000 bytes:       5288
   up to     100000 bytes:       4773
   up to     200000 bytes:       1580
   up to     500000 bytes:        145
   up to    1000000 bytes:          1
    over    1000000 bytes:          0

greets
LTJ

Kann man im Nachhinein eigentlich immer mit Sicherheit feststellen ob mit DivX oder Xvid encodet und dazu noch welche jeweilige Codec-Version benutzt wurde? Mir ist natürlich völlig klar, das es Analyse-Tools wie Mediainfo, gspot und wie sie alle heißen, gibt, jedoch lesen die offenbar nur den FourCC aus und lassen sich leicht täuschen, wenn man mit z.B. MPEG4-Modifier nachträglich Änderungen vornimmt.
Gibt es also Stream-Informationen, die eine Videodatei völlig eindeutig identifizierbar machen?
Was hat es eigentlich genau mit dem Usereintrag auf sich, den man ebenfalls mit MPEG4Modifier ändern kann?

greets
LTJ

Zitat von nexustheoriginal

Um wieviel Prozent ungefähr?

Hab mal 2 Files in Spielfilmlänge durchlaufen lassen.
AC3 -> 5.1-WAV (Besweet)
5.1-WAV -> 5.1-AAC (letztes NeroAACEnc CLI vom 26.05.2006)

|					|					|
		|   AC3		Q=0.35		Q=0.3	|  AC3		Q=0.35		Q=0.3	|
----------------|---------------------------------------|---------------------------------------|
kbps		|   448 	 322		 237	|  384		  322		 237	|
%		|   100%	63,77%		46,83%	|  100%		 84,16%		61,86%	|
Größe (MB)	|  450,88	287,56		211,16	| 287,66	 242,12		177,96	|
		| 					|					|
		|	   Laufzeit: 02:20:42		|	   Laufzeit: 01:44:44		|
		|					|					|
----------------|---------------------------------------|---------------------------------------|
		| 					|					|

Den riesen Test hier kennste ja bestimmt schon. Da wurde aber noch ne andere Version benutzt. Wieviel die sich unterscheiden kann ich nicht sagen.
Müsste mal jemand das gleiche File nochmal durchtesten.

Kleine Frage am Rande:
Was nehmt ihr eigentlich für AC3 -> 5.1-WAV? Immer noch besweet (mit Normalisierung wenn "Downmix overflow" aufftritt)? Wie geht foobar mit Stellen um, die übersteuert werden?

greets
LTJ

Zitat von nexustheoriginal

Hm, mich würde mal interessieren, was ihr für HE AAC benutzt? Nero? WinAmp?

Ich nehme oft Nero 7 CLI mit q im Bereich von 0.3 - 0.35 (ist dann schon SBR LC oder?) für 5.1, wenn ich original AC3-Spuren umrechnen will. Das File wird etwas kleiner und den Qualitätsunterschied höre ich bei Blindtests nicht heraus.

greets
LTJ

Zitat von Selur

... mit konstantem Quantizer um die Auswirkungen auf die Größe zu sehen ...

Das habe ich jetzt mit der DVD-Version von ED gemacht in jeweils MOD 4/8/16
Balken gecroppt und zurück auf DVD-Auflösung resized, also reines Bild als Quelle.

----------------------------------
--crf 20 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\Schwarze Balken Test - Ergebnisse\mod4.mkv" "C:\Schwarze Balken Test - Ergebnisse\mod4.avs"
----------------------------------

MOD 16 -> 720x576 -> 131.379.200 Byte
MOD 8 -> 712x568 -> 130.330.624 Byte
MOD 4 -> 716x572 -> 131.310.593 Byte

Die Unterschiede sind überhaupt nicht nenneswert.

greets
LTJ

Zitat von Mosu

...(bin mir gerade nicht sicher, ob das auch für "Quelle ist Matroska" gilt)...

gilt da auch, gerade eben nochmal probiert

Zitat

Hmm, wurde die Datei vorher mit mkvmerge erstellt?

x264.exe kann den Video-Stream eigenständig in MKV ausgeben. Dies war auch die Quelle für mkvextract um den RAW-Stream zu erstellen und zugleich mein Denkfehler.
Als MeGUI-Benutzer bin ich bisher davon ausgegeangen, dass x264.exe grundsätzlich immer erst einen RAW-Stream erstellt und am Ende mkvmerge dazu benutzt um die Video-MKV zu erstellen, wenn für das Outputformat MKV gewählt ist.

Ich hab das von x264 geschriebene MKV also fälschlicherweise schon als "produced by mkvmerge" angesehen, wodurch meine Testergebnisse dann mit deiner, von mir zitierten, Aussage kollidiert ist.

Nun, die Welt ist wieder rund und alles ist gut, vielen Dank.
greets
LTJ

Zitat von Mosu

mkvmerge entfernt die AR-Informationen beim muxen. mkvextract fügt keine hinzu.

Hallo,
getrieben von der Frage ob --sar das AR-Flag wirklich im Bit-Stream verankert oder vielleicht doch nur direkt bei Streamausgabe als DAR in den Container schreibt, verwirrt mich dabei obige Aussage.

Ein mit mkvextrakt erstellter Elementary-Stream hat bei mir immer noch das korrekte AR-Flag gespeichert, wie
a) erneutes muxxen mittels mkvmerge zeigt

Zitat

mkvmerge v2.0.0 ('After The Rain Has Fallen') built on Jan 13 2007 19:58:31
'D:\AR-Flag-Test\1_Track1.h264': Using the AVC/h.264 ES demultiplexer.
Track 0 of 'D:\AR-Flag-Test\1_Track1.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1489/576.

b) die Mplayer-Ausgabe ebenfalls korrekt erkennt (gleicher RAW-Stream)

Zitat

Starting playback...
VDec: vo config request - 1024 x 576 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.59:1 - prescaling to correct movie aspect.

SwScaler: BICUBIC scaler, from Planar YV12 to BGR 24-bit using MMX2
VO: [directx] 1024x576 => 1490x576 Planar YV12

(Das Seitenverhältnis ist richtig, habe willkürlich --sar 16:11 auf eine 1024er Quelle angewandt).

Um das selber nochmals zu überprüfen drängt sich auch die Frage auf wie ich aus einem RAW-Stream nun das Flag auch wieder auslesen kann.

mkv-Info kanns nicht und h264_parse aus den mpeg4iptools aus dem Beitrag vorher listet es nicht.
Wer gibt nen Tipp?

(Sorry falls zu sehr offtopic.)
greets
LTJ

Prima, vielen Dank.

Zitat von Bumsfalara

Ganz recht, ja. Ich hatte an allen Rändern 4 Pixel weggecroppt und anschließend auf 720x400 resized.

Plötzlich hatte ich wie im Ausgangsmaterial wieder diese ganz kleine schwarze Pixelreihe Rechts und Unten, allerhöchstens nen halben Pixel groß. Keine Ahnung was das ist.

Edit: Auch bei dem Test oben, das gecroppte .avi script: Wenn ich das nochmal bei Meguiavsscriptcreator reinlade und Autocrop mache, sind die Schwarzen Ränder vorhanden. Die sieht man auch, sind extrem klein aber vorhanden.

Hab mir jetzt auch mal das ED_1024.AVI zur Brust genommen.
l,r,o,u jeweils 4 Pixel gecroppt und einmal auf 720x400 und einmal wieder zurück auf 1024 x 576 resized.
Ich kann da nix erkennen, was nach nem schwarzen Balken aussieht.
Wenn du im Script fps=25 eingestellt hast, slide im MeGUI Previewfenster mal auf Frame 1300, da sind die Ränder bei mir schneeweiß, wie es soll.

-----------------

Ich werde in den nächsten Tagen auch mal einen Test machen.
Folgendes schwebt mir da vor:
Ich möchte MOD 4/8 und 16 jeweils mit 2 Pixel breiten schwarzen Balken nur oben und unten, sowie das gleiche ohne Balken per --crf miteinander vergleichen.
Es liegen am Ende also 6 Ergebnisse vor.

Dabei stellt sich die Frage, wie man denn das Quellmaterial sinnvoll vorbereiten kann/sollte. Bei den ersten drei Encodings müsste man die Quelle jedesmal neu anpassen um die Balken zu berücksichtigen, wobei man bei den drei Testdurchläufen ohne Balken einfach auf die entsprechen MOD-Auflösung croppen kann.
Wie weit wäre das also am Ende vergleichbar?

greets
LTJ

OK, das leuchtet zum Teil ein.
Dann Frage ich trotzdem mal etwas tiefergehend.
DGDecode_mpeg2source() wird immer als erste Wahl für D2V-Projektdateien und MPEG-Streams allgemein genannt. Dies scheint mir ein eigenständiger Decoder zu sein der nicht per DirectShow auf die im System vorhanden Decoder zugreift. Ist das richtig?
AVISource() und DirectShowsource() hingegen bedienen sich dem DS-System und somit den nach den Merits hierarchisierten Decoderfiltern.
a) Gibt es Gründe AVISource() bei einer AVIQuelle DirectShowSource() vorzuziehen? (Was ist der genaue Unterschied?)
b) Wenn ich weiß das mein System zum Abspielen z.B. eines H264-Videos als Decoderfilter ffdshow (libavcodec) oder CoreAVC benutzt oder ich das über Graphedit so festgelegt habe, kann ich davon ausgehen das die Einzelbilder die dieser Decoder am Ende ausgibt auch per DirectShowsource() an einen Encoder weitergeleitet werden.
Sind speziell diese Decoder jetzt auch suboptimal, was Frames verschlucken postprocessing etc. angeht? (Kann ich mir ja fast nicht vorstellen.)

Letzte Frage:
Was wäre denn die optimale Lösung einen hochwertigen Bilderzeuger zu bekommen um diese dann sauber enkodieren zu können?

Danke,
greets
LTJ

Zitat von LigH

Ansonsten hilft im Notfall meist noch AviSynth mit DirectShowSource, oder TMPGEnc 2.5 (kann auch AVIs exportieren).

Warum eigentlich im Notfall?
Bei mir ist AVISource(), Directshowsource() und DGDecode_mpeg2source() je nach Quelle immer das erste was ich probiere, da ich viel lieber mit AVISynth arbeite.
Gibt es irgendwelche Gründe dafür lieber Tools zu benutzen, die eigene, auf die verschiedenen Formate zugeschnittene Decoder benutzen?
Am Ende wird doch sowieso immer jedes einzelne Bild an den Encoder weitergereicht.

greets
LTJ

Zitat von Bumsfalara

...um auch sicher zu gehen dass keinerlei schwarzen Ränder vorhanden sind.
Allerdings ist genau das der Fall und zwar an der exakt selben Stelle wie bei dem Ausgangsmaterial. Der Fehler liegt nicht in scripten sondern in irgendeinem Filter.
Strange.

Wie darf ich das verstehen?
Du hast trotzdem schwarze Ränder im Bild, obwohl du sie zuvor weggecroppt hast? :hm:

greets
LTJ

Zitat von LigH

Musst du eigentlich unbedingt 6-Kanal-AAC downmixen und neu encodieren? Die Player tun das beim Abspielen sicher auch freiwillig. Der MPC tut es auf jeden Fall, wenn man es so einstellt. :ja:

Nö, ich selber würde das niemals machen, wozu auch die Qualität noch weiter runterschrauben? Normalerweise lass ich sogar die Quell-AC3 so wie sie ist.
Ich kann per MPC + ffdshow auch eigentlich so ziemlich alles abspielen was ich brauche und AAC-5.1 to AC3-5.1 onthefly für den Receiver klappt damit auch bestens.
ich war einfach nur neugierig.

greets
LTJ

Zitat von LigH

Du gibst hier Beispiele an, wie du ein 6-Kanal-AC3 (Dolby Digital) mit BeSweet konvertierst, und hängst als Testdatei ein Stückchen AC3 (Dolby Digital) an deinen Beitrag.

Was hat jetzt die Bedienung von BeSweet für AC3-Konvertierung mit dem Decodieren von AAC (MPEG4-Audio) zu tun? -- BeSweet hat übrigens keinen AAC-Decoder.

Argh, ich hab letzte Nacht wohl vor Müdigkeit den Threadtitel verhunzt.
Ziel war es eine 6ch-AAC in eine 2ch-WAV zu überführen.
Hatte aber keine 6ch-AAC da, also hab ich mir eben über das AC3-File eine neue Testquelle gebaut. (Hätte die direkt anhängen sollen, sorry)

Zitat

Um 6-Kanal-AAC nach 2-Kanal-WAV zu decodieren, empfehle ich bisher noch:

Code

[noparse]faad -d [-o output.wav] input.aac [/noparse]

(Parameter "-d" für "Downmix"), oder den VLC, oder WinAmp mit DiskWriter.

Das beantwortet meine Frage.
thx
LTJ

Edit//
Hä? Oder hast du den Titel jetzt geändert?
Ich blick gerade nicht durch.

Zitat

Nur verwechselst du anscheinend ab und zu AAC (MPEG4-Audio) und AC3 (Dolby-Digital-Audio).

Wo? Natürlich kenne ich den Unterschied, ich versuche nur herauszufinden welche Möglichkeiten es gibt das eine Format in das andere zu überführen.

Dabei weiß ich jetzt aber immer noch nicht wie ich von 6ch-AAC zu 2ch-WAV komme ohne den Umweg über AC3 zu gehen, oder gehts nicht anders?

thx
LTJ

Hab ein wenig hin und her probiert um zu sehen was alles geht und was nicht.
Zu Testzwecken wurde Folgendes gemacht:

• AC3 -> 6ch-WAV (Besweet -> klappt)
  
  
  Code

  BeSweet.exe -core( -input "1.ac3" -output "1.wav"  -6chwav )

• 6ch-WAV -> 6ch-AAC@mp4 (Nero 7 CLI Enc. -> klappt)
  
  
  Code

  neroaacenc.exe -q 0.35 -if "1.wav" -of "1.mp4"

• 6ch-AAC@mp4 -> 6ch-WAV (Nero 7 CLI Dec. -> klappt)
  
  
  Code

  neroaacdec.exe -if "1.mp4" -of "1.wav"

• AC3 -> 2ch-WAV (Besweet -> DPL2 kommt raus (warum?))
  
  
  Code

  BeSweet.exe -core( -input "1.ac3" -output "1.wav"  -2ch )

• AC3 -> 2ch-WAV (Besweet -> kommt ebenfalls DPL2 raus (warum?))
  
  
  Code

  BeSweet.exe -core( -input "1.ac3" -output "1.wav"  -2ch ) -azid( -s stereo -L -3db )

• 6ch-WAV -> 2ch-WAV (Besweet -> Ergebnis ist ein File von der Größe der 6ch-WAV mit einer 3-fachen Laufzeit und akustischem Käse)
  
  
  Code

  BeSweet.exe -core( -input "1.wav" -output "2.wav"  -2ch ) -azid( -s stereo -L -3db )

Die Frage ist, wie bekomme ich nun ein 2ch-WAV aus einer 6ch-AAC oder aus einem 6ch-WAV? Ich hab auch schon Mono-Streams ausgeben lassen, daraus ein *.mix-File mit korrigiertem channel-mapping erstellt und dann vesucht dieses zu einem 2ch-WAV zu konvertieren, das Ergebnis ist exakt dasselbe wie im letzen Beispiel, also Mist.
Ich hab das Test-AC3-File mal angehängt.

Wer hat einen kleinen Tipp?
Danke
LTJ