[FFmpeg-devel] a64 encoder

[Bitbreaker/METALVOTZE]

> If you are in control of the format why dont you use an existing
> muxer/demuxer?
> And no iam not suggesting you implement a full avi demuxer on teh c64 but
> just one that can handle the subset of avi used in the muxer

Well, on c64 side it is best to simply load in 0x400 big blocks, as thus 
  loading speed is optimal. That is also where exactly frame data fits 
best. Most of all, when having to fiddle around with the lowbyte, this 
would include a big overhead and time consumption on c64 side. I am not 
sure if i am able to meet that requirements with an avi. Ideally there 
would be a fixed size header and after that i switch to loading big 
blocks of raw frame data. Loading is in some situations even timed so 
well, that data is loaded directly into colorram just at the position 
behind the current rasterline, teh videochip displays. This enables me 
framerates of 25fps in certain modes while streaming data over the network.
Hardware on c64 side is a RRNet Module, that is rather common in 
c64-scene, but it should also be possible to load from a MMC64 
(http://www.c64-wiki.de/index.php/MMC64). Though displayer has still to 
be done.
As Streamingserver i use 64net/2 
(http://sourceforge.net/projects/c64net) a project where i am also 
involved in and did the whole networking stuff for (before that, it was 
only possible to attach a 64net server via parallel cable, what was 
rather slow compared to ethernet).

 > The patch is also very big, spliting it per encoder would definitly be
 > a good idea

Well, i suggest to focus on multi/ecmh first, would that be okay? I'd do 
an appropriate patch then.

> also id like to hear some use case for each encoder, that is some situation
> in which it is better than all others.

The different modes have all their advantages and disadvantages. I have 
already a page made ready that describes some modes, but it is rather 
outdated and quite a few things are improved now. But i am about to 
update the webpage for that soon. Meanwhile you can have a look on teh 
results after encoding, to get an idea how these modes might look like:
http://www.ihlaid.de/content/videomodes2.php

Size of an encoded frame differs from mode to mode, less size means 
usually, more fps, but depending on the format also less quality. Of 
course the petscii mode is more a fun thing than real cinema experience, 
but still it is fun to display movies with that mode. The ecmp mode is 
more or less the same as petscii, but makes use of 4 background colors, 
thus having more colors but less details/chars available.
Same goes for the ecmh mode, it can only show a resolution of 160x100 
pixels (well, in fact it is even a symbol for each 4x4 block, but i am 
tricking around with deblocking symbols). Ecmh is quite slow (even 
slower as others as the displayroutine on c64-side is quite cpu 
consuming), but very colorful, and offering a decent level of detail and 
smooth color fades.
The multicolor modes have the best level of detail and frames are rather 
small, but therefore can have only b/w capabilities.

>> +uint8_t *multicol_charset;
>> +uint8_t *meta_charset;
>> +uint8_t *multicol_bitmap;
>> +int *multicol_charmaps;
>> +int *multicol_resolve_map;
>> +int *multicol_colram_map;
>> +int *multicol_charset_stats;
> 
> as alraedy mentioned by others these things are not thread safe.

I fixed all that in the meanwhile and moved it into A64Context.

> trailing whitespace is forbiden in ffmpeg svn

All detected, all removed :-)

> av_free(NULL) is safe thus no need to check

okay. I reduced the number of allocs and coudl remove even all memsets, 
after doing some changes it was an easy thing.

> tabs are also forbidden in ffmpeg svn

Found all, killed all.

> see START/STOP_TIMER

Oh, good to know of that. I just had my functions in there as a remain 
of older times, to be able to see if encoding speed improves.

>> +uint8_t hires_charset_std[]={
>> +/* original charset */
>> +/* char 00 - 0 */
>> +0, 0, 2, 2, 2, 2, 0, 0,  //  ####  
>> +0, 2, 2, 0, 0, 2, 2, 0,  // ##  ## 
>> +0, 2, 2, 0, 2, 2, 2, 0,  // ## ### 
>> +0, 2, 2, 0, 2, 2, 2, 0,  // ## ### 
>> +0, 2, 2, 0, 0, 0, 0, 0,  // ##     
>> +0, 2, 2, 0, 0, 0, 2, 0,  // ##   # 
>> +0, 0, 2, 2, 2, 2, 0, 0,  //  ####  
>> +0, 0, 0, 0, 0, 0, 0, 0,  //        
> 
> I assume the charset of the c64 cannot be changed? Because some of these
> are likely not good choices for encoding videos
> and its missing a const

Well, at least not in the case of Petscii mode, that is, why it is named 
after the c64 charset :-) In other modes i define a seperate charset, 
like in mutlicolor mode or ecmh mode. I have reduced the dithered chars 
   to 11 usefull ones though. But else, there is always a theoretical 
chance that each character may fit, so i better keep them all.

Kindest regards,

Toby

-- 
      style)KURVE - Fotografie mit Biss.
   www.style-kurve.de - info at style-kurve.de
Tobias Bindhammer, Uhlandstrasse 8, 89278 Stra?
        		01577/1751761