[FFmpeg-devel] a64 encoder
Bitbreaker/METALVOTZE
bitbreaker
Fri Jan 16 15:14:46 CET 2009
> 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
More information about the ffmpeg-devel
mailing list