I'd like to know this guy's definition of "highend", seriously. Today I've got an outdated AMD X2 3800+ with 3GB of RAM and I capture anything on Gens in realtime. Given that Vista sucks so much performance, I can understand his need for yet another proprietary codec. Way to work around the issue!
Never heard of x264?
Pointless. Seems like he just wants to show everybody what a great coder he is that he wrote something like this.
Obviously, good operating systems were neither tested nor given a chance to be tested.
So you're supposed to encode it again afterwards instead of having a sharable file in the first place? Now that's neat! I'm sure somebody will thank him for all the energy wasted due to this.
As far as I can see, Kega is completely closed source. Thus I highly doubt that part of the code would ever be released publicly, even if it's just a codec.
I'm sorry for the rant and I really think you meant it in a good way, but to me this is absolutely pointless. It might bring something for lowend machines, but stating that highend ones lag while capturing just because you've got an inferior OS is really the wrong thing to do. Guess he misunderstood the cause of the lag.
In a nutshell: this is a codec that's supposed to rival x264-lossless in compression ratio, and uncompressed raw in capturing speed. There actually is a whole lot of sense in making something like this, if you think about the processes involved.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
I disagree with everything ShinyDoofy has said.
This is pretty good news. Now if you had problems in the past with capturing and playing, you now have a better option.
ShinyDoofy's mention of x264 here was pretty silly, since x264 is one of the most cpu intensive codecs out there for video at this time. I assume x264 is what he's referring to when he mentions "can't keep up with 60fps".
I like this idea. If this were to be added to other emulators, this could also theoretically increase the speed of initial captures, saving encoders on this site some time. He's a bit vague with actual numbers though..
I find it really funny how ShinyDoofy complains about the choice here (re: no linux) yet somehow he completely forgets that Kega is Windows only. What is it that you expected?
This is the same as FRAPS, and is completely understandable. It's just a better way of doing initial captures, and really shouldn't be used for actual distribution.
What makes you think this won't be open-sourced? he has outright expressed his desire to open-source it. This isn't some Q&A where someone's actually pressed for it to be open-sourced, he's actually mentioned it's something he's willing to do.
I can't believe someone who is an encoder on this site can be so pessimistic and narrow-minded on what has the potential to be very useful if made well.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Great to see some discussion. :)
Sure that's correct, but for me it started off with the wrong argument. After all I find his definition of "highend" very vague. If he said something like capturing in general to be of poor performance, I would have understood, but like this? I don't know.
Raiscan wrote:
and using any of the available codecs either doesn't compress well enough to fix that, or does compress well enough, but can't keep up with 60fps, so you get poor performance either way.
ShinyDoofy's mention of x264 here was pretty silly, since x264 is one of the most cpu intensive codecs out there for video at this time. I assume x264 is what he's referring to when he mentions "can't keep up with 60fps".
If x264 is the one to blame, then why not fork it and create something new out of it instead of starting a codec from scratch? Sega games from this era have a really low resolution, so I assume that even older machines are capable of capturing the gameplay at a decent speed. If he started a codec that would not only generally outperform x264, but also have better quality at the same target size and be versatilely usable, I might try it out. Given that it's a purely lossless codec only designed and useable for this purpose, I'm not going to try it.
Raiscan wrote:
The codec is able to use hints from the emulator to aid in compression, allowing pretty good compression while taking very little CPU time.
I like this idea. If this were to be added to other emulators, this could also theoretically increase the speed of initial captures, saving encoders on this site some time. He's a bit vague with actual numbers though.
And that's just my point. It's all a little too vague. Helping the encoder out really is a great idea, but if this was to be his goal, he could have made it open source from the very beginning. I appreciate him even thinking about releasing his specs or even the code to the public, but see it this way: in order for this to be used by another emulator, he'd have to reveal parts of what he has kept secret from the public for over 10 years, as the emulator itself would have to be partially put open as well. I can't quite say why, but it feels like Microsoft's OpenXML. Most things are disclosed, but some just aren't. So my approach of either keeping everything shut or showing everything you've used is not met. One could call such an attempt half-assed, but it's too strong of an expression and doesn't quite match it imho.
Raiscan wrote:
The codec to allow you to play back and convert the files is included in the archive, and can be installed via right clicking on the INI file and telling the OS to continue with the install. Tested on XP and Vista64, should work fine on 9x and Vista32.
I find it really funny how ShinyDoofy complains about the choice here (re: no linux) yet somehow he completely forgets that Kega is Windows only. What is it that you expected?
I know that Kega is a purely Microsoft-software-based emulator (it was from the very beginning), I admit that I'm sometimes a bit of a OS nazi. It's not that I want to nuke Microsoft (well, sometimes I do, but not in this case), but laying something like this open also means that anyone is supposed to be able to use it, not just people natively running Windows. That's like saying "Hey, we're about to revolutionize the internet, but only for white people" in my eyes.
Raiscan wrote:
Note that these AVI files are not really meant to be shared as they are, it's just a way for you to log video without horrible laggy gameplay. Convert them to Xvid or something using the excellent VirtualDub program (Google it.)
This is the same as FRAPS, and is completely understandable. It's just a better way of doing initial captures, and really shouldn't be used for actual distribution.
As you probably know, different codecs use different colorspaces. I don't know for sure, but I guess it won't use yuv420p, so you'd also have to change the colorspace again, which takes more CPU time than actually capturing it in the previously desired codec. I used to capture Genesis games in FFV1 and the first pass of encoding ran at about 40 to 50 fps (due to the colorspace conversion, I assume; you're welcome to correct me if I'm wrong). When I captured the same games with x264, the first pass ran at 80-90fps. Imho this saves more time than using a faster codec for capturing and then having to slowly decode it again for using x264 (which encoders at this site are encouraged to use to publishing accepted runs).
Raiscan wrote:
I can't believe someone who is an encoder on this site can be so pessimistic and narrow-minded on what has the potential to be very useful if made well.
Usually, I welcome progress and new things in general, but this one has a somewhat bitter taste to it for me for the reasons stated above. If this really gets to be open source some day and any of the emulators we use here at TASvideos really support this, you're welcome to use it as long as the results are good. I, however, am not going to use it until I either see it running flawlessly and far better than x264 with my own eyes on my machine or I'm forced to use it. In case the latter becomes true and my objections are not resolved until then, I might as well quit before I voluntarily return to a closed source world where I'm bound to what the designers/programmers though was good for me instead of leaving the choice to me.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
Note: For readability, I have made my reply colour slightly different.
ShinyDoofy wrote:
Raiscan wrote:
* Added AVI Logging using custom Kega Game Video 1 lossless codec. This is needed because logging RAW video causes poor performance even on highend machines
This is pretty good news. Now if you had problems in the past with capturing and playing, you now have a better option.
Sure that's correct, but for me it started off with the wrong argument. After all I find his definition of "highend" very vague. If he said something like capturing in general to be of poor performance, I would have understood, but like this? I don't know.
When capturing RAW (uncompressed) frames, the bottleneck is the hard drive, not the cpu. Perhaps this is what he is referring to? Capturing RAW 320x240x60 is alot even for my RAID0 array. Apart from that, I'm unsure what he classes as "highend".ShinyDoofy wrote:
Raiscan wrote:
and using any of the available codecs either doesn't compress well enough to fix that, or does compress well enough, but can't keep up with 60fps, so you get poor performance either way.
ShinyDoofy's mention of x264 here was pretty silly, since x264 is one of the most cpu intensive codecs out there for video at this time. I assume x264 is what he's referring to when he mentions "can't keep up with 60fps".
If x264 is the one to blame, then why not fork it and create something new out of it instead of starting a codec from scratch? Sega games from this era have a really low resolution, so I assume that even older machines are capable of capturing the gameplay at a decent speed. If he started a codec that would not only generally outperform x264, but also have better quality at the same target size and be versatilely usable, I might try it out. Given that it's a purely lossless codec only designed and useable for this purpose, I'm not going to try it.
For him to fork x264, he would have to look through a huge amount of code and learn how it all works for him to change it. Why do that when you have something in your mind and how to do it efficiently? Who's to say he didn't base his codec on another anyway?ShinyDoofy wrote:
Raiscan wrote:
The codec is able to use hints from the emulator to aid in compression, allowing pretty good compression while taking very little CPU time.
I like this idea. If this were to be added to other emulators, this could also theoretically increase the speed of initial captures, saving encoders on this site some time. He's a bit vague with actual numbers though.
And that's just my point. It's all a little too vague. Helping the encoder out really is a great idea, but if this was to be his goal, he could have made it open source from the very beginning. I appreciate him even thinking about releasing his specs or even the code to the public, but see it this way: in order for this to be used by another emulator, he'd have to reveal parts of what he has kept secret from the public for over 10 years, as the emulator itself would have to be partially put open as well. I can't quite say why, but it feels like Microsoft's OpenXML. Most things are disclosed, but some just aren't. So my approach of either keeping everything shut or showing everything you've used is not met. One could call such an attempt half-assed, but it's too strong of an expression and doesn't quite match it imho.
All that needs to be opened up is what is passed to the codec from the emulator and how it's done. How does this mean that a large chunk of his emulator code needs to be opened up also? ShinyDoofy wrote:
Raiscan wrote:
The codec to allow you to play back and convert the files is included in the archive, and can be installed via right clicking on the INI file and telling the OS to continue with the install. Tested on XP and Vista64, should work fine on 9x and Vista32.
I find it really funny how ShinyDoofy complains about the choice here (re: no linux) yet somehow he completely forgets that Kega is Windows only. What is it that you expected?
I know that Kega is a purely Microsoft-software-based emulator (it was from the very beginning), I admit that I'm sometimes a bit of a OS nazi. It's not that I want to nuke Microsoft (well, sometimes I do, but not in this case), but laying something like this open also means that anyone is supposed to be able to use it, not just people natively running Windows. That's like saying "Hey, we're about to revolutionize the internet, but only for white people" in my eyes.
I wasn't aware skin colour could be chosen freely, and that there was a front layer for people of other races to appear and function as someone who is white. I think this is a flawed comparison. He's chosen to code an emulator for Windows. It's his choice. Making something open means anyone can get the source and modify it. It does not mean he has to make it cross platform.ShinyDoofy wrote:
Raiscan wrote:
Note that these AVI files are not really meant to be shared as they are, it's just a way for you to log video without horrible laggy gameplay. Convert them to Xvid or something using the excellent VirtualDub program (Google it.)
This is the same as FRAPS, and is completely understandable. It's just a better way of doing initial captures, and really shouldn't be used for actual distribution.
As you probably know, different codecs use different colorspaces. I don't know for sure, but I guess it won't use yuv420p, so you'd also have to change the colorspace again, which takes more CPU time than actually capturing it in the previously desired codec. I used to capture Genesis games in FFV1 and the first pass of encoding ran at about 40 to 50 fps (due to the colorspace conversion, I assume; you're welcome to correct me if I'm wrong). When I captured the same games with x264, the first pass ran at 80-90fps. Imho this saves more time than using a faster codec for capturing and then having to slowly decode it again for using x264 (which encoders at this site are encouraged to use to publishing accepted runs).
I'm not sure what you're getting at here. Surely if it doesn't change the colourspace then you're only delaying it for a conversion to another colour space at a later point in time? Why it would use anything other than RGB (which the games are natively in) or YV12 (which x264 uses) is beyond me, so I don't see why it would be a problem.ShinyDoofy wrote:
Raiscan wrote:
I can't believe someone who is an encoder on this site can be so pessimistic and narrow-minded on what has the potential to be very useful if made well.
Usually, I welcome progress and new things in general, but this one has a somewhat bitter taste to it for me for the reasons stated above. If this really gets to be open source some day and any of the emulators we use here at TASvideos really support this, you're welcome to use it as long as the results are good.
(emphasis added)
And if the results aren't good? What are you going to do? :P
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Given that the Genesis uses highly controlled video display (only x resolution settings, only x colors available, only x colors at a time/per frame) a custom, intermediary codec makes a lot of sense. I hate dealing with billions of codecs, but that's usually because people misuse them. Having codecs optimized for certain purposes is a different beast altogether.
Jesus christ, the sheer amount of whining that this thread started with is amazing. I'm honestly shocked nobody thought of this sooner, as it could make the intermediate capture time much faster for tile-based emulators.
X264 slows the emulator down to ~125% when AVI capturing as lossless.
I'm honestly kind of surprised nobody did this before.
Yeah, it sounds like a good idea. I don't particularly understand the "Computers are getting so much faster, why optimize?" argument- perhaps they want to use that cpu time for other purposes. [/bicker and argue about who killed whose cpu]
Something semi-related has been suggested before.(And a yet older topic.)
I'm not sure if the sprite information is the hints he's using, but...