[Ffmpeg-devel] Recommended format?

[Erik Slagter]

On Fri, 2006-02-24 at 10:33 +0000, Dieter wrote:

> Can someone recommend a good choice for:
> 
> (a) archiving NTSC
> 	goal #1: high quality
> 	goal #2: small file size (without hurting quality)

(you mean fps=30001/1001, resolution=720x480 with "NTSC" I guess, NTSC
is actually an analogue colour standard and has nothing to do with
digital video encoding, nor with frame size or frame rate)

I'd go for h264 in mp4 (that's what I use), no microsoft stuff
(notoriously for being non-completely-open), achieves highest
compression commonly available. The only thing is, you might have read
this, the mp4 muxer of ffmpeg is not yet perfect. If you want perfect
mp4 compliance, for the moment, remux with gpac.

> (b) timeshifting NTSC
> 	quality somewhat less important than for archiving
> 
> In both cases, must be fast enough to capture in real time on
> AMD64 3000+.

I have been using a XP2000 and a dual MP2600 for similar purposes. With
the XP2000 I was able to capture full resolution / full frame rate in
either mpeg2,mpeg4 or mjpeg, with all "expensive" options disabled.
Similarly with the dual MP2600, although this allowed me to do some
denoising (hqdn3d) and enable a few optimising options. You should not
enable mbd != 0, that is really not possible for encoding in realtime.

> Currently the final output needs to be DV.  This may change in
> the future.  I was hoping to capture straight to DV, especially
> for timeshifting, but so far it is looking like this is too slow
> for real time.

I can't see any theoretical issues preventing this, actually. How about
putting it in a DV container as well (instead of in mpeg ps, which is
highly non-standard). If it really doesn't work, try capturing in mjpeg
with a low "q" value (something like 2 or 3), this will give medium
compression but almost lossless quality and very little CPU load. After
that, you can re-encode to your favourite codec.

> For the archiving case, perhaps a multi step process where
> step one is capture in real time but with a large file,
> and later step two does a slow, careful conversion to a
> smaller file?

If you have two boxes connected with NFS :-)

> Can someone recommend a good README on video formats discussing
> tradeoffs between quality, file size, CPU power needed, etc. ?

No. Just keep reading here and the archives.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2771 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060225/85d243be/attachment.bin>