Recommended intermediate HD codec

[Alex-Kid]

I have a football match capture in HD (1920x1080i, 30fps) that I want to edit to make it highlights. I need to save it to an intermediate file to apply graphics and transitions and then save it as MKV. I use DGAVCDecDI to decode the file, so I can use Avisynth to process it.

So my question is ¿what codec would you recommend to work as an intermediate one without losing too much quality? My upper limit is 145 Mbps (I thought of DNxHD, but afaik there are no DS codecs).

Saludos

By ALEX-KID

[Sagittaire]

there are many lossless codec. Anyway if you want lossy codec with really light loss try MPEG4 ASP (XviD or DivX) with only Iframe and at quant 1 ...

[Alex-Kid]

Thanks for your recommendation Sagittaire.

I finally used XviD as you told me, but it was kinda slow, even using avisource. I got about 6-12 fps in my C2Q Q6600. It would have been good to use a codec like DV for SD video, which is fast and it has very little loss. I tested Lagarith with HD video, and it's fast (20 fps), but less efficient (245 mbps!). Maybe there is a good HD codec, fast, good quality I-frame based, bitrate efficient (120-150 mbps@1080i) and DirectShow/VFW compatible somewhere in Internet.

Saludos

By ALEX-KID

[3ds]

One of the best loosless codec is IMHO Lagarith: http://lags.leetcode.net/codec.html

[Mug Funky]

based on what you've said of your workflow, you would do well to install AVFS (avisynth virtual file system) and pop the resulting uncompressed (and taking zero real space) file in your editing software to do cuts, fades, etc.

then export from there into anything you want.

this would be the fastest i think, bearing in mind i think it's your hard disk that's slowing things up, not your CPU.

[smok3]

cineform maybe http://www.cineform.com/products.php

[Daiz]

How about UTVideo? It's ridiculously fast to seek so you'd expect it to be pretty ideal for editing purposes.

[TheRyuu]

How about UTVideo? It's ridiculously fast to seek so you'd expect it to be pretty ideal for editing purposes.

This.

[kypec]

This.
Yeah, I was about to suggest the same codec as well. No experience with HD filesize requirements but the speed of decoding is excellent, especially on multicore CPUs.

[Alex-Kid]

Thank you all for your suggestions.

I know there are several lossless codecs, and using them would be optimal, but space (specially on HD video) is an issue on my system. CineForm doesn't have DS support AFAIK. My sources are loaded with DGAVCDecDi plugin, which has some problems when seeking on H.264 broadcast captures. I think AVFS could be my option if the script mounted works as a true uncompressed file when trimming it. I'll post results as soon as I have some time to test. If not, I think I'll have to buy a larger HDD.

Saludos

By ALEX-KID

[smok3]

also: http://www.matrox.com/video/en/support/windows/vfw_software_codecs/downloads/softwares/version1.0/

[kolak]

Matrox is the worse crap out there...slow.

From free ones UTVideo is amazing- unmatched speed. You can edit 4K on good PC :) It's lossless so bitrates are more than 200Mbit for HD.

If you can pay than Cineform or Canopus codecs (HQX- many bitrate settings), which you can get by buying Edius or cheap Edius Neo.


Andrew

[smok3]

From free ones UTVideo is amazing- unmatched speed and the latest version is? (drums) some cute links? (drums)

[kypec]

and the latest version is? (drums) some cute links? (drums)
Ever heard of :search: functions? Or Google?
The codec has even its own thread (http://forum.doom9.org/showthread.php?t=143624) on this very forum...

[Atak_Snajpera]

@Alex-Kid
I use x264 as intermediate codec for AVCHD files (camcorder)
x264.exe "script.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --output "video.264"


It is not lossless (above cmd) ofcourse but still gives very good quality. During conversion from 24Mbps 1920x1080i I get ~37 fps on my Q6600@3ghz. If you are not satisfied with quality you can always increase bitrate
(--bitrate 75000 --vbv-bufsize 7500 --vbv-maxrate 75000)

[sneaker_ger]

Why bufsize only a tenth of bitrate/maxrate? Why vbv at all?

[Atak_Snajpera]

Why bufsize only a tenth of bitrate/maxrate? Why vbv at all?
Why would you use larger buffer size for intra only mode? At the begining I was using even 2000 but I had problems with buffer underflow.

[sneaker_ger]

So, why use vbv at all?

[Atak_Snajpera]

So, why use vbv at all?
To reduce decoding lag? In theory --vbv-bufsize 2000 should be enough for 1 frame (--vbv-maxrate 50000 / 25fps) but it is not (buffer underflow). So I decidede to use buffer for 2.5 frames

[sneaker_ger]

There's significant decoding lag on i-fame-only encodes?
Don't get me wrong, I'm not trying to criticize you - just trying to understand the reasoning behind your settings.

[Atak_Snajpera]

Basically I wanted to have easy to edit files. Seeking in Sony Vegas should be slightly faster for example. Maybe I'm wrong but I think that decoder has to fill in whole buffer before decoding selected frame.

[sneaker_ger]

I don't think that's true, it only has to wait for the frame to be completely downloaded. But then again, I'm no expert.

[Alex-Kid]

@Alex-Kid
I use x264 as intermediate codec for AVCHD files (camcorder)
x264.exe "script.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --output "video.264"


It is not lossless (above cmd) ofcourse but still gives very good quality. During conversion from 24Mbps 1920x1080i I get ~37 fps on my Q6600@3ghz. If you are not satisfied with quality you can always increase bitrate
(--bitrate 75000 --vbv-bufsize 7500 --vbv-maxrate 75000)

I think this is a very good recommendation, considering the use of DGAVCDecDi, which is fast on decoding. Do you know if this settings work with DGAVCDecDi (specially the use of intra frame only)?

I tested Matrox codecs and the only ones that worked with my HD sources (1920x1080i) were the uncompressed codecs: not useful.

Saludos

By ALEX-KID

[Atak_Snajpera]

Do you know if this settings work with DGAVCDecDi (specially the use of intra frame only)?
It would be weird if DGAVCDecDi couldn't decode AVC-INTRA ;) ffmpeg-mt , libavcodec and microsoft decoder have no problems with decoding.

[CruNcher]

Did someone already compared AVC-INTRA vs VP8-INTRA, i guess this could be really interesting also over several generations and in terms of speed :)

