Ich sagte ja auch decoder ...
Du brauchst kein Ausgabedevice zum decodieren, sonder das was das Ausgabedevice zum decodieren benutzt als input für ffmpeg womit wir wahrscheinlich eher bei einem Script und mencoder oder mplayer ffmpeg Kombination ankommen, ich kann mir nicht vorstellen das man libxine zur Ausgabe als input für den encoder überreden kann.
<OT>Ich hab jetzt sowohl hier als auch in anderen Threads schon gelesen, daß manchmal jemand ...was zu "Sig(g)i" hochlädt.... Darf man fragen (und auch auf eine Antwort hoffen 
), was das genau bedeutet? Gibts da so eine Art privat betriebenen VDR Portal-FTP, oder sowas in der Art?</OT>
ZitatDu brauchst kein Ausgabedevice zum decodieren, ...
Schon klar, aber ich bräuchte den VDR zum decodieren.
Der Vorgang wäre dann so ähnlich, wie das Abspielen einer Aufnahme, nur dass man eben nix sieht, sondern ne dvd kompatible Aufnahme erzeugt.
Zitatwomit wir wahrscheinlich eher bei einem Script ...
Wenn es Skriptbasiert funzen würde, könnte man ja bereits yacoto nehmen.
Ich habe inzwsichen div. ffmpeg-Varianten getestet und jede schmiert ab. Deshalb gehe ich mal davon aus, dass die Probleme bezüglich h264 bereits bekannt sind (und etwas länger zu beheben dauern).
Aus dem Grunde wollte ich dort ansetzen, wo decodierte Vollbilder verfügbar sind - also nach dem Lesen und Aufbereiten durch den VDR. Ich denke mal, dass der Stream an der Stelle nicht für ein Skript erreichbar ist, deshalb müsste es ein Modul sein, was man im VDR einpflanzen könnte.
Ich dachte spontan an ein Ausgabe-Device, wahrscheinlich könnte es auch ein Player-Plugin sein - keine Ahnung (bin mit VDR-Internas nicht bewandert).
Vielleicht macht es ja auch Sinn, Klaus mal drauf anzusprechen ...
Das virtuelle Ausgabedevice (oder eben der Player) müsste die Bilder verkleinern und anschließend als mpeg speichern. Der Prozess nach dem "Bilder verkleinern" ist wieder identisch mit dem Prozess der VDR-(SD-)Aufnahme, vielleicht wäre ein Player-Plugin doch der bessere Weg und könnte die VDR-Funktionalität des Speicherns verwenden. Die entstandene SD-Aufnahme könnte dann ganz normal mit dem Burn-Plugin und Conserten weiter verarbeitet werden.
Zum Verkleinern der Bilder würde ich spontan auf imagemagick setzen, welches qualitativ hochwertige Ergebnisse liefern kann.
ZitatWas ist denn mit tsMuxeR?
Ich habe mir extra ein 32-bit debian aufgesetzt um das auszuprobieren. Das demuxen funzt, aber die Verarbeitung mit ffmpeg geht genauso wieder in die Hose (liegt also nicht am Stuffing) - und ich habe keine Decoder-Alternative (zu ffmpeg) unter Linux gefunden. Vielleicht ist in dem Test-Aufnahmeschnipsel ja ein Bildfehler drin - falls dem so ist, kann das aber bei jedem vorkommen und der Decoder sollte damit umgehen können (deshalb eben den VDR dafür verwenden).
ZitatGibts da so eine Art ...
Schau mal in der Rubrik TV-Tips etc.
Gruß Gero
ZitatAlles anzeigen
...
Ich habe mir extra ein 32-bit debian aufgesetzt um das auszuprobieren. Das demuxen funzt, aber die Verarbeitung mit ffmpeg geht genauso wieder in die Hose (liegt also nicht am Stuffing) - und ich habe keine Decoder-Alternative (zu ffmpeg) unter Linux gefunden. Vielleicht ist in dem Test-Aufnahmeschnipsel ja ein Bildfehler drin - falls dem so ist, kann das aber bei jedem vorkommen und der Decoder sollte damit umgehen können (deshalb eben den VDR dafür verwenden).
Schau mal in der Rubrik TV-Tips etc.
Gruß Gero
Das mit ffmpeg ist ja dann wirklich schade. Bleibt zu hoffen, daß es dafür bald mal eine weiterentwickelte Variante geben wird, der das keine Probleme bereitet.
Und danke für den Hinweis, habe verstanden 
tach,
versteh ich das richtig das hier überlegt wird eine hd aufnahme in mpeg2 zu wandeln ? sorry aber das ist doch nen witz oder ?
zum thema hd aufnahmen zu mp4/mkv konvertieren, das geht wunderbar mit handbrake mit x264 als codec wird eine zb. ard aufnahme 3/4 kleiner und passt somit, meistens zumindest, auf ne normale dvd.
vielleicht gibs auch bald ein plugin dafür, wenn es denn mal fertig wird.
Lies mal Posting #1 und #7, dann weißt Du, warum... finde das im Diskurs mit meiner Holden eher weniger witzig
tach pandel,
hab das schon verstanden, wenn es jetzt hd sender geben würde die nicht das selbe programm auch in sd ausstrahlen könnte ich das ja noch verstehen, aber jeder sender sendet doch das gleiche auch in sd, warum also nicht direkt in sd aufnehmen und mit dem burn plugin gleich wegbrennen ?
ZitatAus dem Grunde wollte ich dort ansetzen, wo decodierte Vollbilder verfügbar sind - also nach dem Lesen und Aufbereiten durch den VDR.
Der VDR dekodiert die Bilder nicht, er schickt den kodierten Datenstrom
an das Ausgabe device , (also den Hardware- oder Software decoder)
und das Ausgabe device hat den H264 decoder und erzeugt dann die Einzelbilder.
Verwendet das Ausgabe device die hardware Beschleunigung einer Grafikkarte,
kommt man also an die Einzelbilder erstmal nicht so einfach ran 
ZitatOriginal von pandel
kann denn der VDR gleichzeitig auf mehreren Ausgabegeräten unterschiedliche Sachen ausgeben?
mit ner HD-FF kann das gehen. Die gibt gleichzeitig die Bildinformation in HD und SD aus
Gruß Fr@nk
ZitatOriginal von lola
mit ner HD-FF kann das gehen. Die gibt gleichzeitig die Bildinformation in HD und SD aus
Cool. Kann ich dann SPORT1 in HD gucken, indem ich einfach das Kabel umstecke? SCNR. 
Gruß
hepi
Zitatsorry aber das ist doch nen witz
Genau - wenn man's nicht versteht, ist andere auslachen immer die beste Methode 
Ich empfand den Fred eher als offenes brainstorming zu einem gegebenen Problem, welches da lautet: es liegt eine HD-Aufnahme vor, die (möglichst benutzerfreundlich) auf DVD gebracht werden soll - somit scheidet aufnehmen in SD als Lösungsvorschlag aus.
Zitat... kommt man also an die Einzelbilder erstmal nicht so einfach ran
Sch... ade - irgendwie hat mir die Idee gefallen - aber jetzt wo Du es sachst, leuchtet es mir sofort ein.
Keine Ahnung - ich kenn mich jetzt mit den Ausgabedevices noch weniger als mittem VDR aus, ließe sich da ne Schnittstelle für Rohdaten finden, oder ist das illusorisch?
Gruß Gero
ZitatOriginal von hepi
.. indem ich einfach das Kabel umstecke?
Gruß
hepi
wozu Kabel umstecken?
Gruß Fr@nk
Man wird wohl um einen HD Software decoder nicht herum kommen,
dann scalieren und neu kodieren.
Aus Einzelbildern wieder einen MPEG2 stream herstellen
geht glaube ich mit auch mit transcode.
Ach ja und den Ton nicht vergessen.
Also erstmal die Specs für H264 lesen und dann in die Quellen
vom MPlayer/SMPlayer oder anderer sofware hineinschauen,
wie die das gemacht haben.
Leider hab ich ne 50-60 Stundenwoche(bin sebstsändig)
und finde nicht die Zeit dafür.
Unter Windows (Quellen bzw. Linux-Ports verfügbar) läufts qualitativ am besten so:
- H264-Dateien indexieren per DGAVCDec. Bei der Gelegenheit wird auch gleichzeitig die Audiospur(en) als separate Datei rausgezogen.
- Dieses Indexfile an einen Frameserver (in diesem Fall AviSynth) verfüttern, welcher Vollbilder erstellt, resizen kann (u.v.m.) und an einen frameserverfähigen Encoder durchreicht. AviSynth ist kein Klickibunti, sondern arbeitet skriptgesteuert - ein Eldorado für Linux...
Ein Beispielskript (beispiel.avs):
LoadPlugin(DGAVCDecode.dll)
AVCSource("meinfilm.dga") # ist die von DGAVCDEC erzeugte Indexdatei
LanczosResize(720,576)
- HCEnc ist der derzeit beste Freeware-MPEG-Encoder, welcher AVS-Skripts direkt verarbeiten kann - allerdings kann er nur Video. Ob ffmpeg mit avs-Skripten klarkommt, weiss ich nicht.
- muxen der entstandenen .m2v und der Audiospur(en) mit mplex.
- fertig (zunächst das mpeg)
Vielleicht ein Ansatz? Für alle Tools (ausser AviSynth) gibts neben der GIU auch die CLI-Varianten.
BJ1
ZitatMan wird wohl um einen HD Software decoder nicht herum kommen
Den VDR hatte ich ins Spiel gebracht, weil ich ihn für eine Alternative zu ffmpeg hielt. Da das nicht der Fall zu sein scheint, gibt es wohl keine Alternative ...
ZitatAch ja und den Ton nicht vergessen.
Yo, aber beim Ton sind ja keine neuen Formate dazu gekommen - oder?
Also dürfte doch ein demuxen vor dem decodieren reichen und nach dem skalieren und neukodieren der Bilder dürfte ein remux mit den Tonspuren klar kommen. Vielleicht müsste man die Zeitstempel patchen, aber der Rest dürfte doch passen?!?
Zitat... dann in die Quellen vom MPlayer/SMPlayer
da MPlayer nur im Chor dumpt, kann man sich die Mühe auch sparen.
Insbesondere wenn Zeit nicht unbegrenzt zur Verfügung steht, sollte man sich nur ne funktionierende Lösung anschauen. Es sei denn, man hat Specs und somit eine Ausgangsbasis, Fehlverhalten von ffmpeg und Co zu finden.
Wie ist das denn bei den streaming-Lösungen?
Wird dort auch das codierte Video übertragen, oder gibt es eine (funktionierende) streaming Lösung, die auf Server-Seite bereits dekodiert?
Gruß Gero
P.S. neuer Tag neues Glück
habe mir x264 aus dem repo ausgefasst und es mit --prefix=/usr gebaut (vorher die offiziellen Pakete von x264 deinstalliert) und anschließend einen aktuellen ffmpeg gebacken - mit folgendem Resultat:
$ ffmpeg -i 00001.ts -s 720x576 -aspect 16:9 -target pal-dvd test.mpg
FFmpeg version SVN-r24103, Copyright (c) 2000-2010 the FFmpeg developers
built on Jul 8 2010 05:51:09 with gcc 4.3.2
libavutil 50.20. 0 / 50.20. 0
libavcodec 52.80. 0 / 52.80. 0
libavformat 52.73. 0 / 52.73. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.22. 0 / 1.22. 0
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
[h264 @ 0x120ab40] mmco: unref short failure
Input #0, mpegts, from 'testInp.ts':
Duration: 00:44:29.26, start: 38922.647211, bitrate: 975 kb/s
Program 132
Stream #0.0[0x641]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
Stream #0.1[0x642](deu): Audio: mp2, 48000 Hz, 2 channels, s16, 256 kb/s
Stream #0.2[0x646](deu): Audio: ac3, 48000 Hz, stereo, s16, 256 kb/s
[scale @ 0x120f080] w:1280 h:720 fmt:yuv420p -> w:720 h:576 fmt:yuv420p flags:0xa0000004
Output #0, dvd, to 'test.mpg':
Metadata:
encoder : Lavf52.73.0
Stream #0.0: Video: mpeg2video, yuv420p, 720x576 [PAR 64:45 DAR 16:9], q=2-31, 6000 kb/s, 90k tbn, 25 tbc
Stream #0.1(deu): Audio: ac3, 48000 Hz, stereo, s16, 448 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
[h264 @ 0x120ab40] mmco: unref short failure
[h264 @ 0x120ab40] number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0x120ab40] illegal short term buffer state detected
Last message repeated 1 times238962kB time=300.29 bitrate=6519.0kbits/s dup=34 drop=7488
[h264 @ 0x120ab40] number of reference frames exceeds max (probably corrupt input), discarding one
Last message repeated 1 times
[mp2 @ 0x120b390] Header missing
Error while decoding stream #0.1
[h264 @ 0x120ab40] mmco: unref short failure
[h264 @ 0x120ab40] missing picture in access unit
[mp2 @ 0x120b390] incomplete frame
Error while decoding stream #0.1
[h264 @ 0x120ab40] missing picture in access unit
frame= 7554 fps= 26 q=3.0 Lsize= 240900kB time=300.67 bitrate=6563.5kbits/s dup=41 drop=7497
video:219998kB audio:16443kB global headers:0kB muxing overhead 1.885897%Video sieht gut aus und ac3-Ton scheint auch ok zu sein.
Zur Synchronität kann ich noch nix sagen, da es ein Naturfilm war.
Die Aufnahme wird als korrupt angemeckert (dabei dachte ich, das das Prädikat auf mich zutreffen würde ), aber immerhin wird inzwischen ein Film erzeugt, der sich auch problemlos abspielen lässt.
Es scheint also Hoffnung zu geben
Die Verarbeitungsschritte (z.B. für yacoto) könnten so aussehen (idealerweise liegt jeweils das Verzeichnis, in das geschrieben wird auf einer anderen Festplatte als das Verzeichnis, aus dem gelesen wird):
ZitatOriginal von geronimo
Festplatte als das Verzeichnis, aus dem gelesen wird):
- die (TS-)Dateien der (geschnittenen) Aufnahme in einem Arbeitsverzeichnis verbinden (z.B. mit cat)
- ffmpeg mit der temporären Datei als Eingabe starten, Ziel z.B. movie1.mpg in einem weiteren Arbeitsverzeichnis
Verarbeitet ffmpeg denn kein standard input? Kann man die Files nicht einfach in ffmpeg rein pipen? Spart mächtig Platz und Zeit.
Gerald
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!