Infoseite // Hollywood+ als Videoausgabekarte fuer mplayer

Frage von Carla Schneider:


Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
damit es geht ?

--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
> Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
> auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
> Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
> aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
> damit es geht ?

Einen schnelleren Rechner vielleicht?

Gruß,
Alan

PS: Du plenkst .

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede




Antwort von Carla Schneider:

Alan Tiedemann wrote:
>
> Carla Schneider schrieb:
> > Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
> > auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
> > Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
> > aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
> > damit es geht ?
>
> Einen schnelleren Rechner vielleicht?

Natuerlich - die frage geht ja dahin wie schnell . Reicht ein Athlon XP 2500
oder braucht man irgendwas sehr teures


--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
> Alan Tiedemann wrote:
>> Carla Schneider schrieb:
>>> Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
>>> auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
>>> Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
>>> aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
>>> damit es geht ?
>>
>> Einen schnelleren Rechner vielleicht?
>
> Natuerlich - die frage geht ja dahin wie schnell . Reicht ein Athlon XP 2500
> oder braucht man irgendwas sehr teures

Der sollte für MJPEG und DV locker reichen. Achtung: Auch die
Festplatte(;n) müssen schnell genug sein!

Außerdem plenkst Du immer noch.

Gruß,
Alan

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede




Antwort von Carla Schneider:

Alan Tiedemann wrote:
>
> Carla Schneider schrieb:
> > Alan Tiedemann wrote:
> >> Carla Schneider schrieb:
> >>> Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
> >>> auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
> >>> Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
> >>> aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
> >>> damit es geht ?
> >>
> >> Einen schnelleren Rechner vielleicht?
> >
> > Natuerlich - die frage geht ja dahin wie schnell . Reicht ein Athlon XP 2500
> > oder braucht man irgendwas sehr teures
>
> Der sollte für MJPEG und DV locker reichen. Achtung: Auch die
> Festplatte(;n) müssen schnell genug sein!

Das ist nicht das Problem wenn ich es auf dem Computerbildschirm abspiele ist
schon mein Computer schnell genug
Wofuer die Leistung nicht ausreicht
ist die Umsetzung in ein Format das die Hollywood Karte versteht
Wenn das richtiges mpeg2 ist stellt sich schon die Frage wie das zu schaffen sein soll

--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
> Alan Tiedemann wrote:
>> Der sollte für MJPEG und DV locker reichen. Achtung: Auch die
>> Festplatte(;n) müssen schnell genug sein!
>
> Das ist nicht das Problem wenn ich es auf dem Computerbildschirm abspiele ist
> schon mein Computer schnell genug

Okay, hätte ja sein können. Immerhin haben MJPEG und DV-AVI *sehr* hohe
Datenraten, so daß es durchaus an der Plattenleistung scheitern könnte.

> Wofuer die Leistung nicht ausreicht
> ist die Umsetzung in ein Format das die Hollywood Karte versteht
> Wenn das richtiges mpeg2 ist stellt sich schon die Frage wie das zu schaffen sein soll

Mit einer schnellen CPU halt. Da Dein PC mit DivX -> MPG2 keine Probleme
zu haben scheint, krankt es offenbar an der schieren Datenmenge. Und da
hilft eine schnellere CPU durchaus weiter. Nur muß dazu eben auch der
Rest des Systems mitspielen. UDMA33-Platten und PC133-SDR-SDRAM reißen
bei einem 2500 nicht unbedingt Bäume aus, da muß es dann schon eine
fixe aktuelle Platte und tunlichst 333er DDR-SDRAM sein.

Gruß,
Alan

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede




Antwort von Michael Mauch:

Carla Schneider wrote:

> Das ist nicht das Problem wenn ich es auf dem Computerbildschirm abspiele ist
> schon mein Computer schnell genug
> Wofuer die Leistung nicht ausreicht
> ist die Umsetzung in ein Format das die Hollywood Karte versteht
> Wenn das richtiges mpeg2 ist stellt sich schon die Frage wie das zu schaffen sein soll

Mein Athlon 700 spielt DivX mit 352x??? einigermassen erträglich über
eine DVB-S-Karte (;FF), die auch nur MPEG2 verträgt.

