View Full Version : My New Website about x264 - Need help proofreading
steve77
3rd March 2007, 20:18
Here it is:
Encoding x264 Video - A Practical Guide (http://gillam.chris.googlepages.com/)
I eventually plan to host all those hard to find scripts (with the author's permission of course) and elaborate on diffrent concepts like denoising, specific case studies, etc.
I am pretty good at the whole thing but I'm obviously not a guru like some of you here. I therefore ask and for constructive criticism, paticuarly on the content.
I'm pretty much finished the "Guide part"... haven't started the more advanced stuff (which I'll most definately need help.)
I just thought it's the website I wanted when I started video encoding, and maybe it'll be useful to other noobs.
I hope I'm not breaking any forum rules, I could just use your guidance and suggestions.
After all, we're all after the same thing, and if this forum taught me anything, is that THIS is the place for help.
Warmest Regards,
steve77
check
4th March 2007, 11:01
looks good. Here are a few points:
o Have you considered using AvsP instead of VDub for editing the avisynth script? Although in your example it's not needed, letting them use such a tool from the outset will make it far easier for them if they want to start getting into more complex scripts.
o Why not completely replace the visual inspection stage with the megui avs creator? It will function as well, (better imo) for the task required.
o I've never experienced any VBR audio issues with mp4 output. The only VBR issues I know of are in AVI. Are you sure such problems exist?
o ResizedCroppedandDeinteralced.jpg ;)
Finally, a little plug. It's related enough to megui to go onto the mewiki (which is turning into a more general reference all the time now), if you would like it to be hosted there I'd be happy to have it :). Centralisation of video resources I think can only be a good thing.
EDIT:
However, using too many of these may reduce overall quality significantly - Not true. The setting is for *maximum* b frames, so if x264 can get higher quality by not using the extra bframes, it will not use more. It just allows x264 more flexibility, and hence higher quality, when determining frame types.
smok3
4th March 2007, 11:47
Nice work. (I could write the x264 encoding part using command line if you are interested..., i find it easier than using megui.)
steve77
4th March 2007, 13:48
I was going out on a limb for a few things; as I've mentionned I'm not a x264 GURU (hence the proof-reading).
-VBR issues --> With AVIs, had them all the time. If mp4 is good to go, I'll make sure to change that. I didn't want people to have un-sync'ed video.
AvsP--> Yeah, I thought about it to, but then I also thought of the "auto-script" feature built into MeGUI. (which I'll also write about for the lazy people)
For AvsP I'd have to write a small guide: Which I probably will; it's amazing how long it takes to type everything out. I've already praised the author on how great the software is (I only discovered it recently...)
MeGUI Preview Window--> On my PC, it doesn't let me playback in realtime, but VirtualDub does. I have fast PC too (Core2Duo), and I find that it's easier to look at video when it plays at the right framerate than say... 0.8x realtime... another point for AvsP in conjunction with Media Player Classic
The setting is for *maximum* b frames, so if x264 can get higher quality by not using the extra bframes, it will not use more. It just allows x264 more flexibility, and hence higher quality, when determining frame types.
Oops :p...
But I'll DEFINATELY consider that hosting solution you suggested: www.googlepages.com isn't the best, but with little experience in webpages I made something that was relatively attractive.
So basically:
Make Corrections :thanks:
AvsP intro/mini-guide
Add page about more "advanced" filters w/author's permission (MCBob, FFTDenoiser, etc.)
Anything else?
--> More comprehensive Interlacing page: but it's a bitc* to write.... between Telecide, LeakKernelDeint, TDeint, MCBob, MVBob.... and how to see which is best for your source... that alone deserves a guide.
@ smok3: I find the command line daunting, especially when you're not 100% sure what your doing.... plus the tooltips in megui are good. That being said, I don't think my site would be complete without it.
Great, thanks for the feedback... I've been on doom9 since 2005, reading and learning, but i'm still very much a newb. I just jumped on to the x264 wagon after getting a hold on XviD...
check
4th March 2007, 14:48
o you don't need any permission to write guides on filters, although they'll probably appreciate if you point them towards the finished product so they can error check it. You should also read the current documentation on the filters and try to use that as much as possible to save yourself some work.
o avsp should be reasonably simple just to pick up and play, it has many advanced features, but none are needed for what you require of it. The open/save/load functionality works as per normal and readers should already know that.
o neuron2 said he was writing a guide on detecting interlacing in video streams. I was in the middle of writing a guide too, but it's on hold until I see what he produces (it's a little overdue though from his eta, I might prod him soon about it).
o for x264 commandlines, why not suggest sharktooth's profiles?
Dr.Khron
4th March 2007, 14:53
Wow, nice work! Thank you.
I did some professional technical writing when I was a consultant... Just tell me where to start, and I'll do some word smithing for you.
EDIT:
Proofreading looks pretty damn good already. A few dropped words, some run-on sentences (which can be hard to avoid in technical writing). Excellent use of punctuation; hail fellow semicolon user! :)
Thanks for your explanation of CABAC. I haven't fooled around with that yet, I think I'll go read up on that. My aging living room PC has been choking on my 264 encodes, so maybe that will help.
Appu
4th March 2007, 17:02
Had a quick look at your website. Nice work..
Minor quibbles though..
You have mentioned that too many I frames may reduce the quality. ( "However, too many may degrade overall video quality:") I don't think this is correct. Increasing the number of I frames will only increase the quality, but at the cost of a higher bitrate ( hence bigger output files ) because I frame is the least compressed of the three ( I, P, B).
Another statement.
"but if you're looking for a "lossless" encode (extremely high bitrates), it's perfectly safe to set it to 0".
The encoding is always lossy whether you use B frame or not.
steve77
4th March 2007, 17:46
@Appu: I understand that x264 by it's very nature is a lossy codec, but many people use Xvid and x264 to create HIGH quality backups... that's the reason I put quotation marks. But after reading through the forums the B-Frames are of good quality and shouldn't necessarily be omitted when doing high bitrate backups
And the comment about I frames is that they are the very best quality frames, but if you use a bunch of them, for a fixed bitrate there will be less data to go around for the B and P frames... at least that's my interpretation, but again, a guru could straighten me out.
@Dr.Khron: Thanks for the offer... I won't bother you until I get the content down pat though
@Check:I'll let neuron2 explain his guide: he is far more knowledgeable than I am. I'll put up a link when he's finished it.
LoRd_MuldeR
4th March 2007, 18:03
Hi. I noticed two things on the "6-Encoding Our Video" page:
1) You say that you prefer Exaustive as M.E Algorithm, because you want maximum quality. All docs I read before say that Exaustive does *not* give any better results than Uneven Multi Hexagon. It's only slower, but no better. AFAIK Exaustive is only included for completeness.
2) Your description of Trellis - "Preforms various optimizations for speed and efficiency, should always be used" - is very imprecise. Trellis effects the quantization step of the encoding process and it has a huge impact on the encoding speed, especially in mode 2 (~10% slowdown!). Furthermore it should improve the quality, but in fact the opposite might happen. Last but not least the effect of Trellis is unpredictable for CQ modes...
steve77
4th March 2007, 18:26
Hi. I noticed two things on the "6-Encoding Our Video" page:
1) You say that you prefer Exaustive as M.E Algorithm, because you want maximum quality. All docs I read before say that Exaustive does *not* give any better results than Uneven Multi Hexagon. It's only slower, but no better. AFAIK Exaustive is only included for completeness.
2) Your description of Trellis - "Preforms various optimizations for speed and efficiency, should always be used" - is very imprecise. Trellis effects the quantization step of the encoding process and it has a huge impact on the encoding speed, especially in mode 2 (~10% slowdown!). Furthermore it should improve the quality, but in fact the opposite might happen. Last but not least the effect of Trellis is unpredictable for CQ modes...
1) Even from a PSNR point of view?
2) Thanks! I think I might reference the following:
http://forum.doom9.org/showthread.php?t=102339
LoRd_MuldeR
4th March 2007, 18:36
1) Even from a PSNR point of view?
This is from DeathTheSheep's guide. I read similar advice in other guides too.
I suggest use of the “Hexagonal search” (searches horizontally, vertically, and diagonally) for slower machines or people short on time, but otherwise the “Uneven Multi-Hexagon” (searches via multiple hexagonal bursts) search is superior, providing better quality due to its more accurate search algorithm, despite an increase in encoding time. NEVER even think about using “Exhaustive Search” (pixel-by-pixel search, no “estimation” at all); it's not much better than “Uneven Multi-Hexagon” and it decreases encoding speed so drastically you'd be lucky if your encode finished in a week. I don't even know why it's offered as an option.
steve77
4th March 2007, 19:18
This is from DeathTheSheep's guide. I read similar advice in other guides too.
Excellent! I'll make the adjustments. I've learnt something too! (I ALWAYS use RDO, and my encodes DO take time)... but I've always been satisfied with the quality, so never bothered wondering if there were faster ways.
I'll go and try to find the reference, so I may incorporate it into the website.
EDIT: I was re-reading the 8th page (Muxing) and I made a confused suggestion about which player to use for playback. As I understand it, FFDShow (CCCP is easy, which is why I suggeest it) is much faster than letting VLC do the decoding.
HOWEVER, I played back the file using CCCP and the colors were off... any pointers?
LoRd_MuldeR
4th March 2007, 19:53
CCCP use an outdated version of ffdshow!
The ffdshow developmentis going on at ffdshow-tryouts (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416), so you should get an up-to-date version there and try again. Also check all the setting. If there are still problems, report them. You can also try MPlayer (http://tinyurl.com/2scmog) instead of VLC Player.
steve77
4th March 2007, 22:12
CCCP use an outdated version of ffdshow!
The ffdshow developmentis going on at ffdshow-tryouts (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416), so you should get an up-to-date version there and try again. Also check all the setting. If there are still problems, report them. You can also try MPlayer (http://tinyurl.com/2scmog) instead of VLC Player.
Thanks again, will try :cool:
check
5th March 2007, 02:44
no, we don't use an outdated version of ffdshow :) The issue is probably the overlay colour controls in the control panel for your nvidia card. Set them back to normal settings from whatever crazy defaults your particular driver version uses and it should be fine.
steve77
5th March 2007, 02:58
no, we don't use an outdated version of ffdshow :) The issue is probably the overlay colour controls in the control panel for your nvidia card. Set them back to normal settings from whatever crazy defaults your particular driver version uses and it should be fine.
Oops, I went and deleted CCCP from website... but it's not the overlay controls on the NVidia; I calibrated it with a THX test disc. I'll put CCCP back, as it's really more user friendly.
check
5th March 2007, 03:28
The best way to check is not with a THX test disc, but by double checking the settings I mentioned yourself. I have no idea whether or not the THX disc uses overlay, but unless it does, it will not be affected by the same problem ffdshow currently is. If you do find your overlay settings are at default, open cccp settings and check 'reset all settings' on the second page.
Anyway, more points:
o Why do you bother demuxing the audio to wav in dgindex? If you output the ac3, it will need less disc space and you can still load it into megui.
o mod32 is not neccessary, only mod16 is.
o personally, I prefer spline32resize() to lancz4 for downsizing
o using turbo for the 2pass is probably a good idea
o CABAC is basically an algorythm
o link to doom9 on page 6 includes a session argument
o It's Media Player Classic, not Windows Media Player Classic
smok3
5th March 2007, 09:18
unrelated: is there still a problem playing back mp4 files (muxed with mp4box) that are few gigs in size?
steve77
5th March 2007, 15:40
The best way to check is not with a THX test disc, but by double checking the settings I mentioned yourself. I have no idea whether or not the THX disc uses overlay, but unless it does, it will not be affected by the same problem ffdshow currently is. If you do find your overlay settings are at default, open cccp settings and check 'reset all settings' on the second page.
Anyway, more points:
o Why do you bother demuxing the audio to wav in dgindex? If you output the ac3, it will need less disc space and you can still load it into megui.
o mod32 is not neccessary, only mod16 is.
o personally, I prefer spline32resize() to lancz4 for downsizing
o using turbo for the 2pass is probably a good idea
o CABAC is basically an algorythm
o link to doom9 on page 6 includes a session argument
o It's Media Player Classic, not Windows Media Player Classic
Well the THX disc plays back in your Media Player software, in my case, VideoLan.... I have an Nvidia card, so I went into control panel-->Nvidia Control pannel-->video+television-->adjust video color settings... as it turn out everything is at default levels ( I though I had changed them, but guess not)
and I 've made the changes you suggested. However, what is the cost of using turbo on the 2nd pass? The reason I output to WAV is I tried to use the .ac3 stream once on a DVD of mine but sure enough there was a delay (66ms). But no matter how I tried to get it to work in the muxer, it would never sync.... I don't want to go recommend something that I can't get to work (though it may be my own ignorance)
For the record, I did try putting 66ms in the Muxer, -66, checkmark "-" -66 and checkmark "-" 66... everything gave out of sync audio/video.... but I"ll try one out today, was probably a fluke.
check
5th March 2007, 15:46
the muxing issue may well be an issue with the mp4 muxer. I use the standalone mkv muxer mkgmerge anyway, so I can't help with that.
Btw, VLC doesn't use ffdshow, any other CCCP component, or overlay. If you want to decoding with ffdshow and so on, use one of the included players (zoomplayer/mpc) or another non borked directshow player (WiMP, etc)
steve77
5th March 2007, 16:36
I see...
For the purpose of my guide I'll recommend VLC, because it's easy.... last thing I want is people fidleing with graphics card parameters to get things working.
I'm going to add a page of commonly used 3rd party filters soon... I was thinking:
MCBob()
MVBob()
TDeint()
DegrainMedian()
FFTDenoiser()
SangNom()
SeeSaw() --> I love this filter.
...
Any others that are frequently useful? Then I have to track down the various dependencies for each filter, and give some instructions on where to put the DLLs, Importing Scripts, etc.
check
5th March 2007, 23:23
have you checked out the avisynth wiki? It might be better to do your work there and link to it.
steve77
6th March 2007, 00:45
have you checked out the avisynth wiki? It might be better to do your work there and link to it.
I don't follow... :confused:
check
6th March 2007, 10:07
Here: http://avisynth.org/mediawiki/LimitedSharpen
smok3
6th March 2007, 10:12
For the purpose of my guide I'll recommend VLC, because it's easy....
mpui is easy to use as well;
http://mpui.sourceforge.net/ - official
http://mulder.dummwiedeutsch.de/home/?page=projects#mplayer - lord mulder's distro
Another thing; you could mention that mac/linux (and windows as well) users can choose to encode via mencoder as well (which basically saves you from avisynth/virtualdubX dependancy).
And about cli encoding, here is my old guide which focuses on qt compatibility:
http://somestuff.org/x264_qt/h264_in_quicktime7.html
(it would need some testing, some conversion to proper english and similar, you are free to grab it if you think it fits someplace.)
theinv
9th March 2007, 19:25
Hi steve77,
Since you like the Seesaw() filter, can you help me with this?
http://forum.doom9.org/showthread.php?t=123224
Thanks!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.