Where's LenOx now?

[ukb008]

The incredible coder, LenOx, has disappeared again! His last post after re-surfacing was in 2009.

I can't help thinking about his AutoGK now and then. XviD is still in use, although most of us has moved to x264. Everything changes. MeGUI has changed life more than any other thing.

How about x264 support in AutoGK? But, more importantly, where's LenOx?

:confused:

Regards.

[LoRd_MuldeR]

XviD is still in use, although most of us has moved to x264. Everything changes. MeGUI has changed life more than any other thing.

H.264 compresses more efficient than MPEG-4 ASP (Xvid, DivX, etc), H.264 is widely-used nowadays (it is used everywhere from "mobile" devices and web-streams up to HDTV broadcast and BluRay), basically all hardware players you can buy today support H.264 and with x264 we have a very good OpenSource H.264 encoder available. So I'd says there are very few reasons to use MPEG-4 ASP (e.g. Xvid) nowadays.

How about x264 support in AutoGK?

AutoGK is based on VirtualDubMod and VirtualDubMod is a dead project itself. Moreover VirtualDub(Mod) relies on the antiquated VFW interface.

Although using x264 through VFW is possible, that's not exactly the preferred method to use x264.

At the same time there are a whole lot of GUI's for the x264 command-line encoder available from which you can choose, so why do we need yet anther one?

With the author of AutoGK apparently not working activity on the project anymore, I guess the chance for future updates are low anyway.

But, more importantly, where's LenOx?

Probably only LenOx himself knows ;)

If he currently isn't interested or doesn't have the time to update his software projects and/or post on Doom9, then there's not much we can do about it...

[yetanotherid]

H.264 compresses more efficient than MPEG-4 ASP (Xvid, DivX, etc), H.264 is widely-used nowadays (it is used everywhere from "mobile" devices and web-streams up to HDTV broadcast and BluRay), basically all hardware players you can buy today support H.264 and with x264 we have a very good OpenSource H.264 encoder available. So I'd says there are very few reasons to use MPEG-4 ASP (e.g. Xvid) nowadays.

I wish all the DVD players everyone else in this house use to watch video could play x264. ;)
So yes.... for them it's still AVI and of course AutoGK.

At the same time there are a whole lot of GUI's for the x264 command-line encoder available from which you can choose, so why do we need yet anther one?

One which resizes and crops the way AutoGK does would be nice. To the best of my knowledge when it comes to resizing (square pixels) all encoders fudge the aspect ratio to fit it into mod-16 dimensions rather than crop it in an AutoGK fashion. Although at least HDConvertToX calculates the amount of fudge to allow you to crop manually in order to achieve the same result AutoGK does automatically.
There's one "why" I've never worked out... a while back I converted a bunch of HD stuff to SD AVI using AutoGK. While I was at it I converted a few files with MeGUI and HdConvertToX for comparison. I don't know whether it's the resizing method (it's not the XviD encoder version) or something else, but each and every time the AutoGK encodes looked slightly better. Only slightly, but the AutoGK encodes retained slightly more of the fine detail.

Maybe it's those sorts of reasons which have AutoGK users longing for an upgraded version.....

[Gser]

I wish all the DVD players everyone else in this house use to watch video could play x264.lol That is would be completely redundant as that is why there are blu-ray players on the market. Its like saying I wish my diesel engine would use gasoline.

[LoRd_MuldeR]

I wish all the DVD players everyone else in this house use to watch video could play x264. ;)
So yes.... for them it's still AVI and of course AutoGK.

Legacy standalone players that support MPEG-4 ASP but not H.264 probably are the only reason to still use Xvid. However any new standalone player will definitely support H.264 nowadays. And you can get such players for very little money. So this might be worth thinking about an upgrade...

