How to encode soccer game in proper way?

[Romario]

So, I recorded from my analog TV card one soccer (football) game before two months. In MPEG2 format, of course, 720x576, 25 FPS, PAL.

I have one question: what is important here, how can I proper encode that soccer game? I want high or very high quality.

I use x264 codec, of course.


Yesterday I tried to encode that video in x264 codec, two pass, 576x432, bitrate was 2400 kbps. But, I don't understand why, on such high bitrate, encoded file was so bad? MPEG2 original is much better.


BTW, source has little noise.

[Mug Funky]

footage is interlaced. when you resize an interlaced image without due care and attention, it'll come out with blurred fields whenever something moves. i'm sure you saw that.

x264 supports interlace, so i'd just enable that and not bother about resizing. make sure you've got an x264 build that does it right (sharktooth's are in the sticky at the top of this forum, but no doubt you already know that).

either that or you could smart-bob the source, resize down and encode that in x264. in some ways it's a better option, in other ways it's worse... just a matter of preference.

[DarkZell666]

Do note that football contains many fast camera pans, and that those literally SUCK the bitrate by thousands of kbps (along with constant slow camera pans all along, which hogs some bitrate a bit more ^^). I'm personally not surprised that 2500kbps wasn't enough.

Encode using crf 18 or 20 and you'll see that the bitrate will rather be around 4000kbps (if not more, I'm trying not to scare you off there :p)


(+1 for the deinterlacing hints)

[Romario]

OK, thanks guys. But, I am pretty sure that my MPEG2 source is progressive, not interlaced. Because I choose progressive from TV card program.

OK, I will try with constant quality. So, you guys tell me that resizing isn't a good idea for soccer game?

What about deblocking, can I safely turn off this setting, or, can I set both values to -2, -2 or -3, -3? What is your thoughts about deblocking in this particular case?

[Chainmax]

Do note that football contains many fast camera pans, and that those literally SUCK the bitrate by thousands of kbps (along with constant slow camera pans all along, which hogs some bitrate a bit more ^^). I'm personally not surprised that 2500kbps wasn't enough.

Encode using crf 18 or 20 and you'll see that the bitrate will rather be around 4000kbps (if not more, I'm trying not to scare you off there :p)


(+1 for the deinterlacing hints)

Deinterlacing is probably not a good idea because of the fast camera pans you mention. Your advice to encode using crf and get an idea what the bitrate should be is a great idea though, good catch http://smilies.vidahost.com/otn/wink/thumb.gif.


Romario: deblocking should only be used if the source footage has blocking. If you're referring to x264's deblocker, then it should definitely be used, especially on this case. The HQ-Insane profile sets a deblocking of -2,-1, but since this is such a demanding footage, I'd say something like 0,0 would probably be a better idea. In any case, I'd like to ask you to post a small sample so that we can recommend you filtering options to make the source more compressible.
By the way, the footage being progressive or interlaced depends on the source itself, not on the setting you chose on the card. In fact, maybe the source was interlaced or telecined and the card deinterlaced it, which is probably not a good idea.

[DarkZell666]

So, you guys tell me that resizing isn't a good idea for soccer game?
Downsizing is a good idea, since it will eat up much less bitrate. I can't see anybody mentioning that it was a bad idea anyway ... oO

Deblocking removes more details, which will in turn keep the bitrate lower than if you turned it off. It's usually a bad idea to turn deblocking off with any AVC-based codec anyway since it's partly thanks to that it's so efficient :)

If you really hate blocking and/or are prepared to smear some details out, use +6,+6. You might save an extra 10% bitrate.
If not, don't go below 0,0 otherwise you'll loose too much compressibility in your case.

All depends if you really want to read what's written on the player's t-shirts or if you can recognize the players just by looking at them ;)

[Romario]

My MPEG2 source have some noise, not much. Perhaps that noise ruined output quality.

I will try to post a short footage. Source bitrate is 6700 kbps.

What about Trellis Quantization in MeGUI? Is it safe to use Trellis in my case, or not?

BTW, please recommend me a fast upload server, because I hate rapidshare or megaupload.

[Chainmax]

IIRC, contrary as what happened with Xvid, in x264 Trellis was always a good choice.

[Sharktooth]

As every R/D optimization, it is good for clean sources and since the h.264 codec generally behaves like a denoiser, it helps keeping the picture clear...
So generally Trellis is more efficient on h.264 than on ASP.

