Log in

View Full Version : Skipping in video


Sagekilla
11th August 2007, 05:09
I've been having a bit of a problem with some "skipping" in my video.. I checked the stream and message info window under VLC to see if it might be dropping frames or something, but lo and behold.. It's not.

There's a very small sample here (http://skdotnet.sytes.net:45312/skipping.264) if anyone ones to try taking a look to see if they get it too, but I see it quite a lot. The only differences between the sample I put up and the actual encode is I used --crf 23 for the sample to help cut file size down. These were the settings I used:

--crf 19 --ref 4 --bframes 16 --b-pyramid --weightb --b-rdo --bime --direct auto --filter -3:0 --analyse all --8x8dct --no-fast-pskip --subme 6 --me umh --trellis 0 --no-ssim --no-psnr --mixed-refs --progress --threads auto --thread-input --aq-strength 0.5 --aq-sensitivity 11 --cqm "H:\Matrices\prestige.cfg"


I -THINK- it may be the bframes at 16, but I didn't encounter any stuttering in another video I encoded (Battlestar Galactica, first episode) using the same settings. Can anyone give me a hint as to what may be causing this?

Sagekilla
11th August 2007, 05:16
While I'm here with my issue, I'd also like to ask how much of a difference in SSIM is deemed to be significant.

Dark Shikari
11th August 2007, 05:22
1. What speed is your computer, and what decoder are you using?

2. What SSIM difference is significant? Depends on the bitrate; in terms of visual quality, at the higher bitrates you're using, the most noticable changes are the reduction of blocking in flat areas (adaptive quantization), which actually worsens overall SSIM but at high bitrates will improve visual quality, because the human eye notices the nasty blocking in the background far more than the detail lost everywhere else due to the bits being moved to the flat areas.

Also note that when using CRF improving "quality" will usually result in a bitrate drop for the same quality, though some settings boost quality without affecting bitrate much.

Sagekilla
11th August 2007, 05:25
It's an Opteron 170 (2 GHz, Dual core) and I'm using VLC media player. The Info window it has says there's no dropping in frames.

Also, did you take a look at the video to see if it skipped for you? Here it is again if you can't find it in my jumbled mess of a post up there. (http://skdotnet.sytes.net:45312/skipping.264)

Sagekilla
11th August 2007, 05:28
Another quick question.. What's the difference (if any) between --analyse all and --partitions all? I saw --partitions when using --help but I don't remember where I picked up --analyse all from. I kind of figured it was the same as --partitions all, but I'm not really 100% sure.

akupenguin
11th August 2007, 05:29
--analyse was renamed to --partitions, to make it more descriptive of what it does.

mitsubishi
11th August 2007, 21:16
They're supposed to be skipping, it's a folk dance :p

VLC's H.264 decoding is single threaded, so you can forget about one of your cores. But that doesn't seem to be the problem.

In VLC I get skips at the same points every time, in MPC (coreAVC) I do not. After muxing into mp4 however the skips are gone in VLC, so the decoding maybe isn't the problem, but the parsing of the raw file.

Sagekilla
12th August 2007, 06:37
They're supposed to be skipping, it's a folk dance :p

VLC's H.264 decoding is single threaded, so you can forget about one of your cores. But that doesn't seem to be the problem.

In VLC I get skips at the same points every time, in MPC (coreAVC) I do not. After muxing into mp4 however the skips are gone in VLC, so the decoding maybe isn't the problem, but the parsing of the raw file.

It seems to be that way.. in the mkv I made I encounter no skipping whatsoever. Actually, that was a bit inaccurate on my part. It's actually more like stuttering and not skipping in the video. But like I said, it seems to go away once I mux the video into my mkv container.

End of that problem!

foxyshadis
12th August 2007, 07:55
Just b-frames getting played in the wrong order, I suppose. (Since b-frames aren't coded in the same order as they're played.)