HD Aufnahmen sind zu schlecht - andere Kodierung einsetzen

[Ralgert]

So wie ich es in Erinnerung habe, wird der AC3-Strom direkt aufgezeichnet, da er auch extra gesendet wird.

[Leseesel]

So wie ich es in Erinnerung habe, wird der AC3-Strom direkt aufgezeichnet, da er auch extra gesendet wird.

Also mein Sat-Receiver spielt das zusammen ab, nicht erst das Bild und zum Schluss den Ton und er zeichnet es auch in der selben Datei mit auf. Ich wüsste nicht, was an AC3 einzelner wäre, als an den verschiedenen MPEG-1-Audiostreams, aber vielleicht belehrt mich ja jemand eines Besseren.

[Leseesel]

Was stimmt, ist das Problem mit den dunkelnen Stellen. Das ist ein x264 Problem und ist Absicht ... ein Feature sozusagen. Wird dir jeder x264 Entwickler erzählen ... und er wird dir erzählen, dass dein TV falsch kalibriert ist. (was nicht weiterhilft, aber sie erzählen das, weil man dem x264 Codec dieses Verhalten schlecht abgewöhnen kann)

Dann ist eben das zugrunde liegende psychovisuelle Modell falsch. es betrifft außerdem nicht ausschließlich dunkle Bereiche, sondern zusätzlich Flächen mit schwachen Kontrasten, bzw. langsamen Übergängen. Ich finde, das sieht einfach schrecklich aus. Diese wabernden Rechtecke bei DivX finde ich allerdings auch nicht besser.

[Artemis1121]

Aufs Testen würde ich mich freuen!

Ich bin mir aber nicht so sicher, das diese Fehler bei dunklen Flächen durch OTR verursacht werden, da ich zumindest meine diese Fehler auch schon direkt bei den HDTV Ausstrahlungen beobachtet zu haben...
Beim Testen wäre ich also dafür den Originalstream zumindest zusätzlich anzubieten!

[Leseesel]

Leider habe ich keinen H.264-Vergleich, da OTR meine einzige Quelle hierfür ist. Bei SDTV (Insbesondere bei The Next Generation von Tele5) ist es aber regelmäßig zu beobachten, dass diese Unschärfen und Blockartefakte bei HQ stark aufteten, während das DVB-Original zwar dank analoger Videoquelle schon schlecht ist, aber immer noch deutlich detailreicher, ohne Teppenartefakte und ohne diese Blockartefakte auf Flächen und in dunklen Bereichen.

[OTR.TH]

Hallo,

Testen ist immer gut, ich komm ja kaum dazu ;)
Werde am Montag mal Aufnahmen programmieren, Vorschläge bis dahin dann hier.
Ideal wäre wohl, als Vergleich immer die aktuelle Kodierung dabeizuhaben, kann ich dann ja unter anderem Namen (HQ?) hochladen. Originalstream wäre etwas groß? auch wenn ich diese unnötigen Bytes rausmache...
Was kommt denn so geeignetes ab Montag nachmittag zum Testen?

[Raus]

Was kommt denn so geeignetes ab Montag nachmittag zum Testen?

20:15 ARD Fussball: DFB Pokal

Bewegung (hoffentlich :D) pur!

[Artemis1121]

Originalstream wäre etwas groß? auch wenn ich diese unnötigen Bytes rausmache...

Wenn die Sendung vorher ausgewählt wird, würd ich sie mir auch einfach selbst aufnehmen :)

[Ralgert]

20:15 ARD Fussball: DFB Pokal

Bewegung (hoffentlich :D) pur!
Ja, dieser Test wuerde mich auch interessieren. Wenn du ihn gesehen hast, teil mir kurz das Ergebniss mit. Dann kann ich am Dienstag noch einen vernuenftigen Wettschein abgeben.

[Leseesel]

An Wochentagen am Abend: Star Trek auf Tele5: Die Wände, Türen etc. in den Raumschiffen und die Uniformen in dunklen Szenen sind eigentlich in jeder Aufnahme mehrmals voller Klötze.

[Harry999]

als doch recht grosser laie wuerde ich mich freuen, wenn die testfiles dann auch zugaenglich angeboten wuerden.
da ich auch HD nutze, wo verfuegbar... wuerde ich mir das ergebnis gerne im unterschied ansehen und natuerlich feedback geben wollen ob meine hardware (diverse abspielmoeglichkeiten) dazu in der lage ist.

es duerfte aber sinnvoll sein, nicht eine (eher mehrere) sendungen komplett zu vergleichen, sondern direkt geschnittene fertige .otrkeys (sofern rechtlich moeglich) mit den problemszenen zu vergleichen?
zumindest sollte man die sendung(en) festlegen und die problemszenen als hh:mm:ss bennenen um zu vergleichen?

[Artemis1121]

@Leseesel
Es geht hier um die HD-Aufnahmen, insofern sind nur die Sender ARD HD, ZDF HD, Arte HD, Anixe HD, Servus TV HD möglich.

Und Tele 5 sendet selbst ja leider schon so mies, das man die Klötzchen bei der normalen Ausstrahlung schon unangenehm auffallen.

[Leseesel]

In wieweit unterscheiden sich denn die Codiereinstellung und Klötzchenbildung bei HD und HQ? Werden grundsätzlich komplett andere H.264-Codierfeatures verwendet? Die Artefakte im Screenshot sahen eigentlich so ziemlich genauso wie bei SD aus, daher wäre ich der Meinung gewesen: Wenn bessere Einstellungen/Codec-Features möglich sind, sollte beides geändert werden.

[Artemis1121]

Danke für den Vortest, hast du zufällig in irgendwelchen Logs, noch die Kodierzeiten stehn? vielleicht so prozentual am besten umgerechnet auf die OTR-Settings-Kodierdauer?

[Leseesel]

OTR Settings CQ 23 (2935,2 MB) vs. CRF 21 - medium mit -tune film ohne bpyramid/weightp (2858,4 MB)
Das sollte die Kodierung sein, die sich Pete3 wünscht. Sind ungefähr gleich groß. Wie ändert sich die Qualität?

http://screenshotcomparison.com/comparison/106234/

Danke für den Test. Auch wenn das ein sehr verrauschter Film ist und Flächen mit langsamen Farbübergängen (nicht zuletzt wegen des starken Rauschens) weitgehend fehlen: Mit Maus drüber sehe ich deutlich mehr Detail, deutlich mehr vom originalen Rauschen und kleinere Klötze. Wenn das die von Pete3 vorgeschlagene Kodierung ist, dann finde ich das schon einigermaßen überzeugend.

