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

MCEBuddy potentially no new release - help required

Mar 7, 2013 at 7:56 PM

MCEbuddy is facing a crisis. There was a recently change to libavformat within ffmpeg that has ccaused ffmpeg support for wtv to be broken.

The person who can fix this is Peter Ross @pross

I need your help to lobby the ffmpeg forum and peter to fix the issue.

You can find the details here:

If this doesn't get fixed, there may no new releases of mcebuddy.
Mar 7, 2013 at 10:24 PM
Read the details and have some general sense of the technical issue at hand but I am not clear what precisely we can do to help.

Can you give us more direction as to how to go about lobbying?

Is the issue that this is the result of a design decision and we need to lobby to revise this decision or is the issue that resources need to be focused on the technical issue that resulted from implementation of the design change?

I could not tell if this issue only effects MCEbuddy or other users of ffmpeg?
Mar 8, 2013 at 12:53 AM
I have added a comment and voted. Fingers crossed this isn't the case.

Roughly how many .wtv recordings does this effect and is it related to the problem I am having?
Mar 8, 2013 at 4:30 AM
The decision cannot be reserved since it's controlled by a 3rd party libavformat but the owner, Peter Ross needs to put a fix for it in the WTV code.

Essentially, if the users can add their comments about facing similar issues and how it's breaking your programs and the concept of representing MJPEG as a video stream is flawed, Peter should put the code to revert the old functionality where MJPEG is reprsented as an attachment rather an video stream.
Mar 8, 2013 at 4:37 AM
The issue is, with ffmpeg identifying the mjpeg stream as a vidoe stream when MCEBuddy tries to remux the wtv file, ffmpeg tries to copy the mjpeg stream also (since it's identified as a video stream) and the remux fails, i.e. mcebuddy is dead right there since remuxing is fundamental.

Logically also it doesn't make sense to mark a mjpeg stream as a video stream, so there's a bit apparntly which identifies this isssue, and the developer (PEter Ross) needs to add some code to recognize this bit and mark the stream as an attachment and not video so that when ffmpeg tries to copy the video streams (map 0:v) it only copies the actualy video and not the mjpeg.
Apr 2, 2013 at 12:39 AM
Yes, this is what I came to the conclusion too (see my latest post on the ffmpeg tracker). I have been quite shocked of the manner of some of the ffmpeg devs (if they are devs??) very rude.
Apr 4, 2013 at 5:22 PM
Hello all,

Has this been resolved?
Apr 4, 2013 at 5:52 PM
no - ffmpeg has other issues but now mebuddy supports the newer versions

Apr 9, 2013 at 8:46 PM
I've been trying to follow along here, but I'm confused. There was an issue with unprocessed WTV files not being able to be played in this related to that? And if so, what do you mean by "MCEbuddy supports newer versions," does this mean it's working again or the WTV profiles are borked and don't work?
Apr 9, 2013 at 9:18 PM
No these are 2 different issues. WTV not working is related to an open issuer. This is a different issue which has broken the way ffmpeg deals with parsing wtv files which made mcebuddy incompatible with newer versions of ffmpeg. I've put a workaround for this in 2.3.12. Now users can upgrade ffmpeg to the latest version manually and mcebuddy will be able to work with it.

The issue with ffmpeg creating wtv files which don't play back with mce still exists and if users lobby Peter Ross it may be fixes in future ffmpeg releases.

Hope this clarifies the topic.

Apr 9, 2013 at 10:10 PM
Thanks it does!