[Alex-Kid]

Did someone already compared AVC-INTRA vs VP8-INTRA, i guess this could be really interesting also over several generations and in terms of speed :)
That's true, but AFAIK WebM has only DS playback filters (as shown here (http://forum.doom9.org/showthread.php?t=154669)). Are these ones frame accurate to use them with Avisynth's DirectShowSource?

[Chikuzen]

That's true, but AFAIK WebM has only DS playback filters (as shown here (http://forum.doom9.org/showthread.php?t=154669)). Are these ones frame accurate to use them with Avisynth's DirectShowSource?

you can process them with ffms2.
libavcodec is the fastest VP8 decoder at now.

[space1999]

That's true, but AFAIK WebM has only DS playback filters (as shown here (http://forum.doom9.org/showthread.php?t=154669)). Are these ones frame accurate to use them with Avisynth's DirectShowSource?

I think so, because VP8 does not use B-frames.

Besides,

- ffdshow can decode VP8 through VfW

- as a last resort, one can always remux VP8 in AVI and use AVISource() :D

[Alex-Kid]

I think so, because VP8 does not use B-frames.

Besides,

- ffdshow can decode VP8 through VfW

- as a last resort, one can always remux VP8 in AVI and use AVISource() :D

Those are good options to consider.

I did two tests with the suggestion made by CruNcher: h.264 vs WebM.

h.264: used x264 (r1995) with the command line provided by Atak_Snajpera.
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --ssim --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mkv"
WebM: used ffmpeg (r25870-Sherpya) with the following command line
ffmpeg.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -y -b 50000k "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.webm"

Used the SSIM index as an objective quality metric (Avisynth SSIM) and compared both videos. This is the result:

5759 frames, 29.97 fps, 1920x1080i

X264
36.88 fps, 50 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 88.66771698


FFMPEG VP8
~ 2 fps, 23.9 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 85.55319214

x264 took less than realtime to code. ffmpeg is still too much slow for doing this task, it didn't respect the bitrate (is less than a half of it), but showed to be very close to x264 SSIM.

I think that WebM could be a candidate for intermediate codec when it gets faster encode times. This shouldn't be difficult considering it's a less complex format than h.264 (Or am I wrong?)

Saludos

By ALEX-KID

[nm]

SSIM = 88.66771698 doesn't sound quite good enough for intermediate video, although I haven't used the AviSynth implementation on interlaced video. Anyway, I'd drop those VBV limits and use --crf 10 (or lower), and maybe pick a slower preset than superfast.

WebM might become an alternative at some point, but your test doesn't show how far it is. You compared x264 with very fast settings, intra-frame encoding, 50 mbps bitrate against WebM with slow settings, inter-frame encoding and 25 Mbps bitrate.

[Alex-Kid]

SSIM = 88.66771698 doesn't sound quite good enough for intermediate video, although I haven't used the AviSynth implementation on interlaced video. Anyway, I'd drop those VBV limits and use --crf 10 (or lower), and maybe pick a slower preset than superfast.

WebM might become an alternative at some point, but your test doesn't show how far it is. You compared x264 with very fast settings, intra-frame encoding, 50 mbps bitrate against WebM with slow settings, inter-frame encoding and 25 Mbps bitrate.
I agree with you, but you can still use a higher bitrate (100 mbps perhaps) to raise up SSIM. I couldn't get vpxenc to work with Avisynth and as I said on previous post, ffmpeg didn't respect the bitrate specified. I have to admit I have little experience tweaking cli settings. Do you have any suggested settings, specially for WebM?

[CruNcher]

a PSNR of @ least 50 is generally ok for intermediate purposes and visually loss less SSIM most probably would be quite high in the 9x range 0.98-0.99 i guess so 50-70-100 Mbit/s seems to be a good base, and then look @ the decrease over 10 generations

[henryho_hk]

Why not XviD @ "ME=6, VHQ=1, no b-frames, chroma ME, EQM EHR, constant quantizer=2" (i.e., Editing only preset)

[Sagittaire]

Why not XviD @ "ME=6, VHQ=1, no b-frames, chroma ME, EQM EHR, constant quantizer=2" (i.e., Editing only preset)

better to use q1, low coef matrix (flat 8), ME=1, VHQ=0 with only Iframe. Intermediate codec must have the best possible quality with high speed.

[henryho_hk]

Some tests using XviD 1.3.2 (and its internal SSIM calculator)


Matrix CQ VHQ KeyInt Bytes XviD SSIM XviD DSSIM SSIM 0.25 Mbps
EQM_EHR 2 1 240 2066947012 0.99756453 410.60 95.924313 61.31
FLAT8 2 1 240 2282251752 0.99719754 356.83 95.667952 67.70
EQM_EHR 2 0 240 2331591210 0.99705402 339.45 95.548083 69.16
FLAT8 2 0 240 2351546490 0.99704420 338.32 95.538876 69.75
EQM_EHR 2 0 1 2530233380 0.99758143 413.47 95.884627 75.06
EQM_EHR 2 1 1 2530233380 0.99758143 413.47 95.884627 75.06
FLAT8 2 0 1 4062787499 0.99728564 368.41 95.819092 120.52
FLAT8 2 1 1 4062787499 0.99728564 368.41 95.819092 120.52
EQM_EHR 1 1 240 4187715602 0.99925288 1,338.47 97.977496 124.22
EQM_EHR 1 0 1 4378203200 0.99907440 1,080.38 97.437817 129.87
EQM_EHR 1 1 1 4378203200 0.99907440 1,080.38 97.437817 129.87
FLAT8 1 1 240 4892268650 0.99971158 3,467.19 98.843035 145.12
EQM_EHR 1 0 240 5349473908 0.99987316 7,883.87 99.164567 158.68
FLAT8 1 0 240 5363731504 0.99987795 8,193.58 99.174940 159.11
FLAT8 1 0 1 5698372989 0.99954413 2,193.59 98.379881 169.03
FLAT8 1 1 1 5698372989 0.99954413 2,193.59 98.379881 169.03