[monarc99]

Danke für den Vortest, hast du zufällig in irgendwelchen Logs, noch die Kodierzeiten stehn? vielleicht so prozentual am besten umgerechnet auf die OTR-Settings-Kodierdauer?Nein, Logs habe ich keine. Aber die medium Settings dürften langsamer sein. Und je niedriger der crf Wert (also besser,höhere Bitrate, größere Datei), desto langsamer wird der Encoder.
Die von dir eingebrachten Settings wären wie du vorgeschlagen hast für HQ Material + dieses parallel gleich mitaufzuwerten imo auch eine gute Sache - hast du sie mal mit einem höheren CRF probiert, wie sie da noch skalieren?Bei höheren CRF sieht man dann schon, wie die Qualität schwindet. Weiter würde ich nicht gehen. Die Kodierung soll die Dateien ja nur kleiner machen, ohne sichtbar an Qualität gegenüber der jetzigen Kodierung zu verlieren.
Man könnte vielleicht über z.b. einen anderen chroma-qp-offset noch ca. 5% an Dateigröße einsparen ohne das es einen merklichen Qualitäts-Einfluß hätte. Gibt bestimmt auch noch andere Ansatzstellen.Einige Optimierungen sind darin jedoch nicht enthalten, da manches wohl aus Codierzeit- wie Kompatibilätsgründen anscheinend nicht übernommen werden kann - obgleich man hier ev. auch mal genau gucken müßte, v.a. für welche B-Frame Settings das genau gilt. Ich denke alle Vorschläge sind willkommen. Ich habe einige Optimierungen ausgelassen, weil die puren medium settings auf meinen Rechner schon langsamer sind. Du könntest dir also auch überlegen, wie du die Settings tunen würdest, falls es OTR zu langsam ist. Aber was geht und was nicht, kann nur OTR selbst ausprobieren.

[OTR.TH]

Hallo,

ich hab als Testfile mal Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE aufgezeichnet (ZDF).
Wurde ja auch als reguläres HD aufgezeichnet, da hat man dann den direkten Vergleich, ohne dass ich doppelt kodieren lassen muß.
geänderte Einstellungen erstmal:
me=hex
aq=1
mbtree
deblock -1,-1
partitions +parti8x8+parti4x4+partp8x8+partb8x8
psy-rd 1,0.15
subme 7

CRF-Test dann nachher mal, glaub das hatten wir auch schonmal getestet, damals gab es da irgendwelche Probleme (weiß bloß nicht mehr welche...)

[Raus]

... oder muß man dafür die komplette 3GB HD-TV Aufnahme die im Interface erscheint runterladen?

Der Versuch diese Datei zu decodieren erhielt ich den Hinweis, dass sie fehlerhaft sei und konnte sie somit nicht decodieren. :(

[Harry999]

kannst du das direkt verlinken? ich habs nicht gefunden, werde es allerdings definitiv zum test direkt von otr laden.

PS
habs dann doch als HD gefunden (mirror). keine gutschrift ausser einem dekodierpunkt noetig ;)

weiteres dann nach DL und ansehen.
die anzeige von 1,5gb und 3 gb scheint nicht korrekt.
der unterschie in der groesse ist vernachlaessigbar lt DLM
3,1 zu 3,2 GB (grob gerundet)

[Artemis1121]

Ich grüße die mitseedenden ;)

Inspector_Barnaby_12.02.05_22-50_zdf_95_TVOON_DE.mpg.HD.avi.otrkey 3,06 GB (3.295.786.706 Bytes)

