Videokonvertierung - Welche Einstellungen ?

[ahrte 0]

Hallo,

was sind eurer Meinung nach die optimalsten Einstellungen bei einer Video-/Filmkonvertierung (natürlich für das Jet)??? Wie erziele ich eine gute Bild- und Tonqualität?

Format: ? (z.B. 3gp, mp4 )

VIDEO

Videocodec: ? (z.B. H264)

Größe/Auflösung: ? (z.B. 720x480)

Bitrate(Kbps): ? (z.B. 750)

Framerate: ? (z.B. 25)

AUDIO

Audiocodec: ? (z.B MP3)

Frequenz:? (z.B. 44100)

Bitrate: ? (z.B. 96)

[faziman 1]

hm, also jetzt bin ich etwas verwirrt

ich schau mir nahezu alles mit vlc-player an, da mit WMP und power-dvd öfters mal probleme bereitet haben

ich lass nebenbei ffdshow laufen (für die div. codecs)

aber ich werd wohl mal den test machen, den du uns da präsentierst

bezgl. schärfe meinte ich, dass ich im VLC-player bei der quell-datei bei diversen frames noch keinen "schleier" gesehen habe; bei der erneut-kodierten (und komprimierten) datei jedoch am TFT schon

und am JET eben nicht (da dieser screen zu klein ist, um solche details zu erkennen; auch bei ner auflösung von 800x480; meine quell-datei hat nur 630x272; da nützen die max. 720x480 leider gar nichts...)

ach noch etwas; das 2., 3. und 4. vid. das ich jetzt auf 500kbit kodiert habe, hat wunderbarerweise 25fps als quelle UND als fertig-kodierte datei

scheint also ein einmaliger fehler gewesen zu sein

und 10-11% pro Stunde, statt 14-15% ist auch sehr angenehm (da ja auch mehrere vid. auf den int. speicher passen, was mir ja, wie gesagt, strom-technisch auch entgegen kommt)

danke nochmals für deine hilfe, bin mit dem ergebnis in jeder hinsicht sehr zufrieden

[DJ-Tumor 47]

Also ich encode mit meinen Programmen einen kompletten Film in 720*576 in ca. 30mins. meistens drunter sogar!

Naja....man sollte wohl noch die Hardwareconfig mit angeben.

Bei mir ists ein Core2Quad bei 3456Mhz (OC).

Also 11% pro Stunde würde dann ja ca. 9 Stunden für einen Film bedeuten....

Mit was für ner alten Kiste encodest du da???

[*idm* 195]

Ich gehe mal davon aus, daß er den Stromverbrauch des Telefons meint.

11% der Akkuladung pro Stunde Film.

[dieCrisa 0]

Also ich encode mit meinen Programmen einen kompletten Film in 720*576 in ca. 30mins. meistens drunter sogar!

Diese Aussage hat keinen Wert weil keinen Bezug. Wenn die Quelle ebenfalls 720x576 hat, dann ist auch das nicht weiter erstaunlich, da keine Skalierung erfolgt. Was diese Auflösung jedoch mit unserem Jet zu tun hat, ruft in mir eher ein Kopfschütteln hervor. Wieder der falsche Film oder gar das falsche Kino?

MP4-konform - was ist das denn? Ich nehme stark an, dass Du Dir kaum vorstellen kannst, was alles unter MP4 fallen kann. Das Netz ist voll von Problemen damit. Kaum eine Hardware kann alle möglichen ("erlaubten") Variationen abdecken. Von illegalen Codecs ganz zu schweigen.

Wahrscheinlich finden hier sogenannte Codec-Packs reißenden Absatz - und verwunderte User, wenn es Probleme gibt. Auf die Codec-Packs fällt jedoch kein Verdacht, weil die immer so super angepriesen werden. Wer da meint, Masse sei Klasse, mache bitte weiter so. Da hilft dann nichts mehr.

Wenn das auch so gut klappt, wie der Link - ist ja alles supi: https://xn-- http-6ed//www.megaupload.com/?d=G4292JHC

Warum nur fällt mir gerade jetzt die Geschichte von "des Kaisers neue Kleider" ein?

[XtAbIT 0]

nutze x264 800-1000kb "eigentlich zu viel,weniger müßte auch reichen" und aac 128 im mp4 container für alle Filme, es sei denn die Quelle is eh schon schlechter. Dann machts keinen Sinn.