[Sagittaire]

Here the most important is not size but speed/size.

[Atak_Snajpera]

"ffmpeg.exe" -threads 4 -i "E:\_Video_Samples\HDcam\00001.mts" -flags +ildct+ilme -b 50000000 -r 25.000 -vcodec libx264 -preset superfast -tune fastdecode -threads 4 -x264opts keyint=1:nal-hrd=vbr:vbv-bufsize=50000:vbv-maxrate=50000 -ab 512000 "C:\temp\AVC-INTRA.mp4"

While encoding with above command I get 30+ fps on my Q6600@3ghz. Source is AVCHD@24Mbps.

Decoding speed with libavcodec (1 thread) is ~55 fps

[Alex-Kid]

Did some more tests, here is the info:

CLI CODEC/CODER BITRATE SPEED(fps) SSIM(v0.23)
-------------------------------------------------------------
(1) x264 50 mbps 36.88 fps 88.66771698
(2) VP8(ffmpeg) 23.9 mbps ~2 fps 85.55319214
(3) x264 100 mbps 33.23 fps 95.32942963
(4) xvid_encraw 237 mbps 9.93 fps 96.94023053
(5) lagarith 235 mbps 35.30 fps 100.00000954



5759 frames, 29.97 fps, C2Q Q6600@2.4 GHz

------------------------------------------------
(1)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --ssim --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mkv"

36.88 fps, 50 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 88.66771698

------------------------------------------------
(2)
ffmpeg.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -y -b 50000k "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.webm"

~ 2 fps, 23.9 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 85.55319214

------------------------------------------------
(3)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 100000 --vbv-bufsize 20000 --vbv-maxrate 100000 --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.mkv"

33.23 fps, 100 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 95.32942963

------------------------------------------------
(4)
xvid_encraw.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -max_bframes 0 -cq 1 -quality 1 -vhqmode 0 -qmatrix "c:\Archivos de programa\K-Lite Codec Pack\Tools\Xvid_Quant_Matrices\Flat 8-16.xcm" -interlaced 2 -qtype 1 -threads 4 -o "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.avi"

9.93 fps 237 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 96.94023053


------------------------------------------------
(5)
Lagarith (lossless, used as reference)

35.30 fps 235 mbps

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 100.00000954


I'm thinking that (3) cli settings is enough for intermediate codec, given its high SSIM. Maybe 120 mbps would be a little better.

Does anyone know if well known Cineform has better values? Being a wavelet codec, could that be an advantage to achieve higher performance and quality?

[nm]

Could you try x264 without VBV and with CRF rate control instead of CBR, as suggested earlier:

--crf 8 --preset superfast --tune fastdecode --keyint 1

and also with slower settings:

--crf 8 --preset veryfast --keyint 1

If you have time to play with it, adjust CRF so that you get a final bitrate close to 100 mbps. Then the result can be compared with your last numbers.

[henryho_hk]

I thought you want a codec for capturing.

If u do have an AVS to start with, try four simultaneous runs of single-threaded xvid_encraw using EQM_EHR @ CQ=2, VHQ=0 and KeyInt=1.

[henryho_hk]

Did some more tests, here is the info:


What about decoding performance?

[Atak_Snajpera]

@Alex-Kid
I think you should add --aq-mode 2 --no-psy options if you want higher ssim values.

[henryho_hk]

Since he is doing big intermediate encoding, would "--aq-mode 0" be better?

[CruNcher]

yes might be seeing the results the blu-ray pros get with it @ high bitrates it might be backfiring (it needs to be evaluated) though then you dont improve on ssim but on psnr and can use --tune psnr anyways that also will disable AQ

[Alex-Kid]

Well this is the last info from the tests:

CLI CODEC/CODER BITRATE SPEED(fps) SSIM(v0.23)
---------------------------------------------------------------
(1) x264 50 mbps 36.88 fps 88.66771698
(2) VP8(ffmpeg) 24 mbps ~2 fps 85.55319214
(3) x264 100 mbps 33.23 fps 95.32942963
(4) xvid_encraw 237 mbps 9.93 fps 96.94023053
(5) lagarith 235 mbps 35.30 fps 100.00000954
(6) x264 115 mbps 32.62 fps 96.51400277
(7) x264 111 mbps 33.02 fps 96.45086489
(8) HCEnc 102 mbps 2.20 fps 94.13687145
(9) DNxHD(ffmpeg) 145 mbps 13.55 fps 95.35936372
(10) VP8(ffmpeg) 84 mbps 4.38 fps 93.42168415
(11) xvid(VDub) 103 mbps ~35 fps 95.49778054


5759 frames, 29.97 fps, C2Q Q6600@2.4 GHz

x264 r1995
ffmpeg SVN-r25870-Sherpya
xvid_encraw (31-08-2007 build)
lagarith v1.3.25
HCEnc v0.26

------------------------------------------------
(1)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --ssim --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mkv"

------------------------------------------------
(2)
ffmpeg.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -y -b 50000k "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.webm"

------------------------------------------------
(3)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 100000 --vbv-bufsize 20000 --vbv-maxrate 100000 --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.mkv"

------------------------------------------------
(4)
xvid_encraw.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -max_bframes 0 -cq 1 -quality 1 -vhqmode 0 -qmatrix "c:\Archivos de programa\K-Lite Codec Pack\Tools\Xvid_Quant_Matrices\Flat 8-16.xcm" -interlaced 2 -qtype 1 -threads 4 -o "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.avi"

------------------------------------------------
(5)
Lagarith (lossless, used as reference)

------------------------------------------------
(6)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --crf 8 --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.264"

------------------------------------------------
(7)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --crf 8 --aq-mode 2 --no-psy --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.264"

------------------------------------------------
(8)
HCEnc

*INFILE c:\documents and settings\alex-kid\mis documentos\mis vídeos\test.avs
*OUTFILE C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.m2v
*DBPATH C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\HD EDIT
*LLPATH C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\HD EDIT
*MAXBITRATE 120000
*FRAMES 0 5758
*PROFILE best
*ASPECT 1:1
*GOP 1 0
*CQ_MAXBITRATE 1.000
*AQ 3
*DC_PREC 11
*INTERLACED
*TFF
*CLOSEDGOPS
*FRAMELOG
*INTRAVLC 2
*MATRIX mpeg
*LUMGAIN 3