General
Complete name : D:Video_decodeInspector_Barnaby_12.02.05_22-50_zdf_95_TVOON_DE.mpg.HD.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 3.07 GiB
Duration : 1h 50mn
Overall bit rate : 3 965 Kbps
Writing application : Lavf52.108.0

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 50mn
Bit rate : 3 757 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 50.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.082
Stream size : 2.91 GiB (95%)
Writing library : x264 core 114
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=5 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=23 / ip_ratio=1.41 / pb_ratio=1.25 / aq=0

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 50mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 152 MiB (5%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (1.20 video frame)



Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HD.avi.otrkey 3,01 GB (3.237.542.160 Bytes)

General
Complete name : D:Video_decodeInspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HD.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 3.02 GiB
Duration : 1h 40mn
Overall bit rate : 4 282 Kbps
Writing application : Lavf52.84.0

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 40mn
Bit rate : 4 072 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 50.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.088
Stream size : 2.87 GiB (95%)
Writing library : x264 core 107
Encoding settings : cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=23 / ip_ratio=1.41 / pb_ratio=1.25 / aq=0

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 40mn
Bit rate mode : Variable
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 140 MiB (5%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (1.20 video frame)



Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HQ.avi.otrkey 2,73 GB (2.940.541.056 Bytes)

General
Complete name : D:Video_decodeInspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HQ.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 2.74 GiB
Duration : 1h 40mn
Overall bit rate : 3 889 Kbps
Writing application : Lavf52.84.0

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 40mn
Bit rate : 3 679 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 50.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.080
Stream size : 2.59 GiB (95%)
Writing library : x264 core 107
Encoding settings : cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=2 / qpmax=31 / qpstep=3 / ip_ratio=1.41 / aq=1:1.00

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 40mn
Bit rate mode : Variable
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 140 MiB (5%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (1.20 video frame)



Hier nochmal die h264 Settings zusammengefasst:

zdf.HD: x264 core 114; cabac=1 / ref=3 / deblock=1:0:0 /// analyse=0x1:0x111 / me=umh / subme=5 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 // threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=23 / ip_ratio=1.41 / pb_ratio=1.25 / aq=0
tst.HD: x264 core 107; cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=23 / ip_ratio=1.41 / pb_ratio=1.25 / aq=0
tst.HQ: x264 core 107; cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=2 / weightb=0 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=2 / qpmax=31 / qpstep=3 / ip_ratio=1.41 / aq=1:1.00
zur Lauffähigkeit:
Ich habe das ganze mal auf einem einfachen Samsung FullHD LCD-TV direkt via USB getestet und auf meinem xtreamer. Alle funktionieren problemlos.

Eine schöne Teststelle ist z.b bei 00:07:15 in der testdatei(12:16 bei zdf). Die Streifen des Anzugs sind bei den neuen Kodierungen deutlich besser zu erkennen. Auch ist die Raumdecke in der alten Kodierung sehr verschwommen.

Insgesamt finde ich die beiden neuen deutlich besser als die alte Kodierung.. test.HQ wirkt imho bei Flächen(Raumdecke, Monitorgehäuse, Anzüge) besser als test.HD.
Ich sehe gerade nur noch Artefakte und mach erst mal ne Pause ^^

[Pete3]

Schön zu hören das ein Unterschied zu sehen ist,
kann die Files leider nicht runterladen weil ist einfach zu groß bei meinem DSL2000.

Anscheinend wird jedoch immer noch einiges Potential bei dem HQ TestFile verschenkt, denn die eigentlich schon wichtige Analyse wurde wohl noch nicht verbessert, ebensowenig B-Frames, qpmin/max/step/ip/bp-ratio usw. Das meiste davon kostet kaum Zeit, die Summe all dieser Änderungen würde sich jedoch tendentiell auch entsprechend noch positiv auf Qualität/Dateigröße auswirken.

[monarc99]

Also am besten gefällt mir die crf Variante. Auch wenn alle sehr ähnlich sind, ist es doch eine Verbesserung.
Einige Settings sind noch nicht optimal, wie pete3 schon erwähnt hat.

Ein Test mit neuerer ffmpeg Version würde mir gefallen ;)
(in älteren ffmpeg Versionen kann man nicht alle x264 Einstellungen ändern, geht erst mit relativ neuen Versionen)


mit freundlichen Grüssen
monarc

[Pete3]

Hallo,
die Analyse ist wichtig, da sie die Qualität des Encodes entschieden mitbeeinflußt. Gemeint ist damit der hier im Screenie (am Beispiel der vfw Gui) markierte Bereich: http://img4.fotos-hochladen.net/uploads/analysenrsd35xc1p.jpg

Ich weiß nicht was für ein Programm, Encoder usw. du nutzt, die Partitions Analyse läßt sich aber unabhängig von welchen Programm auch immer einstellen .
Sonst notfals über die Kommandozeile:
Bin nicht ganz sicher, aber glaube müßte dann (partitions=all) --partitions all heißen


Und ja Adapt_Bframes 2 verlangsamt, b_pyramid bei aktivierten MBTree tendentiell jedoch nicht so stark wie ohne.

[monarc99]

Für die nächste Runde kannst du noch direct auf 1 bzw. 3 einstellen. 3 (auto) würde ich bevorzugen.--direct (x264)-directpred (FFmpeg)
ich kodier mal was... (Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi)ich hab das mal so eingestellt, wobei ich mit den analyse=0x3:0x133 nicht zurechtkommen...wenn du 8x8dct aktivierst, wird i8x8 in den partitions nutzbar. Ohne das wird die Einstellung vom Encoder einfach ignoriert.Sollte eigentlich passen.
und b_adapt=2 könnte das ganze etwas sehr verlangsamen? naja, läuft eigentlich noch ganz ok, dauert noch paar Stündchen.ja, wird schon langsamer. Aber anpassen kann man ja immer noch.

[Pete3]

Die i8x8 solltest du aber zumindest setzen wie auch Monarc schon geraten hat, sonst halt übers 8x8dct.

Und was die Encodinggeschwindigkeit angeht:
Da mußte einfach mal auf die CPU Auslastung gucken und ggf. über threads= xx
anpassen jenach CPU. Bei Sechskerner liegt man jenachdem mit 9-12Treads gut, mit Vierkerner meist bis so ~6

[OTR.TH]

Datei ist übrigens da: http://www.onlinetvrecorder.com/index.php?aktion=dl2&rrecordingid=2401561&id=&epg_id=5867562

[monarc99]

Datei ist übrigens da: http://www.onlinetvrecorder.com/index.php?aktion=dl2&rrecordingid=2401561&id=&epg_id=5867562

Ja, hab ich gesehen :)
Liege nur mit Fieber im Bett, deshalb so wenig Resonanz von mir ^^

Zur Qualität:
Die Qualität schaut gut aus. 2.3 GB groß und in meinen Augen zu der 2.8 crf Version durchaus vergleichbar. Finde ich prima :)
Allerdings bin ich kein Quali-Fetischist, das müssen andere beurteilen. Ich freue mich da eher, dass die Datei kleiner ist ^^


Zu den Kodiersettings:

Frame rate mode : Variable
variabler Framerate Modus ist aktiv. Einige HW Player (Bluray Player/Medienboxen) kommen damit nicht zurecht. Liese sich aber nur bei einer neueren ffmpeg Versionen abschalten.

Profle High@L3.0:
8x8dct schaltet von Main auf High Profile Modus. 8x8dct gehört jetzt nicht zu den Settings, die normalerweise Probleme bereiten, aber im Grunde müsste man diese http://www.onlinetvrecorder.com/?aktion=compatibility neu testen. Ich würde es erstmal an lassen und bei Problemen daran erinnern.

b_pyramid=2 und weightp=2:
Beides sind Features, die der Encoder nur einsetzt, wenn sie nützlich sind. z.B. nur alle paar Minuten mal. Wenn ich mir den Film mit dem Windows Mediaplayer und den originalen H264 Windows Codecs ansehe, sehe ich bei min 2:25-2:30 ganz kurz Bildartefakte. Kurz bevor das Bild auf die Reklameschild umblendet. Dürfte eins der beiden Settings Schuld sein. Man müsste auch anderen Player testen (z.B. Quicktime und HW Player)

b_pyramid und Avidemux 2.5:
Avidemux warnt ja, dass man den sicheren und dafür ungenauen Modus verwenden soll, wenn in einer H264 Datei B-Frames als Referenz verwendet wird. Damit dürfte bpyramid gemeint sein. Vielleicht kann jemand Avidemux, Virtualdub, CC und CA mal testen, wie die mit diesen Dateien klar kommen? z.B. Avidemux abstürzt, wie in der Meldung gewarnt wird.

qcomp=0.60 / qpmin=4 / qpmax=51 / qpstep=4 / ip_ratio=0.71
ip_ratio ist glaube ich falsch gesetzt. Sollte 1,40 sein?
Ich würde die Variablen gar nicht setzen. Die können sich im Laufe der Entwicklung des Encoders ändern.
Das Problem hier ist, dass die Default Werte in alten ffmpeg mies sind. Ein besserer Weg wäre: Nicht selbst setzen, ffmpeg updaten und die x264opts verwenden. (ja, ich nerve ^^)

