Heeft iemand enig idee of je door te doneren voor Comskip via https://www.comskip.org/ een andere, completere versie krijgt? Of is er geen verschil tussen de gedownloade versie en de donateur-versie?
Dank je wel!
Heeft iemand enig idee of je door te doneren voor Comskip via https://www.comskip.org/ een andere, completere versie krijgt? Of is er geen verschil tussen de gedownloade versie en de donateur-versie?
Dank je wel!
De donator-versie die bij MCEBuddy wordt geleverd is behoorlijk oud (versie 0.82.003 van 2017-09-30). De huidige donator-versie is 0.82.012 van 2022-02-25. Het opvallende aan de nieuwere Comskip donator-versie is een nieuwere ingebedde FFMPEG v4.3, en ondersteuning voor 4k en 10bit videoverwerking. De donator-versie is wat je mpeg4-videoverwerking geeft.
Het hoeft echter niet allerlei moderne codec-ondersteuning te hebben, omdat de meeste input-DVR-videoformaten toch al MP2 of MP4 zijn en bijna alle transcoding begint met een conversie naar MP2 voordat MCEBuddy comskip activeert. De hardware CPU/GPU-ondersteuning komt van de ingebedde FFMPEG in comskip.
Samengevat: ja, het zal de advertentieherkenning versnellen, maar overall is advertentieherkenning slechts een heel klein onderdeel van het gehele transcoding-proces.
Uiteindelijk is het een persoonlijke beslissing voor jou. Zou je er voordeel van hebben? Zeker. Mis je iets of krijg je een enorme prestatie-kracht als je het niet doet? Niet echt.
Een paar updates: we hebben een nieuwe donatorversie van Comskip in ontwikkeling. Deze is gebouwd tegen ffmpeg 6.1.1 en ondersteunt veel meer codecs, waaronder native HEVC- en AV1-decodering met een aangepaste av1-decoder voor maximale prestaties. Het voordeel (wanneer uitgebracht) is dat MCEBuddy niet langer hoeft te remuxen naar MP2, wat de conversiesnelheid en de uiteindelijke kwaliteit zal verbeteren. We testen ook native hardware-decodering voor hevc en av1 met die build, maar er zijn enkele uitdagingen met betrekking tot stabiliteit, dus we testen de afweging tussen hardware-decoderingsprestaties versus stabiliteit. Mogelijk bieden we gebruikers een optie om hardware-decodering in/uit te schakelen.
Dat is uitstekend en welkom nieuws om te horen!
Comskip draait eigenlijk alleen om decoderen, en aangezien de codecs opzettelijk zijn ontworpen om snel te worden gedecodeerd, en alleen met de CPU (zonder afhankelijkheid van GPU of zelfs iGPU), begrijp ik volledig de stabiliteit en het testen over alle generaties van zowel CPU’s als GPU’s van meerdere fabrikanten (met name Intel en AMD, en voor GPU’s ook nVidia). Nog afgezien van moederborden en alle interactie tussen mediaopslag, geheugen, CPU-cache en I/O-bussen (north/south bridges).
Het is geen eenvoudige klus, dus ik waardeer al het werk dat in een release gaat zitten, en maak je geen zorgen over haast.
Probeer de 2.6.4 bètaversie. We hebben nu een nieuwe aangepaste 64-bit build van comskip donator. Hij is veel sneller dan de oude comskip en heeft enkele leuke functies:
Met deze release is remuxen ook geoptimaliseerd, zodat er minder geremuxed wordt bij gebruik van onze build van comskip (het blijft compatibel met de standaard comskip en gratis comskip builds, maar dan zal het trager zijn), vooral bij het decoderen van codecs zoals AV1.
Wat hardware-acceleratie voor decodering met comskip betreft, moet je deze voorlopig handmatig inschakelen via Conversietaak → Expertinstellingen → Comskip-opties
Hier kun je --qsv invoeren als je een Intel-chipset hebt of --cuvid als je een Nvidia-gpu hebt.
Probeer het uit en laat ons weten hoe het voor je verloopt. Ter vergelijking: we hebben geen verbetering in comskip-prestaties gezien bij het decoderen van h264-bronvideo’s, maar wel een verbetering van ~30%-50% bij het decoderen van HEVC/H.265-bronvideo’s. Het enige wat we nog niet hebben kunnen testen is de decodeerprestatie van comskip op AV1-bronvideo’s. Als je chipsets hebt die AV1-bestanden kunnen decoderen, probeer het dan gerust uit en deel je resultaten met ons. Als je een AV1-bronvideo nodig hebt om te testen, gebruik dan gewoon het AV1-profiel van MCEBuddy om een AV1-video-uitvoer te maken. De logbestanden tonen je de gemiddelde FPS voor comskip (en de totale tijd). We hebben 1500+ fps gezien voor HEVC-bestanden bij gebruik van hardware-decodering.
Let op: De reden dat we hardware-decodering voor comskip niet standaard hebben ingeschakeld, is omdat we hebben gemerkt dat het vastloopt als de onderliggende chipset te oud of niet ondersteund is. We zullen dit in de toekomst waarschijnlijk optimaliseren.
Ik vraag me af wat de use case is voor comskip en andere video-encodingformaten? Is Blu-ray X.265? Hebben we 4K ATSC3 OTA DVR’s die naar H.265 encoderen en waarvan de media reclames bevat die met comskip verwijderd moeten worden?
Hetzelfde geldt voor AV1-media. Mijn excuses als ik niet helemaal op de hoogte ben van betaalde diensten zoals YouTube Premium die live OTA-kanalen streamen in H.265 of AV1 en waar nog steeds advertenties in de content worden geïnjecteerd die mensen willen verwijderen (via comskip).
Also, Bezos kan toch gewoon even zijn handen afhouden van de avocado toast, frappes en luxe jachten en Prime Video reclamevrij houden. Ik bedoel, zijn vermogen is tijdens de pandemie met 50% gestegen en hij betaalt nog steeds bijna geen belasting. Maar ik dwaal af.
Heeft iemand voorbeelden van DVR’s die invoer- en uitvoervideosources met advertenties hebben in AV1 of H.265? Welke DVR’s en welke videosources? Aanbevelingen voor producten om mijn verouderde Tivo Roamio OTA (ATSC1.0) en Silicon Dust HD HomeRun Quattro-tuners en DVR te vervangen?
nvdec-logboeken hieronder op een RTX 4000 Ada. Ik zag dat er nieuwere versies van ffmpeg en HandBrake beschikbaar zijn.
nvdec.zip (924,2 KB)
arc logs hieronder
qsv.zip (909,3 KB)
Deze benchmarks zijn super nuttig, heb je toevallig de logs van de software-run (zonder --qsv of --cuvid)?
De resultaten tot nu toe zijn:
| Comskip (FPS) |
Nvidia (–cuvid) |
Intel (–qsv) |
Software (libdav1d) |
|---|---|---|---|
| MPEG2 | 688 | 146 | |
| H.264 | 598 | 144 | |
| HEVC | 448 | 98 | |
| AV1 | 117 | 339 |
*QSV AV1 comskip is blijven hangen en niet voltooid op jouw systeem, waarschijnlijk door een grafische-stuurprobleem waardoor het niet meer reageerde
software logs hieronder.
software.zip (1,0 MB)
@techpro2004 Wat is je broninvoervideo, duur, formaat, resolutie en bevat het advertenties?
Gewoon algemene info, b.v. DVD-rip, 90 min, MPEG2, 480p, enz.
Hoe heb je op- en afschaling en transcoderingskwaliteit gecontroleerd over de verschillende formaten heen?
Ik wil een vergelijkbare benchmark uitproberen met iets dat vergelijkbaar is voor mijn systeem. Ik kan OTA 1080i HD, 720p HD of 470p SD opnemen. Ik heb mijn SD HDHR DVR ingesteld om de ruwe HDTV-stream op te nemen. En ik weet dat er andere mediaformaten, resoluties, codecs en bitrates op het web beschikbaar zijn als ik die nodig heb.
Ik heb een programma opgenomen met Channels DVR vanaf mijn HDHR. Vervolgens heb ik het getranscodeerd naar verschillende formaten in MCEBuddy. Het was een 30 minuten durend MPEG2 1080i-bestand. Het bevat advertenties.
Bedankt. Ik zal dit weekend iets vergelijkbaars proberen draaien.
Als ik MCEBuddy goed begrijp, start het comskip vóór de transcoding op de ruwe invoer (bijna altijd MPEG2), markeert de video, knipt, en transcodet daarna naar de doel-encoding en -formaat.
Of transcodet het eerst, zodat comskip de reclames scant en markeert in de uitvoer-encoding (bijv. H264, HEVC, AV1), niet in de invoer-encoding (MPEG2).
Het lijkt me dat de invoer bijna altijd MPEG2 is; waarom zou comskip dan markeringen in de uitvoerformaten beter maken?
Of zitten in die tijden ook de transcoding-tijd mee, en gaat het niet puur om de comskip-verwerking (om reclames te markeren)?
Historisch gezien wordt eerst getranscodeerd en vervolgens comskip uitgevoerd. De reden dat we deze nieuwe codecs en hardwareversnelde comskip-builds hebben, is om indien mogelijk transcodering te vermijden en zo het proces sneller te maken en andere problemen te verminderen die transcodering in specifieke gevallen kan veroorzaken (vooral wanneer de opnamekwaliteit is verminderd). Dit geeft Comskip ook de beste kans om op de originele video te werken.
Dit zijn geweldige benchmarks. Kun je bevestigen welke Intel-chipset je gebruikt voor QSV? Er wordt gemeld dat het een 13e generatie Raptor Lake-chipset is - wat niet juist klinkt - volgens de Intel-specificaties zou Raptor Lake geen AV1-codering moeten ondersteunen, maar jouw chipset ondersteunt dit duidelijk wel.
Zeer interessante resultaten van @techpro2004
Nvidia (cuvid) presteert duidelijk beter dan Intel (qsv) bij het decoderen van MPEG2, H.264 en HEVC, maar Intel overtroeft Nvidia ruimschoots bij AV1-decodering.
Bovendien presteert de AV1-libdav1d-decoder ver boven de HEVC-decoder.
*QSV AV1-decodering was onvolledig vanwege een driver-hang
Het qsv-systeem is een 13e generatie desktop, maar heeft ook een pcie arc a310 geïnstalleerd. bedankt.
Eén ding over de nVidia 4000-serie kaarten – de 4070Ti en hoger hebben 2 NVENC-eenheden, dus de hogere kaarten kunnen een significante prestatieverbetering bieden ten opzichte van de middelste en lagere kaarten. Ik weet niet of dat resulteert in snellere transcoding voor een enkele AV1-taak (beide NVENC-eenheden worden gebruikt) of dat het betekent dat je 2 NVENC-encodingtaken tegelijk kunt uitvoeren (misschien zelfs met verschillende codecs). Er is echter maar 1 NVDEC-eenheid.
Het kan zijn dat, voor transcoding-doeleinden en MCEBuddy, de hogere kaarten met 2 NVENC-eenheden geen voordeel bieden ten opzichte van de lagere kaarten. Het zou echter kunnen dat het wel uitkomt in een systeem dat ook Plex draait, bijvoorbeeld, waarbij MCEBuddy bezig kan zijn met zijn werk op één NVENC-eenheid en Plex de andere kan gebruiken om on-the-fly te transcoderen voor een speler zonder de prestaties te verstoren.
rtx 4080-logs hieronder
cuvid 4080.zip (910,3 KB)