[FFmpeg-devel] a64 encoder 7th round
Thu Jan 29 19:58:43 CET 2009
On Thu, Jan 29, 2009 at 01:47:52PM +0100, Bitbreaker/METALVOTZE wrote:
> > Surely the addition of P frames does not help in every case, one always can
> > just encode unrelated frames but where it does help the smaller P frames
> > allow the freed up space and bitrate to be used by something else to improve
> > quality ...
> In multicol mode i can only improve quality by either having a bigger
> charset (impossible, 256 is already the maximum the c64 can handle) or
> sending a charset more often. a lifetime of 4 frames however is already
> a good tradeoff between quality and framerate. Also sending two screens
> and thus making chars 8x4 pixels big would be an option. But all that
> would make a single frame much bigger. So i can only take advantage of
> that if i can load/decompress/whatsover them faster _even_ in worst
> case. So a delta/rle/whatsoever must always, under any circumstances be
> faster and have thus no cross over point with plain loading. If not
> framerate will drop or plain loading will be enough for same quality and
scene1 | scene2
F0 F1 F2 F3 F4 F5 F6 F7
your encoder will choose a charset for F0-F3 and another for F4-F7
the second clearly is a very poor choice. F0-F4 F5-F8 would be better
at no point is there more data to deal with
Also let me try to explain it again, there is no worst case issue if you
have 2 frame types, you simply do not use the frame type if it couldnt be
In mpeg there also are cases where P frames are worse than I frames these
use I frames.
> > If this picture was the input then the use of the specific colors is optimal
> > because that is how it is supposed to look.
> > This really very strongly points towards something being wrong with how you
> > choose the colors.
> Sure, i can interlace #000000 and #ffffff to get a nice gray tone, but
> well, try that at 50Hz refresh rate, it is flickering like hell and
> really hurts your eyes :-) It even flickers on my TFT when i watch
> things in an emulator.
so if your input flickers your decoder will remove it
and if it doesnt flicker it needs a hardcoded list of color pairs to
avoid generating flicker
> > You simply have to simulate how something will look and compare that with a
> > good comparission function against the input picture.
> That is exactly what i am doing,
you consider gamma?
luma chroma crosstalk from PAL?
lowpass filter effects the probably somewhet primitive electronics used to
modulate PAL likely cause?
> except for the good compare function,
> > iam not sure what these links are supposed to proof, they arent compareing
> > error diffusion against ordered dither
> > rather you could look at:
> The links show how dithering is usually done on a c64. It is state of
> the art on that platform to do it like this, that simply is how things
> have developed over the past decades and it turned out that this looks
> best on a c64. I just can't help. I have no doubt that your examples
> look good as well, but on a PC.
> Also i don't see any need of proofing. The encoder enables to do
i provided a proof that error diffusion looks better on
TFT & CRT screen connected to a PC. google will provide more such
You did not show an example of a properly done comparission on the C64
nor did you provide any theoretic explanation why it would be worse
You dont have to of course and it of course is a lot of work but then
designing a codec or encoder is alot of work if done well.
If you think its ok to just write something that you belive is best
without any testing that it actually is, well thats fine but keep in
mind normally formats are designed once and then implemented many times
and a mistake at the design can be very painfull because everyone has to
support then yet another broken misdesigned codec because the designer
has no time to do it properly but still pushed it out ...
now surely its C64 specific and thus nowhere at the same level as h264
but still it doesnt feel right to make choices based on unverified claims.
And iam not saying the claim is wrong just that ive not seen much that
would allow it to be compared fairly
> > no, not at all, first you could use loops like:
> > (i hope my wild guesses for the ASM are understandable)
> > ldx #<dest
> > stx a1+1 ;set highbyte of dest in code
> > stx a2+1
> > stx a3+1
> > stx a4+1
> > ldx $de01
> > loop
> > lda $de00
> > a1 sta $0000,x
> > a2 sta $0004,x
> > a3 sta $0008,x
> > a4 sta $000C,x
> > ldx $de01
> > bne loop
> > to write 4 equal bytes, and a similar loop to write 4 different ones
> I corrected your example a bit:
> ldx #<dest
> stx a1+1 ;set highbyte of dest in code
> stx a2+1
> stx a3+1
> stx a4+1
> ;yet only highbytes are set, if you want to change the lowbyte
> (0,4,8,c) additional code is needed here. We can only set 8 bit of a 16
> bit address at once. With +1 that is the lowbyte (little endian).
> ldy #$00
> ldx $de00
> stx count
> lda $de01
> ldx #$00
> a1 sta $0000,x
> a2 sta $0004,x
> a3 sta $0008,x
> a4 sta $000c,x
> cpx count
> bne loop
just to clarify i meant
dst[x+0x0] = a;
dst[x+0x4] = a;
dst[x+0x8] = a;
dst[x+0xC] = a;
i dont think your code is equivalent to that
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel