TS unprocessed with Comskip causing increased artifacts

#1

Request Type:
BUG / NEW FEATURE

MCEBuddy Version and Type (32bit or 64bit):
x64, 2.4 r11

Operating System and Type (32bit or 64bit):
Win7 x64

Summary of the problem or suggestion:
If you use the “TS unprocessed” conversion task with Comskip, the resultant video is corrupted and won’t play or will have bad color. It is easiest seen using the Windows Media Player. They will play better in VLC but you can still see some of the problems.
Using Show Analyzer is not as problematic, but I did see the bad color in one video (and one conversion did fail one time on one video). Converting to MP4 with Compskip is okay.

Steps to replicate the bug:
Configure the “TS unprocessed” conversion task to use Comskip (default INI). Convert a TS file (recorded from TV tuner).
Play the video - if it plays at all it will be blocky and large portions missing.

Screenshots:

image
image.png430×815 22.6 KB

log
mcebuddy.log.zip (39.9 KB)Babel_20190901_1200.ts-TS unprocessed-2019-09-05T18-31-32.4834587-05-00.log (465.5 KB)

#2

Strange I used that same process for the last year with good results. I am on Windows 10 and was using an older version of mcebuddy.

#3

Well, the version is something to note. I was using the free version (for a long time) w/o issue. I just recently purchased the new version.

#4

It’s working fine here. It maybe something specific to your recording. I don’t see the conversion log. You can upload the original video and conversion log to our server and we can check it out.

#5

Another thing to consider. Are you certain the blocking is not there in the original? Are you archiving the originals or allowing mcebuddy to delete?

Just a thought could be a bad signal.

#6

The original is fine. I tried on two videos, one 480p and one 1080p.
I don’t know where the conversion logs are.

#7

In the logs folder, each file has it’s own conversion log.

#8

Not if job logs are turned off :slight_smile: I just uploaded a log.

#9

I checked out your logs, it appears that’s some issue with the original video:

2019-09-05T18:35:09 MCEBuddy.AppWrapper.FFmpeg --> [mpeg2video @ 0000000002a72940] Invalid frame dimensions 0x0.
2019-09-05T18:35:09 MCEBuddy.AppWrapper.FFmpeg --> Last message repeated 4 times
2019-09-05T18:35:09 MCEBuddy.AppWrapper.FFmpeg --> [mpegts @ 0000000002a71000] PES packet size mismatch
2019-09-05T18:35:09 MCEBuddy.AppWrapper.FFmpeg --> Last message repeated 4 times

Whether it’s minor or major I can’t say. The only difference between comskip and showanalyzer is that they have different detection algorithms, so the commercial marker points would differ. It’s possible that the marker points selected by Comskip have some video data corruption at those points in the original video may be causing the issue. Have you tried playing back the converted file in VLC? Sometimes it’s the player codec which has issues.

The only way to tell would be to look at the original and converted videos. If you upload them to the MCEBuddy server I can check them out.

#10

Videos uploaded to FTP server.

#11

Thanks, I checked them out. Your original video has a ton of artifacts when played back in Windows 10 Media Player. Those artifacts are amplified after cutting them, nothing to do with Comskip. It’s just the locations of the cuttings identified by comskip have a more artifacts and errors at those locations than those identified by ShowAnalyzer, either way the issue is with the recording. If you’re using a tuner card, check your signal as these artifacts don’t show up a timing errors (which would indicate a problem with the firmware/driver) but as part of the signal stream itself.

#12

So why do they look okay if I convert to MP4 (along with using Comskip)? Does the conversion or compression cover up or ‘fix’ the obvious errors?

#13

Yes the conversion filters in non Unprocessed profiles try to smoothen the video artifacts and correct minor errors where possible. Unprocessed profiles copy the video unaltered.