This project has moved and is read-only. For the latest updates, please go here.

New ffmpeg version - not Remuxing properly

Oct 13, 2013 at 7:36 PM
Edited Oct 13, 2013 at 7:47 PM

I just upgraded to newest 2.3.14 but again BBC HD files are failing remuxing. Previous version of MCEBuddy ( the one before ffmpeg version change ) remuxed file fine.

here is the log file:
log file

Can we go back to previous or fix the current ffmpeg ? thanks
Oct 13, 2013 at 8:28 PM
I need a copyof the video that is failing, I'll take this up with ffmpeg to fix it, but I need the failing video for that.
Oct 13, 2013 at 11:01 PM
while you're uploading the original, are you saying the move from the 2.3.14 old ffmpeg to the 2.3.14 with the new ffmpeg has caused the issue? (or is it 2.3.13 to 2.3.14)
Oct 13, 2013 at 11:30 PM
Here's an easy way to upload the file:

FTP SERVER: (TIP: Open this link in Windows Explorer and you can upload and download file by dragging and dropping them)
Oct 14, 2013 at 6:55 AM
File is 13gb in size (2hr HD) and I'm not sure resizing/trimming it would represent the file properly.

I've uploaded the file to my Dropbox but when I get home tonight I will initiate the upload to your FTP server., if size is okay.

I will post logs from previous version of MCEBuddy.
Oct 14, 2013 at 1:42 PM
Size is fine not an issue. Or send me the Dropbox link

Oct 14, 2013 at 6:01 PM
Original file

I will try to post logs from previous version later tonight/
Oct 14, 2013 at 9:00 PM
For some reason it keeps disconnecting me from the server after about 1.5 to 2GB.
Can you set the file to upload to the MCEBuddy server?

I tested the short 2GB versions which downloaded and they appear to be working fine, so I'm guessing it's the full size 12G or so which is causing grief to ffmpeg.

Oct 15, 2013 at 2:17 AM
no worries, I managed to download the entire file. Just upload the old log so I can compare it.

Oct 15, 2013 at 4:20 AM
confirm the issue, I've raised it with ffmpeg team. Apparently it only happens wiht very large files, > 10GB types.

Meanwhile I've made a new custom build using the same code base as the previous version but with all the new goodies like the new aac codec. So literally its best of both worlds (with the exception of zvbi teletext support which is not really a priority for now).

I'll make a new build and put it up on the server tonight and that should solve your problem.

Oct 15, 2013 at 5:55 AM
That is awesome and your help is very much appreciated. Thank you very much !!!

(sorry for not providing logs from previous version but little one was demanding attention :-) )
Oct 19, 2013 at 6:46 PM
Edited Oct 19, 2013 at 6:49 PM
Oct 20, 2013 at 6:39 PM
Edited Oct 20, 2013 at 6:39 PM
I'm sorry to bring this up again but I've been testing and testing this weekend and came to conclusion that ffmpeg remux just isnt good enough for UK's BBC HD channels.

Based on suggestions and recent fixes I've tested 2.3.14 10/16/2013 version with Fast Remux and all BBC HD videos that are remuxed with ffmpeg (does not matter whether it is fast/slow) are choppy/laggy. ( I also tried specifying -r 25 and -r 50 in the ffmpeg Remux parameters but that made no difference ).

I've made one sample which shows what I'm talking about. Please try to watch all files in most recent VLC to see how choppy video gets between 7:50 - 8:10 minute mark.

This is original capture. No stuttering at all and plays in MCE and VLC smoothly
Original File

This is Fast Remuxed file that was remuxed with defaul Fast Remux parameters ( stutter very visible at 7:50 min through 8:20 min )
ffmpeg remux

This is Byte remuxed file (By using parameter UseWTVRemuxsupp=true in my profile) Resulting video is as smooth as original wtv file without any ffmpeg stuttering
Remuxsupp file

I've tried using most recent Handbrake (0.9.9) directly and Handbrake GUI encoded video without any problems without any lag/stutter to all Presets I've tried.
I'd like to use Handbrake profiles in MCEBuddy all the time ( to take advantage of all features) and skip Remuxing altogether, But if Remuxed file has stuttering then all MCEBuddy files will be laggy regardless of what encoder is used to actually encode.

Is there any hope for MCEBuddy to by-pass Remuxing ?
Oct 20, 2013 at 7:16 PM
You can always configure mcebuddy to force use byte remuxing. See the documentation.

Meanwhile I'll looking into what happened here. Which was the last working version of ffmpeg for you?