Ansonsten sind die neueste crf Datei top :)

mit freundlichen Grüssen
monarc

[OTR.TH]

Hallo,
Liege nur mit Fieber im Bett, deshalb so wenig Resonanz von mir ^^
dann erstmal gute Besserung :)

qcomp=0.60 / qpmin=4 / qpmax=51 / qpstep=4 / ip_ratio=0.71
ip_ratio ist glaube ich falsch gesetzt. Sollte 1,40 sein?
sollte es eigentlich, ja... hab das Setting hier benutzt:
--ipratio <float> (x264)
-i_qfactor <float> (FFmpeg)


Ich würde die Variablen gar nicht setzen. Die können sich im Laufe der Entwicklung des Encoders ändern.
Das Problem hier ist, dass die Default Werte in alten ffmpeg mies sind.
wie alt? ;)
solange die gleiche Encoder-Version bleibt, ändert sich dann ja erstmal nichts...
ok, glaube, es wäre langsam an der Zeit, den Test auf mehr Leute auszuweiten... Hardware-Kompatibilität, Schneideprogramme testen (d.h. News-Eintrag, neuer Thread)? Oder noch paar Testdateien? ;)

PS: hier mal die Kodierzeiten (ca., 100% = momentane Kodierung):
100% : Inspector_Barnaby_12.02.05_22-50_zdf_95_TVOON_DE.mpg.HD.avi
108% : Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HD.avi
117% : Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HQ.avi
140% : Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi

[Pete3]

Dürfte eins der beiden Settings Schuld sein.
Probleme konnte ich dsbzgl. bei noch keinem Ausgangsmaterial feststellen und ich denke wenn das hier auftritt liegt die Ursache woanders.


Die Qualität schaut gut aus. 2.3 GB groß und in meinen Augen zu der 2.8 crf Version durchaus vergleichbar. Finde ich prima
Hört sich positiv an, Dateigröße wäre also um 700MB zum original OTR gesunken - oder?



Vielleicht kann jemand Avidemux, Virtualdub, CC und CA mal testen, wie die mit diesen Dateien klar kommen?
Avidemux liest solche Dateien ein, schneiden habe ich da jedoch nie probiert.
Virtualdub, Cuttassistant usw. kann sowas normallerweise ohne Probleme schneiden. Solche Files können auch problemlos in Avimux de/muxt oder umkontainert werden.

[The-Dude]

Moin moin,

für bessere Qualität bin ich immer zu haben ;-)
Ich muß allerdings sagen das ich ein Video Codec DAU bin, und da leider nix zu beitragen kann.

Aber zu Qualitätstest melde ich mich gerne.
Ich verwende:

CA 09.13.14
FFDSHOW 3222
VirtualDub 1.7.8
Avidemux 2.5.4
Xtreamer MK 1
Beamer eMachines v700 (baugleich mit Acer H5360)

Ich habe die Datei Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi getestet.
Gefühlt würde ich sagen das das Testfile minimal mehr Schärfe und weniger Artefakte liefert.
Aber das ist wirklich minimal.

Negativ ist aufgefallen:
Ungeschnitten wie geschnitten, leichtes Ruckeln im Bild (auch mit dem VLC auf dem PC).
Starker Tonversatz nach dem Schneiden mit CA. Das gleiche wenn ich ohne CA direkt mit VirtualDub schneide.
Schneiden mit Avidemux geht gar nicht. Ruckelt nur rum der Film.

Viele Grüße

Dude

[Artemis1121]

Frame rate mode : Variable
variabler Framerate Modus ist aktiv. Einige HW Player (Bluray Player/Medienboxen) kommen damit nicht zurecht. Liese sich aber nur bei einer neueren ffmpeg Versionen abschalten.

b_pyramid=2 und weightp=2:
Beides sind Features, die der Encoder nur einsetzt, wenn sie nützlich sind. z.B. nur alle paar Minuten mal. Wenn ich mir den Film mit dem Windows Mediaplayer und den originalen H264 Windows Codecs ansehe, sehe ich bei min 2:25-2:30 ganz kurz Bildartefakte. Kurz bevor das Bild auf die Reklameschild umblendet. Dürfte eins der beiden Settings Schuld sein. Man müsste auch anderen Player testen (z.B. Quicktime und HW Player)

habe die Datei gerade mit dem xtreamer und einem einfach Samsung fullHD TV getestet(LE40C579)
keinerlei Abspielprobleme, auch nicht bei 2:00-3:00.

Verbesserte Qualität bei geringerer Dateigröße: Klasse!

[Pete3]

Hast du die Szene mal in einem anderen Player getestet, ob es da auch ist?
Habs mal in einem alten VLC 1.1.2 angeguckt, der ältere VLC zumindest kann nicht mit B_Pyramid umgehen (Blue Ray ruckeln da auch), mit einem neueren VLC hab ichs nicht probiert (da nicht installiert).

In hinblick auf ältere Player, sonst halt das Pyramid rausnehmen ...
Allgemein wäre es vielleicht auch ev. sinnvollt, wenn nur eine 5Minuten Szene encodiert würde - da so sicherlich mehr Leute sich das zum vergleichen eher mal alles runterladen.

Momentan sind die ganzen Files wenn man sie lediglich vergleichen möchte ja fast 20GB (inkl. Orignal, falls es das zum download auch gibt) oder so, das iss ja schon en bißel heftig zum downloaden....

[monarc99]

sollte es eigentlich, ja... hab das Setting hier benutzt:
--ipratio <float> (x264)
-i_qfactor <float> (FFmpeg)

Ist schon das richtige, nur kommt wohl nicht der Wert an, den man angibt. Klingt irgendwie nach ffmpeg ^^



wie alt? ;)
solange die gleiche Encoder-Version bleibt, ändert sich dann ja erstmal nichts...

ich fürchte sehr jung und den Encoder wird man vermutlich auch updaten müssen. ^^
Soweit ich noch weiss, sind die presets und default Werte vom frontend (x264(.exe)) in die lib264 gewandert.
Und das nutzt ffmpeg jetzt aus. Ist aber so auf jeden Fall besser. Die Default Werte vom ffmpeg sind ja schlimm.