------------------------------------------------
(9)
ffmpeg -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -vcodec dnxhd -yuv420p -flags -ildct -threads 4 -b 145000k -an output.mov "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mov"

NOTE: ffmpeg encoded the file as yuv422p (did not recognize yuv420p flag), so the ssim script was modified as follows:

clip1=avisource("test.avs")
clip2=ffvideosource("GALV.mov", colorspace="yv12")

ssim(clip1,clip2,"results.csv","averageSSIM.txt")

------------------------------------------------
(10)
ffmpeg -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -intra -y -flags -ildct -threads 4 -vcodec libvpx -b 50000k -an "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\output.webm"

------------------------------------------------
(11)
XviD 1.3.2, EQM V3EHR, VHQ 0, MSP 6, CQ2, Keyframe Interval=1, slice-based multithread mode and Virtualdub 1.9 (Q6600@3.2Ghz ... lagarith running at ~40fps).


I haven't had the time to do some more testing, but I think that these ones should be enough. It seems that x264 is the codec to use for intermediate encoding (at least the free one), considering bitrate, speed and quality.

If anyone wants to continue testing, this is the link (http://www.mediafire.com/?q7ibeg450am9pwi) to the capture file I used.

Saludos

By ALEX-KID

[henryho_hk]

Can u describe more clearly the sequence and the programs involved? e.g. what program will be used "to edit to make it highlights"?

I am thinking if you can use "makeavis.exe" from ffdshow32 to make a AVI wrapper over the AVS script which decodes the HD capture file. (btw, it looks more like 1080@30p)

[Alex-Kid]

@henryho_hk

Without intermediate codec:

capture.ts → DGAVCIndexDI → capture.dgi → capture.avs:
dgsource("capture.dgi")
(...) #trims, dissolves, etc.
↓
x264 capture.avs capture.264 [final encoding]

------------------------------
With intermediate codec:

capture.ts → DGAVCIndexDI → capture.dgi → capture.avs:
dgsource("capture.dgi")
(...) #trims to reduce file size
↓
intermediate-codec-cli capture.avs capture.ext [intermediate encoding]
↓
intermediate.avs:
avi-/directshow-/other-/source("capture.ext")
(...) #trims, dissolves, etc.
↓
x264 capture.avs capture.264 [final encoding]

Is that what you wanted?

[Blue_MiSfit]

x264 is about as good as it gets, provided you're okay with 4:2:0. If you aren't then you must look elsewhere.

10 bit works, but decoding hasn't quite caught up to 8 bit :)

ProRes and DNxHD are probably the best options available for this exact workflow to be honest... Not that they're always practical!

[henryho_hk]

um... sorry that I am getting lost... but what is the problem without an intermediate file? you can "import()" avs scripts of "stage 1" into "stage 2". is there something being done not using avs script?

[Alex-Kid]

@henryho_hk: I forgot a step in the workflow, now it's added...

Intermediate file should help me to avoid crashes (due to many trims and dissolves, remember I use DGAVCDecDI) and to reduce file size.

[Alex-Kid]

Added two more tests to the table above (ffmpeg DNxHD and VP8 intra).

About decoding performance: I don't know how to measure it. But the only ones that give me some problem on real time decoding were VP8 and DNxHD.

About the use of PSNR: I didn't find any avisynth filter or any other way to use it.

I learned a lot cli with this post, especially ffmpeg. Thanks everybody :).

Saludos

By ALEX-KID

[kolak]

The best (fastest and most scalable quality ) intermediate codec is Canopus HQX, but expensive.

DNxHD in best mode has PSNR about 49-53dB.


Andrew

[Atak_Snajpera]

For me x264 at 100mbps is optimal. Fast encoding and fast decoding and it is free :)

[henryho_hk]