Aber immo kommt kein codec an x264 ran ... grade im low kb bereich nicht.

Interessantes Material für Leute die sich mehr damit befassen möchten:

Brother John´s Encodingwissen

bearbeitet February 26, 2010 von XtAbIT

[deleiser 0]

also ich hau sie so drauf wie ich sie hier habe

[faziman 1]

Bei mir ists ein Core2Quad bei 3456Mhz (OC).

Also 11% pro Stunde würde dann ja ca. 9 Stunden für einen Film bedeuten....

Mit was für ner alten Kiste encodest du da???

AMD Phenom 2 X4 945 (95W TDP)

dauert für nen 90min-film rund 20min (wenn die auflösung gleich bleibt) und ich nebenbei surfe (bzw. rund 35min, wenn ich zocke ^^)

ich meinte natürlich (so wie *idm* erkannt hat) den stromverbrauch pro stunde

2-CD-film (erste CD --> 1h 15min):

bei 1100kbit xvid und 160kbit mp3 --> 14/16% pro h (int./ext. speicher) --> 6h film (700MB)

bei 500kbit divx5 und 96kbit mp3 --> 10/12% pro h (int./ext. speicher) --> 8h film (320MB)

bei (am JET) gleichbleibender qualiy

werd heute mal nen vergleich mit den playern machen (vlc vs. divx-player)

bin schon gespannt

ciao

fazi

bearbeitet February 26, 2010 von faziman

[DJ-Tumor 47]

@Crisa

dein komplettes Posting macht für mich keinen Sinn.

Die Auflösung 720*576 ist ganz normales PAL und kann überhaupt nicht vom Samsung wiedergegeben werden. Hatte aber mit dem Samsung auch überhaupt nichts zu tun. War jedem klar, nur dir nicht.

Weiter musst du doch Leuten, die wissen wovon sie reden, nicht unterstellen sie wüssten nicht wovon sie reden, bloß weil du nichts mit dem Begriff anfangen kannst.

MP4 Konform bedeuted für mich, das im MPEG4 Container MPEG4 Video und MPEG4 Audio drin steckt. So wie es ursprünglich von dem Konsortium angedacht war. Das sich MPEG4-Audio nicht durchgesetzt hat, ist nicht weiter verwunderlich, da schon so starke Gegner wie MP3 oder AC3 Position genommen haben/hatten. Obendrein buhlt AAC ohnehin auch noch erfolgreicher um eine größere Anhängerschaft.

Das man in den Container MP4 einiges anderes reinschmeissen kann ist mir absolut klar, wobei der Container das Rennen schon längst gegen MKV verloren hat. Den leider das Samsung auch nicht supported.

Ich habe noch nicht viel herumprobiert und weis daher noch nicht was das Samsung noch alles kann. Aber MPEG4 Audio musste einfach gehen, da man ja auf MP4 als Container setzte. MP3 gehört da vorerst gar nicht rein und müsste nicht zwingend unterstütz werden, was aber so ist, wie ich schon in anderen Postings gelesem habe.

Was du da von Codec-Packs faselst ist völlig aus dem Zusammenhang genommen und weist weitere Wissenslücken gnadenlos auf.

Was haben diese Codec-Packs mit dem Encoden zu tun???

NICHTS, da diese Codec-Packs ausschließlich bei Abspielproblemen empfohlen werden und sonst eigentlich nur unheil bringen können.

Das auch ich diese Codec-Packs in 99% der Fällen verfluche ist wohl der einzige Punkt, in dem wir vorerst übereinstimmen.

@faziman

jou....da habe ich wohl auf der Leitung gesessen, aber wenigstens vergreife ich mich nicht gleich so in der Wortwahl wie andere Zeitgenossen hier.

Um meine Ehre zu retten, muss ich jetz natürlich drauf hinweisen, das die Encoding-Zeit (falls es so einen Begriff überhaupt gibt ) von zu vielen Faktoren abhängt, als das man sie so ohne weiteres vergleichen könnte. Angefangen mit der Wahl des Encoders. x264, als echter reinrassiger h264 encoder bietet natürlich deutlich mehr Möglichkeiten und Fähigkeiten, als ein "einfacher" MPEG4 Codec und ist daher auch zu unsäglichem Möglich.