ok, glaube, es wäre langsam an der Zeit, den Test auf mehr Leute auszuweiten... Hardware-Kompatibilität, Schneideprogramme testen (d.h. News-Eintrag, neuer Thread)? Oder noch paar Testdateien? ;)

Nun, man könnte eine sehr verrauschte Sendung suchen. So eine, wo sich die Leute immer beschweren, dass die HQ/HD so mega groß sind.
Und man könnte ne HQ kodieren. Damit man eine Testdatei mit 25fps hat.



PS: hier mal die Kodierzeiten (ca., 100% = momentane Kodierung):
100% : Inspector_Barnaby_12.02.05_22-50_zdf_95_TVOON_DE.mpg.HD.avi
108% : Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HD.avi
117% : Inspector_Barnaby_12.02.05_22-50_test_95_TVOON_DE.mpg.HQ.avi
140% : Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi
Wo ist denn die Schmerzgrenze?

[Artemis1121]

hab den aktuellsten VLC 1.1.11. habs gerade mit dem wmplayer 12 getestet, bei dem ists katastrophal! beim mpc-hc mit und ohne DXVA mein ich auch Ruckler zu sehn..

habe auch einen MK1 und gerade noch mal getestet.. habs hier vom Computer nicht richtig gesehn.. Aber jetzt hab ich mich direkt vor den TV gestellt und da sind mikroruckler zu erkennen.. mir ists aus 5 Meter Entfernung nur nicht aufgefallen... sry..

[Harry999]

mit der 2,34GB grossen HD datei, habe ich probleme.
ich hatte mir mal den part (um 4:20 rum) an der hauswand rausgeschnitten und fand es auch etwas ruckelig.
dann wollte ich mir das am TV ansehen und stellte fest, dass alle geschnittenen files ( mehrere groessen/laengen probiert) bei mir keinen ton abspielen.
(CC 1.0.8.6; VDub 1.9.11; win7-64HP)
die ungeschnittene version wird problemlos abgespielt.
Hardware:
Samsung LE46C750 per HDMI (daher wohl eher wurscht) ueber eine WDTVLiveHD und HDD versorgt.

am laptop habe ich kleine tonaussetzer (VLC 1.1.11) aber zumindest auch im 30sek schnitt ton.

[monarc99]

So auch mal ein wenig getestet:

Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi

die Microruckler sehe ich in VLC. VLC verwendet meines Wissens nur 1 Core, Multicore soll ja mit 1.2 kommen.
MPlayer2 mit Multicore ist alles flüssig.
Per Hardware ist auch alles flüssig.

Ich sehe diese Microruckler allerdings auch in Inspector_Barnaby_12.02.05_22-50_zdf_95_TVOON_DE.mpg.HD.avi, die mit den otr Settings kodiert wurden.
Ist vielleicht minimal weniger, es ruckelt da genauso in VLC bei mir.

Abspielen liess sich die neueste crf 23 Version auf WDTV gen1, Samsung TV C650.

Schneiden:

Avidemux 2.5.5:
* VBR Zeitkarte erstellen -> JA
* Sicheren Modus verwenden -> NEIN
* Index neu erzeugen -> NEIN

Obwohl die Datei mit bpyramid erzeugt wurde, habe ich - bei den relativen kurzen Test - keine Abstürze erlebt.
Das Schneiden an Keyframes war problemlos und die erzeugte Datei war ok.

Virtualdub 1.10.2 + ffdshow:
Bin ich noch am Testen. Die ersten Versuche schauen aber ok aus.

mit freundlichen Grüssen
monarc

[monarc99]

So still geworden hier ^^

Zum Schneiden der crf 23 (2.3 GB) + smart rendering:

Codec ffdshow

klappt leider nur oberflächlich. Ich hab die Einstellungen mal soweit angepasst. Das Video sieht auch in VLC ok aus.
Wenn man allerdings in andere Container umpackt (wie es für einige Player notwendig ist), zeigen sich Bildfehler. Ist also nicht so das Wahre.

Codec x264vfw

Mit diesem Codec schaut es besser aus. Leider ist die HD schlecht zum Testen geeignet, weil schon die ungeschnittene Datei bei mir in Quicktime ruckelt und man schlecht nach Fehler suchen kann ^^
Vielleicht kann jemand testen, wie die geschnittenen Dateien auf den eigenen System läuft?

Laden und entpacken:

http://dl.dropbox.com/u/7287363/VirtualDub-1.10.2-test2.zip
Den im Paket beigelegten x264vfw Codec installieren.

Virtualdub starten.
Mit Menü FILE -> Load processing settings die beigelegte tv_profile_x264vfw.vcf laden
Inspector_Barnaby_12.02.05_22-51_test_95_TVOON_DE.mpg.HD.avi laden und schneiden
(für den Test möglichst nicht auf Keyframes, Smart Rendering soll ja anspringen, die Settings gelten auch nur für diese Datei)
Als AVI speichern.

Auch hat die crf23 (2.3 GB) irgendwas komisches. Einige Programme kommen damit gar nicht klar. (Lesen sie gar nicht ein oder brechen mit Fehlermeldung ab).
Bei der anderen crf 23 (2.8 GB) habe ich dagegen keine Probleme feststellen können.

mit freundlichen Grüssen
monarc

[Artemis1121]

habe die 2.3gb Datei nach deiner Anleitung geschnitten.
Sowohl im VLC, auf dem xtreamer als auch auf Samsung LE40C579 laufen die geschnittenen Dateien(bis auf die angesprochenen Mikroruckler) bei mir problemlos.

(Virtualdub zeigt beim hin und herspringen in der Videodatei ab und zu Probleme. Ich bin Keyframes vor und zurückgesprungen und wollte da einzelne Frames weitergehn die Zeit wurde richtig weitergestellt, aber ich landete im Bild dann immer Keyframes weiter.. den Bug würde ich aber eher Virtualdub zuordnen als der Videodatei.)

ps: man muss doch fast-recompress nehmen.. bei direct-stream-copy schneidet er am vorherigen/nachfolgendem Keyframe, oder?

pps: umpacken probier ich gleich noch.

ppps: nach mkv (mit mkvmerge 5.3.0) umgepackt, läuft im vlc, xtreamer, Samsung LE40c579 problemlos.

[monarc99]

