# Video corrupted during remuxing
**URL:** https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511
**Category:** General Support / Questions
**Created:** [August 27, 2017, 10:07am UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511 "2017-08-27T10:07:35Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@wvladik](https://discussion.mcebuddy2x.com/u/wvladik)
#### Post date: [August 27, 2017, 10:07am UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511/1 "2017-08-27T10:07:35Z")
**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:**
* * *
---
### Author:  [@wvladik](https://discussion.mcebuddy2x.com/u/wvladik)
#### Post date: [September 1, 2017, 6:48am UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511/2 "2017-09-01T06:48:07Z")
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.
---
### Author:  [@RBoy](https://discussion.mcebuddy2x.com/u/RBoy)
#### Post date: [September 1, 2017, 10:59am UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511/3 "2017-09-01T10:59:27Z")
You’re fine for now thanks. Will check it out
---
### Author:  [@RBoy](https://discussion.mcebuddy2x.com/u/RBoy)
#### Post date: [September 1, 2017, 4:28pm UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511/4 "2017-09-01T16:28:10Z")
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.
---
### Author:  [@wvladik](https://discussion.mcebuddy2x.com/u/wvladik)
#### Post date: [September 2, 2017, 6:55am UTC](https://discussion.mcebuddy2x.com/t/video-corrupted-during-remuxing/511/5 "2017-09-02T06:55:31Z")
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.