Recommended intermediate HD codec [Archive] - Page 2

View Full Version : Recommended intermediate HD codec

Pages : 1 [2] 3

Alex-Kid

2nd July 2011, 00:06

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

4th July 2011, 17:30

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

4th July 2011, 19:29

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

henryho_hk

5th July 2011, 17:17

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

6th July 2011, 11:14

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

6th July 2011, 12:31

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

6th July 2011, 14:56

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.

6th July 2011, 15:37

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

6th July 2011, 15:43

@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

6th July 2011, 22:21

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

6th July 2011, 23:24

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

7th July 2011, 01:09

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

7th July 2011, 05:48

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

7th July 2011, 07:18

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

7th July 2011, 10:10

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

7th July 2011, 10:20

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

7th July 2011, 11:01

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

7th July 2011, 11:18

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

kolak

7th July 2011, 11:32

@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

7th July 2011, 11:44

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

kolak

7th July 2011, 11:50

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

7th July 2011, 11:51

Have you increased number of decoding and encoding threads?

kolak

7th July 2011, 11:57

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

7th July 2011, 12:22

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.

7th July 2011, 12:24

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

7th July 2011, 14:25

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

7th July 2011, 14:29

kolak

7th July 2011, 14:31

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

7th July 2011, 14:31

Does so called pro software support mp4 container as input?

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

Andrew

kolak

7th July 2011, 14:39

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

7th July 2011, 15:58

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

7th July 2011, 22:18

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

7th July 2011, 22:20

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

8th July 2011, 12:27

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

8th July 2011, 14:05

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

8th July 2011, 15:20

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

8th July 2011, 16:18

Atak_Snajpera

8th July 2011, 16:36

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

8th July 2011, 16:38

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

8th July 2011, 17:00

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

8th July 2011, 19:23

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

9th July 2011, 11:23

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

9th July 2011, 13:09

needs --tune ssim

Atak_Snajpera

9th July 2011, 13:39

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

mp3dom

9th July 2011, 13:52

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

9th July 2011, 14:01

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

9th July 2011, 21:37

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

12th July 2011, 05:52

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

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

smok3

12th July 2011, 07:23

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

12th July 2011, 13:57

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