Das sieht gut aus.
Vielen Dank!
Das sieht gut aus.
Vielen Dank!
Die Version 3.0.15 ist auf vdr-plugin-markad verfügbar.
- neue "deprecated" Warnung für libavcodec 56.60.100 (ffmpeg 2.8.17) und älter. Wer das noch hat, es wäre mal Zeit für einen Update.
- SegFault fixed, wenn keine Start Marke gefunden wurde, aber eine horizontale Balken Ende Marke der vorherigen Sendung als Start Marke verwendet werden kann (thx heifisch for reporting).
- Verbesserung der Erkennung von kurzen Einspielungen mit Balken innerhalb von Dokumentationen (thx heifisch for reporting).
Und wie immer: viele kleine Fehlerbereinigungen und Optimierungen.
Grundsätzliche Anmerkung zu unterstützten ffmpeg Versionen:
Mit der Zeit wird der Decoder Code immer unübersichtlicher aufgrund zahlreicher Compiler Direktiven für die verschiedenen libavcodec Versionen. Darum kann ich nicht nur hinzufügen, sondern ich muss auch mal alte raus löschen. Da ich selber Ubuntu nutze, orientiere ich mich bei den unterstützten ffmpeg Versionen an dem, was Ubuntu mitliefert, die meisten anderen Distributionen liefern eh neuere Version mit. Über begründete Sonderwünsche können wir gerne diskutieren.
ffmpeg aus aktuellem Ubuntu im Standard Support (also im Moment ab 18.04 mit ffmpeg ab 3.4.8) -> wird voll unterstützt
ffmpeg aus Ubuntu ohne Standard Support aber mit LTS Support (also im Moment 14.04 und 16.04 mit ffmpeg ab 2.7.2) -> Grundfunktionalität wird unterstützt, aber möglicherweise gehen nicht alle Features.
Alles was älter ist wird irgendwann rausfliegen. Damit sind bis zu 8 Jahre alte ffmpeg Version möglich, das sollte wohl jedem reichen, mal einen Update zu machen.
Die Version 3.0.16 ist auf vdr-plugin-markad verfügbar.
Die Version kommt jetzt mit großen Einblendungen über die horizontalen oder vertikalen Balken klar, wie es ein Sender vor kurzen neu eingeführt hat (thx heifisch for reporting). Es wird halt immer ein Anpassen an aktuelle Veränderungen notwendig sein.
Und wie immer: viele kleine Fehlerbereinigungen und Optimierungen.
Die Version 3.0.17 ist auf vdr-plugin-markad verfügbar.
Diesmal sind Optimierungen bei der Erkennung von doppelten Szenen vor und nach der Werbung sowie bessere Erkennung von Werbung im Rahmen mit Senderlogo drin.
Und wie immer: viele kleine Fehlerbereinigungen und Optimierungen.
naja .... ich korrigiere die Schnittmarken vor dem Schneiden manuell, damit ich bei der transcodierten Datei dann nicht zwischendrin irgendwelche Zwischenbilder mit Werbelogos habe.
An so einem Beispiel hätte ich Interesse, vielleicht kann man das besser machen. Du kennst ja schon den Weg, tar auf das Aufnahmeverzeichnis und Link per PM.
ich suche dir mal was raus ...ich habe festgestellt, dass bei den Aufnahmen die Schnittmarke, welche den Beginn der Werbung markiert öfter auf den ersten Frames im Werbeblock liegt. Beim Ende der Werbung sitzt die Schnittmarke dann genau oder um ein zwei Frames versetzt. Eine Abhängigkeit vom Sender kann ich da nicht festmachen.
Ja, gerne. Wie schneidest du das Video, mit markad oder mit der Schnittfunktion vom VDR ?
Edit: Wenn möglich ein Beispiel, wo nicht nach Logo Marken geschnitten wird. Ich habe da schon einen Verdacht und Logo Marken sind leider nie so Frame genau und somit nochmals eine zusätzliche Baustelle.
Ich schneide mit dem VDR …. Schaue mir zuerst die Aufnahme an und sehe wie die Schnittmarken sitzen. Ggf. Korrigiere ich diese mit der Taste 0. anschließend drücke ich die 2.
Verwendet Markad andere Marken?
Verwendet Markad andere Marken?
Andere nicht, aber es entfällt die Fehlerquelle von der Wandlung Framenummer (markad intern) -> Zeit (marks File) -> Framenummer (VDR intern). Außerdem macht VDR Schnitte nur an i-frame Grenzen, markad kann mit "--cut --fulldecode --fullencode=all" auch Frame genau schneiden. Das sollte aber nicht das Problem sein, an i-frame Grenzen schneiden sollte vollkommen reichen und es geht viel schneller weil nicht neu encodiert werden muss.
Ich vermute dass das Problem an der Umwandlung Framenummer -> Zeit -> Framenummer liegt. Also der VDR die Zeit anders in die nächst gelegene i-Framenummer umrechnet, wie ich es erwarte. Mir fällt das nicht auf, da ich VDR nur als Backend nutze und mit markad schneide. Damit habe ich das Problem nur sehr selten und dann liegt die Ursache am nicht exakt erkanntem Logo Ende.
Das Beispiel von dir wird mir zeigen, ob mein Verdacht stimmt ...
Hi!
I'm having problems with the Finnish Nat Geo HD channel. The show is Dr. K's Exotic Animal ER. For some reason the ad marks are always late, sometimes a minute, sometimes about three minutes. The start of the ads is detected late and also the stop of the ads is detected late. This might be because Nat Geo has two sets of ads. Ads for their own shows are separate from the other ads that they run.
I have compiled markad manually, I'm currently running commit 83fc08bfrom the branch V03. kfb77 if you have time to look at this issue, I can post logs.
For channels I can not receive it would be much simpler if I can look into the recording and keep it as test case.
Can you please tar the recording directory and send me a download link via PM.
Here the result of a first look into your files:
0:14:41.06 ( 22030) moved stop mark ( 22030) before logo stop mark ( 22106) at 0:14:06.08, silence detected
The first logo stop was detected correct at 14:04min and then moved to 14:41min because of a detected silence part. This is not valid because:
1. Marks should never moved so far away from the logo mark.
2. 76 frames away should be about 2,5s and not 35s
3. frame 22030 should not have a timestamp greater than frame 22106.
I tested your recording with full decoding (--fulldecode) and analyse internal timestamps (--pts). I got:
Frame PTS (14:04) could only be bigger than timestamp based on frame count / fps (14:42) if there are frame missing in the recording, but never smaller.
Something very strange is going on, more in the next days.
I found frames with only the half of usual duration in this stream (e.g. frame 203 und 204).
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): filenumber 1, frameNumber 192, framenumber timeOffset_ms 7680, PTS timeOffset_ms 7680
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 193, DTS 3967823055, PTS 3967830255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 194, DTS 3967826655, PTS 3967826655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 195, DTS 3967830255, PTS 3967833855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 196, DTS 3967833855, PTS 3967851855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 197, DTS 3967837455, PTS 3967844655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 198, DTS 3967841055, PTS 3967841055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 199, DTS 3967844655, PTS 3967848255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 200, DTS 3967848255, PTS 3967866255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 201, DTS 3967851855, PTS 3967859055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 202, DTS 3967855455, PTS 3967855455, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 203, DTS 3967859055, PTS 3967862655, duration 1800, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 204, DTS 3967860855, PTS 3967864455, duration 1800, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 205, DTS 3967862655, PTS 3967880655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 206, DTS 3967866255, PTS 3967873455, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 207, DTS 3967869855, PTS 3967869855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 208, DTS 3967873455, PTS 3967877055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 209, DTS 3967877055, PTS 3967895055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 210, DTS 3967880655, PTS 3967887855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 211, DTS 3967884255, PTS 3967884255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 212, DTS 3967887855, PTS 3967891455, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 213, DTS 3967891455, PTS 3967909455, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 214, DTS 3967895055, PTS 3967902255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 215, DTS 3967898655, PTS 3967898655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 216, DTS 3967902255, PTS 3967905855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 217, DTS 3967905855, PTS 3967923855, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 218, DTS 3967909455, PTS 3967916655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 219, DTS 3967913055, PTS 3967913055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 220, DTS 3967916655, PTS 3967920255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 221, DTS 3967920255, PTS 3967938255, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 222, DTS 3967923855, PTS 3967931055, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 223, DTS 3967927455, PTS 3967927455, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 224, DTS 3967931055, PTS 3967934655, duration 3600, flags 0
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): framenumber 225, DTS 3967934655, PTS 3967952655, duration 3600, flags 1
Mon Nov 29 16:34:34 [116342] DEBUG: cDecoder::GetNextPacket(): filenumber 1, frameNumber 225, framenumber timeOffset_ms 9000, PTS timeOffset_ms 8960
Alles anzeigen
In your tar there was a cut video by markad. In this file the cuts seems to be correct.
You have "only" the problem, if you use the marks with vdr. Is that correct ?
Die Version 3.0.18 ist auf vdr-plugin-markad verfügbar.
Heute ist dieser Thread genau 2 Jahre alt. Eigentlich dachte ich damals, das ist mit "ein paar API Calls auf den aktuellen Stand bringen" nach ein paar Wochen erledigt. Das war ein großer Irrtum. Den Sendern fallen laufend neue Dinge ein, die Anpassungen erfordern. Diese Version enthält mal wieder ein paar solch kleinerer Anpassungen.
Wie man aber an den Versionsnummern sieht, gab es schon lange keine neuen Features mehr. Da bin ich seit ein paar Monaten mit der Umsetzung meiner ursprünglichen Ideen durch und wohl an den Grenzen des für mich (und unseren CPUs) machbaren angekommen.
Da dieser Thread nach 2 Jahren noch nicht eingeschlafen ist, sind wohl auch immer wieder Probleme zu lösen. Vielen Dank für eure Beiträge, Feedbacks, Bug Reports und Likes. Hinweise auf Dinge, die nicht funktionieren, sind immer gerne willkommen.
…danke für Deine unermüdliche Arbeit. Markad ist eins DER Argumente FÜR den VDR !
öfter auf den ersten Frames im Werbeblock liegt
Bitte teste mal so einen Fall mit den Branch V03. Bei der Fehlersuche zu einem anderen Problem, bin ich zufällig genau auf so einen Fall gestoßen.
Das ist kein Bug, das ist ein Feature zum Auffinden von 0 Byte Aufnahmen.
OK, wenn es dir nicht gefällt, es ist jetzt im Branch V03 gefixed. Danke für den Hinweis.
vpv Please test with branch V03. It includes now a fix for the calculation of the timestamp in the marks file for such type of recordings.
Works great, thank you! I think it now also works better with the Finnish "Frii HD" channel, which airs Discovery programs, but I have too few saved recordings to be sure.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!