[Romario]

Because I have dial-up connection, it's take quite long time to upload 50 MB on server.

Expect sample somewhere tomorrow, or day after tomorrow.

[akupenguin]

If you really hate blocking and/or are prepared to smear some details out, use +6,+6. You might save an extra 10% bitrate.
If not, don't go below 0,0 otherwise you'll loose too much compressibility in your case.

If you want to smear some details out to save bitrate, then downscale (or blur(), but downscale is better). Deblock +6 should never be used (unless combined with an equally wacky CQM or something): it's higher bitrate per QP (let alone per quality) than 0 is. Because at +6, x264 encodes some details, then the deblocker blurs them away, then the details are in the next input frame but not in the previous reference frame, so x264 encodes the details again ...

contrary as what happened with Xvid, in x264 Trellis was always a good choice. The fact that trellis didn't always help Xvid was just a bug, not an inherent difference between the codecs.

[DarkZell666]

Because at +6, x264 encodes some details, then the deblocker blurs them away, then the details are in the next input frame but not in the previous reference frame, so x264 encodes the details again ...Thinking about it, it does sound right ;) So the problem lies in that the difference between the reference frame and the refering frames becomes bigger, if I got that right.

So +6's purpose would "only" be for an already very smoothed out source then ? But if the source is already smoothed out, why use +6 ? Is there any specific occasion on which using +6 is benefic ? I've seen those screenshots comparing different deblocking values on that anime source lying around, but I wasn't too convinced with the results ...

[Chainmax]

...
The fact that trellis didn't always help Xvid was just a bug, not an inherent difference between the codecs.

Oi that's right, I had completely forgot. My bad :o.

[akupenguin]

So +6's purpose would "only" be for an already very smoothed out source then ? But if the source is already smoothed out, why use +6 ?
The purpose of deblocking isn't to remove details (why would you want that?) but to remove blocking artifacts. If your source already contained no details, then there's no penalty for using +6, and it will in fact reduce the amount of blocking. But if your source contains no details then downscaling is better yet, as it will reduce the number of macroblocks (and associated per-macroblock overead), and increase the effectiveness of DCT, and improve speed. So deblock +6 is useful only if your source contains a variable amount of detail and your software can handle variable deblock but not variable resolution (x264 does neither).

[Romario]

Guys, expect 30 seconds sample today. I will edit this post when I upload sample somewhere.

[Romario]

Here it is, guys. Little sample is on http://www.egoshare.com/f0b5cc0f237ab75a2595ab05e1992c54/untitlempg.html

[DarkZell666]

In fact, the source is really dirty imho =)

Using the following simple command-line (and with XviD@Q2, not x264), the avg video bitrate was 1765kbps, and looks cleaner than the source (thank those b-frames again ;)) :

mencoder Untitle.mpg -vf pp=lb,crop=704:560:12:10,scale=576:432 -oac mp3lame -lameopts br=96:cbr -ovc xvid -xvidencopts fixed_quant=2 -o football.avi

Using the following other simple command-line (with x264 this time, @ CRF22), the avg video bitrate was ... 683kbps, and looks even cleaner than the xvid encode xD

mencoder Untitle.mpg -vf format=YV12,pp=lb,crop=704:560:12:10,scale=576:432 -oac mp3lame -lameopts br=96:cbr -ovc x264 -x264encopts crf=22 -o football.avi

the same cmdline with ":nodeblock" added to "-x264encopts" gives 740kbps, but doesn't restore the lost grain, so you might as well keep deblocking to it's default value(s).

Samples :

