Posts by CBArts

hi...

ich denke die meisten haben's erstmal ohne hw-beschleuniger versucht und gemerkt, das der dualcore nicht reicht...

schau mal hier nach:

[SUCHE] channels.conf für DVB-S2 (Technotrend 3200) & DISEQC Probleme

btw: der thread ist auch nicht sehr alt und nur ein paar zeilen unter deinem -->d.h. nächstesmal erst mal schauen ob nicht jemand dafür schon ne lösung hat...

hi...

also zu den problemen auf zdf u.a. transpondern...
hatte ich auch ne ganze weile... incl. dem rumspielen mit den frequenz-offsets...
seit den patches aus der ML gabs keine probleme mehr mit der TT3200 - ich verwende allerdings noch multiproto_plus

die patches waren der derot-step-fix (keine ahnung wie der im original hieß)
und ein patch für register-einstellungen (mit kleinen änderungen)

danach lief alles ohne irgendwelche offsets und alle transponder, die ich getestet hab, liefen ohne probleme

hier die patches, die ich benutze...

@alle:

ich habe mir nochmal die timecodes von den erzeugten mkv-files angeschaut und mit der script-methode verglichen:

• das anfügen von vdr-files mit dem '+' parameter bei mkvmerge führt zu fehlern in den timecodelisten in den ausgabedateien d.h. es ergeben sich wahrscheinlich sync-probleme nach dem 1. vdr-file und jedem weiteren file (002.vdr usw.) - es ist auch möglich das nur video-pakete dort verworfen werden somit das ergebnis zwar sync aber 'unvollständig' (da muss ich nochmal nachschauen)
• die direkte methode (mkvmerge) erzeugt mehr timecodes am ende und einen anderen offset?!? (schau ich auch noch mal nach)

empfehlung: wer mkvmerge direkt verwenden will sollte die vdr-files vorher zusammenfügen z.b. mit cat oder das script umbauen

NACHTRAG:
es gehen definitiv video und audio pakete an den dateigrenzen bei der verwendung des '+' parameters verloren - der a/v-sync kann auch schaden nehmen - leider lässt sich das nicht ohne einen sehr aufwändigen eingriff in die grundstruktur von mkvmerge ändern
punkt 2 hab ich noch nicht genauer untersucht...

