Hello, can somebody tell me please : what are the best settings in ffdshow to encode the best possible HD quality ?
I read the Encoding Guide but i dont know how to use these in ffdshow.
http://imageshack.us/photo/my-images/831/69226100.jpg/
I work with VirtualDub. Is that the best method to make an HD encode ?
Sorry for my bad English.
Hello, can somebody tell me please : what are the best settings in ffdshow to encode the best possible HD quality ?
To get best possible quality, both dumping and encoding must be done right.
For dumping, you need to use codec that is:
* Lossless
* Has RGB or 4:4:4 ITU Rec.709 TV-range colorspace.
The usual ones are (in RGB mode):
* FFV1
* Camstudio codec (this is always RGB).
* Lagarith
* HuffYUV
Avoid h.264 / x264 for dumping because the colorspace that would have to be set (4:4:4 ITU.709 TV/non-full range) is pretty exotic and it might not be possible to set it to use that.
Then on encoding, set rate contol to qp 0 or crf 0, colorspace to ITU.709 TV range (4:2:0 because Youtube does not support 4:4:4). The rest of the settings don't matter for quality (only resulting file size and encoding time).
Sorry, I don't know to set this in ffdshow, as usually the encoding for HD is done using x264 command-line tool with avisynth.
Also, for best possible sound quality, use FLAC for encoding the sound.
I'm repeating that ffdshow (FFV1) sucks in RGB dumping because screws colors up.
Lagarith is okay, but doesn't compress very hard.
Camstudio (Level 9 of GZip algorithm) compresses the most, but takes additional time while dumping.
For YT encodes of regular gameplay vids I dump from emulator with CamStudio codec and then reduce framerate in VirtualDub, compressing with Xvid (best quality settings) and upscaling a frame by 4 with nearest neighbours method.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
@feos
When i dumping with Camstudio Codec the vid is Blue and very low Bitrate ?
Is the Quality also good when i dumping with ffdshow like this ?
http://imageshack.us/photo/my-images/804/43763889.jpg/
I thought that x264 is better than Xvid ?
@Ilari
set rate contol to qp 0 or crf 0 where can i do this ? Is this to control the Bitrate or...? :)
@Ilari
set rate contol to qp 0 or crf 0 where can i do this ? Is this to control the Bitrate or...? :)
Those are rate rate control options (and indeed control the bitrate used), so I presume those are in 'rate control' part.
Don't know, because I have never seen what that tab actually contains.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
For YT encodes of regular gameplay vids I dump from emulator with CamStudio codec and then reduce framerate in VirtualDub, compressing with Xvid (best quality settings) and upscaling a frame by 4 with nearest neighbours method.
That seems like a good way to degrade the quality a lot?
Preferably one shouldn't even upscale.
And compressing with xvid seems like ... a bad idea. x264 will indeed compress a lot better than xvid.
Camstudio is lossless. FFV1 is lossless, Lagarith is lossless.
For YT encodes of regular gameplay vids I dump from emulator with CamStudio codec and then reduce framerate in VirtualDub, compressing with Xvid (best quality settings) and upscaling a frame by 4 with nearest neighbours method.
That seems like a good way to degrade the quality a lot?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I don't really like watching GBA runs in 1/20th of my monitor: http://imgur.com/Mnxme (This claims to be 1x window size, so I'm assuming that's roughly representing the system with no upscaling on my monitor.)
The first post in this thread shows a few different filter options: http://tasvideos.org/forum/viewtopic.php?t=10326 I assume most media players, once enlarged, would perform some sort of point resizing on a non-upscaled video of that small resolution, but as those pictures show, that may or may not be preferable. Semantically, I could say that a viewer's eyes will better interpret the pixels to a smooth image when the video is small as compared to when the video is large and point resized, so maybe some additional smoothing should be implemented through upscaling filters to better approximate an actual enlarged image of what the viewer interprets the small image as.
Assuming everyone is talking about encoding TASes from the emulator, (which I'm not sure was actually 100% implied by the topic creator), There is really no need to preserve the run naturally, as the run can be recreated from the input file at any time.
It's a bit of a matter of preference; one could argue all day about what actually looks better.
I found in ffdshow an AviSynth configuration. When I wrote here my commando lines it works. Can I made on these way my HD encode or is this not a good idea ?
http://imageshack.us/photo/my-images/40/te2z.jpg/
I think it's a bad idea to define the final resolution in such a way. Otherwise, the pixels will get different sizes, for example some pixels get upscaled to 5x5, others get upscaled to 4x4, depending on the position in the original video. Something like this may be better:
PointResize(width()*7,height()*6) #for NTSC NES or SNES
#or
factor=7 # choose this in such a way that height*factor > 1080 and width*factor > 1600 to get "original" option in Youtube (not sure about that)
PointResize(width()*factor,height()*factor) # set pixel aspect ratio accordingly
Preferably one shouldn't even upscale.
Is it a joke?
No, be so kind as to explain to me why it's a joke.
I think upscaling is quite a good idea for Youtube: Which one of these two looks better? Both were encoded with the same codec options... (Well, I used sort of HQx which is non-standard here, about 60% prefer PointResize as far as I know.)
Can someone make an short list of the work steps please ? at first without logo and subtitles. only the Requirement and the using of it.
e.g.
1. dumping with an lossless codec
2. ....and so on
my work steps are :
1. dumping with an lossless codec with RGB32
2. open the video with virtual dub
3. select ffdshow to compress in x264 with some AviSynth settings there
4. save to AVI ...and thats all
I know my steps are not good and thats the reason I wanna know what the right steps are for HD encoding....I read anywhere something about commando lines at x264 ?!?!?! is that the way you all do encoding ?
Can someone explain it please on an easy way for an absolute Newbie?
...
3. select ffdshow to compress in x264 with some AviSynth settings there
4. save to AVI ...and thats all
...
Regardless of everything else, this is something you must not do.
For the compression step, download x264. I tend to use the one at http://x264.fushizen.eu because it has audio features built-in (no need to mux the compressed file later).
If you're going to use avisynth, select the 32-bit version. Otherwise, and if you run a 64-bit OS, choose the 64-bit version.
If you plan not to upload the compressed movie to YouTube, you can choose the 10-bit version. This is likely to be slower than the 8-bit version, but the compression should be greater.
Otherwise choose the 8-bit version.
At the command-line, type
x264 --preset <your_preset> --crf <your_crf> --acodec copy "input" -o "output.mkv"
To get the list of presets, google or type x264 --help. This option controls the speed. The slower, the better compression (avoid ultrafast and placebo). Replace <your_preset> with this value.
Then experiment with the crf value. The lower, the better quality, but the higher file size. So choose what YOU find the best tradeoff between quality and filesize. Default is 23.
"input" is the file to encode.
"output" is the filename of the output (do NOT put .avi at the end).
This should compress your file for you.
There should also be some encoding guide somewhere?
Also, this does not resize the video in any way or form. If you want that, you can add --vf resize:width,height
Ok I downloaded the x264 codec but when I try to use it with cmd there comes a message : x264 error: no input file. Run x264 --help for a list of options
Looks like you forgot the input file.
x264 --preset <your_preset> --crf <your_crf> --acodec copy "<input>" -o "<output>.mkv"
Replace <input> with your input file and <output> with the name you want for the output file.
Then execute that command line.
I told you exactly what to do... it doesn't get simpler than this.
Example:
x264 --preset veryslow --crf 25 --acodec copy "Turtles in time.avi" -o "Turtles in time.mkv"
Also, if you would post your command line and errors, it would be easier to help you.
ffms error: could not create video source
mkv error: unsupportet audio codec
mkv error: failed to create audio track
x264 error: cant set outfile param
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
