Archiving mov (lossless)

[Jan Catrysse]

We would like to archive our mov files (the output from the HD camera).

I've tried ffv1 but the output file is bigger than the input :-)
mencoder -nosound -ovc lavc -lavcopts vcodec=ffv1:vstrict=-2:coder=1:context=1 uncompressed.mov -o compressed.avi

Those are the specs of the MOV file is used for testing, 76MB, 24seconds (ffmpeg -i uncompressed.mov):
Quicktime/MOV file format detected.
[mov] Video stream found, -vid 0
[mov] Audio stream found, -aid 1
VIDEO: [hdv5] 1280x720 24bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:7 fourcc:0x35766468 size:1280x720 fps:25.00 ftime:=0.0400

We are using mencoder, ffmpeg, etc... under FreeBSD 7. I have also tried bzip2 but that only yields +/- 20% compression rate... 50% minimum would be desireable. Time and computing power is not really an issue, being lossless and small is.

A big thanks in advance, I am quitte new to all this...
Jan

[SeeMoreDigital]

What audio/video format does your HD camcorder utilise?

[nm]

We are using mencoder, ffmpeg, etc... under FreeBSD 7. I have also tried bzip2 but that only yields +/- 20% compression rate... 50% minimum would be desireable.
The source MOV is already MPEG-2-compressed, so you won't get more compression with any lossless video codec. A 20 % compression rate with bzip2 is actually surprisingly good, but you might be able to squeeze it a few percents more with the best methods. An external lossless file compressor like bzip2 is the only practical way to make those files smaller losslessly.

If you are satisfied with visually transparent lossy encoding, I'd go for H.264. There's this nice and efficient multiplatform encoder called x264 that you can use through MEncoder and ffmpeg too :) You could probably compress the video to one third of the original size without losing anything of value.

[Jan Catrysse]

What audio/video format does your HD camcorder utilise?

We are using JVC GY-HD110E and GY-HD200E camcorders, the output (rax HD I suppose) is transfered by firewire to a DR-HD100E Hard disk recorder (who compresses the signal). I can choose between: RawDV, AVI Type 1, AVI Type 2, Matrox AVI, Canopus AVI, QuickTime, Pinnacle AVI and AVID DV OMF; 720p MPEG2 ts. (.m2t)

Currently we use Quicktime, AVI results are just bad... I didn't try the other ones...

If you are satisfied with visually transparent lossy encoding, I'd go for H.264

What mencoder commanline should I use for optimum quality ?

Thanks

[smok3]

bit offtopic, but should be usefull: the hd recorder does not compress anything afaik, it just stores the data (packs into different containers), you can't use avi for hdv thought, but mpeg2 ts would be an option as well.

back on topic: i wouldn't recompress, just store them as they are.

p.s. the surprising bzip2 success is probably due to the fact that HDV is CBR?

[nm]

