early parts of video is bad but later parts good

[MKVCrazy]

Hi, I am sorry if this kind of problem already existed and posted as I didn't know how to describe it. I have made a lot of sample conversions and I can tell if something's wrong with the quality or not, even in fast motions. So I'll try my best to explain it. I am trying to convert a TV capture into a portable device format to be played on PSP, iPod/Touch or iPhone. I've made everything worked out pretty well until I noticed there are slightly bad quality in the early part of the video and then the quality gets "a lot" better in later parts of the video. That's something that doesn't fit in my head, I need to fix it but I don't know what may have caused that problem. Here are two screenshots comparison of the early part and later part.

This is the early part of video (lasted about 30 seconds to 1 min or 2 then quality gets better)

http://i38.tinypic.com/2n21ro9.jpg

This is the later part of video

http://i37.tinypic.com/255q78y.jpg

I hope someone can give me suggestion on what to search for at least. :rolleyes:

Thank you,
MKVCrazy

[Dark Shikari]

x264 encoding settings? We're not psychic here.

Or is this the DivX encoder (given the DivX logo on your first image)?

[MKVCrazy]

x264 encoding settings? We're not psychic here.

Or is this the DivX encoder (given the DivX logo on your first image)?

Sorry about that, Lol. No DivX is already there. Nothing to do with that.

http://paste2.org/p/464717

I tried to paste the settings here but vBulletin's CODE BBCode isn't wrapping it.

[Dark Shikari]

brdo=0How about we start by updating to an x264 that is less than 2 years old? :p

[MKVCrazy]

