Video corrupted during remuxing

Request Type:
BUG

EDIT: I’ve uploaded sample video and log file to FTP under wvladik folder

MCEBuddy Version and Type (32bit or 64bit):
2.4.7 64 bit
Operating System and Type (32bit or 64but):
Windows 7 64 bit
Summary of the problem or suggestion:
This video is from DVB-S2, recorded using Windows Media Center from spanish TV station M+ Formula1. However this error happens with all recordings from the broadcaster. Recordings from BBC HD, iTV HD UK do not showcase this error.

Steps to replicate the bug:
Convert video using any profile video is corrupted since video gets messed up by ffmpeg during mpegts remuxing. If i skip remuxing, and use Unprocessed mp4 (ie still using ffmpeg to copy) video is also corrupted.

I will attached the log file along with the video. In the log see the error 2017-08-26T21:14:06 MCEBuddy.AppWrapper.FFmpeg --> [mpegts @ 0000000006f46fa0] Non-monotonous DTS in output stream 0:2; previous: 260157215, current: 260153615; changing to 260157216. This may result in incorrect timestamps in the output file repeating over and over.

Rssulting video is very jerky/laggy while original wtv has smooth playback in WMC.

Screenshots:


Is there anything else I should provide to see if it can be fixed ?

I’ve uploaded video, logs to FTP. Let me know if there’s anything else I can do.

1 Like

You’re fine for now thanks. Will check it out

Checked out your logs, it’s full of errors in your source file:

2017-08-26T21:12:46 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000000006f46fa0] Non-monotonous DTS in output stream 0:2; previous: 11552016, current: 11550215; changing to 11552017. This may result in incorrect timestamps in the output file.

That’s why it’s stuttering. If you’re recording this via a TV tuner card, check it’s drivers, it appears to be sending corrupt/non compliant data. You should try to update them if possible. (even though it may playing back properly, the data itself is corrupted, different decoders handle it differently). In this case ffmpeg while remuxing it is not able to compensate for the errors.

You can try to avoid the remuxing by checking the Skip remuxing option in the expert settings of the conversion task and maybe the encoder might able to compensate for these errors. This will only work if you have the donator version of Comskip.

I did see the ffmpeg error message in the log file but it does not mean there is something wrong with the video … rather there is an issue with the ffmpeg that is used by MCEBuddy.

Video (original wtv) plays back in mce7, mpc-hc, kodi and plex smoothly (so i doubt there’s something wrong with it) but according to the log file , the current ffmpeg has issues with the timing of the frames.

There is nothing wrong with the tuner. I use the same tuner for ALL recordings and never have an issue EXCEPT with recordings from this broadcaster. I suspect they are using an option in h.264 encoder that current ffmpeg does not handle gracefully.

As far as skipping remuxing. I did try that but since I use profile where ffmpeg just copies video into the mp4 file - it again introduces stuttering.

1 Like