(Virtualdub zeigt beim hin und herspringen in der Videodatei ab und zu Probleme. Ich bin Keyframes vor und zurückgesprungen und wollte da einzelne Frames weitergehn die Zeit wurde richtig weitergestellt, aber ich landete im Bild dann immer Keyframes weiter.. den Bug würde ich aber eher Virtualdub zuordnen als der Videodatei.)

Hm, ist es denn in der 2.8GB Datei besser?
bpyramid macht es ein wenig schwieriger die Frames zu sortieren, dann sollte es in der 2.8er besser sein.



ps: man muss doch fast-recompress nehmen.. bei direct-stream-copy schneidet er am vorherigen/nachfolgendem Keyframe, oder?

ja, ist es falsch eingestellt? dann bitte auf fast (normal geht glaube ich auch) umstellen



pps: umpacken probier ich gleich noch.

ppps: nach mkv (mit mkvmerge 5.3.0) umgepackt, läuft im vlc, xtreamer, Samsung LE40c579 problemlos.
Also mkv bzw. avi sollte kein Problem machen. Im Grunde immer nur die umgewandelten MP4.
Avidemux hat auch nie Probleme gemacht, nur spielen viele HW Player die MP4 von Avidemux erst gar nicht ab.
FFMPEG war immer so teils teils ...

Wichtig wären die MP4 von MP4Box. Gibt einige Player, die nur diese Dateien abspielen.
Leider ist MP4Box auch am empfindlichsten. Da zeigen sich Bildfehler, auch wenn alle anderne top aussehen.

ps. guter Test ist z.B. nach MP4(H264,AAC) mit MP4Box umwandeln (z.B. Variante 7 bei den Lemmingen - auch wenn es da etwas umständlich gelöst ist)
und dann in Quicktime abspielen. Wenns da klappt, dürfte es auf den (meisten ^^) HW auch gehen.

mit freundlichen Grüssen
monarc

[Pete3]

aber ich landete im Bild dann immer Keyframes weiter.. den Bug würde ich aber eher Virtualdub zuordnen als der Videodate.. bei direct-stream-copy schneidet er am vorherigen/nachfolgendem Keyframe, oder?
Ja das schneiden im vdub ist nunmal ungenau - nur, die HD Files sind ja aus den öffentlich rechtlichen wo keine Werbung dazwischen ist, so daß man je eh nur (normallerweise) am anfang und ende was wegnimmt, so das man auch einfach über stream copy machen kann. Framegenaues schneiden hat bei den Files ja wenn man ehrlich ist letztlich nicht so die Relevanz wie bei den Privaten, wo halt Werbblöcke dazwischen liegen.
Und wenn man es genauer schneiden will, dann ist vdub alleine halt auch nicht geeignet und akkurateres schneiden funktioniert ja ansonsten einwandfrei mit dem Cuttassistant oder so.

Die Ruckler liegen imo auch nicht am encode, denn wie schon gesagt in der Tagesschau sind sie nicht und wenn es ausschließlich am encode läge = müßten sie da auch zu sehen sein, weil ist ja gleich encodiert.



mit MP4Box umwandeln
Wie stellst du da 50FPS ein?

[Artemis1121]

Hm, ist es denn in der 2.8GB Datei besser?
ich konnte den Fehler jetzt leider nicht mehr reproduzieren.. vorhin war er dauerhaft vorhanden und ich hab mich dann nur noch an der Zeitangabe orientiert und nicht mehr an dem Bild..



guter Test ist z.B. nach MP4(H264,AAC) mit MP4Box umwandeln (z.B. Variante 7 bei den Lemmingen - auch wenn es da etwas umständlich gelöst ist)
und dann in Quicktime abspielen. Wenns da klappt, dürfte es auf den (meisten ^^) HW auch gehen.
klappt zumindest mit meinen beiden Testschnippseln problemlos.

[Pete3]

Hallo,

CA und CC dürften -meines Wissens- nur GUIs sein. Zum Schneiden von AVIs verwenden z.B. die Virtualdub im Hintergrund (über die vdub.exe)
ja klar, das ist richtig - zum schneiden verwenden die vdub (oder wenn man will auch anderes). Da die Schneidepreview jedoch imo übers CA stattfindet, hat man dort jedoch nicht das Versatzproblem (wie in vdub selbst) wenn man versucht zwischen keyframes und so hin/herszupringen.


Über den -fps Parameter
aus den Variante 7 Script von OTR Lemminge (hier im Forum zu finden)
Ok, alles klar dann - danke. :)

[Harry999]

das problem ist ein anderes.
bisher gibts ja nur testfiles (einer ganz anderen aufnahme) und keine liveaenderungen.
ich habe uebrigens Bodyguard in HD ohne probleme von einem mirror gezogen.

[1-2-3-man]

Hab jetzt aus Zeitgründen nicht den ganzen Thread gelesen, aber ich kann bestätigen dass Artefakte in dunklen Bildbereichen gelegentlich schon bei der Ausstrahlung auf HD-Sendern über DVB-S auftreten. Konkret ist mir das bei Uhrwerk Orange aufgefallen. Ich hatte mir die HD-Datei von OTR runtergeladen und in der Szene, als sie mit dem Sportwagen durch die Nacht rasen, bestand der dunkle Hintergrund nur aus Pixelblöcken. Ich hab dann die Wiederholung auf arte HD aufgenommen und siehe da, das Original war kaum besser. War dann etwas schockiert, weil ich derart schlechte Qualität bei den Datenraten nicht erwartet hätte. Vielleicht tüfteln die ja auch noch an den Encoder-Settings...

[Ralgert]

Konkret ist mir das bei Uhrwerk Orange aufgefallen.

Wann und wo lief der Film? Ich bin da schon laenger her und habe ihn auch in der Suche nicht gefunden.


Pete, wieviele _Leser_ hast du gefragt?


edit:
Danke Artemis.
Leider sind die vorhanden Aufnahmen schon zu lange her. Aber mit OTR bin ich bei der naechsten Ausstrahlung dabei.
Achja, die Suche funktioniert nun; sobald man nicht staendig mit Tipfelhern sucht :-)

[Artemis1121]

Wann und wo lief der Film? Ich bin da schon laenger her und habe ihn auch in der Suche nicht gefunden.
Mitte letzten Jahres und er ist noch auf einigen Mirrorservern verfügbar, z.b. beim Datenkeller: http://otrkeyfinder.com/?search=clockwork&search.x=0&search.y=0&order=odn