(It doesn't necessarily have to be an "optical disc" player. There are various HDD Players or Streaming Clients that might do the job just as well, depending on your specific needs)


One which resizes and crops the way AutoGK does would be nice. To the best of my knowledge when it comes to resizing (square pixels) all encoders fudge the aspect ratio to fit it into mod-16 dimensions rather than crop it in an AutoGK fashion. Although at least HDConvertToX calculates the amount of fudge to allow you to crop manually in order to achieve the same result AutoGK does automatically.
There's one "why" I've never worked out... a while back I converted a bunch of HD stuff to SD AVI using AutoGK. While I was at it I converted a few files with MeGUI and HdConvertToX for comparison. I don't know whether it's the resizing method (it's not the XviD encoder version) or something else, but each and every time the AutoGK encodes looked slightly better. Only slightly, but the AutoGK encodes retained slightly more of the fine detail.

Maybe it's those sorts of reasons which have AutoGK users longing for an upgraded version.....

First of all, encoding at non-mod16 isn't such a big deal as many people seem to believe. The loss in compression efficiency is so small that you shouldn't worry too much about it. Anyway, if you need to adjust a non-mod16 video to mod16 for whatever reason, I'd always prefer cropping over resizing. And every halfway decent GUI should allow you to do so, if required.

Moreover all Xvid GUI's use the Xvid library. So given you use the identical source, the same Xvid version and the same Xvid settings, the output will be identical. AutoGK doesn't do magic ;)

[yetanotherid]

lol That is would be completely redundant as that is why there are blu-ray players on the market. Its like saying I wish my diesel engine would use gasoline.

Nahhhh... that's not even a close analogy. Had I said I wish all the DVD players in the house ran off rechargeable batteries your analogy might then make sense.
Maybe try comparing it to wishing my car had an electric motor instead of a diesel one to see if that works better, although I guess it'd still require an explanation as to why the availability of cars with electric motors precludes me from wishing...

[yetanotherid]

Moreover all Xvid GUI's use the Xvid library. So given you use the identical source, the same Xvid version and the same Xvid settings, the output will be identical. AutoGK doesn't do magic ;)

Well... I'll go and munch on some crow shortly.....
I was so sure there were differences.... well there were... and as I could remember which video I played with the most at the time I dug out the AutoGK encode and encoded part of the original again using HDConvertToX. This time, the two encodes were basically the same. I'm 100% sure I used the same resizer last time too though...

Why.... I've no idea. My experimenting was at least one reformat ago and most of the software has been upgraded since, so I guess whatever differences there once were (and really, truly, there were differences) they're not there now. I'm half tempted to take the PC back a year or two by restoring an old Ghost image and running another encode for comparison, just to see if I can work out why, but hopefully that inclination will pass fairly quickly. I might go and make a coffee and annoy the dog until it does....

So yep.... aside from having to lose a few extra pixels to keep the aspect ratio intact when encoding using HDConvertToX, there were none of the differences in the fine detail I thought there'd be.
I'm not sure if it's being wrong, or admitting to being wrong, but one of them makes me feel a little queasy....

[manolito]

Legacy standalone players that support MPEG-4 ASP but not H.264 probably are the only reason to still use Xvid. However any new standalone player will definitely support H.264 nowadays. And you can get such players for very little money. So this might be worth thinking about an upgrade...

What ??
Three of my friends and relatives recently bought new standalone DVD players (DVD - Not BlueRay because they do not care about HD), and all of these players do support DivX playback, but none of them can handle H.264. All these players can upconvert SD stuff to HD, they all have HDMI connectors, but H.264? Sorry, No.

So I think you are talking about BlueRay standalone players, right?

And there also is no need for badmouthing VDub
Moreover VirtualDub(Mod) relies on the antiquated VFW interface.
Avery Lee has some very good reasons to stick with the VFW interface, and in my experience VDub handles many tasks way better than Avidemux which does not use the oh so antiquated VFW interface.


Cheers
manolito

[LoRd_MuldeR]

What ??
Three of my friends and relatives recently bought new standalone DVD players (DVD - Not BlueRay because they do not care about HD), and all of these players do support DivX playback, but none of them can handle H.264. All these players can upconvert SD stuff to HD, they all have HDMI connectors, but H.264? Sorry, No.