With XviD 1.3.2, EQM V3EHR (http://forum.doom9.org/showthread.php?p=552539), VHQ 0, MSP 6, CQ2, Keyframe Interval=1, slice-based multithread mode and Virtualdub 1.9, it runs at ~35fps giving 103Mbps with SSIM=95.49778054 (Q6600@3.2Ghz ... lagarith running at ~40fps).

xvid_encraw is not multithread-friendly at all.

[Atak_Snajpera]

With XviD 1.3.2, EQM V3EHR, VHQ 0, MSP 6, CQ2, Keyframe Interval=1, slice-based multithread mode and Virtualdub 1.9, it runs at ~35fps giving 103Mbps
Does XviD support interlaced encoding (MBAFF) ? I have similar results with x264 --preset superfast --tune fastdecode (~32 fps on Q6600@3Ghz). Lagarith tends to crash in Sony Vegas so I prefer format like mp4 (x264+aac) which could be natively decoded by Vegas without external decoders.

[kieranrk]

Well this is the last info from the tests:

CLI CODEC/CODER BITRATE SPEED(fps) SSIM(v0.23)
---------------------------------------------------------------
(1) x264 50 mbps 36.88 fps 88.66771698
(2) VP8(ffmpeg) 24 mbps ~2 fps 85.55319214
(3) x264 100 mbps 33.23 fps 95.32942963
(4) xvid_encraw 237 mbps 9.93 fps 96.94023053
(5) lagarith 235 mbps 35.30 fps 100.00000954
(6) x264 115 mbps 32.62 fps 96.51400277
(7) x264 111 mbps 33.02 fps 96.45086489
(8) HCEnc 102 mbps 2.20 fps 94.13687145
(9) DNxHD(ffmpeg) 145 mbps 13.55 fps 95.35936372
(10) VP8(ffmpeg) 84 mbps 4.38 fps 93.42168415


5759 frames, 29.97 fps, C2Q Q6600@2.4 GHz

x264 r1995
ffmpeg SVN-r25870-Sherpya
xvid_encraw (31-08-2007 build)
lagarith v1.3.25
HCEnc v0.26

------------------------------------------------
(1)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 50000 --vbv-bufsize 5000 --vbv-maxrate 50000 --preset superfast --tune fastdecode --keyint 1 --ssim --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mkv"

------------------------------------------------
(2)
ffmpeg.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -y -b 50000k "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.webm"

------------------------------------------------
(3)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --bitrate 100000 --vbv-bufsize 20000 --vbv-maxrate 100000 --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.mkv"

------------------------------------------------
(4)
xvid_encraw.exe -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -max_bframes 0 -cq 1 -quality 1 -vhqmode 0 -qmatrix "c:\Archivos de programa\K-Lite Codec Pack\Tools\Xvid_Quant_Matrices\Flat 8-16.xcm" -interlaced 2 -qtype 1 -threads 4 -o "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.avi"

------------------------------------------------
(5)
Lagarith (lossless, used as reference)

------------------------------------------------
(6)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --crf 8 --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.264"

------------------------------------------------
(7)
x264.exe "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" --tff --crf 8 --aq-mode 2 --no-psy --preset superfast --tune fastdecode --keyint 1 --output "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV100.264"

------------------------------------------------
(8)
HCEnc

*INFILE c:\documents and settings\alex-kid\mis documentos\mis vídeos\test.avs
*OUTFILE C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.m2v
*DBPATH C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\HD EDIT
*LLPATH C:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\HD EDIT
*MAXBITRATE 120000
*FRAMES 0 5758
*PROFILE best
*ASPECT 1:1
*GOP 1 0
*CQ_MAXBITRATE 1.000
*AQ 3
*DC_PREC 11
*INTERLACED
*TFF
*CLOSEDGOPS
*FRAMELOG
*INTRAVLC 2
*MATRIX mpeg
*LUMGAIN 3

------------------------------------------------
(9)
ffmpeg -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -vcodec dnxhd -yuv420p -flags -ildct -threads 4 -b 145000k -an output.mov "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\GALV.mov"

NOTE: ffmpeg encoded the file as yuv422p (did not recognize yuv420p flag), so the ssim script was modified as follows:

clip1=avisource("test.avs")
clip2=ffvideosource("GALV.mov", colorspace="yv12")

ssim(clip1,clip2,"results.csv","averageSSIM.txt")

------------------------------------------------
(10)
ffmpeg -i "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\test.avs" -intra -y -flags -ildct -threads 4 -vcodec libvpx -b 50000k -an "c:\Documents and Settings\Alex-Kid\Mis documentos\Mis vídeos\output.webm"

I haven't had the time to do some more testing, but I think that these ones should be enough. It seems that x264 is the codec to use for intermediate encoding (at least the free one), considering bitrate, speed and quality.

If anyone wants to continue testing, this is the link (http://www.mediafire.com/?q7ibeg450am9pwi) to the capture file I used.

Saludos

By ALEX-KID

x264 should also have --tune ssim.

[vivan]

Atak_Snajpera,
Lagarith... tends to crash is Vegas? о_О
Most of our amv-makers are using it as intermediate codec for editing, so it's recommended in some manuals. Also NLEs have problems with compressed video that leads to screwing up complex projects... So stability is something like: Uncompressed > Lagarith / UT video > AVC.
Anyway I could recommend UT video instead of Lagarith, since Lagarith utilises only 2 threads, so UT video is 2 times faster (or 3 times on 6-core CPU, up to 90 fps encoding/decoding on my i7 970).

p.s. omg, please don't quote this huge table, first sentence is enough.

[nm]

Lagarith... tends to crash is Vegas? о_О
Most of our amv-makers are using it as intermediate codec for editing, so it's recommended in some manuals.

In my reality Lagarith is notorious for being buggy, slow and tied to one platform. The FFmpeg decoder implementation is a slight relieve on the last point though.

Also NLEs have problems with compressed video that leads to screwing up complex projects... So stability is something like: Uncompressed > Lagarith / UT video > AVC.

You probably mean that NLEs have problems with interframe video. Try encoding AVC with keyframes only as Alex-Kid has been doing here.

[Atak_Snajpera]

@vivan
Lagarith's 235 Mbps (~30 MB/s) is to much for me. Imagine that you have to work on few streams at the same time (PIP). I don't have money for big SSD yet.

[kolak]

Cineform or Canpous HQX would be good for you than :)
They are very easy to decode (very well threaded) and at 150Mbit have very good quality.

x264 at 100Mbit is great, but still not that easy to cope for NLE.

Edius exports HQX 10x faster than RT for full HD with simple 4 disks raid :)


Andrew

[kieranrk]

x264 at 100Mbit is great, but still not that easy to cope for NLE.


x264 decoding with sliced threads would probably be ok.

[henryho_hk]

Does XviD support interlaced encoding (MBAFF) ?

It supports Progressive, TFF and BFF. Easily selectable via xvid_encraw (multithread unfriendly) and VFW GUI (via Virtualdub which is multithread friendly, fully unleashing the new sliced-threading).

Note that the new sliced-threading may have compatibility problems with hardware standalone players, but there is no need to worry if used as an intermediate codec.

[Alex-Kid]

xvid_encraw is not multithread-friendly at all.
I didn't note that, but now that you have mentioned, I don't remember any option related to multi-threading. Then I have to assume that MeGUI didn't have multithreading support either.