Es gibt Einstellungen, die so brutal sind, das auch mein Rechner für den selben Film über 24h stunden brauchen würde....nicht umsonst heißt diese Einstellung dann auch vom Profilnamen her "insane"

Achja....meine CPU hat ne TDP von nur 65W:haha:

[faziman 1]

Achja....meine CPU hat ne TDP von nur 65W:haha:

lol, ok; 1. runde geht an dich !! aber mein rechner braucht inkl GTX275 nur 100-110W im Idle (beim Encoden 115W); wie schauts da bei dir aus ??

btt: wenn meine quell-datei nur 12bit-video hat, warum erstell ich dann ein divx mit 24bit? braucht das nicht unnötig speicherplatz?

oder liegt da ev. der vorteil, dass die farben nicht noch weiter verfälscht werden

(abgesehen davon, dass ich auch am PC-Screen keinen unterschied sehe *sry*)

inwiefern wirkt sich 12bit vs 24bit auf die dateigröße aus? und lässt sich so vl. noch ein wenig JET-akkuleistung herausholen?

(wohl eher nicht, wenn der unterschied zwischen 1200kbit und 500kbit "nur" -25% stromverbrauch bei -55% bitrate beträgt...)

und leute: reißt euch alle vl. ein bisserl zamm, man muss nicht immer gleich beleidigen oder jemanden anrotzen, wenn der von dem einen weniger weiß, und man dafür bei etwas anderem eher glänzt (das ist kindergarten-politik!)

PS: hab jetzt in einem rutsch 7h 45min divx/500kbit schauen geschafft (beachtlich)

und die typischen 5,5% restakku von samsung sind noch da (um k.a. was zu machen; jemanden anzurufen, dass man jetzt 7,75h film gesehen hat?!), diese 5% wären noch fast 25min schauen *grr*

ich lad jetzt mal und mach den test mit der quell-datei die ja um die 1200kbit hat

ich erwarte mir hier dann um die 6h... bis dann und DANKE an alle, die bisher "recht sachlich" argumentiert und mir und anderen weitergeholfen haben

...

EDIT: hab mal kurz nachgerechnet; 12bit wären ja nur 4096 farben ?!

das muss wieder ein auslesefehler sein... außerdem wäre das doch mehr als nur sichtbar, oder?

24 bit ist ja Truecolor mit rund 16.8 mio farben... da müsste dann echt ein unterschied in der dateigröße sein!

...

EDIT2: die "Audioverstärkung" bei Dr.DivX normalisiert nicht die audio-spur, sondern erzeugt aus 5.1 sound einen vernünftigen 2.0 ton, oder irre ich mich da?

...

EDIT3: kann Dr DivX eig. auch Multipass-Encoding? Habe gerade auf en.wikipedia.org gelesen, dass Dr.DivX 2.0.1 das eig. können müsste; das Profil von "dieCrisa" erstellt aber soweit ich mich jetzt erinnere (bin rad ned an meinem pc) die files nur mit single-pass, dafür aber in 2 durchgängen (was doch auf den selben effekt hinausläuft, oder nicht?)

sry für meine fragen, kenn mich bei dem ganzen sch*** ned so aus wie ihr; muxxen, demuxxen, shapen, stripen, cutten, flooden, bitchen, etc *omfg*

bearbeitet February 26, 2010 von faziman

[dieCrisa 0]

Hi DJ-Tumor!

Als selbsternannter MP4-Fachmann (insbesondere für Konformität), der ganz genau weiß wovon er redet, kannst Du mir das sicher erklären:

Weiter oben hatte ich die Eckdaten eines Videos aufgelistet, welches vom Samsung New PC Studio erzeugt wurde. Dabei wird das Format-Profil MPEG-4 Simple@L3 verwendet. Nach meinem Kenntnisstand ist dafür eine max. Bitrate von 384 (kbit/s) möglich. Das erzeugte Video hat aber eine (variable) Bitrate von 524 (kbit/s für Video) und max. immerhin 1600 (kbit/s). Wie ist dieser Widerspruch zu erklären?

Auch findet laut MediaInfo der H.263 und nicht der H.264 Verwendung, der benötigt relativ betrachtet aber eine höhere Rechenleistung zur späteren Decodierung. Verwendest Du nun den MPEG-4 (H.263)-Codec (ggf. MPEG-4 Advanced Simple Profiles) oder tatsächlich den H.264/AVC-Codec?

