Quality and Video Encoding

To put this out in to the ether...

Do people here give a rats arse about the quality of the vids they download, or are they more interested in size ?
Or (perhaps more likely) there's no single answer and people do or don't download on a whim...

To the other cappers and encoders out there - do you spend all your waking non-work hours doing stuff for the site with the vids you produce ?
I ask as that seems to be what I am doing at present, which is why it's starting to loose any and all appeal !

For me I think quality matters, hence why I've spend literally days going through various tweaks in settings to eke out a very minor improvement here, and speed uplift there, whilst keeping quality at a reasonable level aligned to file size.

But I'm starting to think it's not worth it.

OK. Let's summarise this and a few other bits to some pointed questions:-

1. Do people care about the file size ?
2. Should vids be created at set sizes and take into account define profiles ?
3. For those creating content, do you care if its MKV or MP4 or anything else for that matter ?
4. To keep quality aligned to file size, I find 30 minutes = 200Mb of file size. Is that the same for other encoders ?
5. Is there any benefit to some of the encoders getting together to define a "standard" so that everyone will know what to expect when downloading something ?
6. Should encoders share software used, techniques, settings etc ?
7. Instead of lots of people capping the same channels, should common encoders create a schedule of who will record what channels and post what content ?

I guess I'm just trying to think of some structure, which may in all likelihood just be too much overhead....

Thoughts, questions, rants ?

I'll open the floor to others now....

One point I didn't cover in above is that I encode not just for people to download, but for my own archive. I've plenty of content I don't post either 'cos it's too large, not interesting enough, is from channels we can't post here, or indeed there's loads of it already on the site.

But through it all, as it's for my archive as well, that's why quality matters (to me).

Although as I keep all the mpeg2 source files, I could just scrap that and watch originals and upload whatever the masses think is suitable...

I don't think the average down-loader is bothered by quality or file size. If the subject matter appeals to them, they will download it.

I too am constantly improving my encoding techniques. I've now got to the stage, that I don't think I can get them much better, given the sources we take them from.

I've posted vids ranging from a few meg to over 1 gig. They all get downloaded.

But I'm like you, I prefer to try and post the best quality I can achieve at the time. Yes it takes a lot longer to do, and I'm not sure if people prefer it or not.

I just post whenever I get around to editing it up. If it happens to have been posted by someone else, then fine. I'll let the down-loader choose which one he prefers.

But since 90% of all downloads come from guests. I don't think we will find out what the preference is. As they can't tell us.

(10-02-2011 18:17 )dirk362 Wrote:  One point I didn't cover in above is that I encode not just for people to download, but for my own archive. I've plenty of content I don't post either 'cos it's too large, not interesting enough, is from channels we can't post here, or indeed there's loads of it already on the site.

But through it all, as it's for my archive as well, that's why quality matters (to me).

Although as I keep all the mpeg2 source files, I could just scrap that and watch originals and upload whatever the masses think is suitable...

I try to post stuff that is interesting and not posted by others.
The quality is whatever the h264 codec with default settings gives me from my original source material.
The only editing I do is cropping picture and cutting/splicing sections.
I keep the file sizes below 100MB, and usually a lot less than that by using smaller running times and/or reducing picture size if necessary. This is because I do not download many large vid files myself (no fast paid for accounts and rapidshare takes ages for big files) and some other people have download cap limits, plus I've not much spare hard drive space on this computer. BTW, just bought a new external usb hard drive today.
I keep the originals if captured on DVD but usually delete the source files if captured elsewhere.

Good/interesting points being raised. Keep 'em coming...

For me the tweaking work has now been through so many iterations as I've moved between software stacks, and even OS back and forth from Windows to Linux etc. I've used RipBot264, AviDemux, MeGUI and StaxRip as well as some others, and even though these are GUI tools, a lot of work has gone into the underlying settings to tweak here and there.

