View Full Version : What do you think would yield better quality?
aabxx
6th August 2006, 23:46
Interlaced material encoded as (without any preprocessing)
1. Interlaced xvid
2. Progressive h.264 (no deinterlacing done beforehand, meaning you're encoding interlaced frames as if they were progressive)
What do you reckon? I'm talking about at same, middle-ish bitrate.
lexor
7th August 2006, 03:52
The only way I see x264 handling option 2 is if it will take even lines and interpolate for odd (similarly with odd) that will result in double the frames, twice the frames with same bitrate => lower quality, and it will still require some sort of avisynth filter. Interlaced Xvid then, if those 2 are your only options.
aabxx
7th August 2006, 04:43
Some conclusions of mine after a lot of testing:
1. x264 and ateme mess up interlaced encodings a lot in some scenes when encoded as progressive, although they're still quite acceptable. But they're no match for xvid with interlacing enabled.
2. I'm not particularly impressed with h.264 at high bitrates so far. At least not for my noisy vhs captures. After comparing deinterlaced input, xvid to me looks better than x264 and ateme at high bitrates (I'm talking bitrates around 2000-3000 kbps). And I've tried x264 and ateme with quite a few combinations now. The metrics however have all shown very clear advantages to both x264 and ateme in all cases I tried, yet, xvid looked better to me most of the time. That's why I don't trust metrics AT all, because when they tell me h.264 looked a lot better technically speaking than xvid, and yet xvid looks better, they don't make much sense practically speaking, do they?
3. I fully understand that my VHS caps are perhaps not the most usual type of encoding material, and full of noise (I don't like to denoise). And h.264 might perhaps looks better to me at high bitrates on dvd rips and stuff like that. However, I'm not particularly impressed with how they handle noise. And I tried a lot of deblocking settings (and on and off). Yet, I must confess I'm both a x264 and ateme newbie so maybe my settings were just not good enough... but I did my best and used many hours on comparisons (and am still doings some now at 5:30 AM :D).
4. It is a pretty serious limitations of the current encoders that interlaced handling is so dodging. X264 has an older hack, while with mainconcept the decoder always does something strange despite testing with lots of settings and with 2 different interlaced-capable decoders. I think x264 will take a huge step forward when it has proper interlaced handling. However, I think I'll stick with xvid to be honest for the future as well. I always encode at huge bitrates simply because I have several terabytes of disk space already. And lots of people have xvid-capable (within limits of course) dvd-players (it might take years before h.264 becomes that mainstream), it is quicker to decode and edit with and has much more software support (editing h.264 is no go with many of the video editing tools I use). Easy choice, really.
Having said that, it's still a very useful addition to the family because of its low bitrate handling, of course, and I suppose the only way forward for internet trading of video files (while I might have the space to download huge xvids, it makes much more sense bandwidth-wise to shift over to h.264). So if I put things online, I'll surely use it.
This huge post in response to those who've very enthusiastically hyped and recommended h.264 to me :D
lexor
7th August 2006, 14:19
what do you mean x264 has dodgy interlace support? it has NO interlace support, you have to deinterlace using avisynth filters, otherwise you'll get garbage.
unskinnyboy
7th August 2006, 15:35
I think you missed this (http://forum.doom9.org/showthread.php?t=111527) thread. x264 *does* have interlaced support, albeit rudimentary.
Jay Bee
7th August 2006, 16:40
4. It is a pretty serious limitations of the current encoders that interlaced handling is so dodging. X264 has an older hack, while with mainconcept the decoder always does something strange despite testing with lots of settings and with 2 different interlaced-capable decoders. I think x264 will take a huge step forward when it has proper interlaced handling. However, I think I'll stick with xvid to be honest for the future as well. I always encode at huge bitrates simply because I have several terabytes of disk space already. And lots of people have xvid-capable (within limits of course) dvd-players (it might take years before h.264 becomes that mainstream), it is quicker to decode and edit with and has much more software support (editing h.264 is no go with many of the video editing tools I use). Easy choice, really.
Yes it's odd how little interst there seems to be for true interlaced encoding and decoding support. Probably because most people are just more interested in ripping Hollywood movies than recording interlaced content like sports etc.
XviD can do the encoding but ignores the interlaced flag when decoding. CoreAVC can do the decoding but I haven't been very successfull with AVC interlaced encoding trying several encoders.
Right now I'm keeping my recordings in MPEG-2 and hoping that the upcoming new version of Nero will have good interlaced support. That or wait for x264 to officially add interlaced encoding.
lexor
7th August 2006, 17:25
I think you missed this (http://forum.doom9.org/showthread.php?t=111527) thread. x264 *does* have interlaced support, albeit rudimentary.
neither Shark's nor bobor's builds have any interlace support (even normal cvs checkout won't give you interlace code), and he doesn't sound like he compiled he's own.
unskinnyboy
7th August 2006, 18:54
That's because the patches supporting interlacing were pulled from the latest SVN, due to it slowing down progressive encoding (as per pengvado). When they have troubleshooted and fixed that, the patches will be back. You could always use an older SVN, 532, meanwhile.
Thus my whole point about the interlaced support in x264 being dodgy, but there nonetheless, if really needed.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.