2,4 GHz sollten also IMHO auch für volle Auflösung ausreichen.

Michael




Antwort von Carla Schneider:

Alan Tiedemann wrote:
>
> Carla Schneider schrieb:
> > Alan Tiedemann wrote:
> >> Der sollte für MJPEG und DV locker reichen. Achtung: Auch die
> >> Festplatte(;n) müssen schnell genug sein!
> >
> > Das ist nicht das Problem wenn ich es auf dem Computerbildschirm abspiele ist
> > schon mein Computer schnell genug
>
> Okay, hätte ja sein können. Immerhin haben MJPEG und DV-AVI *sehr* hohe
> Datenraten, so daß es durchaus an der Plattenleistung scheitern könnte.
>
> > Wofuer die Leistung nicht ausreicht
> > ist die Umsetzung in ein Format das die Hollywood Karte versteht
> > Wenn das richtiges mpeg2 ist stellt sich schon die Frage wie das zu schaffen sein soll
>
> Mit einer schnellen CPU halt. Da Dein PC mit DivX -> MPG2 keine Probleme
> zu haben scheint, krankt es offenbar an der schieren Datenmenge.

Wenn ich allerdings mit transcode und mjpegtools MJPEG auf MPEG2 umsetzte
komme ich nur auf etwa 2 Bilder/Sekunde. Da fehlt also mehr als ein Faktor 10.
Das ganze kann also nur dann funktionieren wenn der Umsetzer in mplayer entsprechend
effizienter arbeitet.

> Und da
> hilft eine schnellere CPU durchaus weiter. Nur muß dazu eben auch der
> Rest des Systems mitspielen. UDMA33-Platten und PC133-SDR-SDRAM reißen
> bei einem 2500 nicht unbedingt Bäume aus, da muß es dann schon eine
> fixe aktuelle Platte und tunlichst 333er DDR-SDRAM sein.
Wenn die Platte die MJPEG Datenrate von etwa 3Mbyte/sec schafft muesste das reichen.
Aber eine 2500 CPU ist doch nicht mal 4 mal schneller als die 700Mhz CPU,
oder ist SSE soviel schneller als "3D Now" um da nochmal wesentlich was drauf
zu legen ?


--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
> Alan Tiedemann wrote:
>> Mit einer schnellen CPU halt. Da Dein PC mit DivX -> MPG2 keine Probleme
>> zu haben scheint, krankt es offenbar an der schieren Datenmenge.
>
> Wenn ich allerdings mit transcode und mjpegtools MJPEG auf MPEG2 umsetzte
> komme ich nur auf etwa 2 Bilder/Sekunde. Da fehlt also mehr als ein Faktor 10.
> Das ganze kann also nur dann funktionieren wenn der Umsetzer in mplayer entsprechend
> effizienter arbeitet.

Dann ist mplayer offenbar Mist oder in dem Bereich extrem lahm.
MJPEG->MPEG2 sollte IMHO *deutlich* schneller gehen. Immerhin kann man
das Zeug ja auch in Echtzeit ansehen, oder? Dann sollte mit Decode ->
Recode im schlechtesten (;!) Fall die halbe Bildrate rauskommen, aber
nicht ein Zehntel.

> Wenn die Platte die MJPEG Datenrate von etwa 3Mbyte/sec schafft muesste das
> reichen.

Das ist wahr.

> Aber eine 2500 CPU ist doch nicht mal 4 mal schneller als die 700Mhz CPU,
> oder ist SSE soviel schneller als "3D Now" um da nochmal wesentlich was drauf
> zu legen ?

An Deiner Stelle würde ich mal gucken, ob Du mit dem System *überhaupt*
MJPEG ohne weitere Tricks abgespielt bekommst. Entweder stimmt mit den
MJPEG-Files was nicht, oder da ist sonst irgendwo der Wurm drin.

Gruß,
Alan

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede







Antwort von Carla Schneider:

Alan Tiedemann wrote:
>
> Carla Schneider schrieb:
> > Alan Tiedemann wrote:
> >> Mit einer schnellen CPU halt. Da Dein PC mit DivX -> MPG2 keine Probleme
> >> zu haben scheint, krankt es offenbar an der schieren Datenmenge.
> >
> > Wenn ich allerdings mit transcode und mjpegtools MJPEG auf MPEG2 umsetzte
> > komme ich nur auf etwa 2 Bilder/Sekunde. Da fehlt also mehr als ein Faktor 10.
> > Das ganze kann also nur dann funktionieren wenn der Umsetzer in mplayer entsprechend
> > effizienter arbeitet.
>
> Dann ist mplayer offenbar Mist oder in dem Bereich extrem lahm.

Transcode, bzw. die verwendeten codecs aus mjpegtools.
Wie es mplayer macht weiss ich ja nicht.

> MJPEG->MPEG2 sollte IMHO *deutlich* schneller gehen. Immerhin kann man
> das Zeug ja auch in Echtzeit ansehen, oder?

Auf dem Bildschirm, aber da muss er ja kein mpeg2 herstellen.

> Dann sollte mit Decode ->
> Recode im schlechtesten (;!) Fall die halbe Bildrate rauskommen, aber
> nicht ein Zehntel.
Ich muesste mal schauen ob man mit mplayer das erzeugte mpeg2 auch abspeichern
kann, und nicht nur direkt zur Karte schicken. Dann wuesste ich auch wie schnell
das wirklich laeuft. Leider ist ja die Manpage von mplayer so gross dass man nichts
darin findet.

>
> > Wenn die Platte die MJPEG Datenrate von etwa 3Mbyte/sec schafft muesste das
> > reichen.
>
> Das ist wahr.
>
> > Aber eine 2500 CPU ist doch nicht mal 4 mal schneller als die 700Mhz CPU,
> > oder ist SSE soviel schneller als "3D Now" um da nochmal wesentlich was drauf
> > zu legen ?
>
> An Deiner Stelle würde ich mal gucken, ob Du mit dem System *überhaupt*
> MJPEG ohne weitere Tricks abgespielt bekommst. Entweder stimmt mit den
> MJPEG-Files was nicht, oder da ist sonst irgendwo der Wurm drin.

Das abspielen auf dem PC-Bildschirm geht problemlos in Echtzeit.

--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
>> MJPEG->MPEG2 sollte IMHO *deutlich* schneller gehen. Immerhin kann man
>> das Zeug ja auch in Echtzeit ansehen, oder?
>
> Auf dem Bildschirm, aber da muss er ja kein mpeg2 herstellen.

Ja. Und? Andere Sachen kann er ja offenbar in Echtzeit zu MPEG2 verwandeln.

Mal eine kurze Rechenhilfe:
Ein Bild darf bei 50 fps maximal 20 ms Rechenzeit verbraten.

Wenn DivX --> MPEG2 in 20 ms möglich ist, dauert offenbar generell (;!)
das Encoding von MPEG2 *weniger* als 20 ms. Sonst wäre *beides* nicht in
20 ms zu schaffen, denn irgendwann muß der PC ja auch das DivX
decodieren, und das geht nicht in Nullzeit. Aber wir gehen für folgende
Betrachtung trotzdem mal von 20 ms Zeitbedarf für die Encodierung eines
einzigen MPEG2-Bildes aus.

Wenn MJPEG-Playback in Echtzeit geht, dauert offenbar die Decodierung
von MJPEG ebenfalls weniger als 20 ms pro Bild, sonst wäre das Playback
von MJPEG nicht in Echtzeit möglich.

Wenn jetzt die Kombination aus MJPEG-Decodierung und MPEG2-Encodierung
plötzlich 200 ms dauert (;Du sprachst von Faktor 10!), dann werden
irgendwo in Deinem System 160 ms pro Bild für irgendwelchen sinnlosen
Blödsinn verbraten, denn die Decodierung dauert ja weiterhin maximal 20
ms, und die Encodierung ebenfalls maximal 20 ms. 20 20 = 40, die
Differenz zu 200 beträgt 160.

Ergo: irgendwo in Deinem System hakt es. Wo auch immer.