Oct 20, 2013 at 7:55 PM
Edited Oct 20, 2013 at 7:56 PM
Actually I've tried 2.13 and current 2.14 and they all produce laggy Remuxed videos ( when using ffmpeg remux). Reason why I did not notice it in 2.13 (and earlier 2.3.14) was that Fast Remux was failing automatically thus always falling back to Byte Remuxing.
Oct 21, 2013 at 12:00 AM
I've raised the issue with ffmpeg, you can also vote for it if you'd like to support ogetting fixed

Also for now you can use


in your profile

Marked as answer by rboy1 on 1/29/2014 at 9:06 AM
Oct 21, 2013 at 10:32 AM
Edited Oct 21, 2013 at 10:49 AM
Thanks for looking into this. I will vote for the bug.

As far as UseWTVRemuxsupp=true setting in the profile.... what would be the order of Remuxing if I include it in my profile?

1, Remuxsupp
2, Fast Remux (ffmpeg)
3, Slow Remux (ffmpeg)
4, WTV remux


Also is there anyway to directly jump to encoding wtv ??? (since both handbrake and ffmpeg convert them fine (with ffmpeg only -vcodec copy produces laggy video)
Oct 21, 2013 at 2:06 PM
Yes that's correct.

No there is not way to directly jump since remixing is a critical step in the overall process.

Btw I have seen files that work through ffmpeg remuxing but fail when ffmpeg tries to access them directly from wtv format

Oct 27, 2013 at 9:57 PM
Edited Oct 27, 2013 at 9:59 PM
With version from 25th, the order of remuxing options does not work.

Byte Stream remuxing fails ( i dont know why ) and, fast nor slow remux is attempted.

I attach the log. by the way, file converts in handbrake fine.

EDIT: to be honest, it doesnt seem to be an issue with remuxing but MCEBuddy this time. While MCEBuddy attempts to remux the file, no .ts file is even created in temp folder....
Oct 28, 2013 at 2:48 AM
Please try today's build. I was experimenting with some ultra fast remixing options. Have restored the functionality in today's build. Sorry about that.

Let me know if it still doesn't work with the log file.

Oct 28, 2013 at 4:18 AM
Edited Oct 28, 2013 at 4:38 AM
Wow remux in the 10/27 build is crawling... Uninstalled and resintall 10/09 build ....

10/09 took about 3 minutes
10/27 build says over 2 hours and still climbing at only 14% done :(

I'll post a log file in the morning, one it finishes

Hmm after uninstalling 10/09....installing 10/24 and uninstalling...then reinstalling 10/27 It appears to be working again.... odd

Wish I would have saved the old log files...forget they delete with the uninstall :( So ignore this for now... 2 conversions running about 3 minutes again for remux
Oct 28, 2013 at 5:25 AM
Can you post the log for the 10/27 and 10/9 build. Also if possible can you upload the ORIGINAL file to the mcebuddy server.

In the 10/27 build specify
UseWTVRemuxsupp=true in the profile and let me know if that speeds it up.

Oct 28, 2013 at 7:51 AM
vladik007 wrote:
With version from 25th, the order of remuxing options does not work.

Byte Stream remuxing fails ( i dont know why ) and, fast nor slow remux is attempted.

I attach the log. by the way, file converts in handbrake fine.

EDIT: to be honest, it doesnt seem to be an issue with remuxing but MCEBuddy this time. While MCEBuddy attempts to remux the file, no .ts file is even created in temp folder....
you're right, while streamlining the process, I made a logical error. When UseWTVRemuxsupp is defined it did not fall back to other mechanism's. The issue with remuxsupp is that it's very unreliable and unstable, while it works with 70% of the file it fails with 10% but then 10% it makes the remuxed versions unusable (due to errors in teh original stream whcih are carried over to the TS file) and 10% it just hangs indefinitely.

So in the interest of hte larger audience, MCEBuddy CANNOT hang and cannot create corrupted files, hence remuxsupp needs to be relegated to the second options after ffmpeg. (fast and slow).
However in some cases folks like you all here know what you're doing and I've provided an option via UseWTVRemuxsupp to force using it when you know it's working well for you. This is a logical bug which i've fixed in tomorrow's build (10/28) it will fall back to other options if it fails.

I am however interested in MNSearchers's log files to see what's going on.
Oct 28, 2013 at 8:32 PM
Who develops remusupp ?

Im at cross roads whether to even contitnue using MCEBuddy... Remuxsupp is unreliable, ffmpeg fast remux produces useless output for UKs HD channels (stutter and lag) and slow remux takes forever even on 8 core machine (since its not mulitthreded it doesnt even matter). Why even have multiple encoders setup in a profile when it all comes down to ffmpeg remuxing anyway..

Handbrake coverts videos in a snap, but lacks crazy options of mcebuddy which i love.
Oct 29, 2013 at 12:05 AM
If remuxsupp work for you fine why not continue using it?
That's why we have provided options for users to customize it.
I've put up a new build to allow fall through incase remuxsupp fails.

Unfortunately like everything in life no one solution works for everyone. The goal at mcebuddy is to provide easy access to customized solutions for everyone.

Oct 29, 2013 at 6:18 AM
Remuxsupp has started failing more often in recent weeks so I'm at mercy of ffmpeg more often than before. I'm not sure if BBC has tweaked the encoding or whether Remuxsupp was updated in MCEBUddy but it's not as reliable as it was before. So with Remuxsupp going downhill, ffmpeg fast remux being troublesome for UK HD channels, only option is to investigate how to go directly to handbrake without Remuxing.

For now I'm testing new workflow - MCEBUddy doing fetching, renaming, collecting metadata from wtv to xml and use Handbrake's Folder action to encode renamed files.
Oct 29, 2013 at 7:06 AM
Remuxsupp unfortunately cannot be updated since the source code is not available.

Have you tried streams remuxing? That's a new remuxing process we introduced a few months ago that uses windows directshow to extract the streams. It usually works pretty well for wtv files. See the documentation on how to use streams.

Oct 29, 2013 at 7:16 AM
Also let me look into rearchitecting mcebuddy to avoid remuxing. Can you upload one original video that causes remuxsupp and ffmpeg fast to fail remuxing.

Oct 29, 2013 at 7:41 AM
I will upload the video tonight when i get home ( I'm at work at the moment and then have to pick up little bugger from kindergarden in the afternoon )

Thank you very much !
Oct 29, 2013 at 3:28 PM

I believe I am having the same issue with the new ffmpeg. A lot of my shows will fail the ffmpeg conversion and revert to the handbrake conversion. I can upload logs and the video if you like.
Oct 29, 2013 at 4:01 PM
Yes please upload the logs and the original recording

Oct 30, 2013 at 2:31 PM
Files are uploaded...I put them in "FFMPEG Issues - cmgj" It happened with the full 8gb wtv file and also with the file I split to 60MB. I upload the full wtv log and the split file and the split wtv file.
Oct 30, 2013 at 7:38 PM
Edited Oct 30, 2013 at 9:24 PM

Here is the file that fails WTV Stream Remux, Remuxsupp ( error in the log indicates no audio stream is found ), produces laggy output when Fast Remux is used and adds over 2 hours to encoding using Slow Remux.

(its a private link so it should work ok)

Dropbox is having connectivity issues right now ( as noted on their forums) so please try in couple of hours
Nov 3, 2013 at 12:21 PM
Hello rboy,

have you been able to get the file ? Since file is pretty large, I'd like to remove it from my Dropbox storage once you've downloaded it.

Thank you

Kind regards,
Nov 3, 2013 at 4:44 PM
downloading now. In future see if youcan upload directly to the mcebuddy server. dropbox large file connections are very unstable here for some reason.

Nov 6, 2013 at 4:54 AM
@cmgj - the bug was fixed and it works now. Take today's build.

@vladik007 - I've improved support for fast remuxing, the file you've given me no longer slow remuxes now with the new build. as of getting rid remuxing it'll take time until ccextractor and comskip start supporting wtv files. I'm working with them on enhancing their applications but this is a slow process. If more requested them I thin they (Krik and Carlos) might think about providing support for it. Until then there' not a whole lot, maybe we can skip over closed caption extraction or provide an option to tell mcebuddy about donator version.
Nov 6, 2013 at 5:39 AM
Hello Rboy,
Thanks for response.
1, Did you check output of the Fast remuxed file ? Fast Remuxed files with UK HD are very jerky/laggy. File I've provided you with would stutter every 10-30 seconds making it unusable if Fast Remuxed. ( you can check intermediate .ts file, that one would be very jerky in VLC )
2, Remuxing could be skipped if user does not care about Closed Captions (anyone outside US) and dont have time to tinker with Comskip (like me :-) ) I just want to convert files, and if there's an ad in the converted file, I use old fashioned skip button. (and ad's outside US arent as bad, for example all BBC channels and all other national TVs in EU dont have them).
So workflow could be - dont Remux unless CC checkbox is checked and Comskip is used. If those two options are used, force Remux. And once one of the tools supports wtv files directly it could be taken out of the if/else condition.

Just ideas ..... anyway, thanks for taking time to troubleshoot. Please let me know about point.1 though, I will test it if video at your end is smooth.
Nov 6, 2013 at 5:35 PM
I will leave the indept testing to your expertise. The file remuxs now without resorting to slwo remuxing. as I had mentioend before it's hard to make ti 100% for 90 countries when using 3rd party tools, so I provide options. Use remuxsupp if that works better.

I'll address 2 in the next major release. Open a ticket so I'll remember to get to it.

Nov 6, 2013 at 7:37 PM
Done. Item number 1710.

Thanks alot !