One thing that will help in getting useful customer feedback: acknowledgement.
One of the most common user frustrations with free software projects is that nobody is getting paid to take on the dreary task of answering and responding to user input.
On the old HB page, I would add a comment in the Requests section, (i.e., "Can we do something to fix these hard-to-read transluscent subtitles? Like maybe preserving color data?), and then... nothing.
It could well be that titer was looking into that very question, but I would never know about it, because no response ever came.
This is completely understandable. Programmers do free software projects because they enjoy programming, not customer support.
However, for any given bug report or change request, it would make a HUGE difference in beta-tester participation if each new item got a response from somebody in-the-know that contained the following information:
1. Is the change being considered?
2. If so, is it more than a few revisions away on the priority list?
3. Are there major obstacles to making it happen?
Earlier, on another thread, you were talking about looking for "moderator" volunteers for your Support and Request forums, and I briefly considered stepping up to be that person, but since I am not involved in the coding of this project, the best I would be able to do is respond with a "sorry, I don't know" and/or pass the question along to you guys, which ends up not really saving you any time and trouble at all.
From this forum and the other, it seems like the biggest feature priorities out there are as follows:
0: Up-to-date iPod, AppleTV and PSP formats (I list this as item #0 because we all know that this is one of the main dev priorities, at least as far as this fork is concerned.)
1: Improved audio support, particularly AAC 5.1 output, as well as the ability to rip DTS audio signals.
2: Improved subtitle support. Including the ability to make "switchable" subtitle options in AVI files, and also to restore color data to the "burned in" format.
3: MOV wrappers, which would open up options for chapters, subtitles, etc. (Some of this can already be done with AVI)
4: A queue which can be edited on the fly, adding, changing, and removing files that are waiting to be processed while the app is running.
5: Frame-by-frame step-through in the preview window (to better identify interlacing issues, frame cropping, etc.)
6: Improved de-interlacing options. The current de-interlace technique is rather crude and sometimes results in choppy-looking motion, especially on full-screen pans. It's gotten to the point that I sometimes don't even use it, and instead rely on VLC playback with the "blur" de-interlace option on by default. Obviously this is not an ideal choice, especially if I might want to play the files back via an iPod or AppleTV anytime soon.
7: Brightness/Contrast/Gamma control of video output.
8: Volume control of audio output.
9: Lossless video rips. With AC3 pass-through, this would allow perfect archival rips of any DVD content, without necessarily ripping the entire disk via MtR, and without having to muck around with VIDEO_TS folders.
10: iTunes-friendly meta-tag header files.
11: Blu-Ray / HD-DVD support.
I think that covers the big ones that people are currently wondering about.
MediaFork 0.8.0BETA Customer Feedback Discussion
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
All very true. I would submit that what I call "power users" or just users familiar with the project and its progress, are vital in providing support to end users. If the devs had to do all of it, then not much actual development would get done. Folks like yourself and some others that are seen answering basic questions in the forums really would take the load off of the devs and kind of provide a "liason" between the devs and the average user.golias wrote:One thing that will help in getting useful customer feedback: acknowledgement.
One of the most common user frustrations with free software projects is that nobody is getting paid to take on the dreary task of answering and responding to user input.
On the old HB page, I would add a comment in the Requests section, (i.e., "Can we do something to fix these hard-to-read transluscent subtitles? Like maybe preserving color data?), and then... nothing.
It could well be that titer was looking into that very question, but I would never know about it, because no response ever came.
This is completely understandable. Programmers do free software projects because they enjoy programming, not customer support.
However, for any given bug report or change request, it would make a HUGE difference in beta-tester participation if each new item got a response from somebody in-the-know that contained the following information:
1. Is the change being considered?
2. If so, is it more than a few revisions away on the priority list?
3. Are there major obstacles to making it happen?
Earlier, on another thread, you were talking about looking for "moderator" volunteers for your Support and Request forums, and I briefly considered stepping up to be that person, but since I am not involved in the coding of this project, the best I would be able to do is respond with a "sorry, I don't know" and/or pass the question along to you guys, which ends up not really saving you any time and trouble at all.
A case in point would be the MTR forums. Geezerbuttz is the sole developer, but you mostly hear form WiseWeasel, DVDrexer and Lawnman on the forums. They communicate alot with Geezer and then help the users keep up to date with whats going on. Geezer also participates in the forums alot, but if it were not for the others, he could never keep up with questions.
You dont have to be a developer to help folks use the software, thats for sure.
sorry this is so long...but it should be a sign of acknowledgment at least 
There's no clearer way for a developer to acknowledge an issue.
When you brought it up again here, I spent a Sunday afternoon looking into it. I managed to get totally black subtitles, totally white subtitles, a big translucent black box where the subtitles should be, a translucent black box that filled the screen whenever a subtitle should have appeared...basically, I was able to achieve absolutely everything except giving subs their correct colors. =(
Because I didn't have a solution for you, and because I knew I didn't have one coming, I felt it would have been misleading to respond. It would have given you the impression that this issue was actively being looked at, when it wasn't. I agree that it's a bug, and I have enough anime to have run into situations where transparent subs are a problem...but HB's subtitle code is really complex to a n00b like me, full of hexadecimal and api calls and weird bit shifting operations I can't make heads or tails of. If I'd posted, to say "Hey, spent some time looking at this, haven't found a fix, sorry..." well, that would have shied away other developers from attempting to fix this--some would then think, "Oh, I guess jbrjake's going to cover this."
What I didn't do, and what I should have done, is start a Trac ticket for it here. So I'm going to be more pro-active on that from now on. This weekend I'll troll through the forum archives and start tickets for the things people have mentioned here that fell through the cracks. I'll also copy over the standing tickets from titer's svn, like the subtitle color thing.
Golias, your post makes many excellent points about how we're failing in communicating with the users, and so I hope you don't take all of this as a flame--because that's not how I intend it. I just want you to know that there are sometimes reasons why a feature request won't get a lot of acknowledgment, and that it doesn't necessarily mean everyone's ignoring you.
As far as bug reports, it's often not feasible to say what change is being considered, how far away it is, or what the major obstacles are. Look at the memory leak. It took us over a week to decide what change to consider, we have no clue how far away a fix is, and the major obstacles are entirely dependent on how we go about fixing it.
Similarly, for feature requests, a significant amount of time often needs to be invested before its ramifications can be understood. A few weeks ago, someone asked for the ability to page through every frame in the film. I thought this would be easy, but after examining the preview code, I discovered it would be quite difficult. The preview frames are used to decide cropping, and they're all chosen at the time the dvd is first scanned. To page through each frame without renovating the code would mean storing the entire movie in ram...not happening. So after a day of fooling around with the code I had nothing useful, and I'd gotten up a user's hopes for nothing. To generalize this, it means that deciding whether a change is being considered can't be known until after the major obstacles are known, and this can take days to weeks, and even after this, placing it on the priority list can be tough because major obstacles require sustained dedicated periods of time to overcome and those are not easy to schedule.
Moderators: I don't think being a developer should be a pre-req for being a Support moderator so you should talk to rhester about that. Requests is another story...
Feature priorities:
iPod support is still good, @tv support must wait til it's out but then we've got dynaflash, psp support...eh. I don't have any motivation for that. Anyone else? It shouldn't be too hard with libavformat...don't think titer finished it, though.
maurj's on the AAC 5.1, DTS I don't know about.
subtitle support--don't lump these two together, two totally different things...color subs should be easy for anyone who knows hex and alpha channels and DVD sub protocol, other sub support will be a lot bigger of a deal because we don't currently have a library to call to make vobsub style subs or .srts. No one is working on either, afaik.
I'd expect .mkv support before .mov for subs or chapters, because it's more cross-platform...no one's working on it, though.
benlake is all over the active queue, expect that soon.
frame-by-frame step-thru..difficult as i explained above.
deinterlacing: you have fine taste, golias, for refusing handbrake's subpar deinterlacer. i agree wholeheartedly and wish but that there was an easy solution. Unfortunately, better deinterlacing means mencoder's post-processing. We use libavcodec directly (mencoder uses it but apparently applies its own filtering), so we're stuck with the horrible ffmpeg deinterlacer for the foreseeable future.
brightness/gamma/volume control: these are all better handled at playback time rather than encode time. handbrake should give back what it gets in. the only issue i'm aware of is the whole brightness thing with quicktime, and dynaflash already fixed that by throwing in the colr box code from titer's svn.
lossless video: not sure what you mean. handbrake decodes mpeg-2. if you output mpeg-2 from handbrake, it's re-encoding it to mpeg-2. this is lossy. we could add lossless x264 quite easily, but that takes hundreds of megs to hold a few paltry seconds of standard-def video. titer hand-wrote the dvd reader and I'm really not sure it would be any good for copying a DVD bit by bit as raw data.
metadata: this I can totally see happening in the near future, as long as the user manually enters it. scraping imdb or amazon for the info will be more...involved, I think.
blu-ray/hd-dvd: with recent events I'm sure everyone's aware of, this is not just a hypothetical anymore. i've been following the ordeals of windows users to get things working smoothly. it looks like a good utility for handling those .evo files (fancy .ts files, really, like .vobs) isn't around yet. Once there's a good open source library for handling the raw video files, it should be only a minor struggle to allow reading from a decrypted hd-dvd or blu-ray disk stored on a hard drive. reading directly from the disc is further away. then the problem becomes rewriting all the code that's currently hard set for frames with DVD pixel dimensions, and dealing with the resultant memory issues. the easy part will be encoding. by the time all this is happening, mediafork will support high profile AVC. Space savings won't be as drastic as with DVD compression, though, because HD-DVD and Blu-Ray are already in mpeg-4. Still, you can easily compress a 1080p movie to fit on a dual-layer dvd without sacrificing too much quality. Oh. Another problem is VC-1. A lot of these first HD-DVD discs to be cracked use it, and it's Microsoft's format. I don't think there's an open source decoder for it. So we might not be able to handle those. h.264 and the crappy mpeg-2 ones should work, though.
That's unfair to titer. If you'd checked his Trac, you'd have seen that he started a ticket for that in October: http://handbrake.m0k.org/cgi-bin/trac.cgi/ticket/2golias wrote:On the old HB page, I would add a comment in the Requests section, (i.e., "Can we do something to fix these hard-to-read transluscent subtitles? Like maybe preserving color data?), and then... nothing.
It could well be that titer was looking into that very question, but I would never know about it, because no response ever came.
There's no clearer way for a developer to acknowledge an issue.
When you brought it up again here, I spent a Sunday afternoon looking into it. I managed to get totally black subtitles, totally white subtitles, a big translucent black box where the subtitles should be, a translucent black box that filled the screen whenever a subtitle should have appeared...basically, I was able to achieve absolutely everything except giving subs their correct colors. =(
Because I didn't have a solution for you, and because I knew I didn't have one coming, I felt it would have been misleading to respond. It would have given you the impression that this issue was actively being looked at, when it wasn't. I agree that it's a bug, and I have enough anime to have run into situations where transparent subs are a problem...but HB's subtitle code is really complex to a n00b like me, full of hexadecimal and api calls and weird bit shifting operations I can't make heads or tails of. If I'd posted, to say "Hey, spent some time looking at this, haven't found a fix, sorry..." well, that would have shied away other developers from attempting to fix this--some would then think, "Oh, I guess jbrjake's going to cover this."
What I didn't do, and what I should have done, is start a Trac ticket for it here. So I'm going to be more pro-active on that from now on. This weekend I'll troll through the forum archives and start tickets for the things people have mentioned here that fell through the cracks. I'll also copy over the standing tickets from titer's svn, like the subtitle color thing.
Golias, your post makes many excellent points about how we're failing in communicating with the users, and so I hope you don't take all of this as a flame--because that's not how I intend it. I just want you to know that there are sometimes reasons why a feature request won't get a lot of acknowledgment, and that it doesn't necessarily mean everyone's ignoring you.
As far as bug reports, it's often not feasible to say what change is being considered, how far away it is, or what the major obstacles are. Look at the memory leak. It took us over a week to decide what change to consider, we have no clue how far away a fix is, and the major obstacles are entirely dependent on how we go about fixing it.
Similarly, for feature requests, a significant amount of time often needs to be invested before its ramifications can be understood. A few weeks ago, someone asked for the ability to page through every frame in the film. I thought this would be easy, but after examining the preview code, I discovered it would be quite difficult. The preview frames are used to decide cropping, and they're all chosen at the time the dvd is first scanned. To page through each frame without renovating the code would mean storing the entire movie in ram...not happening. So after a day of fooling around with the code I had nothing useful, and I'd gotten up a user's hopes for nothing. To generalize this, it means that deciding whether a change is being considered can't be known until after the major obstacles are known, and this can take days to weeks, and even after this, placing it on the priority list can be tough because major obstacles require sustained dedicated periods of time to overcome and those are not easy to schedule.
Moderators: I don't think being a developer should be a pre-req for being a Support moderator so you should talk to rhester about that. Requests is another story...
Feature priorities:
iPod support is still good, @tv support must wait til it's out but then we've got dynaflash, psp support...eh. I don't have any motivation for that. Anyone else? It shouldn't be too hard with libavformat...don't think titer finished it, though.
maurj's on the AAC 5.1, DTS I don't know about.
subtitle support--don't lump these two together, two totally different things...color subs should be easy for anyone who knows hex and alpha channels and DVD sub protocol, other sub support will be a lot bigger of a deal because we don't currently have a library to call to make vobsub style subs or .srts. No one is working on either, afaik.
I'd expect .mkv support before .mov for subs or chapters, because it's more cross-platform...no one's working on it, though.
benlake is all over the active queue, expect that soon.
frame-by-frame step-thru..difficult as i explained above.
deinterlacing: you have fine taste, golias, for refusing handbrake's subpar deinterlacer. i agree wholeheartedly and wish but that there was an easy solution. Unfortunately, better deinterlacing means mencoder's post-processing. We use libavcodec directly (mencoder uses it but apparently applies its own filtering), so we're stuck with the horrible ffmpeg deinterlacer for the foreseeable future.
brightness/gamma/volume control: these are all better handled at playback time rather than encode time. handbrake should give back what it gets in. the only issue i'm aware of is the whole brightness thing with quicktime, and dynaflash already fixed that by throwing in the colr box code from titer's svn.
lossless video: not sure what you mean. handbrake decodes mpeg-2. if you output mpeg-2 from handbrake, it's re-encoding it to mpeg-2. this is lossy. we could add lossless x264 quite easily, but that takes hundreds of megs to hold a few paltry seconds of standard-def video. titer hand-wrote the dvd reader and I'm really not sure it would be any good for copying a DVD bit by bit as raw data.
metadata: this I can totally see happening in the near future, as long as the user manually enters it. scraping imdb or amazon for the info will be more...involved, I think.
blu-ray/hd-dvd: with recent events I'm sure everyone's aware of, this is not just a hypothetical anymore. i've been following the ordeals of windows users to get things working smoothly. it looks like a good utility for handling those .evo files (fancy .ts files, really, like .vobs) isn't around yet. Once there's a good open source library for handling the raw video files, it should be only a minor struggle to allow reading from a decrypted hd-dvd or blu-ray disk stored on a hard drive. reading directly from the disc is further away. then the problem becomes rewriting all the code that's currently hard set for frames with DVD pixel dimensions, and dealing with the resultant memory issues. the easy part will be encoding. by the time all this is happening, mediafork will support high profile AVC. Space savings won't be as drastic as with DVD compression, though, because HD-DVD and Blu-Ray are already in mpeg-4. Still, you can easily compress a 1080p movie to fit on a dual-layer dvd without sacrificing too much quality. Oh. Another problem is VC-1. A lot of these first HD-DVD discs to be cracked use it, and it's Microsoft's format. I don't think there's an open source decoder for it. So we might not be able to handle those. h.264 and the crappy mpeg-2 ones should work, though.
A couple of reactions.jbrjake wrote:sorry this is so long...but it should be a sign of acknowledgment at leastThat's unfair to titer. If you'd checked his Trac, you'd have seen that he started a ticket for that in October: http://handbrake.m0k.org/cgi-bin/trac.cgi/ticket/2golias wrote:On the old HB page, I would add a comment in the Requests section, (i.e., "Can we do something to fix these hard-to-read transluscent subtitles? Like maybe preserving color data?), and then... nothing.
It could well be that titer was looking into that very question, but I would never know about it, because no response ever came.
There's no clearer way for a developer to acknowledge an issue.
When you brought it up again here, I spent a Sunday afternoon looking into it. I managed to get totally black subtitles, totally white subtitles, a big translucent black box where the subtitles should be, a translucent black box that filled the screen whenever a subtitle should have appeared...basically, I was able to achieve absolutely everything except giving subs their correct colors. =(
Because I didn't have a solution for you, and because I knew I didn't have one coming, I felt it would have been misleading to respond. It would have given you the impression that this issue was actively being looked at, when it wasn't. I agree that it's a bug, and I have enough anime to have run into situations where transparent subs are a problem...but HB's subtitle code is really complex to a n00b like me, full of hexadecimal and api calls and weird bit shifting operations I can't make heads or tails of. If I'd posted, to say "Hey, spent some time looking at this, haven't found a fix, sorry..." well, that would have shied away other developers from attempting to fix this--some would then think, "Oh, I guess jbrjake's going to cover this."
What I didn't do, and what I should have done, is start a Trac ticket for it here. So I'm going to be more pro-active on that from now on. This weekend I'll troll through the forum archives and start tickets for the things people have mentioned here that fell through the cracks. I'll also copy over the standing tickets from titer's svn, like the subtitle color thing.
First of all, The trac tickets are not something which users are likely to be aware of. Case in point, I didn't even know such an animal existed until you just pointed it out.
Secondly, a reply can be as simple as, "I looked into it, and I can't find a way to do it with the tools that HB is built on. For now, it doesn't look like it is likely to happen in the foreseeable future."
In other words, answering "no" is probably more useful to users than not answering.
Saying "it would require a major re-write, and we probably won't have time for that anytime soon" is also sometimes an informative-enough response.
I totally get why answers don't always come on the forums. When it comes to "how do I do such-and-such" type questions, I usually do my best, as a good forum citizen, to chime in if I can help the user, because I don't want devs to lose development time to dealing with such stuff either. That's how it should be.
But when it comes to question that only somebody like you can answer, hearing back from you dramatically increases people's willingness to provide the kind of feedback you want.
The memory leak is something that I see as an example of where the issues have been EXTREMELY well-comunicated. Everybody who follows this forum understands that it is a huge challenge, and probably won't be fixed in the immediate future.
Your other answers here are awesome. And no, I don't consider anything you said to be "flaming" me. You brought to light several fact that I flat-out was not aware of.
This thread is pure gold. I just wish I had a good answer on how to handle it.
It doesn't belong in Trac. Yes, the "core issues" being discussed will largely be in Trac, but VERY developer-centric and technical (as they should be!). This is of precious little use to all but the hardest-core end-users.
It doesn't belong in the forums. Sure, we could do a sticky, but what's an effective way to keep it updated, particularly by multiple contributors? Who will police the forums to keep track of requests and the Trac (and direct developer communication) for status?
It doesn't belong on the blog. See forums.
Is anyone even aware of any open-source "request tracking" software? I'm not looking for anything for bug reports (we have it), milestone associations (we have it), etc. - just something we can actually put in end-users' hands (and, I'll confess, later likely regret it because of nasty things like issue duplication and "why doesn't MediaFork make toast?") to keep an indexable log of requests that one or two individuals can periodically review, suggest the most reasonable ones to the devs, and eventually become Trac issues associated with milestones.
I'm afraid I categorically disagree with the "every feature request deserves a dev response". a) Most requests are duplicates - and no hammer large enough exists to force users to read existing requests to see if theirs has already been covered. It's an age-old problem. b) Many requests are obvious even to other users to be either totally unrealistic or completely out of scope for the product in question. c) The requests that don't fit a or b tend to be FAQ-type stuff, where they are asking for something that is already there but they don't know how to use. I'd suggest a pointer to the FAQ, but see a. d) The final few are just completely incomprehensible, due to language barriers (or worse).
If anyone has reasonable, supportable, maintainable solutions to all this that most importantly does not unnecessarily take up developer time or resources, I'm game, even if it means building out the support site more. But end-user communication takes a back seat, especially now, to working through the issues. In the end, HandBrake was a tool titer wrote for himself and graciously shared his work with the world. MediaFork will be no exception. Take note that the developers are individually working on the pieces that interest them, to satisfy their own personal, selfish goals...and this is why open-source works.
As a quick aside - I'd love to tell you we're all about the end-users. We're not - or at least I'm not. I started this whole fork because I needed iPod firmware 1.2+ support and it did not appear to be forthcoming on the timetable I wanted. The fact a few thousand other people were/are in the same boat did not concern me in the least. I had the opportunity to share what little I'd done with others at very little cost to me and that led to a true renaissance of interest in HandBrake development, so that's goodness. But all the same - we're already showing our support for end-users by building a support site, providing adequate bandwidth and infrastructure to handle mass hordes, and making anyone interested enough to read what we do able to follow along with our discussions (and frustrations!), our progress, and even our very source code as anonymously as they like. We don't have to. We do it because it also helps our aims and isn't any real skin off our noses.
Since the aside turned out to be not-so-quick, one more point of note to the Digg users who suggested we "owe" them something/anything: Get a clue. You are not groupies. We are not a rock band. But if you and I both were those things, I might owe you something, because I'm selling a product (my music) that you are rewarding me for (with cash). This isn't music. You aren't supplying cash. What I owe the ingrates talking such trash is to just rip the entire house down and go home. But I know for every one of them there is at least a hundred good and decent people looking for a free software solution that Just Works(TM), and to those, I extend a warm welcome.
re: cash. Don't ever mention it here. I know titer took donations for equipment, etc., and I know it has worked fairly well in the past in a few targeted projects where that sort of thing is beneficial. Here, we code for fun and as a hobby, and that's it. I'm not accepting anyone's money (for a great many reasons) or any sort of other compensation, nor am I making any promises. We're writing software. You can use it if you want. That's as far as the contract goes.
Off my soapbox now. =)
Rodney
It doesn't belong in Trac. Yes, the "core issues" being discussed will largely be in Trac, but VERY developer-centric and technical (as they should be!). This is of precious little use to all but the hardest-core end-users.
It doesn't belong in the forums. Sure, we could do a sticky, but what's an effective way to keep it updated, particularly by multiple contributors? Who will police the forums to keep track of requests and the Trac (and direct developer communication) for status?
It doesn't belong on the blog. See forums.
Is anyone even aware of any open-source "request tracking" software? I'm not looking for anything for bug reports (we have it), milestone associations (we have it), etc. - just something we can actually put in end-users' hands (and, I'll confess, later likely regret it because of nasty things like issue duplication and "why doesn't MediaFork make toast?") to keep an indexable log of requests that one or two individuals can periodically review, suggest the most reasonable ones to the devs, and eventually become Trac issues associated with milestones.
I'm afraid I categorically disagree with the "every feature request deserves a dev response". a) Most requests are duplicates - and no hammer large enough exists to force users to read existing requests to see if theirs has already been covered. It's an age-old problem. b) Many requests are obvious even to other users to be either totally unrealistic or completely out of scope for the product in question. c) The requests that don't fit a or b tend to be FAQ-type stuff, where they are asking for something that is already there but they don't know how to use. I'd suggest a pointer to the FAQ, but see a. d) The final few are just completely incomprehensible, due to language barriers (or worse).
If anyone has reasonable, supportable, maintainable solutions to all this that most importantly does not unnecessarily take up developer time or resources, I'm game, even if it means building out the support site more. But end-user communication takes a back seat, especially now, to working through the issues. In the end, HandBrake was a tool titer wrote for himself and graciously shared his work with the world. MediaFork will be no exception. Take note that the developers are individually working on the pieces that interest them, to satisfy their own personal, selfish goals...and this is why open-source works.
As a quick aside - I'd love to tell you we're all about the end-users. We're not - or at least I'm not. I started this whole fork because I needed iPod firmware 1.2+ support and it did not appear to be forthcoming on the timetable I wanted. The fact a few thousand other people were/are in the same boat did not concern me in the least. I had the opportunity to share what little I'd done with others at very little cost to me and that led to a true renaissance of interest in HandBrake development, so that's goodness. But all the same - we're already showing our support for end-users by building a support site, providing adequate bandwidth and infrastructure to handle mass hordes, and making anyone interested enough to read what we do able to follow along with our discussions (and frustrations!), our progress, and even our very source code as anonymously as they like. We don't have to. We do it because it also helps our aims and isn't any real skin off our noses.
Since the aside turned out to be not-so-quick, one more point of note to the Digg users who suggested we "owe" them something/anything: Get a clue. You are not groupies. We are not a rock band. But if you and I both were those things, I might owe you something, because I'm selling a product (my music) that you are rewarding me for (with cash). This isn't music. You aren't supplying cash. What I owe the ingrates talking such trash is to just rip the entire house down and go home. But I know for every one of them there is at least a hundred good and decent people looking for a free software solution that Just Works(TM), and to those, I extend a warm welcome.
re: cash. Don't ever mention it here. I know titer took donations for equipment, etc., and I know it has worked fairly well in the past in a few targeted projects where that sort of thing is beneficial. Here, we code for fun and as a hobby, and that's it. I'm not accepting anyone's money (for a great many reasons) or any sort of other compensation, nor am I making any promises. We're writing software. You can use it if you want. That's as far as the contract goes.
Off my soapbox now. =)
Rodney
Last edited by rhester on Fri Jan 26, 2007 2:21 pm, edited 2 times in total.
Rhester's comments are exactly why I *love* that MediaFork is going forward as an open-source app. If somebody out there sees a feature which they would like, and know how to add, they can submit it. With a lot of software out there, particularly so-called "shareware", the devs lock it down do tight that such improvements are not possible.
I predict a bright future for this app!
I predict a bright future for this app!
Well, like I promised last night, I went through every post in the forum and made up a list of bugs and feature requests:
But after reading rhester's comment:***** Bugs
FPS autodetection (Per rhester, possibly an .IFO problem and not fixable. But ffmpeg has changed its base vrate calculations several times recently, so maybe that magically fixes it? Haven't had a chance to test with a DVD I know is detected incorrectly.)
Preserve subtitle coloration
"digital nastiness" when converting 24-bit PCM to AAC
Problems decoding audio from eyeTV-sourced home-burnt DVD
dropped final second of video
Some VIDEO_TS folders not ripped with MTR make the console fill up with
"[mp2 @ 0x57a524]header missing skiping one byte" messages until the hard drive is full and the system crashes.
Sometimes Picture Settings will seem to boost picture resolution above iPod limits by jumping up one macroblock in size, even though the correct <= 640 width is used at encode time.
***** Features
Frame-by-frame preview step-thru
Better deinterlacing
More exact chapter times
Encode from .vob or .ts
Checkbox to maintain aspect ratio when cropping
1-channel aac
6-channel aac
.mov and/or .mkv support for chapters
.srt or ripped subtitles instead of burned
DTS pass-thru
Auto-scale video to iPod resolution if iPod x264 encoding is selected
Apple TV support
PS3 support
PSP support
2-pass support for IMF
n-pass support for MF
More exact cropping
Default deinterlacing on/off preference
Fuller use of doxy documentation
Verbose log display in the GUI
Advanced x264 options including High Profile
Ability to read MeGUI profiles
Presets
active queue
iTunes metadata in the .mp4 container based on film info scraped from iMDB or Amazon
Blu-Ray / HD-DVD support
IMF droplet or iTunes plug-in for automated encoding
...I'm not sure if I should add them as new tickets to the Trac.rhester wrote:It doesn't belong in Trac.
When I said "it doesn't belong in Trac", that should be translated to "we can't just allow any old request or bug that hasn't been vetted and reproduced to land in Trac".
Your list, on first glance, looks quite sane (especially in the bugs department - though where's the memory leak on that list?
. The bugs on your list should absolutely be Trac'd. As for the feature requests, as long as they are realistic, achievable, and fall within our large-scale goals, I say Trac 'em and we'll tie them to releases as appropriate.
Rodney
Your list, on first glance, looks quite sane (especially in the bugs department - though where's the memory leak on that list?
. The bugs on your list should absolutely be Trac'd. As for the feature requests, as long as they are realistic, achievable, and fall within our large-scale goals, I say Trac 'em and we'll tie them to releases as appropriate.Rodney
OK, I went and added a massive number of tickets. If it seems overwhelming, switch to "view by milestone" and you'll see that it's not so bad.
As far as which tickets are attached to which milestones, I can't say I used any hard and fast rules, except that the tougher it is, the further back I pushed it.
Everyone feel free to edit or delete or reassign any of them as you see fit. maurj, I assigned you the 5.1 aac I know you're working on already. dynaflash and benlake, you have the presets. benlake? active queue is all yours. dynaflash? you own the verbose logging drawer for the gui. I put me and dynaflash down for apple tv support, and gave myself the x264 options (including 3rd pass abr) and megui profile parsing I'm interested in.
johnallen: several weeks ago you expressed an interest in stripping down IHB so it could be an automated encoder (I believe the workflow you outlined would be 1: insert the dvd 2: launch ihb 3: there is no step three) or an iTunes plugin. I neglected to start a ticket for this because I wasn't sure how you'd want to describe it or if it's something you're seriously considering.
I didn't make a ticket for the memory leak either. If anyone feels that that's a horrible oversight, go ahead and add it too.
As far as which tickets are attached to which milestones, I can't say I used any hard and fast rules, except that the tougher it is, the further back I pushed it.
Everyone feel free to edit or delete or reassign any of them as you see fit. maurj, I assigned you the 5.1 aac I know you're working on already. dynaflash and benlake, you have the presets. benlake? active queue is all yours. dynaflash? you own the verbose logging drawer for the gui. I put me and dynaflash down for apple tv support, and gave myself the x264 options (including 3rd pass abr) and megui profile parsing I'm interested in.
johnallen: several weeks ago you expressed an interest in stripping down IHB so it could be an automated encoder (I believe the workflow you outlined would be 1: insert the dvd 2: launch ihb 3: there is no step three) or an iTunes plugin. I neglected to start a ticket for this because I wasn't sure how you'd want to describe it or if it's something you're seriously considering.
I didn't make a ticket for the memory leak either. If anyone feels that that's a horrible oversight, go ahead and add it too.