Well, these are the "legacy" players I have been talking about. I certainly wouldn't recommend to buy such a player nowadays. You can get a fully-fledged BD Player for little money (like ~100€) noways. Such player will handle Video-DVD too, of course (usually including some fancy "upscale" filter). And it naturally supports H.264 as well as VC-1, which is a huge advantage IMHO.

So I think you are talking about BlueRay standalone players, right?

Not only! As said before, if your main purpose is playing your own encodes, then a Streming Client or a HDD Player (also available for ~100€) might do the job just as well - or even better, as you don't need to burn everything to a DVD-R before watching on the stand-alone. Really, you don't have to use an "optical disc" player for H.264 playback. The ultimate solution is a "Media Center" PC, of course...

Avery Lee has some very good reasons to stick with the VFW interface, and in my experience VDub handles many tasks way better than Avidemux which does not use the oh so antiquated VFW interface.

I don't know why you mention Avidemux here (and what problems you are reffering to), because it certainly is not the only GUI that uses x264 without VFW. Actually I'm not aware of any x264 GUI that still uses x264 through VFW, except for VirtualDub[Mod] (and the tools that build on top of VDub[Mod]). Especially because VFW is a Windows-only technology. VirtualDub[Mod] basically is the only (relevant) application that still relies on VFW and the only "good" reason to stick with VFW is for historical reasons (apparently people prefer to stick with the VFW Codecs they have been using since the early "DivX era"). Because of the ongoing popularity of VirtualDub[Mod] various "hacks" have been invented to get H.264 working with VFW and AVI (more or less), but that's not really a "pro" argument...

[smok3]

there is gazillion codecs for production purposes that have vfw interface, so that is actually quite usefull, also the new beta versions of virtualdub can pipe to external encoders, including x264 ( http://forum.doom9.org/showthread.php?p=1468681#post1468681 ).

[LoRd_MuldeR]

also the new beta versions of virtualdub can pipe to external encoders, including x264 ( http://forum.doom9.org/showthread.php?p=1468681#post1468681 ).

That seems like the logical step into the right direction.

However I wonder how complicated it will be for the Average Joe user to create/edit the required configuration files, e.g. for adjusting a specific x264 option.

VDub already supports Filter and Input plug-ins. Would be great if they finally added Output plug-ins in an Avidemux-like fashion...

(This way we could use libx264 in VDub through its "native" interface and with a fully-fledged configuration dialog)

[smok3]

personally i could construct an x264 version with the appropriate encoders + setup, but i wonder if that kind of binary distribution would be gpl compatible/legal, or with other words, how to make it legal?
edit: Actually i'd have to use FAAC instead of nero for audio, so that complicates matters even further...

[LoRd_MuldeR]

Redistributing binaries of GPL'd or LGPL'd software is no problem at all, as long as you include the (modified) sources or make the sources available for free on request. Nero AAC is released under a proprietary license, which doesn't allow redistribution. You'll have to ask the user to download it manually (that's what I do) or use an alternative...

[ukb008]

"Buckethead can pick up a guitar hero controller that aint pluged in and compose a masterpiece"
My software projects | My system specifications

Hello, LoRd

I visited your homepage at http://code.google.com/p/mulder/downloads/list and found a number of your creations. These are GPL'd so of course one can't complain, but may I suggest you append a two-sentence description with the lesser-known one ones (like Chromium-updater)?

Sorry for going off-topic.

Thanks and regards.

[LoRd_MuldeR]

Hello, LoRd

I visited your homepage at http://code.google.com/p/mulder/downloads/list and found a number of your creations. These are GPL'd so of course one can't complain, but may I suggest you append a two-sentence description with the lesser-known one ones (like Chromium-updater)?

Sorry for going off-topic.

Thanks and regards.

I still hope that one day my main web-site will be back "online". Currently I don't have the time to do this :rolleyes:

(BTW: The "Chromium Updater" does what the name implies, it downloads/installs the latest build of Chromium. Chromium is the OpenSource variant of Chrome)