>> Dann sollte mit Decode ->
>> Recode im schlechtesten (;!) Fall die halbe Bildrate rauskommen, aber
>> nicht ein Zehntel.
>
> Ich muesste mal schauen ob man mit mplayer das erzeugte mpeg2 auch abspeichern
> kann, und nicht nur direkt zur Karte schicken. Dann wuesste ich auch wie schnell
> das wirklich laeuft.

Das wäre mal eine Maßnahme.

> Leider ist ja die Manpage von mplayer so gross dass man nichts
> darin findet.

Schade, aber ich kenne das Programm leider gar nicht.

>> An Deiner Stelle würde ich mal gucken, ob Du mit dem System *überhaupt*
>> MJPEG ohne weitere Tricks abgespielt bekommst. Entweder stimmt mit den
>> MJPEG-Files was nicht, oder da ist sonst irgendwo der Wurm drin.
>
> Das abspielen auf dem PC-Bildschirm geht problemlos in Echtzeit.

Dann trifft meine obige Aussage vorbehaltlos zu. Irgendwo auf dem Weg
von MJPEG nach MPEG2 macht Dein System einen gravierenden Fehler.

Gruß,
Alan

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede




Antwort von Carla Schneider:

Alan Tiedemann wrote:
>
> Carla Schneider schrieb:
> >> MJPEG->MPEG2 sollte IMHO *deutlich* schneller gehen. Immerhin kann man
> >> das Zeug ja auch in Echtzeit ansehen, oder?
> >
> > Auf dem Bildschirm, aber da muss er ja kein mpeg2 herstellen.
>
> Ja. Und? Andere Sachen kann er ja offenbar in Echtzeit zu MPEG2 verwandeln.
>
> Mal eine kurze Rechenhilfe:
> Ein Bild darf bei 50 fps maximal 20 ms Rechenzeit verbraten.
>
> Wenn DivX --> MPEG2 in 20 ms möglich ist, dauert offenbar generell (;!)
> das Encoding von MPEG2 *weniger* als 20 ms. Sonst wäre *beides* nicht in
> 20 ms zu schaffen, denn irgendwann muß der PC ja auch das DivX
> decodieren, und das geht nicht in Nullzeit. Aber wir gehen für folgende
> Betrachtung trotzdem mal von 20 ms Zeitbedarf für die Encodierung eines
> einzigen MPEG2-Bildes aus.
>
> Wenn MJPEG-Playback in Echtzeit geht, dauert offenbar die Decodierung
> von MJPEG ebenfalls weniger als 20 ms pro Bild, sonst wäre das Playback
> von MJPEG nicht in Echtzeit möglich.
>
> Wenn jetzt die Kombination aus MJPEG-Decodierung und MPEG2-Encodierung
> plötzlich 200 ms dauert (;Du sprachst von Faktor 10!), dann werden
> irgendwo in Deinem System 160 ms pro Bild für irgendwelchen sinnlosen
> Blödsinn verbraten, denn die Decodierung dauert ja weiterhin maximal 20
> ms, und die Encodierung ebenfalls maximal 20 ms. 20 20 = 40, die
> Differenz zu 200 beträgt 160.
>
> Ergo: irgendwo in Deinem System hakt es. Wo auch immer.
>
> >> Dann sollte mit Decode ->
> >> Recode im schlechtesten (;!) Fall die halbe Bildrate rauskommen, aber
> >> nicht ein Zehntel.
> >
> > Ich muesste mal schauen ob man mit mplayer das erzeugte mpeg2 auch abspeichern
> > kann, und nicht nur direkt zur Karte schicken. Dann wuesste ich auch wie schnell
> > das wirklich laeuft.
>
> Das wäre mal eine Maßnahme.
>
> > Leider ist ja die Manpage von mplayer so gross dass man nichts
> > darin findet.
>
> Schade, aber ich kenne das Programm leider gar nicht.
>
> >> An Deiner Stelle würde ich mal gucken, ob Du mit dem System *überhaupt*
> >> MJPEG ohne weitere Tricks abgespielt bekommst. Entweder stimmt mit den
> >> MJPEG-Files was nicht, oder da ist sonst irgendwo der Wurm drin.
> >
> > Das abspielen auf dem PC-Bildschirm geht problemlos in Echtzeit.
>
> Dann trifft meine obige Aussage vorbehaltlos zu. Irgendwo auf dem Weg
> von MJPEG nach MPEG2 macht Dein System einen gravierenden Fehler.