My AVS scripts (for StaxRip) are now quite complex (example below and yes some of these may seem a bit weird like post-processing and then going to the effort of using QTGMC, but with the quality of the input mpeg2 files this works well) such that I can get the most out of the source material (which lets be honest is pretty piss-poor across all the channels even those with decent cameras as the bandwidth just isn't there from $ky). This quality has a time impact in that quick-n-dirty encodes are at 65fps or above, whereas quality is around 25fps and can go as low as 5fps


I also try and post stuff not elsewhere, although there are some exceptions that are just too good to be kept to oneself

(10-02-2011 18:11 )dirk362 Wrote:  7. Instead of lots of people capping the same channels, should common encoders create a schedule of who will record what channels and post what content ?

I've thought that myself, a few times.
Especially when I spend 30 mins watching a web-stream taking screen-shots, then sort through the best ones, then upload them to an Image host, then go to the appropriate Babe's page... only to find that someone else has already posted a load of similar pics - 2 minutes ago.

I then usually just post my pics anyway, rather than just delete them.

I'm not sure a rota would work though. I can do caps all weekend, and sometimes afternoons/evenings through the week. But if I'm working late, or the web-stream's down, then someone else (with Sky, in the last case) would have to take over. But if I'm working late, I would have no way of telling the Forum, so unless someone else took caps "just in case", the section I would have been doing wouldn't get covered.

Plus, there would bound to be arguments over who caps what. There's always going to be someone who'll post caps regardless. Should their screen-shots be deleted from the Forum, purely because it's not their turn to do so?

So, some sections get covered by 2 or 3 people, whilst most sections go uncovered altogether. Not very efficient, but I can't see any way of implementing a system.
Maybe some sections don't deserve to be capped, anyway.

And, if someone else does cap a channel same time as me... well, "the more, the merrier."

"The road to Good Intentions be paved with Hell"

(10-02-2011 20:07 )Jam Da Man Wrote:  Plus, there would bound to be arguments over who caps what. There's always going to be someone who'll post caps regardless. Should their screen-shots be deleted from the Forum, purely because it's not their turn to do so?

So, some sections get covered by 2 or 3 people, whilst most sections go uncovered altogether. Not very efficient, but I can't see any way of implementing a system.
Maybe some sections don't deserve to be capped, anyway.

And, if someone else does cap a channel same time as me... well, "the more, the merrier."

Valid point. It would be unlikely to work in the real world given these sorts of issues. Theory of not by channel but by babe might work with primary, secondary etc cappers. But it's just too damn complex to set up.

Oh and on posting caps or whatever, just add them in - I tend to ignore pretty much what's been done before unless the forums overflowing with the same pictures of the same babes... If you've put the effort in and uploaded 'em, then make sure you post 'em !

When it comes to video quality, there are a few things that can really bugger things up and yet nearly all the channels do this.

Girls wearing nets of any type cause real issues as it requires a lot more bandwidth (read kbps) to produce. This in turn affects encoding as it will try desperately to make the distinction between skin and the lines of the net, which means a huge amount of extra kbps is required (in fact you can't stop the encoders from doing this). In real world this can make an encode of very similar scenes for movement upto 50% bigger when nets are worn rather than not.

The background - it may not seem important, but it's there and therefore has to be encoded. On RLC for example they have very detailed sets with flowers, lights with wires, and fur cushions etc. All of this has to be encoded and just because we're ignoring it all and concentrating on the babe, the encoder can't do this. So again more kbps get used for stuff we don't really care about.

The OSG - with constant movement, these add a change to every single frame. It adds circa 30% to the final size when OSGs are in place and when not.

Camera movement - try not to bugger about with it so much and keep it moving - that means the whole screen is moving so it's all a different type of frame when encoding (forces use of more I and P frames rather than B frames as references). Basically lots of camera movement = more bandwidth.

If producers and content owners could just take the above in to some consideration when designing sets and also how they'll produce and air the show, it would all be much much better.

what hardware are you using?
especially the gfx card... are you recoding off the cpu or the gfx...

personally i prefer quality over file size... if there to small they just look blurry on my 1080p display

My personal understanding is GPU encoding is still in it's infancy in respect of what you can and can't do with it, and the improvements in encode time don't come up to scratch with quality (there are no decent H264 encoders that support GPU encoding that offer the full setting options, or more accurately I should state none that are free and don't cost many £1000's).

I've 3 different PCs I use for encoding - lowest spec is Phenom II X6 with 4Gb RAM and SATA-2 disks, through to to my Core i7 (1366 socket) overclocked to 4.2GHz with SATA-2 in RAID-0 for temporary space and 8Gb RAM. All machines have PCI-x graphics which has at least 768Mb RAM on it and I use ATI/AMD graphics only (as NVidia went through a bad patch as far as I'm concerned with their drivers). An example card is HD5750.

What you set in respect of parameters, de-interlacer, size etc all have an impact on encoding speed. I know for example that QTGMC de-interlace (with the other bits on as well) means in a non multi-threaded AviSynth environment might just might reach 5fps on the i7 when working with Elite-965 encoding to 720x404. I can increase that to around 25fps on same machine and content using AviSynth-MT.
If I go with a simpler de-interlacer such as Yadif, the speed goes up a lot to around 65fps, but the quality goes down (as it's a quick and dirty de-interlacer), and also the kbps in the encode goes up as it's a bit blurry to encode due to the de-interlacer. I can get slightly better quality with say Decomb (with no strategy defined) and that is around 45fps.

I do however use very specific x264 parameters that took me a long time to define and refine (and keep refining as they keep improving the x264 encoder itself). As an example the current ones are:-

x264.exe --preset slower --tune film --crf 24 --level 3.1 --ref 5 --no-fast-pskip --qpmin 0 --vbv-bufsize 14000 --vbv-maxrate 14000 --merange 32 --no-dct-decimate --qpmax 30

I check all content on my 24" 1080p monitor, and if I don't like it there then it doesn't get an upload.

Quality vs File Size is a difficult mistress to please - you can't keep them all happy all the time.

I'm going to (once I get all my overnight encodes out the way) do some analysis and post some examples of good vs bad in respect of why the content as aired is critical to a successful encode.