What mencoder commanline should I use for optimum quality ?
Well, to encode with x264, make sure that you compile MEncoder SVN with the latest x264 git version (git clone git://git.videolan.org/x264.git). That way you'll get VAQ, which should increase quality/bitrate compared to no adaptive quantization. Try x264 with crf=18 or perhaps crf=16. Then most of the other encoding options just decrease (or increase) the output size while keeping quality at approximately the same level.

For command-line examples, take a look at a test script (http://www.cs.helsinki.fi/u/mikkila/video/hdvtest/) that I wrote when encoding samples for a closely related thread (http://forum.doom9.org/showthread.php?p=1117546#post1117546). Note that some of the examples are for interlaced sources.

For full descriptions of all encoding parameters, see the MPlayer/MEncoder man page and the HTML documentation: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

If most of the videos will be edited later, I'd also suggest just keeping the originals until then.

[Jan Catrysse]

So if I understand it well, I won't be able to compress much better than the 20% bzip2 ?

Damn ;-)

If any ideas come to mind feel free to help me out...

A big thanks for the info, I am getting wiser by the day. All that container, codec, video stuff is very interesting...

Cya

[SeeMoreDigital]

Just read your cameras spec (http://www.jvcpro.co.uk/item?item=GY-HD110E)

VIDEO
HDV
Video signal recording format: HDV720p format, 8-bit, 19.7 Mbps
Compression: MPEG-2 video (profile & level: MP@H-14)

DV
Video signal recording format: DV format, 8-bit, 25 Mbps
Compression: DV compression 4:2:0

AUDIO:
HDV
Audio signal recording format: MPEG1 Audio Layer II

DV
Audio signal recording format: 16-bit (locked audio), 48 kHz PCM for 2 channels

Cassette type: Mini DV
Tape speed: 18.8 mm/sec.
Record/play time: 63 minutes (with an M-DV63PROHD tape)


Personally I would not re-encode either of above source formats to a lossless format.... The resulting lossless encodes would be far bigger data-wise compared to your sources.


Cheers

[Leak]

I can choose between: RawDV, AVI Type 1, AVI Type 2, Matrox AVI, Canopus AVI, QuickTime, Pinnacle AVI and AVID DV OMF; 720p MPEG2 ts. (.m2t)
Those are all just different container formats for the same compressed video stream - since it seems to be plain MPEG2 I'd go for the MPEG2 transport stream which is the most basic one, and MPEG2 is probably the easiest (and most standard) format to work with anyway.

Lossless video codecs of course take the decoded video and compress it frame for frame, so no matter which one you choose the result will be several times bigger than the MPEG2 video.

If you want better data compression than bzip2 for your MPEG2 files you could give 7zip a try; it usually squeezes a few more percent out of files you throw at it...

np: Underworld - MoMove (AHundredDaysOff)

[foxyshadis]

There's always a chance that remuxing alone may save most of the space that bzip2 does, if the camera inserts a lot of padding at the container level. If the padding is at the bitstream level, it can be a bit more painful to remove it.

[Jan Catrysse]

Indeed the camera outputs the info (MPEG-2 video (profile & level: MP@H-14)) and the HDD is putting it into the container. I should have seen this myself.

There's always a chance that remuxing alone may save most of the space that bzip2 does, if the camera inserts a lot of padding at the container level. If the padding is at the bitstream level, it can be a bit more painful to remove it.

Probably this is a trivial question, but what commandline FreeBSD (or linux) tool should I use to demux my MOV file? I see things like mp4box, avidemux, ... but that doesn't seem to be the thing I need.

In the mean time I'm doing some H.264 testing. I've tried it on a Mac workstation with Final Cut and the resulting quality s**ks... Than again, I only have some basic settings and the output size is really small. I will do some testing with mencoder with optimized settings.

I'll keep you posted.

Regs,
Jan

[Jan Catrysse]

If you want better data compression than bzip2 for your MPEG2 files you could give 7zip a try; it usually squeezes a few more percent out of files you throw at it...

bzip2 = 79,76%
7zip = 77,99%

[nm]

Probably this is a trivial question, but what commandline FreeBSD (or linux) tool should I use to demux my MOV file? I see things like mp4box, avidemux, ... but that doesn't seem to be the thing I need.
You could try remuxing with MEncoder (-ovc copy -oac copy -of ...), but I doubt that helps much since the video stream itself is probably sparse.

[Jan Catrysse]

Those are the results of the x.264 compression.

I you have remarks on the options used, I welcome all explanations. It’s a mix of options from man pages, wikis, other users scripts, etc. I don’t understand all of them to their full extend.

The first pass with some speed optimization (turbo=1, frameref=1, subq=1):
mencoder uncompressed.mov -o compressed_temp.264 -passlogfile compressed_temp.log -ovc x264 -x264encopts
turbo=1:qp=20:frameref=1:bframes=3:b_adapt:b_pyramid:weight_b:8x8dct:subq=1:trellis=2
:brdo:threads=auto:pass=1:analyse=all -of rawvideo -nosound
The second pass optimized for quality:
mencoder uncompressed.mov -o compressed_temp.264 -passlogfile compressed_temp.log -ovc x264 -x264encopts
qp=20:frameref=12:bframes=3:b_adapt:b_pyramid:weight_b:partitions=all:8x8
dct:me=umh:subq=7:trellis=2:brdo:threads=auto:pass=2:analyse=all -of rawvideo -nosound

Afterwards I extracted the sound and did some encoding with neroAacEnc.
Finally I’ve put all together with mp4box.

I’ve used CRF=16 the first time but that doesn’t seem to work with two pass encoding and the size of the file is much higher… If I understand it well it’s because the CRF enforces CBR encoding and not VBR encoding…

To make a big story long:
309 MB MOV files (mp2 without much movement) = 43 MB m4v files (14%)
The quality is really impressive. 7zip only made the files bigger.
The only thing that seems somewhat of a bummer is the visible difference in luminosity and contrast. Is that something that can be fine-tuned?
Files with more details and more movement are similar at 25% resulting filesize.

Simple demuxing gives me a 20% gain. 30% in total when using 7zip on it:
mencoder uncompressed.mov -o compressed.mp2 -ovc copy -oac pcm
The output however is AVI, Mpeg, … but never MOV :-(

Using the mv4 (mpeg4) files in Final Cut is another hassle, apparently it only works nice with MOV files… Otherwise Final Cut needs to convert everything back to MOV…

Is it possible to save files in MOV format? Like MP4Box but for MOV containers? Or is it possible to convert them back on the server to the original format? If so, would this me a loss of quality?

Thank you!
Grtnx,
Jan

[Dark Shikari]

I’ve used CRF=16 the first time but that doesn’t seem to work with two pass encoding and the size of the file is much higher… If I understand it well it’s because the CRF enforces CBR encoding and not VBR encoding…No, CRF is inherently VBR. The reason is because your CRF value is simply so low.

[nm]

The second pass optimized for quality:
mencoder uncompressed.mov -o compressed_temp.264 -passlogfile compressed_temp.log -ovc x264 -x264encopts
qp=20:frameref=12:bframes=3:b_adapt:b_pyramid:weight_b:partitions=all:8x8
dct:me=umh:subq=7:trellis=2:brdo:threads=auto:pass=2:analyse=all -of rawvideo -nosound
You are using qp=20, which sets a constant quantizer and the data collected in the first pass is simply discarded. If you want to do multiple passes, you'll need to specify a bitrate instead of qp or crf to use the ABR mode. However, 1-pass CRF is as good as 2-pass ABR, so you would be just wasting time. Also, guessing the right bitrate for each source is harder than using quality-based encoding (CRF) when you don't need to aim for a specic filesize. So, drop the first pass, remove "pass=2" from the second and add crf=18.

CRF/QP=20 is probably not visually transparent, so to play it safe, use CRF=18 or lower.

I’ve used CRF=16 the first time but that doesn’t seem to work with two pass encoding and the size of the file is much higher… If I understand it well it’s because the CRF enforces CBR encoding and not VBR encoding…
Nope, with CRF you get a variable bitrate. File size is much higher because you ask for better quality with CRF=16. CRF=20 would give you about the same results as QP=20 (but CRF has a bit better overall quality/filesize ratio).

The quality is really impressive. 7zip only made the files bigger.
The only thing that seems somewhat of a bummer is the visible difference in luminosity and contrast. Is that something that can be fine-tuned?
That is probably a playback problem caused by the TV/PC levels difference. x264 itself doesn't change the overall luminosity or contrast. Could you post a short clip (10-30 seconds should be enough) of the source video and an x264 encode of it?

Simple demuxing gives me a 20% gain. 30% in total when using 7zip on it:
mencoder uncompressed.mov -o compressed.mp2 -ovc copy -oac pcm
The output however is AVI, Mpeg, … but never MOV :-(
Damn those Apple engineers forcing people to mux perfectly good MPEG video to MOV... ;) Well anyway, muxing to MOV should be possible with "-of lavf -lavfopts format=mov". Or use ffmpeg to do it.

[Jan Catrysse]

Now I’m using this command line:
mencoder uncompressed.mov -o compressed_temp.264
-ovc x264 -x264encopts crf=19:frameref=12:bframes=3
:b_adapt:b_pyramid:weight_b:partitions=all:8x8dct:
me=umh:subq=7:trellis=2:brdo:threads=auto:analyse=all
-of rawvideo –nosound

When I change the CRF value to 20 or 18 the quality loss / gain isn’t really visible but the size is.
Original: 70MB MOV
QP 20: 11,3 MB
CRF 20: 9,0 MB
CRF 19: 11,6 MB
CRF 18: 14,6 MB

Original: 98MB MOV (close-up with lots of movements)
QP 20: 25,6 MB
CRF 20: 25,8 MB
CRF 19: 33,4 MB
CRF 18: 40,9 MB

Muxing to MOV should be possible with "-of lavf -lavfopts format=mov". Or use ffmpeg to do it.
I’ve tried converting to MOV with mencoder, but that seems to be broken (lavf)? The video plays well in VLC, mplayer, etc… But in a native Quicktime player or in Final Cut the images stutters. I now use ffmpeg wich hasn’t got the problem. Filesize doesn’t change.
ffmpeg -i compressed.m4v -vcodec copy -acodec copy compressed.mov

Could you post a short clip (10-30 seconds should be enough) of the source video and an x264 encode of it?
I’ll come back to this later.

The overall compression size and quality is very good, the first goal has been achieved. The second one, reediting in Final Cut, is another hastle. Final Cut just can't handle the heavily compressed files. Would it be possible to decompress (recode) the x264 files to mpeg2 or something similar without quality loss? Has anyone got some experiance with that or the options to use?

Thanks again,
Kind regs,
Jan

[SeeMoreDigital]

I’ve tried converting to MOV with mencoder, but that seems to be broken (lavf)? The video plays well in VLC, mplayer, etc… But in a native Quicktime player or in Final Cut the images stutters.
That's because QuickTime only supports AVC encodes that contain 1B-VOP (1b-frame).


Cheers

[Dark Shikari]

That's because QuickTime only supports AVC encodes that contain 1B-VOP (1b-frame).


CheersThat's not the only pointless restriction Quicktime places on the video :p

[nm]

That's because QuickTime only supports AVC encodes that contain 1B-VOP (1b-frame).
This remuxing attempt was for the original MPEG-2 video, and Jan is probably using the OS X version of QuickTime, which has less restrictions for AVC content too.

[Jan Catrysse]

I am indeed on OS X. Which is also new for me, FreeBSD and Windows are more my domain.

I would like to convert the compressed x264 files to mpeg2 to make them more easily editable by Final Cut (x264 = Final Cut Crash :mad:). And off course without quality loss if that’s even possible… I see a whole bunch of possible lavcopts to use with mencoder but I am honestly clueless about the meaning of all of them.
Currently I’m stuck with: :)
-lavcopts vcodec=mpeg2video

I hope someone can point me the direction on what lavcopts I can use to achieve that.

I'm sure that in time I will speak that quantizer and I/P/B-frames Chinese to :)

A big thanks (again) :thanks:
Jan

[Blue_MiSfit]

noooooooooooo :)

You've gone from MPEG-2 to H.264, and now you want to go back to MPEG-2.

God help you :D

I think you should really just archive your HDV with 7zip. That way you avoid _two_ lossy compression cycles. Yeah, it's big, but it's an HD master. Hard drives are cheap!

~MiSfit

[Jan Catrysse]

1 subject = 10GB
150 subjects a month
12 months a year
= 18 TB

We have a raid configuration with 16 Drives... 2 drives in mirror for the system 1 hot spare and 13 TB Disks in RAID 6 = 11 TB :(

[Mug Funky]

you should be able to archive to tape if you're not recording to tape to begin with. final cut's "print to tape" should be able to do it and retain timecode for conforming later. regular DV tapes are cheap as, and fit nicely on shelves for future referencing.

so long as you retain your timecode you can always reconform from the tapes out of final cu*t, then just back up the project files and referenced media.

you really don't want to recompress HDV - it's bad enough to begin with.

also, if you record as mpeg TS's, you might be able to shave off some space using rejig at 100% quality - this should strip out the padding without hitting the data. but i haven't used it this way so testing might be a good idea :)

[Jan Catrysse]

if you record as mpeg TS's, you might be able to shave off some space using rejig at 100% quality - this should strip out the padding without hitting the data. but i haven't used it this way so testing might be a good idea :)