Die Loesung war ganz einfach. DIVX wird nicht in mpeg 2 umgewandelt sondern
nur in mpeg 1 mit 25 bildern/sec.
Es ist mir gelungen die mplayer dokumentation in html auf einem webserver zu finden.

--
http://www.geocities.com/carla sch/index.html




Antwort von Alan Tiedemann:

Carla Schneider schrieb:
> Die Loesung war ganz einfach. DIVX wird nicht in mpeg 2 umgewandelt sondern
> nur in mpeg 1 mit 25 bildern/sec.

Na dann wird Dir ein schnellerer Rechner bei Deinem Problem auf jeden
Fall helfen.

> Es ist mir gelungen die mplayer dokumentation in html auf einem webserver zu finden.

Vielleicht findest Du auch noch eine Dokumentation zur Einstellung der
Zeilenlänge bei Deinem Newsreader und zur Vermeidung von sinnlosen
Fullquotes...

Gruß,
Alan

--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede




Antwort von Andre Beck:

Carla Schneider writes:
>
> Wenn ich allerdings mit transcode und mjpegtools MJPEG auf MPEG2
> umsetzte komme ich nur auf etwa 2 Bilder/Sekunde. Da fehlt also mehr
> als ein Faktor 10.

In dieser Kette geht es um hochwertiges MPEG2-Encoding in einen Stream,
der sich exakt an vielerlei Profile und Limits hält und dabei auch noch
so gut wie möglich aussieht. Sowas dauert.

> Das ganze kann also nur dann funktionieren wenn der Umsetzer in mplayer
> entsprechend effizienter arbeitet.

Das tut er. Er benutzt libfame für eine extrem schnelle YV12->MPEG1
Kodierung (;die AFAIK nur I-Makroblöcke produziert). Das geht ähnlich
schnell wie DV- oder MJPEG-Encoding, stellt also für moderne CPUs kein
Problem mehr dar. Neuere Versionen können dafür auch libavcodec
nutzen, die inzwischen noch schneller und besser als fame arbeitet.

Erstaunlich, wie der CPU-Footprint da in letzter Zeit gesunken ist.
Sieht man schön, wenn man mit vlc streamed - meine Testkiste, ein
1GHz Athlon, grabbed das Video in CIF, encodet es als MPEG4/MP2 in
einen MPEG TS, sendet den per Multicast und dekodiert den Stream per
duplicate zusätzlich gleich wieder auf den Bildschirm, damit ich
ein Monitoring der gesendeten Qualität habe. Das kostet die Kiste
keine 50% CPU-Last mehr, noch vor zwei Jahren war sie mit dem damaligen
Entwicklungsstand diverser Softwares zu langsam für sowas.

Eine Erklärung dafür, wieso die rechnerisch weniger aufwendige Trans-
codierung von MJPEG nach I-only MPEG bei Dir langsamer abläuft als die
anspruchsvollere von MPEG4 nach I-only MPEG habe ich aber auch nicht,
das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
aber: Interlace. Während DivX gewöhnlich für progressive Spielfilm-
RIPs benutzt wird, enthält MJPEG ja typischerweise field separated
Material in Full D1, also 576i bei CCIR/PAL. Wenn hier das resultierende
Bild was taugen soll, kann man das nicht einfach in 25fps MPEG1 um-
wandeln und an die Karte rauskippen - man muss es in interlaced MPEG2
umwandeln. Und das ist aufwendiger.

MPlayer macht gewöhnlich ziemlich verbose Angaben darüber, was er bei
der Ausgabe eines Videos so anstellt. Sieht man da einen Unterschied?

--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-




Antwort von Anette Heimann:


Alan Tiedemann schrieb:

> Carla Schneider schrieb:
> > Bei mpeg2 funktioniert es ganz gut, interessant ist aber dass
> > auch bei anderen Videoformaten mplayer offenbar eine Umrechnung macht.
> > Bei divx geht es sogar in Echtzeit, bei mjpeg und dv leider nicht,
> > aber mein Computer ist ja nur ein Duron 700Mhz. Was muesste man haben
> > damit es geht ?
>
> Einen schnelleren Rechner vielleicht?
>
> Gruß,
> Alan
>
> PS: Du plenkst

alan, du mußt den leuten schon sagen, was du damit meinst. hj





Antwort von Carla Schneider:

Andre Beck wrote:
>
> Carla Schneider writes:
> >
> > Wenn ich allerdings mit transcode und mjpegtools MJPEG auf MPEG2
> > umsetzte komme ich nur auf etwa 2 Bilder/Sekunde. Da fehlt also mehr
> > als ein Faktor 10.
>
> In dieser Kette geht es um hochwertiges MPEG2-Encoding in einen Stream,
> der sich exakt an vielerlei Profile und Limits hält und dabei auch noch
> so gut wie möglich aussieht. Sowas dauert.
>
> > Das ganze kann also nur dann funktionieren wenn der Umsetzer in mplayer
> > entsprechend effizienter arbeitet.
>
> Das tut er. Er benutzt libfame für eine extrem schnelle YV12->MPEG1
> Kodierung (;die AFAIK nur I-Makroblöcke produziert). Das geht ähnlich
> schnell wie DV- oder MJPEG-Encoding, stellt also für moderne CPUs kein
> Problem mehr dar. Neuere Versionen können dafür auch libavcodec
> nutzen, die inzwischen noch schneller und besser als fame arbeitet.
>
> Erstaunlich, wie der CPU-Footprint da in letzter Zeit gesunken ist.
> Sieht man schön, wenn man mit vlc streamed - meine Testkiste, ein
> 1GHz Athlon, grabbed das Video in CIF, encodet es als MPEG4/MP2 in
> einen MPEG TS, sendet den per Multicast und dekodiert den Stream per
> duplicate zusätzlich gleich wieder auf den Bildschirm, damit ich
> ein Monitoring der gesendeten Qualität habe. Das kostet die Kiste
> keine 50% CPU-Last mehr, noch vor zwei Jahren war sie mit dem damaligen
> Entwicklungsstand diverser Softwares zu langsam für sowas.
>
> Eine Erklärung dafür, wieso die rechnerisch weniger aufwendige Trans-
> codierung von MJPEG nach I-only MPEG bei Dir langsamer abläuft als die
> anspruchsvollere von MPEG4 nach I-only MPEG habe ich aber auch nicht,
> das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
> aber: Interlace. Während DivX gewöhnlich für progressive Spielfilm-
> RIPs benutzt wird, enthält MJPEG ja typischerweise field separated
> Material in Full D1, also 576i bei CCIR/PAL.

Das divx ist 368x280 bei 25 bildern/sec.
Das MJPEG ist 736x560 bei 25 bildern/sec interlaced, das ist
das 4fache.

> Wenn hier das resultierende
> Bild was taugen soll, kann man das nicht einfach in 25fps MPEG1 um-
> wandeln und an die Karte rauskippen - man muss es in interlaced MPEG2
> umwandeln. Und das ist aufwendiger.

Genau, und ich frage mich ob das mplayer ueberhaupt prinziell kann.

>
> MPlayer macht gewöhnlich ziemlich verbose Angaben darüber, was er bei
> der Ausgabe eines Videos so anstellt. Sieht man da einen Unterschied?

Er sagt nur was ueber die decoder. Das ist z.B. mit divx:

Playing /cdrom/fp198p3.avi.
AVI file format detected.
VIDEO: [DIVX] 368x280 24bpp 25.000 fps 1905.8 kbps (;232.6 kbyte/s)
Clip info:
Software: transcode-0.6.2
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2&3 finished, tables done
AUDIO: 44100 Hz, 2 ch, 16 bit (;0x10), ratio: 16000->176400 (;128.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (;mp3lib MPEG layer-2, layer-3)
==========================================================================
VO: [dxr3] Enabling prebuffering.
VO: [dxr3] Using new sync engine.
VO: [dxr3] Will set TV norm to: PAL.
VO: [dxr3] Opened /dev/em8300-0.
VO: [dxr3] Opened /dev/em8300 mv-0.
VO: [dxr3] Opened /dev/em8300 sp-0.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm:ffmpeg (;FFmpeg MPEG-4)
==========================================================================
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int
AF pre: 44100Hz 2ch Signed 16-bit (;Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (;Little-Endian) (;2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Starting playback...
VDec: vo config request - 368 x 280 (;preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Opening video filter: [lavc]
VDec: using Planar YV12 as output csp (;no 0)
Movie-Aspect is 1.31:1 - prescaling to correct movie aspect.
VO: [dxr3] 368x280 => 368x280 Mpeg PES
VO: [dxr3] Setting up for PAL/SECAM.
VO: [dxr3] Setting aspect ratio to 4:3.
A: 4.7 V: 4.7 A-V: -0.016 ct: -0.122 118/118 35% 23% 2.8% 8 0 0%%


--
http://www.geocities.com/carla sch/index.html




Antwort von Andre Beck:

Carla Schneider writes:
> Andre Beck wrote:
>
>> Eine Erklärung dafür, wieso die rechnerisch weniger aufwendige Trans-
>> codierung von MJPEG nach I-only MPEG bei Dir langsamer abläuft als die
>> anspruchsvollere von MPEG4 nach I-only MPEG habe ich aber auch nicht,
>> das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
>> aber: Interlace. Während DivX gewöhnlich für progressive Spielfilm-
>> RIPs benutzt wird, enthält MJPEG ja typischerweise field separated
>> Material in Full D1, also 576i bei CCIR/PAL.
>
> Das divx ist 368x280 bei 25 bildern/sec.
> Das MJPEG ist 736x560 bei 25 bildern/sec interlaced, das ist
> das 4fache.

Das ist schon mal ein beträchtlicher Unterschied.

>> Wenn hier das resultierende
>> Bild was taugen soll, kann man das nicht einfach in 25fps MPEG1 um-
>> wandeln und an die Karte rauskippen - man muss es in interlaced MPEG2
>> umwandeln. Und das ist aufwendiger.
>
> Genau, und ich frage mich ob das mplayer ueberhaupt prinziell kann.

Du hast leider nur das Log vom DivX gepostet, nicht das vom MJPEG.

>> MPlayer macht gewöhnlich ziemlich verbose Angaben darüber, was er bei
>> der Ausgabe eines Videos so anstellt. Sieht man da einen Unterschied?
>
> Er sagt nur was ueber die decoder. Das ist z.B. mit divx:

Nene, achte auf VO:

> VIDEO: [DIVX] 368x280 24bpp 25.000 fps 1905.8 kbps (;232.6 kbyte/s)
> ==========================================================================
> VO: [dxr3] Enabling prebuffering.
> VO: [dxr3] Using new sync engine.
> VO: [dxr3] Will set TV norm to: PAL.
> VO: [dxr3] Opened /dev/em8300-0.
> VO: [dxr3] Opened /dev/em8300 mv-0.
> VO: [dxr3] Opened /dev/em8300 sp-0.
> ==========================================================================
> Movie-Aspect is 1.31:1 - prescaling to correct movie aspect.
> VO: [dxr3] 368x280 => 368x280 Mpeg PES
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> VO: [dxr3] Setting up for PAL/SECAM.
> VO: [dxr3] Setting aspect ratio to 4:3.

Ah, siehste was? Die Karte kann offenbar auch abartige Auflösungen in
MPEG fullscreen skalieren, so dass der Encoder nicht etwa erst das YV12
auf 704/720x576 softwareskalieren und dann auch noch diese Auflösung
MPEG-encoden muss - er kann das direkt in der DivX-Originalauflösung
tun. Kommst Du jetzt mit einem Full-D1-Video, dann vervierfacht sich
der Encodingaufwand also, was natürlich schon alles begründen kann.
Mit einem DivX in Full D1 ließe sich das nachvollziehen - es sollte
bei noch bestehender Gültigkeit der Naturgesetze mindestens genau so
ruckeln. Zum Test einfach das MJPEG nach DivX bringen.

--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-