Hauppauge Capture - HD PVR2 Af en toe problemen met conversie

Vraag me af of iemand oplossingen heeft voor een af en toe voorkomend probleem waarbij wanneer ik opneem met Hauppauge Capture als een TS-bestand en knip, de opname soms niet converteert. De TS zelf speelt wel goed af, maar zelfs als ik handmatig probeer te knippen met ffmpeg, krijg ik problemen. Het typische probleem is dat ik een bestand krijg dat erg kort is, bijvoorbeeld een tv-programma dat na knippen 40-45 minuten zou moeten zijn, is 20 minuten, of soms is het maar een paar seconden en toont alleen de hoesafbeelding.

Wanneer dit gebeurt, is de enige oplossing opnieuw opnemen. Gebeurt ook af en toe met MP4.

Ik heb OBS geprobeerd, maar niet succesvol iets kunnen krijgen dat er goed uitziet. Meestal heb ik vreemde horizontale vervaging en de meeste suggesties gaan over FPS, en het apparaat doet 60fps, dus 60 geprobeerd, 30 (iemand zei een veelvoud te gebruiken) en ik geloof 55, maar allemaal zijn ongeveer hetzelfde.

Klinkt alsof je tuner/opname driver corrupte video creëert tijdens een periode met zwak signaal.

Probeer dit:

  1. Wijzig je profiel order om eerst handbrake te gebruiken en daarna ffmpeg
  2. Schakel in de Conversion task → Expert settings Skip remuxing in

Dit zal ffmpeg omzeilen dat moeite lijkt te hebben met het verwerken van corrupte video en in plaats daarvan handbrake proberen het te laten afhandelen.

Ik zal het bij de volgende mislukking proberen. Ik denk niet dat ik eerdere mislukte bestanden heb bewaard.
Ik weet dat we dit eerder hebben besproken, en ik geloof dat ik Handbrake heb geprobeerd – dat is ook mislukt, maar dat is al een paar maanden geleden.

The Brothers Celebrating The Allman Brothers Band 50th Anniversary (2024).ts-TestingAV1Conversions-2024-09-06T18-58-04.log (7,2 MB)

Het is al een paar weken geleden, maar ik ben eindelijk een voorbeeld van een probleem tegengekomen. Ik heb gekeken naar de logbestanden, maar in dit geval denk ik niet dat het probleem bij de conversie ligt, maar bij het knippen. Ik gebruik EDL-bestanden die ik zelf maak met custom cuts, en de resulterende video lijkt twee delen te missen. De opname is van een PBS-zender die fondsenwerving houdt, dus er zijn een paar grote cuts, groter dan gebruikelijke reclameblokken. Er waren 5 cuts, inclusief begin en einde, dus 4 ‘goede’ stukken, en voor zover ik kan zien in het resulterende bestand ontbreken de laatste twee. De video zou ongeveer 1 uur moeten duren, maar is nu slechts ongeveer 38 minuten.
Iemand een idee?

Ik zie inderdaad 5 cuts geïdentificeerd

2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:0.000 End:61.301 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:1212.502 End:1753.003 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:2920.505 End:3536.006 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:4776.211 End:5307.011 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:5414.414 End:6543.000 Action:0

Vervolgens zie ik een fout bij het proberen van het knippen van het 3e segment

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!
→ Process exited with code -1094995529
→ FFMpeg output file size [KB] → 34.00

Daarna stopt het en knipt het de resterende segmenten niet meer (dat zou het niet moeten doen, dus het zou een bug kunnen zijn), maar het lijkt erop dat het originele bestand mogelijk beschadigd is.

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9216112, dts=9216113, size=14338
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9492388, dts=9492389, size=38037
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).

Kun je het originele TS-bestand en je .EDL-bestand uploaden zodat we het probleem kunnen reproduceren en kunnen zien wat er aan de hand is.

geüpload onder jsam01

Bedankt voor het voorbeeld. Het lijkt erop dat de originele video veel timestamp-corruptie bevat (waarschijnlijk veroorzaakt door een slechte OTA-signaal of een tv-tuner driver-probleem, wat kan worden opgelost door een andere versie van de tv-tuner driver te proberen of het OTA-signaal te versterken).

Er was een bug in MCEBuddy waardoor het de corruptie niet goed kon detecteren en daardoor de beschadigde video negeerde. We hebben dat opgelost in de nieuwste 2.6.5 bètaversie. Nu zal het de beschadigde video detecteren en als het de knipbewerkingen niet vóór de conversie kan uitvoeren, zal het proberen de videoproblemen tijdens de conversie te corrigeren en daarna proberen de reclameblokken te verwijderen. Wanneer dit gebeurt, duurt de conversie langer, maar het zou de video moeten kunnen herstellen en de reclameblokken succesvol kunnen verwijderen.

Probeer de nieuwste bètaversie en laat me weten hoe het gaat.

Ik heb 2.6.5 geprobeerd en het lijkt te werken, ik zag dat het de 2e keer aan het einde knipte. De knipsels zijn iets minder precies vergeleken met bijvoorbeeld het origineel - in ieder geval bevatte het begin van de video met 2.65 een beetje van wat ik probeerde te knippen.

Ik zal kijken of ik iets met het apparaat kan doen - het is geen tuner maar technisch gezien een video-opnameapparaat voor gaming, maar het heeft hdmi- en component-ingangen, dus ik gebruik component van mijn kabelbox. Ik zie dat de driver een hoger nummer lijkt te hebben dan beschikbaar is op hun website, wat een beetje vreemd is, en het is een vrij lange usb-kabel dus ik zou de box kunnen verplaatsen en een kortere nieuwere kabel kunnen proberen.

Ik heb het videobestand dat je hebt geüpload samen met het EDL-cuts-bestand door MCEBuddy 2.6.5 beta laten verwerken met het MP4 Unprocessed-profiel. Het heeft exact volgens het EDL-bestand geknipt, wat overeenkomt met het originele bestand. Ik heb geen verschil in de knippunten opgemerkt (niet meer dan ongeveer 1 seconde synchronisatie, wat gebeurt omdat sneden altijd op GOP-grenzen plaatsvinden, anders zou je videotearing zien).

Welk profiel gebruik jij?