@pete3:
es gibt leider nicht die Einstellung die man einfach so für alles nehmen kann... und OTR hat keine großen finanziellen Mittel, wie du annimmst.
es werden hier Tests gemacht, es wird der Rat von Leuten die sich besser auskennen berücksichtigt. was ist eigentlich dein Kritikpunkt?
hier in diesem Thread haben sich einige Leute eingebracht, auch wenn nur ihr 2 direkt mit OTR.TH die Settings diskutiert. Aber zu unterstellen, dass die anderen User sich nen Ast lachen über euch 2 Deppen finde ich unmöglich!

[Leseesel]

Ist ja wirklich nicht so, dass keine Resonanz gekommen wäre. Weder in Bezug auf Nutzer, noch auf OTR-Macher. Selten wurde einem Vorschlag so schnell Beachtung bis hin zu Tests geschenkt. Sorry, ich kann das Verhalten nicht nachvollziehen. Ich könnte noch einiges dazu schreiben, das ich mir erst einmal spare. Was würde so jemand machen, wenn er mit Problemen konfrontiert ist, die ich seit Jahren zu tragen habe? Vermutlich nach 2 Sekunden aus dem Fenster springen.

[Harry999]

Wir verplempern hier nur unsere Zeit.

beim lesen deines posts, war es so....

[Eos]

Hallo!

Als Nur-Nutzer muß ich ganz klar mal feststellen, daß ich bei den hier diskutierten Einstellungen des Codecs einfach nur Bahnhof verstehe - und da bin ich bestimmt nicht alleine.
Um OTR nutzen zu können, muß man über diese Dinge auch gar nicht Bescheid wissen - ein Autofahrer muß ja auch die Programmierung der heutigen Motor-Elektronik nicht kennen und verstehen.

Da ist es natürlich kein Wunder, daß hier bei diesen Fachgesprächen auf höchstem Niveau nur wenig Reaktionen kommen. Viele Nur-Nutzer werden diesen Thread gar nicht lesen und wissen deshalb nicht, daß Testdateien mit verschiedenen Einstellungen angeboten werden, um die Einstellungen optimieren zu können. Etwas mehr Reklame für die Testdateien (und möglichst auch kleinere Dateien - man könnte ja die als kritisch erkannten Bereiche herausschneiden) würde auch für mehr Resonanz sorgen.

Gruß

Eos

[gulliver]

Bitte wieder Back2Topic ;)

[Pete3]

was ist eigentlich dein Kritikpunkt?
Eos hat es schon angesprochen: Die TestFiles sind viel zu groß und manches wirft zudem Fragen auf die man (ohne ein original file gesehen zu haben) eh kaum beantworten kann. Z.b. die Mikroruckler, waren sie im original -oder- entstehen sie durch die Art wie OTR das über ffmpeg ?() ins avi encoded. Sind Sachen, die letzlich nur OTR beantworten kann,
Und Änderungsvorschläge sind genannt worden - doch, was nützt es weiter Zeit investieren - zumal auch grundsätzlich unklar ist, inwiefern OTR letzlich auch tatsächlich beabsichtigt etwas an den HD-Aufnahmen zu ändern bzw. (in Abwägung zur Encodingzeit) überhaupt ändern kann. (was ebenfalls nur OTR beantworten kann)

[Leseesel]

Eos hat es schon angesprochen: Die TestFiles sind viel zu groß und manches wirft zudem Fragen auf die man (ohne ein original file gesehen zu haben) eh kaum beantworten kann. Z.b. die Mikroruckler, waren sie im original -oder- entstehen sie durch die Art wie OTR das über ffmpeg ?() ins avi encoded. Sind Sachen, die letzlich nur OTR beantworten kann,

Nun, zumindest ein Vergleich zu momentanen Codierung, die in Sachen Ruckler eigentlich als unproblematisch gelten dürfte, sollte möglich sein. Damit dürfte sich die Frage weitgehend beantworten lassen. Oder zumindest ist es in Bezug auf Änderungen unproblematisch, da man Verschlimmerungen somit ausschließen kann.
Dass die Dateien natürlich sehr groß sind und man manuell an die entsprechenden Stellen navigieren muss, ist ein Problem. Bei mir kommt das Problem hinzu, dass mein Rechner momentan schon zu schwach ist, um normale HD-Files fehlerfrei wiederzugeben und dass die Probleme, die ich am Hals am Hals habe, im Moment viel Stress erzeugen. Ich also nur wenig zu anspruchsvollem, konzentriertem Vergleichen komme, weil ich übermüdet bin und häufig unterbrochen werde.


Und Änderungsvorschläge sind genannt worden - doch, was nützt es weiter Zeit investieren - zumal auch grundsätzlich unklar ist, inwiefern OTR letzlich auch tatsächlich beabsichtigt etwas an den HD-Aufnahmen zu ändern bzw. (in Abwägung zur Encodingzeit) überhaupt ändern kann. (was ebenfalls nur OTR beantworten kann)

Nun, ich werte

http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=339076&viewfull=1#post339076
http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=339032&viewfull=1#post339032
http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=339028&viewfull=1#post339028
http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=339022&viewfull=1#post339022
http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=338976&viewfull=1#post338976
http://www.otrforum.com/showthread.php?66385-HD-Aufnahmen-sind-zu-schlecht-andere-Kodierung-einsetzen&p=338966&viewfull=1#post338966

zumindest mal als ein sehr gutes Zeichen für eine Änderungsbereitschaft.

[monarc99]

Gibt bei mir keine Probleme mit VLC2.0
Aber du kannst probieren, den Cachewert von 300ms auf 1000 oder höher zu stellen.
Oder die Threadanzahl von 0 (auto) auf 2 (hast ja 2 Kerne?) zu stellen.

Oder schon einen anderen Player probiert? MP-HC z.B.?

[Pete3]

@Leseesel
Der VLC Player war mal ein guter Player aber so gut wie damals ist der heutzutage nicht mehr. Nimm einen vernünftigen Player wo man auch externe Sachen einbinden kann wie z.b. einen Cuda basierten Dekoder+ Renderer ö.ä. => dann läuft HD schon flüssig (selbst mit einem Einkerner, wenn die GPU das dekodieren übernimmt)

[Leseesel]

Danke, ich fürchte, die Geforce Go 7300 kann kein Cuda. Falls doch, bitte gerne rückmelden.

