Logo Logo
/// 

Hollywood+ als Videoausgabekarte fuer mplayer



Noch was unklar? Dann in unserem Forum nachfragen!


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 MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt 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 FormatFormat im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt und DV-AVIDV-AVI im Glossar erklärt *sehr* hohe
Datenraten, so daß es durchaus an der Plattenleistung scheitern könnte.

> Wofuer die Leistung nicht ausreicht
> ist die Umsetzung in ein FormatFormat im Glossar erklärt 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 DivXDivX im Glossar erklärt -> 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 FormatFormat im Glossar erklärt 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 DivXDivX im Glossar erklärt mit 352x??? einigermassen erträglich über
eine DVB-S-Karte (;FF), die auch nur MPEG2MPEG2 im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt und DV-AVIDV-AVI im Glossar erklärt *sehr* hohe
> Datenraten, so daß es durchaus an der Plattenleistung scheitern könnte.
>
> > Wofuer die Leistung nicht ausreicht
> > ist die Umsetzung in ein FormatFormat im Glossar erklärt 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 DivXDivX im Glossar erklärt -> MPG2 keine Probleme
> zu haben scheint, krankt es offenbar an der schieren Datenmenge.

Wenn ich allerdings mit transcode und mjpegtools MJPEGMJPEG im Glossar erklärt auf MPEG2MPEG2 im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt DatenrateDatenrate im Glossar erklärt 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 DivXDivX im Glossar erklärt -> MPG2 keine Probleme
>> zu haben scheint, krankt es offenbar an der schieren Datenmenge.
>
> Wenn ich allerdings mit transcode und mjpegtools MJPEGMJPEG im Glossar erklärt auf MPEG2MPEG2 im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt DatenrateDatenrate im Glossar erklärt 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 DivXDivX im Glossar erklärt -> MPG2 keine Probleme
> >> zu haben scheint, krankt es offenbar an der schieren Datenmenge.
> >
> > Wenn ich allerdings mit transcode und mjpegtools MJPEGMJPEG im Glossar erklärt auf MPEG2MPEG2 im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt DatenrateDatenrate im Glossar erklärt 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*
> MJPEGMJPEG im Glossar erklärt 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 MPEG2MPEG2 im Glossar erklärt verwandeln.

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

Wenn DivXDivX im Glossar erklärt --> MPEG2MPEG2 im Glossar erklärt in 20 ms möglich ist, dauert offenbar generell (;!)
das Encoding von MPEG2MPEG2 im Glossar erklärt *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 MJPEGMJPEG im Glossar erklärt ebenfalls weniger als 20 ms pro Bild, sonst wäre das Playback
von MJPEGMJPEG im Glossar erklärt 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*
>> MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach MPEG2MPEG2 im Glossar erklärt 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 MPEG2MPEG2 im Glossar erklärt verwandeln.
>
> Mal eine kurze Rechenhilfe:
> Ein Bild darf bei 50 fps maximal 20 ms Rechenzeit verbraten.
>
> Wenn DivXDivX im Glossar erklärt --> MPEG2MPEG2 im Glossar erklärt in 20 ms möglich ist, dauert offenbar generell (;!)
> das Encoding von MPEG2MPEG2 im Glossar erklärt *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 MJPEGMJPEG im Glossar erklärt ebenfalls weniger als 20 ms pro Bild, sonst wäre das Playback
> von MJPEGMJPEG im Glossar erklärt 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*
> >> MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach MPEG2MPEG2 im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt 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 MPEGMPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach I-only MPEGMPEG im Glossar erklärt bei Dir langsamer abläuft als die
anspruchsvollere von MPEG4 nach I-only MPEGMPEG im Glossar erklärt habe ich aber auch nicht,
das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
aber: Interlace. Während DivXDivX im Glossar erklärt gewöhnlich für progressive Spielfilm-
RIPs benutzt wird, enthält MJPEGMJPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt 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 MPEGMPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach I-only MPEGMPEG im Glossar erklärt bei Dir langsamer abläuft als die
> anspruchsvollere von MPEG4 nach I-only MPEGMPEG im Glossar erklärt habe ich aber auch nicht,
> das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
> aber: Interlace. Während DivXDivX im Glossar erklärt gewöhnlich für progressive Spielfilm-
> RIPs benutzt wird, enthält MJPEGMJPEG im Glossar erklärt ja typischerweise field separated
> Material in Full D1, also 576i bei CCIR/PAL.

