Cypheros Transportstream Forum

Ich bin im Moment etwas perplex (ok, Leute, die mich kennen, werden behaupten, dass sei der Normalzustand, alles nur Fake News!)
Ich enkodiere einen Film mit Handbrake, als Encoder nehme ich inzwischen die Grafikkarte (musste etwas lange experimentieren, bis annähernd die selbe Qualität und Dateigrösse rauskommt, aber inzwischen ist es durchaus akzeptabel).
Das flutscht dann so mit bis zu 500fps ab, je nach Zusatzaufgaben wie Entrauschen oder Nachschärfen oder Farbanpassung.

Alles gut, nur ein Blick in den Taskmanager zeigt mir:

Du darfst in diesem Board keine Dateianhänge sehen.

(ist nur ein Ausschnitt, die anderen 20 Kerne sind genauso belastet, aber wir wollen ja keinen Neid bei Scheffe erzeugen  )
Die GraKa wird nur zu 6% geärgert (in der Detailansicht wird 54% für den Encoderteil angezeigt, der Rest schläft friedlich), die CPU ist aber doch noch stark involviert ?!?!?!?
Die zweite GPU wird gar nicht verwendet, da wird noch Potential verschenkt.

Irgendjemand eine plausible Erklärung, warum die CPU so belastet ist?

Zitat von: Cypheros am März 29, 2024, 23:00:13Ob das aber auch anderen Zugute kommte ist fraglich, da nur der DVBViewer mehr als eine PAT und PMT im Stream speichert.

Na ja, DVBViewer ist ja nun nicht das seltenste Programm für die Windows Welt. Ein paar andere wirds dann wohl auch betreffen.
Ich bin halt faul, die ganzen Receiver sind mir einfach zu lahm um die Aufnahmen zu übertragen. Ein Windows Server PC mit DVBViewer und 10G LAN geht da bretzliger ab 
(Im Alter will man ja keine Lebenszeit mit Warten verschwenden)

Ach ja, was mich noch stutzig macht: Bei DVBViewer habe ich natürlich "Aufnahme neu starten bei Senderwechsel" aktiviert. Das sorgt dafür, dass bei Wegfall oder Hinzufügen von Streams die alte Aufnahme beendet wird und eine neue gestartet wird. Das passiert manchmal bei WDR NDR und Co aber bislang noch niemals bei BBC Kanälen... Ist das wieder eine andere Baustelle? (nicht für den Doc natürlich)

Nein, Update hat nichts mit deinem Problem zu tun.

Bei deiner Aufnahme wird keine brauchbare PMT gefunden, die die Sprach-Infos enthalten, da die gefundene PAT nicht zu dem Stream passt.

Die nächste Version 4.0.39 wird das Problem bei deiner Aufnahme beheben. Ob das aber auch anderen Zugute kommte ist fraglich, da nur der DVBViewer mehr als eine PAT und PMT im Stream speichert.

hmm, wenn sich der bug fix in der 4.0.38 auf meinen Fehler hier beziehen sollte, lautet die traurige Erkenntnis: GEHT IMMER NOCH NICHT!!!

Da ihr ja unterbeschäftigt seid, wartet eine kleine Denksportaufgabe auf dem FTP Server auf euch     

Phänomen: Zu immer derselben Tageszeit wechseln Sender mal ihre Kennung / Inhalt. Hier wird um 20:00 rum BBC Ceebies zu BBC 4. Aufnahmen haben ja immer einen Vorlauf, so dass am Anfang der Wechsel immer mit drauf ist.

Der Doc erkennt netterweise den Wechsel, und erstellt automatisch eine _fixed Datei mit dem Inhalt des "neuen" Senders.

Soweit, so gut, aaaaaber:
Bei der Fixed Datei gehen alle Infos über die Streams verloren. Alle Tonspuren sind auf einmal "deutsch", was sie in diesem Falle nun wahrlich nicht sind. Das wäre so noch kein wirkliches Problem, aber da ALLES "deutsch" ist, muss man sich nun im Player jede Spur einzeln anhören um die wirkliche Spur zu finden und die Narrativ Spur deaktivieren zu können.

Das kriegt ihr sicherlich besser hin     

Thanks very much for the explanation!

TS-Doctor removes filler data broadcaster uses to keep the overall bitrate more or less constant. As this is only needed for the broadcast via cable, satellite or antenna, it can be removed safely from the recording.

This does not affect the video or audio quality.

I have been using TS Doctor for a umber of months now and find it a great product and is much quicker at  stripping out commercials from TV recorded films compared to movie editing software I had been using before.
I am curious though as to how TS Doctor manages to reduce file sizes by so much, even after taking into account the space taken up by commercials.
One movie I have just edited went from 3.6GB to 1.6GB.
Certainly when I look at the properties of both the before and after edited files there is no difference in the data and bitrate.

Danke für den schnellen Fix !
Immer wieder interessant, wie schnell man wieder neue Bugs einbauen kann...

Ist in der Version 4.0.37 gefixt.