Razorblade:
Ja die zuordnung funzt manchmal (hab auch nen film gehabt bei dem es ging; aber 2 oder 3 andere wo's nicht ging)...
hmm... komisch wenn ich so drüber nachdenke - sollte eigentlich immer richtig funktionieren, da die tonspuren ja immer automatisch nach dem id sortiert werden... werd' doch noch mal in den code schauen müssen
ist der sync ok wenn du das file über das script erzeugst? wenn ja kannst du die timecodes der beiden mkv's mal vergleichen (kann man mit mkvextract wieder zurückgewinnen)
hast du mit unterschiedlichen playern getestet? mplayer ist da leider keine so gute referenz, so, wie's aussieht...

bei defektem material mein ich eher fehler aus zu schwachem signal (muss die schüssel neu ausrichten)...

Konni:
danke für's angebot - im moment hab ich allerdings recht wenig zeit dafür

hi...

Nach meinen tests hab ich seltener eine erfolgreiche umwandlung gehabt (liegt vielleicht an fehlerhaftem quellmaterial)....
Die größten probleme die ich gefunden hab bis jetzt sind:
[list=1]
[*] beim zusammenfügen (anhängen) von vdr-files zu einem mkv: mkvmerge scannt jede datei einzeln und kann dann die tonspuren nicht zuordnen (kann man wohl 'per hand' machen aber das wär wohl ziemlich aufwändig bei z.B. 15 oder mehr vdr-files (Olympia)) - lässt sich sicherlich im source korrigieren - aber so tief will ich in mkvtoolnix nicht eingreifen/vordringen
[*] bei AC3 (und auch mp3?!?) werden die timecodes intern separat zum mkv generator übergeben - wobei noch ein weiterer AC3-paket-check nach der timecodeübergabe erfolgt und der timecode, wenn das paket verworfen wird, nicht auch verworfen wird -> unsynchron (könnte aber bei der demux-variante ähnlich sein) - sollte lösbar sein (kann sich aber nur bei defekten aufnahmen auswirken)
[/list=1]
in fall 2 sollte aber mkvmerge meckern (ist zumindest bei mir so...)

Razorblade: bekommst du fehlermeldungen?

dings:
es kann sein das der scanbereich von mpeg_ps_extract/mpeg_ps_info zu klein ist und er kein weiteres tonpaket findet (eigentlich ist der aber schon sehr großzügig eingestellt)
werden denn alle tonspuren ausgepackt mit mpeg_ps_extract?

PS: danke für die 2 rückmeldungen (bei ca. 43 downloads ist das schon ziemlich mager...)
PPS: welche player verwendet ihr so zum abspielen? (ich hab mit mplayer massive sync&speed-probleme - sowohl bei 720p als auch 1080i)

so die neue PESFIX 0.6 BETA für mkvtoolnix 2.2.0 (mkvmerge) ist fertig... (ermöglicht das direkte konvertieren von vdr-files in das matroska-format)
(ihr braucht mkvtoolnix version 2.2.0 im source (und evtl. zubehör libebml-dev, matroska-dev u. mglw. andere dev-pakete) und den angehängten patch)

sehr viele bugfixes und änderungen...

bitte testet mal auf sync bei h264 material - es sollte jetzt synchron sein
(bitte um rückmeldung - auch bei positivem ergebnis)

mpeg sollte man aber nicht umwandeln (ist zwar auch sync, aber irgendwo auf dem verarbeitungsweg gehen ein paar bytes verloren )

PS: mkvmerge erkennt jetzt auch die richtige Bildrate und schreibt sie ins file (zumindest bei vdr-files) - so weit ich das sehe verwendet mkvmerge normalerweise 25 fps als standardvorgabe was zu "Zeitlupenwiedergabe" z.b. beim mplayer führt....

s_herzog:

Quote

Seh ich das richtig, dass nur eine Instanz des Scripts gleichzeitig laufen sollte weil die tempfiles alle gleich heißen? Könntest du da nicht die pid oder so in den Namen einbauen? Dann könnte die Box die Nacht durch einen Haufen Zeug konvertieren großes Grinsen

jepp... kannst ja einfach 8 temp verzeichnisse machen mit 8 scripten (bin im moment mit PESFIX beschäftigt...)

Quote

EDIT2: Magst du nicht deinen SSEM-Patch an mpeg4ip einreichen, damit sie es eventuell in den Standard aufnehmen?

nein, das halte ich für keine gute idee, da das ein reiner quick-and-dirty fix bzw. eine notlösung ist - normalerweise muss das hauptprogramm und mglw. die library völlig neugeschrieben/umgeschrieben werden um bessere performance und ein sauberen code zu liefern

der PESFIX für mkvmerge wär die bessere lösung: ist permanenter, schneller und sehr viel effizienter

@alle
hab jetzt feststellen müssen das das "speicherleck" bei mkvmerge scheinbar mit den timecodes zu tun hat (bzw. duch paket umsortierung entsteht) mal schauen ob ich das gelöst bekomme...
(d.h. wer nur video im mkv haben will sollte mit der letzten version schon arbeiten können )

ps: wenn mehrere vdr-dateien in ein mkv file konvertiert werden sollen reicht ein +
bsp: mkvmerge -o result.mkv 001.vdr +002.vdr +003.vdr usw.

hi...

hab einen patch für mkvtoolnix geschrieben, der es ermöglicht ein vdr-file direkt ohne extra demuxen in ein matroska container zu konvertieren...
ACHTUNG: dies ist eine BETA-version D.H. ___keine___ beschwerden nach dem patchen das euer mkvmerge nich mehr richtig läuft
aber wenn ihr damit experimentieren wollt: ihr braucht mkvtoolnix version 2.20 im source (und evt. zubehör libebml-dev, matroska-dev u. mglw. andere dev-pakete) und den angehängten patch

soweit ich das ding getestet hab: mormale vdr-aufnahmen (mpeg2) sind scheinbar ok (incl. aller tonspuren)...
h264 macht, so wie's aussieht, noch probleme...

achso: keine sync garantien (das hab ich erst mal außen vor gelassen...) - der sync könnte aber ok sein (größtenteils hab ich den vorhandenen MPEG PS parser verwendet)

...hab nur seeehr wenig gesteted...
vielleicht findet noch jemand nen bug im source...

aufruf: mkvmerge -o <ausgabefile.mkv> <vdr-file>

NACHTRAG:
bei der h264 verarbeitung scheint irgendwo ein speicherleck zu sein...

NACHTRAG2:
der parser muss noch mal überarbeitet werden ... wird noch nen bisschen dauern...
(mpeg2-erkennung wurde durch die h264 korrekturen beschädigt *grr* )

NACHTRAG3:
der mpeg2 teil läuft wieder leider gibt es sync probleme (hab noch keine ahnung wie ich die löse)
...auf alle fälle funktioniert jetzt die erkennung mpeg2/h264 ganz gut... das speicherleck für h264 ist immernoch irgendwo (sollte aber niemanden vom testen abhalten )

PESFIX Version 0.2:

faup:
ich bin grad' am scheiden der 2ten aufnahme ca. 70 gibibyte - diesmal wurde die Cut-engine ab ca. 40 GiB langsam (1MiB/s) - die CPU last ist nahe bei 100% (ist mir eben erst aufgefallen) -
RAM ist noch massig frei: htop sagt 1.9% verwendet von 1GiB
liegt definitiv an perl...

btw: ich bin grad am experimentieren mit mkvmerge - es sollte möglich sein direkt von einem VDR-file in ein matroska file zu schreiben (bei MPEG-PS kann er das laut source ja auch...)

faup:
nee nur die Cut-engine hat ab ca. 30-32 GiB nur noch 1-3MiB/s geliefert demux lief mit normalem speed (matroska muss ich gleich nochmal starten (hat wegen audio-sync-reihenfolge gemotzt))
...dann wirds wohl an perl liegen ... auch egal - momentan ist speed nicht so wichtig und so große aufnahmen gibts sowieso nur zu olympia

zu den iframes:
hab mir das ganze auch nur oberflächlich angesehen - wenn man den ffmpeg/libavcodec decoder dazu bringen kann kurz vor der marke anzufangen zu dekodieren und dann zum mark mit x264 das decodierte frame in einen iframe umzuwandeln.... vielleicht reicht's dann schon das neue iframe einfach vor den nächsten frame zu setzen.... hab nur mal laut gedacht

ps: werde das neue script mal testen

NACHTRAG:
man sollte wohl so große aufnahmen vermeiden: mpeg_ps_demux liefert in den audio-sync-files nur noch murx..........(oder die aufnahme war nicht sauber)

Hi,

also Iframes mit dem x264 encoder zu generieren ist ja scheinbar nich so schwierig (siehe x264.c)... kompliziert wirds mit dem decoder... (muss ne möglichkeit geben ein vollständiges bild zu "erkennen" nach dem anlaufen
den erstellten iframe an der richtigen stelle einzusetzen stell' ich mir auch nicht so einfach vor....

...aber von der idee her wär das mal nen anfang um wenigstens die aufnahme mit einem iframe starten zu lassen...

faup:
btw: kann das sein das, das script ab ca. 32GiB beim kopieren seehr langsam wird ? (hoffentlich liegts nicht am dateisystem ... (ext2) - ich sitz jetzt schon über 20h an 'ner 67GiB aufnahme )

femon funktioniert schon - zumindest sind die wichtigsten daten vorhanden (ber,snr) - die "Operation not supported" meldung kann man ignorieren...

schade ist nur das der stb0899 so schlecht dokumentiert ist - wenn man max-werte für snr und signal hätte könnte man auch ne prozentanzeige/balkenanzeige im vdr plugin ermöglichen

Hallöchen...

Ich hab das Script ein bisschen aufpoliert in hinsicht auf MP3 tonspuren (btw. in den files steckt üblicherweise MPEG 1 Layer 2 und nicht Layer 3 wie der dateiname suggeriert )
leider ist allerdings jetzt die AC3 stream sortierung wieder raus (bin nicht so der perl typ ) d.h. wer immer den AC3 strom mit den meisten kanälen als ersten stream haben will sollte auf nen fix von faup warten...

fazit: ORF1 HD und BBC HD sollte jetzt gehen

PS: bin leider nicht zum testen gekommen ( Olympia aufnahme läuft )
PPS: momentan ist das script auf 9 audiostreams limitert - das sollte wohl vorerst mal reichen
PPPS: nach dem fix wäre wohl nen versionswechsel auf V7 ganz gut

NACHTRAG:
hotfix für tonspuren war nötig (falscher pfad) - bitte V6e erneut laden (gilt nur für die, die V6d geladen haben)
bin grad am testen...

hi...

muss mich da mal mit dranhängen...
hab auch das problem (ähnliche hardware Asrock ALiveDual-eSATA2... )
(btw: bei mir hat das board sogar spdif nur wird das nich unterstützt wird von alsa da der chip wohl topsecret ist *grr*)

ps: interessant ist auch das seit vorgestern der digi-out der sblive zwar ein signal ausgibt (receiver sagt PCM vorhanden) aber ohne ton ... alle anwendungen! bis auf bitstreamout (mit stotternem ton)

.... wär ich doch mal beim alten non-HDReady system geblieben...

Maniac:
das was dich interessiert steht in zeile 1224 & 1237 ... (der rest sind nur: mein rolloverpatch und ein paar 'dynamische' korrekturen (korrigieren der PTS werte auf die aktuelle 'paket-position'))
zu 1224: das ist das was du schon machst ptspos = endwert - startwert) (ohne den rollover zu berücksichtigen)

rnissl:
kann sein das es zu den zeiten einen bufferoverflow gab ich schau mal ob ich für die fragliche datei noch nen syslog hab...

NACHTRAG: ist leider schon zu lange her ... log ist wech bei den anderen umwandlungen hab ich leider nicht drauf geachtet ... vielleicht hat irgend jemand nen log von ner defekten aufnahme

hi...

ja dann ist alles klar: starte mpeg_ps_extract mal ohne parameter ... die haben sich nämlich geändert --video hab ich rausgenommen d.h. es ist immer aktiv...

jo dein tool macht das gleiche...ist in mpeg4ip nur ein 'bisschen' aufwendiger programmiert (muss man sich ne weile einlesen...)

als tip: (find ich ganz gut dargestellt)
http://dvd.sourceforge.net/dvdinfo/pes-hdr.html

(die eingefügten einsen sind ein bisschen nervig beim pts... und was man auch gern übersieht ist das der PTS ne länge von 33 bit hat und nich 32...)

zur zeitberechnung: da musst du mal in mpeg2ps.c nachschauen dort werden konvertierungen vorgenommen... (irgendwas mit 90kHz) --> function convert_ts

Maniac:
fehlermeldungen werden mit der aktuellen mpeg_ps_extract version nur ausgegeben wenn der parameter verbose alleine oder verbose=3 oder größer angegeben wird (hat faup nicht im script mit drin - hätte ich vielleicht noch mal explizit erwähnen sollen...sorry)

ausserdem werden nur pes-längenfehler gemeldet d.h. wenn die paketgröße stimmt aber im packet ein paar bytes falsch sind wird das _nicht_ als fehler angezeigt - CRC summen werden, nach dem, was ich bis jetzt gesehen hab, nicht übermittelt also kann man den inhalt auch nicht prüfen (würde die sache sowieso noch nen ganzes stück langsamer machen als es schon ist ...))

hmm.. die suffix meldung kenn ich noch nich...

NACHTRAG:
die suffix meldung kommt davon das er ein inputfile nicht lesen kann (mglw. erkennt er eine option nicht richtig z.b. ein "-" zuwenig oder es ist noch nen bug drin - poste mal deinen aufruf mit parametern)

hi...

so hab mal aufgeräumt im SSEM 'hotfix' und das userinterface verbessert

es ist jetzt möglich eine datei nur zu scannen (nur sinnvoll mit verwendung von parameter verbose) auch die sync-files und audioextraction sind jetzt abschaltbar
mit dem parameter progress gibts ne fortschrittsanzeige

ich hab zwei patches angehängt:
* den SSEM v0.8 (mpeg_ps_extractor alleine - ist kein update d.h. bitte auf originalfile anwenden!)
* einen ALLPATCH - wie gewünscht alles in einem paket

achso:
im script die programmversion von 0.4 auf 0.8 ändern oder auf neues script warten

faup:
wäre schön wenn du die versionserkennung in deinem script dynamisierst d.h. die nummer extrahierst und einen mindestversionsvergleich einbaust (die 0.4 ist zwar jetzt alt aber trotzdem noch verwendbar) idF: version>=0.4
...ich denk' zwar nicht das da noch ne neue version kommt - wär aber besser...

@all:
bitte testet das ding erst mal - hab nur kurz getestet

ps: wer unbedingt PTS rollovers sehen will muss den debug-level verwenden (7)

hi

so langsam nervt die mpeg4ip library...

also ich hoffe das das der letzte patch war... da ich immernoch einen film hatte bei dem matroska mit einer 'merkwürdigen' fehlermeldung abbrach hab ich mir auch dort die dateien angesehen... mit dem ergebnis das die mpeg4ip-lib ohne patch eigentlich nicht für DVB aufnahmen geeignet ist...

es gibt einen designfehler bei der berechnung der zeitstempel (für die sync files) dort geht man scheinbar davon aus das zeitcodes nie 'überrollen' d.h. mitten im film wieder bei 0 anfangen (wie bei DVB üblich...) ...

lange rede kurzer sinn: patch einspielen und dann sollten auch die letzten nicht umwandelbaren filme gehen...
ich empfehle ALLEN, die vdr files in matroska files wandeln wollen dringenst den patch anzuwenden!!!

achso: ich habe versucht mit dem mplayer unter windows auf nem schnellen rechner nen film abzuspielen - mit bescheidenem erfolg: der mplayer kommt wohl nicht mit den zeitstempeln in dem matroska files klar (ffdshow lief problemlos) woraus ich folgere das mencoder auch dieses problem hat...

hoffentlich ist jetzt ruhe