I'll check this out.

Thanks

[smok3]

i wonder what would be the difference between rejig and zip type compression as well.

shave off some space using rejig at 100% quality

how would one do that?

edit: i did a quick zip test on m2t container and i get nowhere near the 20%.

sony hdv 1440x
126.700.532 hdv-2007_09_26-14_04_18.m2t
123.979.535 hdv-2007_09_26-14_04_18.zip
121.621.705 hdv-2007_09_26-14_04_18.7z

jvc hdv 1280x
64.349.696 Clip 006.m2t
59.705.856 Clip 007.m2t
25.932.800 Clip 008.m2t
50.139.136 Clip 009.m2t
77.488.128 Clip 010.m2t
277.616.138 jvc_zip0.zip
256.653.844 jvc_zip9.zip

[Jan Catrysse]

i did a quick zip test on m2t container and i get nowhere near the 20%.

When I Remux a .mov I get +/- the same size as a .m2t, afterwards a compression with 7zip gives a total result of 73% (mov compared to 7zip)

When I directly compress the original .mov the resulting 7zip is a few percents bigger.

[Jan Catrysse]

I’ve tried converting to MOV with mencoder, but that seems to be broken (lavf)? The video plays well in VLC, mplayer, etc… But in a native Quicktime player or in Final Cut the images stutters. I now use ffmpeg wich hasn’t got the problem.

Correction: ffmpeg has the same problem. Original .mov remuxed to .mov has a smaller size but the video doesn’t play correctly on the Mac.

That's because QuickTime only supports AVC encodes that contain 1B-VOP (1b-frame).

I don’t understand very well what this means, but can this be solved?

Jan

[smok3]

post ffmpeg command line.

[Jan Catrysse]

ffmpeg -i oldmov.mov -vcodec copy -acodec copy newmov.mov

[smok3]

this only remuxes things, nothing to do with AVC.

[Blue_MiSfit]

It sounds like your operation is big enough to merit some heavy duty storage.

LTO-4 tape drives and media aren't unaffordable, especially when your IP is concerned. 800GB per tape uncompressed and up to 2x that compressed (your results will likely be somewhere in between bc apparently these HDV streams have some padding in them)

They're HD masters. They're going to be big! Archive them without destroying them.

Seems easier to do this than back up each show to MiniDV tapes. Much more reliable, too!

~MiSfit

[Jan Catrysse]

We were hoping to have all data available online...

[smok3]

example, with x264 command line:
qt ready
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/FighterPilot_qt-x1280y720.mp4
very simple one (i would use this one, with doubled or tripled bitrate, check how this behaves in final-cut-pro?)
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/FighterPilot-x1280y720.mp4