Und was mich ganz brennend - auch und vor allem um endlich zum Thema etwas handfestes zu sagen - interessiert:

Welche Einstellungen verwendest Du?

Gerne würde ich auch sehen wollen, was MediaInfo zu Deinen MP4-Videos ausspuckt.

[XtAbIT 0]

MPEG-4 Simple@L3 unterstützt von 10kb/s bis zu 2mb/s

edit: ... und er verwendet den H.264 was du dir auch im obersten Post auf dieser Seite anschauen kannst.

greetz

[DJ-Tumor 47]

Also da ich nicht auf die maximale Akkuleistung achte, wie es offensichtlich das ziel von faziman ist, sondern einfach nur hin und wieder mal einen Film aufs Handy bringen wollen würde, ist unsere Zielsetzung offensichlich eine andere.

Da ich, wie ich schon schrieb, alles nur noch mit H264 codiere dürfte die Frage nach dem verwendeten Codec auch beantwortet sein und die Settings für x264 findeste oben im Screenshot (Anhang).

Wobei ich wie gesagt drauf hinweisen will, das 1,2Mbit Overkill sind.

Ich denke 500-600Kbit sollten gut reichen (maximal 800kbit 100%ig!), ohne das man visuelle Unterschiede sieht, aber in diesen Bitraten Regionen bin ich eigentlich noch nicht unterwegs gewesen

Ich erstelle normaler weise eher BD9/BD5 oder 1/3 DVD große Files aus den BDs/DVDs > H264.

Encoding fürs Handy und damit mehr oder weniger purem Minimalismus müsste ich mich dann erstmal widmen. Daher würde ich dann auch gleich den Hinweis auf zu verwendende Einstellungen bei x264 machen wollen.

Mit Sicht auf die Akkulaufleistung sollte man dann vielleicht eher das Profil wechseln bei x264 und anstatt "faster" "ultrafast" nehmen.

Kurze Erklärung. Hinter diesen Profiles verstecken sich Standart-Einstellungen für die diversen Features und das im Verständnis zu stetig anwachsender Bildqualität. Auf dem kleinen Bildschirm macht alles größer "fast" 100%ig keinen Sinn. Mit zweitem Blick drauf, macht eigentlich auch DAS keinen Sinn, sondern "Very Fast" sollte mindestens verwendet werden. Da es auch eine Hardware-Design Frage ist, könnte aber durchaus das "Very Fast" Profil mehr Standvermögen, denn das "Ultra Fast" Profil abwerfen. Verteufelt mir nicht die Codec Features! Wenn die sauber genutzt werden, sind die mächtig Effizient, was also zu Akkulaufleistungsverlängerung gereichen würde.

Diese gnadenlose Optimierung führt natürlich dazu, das diese Files für nichts anderes, als das Handy geeignet sind. Auf größeren Bildschirmen 10"+ WIRD MAN DEFINITIV Stück für Stück Verschlechterungen im Bild wahrnehmen können.

Sogar die Farbtiefe einzubeziehen haut mich allerdings um. Dazu das hier:

Farbtiefe [bearbeiten]

Die Farbtiefe des Framebuffers definiert die Maximalzahl der gleichzeitig auf dem Bildschirm angezeigten Farben. Die angegebenen Pixelformate geben an, wie viele Bits pro Pixel auf die einzelnen Farbkanäle (rot, grün, blau, alpha) vergeben wird - bei Farbmodi, die Paletten benutzen, fehlt diese Angabe, weil sie keinen Sinn ergibt.

* 1 Bit pro Pixel

o MDA

o zwei Farben

* 2 Bit pro Pixel

o CGA

o vier Farben aus einer Palette mit 16 Farben

* 4 Bit pro Pixel

o EGA

o 16 Farben aus einer Palette mit 64 Farben

* 8 Bit pro Pixel

o VGA

o 256 Farben aus einer Palette mit 262144 Farben

* 15 Bit pro Pixel

o Real Color

o 32768 Farben

o Pixelformat 5-5-5, d. h. 5 Bit pro Farbkanal (also 32 Farbabstufungen pro Kanal)

* 16 Bit pro Pixel

o High Color

o 65536 Farben

o Pixelformat 5-6-5, d. h. 5 Bit für Rot und Blau (32 Farbabstufungen) und 6 Bit für Grün (64 Farbabstufungen)

