Video codecs
category: general [glöplog]
I recently tried encoding videos with the H.264(x264) codec and the results were really superior to Xvid (halved filesize, better quality). Encoding took a bit longer though.
What is your oppinion on encoding demo captures with that codec? Should everybody be able to play those files if I put them into an AVI container? Will
CONS for me are that they can't be played back on external Video-Players (yet).
Any suggestions on Codec settings and/or different Audio codecs (MP3, AAC, OGG)?
Anyway, all (non-trolling) ideas/comments/hints are welcome... ;)
What is your oppinion on encoding demo captures with that codec? Should everybody be able to play those files if I put them into an AVI container? Will
CONS for me are that they can't be played back on external Video-Players (yet).
Any suggestions on Codec settings and/or different Audio codecs (MP3, AAC, OGG)?
Anyway, all (non-trolling) ideas/comments/hints are welcome... ;)
h.264 rocks hard. decoding is slower than xvid though, which presents something of a dilemma: you need a really fast machine to be able to view a 800x600 60fps h264 video without stutters, which kind of defeats the purpose of demo video captures (ok, you can use 30fps, but i prefer full framerate for demos when possible).
i'd definitely use it for archival and for relatively low-res source material (h.264 looks SO much better on pixeled graphics...); but for high-resolution and high-framerate captures, requirements are really a bit steep.
i'd definitely use it for archival and for relatively low-res source material (h.264 looks SO much better on pixeled graphics...); but for high-resolution and high-framerate captures, requirements are really a bit steep.
rarefluid: the standard container for x264 videos is .mkv, prolly for its multiaudio and multisub features, which aren't really necessary for demo purpose, but heh mkv is the de facto x264 standard so it would be better to use it instead of .avi...
As I watch all my videos with XBox-Media-Center, I would strongly discourage using H264, because it will only play with like 2-4 fps. XVid/MPEG2/etc. all play full-frame rate.
Maybe in a few years everybody can use it...
Maybe in a few years everybody can use it...
@Zest: that's the matroska-something container-type right?
@ryg: I have been capturing quite a few demos (mostly older stuff) in the last months and my opinion is that few demos need the full framerate. If there are no really fast moving objects, screen-flashes, scrolltexts or text displayed for a really short duration then 25-30fps works fine.
I have been resizing low-res-videos with a nearest-neighbour-filter to make use of the doubled chroma-resolution. Will that still be necessary for H.264? I have seen that there is a 4:4:4 profile available now...
@ryg: I have been capturing quite a few demos (mostly older stuff) in the last months and my opinion is that few demos need the full framerate. If there are no really fast moving objects, screen-flashes, scrolltexts or text displayed for a really short duration then 25-30fps works fine.
I have been resizing low-res-videos with a nearest-neighbour-filter to make use of the doubled chroma-resolution. Will that still be necessary for H.264? I have seen that there is a 4:4:4 profile available now...
My media center has an Athlon64 X2 3600+, but I dol care about other people being able to watch my captures, that's why I'm asking here... :)
XBMC is quite nice btw. A friend of mine uses it too.
I use KnoppMyth on my box and really love it!
XBMC is quite nice btw. A friend of mine uses it too.
I use KnoppMyth on my box and really love it!
And what do you think about audio codecs? IMHO every hardware player supports MP3, but few support MP4/AAC, and even fewer OGG. So maybe MP3 ist still the way to go for now...
rarefluid: really needing (i.e. looking like crap without) the full framerate is one thing, but most demos still look notably better with it, so i definitely prefer it. and on oldschool platforms, it's simply a must (and for example the breakpoint team spent considerable time doing "R&D" to make high quality full framerate captures of c64/amiga demos a reality, which was definitely worth it).
a 4:4:4 profile for h.264 exists, but that's together with 14 bit per color channel (so mainly for archival purposes) and i know no current encoder that actually supports it.
as for container format, matroska is great, but the standard container for h.264 would definitely be a mpeg4 systems steam (i.e. .mp4 files).
audio, well... for movies, where you typically use about 700-900kbps for the video stream (and this is with xvid, with h.264 you can go considerably lower than that), it does make a notable difference whether you replace 160/128 kbit MP3 with 128/96kbit AAC; for demos, where you typically end up in the multi-megabit range no matter what, it's not such a big factor and i guess the most compatible option is the best.
(and as for ogg - well, most containers have serious issues with variable bitrate audio, so together with the lack of support, i really wouldn't recommend this)
a 4:4:4 profile for h.264 exists, but that's together with 14 bit per color channel (so mainly for archival purposes) and i know no current encoder that actually supports it.
as for container format, matroska is great, but the standard container for h.264 would definitely be a mpeg4 systems steam (i.e. .mp4 files).
audio, well... for movies, where you typically use about 700-900kbps for the video stream (and this is with xvid, with h.264 you can go considerably lower than that), it does make a notable difference whether you replace 160/128 kbit MP3 with 128/96kbit AAC; for demos, where you typically end up in the multi-megabit range no matter what, it's not such a big factor and i guess the most compatible option is the best.
(and as for ogg - well, most containers have serious issues with variable bitrate audio, so together with the lack of support, i really wouldn't recommend this)
Well. I'm constantly trying to check/improve quality. Still learning...
For now I'll resort to full-frame, Xvid, MP3 then.
I was planning on recapturing some of the older stuff I did anyways. Some of that is okish, but could be done better.
I would love to make a go for H.264, but few people will be able to watch it, which is not what I want... Encoding everything twice may be an option if I can use/improve my virtualdub scripts for that. Or write a simple encoder myself. Another issue will be webspace then... Will have to bug scamp with that ;)
For now I'll resort to full-frame, Xvid, MP3 then.
I was planning on recapturing some of the older stuff I did anyways. Some of that is okish, but could be done better.
I would love to make a go for H.264, but few people will be able to watch it, which is not what I want... Encoding everything twice may be an option if I can use/improve my virtualdub scripts for that. Or write a simple encoder myself. Another issue will be webspace then... Will have to bug scamp with that ;)
rarefluid: you may not want to follow the standards of the 'other' scene but their rules can give good pieces of advice.
and if you go h264 i advise you to go at least 720p (that is 1280*720).
and if you go h264 i advise you to go at least 720p (that is 1280*720).
h.264 is the state-of-the-art in codecs... I think.
Quote:
h.264 rocks hard. decoding is slower than xvid though, which presents something of a dilemma: you need a really fast machine to be able to view a 800x600 60fps h264 video without stutters, which kind of defeats the purpose of demo video captures
I disagree a bit here. For me, video recordings of demos have been to see demos that I wouldn't be able to see otherwise - eg from other platforms than my own. And then I much prefer to see the better codec used to save quality, bandwidth and to some extent disk space (though not very important any longer..).
As mainstream software players do H.264/AVC just fine (VideoLAN Client for example) it's time to move on. Xbox 1 is what, six years old now? Then the 30/60 FPS question, I guess it's mostly a matter if you can support the bandwidth for having twice the load, then go 60.
Ryg, a question. How do you do the 50 FPS recordings from Amiga, C-64 etc ? Do you have hardware or software that puts up the interlaced fields as two progressive ones ? If so, how does it look with real hires (480-576 lines) images (I imagine it will blend the lines then) ?
Unfortunately, there's nothing like XBMC (XBoxMediaCenter) e.g. for the XBox360, that's the main reason I'm still using XBMC. I really quit watching videos on my PC when I discovered XBMC. It simply rules, and I really hope that there will be an equivalent on a next-gen console (XB360 or PS3) with full HD support in the near future... (for now my old 32" 16:9 CRT is still working great) :)
Bartman: I understand that XBMC is being ported to Linux now, once done any PC would do the job with a lot more horsepower. Personally I've grown tired of buying one DVD player after the other with one new codec added each time, so I run the videos from the computer to the big screen, works quite well too and it does any resolution :)
zest: guidelines for movies/tv series are pretty useless, at least as far as the target sizes are concerned. most demos have most of the screen changing constantly and you need a significantly higher bitrate if you don't want to end up with a blurry mess.
and 720p has great quality, but is really cpu-hungry for playback, so it's not an option if you're targeting lower-spec machines, which is the main reason for doing videos of demos on PCs (there's nearly nothing on xbox360/ps3 yet, all handhelds are lowres, and all other consoles are PAL/NTSC so 720p doesn't make sense there).
and again, 720p@30fps for demos is a LOT more cpu-hungry than the same for movies/tv series: higher bitrate means more time spent decoding the bitstream (yes, that takes a significant amount of time during playback, especially since most of the rest is hw accelerated by now) and more motion means a bigger screen area that needs to be updated. this can easily get you in trouble even on relatively recent machines - for example kbs 1280x640@30fps h.264 video of debris doesn't have significantly lower minimum system specs for smooth playback than debris itself :) (cpu-wise, that is - it's of course the way to go if your graphics card is too slow). and debris is really quite well-behaved. especially demos with a layer of noise on top (hello mfx) are a bitch to encode properly (and prolly 2x as big as they would be without the noise).
30/60fps is an interesting case. it depends heavily on the source material. for some demos (e.g. the aforementioned ones with noise layer on top) doubling the framerate nearly doubles the required bit rate. but mostly, the slope of that curve is far more gentle, because the motion vectors and coded residuals tend to be notably smaller for high-framerate material (as long as it contains smooth motion). for "well-behaved" demos, a good 60fps encode has a lot lower than twice the bitrate of a good 30fps version. i don't have any concrete numbers to compare right now, but from experience i'd say it tends to be between 20-40% more, which is ok.
h.264 decoding THAT slow on xbmc sounds pathological. probably certain asm optimizations not compiled in for some reason (or something similar). performance is not going to be stellar on a xbox1, but it should be better than 1-2fps.
evil: we recorded the material as dv. we then encoded it using mencoder with yadif (deinterlacing filter using edge-directed interpolation that keeps the full 50fps) and mcdeint (motion-compensating deinterlacer running after yadif).
yadif is basically a run-of-the-mill deinterlacing filter that is fast, has reasonable quality and blurs less than most deinterlacers. mcdeint first does motion estimation using available data in the current and adjacent fields. wherever the results seem to be accurate, it then replaces the interpolated data yadif generated with data extrapolated from the image data in adjacent frames and the estimated motion. this is fucking slow but gives pretty spectacular results as far as reconstruction quality is concerned.
if you feed it an interlaced image that is standing still, the result is "mostly" the original image (you may still get some slight blurring depending on what happened during sampling and DV encoding).
and in case someone wonders what the breakpoint team "R&D" was if we just use mencoder, well, aside from tweaking the settings, we also had to figure out how to play DV video from disk at 50fps without stutters (NOT as easy as it sounds) and get the software and infrastructure in place to make the whole thing scale (hooray for sponsored machines :)).
and 720p has great quality, but is really cpu-hungry for playback, so it's not an option if you're targeting lower-spec machines, which is the main reason for doing videos of demos on PCs (there's nearly nothing on xbox360/ps3 yet, all handhelds are lowres, and all other consoles are PAL/NTSC so 720p doesn't make sense there).
and again, 720p@30fps for demos is a LOT more cpu-hungry than the same for movies/tv series: higher bitrate means more time spent decoding the bitstream (yes, that takes a significant amount of time during playback, especially since most of the rest is hw accelerated by now) and more motion means a bigger screen area that needs to be updated. this can easily get you in trouble even on relatively recent machines - for example kbs 1280x640@30fps h.264 video of debris doesn't have significantly lower minimum system specs for smooth playback than debris itself :) (cpu-wise, that is - it's of course the way to go if your graphics card is too slow). and debris is really quite well-behaved. especially demos with a layer of noise on top (hello mfx) are a bitch to encode properly (and prolly 2x as big as they would be without the noise).
30/60fps is an interesting case. it depends heavily on the source material. for some demos (e.g. the aforementioned ones with noise layer on top) doubling the framerate nearly doubles the required bit rate. but mostly, the slope of that curve is far more gentle, because the motion vectors and coded residuals tend to be notably smaller for high-framerate material (as long as it contains smooth motion). for "well-behaved" demos, a good 60fps encode has a lot lower than twice the bitrate of a good 30fps version. i don't have any concrete numbers to compare right now, but from experience i'd say it tends to be between 20-40% more, which is ok.
h.264 decoding THAT slow on xbmc sounds pathological. probably certain asm optimizations not compiled in for some reason (or something similar). performance is not going to be stellar on a xbox1, but it should be better than 1-2fps.
evil: we recorded the material as dv. we then encoded it using mencoder with yadif (deinterlacing filter using edge-directed interpolation that keeps the full 50fps) and mcdeint (motion-compensating deinterlacer running after yadif).
yadif is basically a run-of-the-mill deinterlacing filter that is fast, has reasonable quality and blurs less than most deinterlacers. mcdeint first does motion estimation using available data in the current and adjacent fields. wherever the results seem to be accurate, it then replaces the interpolated data yadif generated with data extrapolated from the image data in adjacent frames and the estimated motion. this is fucking slow but gives pretty spectacular results as far as reconstruction quality is concerned.
if you feed it an interlaced image that is standing still, the result is "mostly" the original image (you may still get some slight blurring depending on what happened during sampling and DV encoding).
and in case someone wonders what the breakpoint team "R&D" was if we just use mencoder, well, aside from tweaking the settings, we also had to figure out how to play DV video from disk at 50fps without stutters (NOT as easy as it sounds) and get the software and infrastructure in place to make the whole thing scale (hooray for sponsored machines :)).
hehe someone has deeply thought about the subject of video-encoding demos :D
but i don't see the interest of using h264 power and hunger if that means targetting the same basic requirements as xvid.
i would stay within the standards, that means using common mpeg2 or old mpeg4 like xvid if you seek the largest playability. And h264 in HD format for future standard longevity.
now as Ryg clearly stated, some demos may need more bitrate and CPU than an average movie, but heh that wouldn't be the first time that demos are titillating the standard limits ;D
but i don't see the interest of using h264 power and hunger if that means targetting the same basic requirements as xvid.
i would stay within the standards, that means using common mpeg2 or old mpeg4 like xvid if you seek the largest playability. And h264 in HD format for future standard longevity.
now as Ryg clearly stated, some demos may need more bitrate and CPU than an average movie, but heh that wouldn't be the first time that demos are titillating the standard limits ;D
btw for PC playback, modern vidcard lines (6xxx-7xxx-8xxx for nvidia) do partially accelerate h264 decoding and you need 'only' to use a codec that does support this hardware decoding (like PowerDVD one). It's still CPU-hungry but it does alleviate the CPU load : it makes my outdated sempron 3000+ play 720p h264 smoothly.
I tried playing back a capture of "Bomb!- State of mind" with VLC, encoded with 640x400, 2000kBps, h.264, 60fps (58MB) on an "older" Pentium Dual-Core and had like 50-60% cpu load...
Quality was noticeably better than the Xvid encoding with 4000kBps (108MB), which played with 40-50% cpu load.
bartman: The Xbox has a 733MHz P3 CPU and a 133MHz bus. That's not much, even for MPEG2 and MP4... x264 is not that mature yet, so there is probably some performance gain possible in the future.
How much frames do you have with MP4/Xvid videos? If you look at my figures, the difference shuold not be as dramatic as it is in your case...
Almost all encodings of old DOS demos will have similar resolutions. I don't think it makes sense to rescale demos more 2x if they have a low resolution. So that leaves me with stuff <720p which should be manageable by a decent PC.
And I second that "hello mfx" :D
Quality was noticeably better than the Xvid encoding with 4000kBps (108MB), which played with 40-50% cpu load.
bartman: The Xbox has a 733MHz P3 CPU and a 133MHz bus. That's not much, even for MPEG2 and MP4... x264 is not that mature yet, so there is probably some performance gain possible in the future.
How much frames do you have with MP4/Xvid videos? If you look at my figures, the difference shuold not be as dramatic as it is in your case...
Almost all encodings of old DOS demos will have similar resolutions. I don't think it makes sense to rescale demos more 2x if they have a low resolution. So that leaves me with stuff <720p which should be manageable by a decent PC.
And I second that "hello mfx" :D
Zest: H264 is pretty standard. Every HD camera uses it.
And I didn't know about mencoder! That thingy'd fit nicely into "my toolchain" :)
I think I'll at least give x264 a try and see how it works out...
I think I'll at least give x264 a try and see how it works out...
rarefluid: indeed, keeping the genuine resolutions for old DOS demos makes sense :)
rarefluid: nice collection you have done on your page, it would be cool that you release it as a whole package when your codec/res/bitrate dilemmas are fixed (maybe if you have begun with xvid you'd better keep it besides h264).
The way I see it is that there are two reasons for making a video: so people with older machines / different platform etc. can see it, and preserving it for the future. I reckon then that it might be best to do two videos - say 640x480 xvid for the older machines (and maybe getting a quick look at a demo you can't run) and a high quality 720p h264 copy for future viewing. Not so nice for whoever hosts it of course...
One question though, what are the best formats to actually use for compatibility? Xvid seems to be mpeg4 - so why not just use .mp4 files? And h264 - I've seen that saved as avi, h264, mov, mp4, and somebody mentioned mkv. Does one of them work nicely in most players?
Actually, one more question. Most of these formats are made for live video, demo content is pretty different - is there a codec better suited to it?
One question though, what are the best formats to actually use for compatibility? Xvid seems to be mpeg4 - so why not just use .mp4 files? And h264 - I've seen that saved as avi, h264, mov, mp4, and somebody mentioned mkv. Does one of them work nicely in most players?
Actually, one more question. Most of these formats are made for live video, demo content is pretty different - is there a codec better suited to it?
Zest: Scaling captures up 2x (320x200->640x400) should make them look better(more original) when playing them back and you have a higher chroma resolution which should provide more quality when compressing. I don't know if this is still necessary with h.264 though...
Releasing it as a package would be quite painful. I'd need to recapture a lot of older stuff to provide a decent compilation. I think that most people should be able to play the videos on their PC/Mediacenter/DVD-Player, so IMHO there's no real need for that...
Releasing it as a package would be quite painful. I'd need to recapture a lot of older stuff to provide a decent compilation. I think that most people should be able to play the videos on their PC/Mediacenter/DVD-Player, so IMHO there's no real need for that...
psonice: XviD is an implementation of MPEG-4 Part 2: (Advanced) Simple Profile, that's right. It's also correct that the natural file format for these clips should be MP4, but AVI is the "de facto" standard for that format, for historical reasons (back when the MP4 container format was specified, the video codecs were already in wide use). Modern media player software doesn't care that much about the container format -- using MPlayer or VLC, you should be able to play both XviD and H.264 content in AVI, MOV, MP4 and Matroska containers without problems. If you want DirectShow support, you need ffdshow or some other MPEG-4 decoder filter and Haali Media Splitter.
For hardware players (read: standalone DVD players that also happen to play DivX movies) the situation is a little bit more complicated. First of all, none of these devices will play H.264 (yet). The same goes for Matroska containers. Even for DivX/XviD video, most players are limited to the AVI container format; those who do support MP4 are usually labelled with a "nero Digital" compatibility sign.
rarefluid: I completely agree with the 2x upscaling "trick". Every common video codec (MPEG-1 to -4, H.261-H.264, WMV1-3, you name it) normally uses 4:2:0 chroma subsampling, so you will get some bad color bleeding at sharp edges if you don't upscale prior to encoding. The alternative would be 4:4:4 encoding, but this isn't supported by most codec implementations.
For hardware players (read: standalone DVD players that also happen to play DivX movies) the situation is a little bit more complicated. First of all, none of these devices will play H.264 (yet). The same goes for Matroska containers. Even for DivX/XviD video, most players are limited to the AVI container format; those who do support MP4 are usually labelled with a "nero Digital" compatibility sign.
rarefluid: I completely agree with the 2x upscaling "trick". Every common video codec (MPEG-1 to -4, H.261-H.264, WMV1-3, you name it) normally uses 4:2:0 chroma subsampling, so you will get some bad color bleeding at sharp edges if you don't upscale prior to encoding. The alternative would be 4:4:4 encoding, but this isn't supported by most codec implementations.