Table updated (http://forum.doom9.org/showthread.php?p=1510777#post1510777) with results from henryho_hk (post (http://forum.doom9.org/showthread.php?p=1511804#post1511804)). Just to keep things in order.

[henryho_hk]

xvid_encraw has "-threads" option (squid80's 1.2 version is better threaded) and the newer 1.3 versions has the "-slices" option. "-slices" should scale quite well but I find it much better realized in VirtualDub via VFW.

Concerning the speed, I suggest adjusting it by prorata as ~30.89fps = ~35fps / ~40 * 35.3

[kolak]

x264 decoding with sliced threads would probably be ok.

Yes- for simple timelines it works fine, but once you make it more complicated (or use multicam) it starts showing problems.

It's still more difficult than all intermediate codecs.
For crucial work it needs 150Mbit or more, so that's make it even more difficult.


Andrew

[nm]

Yes- for simple timelines it works fine, but once you make it more complicated (or use multicam) it starts showing problems.

It's still more difficult than all intermediate codecs.

Bad decoders and demuxers aside, I don't see a format-related issue that would make it more difficult as long as you only have intraframe video.

[kolak]

It just complicity of AVC- all intermediate codecs are much easier to decode.

Edius export for this sample to HQX (about 120Mbit)= 145fps using 12 cores at 100% (all CPU processing).

There are different implementation of the decoders, but we're talking about using AVC as an intermediate format- so it has to work in NLEs.

In Edius to play this sample CPU=7%, for HQX file=4%.
Not sure how good is Edius AVC decoder, but I have not seen better NLE for handling AVC files.

Going to encode it to AVC-I using posted cmd and check playback.

AVC-I CPU=6%, but seeking is much better.

Andrew

[Atak_Snajpera]

@kolak
http://forum.doom9.org/showthread.php?p=1508272#post1508272

[kolak]

@kolak
http://forum.doom9.org/showthread.php?p=1508272#post1508272


Decoding speed?

To have fast decoder is one thing, but to have it working inside NLE with timeline, seeking is another.


Andrew

[Atak_Snajpera]

What is your problem if we are talking about AVC-INTRA (each frame is independent) in mp4 container?

[kolak]

Yes- I know.

Not sure what are you talking about:)

I've encoded this sample to AVC-I using posted cmd line. I had 80fps using 60% of 12 cores. It may maxing my HDD speed.

update- it was maxing HDD- encodign from Canopus HQ gives about 180fps (6x faster than RT) and 70% of all 24threads. Should it be 100%?


Andrew

[Atak_Snajpera]

Have you increased number of decoding and encoding threads?

[kolak]

Have you increased number of decoding and encoding threads?

Encodign from uncompressed.

One note- people encode to AVC-I with x264, but this streams are way out of Panasonic AVC-I spec as far as I can see.

If it's just AVC with I frames only than fine, but it has nothing to do with AVC-I spec.

Andrew

[Atak_Snajpera]

update- it was maxing HDD- encodign from Canopus HQ gives about 180fps (6x faster than RT) and 70% of all 24threads. Should it be 100%?
Are you sure that your hdd is not a bottleneck again? Increase number of encoding threads.

[nm]

One note- people encode to AVC-I with x264, but this streams are way out of Panasonic AVC-I spec as far as I can see.

Maybe some people encode to AVC-I, but you are the only one who has mentioned it in this thread so far. There's no reason to care about Panasonic specs when the stream is used internally and the tools aren't limited to AVC-I.

[kolak]

That's the whole point- you need compatibility with AVID and rest of Pro software if you want x264 being used commercially.

It should be also 4:2:2 as intermediate codec.

For home use you can do whatever you want. You never have good quality source- best is ripped BD, so it's bit pointless anyway.

Andrew

[Atak_Snajpera]

Does so called pro software support mp4 container as input? BTW. I'm not "PRO" so for my AVCHD recordings x264 Intra 100 Mbps is perfect. Small size + very high quality + very fast decoding speed + natively decoded by Sony Vegas + it' free. Why should I use something else.

It should be also 4:2:2 as intermediate codec.
I always thought that x264 10 bit does that.

[kolak]

Are you sure that your hdd is not a bottleneck again? Increase number of encoding threads.

No- it can do 450MB/sec. Canopus HQ file is about 150Mbit.
It can be related to decoding in avisynth (I read it through mt mode 2). I know that it works 2x as fast in Edius- decoding/encoding for HQ.

Andrew

[kolak]

Does so called pro software support mp4 container as input?

Depends which- some do. Most likely you need MXF.

Andrew

[kolak]

Does so called pro software support mp4 container as input? BTW. I'm not "PRO" so for my AVCHD recordings x264 Intra 100 Mbps is perfect. Small size + very high quality + very fast decoding speed + natively decoded by Sony Vegas + it' free. Why should I use something else.


I always thought that x264 10 bit does that.

Exactly, but world does not end only on your needs :)

Yes- but posted cmd line is for normal 8bit encoding. 10bit 4:2:2 would be even slower for decoding.

That's why I said that HQX is great- quality can be set from offiline to higher than HDCAM-SR and all extreamly fast for processing. Not free, but also not very expensive.

There is no specially designed, free intermediate codec (except DNxHD- but it's quite limited)- only paid ones. We have amazing lossless ones- like UtVideo, but someone would like lower bitrate (for small loss in quality).


Andrew

[kieranrk]

That's why I said that HQX is great- quality can be set from offiline to higher than HDCAM-SR and all extreamly fast for processing. Not free, but also not very expensive.


You could write the MPEG-4 Studio profile data stored on HDCAM-SR straight to MXF if you wanted :)

I don't see what the problem is with Intra H.264 as an intermediate codec, just as long as there's good 10-bit 4:2:2 support and possible CABAC turned off and maybe only limited deblocking. With enough slices it would be fast to decode. "Pro" intra codecs aren't much different, but the manufacturers of editing tools can control the market.

[kolak]

No problem except complex decoding-more complex than all intermediate codecs for the price of smaller size. These days storage is cheap, so I prefer easier decoding.

AVC-I 100 is CAVLC by Panasonic standard, but it's not really transparent at 100Mbit (you need something like 150Mbit).


Andrew

[kolak]

You could write the MPEG-4 Studio profile data stored on HDCAM-SR straight to MXF if you wanted :)

I don't see what the problem is with Intra H.264 as an intermediate codec, just as long as there's good 10-bit 4:2:2 support and possible CABAC turned off and maybe only limited deblocking. With enough slices it would be fast to decode. "Pro" intra codecs aren't much different, but the manufacturers of editing tools can control the market.

Sony had beta decoder for FCP but what now- buhaha?
Apple decided to kill FCP, so Sony will probably move away from releasing it.

Andrew

[Atak_Snajpera]

AVC-I 100 is CAVLC by Panasonic standard, but it's not really transparent at 100Mbit (you need something like 150Mbit).
This only shows that their encoder is not very efficient. 100 Mbps should be enough for 1920x1080@50i.