o alternativ auch 4-4-4-4, d. h. 4 Bit pro Farbkanal (16 Farbabstufungen), wobei die letzten vier Bits entweder ungenutzt sind oder als Alphakanal verwendet werden (s. 32 Bit True Color)

* 24 Bit pro Pixel

o True Color

o 16777216 Farben

o Pixelformat 8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)

* 32 Bit pro Pixel

o True Color

o Pixelformat 8-8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)

o Die gegenüber 24 Bit True Color hinzugekommenen 8 Bit werden normalerweise nicht genutzt; auf Rechnern mit 32-Bit-Architektur ist die Verarbeitung von 32-Bit-Werten aber effizienter als die von 24-Bit-Werten, weil dies genau der Wortbreite des Prozessors entspricht, weswegen trotz des 33% höheren Speicherbedarfs True-Color-Framebuffer meistens 32 Bit Farbtiefe benutzen.

Zum Thema Mpeg4 Profiles:

Technical Specification

MPEG-4 Video Compression

1.

Fully compliant with MPEG-4 ISO/IEC 14496-2

2.

Simple Visual Profile @L0-L3, H.263 (baseline)

3.

Encoded Bit Rates: 10 Kbps to 2 Mbps

4.

Encoded Frame Rates: up to 30 fps

5.

Low processing latency

6.

Modular software architecture

7.

Concurrent MPEG-4 Simple Visual Profile Encoder/Decoder on a single processor

Da steht nix von einer begrenzung auf 384 kbits, sondern bei 2Mbit ist schluss. Das würde bedeuten, das das Samsung-Programm innerhalb der Spezifikationen bleibt. Aber selbst wenn deine Quelle richtig wäre, würde mich das nicht überraschen....wäre nicht das erste Hersteller-Tool, das außerhalb der Spezifikationen arbeiten würde

@ Crisa....den Link im anderen Posting zum Video habe ich einfach gefixt....da ist irgendwie ein Zeichen reingeraden, was den ganzen Link geplättet hat....es war ein "´":icon_redf

@faziman:

@Punkt1+2...NULL AHNUNG...nutze diese Programme nicht

@Punkt3: Das kann eigentlich nicht sein. Das hieße ja, das er zwei mal das gleiche macht und das bleibt halt das Geiche! Sowas kann man eigentlich nirgendswo einstellen, weils halt sinnlos ist, aber ich lass mich da ggf. eines besseren Belehren;)

Bei 2pass-Encoding, encoded der Rechner 2mal gleich, ABER er vergleicht während des 2.Encoding-Prozesses das erzeugte Bild mit dem des aus dem ersten Vorgang erstellen Bildes unverwirft das schlechtere Bild sofort.

===============================================================================

Ich werde gleich mal einfach was bei MTV aufnehmen und dann in 800,700,600,500,400kbit encoden und dann dürft ihr selbst ja entscheiden, obs was ausmacht auf dem Handy.

Hier die Links:

400

500

600

700

800

Ich Depp....für Qualitests ist MTV natürlich ungeeignet. Deswegen habe ich 720p Ursprungsmaterial gewählt, damit es über jeden Zweifel erhaben ist, das es an der Source liegt.

PS: Interessant, das das Samsung auch 24P abspielt:goofy:

bearbeitet February 26, 2010 von DJ-Tumor

[faziman 1]

okay, uff, viele infos zu verdauen;

kurz mal gefragt: h.264 ist der neuere und bessere codec (qualy-mäßig)

aber: (und jetzt bitte ned lachen) welcher von beiden ist jetzt der prozessor-schonendere?

ich denke, der h.263 weil er ja älter ist, oder? kann das JET eig. h.264? (vl FAQs schauen... hm)

und was bewirkt jetzt bei dr divx der regler "gute qualität" oder "ausgewogen"; bzw h.263 vs h.263 optimiert?

erstellt der mir nur schneller die divx-file und dadurch auch weniger "schön"?

oder dauert es gleich lang, qualy schlechter, dafür weniger prozessor-last beim abspielen? (decoden, richtig?)

danke für eure hilfe..

[dieCrisa 0]

alles nur noch mit H264

Gut, aber...

...was soll dann diese Information:

Technical Specification

MPEG-4 Video Compression

Simple Visual Profile @L0-L3, H.263 (baseline)

In welchem Zusammenhang steht nun H.263 wenn Du doch ausschließlich H.264 verwendest? Oder soll das (woher stammt diese Information?) belegen, dass Simple@L3 mehr als 384 kann?