XviD encode @ Q2 (http://www.egoshare.com/89b76a9297ada4440a8de2f586241335/footballxvidavi.html)
x264 encode @ CRF22 with default deblocking (0,0) (http://www.egoshare.com/0888f21d1c4736cf0d2a4a7c9ea66850/footballx264_deblock0mkv.html)
x264 encode @ CRF22 with no deblocking (http://www.egoshare.com/71f11c57b55ca41e4edefb140f7b505e/footballx264nodeblockmkv.html)

So either the sample doesn't reflect your source sufficiently well, or you did something wrong ;)

Could you post a sample of what you actually encoded ? I can't believe a 2400kbps encode can look that bad (considering the surprisingly low bitrate I obtained myself right now ... o_O).

Edit: second thoughts, did you use an AVS script to try and clean the source ? You'll have to be more precise about what you actually did, it's a guessing game again ...

[Jay Bee]

I made 1fps Huffyuv AVI that compares the same frame of the original source, Elecard converter beta 2000kbps and DarkZell666's x264_deblock0 (in this order).

http://rapidshare.com/files/4365724/compare.avi.html (1.2 MB)

IMO the MPEG-2 is still clearly the best, the Elecard file is pretty good and the x264 file is pretty awful (no offence). Maybe you were confusing the details of the grass pitch with noise?

[DarkZell666]

I'm afraid there really is quite a bunch of noise and blocking man, and because of that, there isn't any grass-detail left in the source anyway :) I do agree the x264 version smooths a lot of texture out and looks a tad artificial, but changing some settings can obviously set that straight again ;)

Note: XviD@Q2 is said to be visually equivalent to x264@qp18. I used crf22, so no wonder the deblocking is a bit overdone :p

XviD does a better job at keeping the grain, and the bitrate is still below 2000kbps, which I why I'm pretty surprised to see that 2400kbps using x264 isn't enough for Romario :)

Edit: a crf18 version is visually closer to xvid@q2 and gives 1423kbps, and a cqp18 version is visually even closer to xvid@q2 but needs 2432kbps (WoW o_O)