Das divx ist 368x280 bei 25 bildern/sec.
Das MJPEGMJPEG im Glossar erklärt 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] MPEGMPEG im Glossar erklärt 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 MPEGMPEG im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach I-only MPEGMPEG im Glossar erklärt bei Dir langsamer abläuft als die
>> anspruchsvollere von MPEG4 nach I-only MPEGMPEG im Glossar erklärt habe ich aber auch nicht,
>> das kann eigentlich nicht sein. Eine potentielle Erklärung habe ich
>> aber: Interlace. Während DivXDivX im Glossar erklärt gewöhnlich für progressive Spielfilm-
>> RIPs benutzt wird, enthält MJPEGMJPEG im Glossar erklärt ja typischerweise field separated
>> Material in Full D1, also 576i bei CCIR/PAL.
>
> Das divx ist 368x280 bei 25 bildern/sec.
> Das MJPEGMJPEG im Glossar erklärt 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 DivXDivX im Glossar erklärt 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 DivXDivX im Glossar erklärt 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 MJPEGMJPEG im Glossar erklärt nach DivXDivX im Glossar erklärt 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 <-





Noch was unklar? Dann in unserem Forum nachfragen!


Antworten zu ähnlichen Fragen:
Creative AudigyPlayer - Soundkarte mit IEEE
mplayer subtitles türkisch
DV archivieren und Mplayer Problem
MP4 crasht mplayer (Linux)
mplayer-Befehl: transkodiert neu oder nicht?
Mit mplayer/mencoder *.mpg dateien zusammenfuegen
[mplayer] Getrennte Audio/Video Dateien zusammen abspielen?
Problem: Windows Vista, H264 und MPlayer Portable GUI
Rekodieren von rv40 nach mpg2 mit mplayer und mencoder
Was benutzt Hollywood?
Hollywood FX PRO
Filmschnitt in Hollywood
How China is changing Hollywood
The 3D Camera that Hollywood Loved
Crane S2 vs Hollywood Steady
Safety in Hollywood / AirNZ SafetyVideo
Once Upon A Time in Hollywood - offizieller Trailer
Hollywood at Lake Como: Villa Balbianello
Dazzle Hollywood Bridge will nicht mehr
Studio9 und Hollywood FX Übergänge funktionieren nicht!
Storyboards für Hollywood Blockbuster per iPad Pro
Wow, Once Upon a Time in Hollywood hat 9,5 bei imdb
Tiffen Black Pro Mist vs Schneider Hollywood Blackmagic
Schießt Avid reihenweise Mac Pros in Hollywood-Studios ab?
Josh Beal: Reconsidering Final Cut Pro X in Hollywood
Hollywood-Filmemacher protestieren gegen neues Netflix-Feature

















weitere Themen:
Spezialthemen


16:9
3D
4K
AI
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Avid Media Composer
Band
Bild
Bit
Blackmagic
Blackmagic DaVinci Resolve
Blackmagic Design DaVinci Resolve
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS 5D MKII
Canon EOS C300
Capture
Capturing
Cinema
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
EDIUS
ENG
EOS
Effect
Effekt
Effekte
Euro
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Format
Formate
Foto
Frage
Frame
GoPro
Grass Valley Edius
HDMI
HDR
Hilfe
Import
JVC
KI
Kabel
Kamera
Kanal
Kauf
Kaufe
Kaufen
Kurzfilm
Layer
Licht
Light
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
NAB
Nero
News
Nikon
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Panasonic S1 mit V-Log
Panasonic S5
Pinnacle
Pinnacle Studio
Player
Plugin
Plugins
Premiere
Projekt
RAW
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sony HDR
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
YouTube
Zoom