Lol, I didn't realize my x264 is over 2 years old. Well I have a few questions then, currently I'm not using MeGUI and using one of the old versions of XviD4PSP (don't want the latest one). Now the author left his app to another guy and he doesn't seem to know how to make a good and stable app like the original author, no offense. I tried his latest unofficial app and it kept on crashing but I fixed it then again I couldn't get the settings for all PSP, iPod/Touch and iPhone. Even the default PSP format settings won't play on my PSP nor iPhone nor iPod/Touch. So I am guessing he's done yet with the stuff. By looking at what you've pointed me out "brdo=0" is that some setting that you control using the commandline? or I can do that in XviD4PSP? Would I be fine by just replace the x264.exe file with the new on in the install dir? Well I am sure nothing will happen if I just replace the file then I won't know what are the benefit of replacing it so I had to ask. What do think I should do?

[Dark Shikari]

Lol, I didn't realize my x264 is over 2 years old. Well I have a few questions then, currently I'm not using MeGUI and using one of the old versions of XviD4PSP (don't want the latest one). Now the author left his app to another guy and he doesn't seem to know how to make a good and stable app like the original author, no offense. I tried his latest unofficial app and it kept on crashing but I fixed it then again I couldn't get the settings for all PSP, iPod/Touch and iPhone. Even the default PSP format settings won't play on my PSP nor iPhone nor iPod/Touch. So I am guessing he's done yet with the stuff. By looking at what you've pointed me out "brdo=0" is that some setting that you control using the commandline? or I can do that in XviD4PSP? Would I be fine by just replace the x264.exe file with the new on in the install dir? Well I am sure nothing will happen if I just replace the file then I won't know what are the benefit of replacing it so I had to ask. What do think I should do?Update to a GUI that is still maintained or just use x264 directly.

[MKVCrazy]

I tried turning on the brdo but I'm still see similar images :(. I'll try updating my x264 file and try again another time. Thanks a lot for your advice, Dark Shikari.

Thank you,
MKVCrazy

[Dark Shikari]

I tried turning on the brdoWhoever told you to do that? I was just using the existence of that option as proof that you had an ancient, stone-age x264.

[Shevach]

Hi all

I experienced the same problem on other H.264 encoders but I think the problem is common for all encoders.

The problem is related to Rate Control. Initial settings of Rate Control is not always fit to video content. As usual the setting of Rate Control includes expected bit-rate and initial QP values for I, P and B pictures.
If intitial QPs values are set much higher than needed for the given video content then first pictures of video stream should have serious distortions due to coarse quantization. Of course after some time (or some run of pictures) Rate Control inevitable will fit itself to the video content and quality will be improved.
I resolved this issue by individual setting of intial QPs for each stream.

[Dark Shikari]

Hi all

I experienced the same problem on other H.264 encoders but I think the problem is common for all encoders.

The problem is related to Rate Control. Initial settings of Rate Control is not always fit to video content. As usual the setting of Rate Control includes expected bit-rate and initial QP values for I, P and B pictures.
If intitial QPs values are set much higher than needed for the given video content then first pictures of video stream should have serious distortions due to coarse quantization. Of course after some time (or some run of pictures) Rate Control inevitable will fit itself to the video content and quality will be improved.
I resolved this issue by individual setting of intial QPs for each stream.This comment is only relevant to 1-pass ABR mode, which really nobody should be using...

[Rumbah]

You could try Ripbot264. It's pretty easy to use.
Just select the proper profile and press the properties button, there you can select to resize to PSP dimensions. Select a bitrate or a CRF value, that should be all to give you a good encode.

[G_M_C]

Hmmm, we might want to get a sticky up here in this part of the forum about posting X264 bugs. Lets say that you can oly post bugs if you have tried one of the (most) recent builds available trough the "current patches thread". It might help stoppig the many bug threads i've seen that post bugs in (very) old builds, that sometimes have allready been resolved long ago. Might save the developers some time (that then can be spent developing new features ;) ).

[Chengbin]

Hmmm, we might want to get a sticky up here in this part of the forum about posting X264 bugs. Lets say that you can oly post bugs if you have tried one of the (most) recent builds available trough the "current patches thread". It might help resolving the many bug threads i've seen that post bugs in (very) old builds, that sometimes have allready been resolved long ago. Might save the developers some time (that then can be spent developing new features ;) ).

+1

LOL at the last sentence!

[G_M_C]

+1

LOL at the last sentence!

:D

But if you think about it, it's also true :cool:

[Chengbin]

:D

But if you think about it, it's also true :cool:

That's the funny thing!

[dstln]

Honestly it just looks to me that it's a fairly poor hdtv capture. The first scene is heavy motion that the original encoder/broadcast couldn't handle well under the circumstances. The second is a near-still image that works fine. That first image is still terribly bad though. What exactly is this? A hdtv capture that was reencoded in divx that you're working with?

[juGGaKNot]

the divx logo is there because of the decoder, same here for h264 video ( at the start ).

[MKVCrazy]

Hi all

I experienced the same problem on other H.264 encoders but I think the problem is common for all encoders.

The problem is related to Rate Control. Initial settings of Rate Control is not always fit to video content. As usual the setting of Rate Control includes expected bit-rate and initial QP values for I, P and B pictures.
If intitial QPs values are set much higher than needed for the given video content then first pictures of video stream should have serious distortions due to coarse quantization. Of course after some time (or some run of pictures) Rate Control inevitable will fit itself to the video content and quality will be improved.
I resolved this issue by individual setting of intial QPs for each stream.
Yes, that may be my problem mate. Could you tell me what's QP in the settings format? like brdo=0 as visible in MediaInfo or something. My settings don't just say "QP" :\

Could you see my settings, there some about 4 qp settings.

http://i37.tinypic.com/28w00nm.jpg

Even default 1-Pass ABR profiles in MeGUI have those values, 10-51-4.
This comment is only relevant to 1-pass ABR mode, which really nobody should be using...
I am using 1-pass ABR mode, I can't wait 2 pass since I'm getting the same quality.
Honestly it just looks to me that it's a fairly poor hdtv capture. The first scene is heavy motion that the original encoder/broadcast couldn't handle well under the circumstances. The second is a near-still image that works fine. That first image is still terribly bad though. What exactly is this? A hdtv capture that was reencoded in divx that you're working with?
You're right the HDTV capture is poor and not as good as the originally aired quality but it didn't make those "distortions" at the beginning of the re-encoded video I made.

[Dark Shikari]

I am using 1-pass ABR mode, I can't wait 2 pass since I'm getting the same quality.If you're using 1-pass, use CRF, not ABR.

[MKVCrazy]

If you're using 1-pass, use CRF, not ABR.

Won't it give me some random "huge" file size? I am looking for quality and size as portable devices have very little space compared to computers.

[Chengbin]

Won't it give me some random "huge" file size? I am looking for quality and size as portable devices have very little space compared to computers.

That's CQ mode.

[nm]

Won't it give me some random "huge" file size?
No, it's completely adjustable. It will give somewhat different bitrates for different sources, but never huge files at sane values and sources such as yours.

I am looking for quality and size as portable devices have very little space compared to computers.
Then CRF with VBV is definitely the way to go.

[Dark Shikari]

Won't it give me some random "huge" file size?No, that'll give you a random "small" file size, if you pick a reasonable quality value.

[MKVCrazy]

That's CQ mode.

Oh, wow I just rechecked the two and I didn't know there were two "CQ's" but anyway I meant "Constant Quantizer" as I didn't know about "Constant Quality". So I did a few tests with little higher values than default, I am getting near my target bitrate I used in ABR mode and I'm getting good image.

So does a value of CRF means a constant bitrate? Let' say CRF of 22 is equal to a specific bitrate? or it changes the size depending the source quality?

Let's say I have one video from a 1280x720 (720p) HDTV capture encoded into 480x272 at same CRF

then I made another one from a 720x480 HDTV capture and encoded into 480x272 at same CRF as above.

Will the first one have larger file size as the source's quality is better? I have always been so confused about this. :confused:

[nm]

In both cases the quality at 480x272 can be excellent. Anyway, bitrate differences are due to differences in compressibility. For example, if you have a video that is mostly stationary and smooth, perhaps showing someone talking, it will require much less bitrate to encode than a grainy action movie for a given quality level.

[MKVCrazy]

In both cases the quality at 480x272 can be excellent. Anyway, bitrate differences are due to differences in compressibility. For example, if you have a video that is mostly stationary and smooth, perhaps showing someone talking, it will require much less bitrate to encode than a grainy action movie for a given quality level.

I tested another 3 samples at different scenes. Talking scenes go as high as 600 kbps! That's really huge for portable devices. I am planning to not pass over 384 kbps :\

But I found something good about CRF. It fixed my problem that distortion happening at begining of video. Strange.

[Dark Shikari]

I tested another 3 samples at different scenes. Talking scenes go as high as 600 kbps! That's really huge for portable devices. I am planning to not pass over 384 kbps :\If you need to restrict the local bitrate, use VBV. It works fine in CRF mode.

[nm]

I tested another 3 samples at different scenes. Talking scenes go as high as 600 kbps! That's really huge for portable devices. I am planning to not pass over 384 kbps :\
I wouldn't worry about the bitrates of single scenes but complete encodings. Remember to use VBV to restrict the peak bitrates to something that your portable device can handle and let x264 handle the bitrate distribution.

But I found something good about CRF. It fixed my problem that distortion happening at begining of video. Strange.
No it's not. Rate control -related distortions can be expected with 1-pass ABR, as discussed above. Overall, CRF gives you higher quality than a given 1-pass ABR encode at the same average bitrate.

[dstln]

As people have said, crf is constant quality, modified by the quality amount you give it (higher crf values mean less overall quality and lower bitrates, lower crf values mean higher overall quality and higher bitrates). It is not related to any constant bitrate, although similar crf values MAY produce similar bitrates for similar sources. If your device has localized bitrate limits, use vbv to put hard caps on peaks (as people have said). If you're encoding to a certain overall bitrate/filesize, use 2-pass.

[Rumbah]

If the file size is too big for you just increase the CRF value to 23 or 24 or higher till you hit the bitrate you like for that source. Even 30 looks good for its size, especially if you don't zoom in (what you are not planning to do as you resize to the native device resolution).

[G_M_C]

Hmmm, we might want to get a sticky up here in this part of the forum about posting X264 bugs. Lets say that you can oly post bugs if you have tried one of the (most) recent builds available trough the "current patches thread". It might help stoppig the many bug threads i've seen that post bugs in (very) old builds, that sometimes have allready been resolved long ago. Might save the developers some time (that then can be spent developing new features ;) ).

I want to re-make this point.

Because this same CRF-question like above has been made numerous times before. I has been asked/explained and clarified many many times. People should learn to use the search. It's not for naught that there is a special smiley for cases like that.

Even google knows what CRF means .... Search with google for "x264 what is CRF" (http://www.google.nl/search?hl=nl&q=x264+what+is+CRF&btnG=Google+zoeken&meta=)

So; :search:

[MKVCrazy]

I've got another question. I re-tested the with another clip using the same settings as the one I used to and get distorted images and there are differences between the two. I know bitrates/length/frames/size/resolution are suppose to be different but there are differences in their "x264 settings" when viewed in MediaInfo.

The one with distorted images has the "x264 settings" written two times but the other one is normal and only written once. This is what I meant:

http://i36.tinypic.com/289zjtx.jpg

Can having same x264 settings info twice in the header cause distorted images at beginning? I can't get it to show the info only once. I think it's more like because of the source file :\

[me7]

Why are you still testing your old version? x264 has improved a lot in the past months/years and chances are that you are complaining about a behaviour or maybe even a bug that was changed/fixed ages ago.

Get the latest version, run some tests and do NOT use 1-pass-ABR.

[G_M_C]

Why are you still testing your old version? x264 has improved a lot in the past months/years and chances are that you are complaining about a behaviour or maybe even a bug that was changed/fixed ages ago.

Get the latest version, run some tests and do NOT use 1-pass-ABR.

+1

MKVCrazy have you actually read this thread? They are all reply's to your initial question you know. What Me7 says, not using ABR and upgrading using VBV settings, it is all posted here :rolleyes:

Follow these hints, you'll get better results.

[MKVCrazy]

+1

MKVCrazy have you actually read this thread? They are all reply's to your initial question you know. What Me7 says, not using ABR and upgrading using VBV settings, it is all posted here :rolleyes:

Follow these hints, you'll get better results.

I actually did read them. The problem is most of people who replied here are pretty good with the facts and stuff but I am having a problem with more like an unusual case, can't fix it by doing what you guys say as my knowledge to encoding is limited and can't provide all the info needed. The reason why I still wanted to use ABR was because, when I tried CRF and limit VBV at 302 (I prefer to have bitrates around 300kbps), some scenes are pretty messed up and I am guessing the encoder considered those scenes don't need much bitrates. I like the idea how it decides where most bitrates are required but with low bitrate like 300kbps, the encoder might have given those scenes around 230kbps or even less! (telling by the looks of it) that's way too low again :\. So I thought it could have been fine if all scenes were around 299-302 kbps.

So I took your suggestions about upgrading the tools, I downloaded the latest RipBot. And I am now using CRF mode to convert. It's giving me over 65fps but I can see how it gives bitrates better than the previous one. Bitrates are around 287kbps but I am amazed, the pictures still look great and RipBot is a lot more auto.

:thanks: for your replies. I guess it was just time to step up to the next generations. And I "really" appreciated them :).

[nm]

The reason why I still wanted to use ABR was because, when I tried CRF and limit VBV at 302 (I prefer to have bitrates around 300kbps), some scenes are pretty messed up and I am guessing the encoder considered those scenes don't need much bitrates.
I'd guess it was hitting your 302 kbps ceiling at those points. The encoder would use more bits but you are restricting it way too much. VBV maxrate should be set about twice as high as the average bitrate that you're targeting, or preferably, according to the device level restrictions.

So I thought it could have been fine if all scenes were around 299-302 kbps.
Nope, it would be about the same as your 300 kbps VBV -constrained encode. What you're describing here is constant bitrate (CBR) and even 1-pass ABR (without VBV restrictions) is better than that, as you seem to have noticed. But that's because ABR doesn't restrict the maximum bitrate like you tried to do with CRF & VBV.

So I took your suggestions about upgrading the tools, I downloaded the latest RipBot. And I am now using CRF mode to convert. It's giving me over 65fps but I can see how it gives bitrates better than the previous one. Bitrates are around 287kbps but I am amazed, the pictures still look great and RipBot is a lot more auto.
That's Good :)

[Forteen88]

http://i36.tinypic.com/289zjtx.jpgWith bitrate-starved encodes (as you do), decimate=0
isn't good. bframes 0 sucks (bframes 3 is normal), although if it's a must for hardware-compatibility I understand it.
BTW, as others already said: update your x264! I update my x264 every time I prepare a new encode.

[me7]

BTW, as others already said: update your x264! I update my x264 every time I prepare a new encode.

if you had read his last post (two posts above yours), you'd know that he has updated x264 and the issues are gone. But hey, at least you tried to be helpful :)

[Forteen88]

if you had read his last post (two posts above yours), you'd know that he has updated x264 and the issues are gone. But hey, at least you tried to be helpful :)I just confirmed the importance of updating x264 (as new version pop up every ~week). Did you mention: "update x264 every time you prepare a new encode." as I basically did? No, I didn't think so :)