Es wäre echt nett von Dir, mal ein solches Video - lauffähig auf unserem Jet - zum Runterladen zu posten.

Hinter diesen Profiles verstecken sich Standart-Einstellungen für die diversen Features

Und genau diese Einstellungen wüsste ich zu gerne! Ist das so schwer zu verstehen? Würdest Du denn wenigstens das verwendete Level nennen?

Ein Profil "Faster" oder "Ultrafast" mag es für das von Dir verwendete Programm geben - ist aber eben nur programmspezifisch und nicht MPEG-Standard. Genauso wenig sagen Profile "toll" und "supi" etwas über Einstellungen des Encoders aus.

Das Ergebnis von MediaInfo für Deine MP4-Videos ist dann auch zu viel der Mühe? Schade. Schreibst Du doch sonst soviel - nur nicht wirklich das, was von echtem Interesse wäre.

was du dir auch im obersten Post auf dieser Seite anschauen kannst.

Ich kann schon schauen. Auch schaue ich auf andere Dinge...

MPEG-4 Simple@L3 unterstützt von 10kb/s bis zu 2mb/s

z.B. schaue ich hier hin:

https://encodingwissen.de/xvid/technik.html

... und dort sehe ich das nicht bestätigt - sondern das, was ich sagte.

Geschaut habe ich auch hier:

Bei 2pass-Encoding, encoded der Rechner 2mal gleich, ABER er vergleicht während des 2.Encoding-Prozesses das erzeugte Bild mit dem des aus dem ersten Vorgang erstellen Bildes unverwirft das schlechtere Bild sofort.

Das ist nun völliger Unsinn - richtiger wäre das hier: https://encodingwissen.de/codecs/encoding-methoden.html bearbeitet February 26, 2010 von dieCrisa

[DJ-Tumor 47]

1. JA KLAR, kann das Samsung h264, sonst wäre all mein geschreibsel doch absolut fürn "POPO".

2. H.264 ist immer noch Mpeg4, nämlich MPEG4 ASP/AVC.

Und ja er ist neuer und besser als der alte h263.

Ob er mehr Stromverbrauch generiert kann ich nicht sagen, da ich NIE IM LEBEN mit h263 gearbeitet habe, da für nix anderes zu gebrauchen, als diese seltenen Gelegenheiten. Meine Files sollten auf der PS3 abspielbar sein und auch auf so manchem BD-Player, der die Restiktionen nicht bis ins Mark eingetrichtert bekommt per Firmware, wie z.B. mein Pioneer BDP-LX52.

3. Mit dem Regler werden im Hintergrund auch wieder Profile durchgeschalten, wie ich es auch beim H.264 mache. Ergo jedes Profil bringt seine Einstellungen mit sich, die man primär erstmal nicht sieht.

4. Test Video habe ich schon ganz früh gepostet....hattest du doch angeblich gesehen ?!

Ich habe aber nun den Test gemacht und alle Videos hochgeladen.

Damit kannste dir das anschauen und Media-Infoen bis der Arzt kommt.

5. Will ich mal nicht wiedersprechen...faktisch ist es falsch, was ich geschrieben habe, aber in der Regel verstehen die Leute es nur so ohne solche Grafiken.

Also mein eigenes Fazit sieht wie folgt aus:

400Kbit bricht völlig weg, während 800Kbit perfektes Bild bietet.

700Kbit ist nahe perfekt, nur ab und zu ist mal was zu sehen.

Bleiben 500Kbit + 600 Kbit. Hier geht es sich eigentlich nur darum wo beim Betrachter die Schmerzgrenze liegt, was die Fehler im Bild angeht. Während 600Kbit noch die meiste Zeit ein stabiles Bild liefert, vor allem bei ruhigem Bildinhalt, bricht 500Kbit für meinen Geschmack zu oft zu früh weg.

Meine Empfehlung daher was den x264 (h264) Codec angeht:

Mode: ABR

Bitrate: 600Kbit

Preset: Very Fast

Profile: Baseline@3.0

@faziman: bezüglich Akkulaufzeit...wäre das hier nicht interessant für dich? https://cgi.ebay.de/Akku-f-Samsung-S8000-Jet-1200mAh-Li-Polymer_W0QQitemZ400082408658QQcmdZViewItemQQptZHandy_Zubeh%C3%B6r?hash=item5d26c514d2