Da das Notebook schon seit Jahren am verrecken ist, werde ich es bald gegen ein unkomfortableres, zu dem ich noch keine XP-Treiber gefunden habe, tauschen müssen. Vielleicht läuft es dort dann besser. Das hat dann AFAIR einen GF 8400. Da fehlt mir dann allerdings der optische Audio-Ausgang und das Display ist schlechter, das Gerät macht Lärm, ich muss ein anderes OS kaufen usw. Außerdem war das auch schon ziemlich defekt und ich weiß nicht, wie lange das hält.

Ich verstehe nur nicht, warum das neue VLC bei mir so katastrophal läuft und bei allen anderen besser als das alte VLC. Werde noch an den Einstellungen spielen, aber viele Hoffnungen mache ich mir nicht.

Ach, eines noch: Ich werde vermutlich ein paar Tage nicht antworten und nicht testen können.

[Leseesel]

Alles durchprobiert, bislang keine Chance, wenigstens die HQ-Datei sauber abzuspielen.
Der einzige erkennbare Unterschied: Hardware-Decodierung an: Nur 1 Kern wird genutzt (50% CPU), stehen bleiben, defekte Bilder.
Hardware-Decodierung aus: 2 Kerne scheinen genutzt zu werden, nur noch ungleichmäßiger Bildablauf, also Ruckeln.
Habe jetzt meinen MPC-HC mal aktualisiert. Da gefallen mir allerdings einige Dinge in der Bedienung nicht so, z.B. das schnelle Ändern des Seitenverhältnisses, oder mal eben in den Hintergrund schieben, um hier zu tippen. Läuft aber um Klassen besser auf den ersten Blick.

[okossmann]

@Leseesel
Der VLC Player war mal ein guter Player aber so gut wie damals ist der heutzutage nicht mehr. Nimm einen vernünftigen Player wo man auch externe Sachen einbinden kann wie z.b. einen Cuda basierten Dekoder+ Renderer ö.ä. => dann läuft HD schon flüssig (selbst mit einem Einkerner, wenn die GPU das dekodieren übernimmt)

Hola.

Zum Beispiel welchen ??

Gruessle

[Artemis1121]

Cuda (http://en.wikipedia.org/wiki/CUDA) ist nur Nvidias Schnittstelle für parallele Berechnungen auf der Grafikkarte.
Für die Dekodierung der Videosströme wird aber was anderes genutzt:
Unter Windows nennt sich das DXVA(DirectX Video Acceleration) (http://en.wikipedia.org/wiki/DXVA) und die Einheiten auf den Grafikkarten nennen sich Nvidia PureVideo (http://en.wikipedia.org/wiki/Nvidia_PureVideo) oder bei ATI/AMD Unified Video Decoder (http://en.wikipedia.org/wiki/Unified_Video_Decoder).
Im DXVA-Artikel (http://en.wikipedia.org/wiki/DXVA) gibts ne kleine Liste mit Programmen die das nutzen: WMPlayer, MPC-HC, VLC und viele andere. Teilweise muss man es aber erst in den Einstellungen aktivieren. GIDF! :)

PS: ein schönes Tool um zu schaun ob der eigene Computer DXVA unterstützt, ist DXVAChecker (http://bluesky23.yu-nagi.com/en/index.html#DXVAChecker)!

[Artemis1121]

AVIs können zwar auch mehrere Tonspuren beinhalten, jedoch bearbeiten die Schnittprogramme nur die erste Tonspur und ignorieren die zweite.
MKVs lassen sich aktuell nur Keyframe-genau schneiden - nicht framegenau. Ich hab eine Zeit lang mit mkvmerge GUI geschnitten. dazu einfach AVI und AC3 in das Programm ziehn, die Schnittstellen eintragen und dann hat das Programm geschnitten. wie geasgt, man konnte nur an Keyframes schneiden und man muß die Schnittstellen aus dem CutAssistant umrechnen und eintragen.. Die Ac3 Tonspuren waren oft nicht synchron, so dass ich es irgendwann aufgegeben habe..

[monarc99]

Cuda (http://en.wikipedia.org/wiki/CUDA) ist nur Nvidias Schnittstelle für parallele Berechnungen auf der Grafikkarte.

Da ist vielleicht LAV Filters gemeint. Die enthalten neben den Software Decoder, DXVA auch einen NVIDIA CUVID Hardware decoder.

Man verwendet da MPC-HC x86 + MadVR + LAV filters 32 bit zusammen.
Wer das mal ausprobieren will, findet hier ne Anleitung, ist aber eher was für die Experimentierfreudigen, liefert aber gute Qualität.
http://www.avsforum.com/avs-vb/showthread.php?t=1357375

mfg
monarc

[okossmann]

Hola. Das hört sich ja nicht so toll an :(

Weiß jemand wieso es scheinbar so ein Problem ist mkv's zu schneiden ?

Gruessle

[MrR]

Kennst du evtl. noch ein Programm um MKV's zu schneiden.
Guggst Du :) http://www.otrforum.com/showthread.php?57685-MKV-mit-Cut-Assistant-und-MKVToolnix-schneiden

[Artemis1121]

Wie gesagt, MKVs mit mkvmerge keyframegenau schneiden funktioniert, aber es gibt keine Lösung zum schnellen Framegenauen schneiden von MKVs.
Der Grund ist, das man zum keyframegenauen schneiden nur die passenden Punkte suchen muß und einfach schneiden kann, beim framegenauen Schnitt muss man zusätzlich noch die Frames rundherum neukodieren. man benötigt also zusätzlich noch einen h264 Encoder. Ist kein unlösbares großes Problem, aber es hat eben noch niemand bisher programmiert.

[Pete3]

Man verwendet da MPC-HC x86 + MadVR + LAV filters 32 bit zusammen.
Nutze selbst die Kombi KMPlayer + MadVR + Lav, man kommt da so auf ca. 3% CPU Auslastung bei 1080p Material. In Pod & BSPlayer läßt sich das auch nutzen. Leider kann Leseesel die Kombi jedoch nicht nutzen, da er keine Nvidia Graka hat. Wenn kein Cuda bleibt wohl nur DVXA. Bei Sandy Bridge CPUs und Nutzung der IGP, gäbs sonst glaub ich noch Intel QuickSync oder so.



Ist kein unlösbares großes Problem, aber es hat eben noch niemand bisher programmiert.
H.264/MKV framegenau schneiden sollte glaube ich mit der VideoRedo (H.264) Suite gehen, das Prog. ist aber kostenpflichtig.