video:no-deinterlace-teletext gets first 2 frames wrong

[ojwb]

I was trying out video:no-deinterlace-teletext. Mostly it seems very good, but the first two frames don't seem to be handled the same as the rest. The first frame seems to have only one interlace, then the second frame only the other. The rest have both interlaces combined.

To reproduce (this pokes a VDU command to disable the cursor into the keyboard buffer so there's no flashing cursor - the runes here are cut down from those bbcmicrobot uses):

$ perl -e 'print "V.279;0;0;0;0;\r"'> keys.bin
$ ./beebjit -fast -headless -accurate -opt video:paint-start-cycles=60680000,video:border-chars=0,video:no-deinterlace-teletext -frame-cycles 1 -max-frames 10 -cycles 69000000 -commands 'breakat 600000 ;c;loadmem keys.bin 03e0;writem 02e1 ef;c'
[ITRP] D9CF: STA $0D00      [A=40 X=00 Y=00 S=FD F=  I  1  ] [addr=0D00 val=FF]
(6502db) breakat 600000 ;c;loadmem keys.bin 03e0;writem 02e1 ef;c
(6502db) c;loadmem keys.bin 03e0;writem 02e1 ef;c
[ITRP] DAE3: STY $FE30      [A=CF X=04 Y=08 S=FF F=C I  1  ] [addr=FE30 val=72]
(6502db) loadmem keys.bin 03e0;writem 02e1 ef;c
(6502db) writem 02e1 ef;c
(6502db) c
info:jit:JIT handled fault (log every 1k)
unimplemented:misc:write of TUBE region
$ sha1sum *.bgra
6f1517021191dc8c3c96e1e42170568bb88695fe  beebjit_frame_0.bgra
ec92903804d65d56d363dab69d353150861c0af6  beebjit_frame_1.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_2.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_3.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_4.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_5.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_6.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_7.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_8.bgra
13027eecfe377f0e80d729cb1a41e3729ebe3126  beebjit_frame_9.bgra
$ for x in 0 1 2 ; do ffmpeg -hide_banner -y -f rawvideo -pixel_format bgra -video_size 640x512  -i "beebjit_frame_$x.bgra" -vf "scale=1280:1024" "$x.png" ; done

Then open [012].png in your image viewer of choice and compare.

[scarybeasts]

Thanks for filing this. It's partially resolved as of the referenced commit.

Now, I get this:

ec92903804d65d56d363dab69d353150861c0af6 beebjit_frame_0.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_1.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_2.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_3.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_4.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_5.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_6.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_7.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_8.bgra 13027eecfe377f0e80d729cb1a41e3729ebe3126 beebjit_frame_9.bgra

As can be seen, the first frame is different. This is to be expected as things are currently implemented. Conceptually, "video:paint-start-cycles=60680000" specifies when the monitor turns on. So, in interlaced mode, the very first frame will only have one of the interlace fields (odd or even) rendered, because it all starts from black. I suspect it may be easiest to have the BBC Micro Bot toss the first frame, and start a little earlier if there's a need to keep the same timing.

I can imaging we might hit more quirks and caveats with interlaced rendering in the future:

• If have interlaced MODE7 and de-interlaced bitmapped modes, there's likely to be rendering artifacts when switching between the two.
• For the "glitch" style programs that reprogram the CRTC on the fly, these trigger framing changes, which is where the rendered rectangle changes size. When a framing change occurs, the whole canvas is cleared to avoid stale pixels, if the rectangle got smaller. I can imaging this might interact badly with interlace, i.e. again, we'd have a frame where only one of the interlace fields was rendered.

If any of this things become bothersome, we can look at further changes.

[ojwb]

Thanks for the changes. I can certainly see why the first frame is a special case.

I suspect it may be easiest to have the BBC Micro Bot toss the first frame, and start a little earlier if there's a need to keep the same timing.

I think that shouldn't be hard to do - I'll take a look.