Frage von Lutz Frommberger:Hallo,
ich habe einen Haufen Aufnahmen in MPEG2 vorliegen (;DVB-T-Aufnahmen,
demulitplext und geschnitten mit Project X, gemultiplext mit mplex).
Jetzt ist mir das aber alles zu groß, und ich will das in MPEG4
kriegen. Leider habe ich von alledem keine Ahnung, und ich nutze
Linux.
Naiv würde ich jetzt den MPEG2-Film durch mencoder hauen und ein AVI
draus machen:
mencoder -oac copy -ovc lavc -o Output.avi Input.mpeg
Welche Fehler habe ich jetzt dabei gemacht?
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Thomas Beyer:
Lutz Frommberger schrieb:
> Hallo,
>
> ich habe einen Haufen Aufnahmen in MPEG2 vorliegen (;DVB-T-Aufnahmen,
> demulitplext und geschnitten mit Project X, gemultiplext mit mplex).
> Jetzt ist mir das aber alles zu groß, und ich will das in MPEG4
> kriegen. Leider habe ich von alledem keine Ahnung, und ich nutze
> Linux.
>
> Naiv würde ich jetzt den MPEG2-Film durch mencoder hauen und ein AVI
> draus machen:
>
> mencoder -oac copy -ovc lavc -o Output.avi Input.mpeg
Eine guter Einstieg zum Reinlesen in die mencoder Parameter ist:
http://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-vcd-dvd.html
> Welche Fehler habe ich jetzt dabei gemacht?
Definiere "MPEG4". Ich nehme mal an, Du meinst nicht MPEG4 AVC, sondern
etwas XVid-Artiges, was *AVI in deinem Beispiel suggeriert. In dem Falle
würde ich dies als Basis für weitere Versuche verwenden:
mencoder.exe input.mpg -o output.avi -oac copy -ovc xvid -xvidencopts
bitrate 00
Die Bitrate ist für 720p ausreichend, für SDTV würde ich noch ein wenig
runtergehen.
Zum Verwursten beliebiger Videoquellen bis hin zu 1080i MKV zu einem
DVD-kompatiblen MPEG2 PES ist mencoder übrigens auch prima zu
gebrauchen, sogar ansprechend schnell:
(;PAL, zusätzlich wird in diesem Beispiel der Ton in AC3 reenkodiert))
mencoder.exe input.mkv -o output.mpg -oac lavc -ovc lavc -of mpeg -
mpegopts format%dvd:tsaf -vf scaler0:576,harddup -srate 48000 -af
lavcresampleH000 -lavcopts vcodec%mpeg2video:vrc buf size=
1835:vrc maxrate˜00:vbitrateP00:keyint:vstrict=
0:acodec¬3:abitrate"4:aspect/9 -ofps 25
(;NTSC, in dieem Beispiel wird nur der Videopart neuenkodiert, Audio wird
wegen -oac copy nur durchgemuxt)
mencoder.exe input.mkv -o output.mpg -oac copy -ovc lavc -of mpeg -
mpegopts format%dvd:tsaf:telecine -vf scaler0:480,harddup -lavcopts
vcodec%mpeg2video:vrc buf size35:vrc maxrate˜00:vbitrate=
5000:keyint:vstrict0:aspect/9 -ofps 24000/1001
Aber ich bin abgeschweift. Deiner Programmzeile fehlte die Instruktion,
welchen Videoencoder mencoder für AVI verwenden sollte, also schlichtweg
das -ovc xvid -xvidencopts bitrate 00
MfG,
Thomas
Antwort von Lutz Frommberger:
Thomas Beyer
wrote:
> Eine guter Einstieg zum Reinlesen in die mencoder Parameter ist:
> http://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-vcd-dvd.html
Da habe ich schon drin rumgelesen. Erkenntnisgewinn war nicht
ausreichend. :-)
>> Welche Fehler habe ich jetzt dabei gemacht?
>
> Definiere "MPEG4". Ich nehme mal an, Du meinst nicht MPEG4 AVC, sondern
> etwas XVid-Artiges, was *AVI in deinem Beispiel suggeriert.
Ehrlich gesagt, keine Ahnung. Ich dachte wohl schon an AVC, mit
"xvid-artiges" kann ich nichts anfangen. Aber wie gesagt: Ich bin
vollkommen unwissend, ich will nur klein. :-)
> Die Bitrate ist für 720p ausreichend, für SDTV würde ich noch ein wenig
> runtergehen.
Gut zu wissen.
> Aber ich bin abgeschweift. Deiner Programmzeile fehlte die Instruktion,
> welchen Videoencoder mencoder für AVI verwenden sollte, also schlichtweg
> das -ovc xvid -xvidencopts bitrate 00
Ich hatte "-ovc lafc" angegeben, weil mir das sympathisch vorkam. Was ist
and xvid anders/besser?
Und welchen Audio-Codec nimmt man geeigneterweise? "copy" war am Ende
kürzer als alles MP3-encodierte.
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Thomas Beyer:
Lutz Frommberger schrieb:
> Thomas Beyer wrote:
> > Eine guter Einstieg zum Reinlesen in die mencoder Parameter ist:
> > http://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-vcd-dvd.html
>
> Da habe ich schon drin rumgelesen. Erkenntnisgewinn war nicht
> ausreichend. :-)
Na gut, dann speziell zum Thema mencoder und XVid:
http://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-xvid.html
> >> Welche Fehler habe ich jetzt dabei gemacht?
> >
> > Definiere "MPEG4". Ich nehme mal an, Du meinst nicht MPEG4 AVC, sondern
> > etwas XVid-Artiges, was *AVI in deinem Beispiel suggeriert.
>
> Ehrlich gesagt, keine Ahnung. Ich dachte wohl schon an AVC, mit
> "xvid-artiges" kann ich nichts anfangen. Aber wie gesagt: Ich bin
> vollkommen unwissend, ich will nur klein. :-)
Nun, MPEG4 AVC ist das neuste Spiezeug unter uns Videophilen. Allerdings
knechtet das die Hardware auch am meisten beim Enkodieren, sprich: es
ist arschlangsam.
Versuchen wir also bei Xvid-AVI zu bleiben und, bezugnehmend auf deine
Sourcen (;DVB-T, also überwiegend MPEG2-Video 720x576, MPEG1 Audio), ein
brauchbares Profil für mencoder zu erstellen. Gar nicht so schwer, wenn
man oben zitierte Website mal durchliest.
Wenn Du die Auflösung (;720x576) 1:1 beibehalten willst, sind
Videobitraten von mindestens 900kbps zu empfehlen, und dieser Wert ist
schon grenzwertig. In verbindung mit erneuter Audiokomprimierung auf MP3
128kbps und QPEL erreicht man aber schon deutliche
Dateigrößenersparnisse, ohne dass es zu viel Pixelmatsch wird:
mencoder.exe input.mpg -o output.avi -oac mp3lame -ovc xvid -xvidencopts
bitrate0:vhq2:bvhq1:chroma opt:quant type%mpeg -aid 128
... wäre eine Emfehlung zum Einstieg. Du kannst an der Videobitrate
(;Bsp:900) und der Audiobitrate (;Bsp:128) ja gerne noch ein wenig drehen,
bis es Dir paßt. Obiges Beispiel ist IMHO aber schon nahe bei Optimum
für das, was Du da vorhast.
> Ich hatte "-ovc lafc" angegeben, weil mir das sympathisch vorkam. Was ist
> and xvid anders/besser?
Bei Angabe von lafc wird libavccodec genutzt:
http://www.mplayerhq.hu/DOCS/HTML/de/menc-feat-enc-libavcodec.html
Anders im Gegensatz zu den relativ simplen Parametern von xvid ist, das
es für den Einsteiger komplexer wird. Und auch langsamer wegen des
Overheads.
> Und welchen Audio-Codec nimmt man geeigneterweise? "copy" war am Ende
> kürzer als alles MP3-encodierte.
Mit "-oac mp3lame -aid 128" wird der Audiostream Du auf jeden Fall
kürzer als im original, das 128kbps MP3 immer kleiner sein wird als das,
was bei DVB-Streams verwendet wird (;normal: AC3 448kbps oder MPEG1 LII
192kbps)
MfG,
Thomas
Antwort von Thomas Beyer:
Thomas Beyer schrieb:
> mencoder.exe input.mpg -o output.avi -oac mp3lame -ovc xvid -xvidencopts
> bitrate0:vhq2:bvhq1:chroma opt:quant type%mpeg -aid 128
^^^^^^^^
Das ist falsch. Die Bitrate der Audioenkodierung bei -oac mp3lame wird
nicht mit -aid 128 festgelegt, sondern so: -lameopts abr:br8
Obiges Beispiel ändert sich also in:
mencoder.exe input.mpg -o output.avi -oac mp3lame -ovc xvid -xvidencopts
bitrate0:vhq2:bvhq1:chroma opt:quant type%mpeg -lameopts abr:br8
> > Und welchen Audio-Codec nimmt man geeigneterweise? "copy" war am Ende
> > kürzer als alles MP3-encodierte.
Bei der Gelegenheit auch gleich die Schreibfehler hier korrigiert:
> Mit -lameopts abr:br8" wird der Audiostream auf jeden Fall
> kürzer als der des Originals, da 128kbps MP3 immer kleiner sein wird als das,
> was bei DVB-Streams verwendet wird.
Zum Spielen mit "richtigem" H.264 (;MPEG4-AVC) können wir auch gerne
kommen. Vielleicht gibts Deine CPU ja her :)
MfG,
Thomas
Antwort von Mirko Schuller:
Am Mon, 10 Mar 2008 23:31:01 0000 (;UTC) schrieb Lutz Frommberger:
> Welche Fehler habe ich jetzt dabei gemacht?
Linux zu verwenden. Woanders gibt es zig Programme, die das einfachst
können ...
Antwort von Lutz Frommberger:
Thomas Beyer wrote:
> Nun, MPEG4 AVC ist das neuste Spiezeug unter uns Videophilen. Allerdings
> knechtet das die Hardware auch am meisten beim Enkodieren, sprich: es
> ist arschlangsam.
Das schreckt mich jetzt nicht unbedingt. Ich muss es ja nicht selbst
ausrechnen und Rechenleistung steht überall ungenutzt herum. Natürlich
sollte das Ergebnis den Stromverbrauch irgendwie rechtfertigen. :-)
> Wenn Du die Auflösung (;720x576) 1:1 beibehalten willst, sind
> Videobitraten von mindestens 900kbps zu empfehlen, und dieser Wert ist
> schon grenzwertig. In verbindung mit erneuter Audiokomprimierung auf MP3
> 128kbps und QPEL erreicht man aber schon deutliche
> Dateigrößenersparnisse, ohne dass es zu viel Pixelmatsch wird:
Ich möchte eigentlich möglichst wenig Qualitätsverlust sehen - das
Quellmaterial ist ja schon mäßig genug, dennoch werfe ich es gerne
per Beamer an die Wand. Was wäre denn ein Wert für "maximall sinnvoll"?
Wie sinnvoll QPEL ist, kann ich nicht einschätzen - das beeinflusst doch
auch den Abspieler, richtig?
> ... wäre eine Emfehlung zum Einstieg. Du kannst an der Videobitrate
> (;Bsp:900) und der Audiobitrate (;Bsp:128) ja gerne noch ein wenig drehen,
> bis es Dir paßt. Obiges Beispiel ist IMHO aber schon nahe bei Optimum
> für das, was Du da vorhast.
Audiobitrate kann man ja für aktuelle Filme bei 192 belassen. Was spricht
gegen vhq4? Encodierzeit ist wie gesagt zweitrangig.
> Anders im Gegensatz zu den relativ simplen Parametern von xvid ist, das
> es für den Einsteiger komplexer wird. Und auch langsamer wegen des
> Overheads.
Es ist komplexer und langsamer. Hat es auch Vorteile? :-)
> Mit "-oac mp3lame -aid 128" wird der Audiostream Du auf jeden Fall
> kürzer als im original, das 128kbps MP3 immer kleiner sein wird als das,
> was bei DVB-Streams verwendet wird (;normal: AC3 448kbps oder MPEG1 LII
> 192kbps)
Sollte man meinen, war aber nicht so. Ich hatte Audio auf 96kbps
runtercodiert, und der Ergebnisfilm (;5 min) war ein paar hundert
kB länger als bei "copy". Ich habe mir das mal mit Overhead zu erklären
versucht...
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Lutz Frommberger:
Mirko Schuller wrote:
> Am Mon, 10 Mar 2008 23:31:01 0000 (;UTC) schrieb Lutz Frommberger:
>
>> Welche Fehler habe ich jetzt dabei gemacht?
>
> Linux zu verwenden. Woanders gibt es zig Programme, die das einfachst
> können ...
Ich glaube eher nicht, dass ein anderes OS mir das Einstellen der
Parameter abnimmt. :-)
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Lutz Frommberger:
Konrad Wilhelm wrote:
> Ich liebe Unix! Es ist alles so einfach und selbsterklärend.
>
> (;Feht da oben nicht noch -Ss -Pf (;oder war es -pF?)
>
> Ich hättte nicht gedacht, dass das bei Linux alles immer noch so schön
> ist.
Das Schöne daran ist, dass man sich gegenseitig weiterhelfen kann.
Ich bin damit überfordert, den passenden Codec auszuwählen, du bist
damit überfordert, ihn einzutippen. :-)
Die Sache soll batchgesteuert im Hintergrund über die Bühne gehen.
Da hilft mir eine hübsche GUI nicht weiter, abgesehen davon, dass
die Auswahl der Einstellungen auch im Jahr 2008 noch dem Benutzer
überlassen bleibt. Das prangere auch ich an, aber es hilft ja nix.
:-)
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Thomas Beyer:
Konrad Wilhelm schrieb:
> On Mon, 10 Mar 2008 23:31:01 0000 (;UTC), Lutz Frommberger
> wrote:
>
> >mencoder -oac copy -ovc lavc -o Output.avi Input.mpeg
>
> Ich liebe Unix! Es ist alles so einfach und selbsterklärend.
Ich nutze mencoder auch unter Windows. Im Total Commander. Einfach ein
paar Videodateien markieren, im Menü das gewünschte Zielformat auswählen
(;Bsp: FLV zu DVD), fertig.
> (;Feht da oben nicht noch -Ss -Pf (;oder war es -pF?)
>
> Ich hättte nicht gedacht, dass das bei Linux alles immer noch so schön
> ist.
Unter Windows verpackt man Mencoder unter so "tolle" Oberflächen wie
SUPER und läßt dessen Installation die Directshowarchitektur des
Betriebssystems schrotten. Nein Danke, dann lieber doch Kommandozeile.
Das geht schneller, hat mehr Optionen und ist vielseitiger.
Antwort von Thomas Beyer:
Lutz Frommberger schrieb:
> Thomas Beyer wrote:
> > Nun, MPEG4 AVC ist das neuste Spiezeug unter uns Videophilen. Allerdings
> > knechtet das die Hardware auch am meisten beim Enkodieren, sprich: es
> > ist arschlangsam.
>
> Das schreckt mich jetzt nicht unbedingt. Ich muss es ja nicht selbst
> ausrechnen und Rechenleistung steht überall ungenutzt herum. Natürlich
> sollte das Ergebnis den Stromverbrauch irgendwie rechtfertigen. :-)
MPEG4-AVC gehört IMHO die Zukunft. HDTV über DVB nutzt es (;High Profile
Level 4), man kann auf dem PC damit schon etwas anfangen (;TSRemux,
Mencoder ...), und es ist standardisiert (;TU-T H.264 sowie ISO/IEC
14496-10).
Ich sehe derzeit dieselben Nachteile, welche es Mitte der 90er beim
Durchmarsch von MPEG2 (;DVD) gab:
- Software zum Enkodieren/Abspielen/Bearbeiten in den Kinderschuhen
- derzeitige Hardware seltenst performant genug (;CPU, GPU)
- Abspielmöglichkeiten jenseits des Computers noch arg eingeschränkt
(;kaum Player und wenn, dann teuer)
Dazu kommt - computerspezifisch - wieder ein Sumpf auf Containern auf
uns zu. Die Filesharerszene verpackt H.264 derzeit gerne in MKV, es gibt
mittlerweile auch AVI Container, DVB-Karten speichern es gerne als
Transportstream, stemmen es aber manchmal auch als Programmstream auf
die heimische Platte.
Das Resultat sind Probleme. ATI/AMDs derzeitige GPUs, welche in der Lage
sind H.264 hardwarebeschleunigt abzuspielen, erkennen bspw. H.264 im MKV
Container nicht zuverlässig mit dem Resultat, das die CPU wieder auf
Anschlag arbeitet. Derzeitige Demuxer verschlucken sich oft bei
exotischen Streams.
> > Wenn Du die Auflösung (;720x576) 1:1 beibehalten willst, sind
> > Videobitraten von mindestens 900kbps zu empfehlen, und dieser Wert ist
> > schon grenzwertig. In verbindung mit erneuter Audiokomprimierung auf MP3
> > 128kbps und QPEL erreicht man aber schon deutliche
> > Dateigrößenersparnisse, ohne dass es zu viel Pixelmatsch wird:
>
> Ich möchte eigentlich möglichst wenig Qualitätsverlust sehen - das
> Quellmaterial ist ja schon mäßig genug, dennoch werfe ich es gerne
> per Beamer an die Wand. Was wäre denn ein Wert für "maximall sinnvoll"?
Da die Sourcen (;DVB-T) eine bekannte Größe sind, welche Du kleiner
komprimieren möchtest, ohne sichtbar Qualität zu verlieren:
Typisches DVB-T ist
- Video MPEG-2, ~2000kbps
- Audio MPEG-1, ~192kbps
Egal, welches Format Du nun wählst (;MPEG2, MPEG4 AVS, MPEG4 AVC ...), Du
mußt die Bitrate reduzieren um eine Dateiverkleinerung herbeizuführen,
also unter diesen Werten liegen. Um die damit einhergehende
Qualitätseinbuße im Rahmen zu halten, muß der Algorithmus effizient
sein. Es hat also wenig Sinn, MPEG2 zu MPEG2 einzusetzen.
> Wie sinnvoll QPEL ist, kann ich nicht einschätzen - das beeinflusst doch
> auch den Abspieler, richtig?
Verbreitete Chipsätze von Standalones (;HDD-Videospieler, DVD-Player)
sind oftmals nicht in der Lage mit QPEL umzugehen. Bestenfalls
ignorieren sie es und spielen qualitätsreduziert ab, oftmals geraten sie
bei Abspielen ins Schleudern. Setzt Du Sachen wie QPEL ein mußt Du
ausprobieren, ob Deine Wiedergabekette damit klarkommt. Und zusätzlich
abwägen, ob evt. zukünftig Probleme auftreten önnten (;spielt das mein
nächster Player noch ab, meckert mich mein Bruder bei Videoabenden an,
das sein Player damit nichts anfangen kann ...)
> > ... wäre eine Emfehlung zum Einstieg. Du kannst an der Videobitrate
> > (;Bsp:900) und der Audiobitrate (;Bsp:128) ja gerne noch ein wenig drehen,
> > bis es Dir paßt. Obiges Beispiel ist IMHO aber schon nahe bei Optimum
> > für das, was Du da vorhast.
>
> Audiobitrate kann man ja für aktuelle Filme bei 192 belassen. Was spricht
> gegen vhq4? Encodierzeit ist wie gesagt zweitrangig.
Na dann, nutz es :-)
> > Mit "-oac mp3lame -aid 128" wird der Audiostream Du auf jeden Fall
> > kürzer als im original, das 128kbps MP3 immer kleiner sein wird als das,
> > was bei DVB-Streams verwendet wird (;normal: AC3 448kbps oder MPEG1 LII
> > 192kbps)
>
> Sollte man meinen, war aber nicht so. Ich hatte Audio auf 96kbps
> runtercodiert, und der Ergebnisfilm (;5 min) war ein paar hundert
> kB länger als bei "copy". Ich habe mir das mal mit Overhead zu erklären
> versucht...
Ja, ich hatte das falsche Flag zum Setzen der MP3 Bitrate gepostet. Nimm
statt -aid 128: -lameopts abr:br8
MfG,
Thomas
Antwort von Lutz Frommberger:
Thomas Beyer wrote:
> MPEG4-AVC gehört IMHO die Zukunft. HDTV über DVB nutzt es (;High Profile
> Level 4), man kann auf dem PC damit schon etwas anfangen (;TSRemux,
> Mencoder ...), und es ist standardisiert (;TU-T H.264 sowie ISO/IEC
> 14496-10).
>
> Ich sehe derzeit dieselben Nachteile, welche es Mitte der 90er beim
> Durchmarsch von MPEG2 (;DVD) gab:
Gut. Die Probleme leuchten ein, was sind die (;sichtbaren) Vorteile?
Klingt jetzt wirklich nicht so, als müsste man das unbedingt haben -
es wäre ja auch schön, wenn ein Laptop sowas spielen könnte, ohne
sich totzulüften.
> Da die Sourcen (;DVB-T) eine bekannte Größe sind, welche Du kleiner
> komprimieren möchtest, ohne sichtbar Qualität zu verlieren:
>
> Typisches DVB-T ist
>
> - Video MPEG-2, ~2000kbps
> - Audio MPEG-1, ~192kbps
>
> Egal, welches Format Du nun wählst (;MPEG2, MPEG4 AVS, MPEG4 AVC ...), Du
> mußt die Bitrate reduzieren um eine Dateiverkleinerung herbeizuführen,
> also unter diesen Werten liegen. Um die damit einhergehende
> Qualitätseinbuße im Rahmen zu halten, muß der Algorithmus effizient
> sein. Es hat also wenig Sinn, MPEG2 zu MPEG2 einzusetzen.
900 wird offenbar gerne empfohlen. Aber sieht man einen Unterschied zu,
was weiß ich, 1200?
>> Wie sinnvoll QPEL ist, kann ich nicht einschätzen - das beeinflusst doch
>> auch den Abspieler, richtig?
>
> Verbreitete Chipsätze von Standalones (;HDD-Videospieler, DVD-Player)
> sind oftmals nicht in der Lage mit QPEL umzugehen. Bestenfalls
> ignorieren sie es und spielen qualitätsreduziert ab, oftmals geraten sie
> bei Abspielen ins Schleudern. Setzt Du Sachen wie QPEL ein mußt Du
> ausprobieren, ob Deine Wiedergabekette damit klarkommt. Und zusätzlich
> abwägen, ob evt. zukünftig Probleme auftreten önnten (;spielt das mein
> nächster Player noch ab, meckert mich mein Bruder bei Videoabenden an,
> das sein Player damit nichts anfangen kann ...)
Kaffeesatzlesen... :-/
>> Sollte man meinen, war aber nicht so. Ich hatte Audio auf 96kbps
>> runtercodiert, und der Ergebnisfilm (;5 min) war ein paar hundert
>> kB länger als bei "copy". Ich habe mir das mal mit Overhead zu erklären
>> versucht...
>
> Ja, ich hatte das falsche Flag zum Setzen der MP3 Bitrate gepostet. Nimm
> statt -aid 128: -lameopts abr:br8
Daran lag es nicht, das war bei meinen Tests vor Verfassen des gestrigen
Postings so. Aber vielleicht habe ich mich da auch vertippt...
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Mirko Schuller:
Am Tue, 11 Mar 2008 08:53:27 0000 (;UTC) schrieb Lutz Frommberger:
>> Linux zu verwenden. Woanders gibt es zig Programme, die das einfachst
>> können ...
>
> Ich glaube eher nicht, dass ein anderes OS mir das Einstellen der
> Parameter abnimmt. :-)
Die Kommandozeilen aber doch schon, und darum ging es doch schliesslich ...
Antwort von Thomas Beyer:
Mirko Schuller schrieb:
> Am Tue, 11 Mar 2008 08:53:27 0000 (;UTC) schrieb Lutz Frommberger:
>
> >> Linux zu verwenden. Woanders gibt es zig Programme, die das einfachst
> >> können ...
> >
> > Ich glaube eher nicht, dass ein anderes OS mir das Einstellen der
> > Parameter abnimmt. :-)
>
> Die Kommandozeilen aber doch schon, und darum ging es doch schliesslich ...
Ein GUI erspart Tippfehler, aber nicht das Denken. Jedem nach seiner
Fasson. Blindwütiges Wadenbeissen von Leuten, die schon bei der bloßen
Einsicht in eine Zeile Parameter Aversionen kriegen traue ich irgendwie
nicht zu, das sie in einem GUI einen Encoder parametrisieren können.
Antwort von Heiko Nocon:
Mirko Schuller wrote:
>Die Kommandozeilen aber doch schon, und darum ging es doch schliesslich ...
Nicht wirklich. Weil: Letztlich macht es keinen großen Unterschied, ob
man Parameter per Kommandozeile festlegt oder das per GUI tut. Man spart
die Eingabe des Parameternamens, das ist alles.
Wenn allerdings die Ausgabe der Hilfe auf der Console so verbrecherisch
bescheuert gelöst ist wie etwa bei VLC, dann wird der Vorteil eines GUI
wirklich substantiell. Es kann und darf nicht sein, daß die die
nutzbringende Anwendung der Hilfefunktion tiefere Kenntnisse der
jeweiligen Textshell erfordert. Sowas ist echt pervers.
Anyway, der springende Punkt ist aber eigentlich: Ob GUI oder Console,
wenn man nicht weiß, was man da eigentlich tut, wird am Ende nur Müll
rauskommen. Und GUIs, die fünf Sechstel der Konfigurationsmöglichkeiten
verstecken, produzieren auch nur Müll. Ob sie nun "Super" oder "AutoGK"
oder sonstwie heißen. Alles nur Müll.
Antwort von Lutz Frommberger:
Mirko Schuller wrote:
> Die Kommandozeilen aber doch schon, und darum ging es doch schliesslich ...
Nein. Mir hilft auch eine GUI nicht weiter, wenn ich nicht weiß, welche
Bitrate sich anbietet. Ich habe hier gefragt, weil ich inhaltliche
Lücken habe, nicht, weil ich nicht weiß, wie man Programme bedient.
GUIs sind toll, und wenn vorhanden, nutze ich sie meist. Vor allem
erlauben sie es, ein Programm auch sporadisch zu nutzen, ohne stets
vorher die Doku neu lesen zu müssen (;bei allem Respekt, die Optionen
kann ich mir nicht über Monate merken, und sie sind auch nicht trivial
aus den Manpages zu entnehmen). GUIs sind auch nicht zwangsläufig
limitiert. Dennoch habe ich keine Berührungsängste zur Kommandozeile, im
Gegenteil erlaubt sie mir die Batch-Ausführung im Hintergrund - ein
substanzieller Vorteil, so dass ich in diesem Fall stets ein CLI-Tool
einem GUI-Tool vorziehen würde.
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Antwort von Thomas Beyer:
Lutz Frommberger schrieb:
> > MPEG4-AVC gehört IMHO die Zukunft. HDTV über DVB nutzt es (;High Profile
> > Level 4), man kann auf dem PC damit schon etwas anfangen (;TSRemux,
> > Mencoder ...), und es ist standardisiert (;TU-T H.264 sowie ISO/IEC
> > 14496-10).
> >
> > Ich sehe derzeit dieselben Nachteile, welche es Mitte der 90er beim
> > Durchmarsch von MPEG2 (;DVD) gab:
>
> Gut. Die Probleme leuchten ein, was sind die (;sichtbaren) Vorteile?
MPEG-4/AVC stellt zur Zeit den effizientesten
Videokomprimierungsstandard dar. Je nach zum Einsatz kommendem Profil
ist der Rechenaufwand zur De- und Enkodierung gegenüber MPEG-2
allerdings immens.
Die versprochene 1/3 Reduktion im Vergleich zum etablierten MPEG-2
erreicht man halt nicht zum Nulltarif, sondern u.a. mit komplexerer
Entropiekodierung, verfeinerter Macroblock Partioning und verbesserter
Bewegungskompensation.
> Klingt jetzt wirklich nicht so, als müsste man das unbedingt haben -
> es wäre ja auch schön, wenn ein Laptop sowas spielen könnte, ohne
> sich totzulüften.
Das ist gegenwärtig das Hauptproblem. Die Wiedergabe von MPEG-4/AVC in
fernsehkompatibler Größe (;also ab 720x576 und Level 3aufwärts) erfordert
entweder eine hochpotente CPU (;selbst ein Pentium 4 mit 3GHz ist da
schon überfordert), oder man setzt dafür spezielle Dekodereinheiten
(;Avivo HD, Purevideo HD) in den GPU (;den Grafikchips) ein.
Wobei das auch wieder Augenwischerei ist. Nehmen wir mal an, die CPU-
belastung eines CoreDuo Prozessors sinkt beim Abspielen eines 1080p
Streams von 90% auf 5%, weil nun die GPU dekodiert. Sieht erst mal
ansprechend für den Nutzer aus.
Allerdings wird dabei in keinster Weise weniger Strom vebraucht. Die CPU
verbrät dabei bei mir ~50W weniger Strom, dafür gönnt sich sofort meine
ATI 2600 Grafikkarte statt 14W (;idle) 85W (;!).
Auf das Notebook assoziiert mache sich jeder selbst seine Gedanken zu
Hitzeentwicklung, Akkulaufzeit und Stromverbrauch.
> > Egal, welches Format Du nun wählst (;MPEG2, MPEG4 AVS, MPEG4 AVC ...), Du
> > mußt die Bitrate reduzieren um eine Dateiverkleinerung herbeizuführen,
> > also unter diesen Werten liegen. Um die damit einhergehende
> > Qualitätseinbuße im Rahmen zu halten, muß der Algorithmus effizient
> > sein. Es hat also wenig Sinn, MPEG2 zu MPEG2 einzusetzen.
>
> 900 wird offenbar gerne empfohlen. Aber sieht man einen Unterschied zu,
> was weiß ich, 1200?
Sei kreativ, enkodiere mal ein paar Sekunden kritisches Bildmaterial
(;hoher Anteil dunkler Bildanteil, viel Bewegung im Bild, vielleicht
sogar noch Rauschstörungen drin - das sind die drei
Bitrateneminimierungskiller), begutachte visuell, gehe solange mit der
Bitrate runter, bis Deine Schmerzgrenze überschritten wurde.
Es gibt KEIN Patentrezept mit den "garantiert optimalen, immer zu
empfehlenden ulatimativen Einstellungen"
> >> Wie sinnvoll QPEL ist, kann ich nicht einschätzen - das beeinflusst doch
> >> auch den Abspieler, richtig?
> >
> > Verbreitete Chipsätze von Standalones (;HDD-Videospieler, DVD-Player)
> > sind oftmals nicht in der Lage mit QPEL umzugehen. Bestenfalls
> > ignorieren sie es und spielen qualitätsreduziert ab, oftmals geraten sie
> > bei Abspielen ins Schleudern. Setzt Du Sachen wie QPEL ein mußt Du
> > ausprobieren, ob Deine Wiedergabekette damit klarkommt. Und zusätzlich
> > abwägen, ob evt. zukünftig Probleme auftreten önnten (;spielt das mein
> > nächster Player noch ab, meckert mich mein Bruder bei Videoabenden an,
> > das sein Player damit nichts anfangen kann ...)
>
> Kaffeesatzlesen... :-/
Nein. Man muß sich nur der Problematik bewußt sein und dann entscheiden,
ob man das einsetzen will oder nicht. Zyniker wie ich halten sich eh nur
noch an Standards, die länger als 5 Jahre existieren, und für die es auf
absehbar längere Zeit Abspielgeräte gibt. Merke: Das gilt auch für
Computer. Schon mal versucht, eine alte 5 1/4 Zoll C64 Disk von 1991 mit
damals wichtigen Daten auf ein aktuelles System zu migrieren?
> >> Sollte man meinen, war aber nicht so. Ich hatte Audio auf 96kbps
> >> runtercodiert, und der Ergebnisfilm (;5 min) war ein paar hundert
> >> kB länger als bei "copy". Ich habe mir das mal mit Overhead zu erklären
> >> versucht...
> >
> > Ja, ich hatte das falsche Flag zum Setzen der MP3 Bitrate gepostet. Nimm
> > statt -aid 128: -lameopts abr:br8
>
> Daran lag es nicht, das war bei meinen Tests vor Verfassen des gestrigen
> Postings so. Aber vielleicht habe ich mich da auch vertippt...
Anders ist das gar nicht erklärbar, den 128kbps MUSS kleiner ausfallen
als 192kbps. Tippfehler, fehlerhaftes Programm, oder falscher Parameter.
Ich tippe auf VBR statt ABR.
MfG,
Thomas
Antwort von Jörg Tewes:
Heiko Nocon schrub...
[Commandline vs GUI]
> Nicht wirklich. Weil: Letztlich macht es keinen großen Unterschied,
> ob man Parameter per Kommandozeile festlegt oder das per GUI tut.
> Man spart die Eingabe des Parameternamens, das ist alles.
Nein, ein gutes GUI spart nicht nur die Eingabe, sondern auch das
merken der Parameter. Sichelrich weiß man bei excesiver Benutzung
irgendwann alle Parameter, oder hat die die man braucht auswendig
gelernt, aber für einen der eher unregelmäßig ein Programm benutzt,
hat da bei Commandline Programmen eher Probleme. Es sei denn er
schreibt sich ein Script für jeden Furz. Bei einem GUI macht er einmal
seine präferierten Einstellung und hat immer die gleiche Qualität, bei
gleichem Ausgangsmaterial. Das ein GUI einen nicht davon erlöst zu
wissen was man tut, ist selbstverständlich. Dss ein schlechtes GUI
nicht besser sein kann als die Commandline auch.
Und Tschüss Jörg
--
"There's only one truth about war: people die. Killing is part of a
soldier's job. We can't deny it. We can only live with it and hope
the reasons for doing it are justified."
(;Sheridan, "GROPOS")
Antwort von Lutz Frommberger:
Thomas Beyer wrote:
> Es gibt KEIN Patentrezept mit den "garantiert optimalen, immer zu
> empfehlenden ulatimativen Einstellungen"
Ich habe die Erfahrung gemacht, dass ich selbst nicht sonderlich gut
als Benchmark tauge. Wenn ich verlustbehaftet encodiere, sehe ich überall
Klötzchen und höre stets Artefakte. Blindtests ergeben, wenn überhaupt,
nur gute Ergebnisse, solange es blind ist, danach sehe ich dann
Unterschiede. Außerdem neige ich zum Hadern ob stets wahrscheinlich
falscher Entscheidungen. Insofern beruhigt mich eine externe Empfehlung
der Art "meist eine gute Wahl" i.A. sehr - dann hat man eine Basis zum
Weiterprobieren.
Ich testsehe gerade mit den von dir empfohlenen Parametern, was aber
angesichts des lausigen Ausgangsmaterials recht undankbar ist.
Vergleichssehen ist kaum machbar, und schlecht ist das Bild ja vorher
schon gewesen.
> Nein. Man muß sich nur der Problematik bewußt sein und dann entscheiden,
> ob man das einsetzen will oder nicht. Zyniker wie ich halten sich eh nur
> noch an Standards, die länger als 5 Jahre existieren, und für die es auf
> absehbar längere Zeit Abspielgeräte gibt. Merke: Das gilt auch für
> Computer. Schon mal versucht, eine alte 5 1/4 Zoll C64 Disk von 1991 mit
> damals wichtigen Daten auf ein aktuelles System zu migrieren?
QPEL habe ich erstmal abgeschrieben. Der Qualitätsgewinn (;den ich bislang
nirgends sehen konnte) rechtfertigt m.E. die Risiken derzeit nicht.
>> Daran lag es nicht, das war bei meinen Tests vor Verfassen des gestrigen
>> Postings so. Aber vielleicht habe ich mich da auch vertippt...
>
> Anders ist das gar nicht erklärbar, den 128kbps MUSS kleiner ausfallen
> als 192kbps. Tippfehler, fehlerhaftes Programm, oder falscher Parameter.
> Ich tippe auf VBR statt ABR.
Habe ich gestern erfolglos versucht zu reproduzieren - wäre ja auch sehr
eigenartig gewesen. Wo ich mich vertippt habe, lässt Raum für Spekulationen.
Geht VBR im Zusammenspiel mit Film überhaupt?
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
