[Ffmpeg-devel] [RFC] Smacker decoder

[Kostya]

On Mon, Mar 20, 2006 at 10:22:02AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Mar 20, 2006 at 06:26:16AM +0200, Kostya wrote:
> > On Sun, Mar 19, 2006 at 01:30:22PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Sun, Mar 19, 2006 at 06:46:44AM +0200, Kostya wrote:
> > > > Here is long-waited decoder for Smacker data. Please test it on different 
> > > > data (especially SMK4, have no samples here) and also give comments about 
> > > > it structure. It is not as perfect as it could be (some graphic and sound 
> > > > glitches still occur) but works for most data (at least I hope).
> > > > 
> > > > @Michael: I used table instead of VLC for big trees because of large 
> > > > tree size (for 16-bit values and lengths of codes >20) get_vlc2(gb,vlc.table,9,3) 
> > > > got strange errors in decoding and VLC building sometimes was slow.
> > > 
> > > hmm, but the code contains get_vlc2(... ,2)
> > Those get_vlc2() are used for smaller trees, where I have never seen length > 17 bits.
> > Changed to 3 anyway.
> 
> well, if there are no length >17 then theres no need to change it to 3
> 
> 
> > > and try to change VLC_TYPE to int32_t
> > I'll experiment with this. But VLC_TYPE is already defined in bitstream.h, so redefining it
> > may cause some unwanted effects. Please think how that could affect source and compatibility
> > (for example, argument in get_vlc2 is a table of VLC_TYPEs)
> 
> i meant change it in bitstream.h and see if it fixes the issue ...
Changed VLC_TYPE to int32_t, recompiled and run. It works even when codewords are 23 bits long but
second issue (time) still remains.
Some statistics: 
Smacker video, playback time 65 seconds.
CPU: PII-266
Time spent on decoding (time ffmpeg -i intro.smk -vcodec rawvideo -acodec pcm_s16le -y -f avi /dev/null)
Without get_vlc2() for large tables: ~12 seconds
With get_vlc2() with different n_bits: 40-68 seconds
About twenty seconds are spend on vlc table constructing (time before ffmpeg starts and begins decoding).
For smaller samples it's still very large, especially the lag before decoding starts.

So I'll commit current version tomorrow if nobody objects.
> 
> [...]
> 
> -- 
> Michael
> 
>