[MPlayer-dev-eng] encoding to huffyuv

[D Richard Felker III]

On Sun, Jun 30, 2002 at 01:08:23PM +0200, Marian Jancar wrote:
> On Sat, 29 Jun 2002 13:52:46 -0500
> "Billy Biggs" <vektor at dumbterm.net> wrote:
> 
> >   An alternative, I wrote a simple huffyuv-style compression codec for
> 
> I also wrote something similar, using mmx to compute the
> (intraframe) deltas and to replace them with Huffman codes Im able to
> compress full PAL in about 80% cpu time of K6-2 350, unfortunately the
> remaining 20% isnt enough to save the data to the disk without drops.
> The limitig factor is memory speed i guess, bt848 writes 20MB/s, I
> need to read 20MB/s 2 times - curent and previous filed, write 10MB/s
> huffman codes and then read them by hdd controler, the required 80MB/s
> total is probably too much. Better compression (or better computer, i
> know) could help here.

Really, from my experience, HD performance is the biggest obstacle to
recording from live sources. I've actually had the best luck using
libavcodec to encode almost-intra-only (keyint=1, 2, or 3) mpeg4 with
constant qscale=2, but my K6-2 450 is still slightly too slow to keep
up all the time. A $30 upgrade to a 550 would probably fix the problem
entirely.

> > app I've been writing (www.sf.net/projects/reetpvr).  It would be pretty
> > easy I bet to throw it in mplayer.  The code is straight C and only
> > depends on inttypes.h :)
> 
> Actualy mencoder handles v4l input an inefficient way, I cant save
> 384x288 stream without drops using mnecoder while using streamer from
> xawtv I can save 768x288 with fewer drops. I will add the losless
> compression to steamer and the support to read it to mplayer, this is
> probably the easiest way achieve my goal. I will develop own simple
> format based on advices and experince from anyone capable, as the
> huffyuv sources contain assembler in a Microsoft format, which I dont
> want to rewrite by hand and dont know any convertor to at least nasm.

I think the problem in mencoder is that the writes to disk block, but
that's just a guess. Try piping output to a separate writing process
that does its own buffering. It might also be good to be calling
sync frequently so the stupid kernel doesn't try to buffer up a lot of
stuff itself and then freeze for a few seconds when it figures out it
actually needs to write to disk.

Rich

P.S. Please word wrap your emails. It's a lot of work reading them
(much less trying to quote them legibly) when they extend for 10 pages
horizontally.