I honestly have no idea how to check that. If I had to guess, I'd be using Haali's Media Splitter for that as well, but I have no idea if that's a dual-use codec or not. If not that, then I guess the default MPEG Audio filter. (I'm not as experieced with fiddling with the various codecs I have as I may seem. XD)
It's easy to check in MPC/MPC-HC. While playing a file, right click the screen and goto filters. It will list all filters in use.
Media Player Classic's internal MP4 filter is disabled, yes. And I do indeed have Haali's Media Splitter demuxing (??? That is such a weird word...) MP4s. I'm watching the recent encoding of Bobby's World by Velitha at this moment, in fact, and it's perfectly in synch. Your encodes, though, I've never been able to watch in-synch without enabling the time adjust function. If you remember correctly, I had this problem before, as well. But I wouldn't worry about it since I can just shift the audio to match the video. I've gotten quite used to doing that, actually.
Now, one thing I didn't try was disabling the built-in audio switcher filter, which is nice to have on since I can actually hear things since it plays nice and loud (as well as shift the audio around, swap speakers, etc.). I'll give that a try next time I watch one of your encodes and see if it helps.
Edit: No difference after disabling the interal audio switcher. Watching your encode of Tomba in Media Player Classic still resulted in the video being 500ms out of synch with the audio. However, watching your encode in VLC media player, it works fine with no fiddling whatsoever. Not sure what this means.
Maybe the problem is on the audio front. What are you using to decode AAC, for that matter, what are you using to decode H.264?
Ugh, I must have selective vision or whatever..I see it popping up with the normal material now. So much for that :/ ...if only there was a proper decoder so I could verify for sure..
*just realizes FFVI had 444P output*..*does a quick encode to rule out ffdshow's faulty decoding*..bah, x264 downsamples to yv12. Least I know for sure ffdshow was reconverting back to YV12 After all that mess. -_-;
I would be very interested in your conversion method. Even if there were YV24 decoders I would have to go all the way down to q40-45 in order to get the same file size as the 4:2:0 material at q20..and in general it ended up looking worse (compression artifacts). Maybe 2x Resolution is the only real way to go about it..and if I have to use 4:2:0 I'd rather get the colors accurate due to a better dithering method.
Using AviSynth 2.60 Alpha I do the following lines:
ConvertToYV24(chromaresample="point")
ConvertToYV12(chromaresample="lanczos4")
SatoshiLyish wrote:
Well, when I started encoding I got a "4:4:4 Predictive" popup, so I'm assuming it was reading and encoding as YV24 material. Also, where is all the extra space coming from in the file sizes? I somehow doubt its all junk data in there.
Ah, but it always says that even when encoding with YV12 source. I really do think the increase in file size is due to garbage data. Garbage data can be hard to encode =p.
Very interesting. Also, I think I'll have to take back what I said about lossless being pointless since it wasn't true lossless. I've been reading up on the "Encode to Lossless x264" thread, and I didn't realize that it was possible to get lower file sizes than some q>0 encodes (my experience with all other encodes and codecs proved to be otherwise). I guess anything that increases the quality:size ratio is worth it.
Unfortunately that thread, (which was started by me, right?) is a bit outdated now. After finding out out the different ways I could convert to YV12 from RGB32, in which some retains more or less color, I don't think encoding to lossless can be as small as it used to be. Apparently the way I converted to YV12 before was a simple method making it easier to encode at the cost of the colors are not as accurate. The method I now use to convert to YV12 now retains (all subjective of course) more color, but making the file size larger in which I've noticed most of the time it be smaller to just go lossy.
SatoshiLyish wrote:
Also, I HAVE figured out a way to encode 'true' lossless to x264, and all that's required is downloaded the latest AVISynth 2.6.0 beta (or alpha?) and using the following script:
source=ConvertToYV24(ffdshow_source())
return (source)
However, there's currently no decoder that will process the video correctly. What you get is the full luma displaying correctly, with the top left quarter of the chroma displayed on top of it. Strange looking to say the least. The only thing I could see this site using it for is for "future archiving" when yv24 decoding becomes more mainstream/supported.
File sizes are a lot bigger. 4:2:0 q0 is 1.9MB, q1 1.6MB; 4:4:4 q0 6.71MB, q1 8.28MB. LOL, guess that just proved lossless encoding efficiency right there.
I don't think this works. Even if you convert to YV24 in avisynth, x264 auto converts it to YV12 (at least in the newer versions). I think you are getting the errors you see because x264 assumes it's YV12 and encodes as such. I'm not sure though. I'll do some of my own testing.
It is common to see q1 is better than q0 actually. I'm not so surprised by that really since some of the info might be just pure motion in q0, thus saving space.
Well, I wasn't sure whether it ignored the command or not. You can never be too sure with programmer's implementation..But in terms of script efficiency, B frames shouldn't even be mentioned if its a lossless encode.
I was the one who found the bug that lossless mode still had b-frames back in 2008, so I know the fix was to just ignore it. Plus the encoding generally is faster doing lossless than not (because lack of b-frames) which is why Flygon would even do these insane settings. These settings with b-frames would be a lot slower.
SatoshiLyish wrote:
As for master encoding before the final process, I now use FFV1 (Final Fantasy VI anyone? ^^) in RGB32 mode, thanks to the suggestion from sgrunt. That way I know everything is bit perfect before final encode. (although I can't imagine uploading one of those to Youtube, unless it was a 1 minute clip or something ^^;)
Usually I do upload near lossless to YT (YT doesn't support lossless H.264), so what moozooh said is correct. Lossless does have the advantage of having no lossy artifacts also, dispite the color loss =p.
Johannes is right about the whole B frames in lossless mode thing, Flygon. When I loaded the two videos that you mentioned were encoded with the script (Super Mario Land and NES Tetris), in AVIDemux, if you go under Tools, Bitrate Histogram, it'll tell you the # of each of I,P, and B. For Super Mario Land, its 76 I frames and 43296 P frames, with 0 B, and in Tetris, 8 I frames, 3485 P frames, 0 B. Granted, I don't think the graph was perfectly accurate, as I had to rebuild the keyframes to get a more accurate number (possibly due to the lossless compression, which doesn't display right in the player at all), but when I skimmed through the Tetris video, I didn't see any B frames pop up at all. So, for lossless encodes I'm sure you can omit any B frames..it might or might not speed up the encode process.
I'll be experimenting with your script sometime soon...just as soon as I can get my VB AVISynth script hassle free with no memory issues. :/
Edit: I should mention that x264 lossless isn't really lossless, due to the YV12 colorspace. Something else to consider :P
The param there won't hurt it like Johannes found out. x264 just ignores it. Flygon should know very well by now that it isn't really lossless since I've been drilling that into him. XD
This is incorrect. Haali's splittter can demux MP4s and MPEG-TS also. It also can optionally do AVIs if I remember correctly. Just make sure MPC is using Haali's splitter for MP4s by turning off MPC's internal MP4 demuxer.
Heh, interesting! So it's not just me?
Yeah, as far as I can tell, every encode Aktan has ever done has the audio exactly 500ms out of synch with the video! Since I don't have a PS3, I don't know of a way to fix this, but I was able to easily remedy this issue in Media Player Classic by adjusting the audio delay by -500ms. I hope someone else can help you, though.
Now this problem should NOT exist for MPC. Are you using Haali's media splitter to demux MP4s? PS3 demuxer I have no control over, but MPC you have control over. Even if you have Haali's media splitter installed, MPC's internal MP4 demuxer must be unchecked for it to be used.
Aktan, your MP4 desyncs on a PS3 in the same way your MP4 for Rockman L desynced for me; the audio is about a second ahead of the video.
Could you do a basic, no-fancy-size-reducing-gimmicks encode for those of us who watch on PS3s?
Well I'm not a fan of k-lite (I think it messes up the system), but I think all you need to do is update your ffdshow. To me all you need instead of the k-lite crap is the following:
MPC-HC
ffdshow
haali media splitter
ac3filter
Anyway that was a rant really so here is the link to a later version of ffdshow:
http://www.free-codecs.com/download/ffdshow.htm
Default: auto (1.5 * logical processors, rounded up)
Btw, one could ask why have more threads than processors? (With the formula above, even with one single-core processor you would get two threads. With a dual-core you would get 3 threads. But why? What's the point?)
The idea is, AFAIK, that since video encoding is quite I/O-heavy, using more threads than processors actually helps speeding up the process. This is because if there were only as many threads as processors, any thread which is currently doing I/O would have its processor sitting idle (because I/O is so enormously slower than the CPU that the latter has basically nothing to do while it waits for the I/O to finish). Thus if you run 2 threads on one single-core processor, there's a good chance that one of the threads will get this free CPU time for its calculations while the other one is waiting for I/O, hence the CPU will get fully used. The same is true for more processors/cores, naturally. (In fact, with more CPUs and hence more threads the efficiency rate may even be better because it lessens the possibility of the single-core case where both threads are waiting for I/O at the same time.)
The reason for more threads than CPU is due to the fact that there are dependency on certain parts to be encoded first before the thread can finish. Due to these dependency, not all threads would use 100% CPU all the time. Also I think it is off. I could have sworn it was rounded down, not up so that a single core only gets 1 thread.
If you just watched the streaming, that was auto made by archive. I'll be doing another encode with better streaming. The screen tho will be like original DS since I prefer it that way =p.
The video is 100% lossless with a theoretically impossible to beat video stream (Unless you go lossy, which isn't really desirable), smaller than the other posted encodes and has far higher audio quality. You cannot make this smaller without reducing the quality somewhere.
Sorry to bring encoder qualms into this thread but this again is wrong. While it is indeed lossless, the way you resample (assuming you used default mencoder resampler) to YV12 is worse off making it possible to still increase quality at the cost of file size. Take for example the lossless encode I tried with a merange of 1024. The video size is still bigger than yours at 2.29 MB. Being it is lossless, why would mine be bigger? This is because the way I resample the color retains more information than the way you did. My encode would look more colorful (subjective as usual). On the flip side, if I encode with the simplest resampler, I get a file size of 1.47 MB (still merange of 1024).
Just a thought, the majority of Rubik's Cube positions can be solved in 16-19 moves. This movie uses 20 moves, I only know one cube position that requires 20 moves. >_>
As explained in the thread, the game counts only quarter moves, meaning what usually one would count as 1 move for a half turn counts as 2 in this game.
I also took a look. Nice (mostly) sword run. Might be due to me watching this late at night, but just sword only and not aiming for fastest time seems a bit boring after a while. Good job though.