bearbeitet February 26, 2010 von DJ-Tumor

[dieCrisa 0]

Gut - dann ausführlich - ich wiederhole und ergänze wie folgt:

Es wäre echt nett von Dir, mal ein solches Video - lauffähig auf unserem Jet - zum Runterladen zu posten - und zwar mit diesen Technical Specification:

MPEG-4 Video Compression

1.

Fully compliant with MPEG-4 ISO/IEC 14496-2

2.

Simple Visual Profile @L0-L3, H.263 (baseline)

3.

Encoded Bit Rates: 10 Kbps to 2 Mbps

4.

Encoded Frame Rates: up to 30 fps

5.

Low processing latency

6.

Modular software architecture

7.

Concurrent MPEG-4 Simple Visual Profile Encoder/Decoder on a single processor

(Anmerkung: besonders auf das in Fettschrift kommt es mir an!)

ich es auch beim H.264 mache. Ergo jedes Profil bringt seine Einstellungen mit sich, die man primär erstmal nicht sieht.

Gut, ich nehme auch den sekundären Blick. Aber ich fürchte, da kann ich noch soviel bohren und lästig sein - den bekomme ich einfach nicht.

Da ich gelesen habe, dass 800 kbit/s hundertprozentig ausreichend sind und 1200 kbit/s den OVERKILL bedeuten, kann ja schlecht das MTV-Video (welches weiter oben verlinkt ist) gemeint sein. Denn das hat ja stolze 1218 kbit/s. Oder willst Du mich auf die dumme Art veralbern?

Nun, inzwischen hast Du ja Videos mit <800 hier verlinkt. Auch wenn das nicht auf meinen Wunsch hin geschah (da gab es doch eher eine Verweigerungshaltung oder blöde Anmache), so sage ich dennoch: Danke!

Edit: Die Datei, auf die Sie zugreifen möchten, ist derzeit leider nicht verfügbar.

Schade.

[DJ-Tumor 47]

Du musst einfach mal die Sachen zusammenbringen und endlich aufhören ständig anderen die Missverständnisse und Verständnisfehler unterzuschieben.

So kriegt man mich ganz gewiss langsam aber sicher auf 100%!!!!!

Dieser Test geschah aus freien Stücken und auf strukturierten und kontruktiven Nachfragen von faziman, der zwar scheinbar weniger wissen mitbringt, dafür aber nicht bei jedem Wissen mit irgendeiner wissensdatenbank winkt, die nur halb verstanden wird.

Leider haben sich in der Praxis mehr die DivX-Profile als die aus dem Standard durchgesetzt.

Also...was ist nun mit diesem Profiles was die Mpeg4/ASP Codecs angeht...?

In den Wing geblasen worden und keiner hällt sich dran

estgelegt wird dabei, wie viele Bits der Puffer maximal enthalten darf und welchen Wert die Bitrate maximal erreichen kann. Wenn das entsprechende Profil und Level eingestellt ist, sollte sich Xvid an diese Beschränkungen halten. Leider funktioniert das nicht. Wer VBV benötigt, sollte besser DivX verwenden.

Was steht da? Das sich der bekannteste freie Encoder nen feuchten Kehricht drum kümmert, was da so schön tabellarisch aufgeführt wird.

Und jetz soll ich dir erklären warum irgendeine Datei, die du erstellt hast sich nicht in deine schöne Tabelle einpassen lässt?

Das mal so aus der Hüfte.

Weiter habe ich die Empfehlung 800Kbit NACH DEM ENCODEN des des Videos getroffen und absolut NIRGENDSWO behaupte ich, das das Video auch nur irgendeine Bitrate hat. Das hast da fäschlicherweise angenommen und schiebst es mir nun wieder unter. So geht das wie gesagt nicht!

So bin ich nicht bereit mit dir zu kommunizieren und werde das ggf. auch zur Ignoration ausbauen und dann wohl alleinig mit faziman austauschen.

Weiter schrieb ich, das ich ausschließlich H264 encode und habe später, im Posting 56 deutlich geschrieben, warum ich mich von h263 distanziere und habe auch absolut keine Lust mich mit dem veralteren zeug nochmal auseinander zusetzen. Meine Zeiten mit Xvid sind vorbei. Xvid hat einfach keine Schnitte gegen X264. Mit der zeit wurde x264 obendrein auch noch deutlich schneller als Xvis beim encoden und hat böser weise dabei noch die bessere Bildqualität. Von den technischen Möglichkeiten her sowieso mal abgesehen. Ich meine Xvid ist nur bis 720p spezifiziert. Zu mindest war das damals so, als ich aufhörte mit Xvid.