(double the bitrate i used and you are on the go.)

[foxyshadis]

We were hoping to have all data available online...

That doesn't stop you from archiving, it just means you need to recompress in addition. Speaking from experience, I can tell you that you always regret getting rid of the original, unless it's a throwaway; if it's important enough to keep it's important enough to leave pristine until you know you which subjects are no longer needed. This can be a selling point!

[Blue_MiSfit]

Well said.

If you need to have it all available online, then you could create proxy files - these x264 encodes for example. Just do them at CRF20 or something, and be done with it. Keep the original masters though - on the MiniDV tapes, LTO tape, whatever you need to.

If you just compress everything and loose the masters, you will _really_ regret it when you need to pull a shot out of the archive, and the compression artifacts / loss of detail make it stand out / not match with the rest of your material!

~MiSfit

[smok3]

there is another plus in archiving the originals in your case, customer may not be satisfied with the quality and you have a backup trick in your sleeve (send in the original then).

[Jan Catrysse]

I'll keep that in mind, it is indeed a verry good idea to keep offline backups.

As the x264 files can't be read within Final Cut, without it crashing every 5 minutes, I'll stick to 7zip for the moment...

Thank you all for helping out.

[Jan Catrysse]

Correction: ffmpeg has the same problem. Original .mov remuxed to .mov has a smaller size but the video doesn’t play correctly on the Mac.