100 Mbps / 8 = 12,5 MB/s
12,5 / 25 fps (PAL 50i) = 0,5 MB per frame.

This is even enough for old M-JPEG compression. (Quality ~95% format 4:4:4)

http://www.picamatic.com/show/2011/07/08/03/27/7677784_bigthumb.png (http://www.picamatic.com/view/7677784_Untitled-1/)

[kolak]

This only shows that their encoder is not very efficient. 100 Mbps should be enough for 1920x1080@50i.

100 Mbps / 8 = 12,5 MB/s
12,5 / 25 fps (PAL 50i) = 0,5 MB per frame.

This is even enough for old M-JPEG compression. (Quality ~95% format 4:4:4)

http://www.picamatic.com/show/2011/07/08/03/27/7677784_bigthumb.png (http://www.picamatic.com/view/7677784_Untitled-1/)


Is that PSNR 50+?

Avatar is very clean source shot with small depth of field- in this case 100Mbit may be quite ok, but this is not the best reference source.

Andrew

[Atak_Snajpera]

Ok. Now something more detailed. Photo made by Nikkon D3S downloaded from http://www.dpreview.com/galleries/reviewsamples/photos/141947/sample-44?inalbum=nikon-d3s-review-samples
Then resampled and cropped to 1920x1080

PNG
http://www.mediafire.com/?utm0btipanw4plt

JPG Quality at 85% (4:2:2)
http://www.mediafire.com/?afgze6mfw29w107

Comparison
http://www.picamatic.com/show/2011/07/08/06/20/7677981_bigthumb.png (http://www.picamatic.com/view/7677981_Untitled-2/)


Don't forget that we are talking about old jpeg compression . I'm sure that highly optimized H.264 (x264) produces even better results.

[kolak]

Ok. Now something more detailed. Photo made by Nikkon D3S downloaded from http://www.dpreview.com/galleries/reviewsamples/photos/141947/sample-44?inalbum=nikon-d3s-review-samples
Then resampled and cropped to 1920x1080

PNG
http://www.mediafire.com/?utm0btipanw4plt

JPG Quality at 85% (4:2:2)
http://www.mediafire.com/?afgze6mfw29w107

Comparison
http://www.picamatic.com/show/2011/07/08/06/20/7677981_bigthumb.png (http://www.picamatic.com/view/7677981_Untitled-2/)


Don't forget that we are talking about old jpeg compression . I'm sure that highly optimized H.264 (x264) produces even better results.

Just by looking I don't think it's close to 50dB PSNR. If you can see differences on 1:1 size than it's not good enough as intermediate codec.
With all of the existing ones you need to zoom 3x or more to see differences.

Andrew

[Atak_Snajpera]

If you can see differences on 1:1 size than it's not good enough as intermediate codec.
Have you downloaded my files or you just checked zoomed comparison? Frankly I can't see difference on 1:1 samples. Even at 200% image degradation is not visible. I really don't understand why you claim that more efficient AVC-Intra 100 is not good enough if even older jpeg compression gives very good results.

Just by looking I don't think it's close to 50dB PSNR
PSNR is not good way to measure quality. Human eyes are the best ;)

[kolak]

I've checked AVC-I (Panasonic encoder) few times and you can see differences on 1:1 frame on many sources. It's good enough for TV, documentaries, but not for crucial work- movies, grading, etc.

PSNR is just a metric- never as good as human eye :)

AVC-I is most efficient of all of them, I don't complain- just needs more than 100Mbit for high quality masters.

Looked at original files- there is loss in sharpness and big problems on red- not good enough as intermediate file. You can see differences on 1:1- no need for zoom.
Good BD encoding can achieve such a transparency- so you need better quality as a master:)


Andrew

[Atak_Snajpera]

Let's forget about crappy Panasonic encoder and better focus on x264 INTRA efficiency.
Again but this time I added x264

PNG
http://www.mediafire.com/?utm0btipanw4plt

JPG Quality at 85% (4:2:2)
http://www.mediafire.com/?afgze6mfw29w107

x264 --preset superfast --tune fast decode (4:2:0) mp4 file size = 516 KB
http://www.mediafire.com/?spr2vvvkmk412sz

Comparison in Corel PhotoPaint (zoomed 4 times!)
http://www.picamatic.com/show/2011/07/08/08/00/7678176_bigthumb.png (http://www.picamatic.com/view/7678176_Untitledpng/)

[kolak]

Looks ok- but 2x zoom already reveals quite big differences.
There is also 601/709 color space issue between source and x264-I, so it's quite difficult to judge.
It's quite away from intermediate codecs. It confirms what I have said- you need 150Mbit+, but this is still way better than other codecs. AVC-I is probably about 1.5x more efficient.


Andrew

[Atak_Snajpera]

Looks ok- but 2x zoom already reveals quite big differences.
show me where.

There is also 601/709 color space issue between source and x264-I, so it's quite difficult to judge.
No wonder because source is 24 bit RGB.

It's quite away from intermediate codecs.
I don't agree. Personally I doubt that your camera will capture that kind of details like very expensive Nikon D3S. Moving footage is not that sharp. 100 Mbps x264-I is enough. Period.

Another test
park_joy_1080p.y4m (1920x1080@50p) ~500 KB per frame

x264_x64.exe --bitrate 200000 --preset superfast --tune fastdecode --keyint 1 --nal-hrd vbr --vbv-bufsize 5000 --vbv-maxrate 200000 --ssim -o C:\temp\AVC-INTRA.mp4 E:\_Video_Sample\y4m\park_joy_1080p.y4m
y4m [info]: 1920x1080p 1:1 @ 50/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1
x264 [info]: frame I:500 Avg QP:25.25 size:491982
x264 [info]: mb I I16..4: 3.4% 26.5% 70.1%
x264 [info]: 8x8 transform intra:26.5%
x264 [info]: coded y,uvDC,uvAC intra: 99.1% 95.7% 85.7%
x264 [info]: i16 v,h,dc,p: 6% 6% 61% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 16% 24% 5% 8% 6% 7% 7% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 17% 17% 6% 11% 6% 8% 7% 14%
x264 [info]: i8c dc,h,v,p: 52% 21% 15% 11%
x264 [info]: SSIM Mean Y:0.9653102 (14.598db)
x264 [info]: kb/s:196792.66