/EDIT: Das tut mir leid, das die blöden Free-Hoster ständig Dateien offline stellen, was laut eigenen AGB garnicht drin sein soll. Aber was will man machen. Bei meinem kurzen Test waren gerade alle Dateien verfügbar. Könnte sein, das die das über deine IP machen. Versuch mal, dir eine neue zu holen.

Wenns immernoch nicht geht....sag mir einfach WELCHE du nicht laden kannst...dann versuchen wirs mal mit Rapidshare, was aber nach meinen Erfahrungen noch schlimmer ist.

/EDIT:Zum Thema x264, also H264 fällt mir noch ein, das es da noch MeGUI gibt. Ein Super Programm für Leute, die geneigt sind, sich mehr in die Materie einarbeiten zu wollen.

Hier mal ein Link: https://sourceforge.net/projects/megui/

In diesem Forum werden sie geholfen, falls man damit Probleme hat: https://forum.doom9.org/showthread.php?t=96032

bearbeitet February 26, 2010 von DJ-Tumor

[dieCrisa 0]

Och, Mister MP4-Konfom, das ist jetzt kein großer Verlust. Hinterfragt man Behauptungen oder stellt eindeutige Fragen, so gibt es keine oder falsche Antworten oder man wird mit lästigem Halbwissen besudelt.

Das einzige, was ich "lernen" konnte: MP4 ist machbar - aber außerhalb jeder Regel. Und das wird dann MP4-konform genannt.

[DJ-Tumor 47]

@faziman:

Also ich habe es gerade mit Star Trek ausprobiert...650MB kamen da heraus.

VOR dem Muxen! 105MB sind alleine das Audio.

Also ich würde sagen für ein dauerhaft besseres Bild doch eher zu 650Kbit oder 700Kbit zu greifen, wenn der Film viele Action Sequenzen enthält.

Der Anfang sieht einfach schrecklich aus, finde ich.

Gucken kann man das selbstverständlich BESTENS, aber meine Ansprüche sind da einfach höher

[faziman 1]

so, also: wie ich gefragt habe, ob Dr DivX multipass-encoding kann, habe ich zumindest mal gewusst, wofür die 2 durchgänge sind

(ich verstehe ja auch, wie die komprimierung zustande kommt; das bsp mit dem wettermann ist sehr einleuchtend; der hintergrund bleibt bestehen, während sich der mensch bewegt; bis sich die kamera bewegt etc.; und solche dinge werden im 1. durchgang analysiert und für den 2. durchgang dann aufbereitet...)

also 2 durchgänge zahlen sich defintiv aus (mehr sollen den aufwand erhöhen, aber die qualy nur mehr wenig)(ich weiß ja auch in grundzügen, wie bspw ne jpg erzeugt wird... divx ist einfach "in motion" mit ein paar zusatzkniffen)

so, jetzt noch ne allerletzte frage für heute: h.264 zahlt sich für nen dvd-rip (od. ne gute SAT-VCR-Quelle) aus, aber nicht für ein bereits in h.263 bzw. xvid vorliegendes video; könnte man da zustimmen? (ich meine, dass ein bereits verhunztes video nicht mehr aufgebessert werden kann)

und mit dem akku bin ich an sich zufrieden, hersteller-fremde akkus rufen leider in mir ein ungutes gefühl hervor (gibt es eig. originale akkus zu nem vernünftigen preis?) ansonsten: seeeehr witzig; ich weiß, dass ich mit meinen %-rechnerein sehr pingelig und nervig bin (aber es ist mir wuuaaaascht, zu deutsch: egal!)

wärst du bitte noch so frei, und könntest mir nen link zu dem "simple x264 launcher" anbieten? trotz google komme ich da auf keinen grünen zweig (ich find nur erklärungen dazu, aber keinen download!)

ich werd mich dann einfach mal einlesen, was muxen ist (ich nehme an, das verbinden von ner video und ner ton-spur? kommen so die synchronisationsfehler von so manchen xvid/divx-videos her?) und wie das geht...

ciao und gn8 peoplez

und PEACE