x264@cqp18 (2432kbps) (http://www.egoshare.com/71a3b97d7530b065e4eab10f171ac736/footballx264_cqp18mkv.html)
x264@crf18 (1432kbps) (http://www.egoshare.com/7fa015d6af07feb35f6f324efb4130d4/footballx264_crf18mkv.html)

[Jay Bee]

The x264 look better now but I actually like the Xvid file best. I tried some more tests based on your command lines but without the resizing since I think it takes away some of the detail. What I came up with is that Xvid@Q3 and x264@crf19.5 are about the same filesize as the Elecard file I made earlier.

Here's a comparision of the three (order:elecard,xvid,x264):
http://rapidshare.com/files/4402822/compare2.avi.html

Of these encodes I like the elecard best then xvid then x264. But I admit it's not easy to tell artefacts from detail.

[rhayman]

Hi, Im having a similar problem with a soccer game, i recorded it on High Quality on my dvd
recorder, source is Pal 720x576. It is slightly blocky in some places but overall quite
good quality. I have tried to deinterlace it with various methods and when up close on players
it looks fine but when zoomed out on large area of pitch it loses a lot of detail and get very blury.

I have of uploaded some samples of the original MPEG2 files.

http://www.egoshare.com/4f579e3bdc9d7537b82aa006acf42eb6/sampleszip.html

Theres quite a few mpeg2's like this i wish to encode to save space which i plan to view both on my
pc and on my tv (using xboxmediacenter), I have read that its better to keep it interlaced if you plan to
veiw on your tv as it will looks better and keeps more detail.

I plan to use meGUI to encode the files to x264. Is better to keep these files interlaced and encode them (can you resize),
how do you go about doing it, I tried encoding a plain avs script with no deinterlacing and it looked awfull.
If it is possible to encode to x264 keeping it interlaced when its played back (using ffdshow)
does it deinterlace, like mpeg2 decoders can.

[nm]

Of these encodes I like the elecard best then xvid then x264. But I admit it's not easy to tell artefacts from detail.
Well, if you want to compare the output of different encoders at the same bitrate, you should use comparable encoder settings too. With DarkZell666's MEncoder commands, x264 uses only 1 reference frame and no b-frames, 8x8dct nor trellis. XviD has (relatively) higher quality default settings.

[Jay Bee]

Yeah, but I wasn't comparing encoders, I was comparing encodes.

rhayman:
Another big reason you want to keep interlaced video interlaced is because deinterlacing will, depending on deinterlacer, either cut the temporal resolution in half (motion smoothness) or double the frame rate (higher bitrate). ATM there is no AVC or ASP decoder with good support for automatic deinterlacing but the next version of CoreAVC should do the job.

[nm]

I wasn't comparing encoders, I was comparing encodes.
But why? As far as I can see, in this case the differences between the encodes would be due the encoders and their settings. So what is your point?

[Jay Bee]

As far as I can see, in this case the differences between the encodes would be due the encoders and their settings.

Quite possible. But again, I wasn't trying to find out which encoder was better. Really it's quite straightforward:

Romario asked for football encoding advice, Darkzell made some suggestions, I made a suggestion and compared, Darkzell made some new suggestions, I made some small changes and compared again. Then I posted my opinion about which resulting encode I liked the most.

Now maybe it's possible to get the same results with x264, maybe not, I didn't try and I see no reason why I should have. :confused:

I would be interested in what other people think about the results though.

[Chainmax]

Here it is, guys. Little sample is on http://www.egoshare.com/f0b5cc0f237ab75a2595ab05e1992c54/untitlempg.html

I can't download it, it only plays within the browser.

[DarkZell666]

Well, if you want to compare the output of different encoders at the same bitrate, you should use comparable encoder settings too. With DarkZell666's MEncoder commands, x264 uses only 1 reference frame and no b-frames, 8x8dct nor trellis. XviD has (relatively) higher quality default settings.LOL you owned me there, I didn't even check what the default settings were. I (naively) thought that mencoder's x264 defaults would at the very least use 2 bframes and 2 or 3 refs ... :D

The whole point Romario is on about (and which I don't understand, at all), is that his 2400kbps x264 encode (which I'm still waiting for a sample of ;)) looks awful. Even XviD does a very clean encode @Q2 and only requires 1700kbps, which tends to show that either Romario did something wrong, or that he used an AVS script that contains (amongst other things) some sharpening (which would explain partly why 2400kbps wouldn't be enough, imho).

[Romario]

I used an AVS script, like this:

DGDecode_mpeg2source("P:\Untitle.d2v",cpu=4,info=3)
ColorMatrix(hints=true)
#blank deinterlace line
#crop
LanczosResize(576,432) # Lanczos (Sharp)
mergechroma(blur(1.3)) # Little Noise

With these settings:

x264.exe --pass 2 --bitrate 2400 --stats ".stats" --ref 6 --mixed-refs --bframes 4 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --me umh --thread-input --progress --no-psnr --output "P:\Untitle.mp4" "P:\Untitle.avs"

[Jay Bee]

Romario:
Any comments on the suggestions that have been made?

[DarkZell666]

I don't see any resizing in your script, which would also explain why the resulting encode is blocky. In your first post you stated that you resized to 576x432, which doesn't seem to be the case from what you've posted.

[Romario]

Yes, you are right, DarkZell666, I forgot to include resizing in AVS script. I will edit the post right away.

Gyus, thanks on good advices, but I think that noise ruined my x264 encode. Can anybody tells me how to clean the noise? Which parameters?

[DarkZell666]

On the samples I posted, the noise doesn't harm the encode at all. As you can see on the CRF18 sample, the picture is clean and the bitrate is around 1400kbps (which is way below your 2400kbps :/).

(I tried adding bframes and more refs and this only gave me more ringing but hardly impacted the bitrate, so I wouldn't bother).

I clearly remember now that x264's 2pass ratecontrol doesn't like fast moving objects and/or sudden bitrate/quantizer variations. If you really don't want to use CRF, try tweaking the ratetol and qcomp parameters (ex: --ratetol inf and --qcomp 0.75 instead of the defaults, which are --ratetol 1.0 and --qcomp 0.6). But since you're trying to achieve *VERY HIGH QUALITY*, you shouldn't be using 2pass but a quality-based mode anyway :) Heck, this is what crf is for !

[Chainmax]

Yeah, you should use the CRF equivalent to Q2 with some judicious filtering. Probably AddGrain(2,0,0) or (5,0,0) would be good as well.

[akupenguin]

I clearly remember now that x264's 2pass ratecontrol doesn't like fast moving objects and/or sudden bitrate/quantizer variations. If you really don't want to use CRF, try tweaking the ratetol and qcomp parameters
Note that CRF penalizes fast moving objects in exactly the same way that 2pass does.

[Romario]

Then, what's your proposal, akupenguin? How to deal with fast moving objects?

[akupenguin]

I like it the way it is, that's why I wrote it this way. But as DarkZell said, you can tweak qcomp if you want a different distribution of bits.

[Romario]

I can't read your mind, akupenguin. Can you, please, be more specific.

Thank you very much.

[DarkZell666]

Romario: you have all the info you need. akupenguin (which is one of the x264 developers if you didn't know ;)) chose to sacrifice "fast moving objects" when he designed the ratecontrol, so the easiest way to "correct" this is to tweak the --qcomp value.

I believe you have enough info to solve your "problem" now :)

Did you do other tests ? Do you have new results ?

This has been running for 2 weeks now, I'm sure you must have tried something ;)