encoded 500 frames, 48.27 fps, 196793.21 kb/s

[kieranrk]

needs --tune ssim

[Atak_Snajpera]

needs --tune ssim
It does not change much. Instead of 0.965 I got 0.967.

[mp3dom]

show me where.
At original zoom:
The AVC have red color bleeding on the red mistletoe dots (more than the results on jpeg) and the darker leaf gets some visible loss. Also the red dots itself have a 'washy' reds compared to the original and jpeg version.

At 2x zoom the differences are even more noticeable.

Considering that this is an 'intermediate' pass so you need to do another step of compression, the quality loss is too much for my taste. I prefer to go all the way with a lossless codec. Today hard disk space is cheap and RAID systems are even cheaper. An HD "Canopus Lossless" file is playable/editable in realtime in a non-RAID system with an NLE like Edius (as its a native codec for that NLE). With RAID the performances are even better. Gets imported without waiting anything, it can be printed to a deck without rendering the whole timeline, it's a 4:2:2 codec and gets decoded to YUY2 in AviSynth without any plugin (you only need the codec installed). Personally I'm happy with this workflow. For only backup purpose I prefer UTVideo.

[Atak_Snajpera]

My current workflow looks like this
AVCHD -> AVC-Intra 100 (x264 --preset superfast --tune fastdecode --tff) -> Sony Vegas -> UTVideo

Like i said before Big SSD (100GB+) are to expensive for me at the moment. Also I'm not going to invest in RAID because SSD is alot better (up to 480MB + ultra fast random access + SILENCE)

[kolak]

Your needs are totally different than main- that's it:)
Quite often quality of this what you call "intermediate format" I have on BD disc, so I need to start with something much better.

Canopus codecs are great and when you use Edius than it's unbeatable workflow.


Andrew

[henryho_hk]

Like i said before Big SSD (100GB+) are to expensive for me at the moment.

Yup, SSD is both expensive and addictive. :devil:

[smok3]

Apple decided to kill FCP, so Sony will probably move away from releasing it.

what do you mean?
http://www.apple.com/finalcutpro/

edit:
p.s. ok i see, quote from a user:
No XML,
No EDL,
No OMF,
No External Monitoring,
No Multiclipping,
No RED Support.
No Log & Capture

[kolak]

what do you mean?
http://www.apple.com/finalcutpro/

edit:
p.s. ok i see, quote from a user:

New FCP X has nothing to do with old FCP.
It should never been called FCP.
Apple also recalled all existing licenses of FCP 7-editors/companies are going crazy :)

Welcome to Apple World- you do it the way how Steve says- not how you like it:)


Andrew

[Sagittaire]

No problem except complex decoding-more complex than all intermediate codecs for the price of smaller size. These days storage is cheap, so I prefer easier decoding.

AVC-I 100 is CAVLC by Panasonic standard, but it's not really transparent at 100Mbit (you need something like 150Mbit).


Andrew

100 Mbits is not enough ... ?

It's certainely not transparent with loop in particular condition because lossy will be always lossy. Anyway I doubt seriousely that you can see compression artefact at this quality. I doubt seriousely that you can say "this is original and this is lossy compression". 100 Mbps for AVC at 100 Mbps is by far enough for original master ... simply because production will be more destructive and by far ...

[kolak]

Try it:)

AVC-I is great in many areas TVs, news, documentary, etc), but not for feature movies, grading or as BD master.

I don't have to doubt- I've tried it.

Intermediate codec should be as good as HDCAM-SR- that's the whole idea of it. AVC-I at 100mbit is not as good, by quite a lot.


Andrew

[poisondeathray]

kolak is correct; Panasonic's AVC-I 100 isn't good enough for mastering or high end acquisition. It probably needs 150-200Mb/s.

People who use cameras with AVC-I for TV shows (e.g. HPX3700), use external recorder because AVCI-100 isn't good enough

You can see artifacts and detail loss with naked eye (unzoomed) compared to simultaneous uncompressed recording, or even compared to ProResHQ

[kolak]

Yes- about 1.3-1.5x less bitrate than other intermediate codecs, but 100Mbit is not enough.
In the same time decoding is more complicated and these days (with cheap storage) it's not worth it.

Andrew

[poisondeathray]

Like you said, it's fine for some purposes, but not ok for others... But it's not even in the category of "visually lossless"

There have been rumors of an "AVC-Ultra" by Panasonic , a 200Mbps 4:2:2 10-bit variant, but it never got released .

[kolak]

All of the intermediate codecs are good and have about the same efficiency- ProRes, DNxHD, Cineform and Canopus HQX- all great and very fast, but HQX in Edius is unbeatable:)


Andrew

[henryho_hk]

but HQX in Edius is unbeatable:)

Any subjective measurement?

[kolak]

Any subjective measurement?

In what terms? Speed is unmatched by any other NLE+their native codec. AVID+DNxHD is a joke in comparison :)
Quality- at highest setting it's almost lossless. You need to zoom 5x to see single pixel changes. PSNR 55dB+.

It's like other intermediate codecs, but more scalable and performance is amazing. You can do 4K color grading in RT on modern machine.

UtVideo is also very fast (and lossless), but 8bit only.


Andrew

[mp3dom]

kolak, since HQX is a 10bit codec, do you know if the conversion to 8bit (for final encoding for example) is forced to be done inside Edius or is there a way to convert it to 8bit outsite the NLE? With proper codec installed I think VDub or AviSynth see it as a 8bit codec (truncating the 2 bits) or am I wrong?

[kolak]

Yes- no access to 10bit in HQX outside Edius at this point. It has been passed to GV and they confirmed it. It may change soon. HQX decoder (outside Edius) has no higher than 8bit output pin for now.


Andrew

[kolak]

Here is some white paper:

http://www.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf

It looks "real"- no cheating- some text is marketing crap, but graphs seams to be fine.
Advantage of HQX is that you have huge range of quality- from 25:1 to nearly lossless. Other codecs are more strict, but efficiency is basically the same.


Andrew