h.264 at DV Quality

[jfsecure]

I have been working on transcoding DV recorded sports footage into h.264 footage. We only need to reduce the overall size of the files as much as possible while maintaing DV quality with no specific file size restrictions. Ideally a 60-70% in file size would be excellent.

That being said, as I progress though my testing is it even possible to reproduce DV quality footage with enough bitrate in h.264? I can get close but it seems I cannot quite get the fluidity of motion and sharpness of raw DV.

[kotrtim]

You did not mention your command line...


http://forum.doom9.org/showthread.php?t=101813

These are profiles made by sharktooth
use "CQ-ASP_Q2_eq(crf)"

--crf 18 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh

again since you did not mention the what encoder you use, i assume you use x264

[hpn]

I can get close but it seems I cannot quite get the fluidity of motion and sharpness of raw DV.
60% of DV (25Mbps) is about 15Mbps, so you could try some very low constant quantizer, like 7 or something and see if you like the result (CLI: x264 -q 7 ...). If you encode DV footage with x264, make sure you deinterlace first, cause most DVs are interlaced unless you have a progressive camcorder (x264 does not "like" interlaced input). With Nero Digital you could do it without deinterlacing, but I haven't played with Nero lately so I can't remember if it has constant quantizer option.

[DarkZell666]

Why not try the lossless mode (qp = 0) ?
x264 -qp 0 -o input.dv output.mp4

If the filesize is too big, try just disabling the inloop filter with the --nf switch and encoding with a specific quantizer (10 should be fine, and 18 is said to be the equivalent to XviD's quantizer 2).
The inloop filter smoothes the picture out a bit too much for some sources, even set to -6:-6 so this might be the solution to the lack of sharpness you described. Disableing bframes might help, try just in case.

Example :
x264 --qp 10 --bframes 0 --subme 6 --me umh --nf -o input.dv output.mp4

If you are trying to achieve a certain quality, you should better forget trying to find a bitrate. Simply run some test qp-based encodes with 1000 frames and playing with the qp value. When the quality suits you let the full encode run and see if the filesize suits you.

As for the motion fluidity, h264 is very CPU intensive for encoding and decoding. If you are using high-resolution material you'd better have a 2ghz+ CPU :)

Please give us some feedback when you have some more results.

[akupenguin]

x264 --qp 10 --nf -o input.dv output.mp4
-o means output ;)... and x264cli can't read directly from dv files, you need a .avs in between (or mencoder).
At qp<=15, loopfilter is inherently disabled, so playing with -f or --nf does nothing.

This doesn't help the original question, just nitpicking.

[hpn]

Why not try the lossless mode (qp = 0) ?

Lossless + DV source produces a slightly higher bitrate than the original DV in my tests, so it's useless. -q 7 gives me about 60% the original size and anything less than quantizer 6 gets very close to the original size, so it's also useless.

[foxyshadis]

If --qp 7 looks good on all scenes, then perhaps --crf 8, 9, or 10 would be good overall, and at least acceptible on the most complex scenes, while saving a lot of bitrate? Worth a shot.

Also, for the most benefit, a mild deblocker on the source is probably worthwhile unless you have a really great-looking DV.

[DarkZell666]

-o means output ;) ...
hmm lol I need more sleep xD

[jfsecure]

This is some great information to work with. To answer your question, yes I am using x.264 and de-interlacing before encoding.

I'll run some more tests tonight and post my results.

[nm]

I'd say your problems with sharpness and fluidity come from deinterlacing, so check that phase too.

[smok3]

yeah, afaik x264 does not support interlaced material, i would pick some mpeg2 encoder instead, like HC.