ffmpeg -i 20080322-163316c01.mov
FFmpeg version SVN-r10657, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --cc=cc --prefix=/usr/local --make=gmake --disable-debug --enable-memalign-hack --enable-shared --enable-pp --extra-cflags=-I/usr/local/include/vorbis -I/usr/local/include --extra-ldflags=-L/usr/local/lib -la52 --extra-libs=-pthread --enable-gpl --enable-pthreads --mandir=/usr/local/man --enable-liba52 --enable-liba52bin --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libamr-nb --enable-libamr-wb --disable-mmx --enable-libgsm --enable-libmp3lame --enable-libogg --enable-swscaler --enable-libtheora --enable-libvorbis --enable-libx264 --enable-freetype2 --enable-imlib2 --enable-vhook --enable-libxvid
libavutil version: 49.5.0
libavcodec version: 51.44.0
libavformat version: 51.14.0
built on Apr 28 2008 13:02:33, gcc: 4.2.1 20070719 [FreeBSD]
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8008cc040]negative ctts, ignoring
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8008cc040]Could not find codec parameters (Video: HDV 720p25, 1280x720)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8008cc040]Could not find codec parameters (Data: tmcd / 0x64636D74)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20080322-163316c01.mov':
Duration: 00:00:00.4, start: 0.000000, bitrate: 30933 kb/s
Stream #0.0(eng): Video: HDV 720p25, 1280x720, 25.00 fps(r)
Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, stereo, 1536 kb/s
Stream #0.2(eng): Data: tmcd / 0x64636D74

ffmpeg -i new_20080322-163316c01.mov
FFmpeg version SVN-r10657, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --cc=cc --prefix=/usr/local --make=gmake --disable-debug --enable-memalign-hack --enable-shared --enable-pp --extra-cflags=-I/usr/local/include/vorbis -I/usr/local/include --extra-ldflags=-L/usr/local/lib -la52 --extra-libs=-pthread --enable-gpl --enable-pthreads --mandir=/usr/local/man --enable-liba52 --enable-liba52bin --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libamr-nb --enable-libamr-wb --disable-mmx --enable-libgsm --enable-libmp3lame --enable-libogg --enable-swscaler --enable-libtheora --enable-libvorbis --enable-libx264 --enable-freetype2 --enable-imlib2 --enable-vhook --enable-libxvid
libavutil version: 49.5.0
libavcodec version: 51.44.0
libavformat version: 51.14.0
built on Apr 28 2008 13:02:33, gcc: 4.2.1 20070719 [FreeBSD]
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x8008cc040]Could not find codec parameters (Video: hdv5 / 0x35766468, 1280x720)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'new_20080322-163316c01.mov':
Duration: 00:00:00.4, start: 0.000000, bitrate: 19857 kb/s
Stream #0.0(eng): Video: hdv5 / 0x35766468, 1280x720, 25.00 fps(r)
Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, stereo, 1536 kb/s

Apparently the difference in filesize and I suppose the problems while playing (stutter) are due to Stream #0.2(eng): Data: tmcd / 0x64636D74 that's missing when muxing to another file...

[Inventive Software]

Update your ffmpeg revision. Current in the SVN trunk is 13010 as I write this.

[Jan Catrysse]

I have allways been using the latest version from the FreeBSD ports collection.

I'm trying out the SVN version now but it doesn't compile... I'm looking into that.

I'm however not sure that the missing TMCD stream (timecode) is a bug, I have more and more the idea that FCP/Mac is not really following the rules...

[Jan Catrysse]

Video archiving to h.264 and recoding to mpeg2 works like a charm.

For info:
The command lines used.
mencoder original.mov -o temp.264 -vf harddup -ovc x264 -x264encopts crf=18:frameref=12:bframes=3:b_adapt:b_pyramid:weight_b:partitions=all:8x8dct:me=umh:subq=7:trellis=2:brdo:threads=auto:analyse=all -of rawvideo -nosound
(afterwards extracted the sound, encoded the sound and put into a mp4 container with mp4box)

mencoder temp.m4v -o final.mov -ovc lavc -lavcopts vcodec=mpeg2video:vqscale=2:mbd=2:keyint=5 -of lavf -lavfopts format=mov -vf harddup -ffourcc hdv5 -oac pcm

the -ffourcc was added in the codecs.conf and is JVC HDPro compatible.