News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Arnaud

CPCEC a new emulator from cngsoft

Started by Arnaud, 08:14, 16 March 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carnivius

Quote from: cngsoft on 17:49, 04 January 21
I made a provisional version based on the code supplied by Pelrun: http://cngsoft.no-ip.org/cpcec-20210103-2555.zip
I don't have any joysticks at home and right now I must head out, so please test it and tell me whether the new joystick code behaves as intended.
If everything goes well, I'll properly update the docs and make this version fully public. If not, I'll continue editing the code until both angular and axial joysticks work.
heya, i tested it and it's not detecting any input from my controller.  I checked again on the previous version to make sure that one still does and yeah the previous one still detects buttons and has the movement attached to analog but this new one I'm getting nothing from. Sorry. :/
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

cngsoft

#126
Quote from: Carnivius on 18:16, 04 January 21
heya, i tested it and it's not detecting any input from my controller.  I checked again on the previous version to make sure that one still does and yeah the previous one still detects buttons and has the movement attached to analog but this new one I'm getting nothing from. Sorry. :/
Second try: http://cngsoft.no-ip.org/CPCEC-20210104-2335.ZIP
Made after noticing three points: 1.- Win32 joyGetPosEx requires the dwSize and dwFlags fields of JOYINFOEX to be properly filled in advance, 2.- Win32 JOYINFOEX.dwPOV field is not -1 when the controller is a joystick, but 65535; 3.- the SDL2 SDL_GameController operation set must coexist with the SDL_Joystick set; the former does NOT include the later, the function SDL_IsGameController tells which operation set must be used.
(if you can't see the banner right now my server is currently offline)

Carnivius

Quote from: cngsoft on 00:17, 05 January 21
Second try: http://cngsoft.no-ip.org/CPCEC-20210104-2335.ZIP
Made after noticing three points: 1.- Win32 joyGetPosEx requires the dwSize and dwFlags fields of JOYINFOEX to be properly filled in advance, 2.- Win32 JOYINFOEX.dwPOV field is not -1 when the controller is a joystick, but 65535; 3.- the SDL2 SDL_GameController operation set must coexist with the SDL_Joystick set; the former does NOT include the later, the function SDL_IsGameController tells which operation set must be used.
D-pad working fine now. Thanks! :)
My only other request would be to choose which buttons on the controller is Fire 1 and Fire 2 (and allow for some keys to be mapped to controller for games that require it like those that use Space or Return for smart bombs or menus or P/H keys for pausing) but don't worry about that.  Just having the more precise control of controlling CPC games correctly with the d-pad instead of the analog stick is a huge improvement and I can properly play games on it. :)
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

cngsoft

Quote from: Carnivius on 10:39, 05 January 21D-pad working fine now. Thanks! :)
My only other request would be to choose which buttons on the controller is Fire 1 and Fire 2 (and allow for some keys to be mapped to controller for games that require it like those that use Space or Return for smart bombs or menus or P/H keys for pausing) but don't worry about that.  Just having the more precise control of controlling CPC games correctly with the d-pad instead of the analog stick is a huge improvement and I can properly play games on it. :)
Excellent, it works at last! I just made a couple more edits (accepting more joystick buttons as virtual mirrors) and published the resulting package:

20210105 -- minor patch fixing a bug in video recording (it turned 44KHz stereo into 88KHz mono) and tape playback (16 and 24 bit WAVE files were improperly supported), extending the joystick support to handle directional controls (thanks to Pelrun for the Win32 and SDL2 code) and letting the Dandanator emulation modify the cartridge (configuration, savestates...) if the user requests it.

I'll have to think of a way to give the user the ability to redefine the keyboard and joystick mappings altogether, although I cannot easily imagine it working on Win32 and SDL2 at the same time. Perhaps in the next major release...
(if you can't see the banner right now my server is currently offline)

tjohnson

This latest version has broken my gamepad, now seems to be show up arrow constantly pressed on the pad.  Checked with previous version and that works fine.

cngsoft

#130
Quote from: tjohnson on 01:38, 06 January 21This latest version has broken my gamepad, now seems to be show up arrow constantly pressed on the pad.  Checked with previous version and that works fine.
After buying a game controller for 10 EUR I edited the code until it behaved as intended. Interestingly, the order of buttons in SDL2 is different from Win32, despite the controller being the same. Arthur also spotted a couple of things that needed fixing and helped me get them right.

- 20210107 -- minor patch fixing a bug in the ASIC's screen split trigger (SSSL must be checked when HSYNC rises, rather than when HDISP rises) and a glitch in the Win32 joystick support, and making the Playcity CTC more responsive.

That being said, configuring the joystick within the OS stays important; my own new controller can work in digital and analog modes, and things fared differently on each mode; changing modes while CPCEC was on led to undesired effects (i.e. going crazy)
(if you can't see the banner right now my server is currently offline)

cngsoft

New update, made possible by a bug report from Xenomorph, and featuring several tweaks:
- 20210114 -- minor patch improving Playcity stereo autodetection ("Alcon 2020" uses the left chip only), adding ROM simulation to Dandanator cartridges ("CPC Soccer") and fixing a bug in Z80 instruction CPI introduced in version 20210105 (RAXOFT tests) and another one in the CRTC1 VSYNC length ("Pheelone").
(if you can't see the banner right now my server is currently offline)

cpcitor

Quote from: cngsoft on 15:39, 15 January 21
New update, made possible by a bug report from Xenomorph, and featuring several tweaks:
- 20210114 -- minor patch improving Playcity stereo autodetection ("Alcon 2020" uses the left chip only), adding ROM simulation to Dandanator cartridges ("CPC Soccer") and fixing a bug in Z80 instruction CPI introduced in version 20210105 (RAXOFT tests) and another one in the CRTC1 VSYNC length ("Pheelone").

As usual, all those update are propagated on https://github.com/cpcitor/cpcec . (I have written a script, it's just a matter of running it.)

Congratulations cngsoft!

Strangely enough, about a month ago I had a bug where the CPC screen would refresh only about once a second (version was up to date at the time, SDL2 on Xubuntu 20.04). Tested several versions recently, not reproduced anyway. ¯\_(ツ)_/¯
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cngsoft

Extremely quick fix: "20210115 -- minor patch fixing a bug in the CPC PIO: "Inertie" sends a value to port A, then reads the same value back instead of receiving a PSG register or keyboard bits." Thanks to Dlfrsilver for spotting the glitch.
(if you can't see the banner right now my server is currently offline)

cngsoft

#134
Two updates:



CPCEC 20210127 -- minor patch fixing bugs in the Spectrum timing ("LD (IX+n1),n2" and Z80_PRAE_SEND: thanks to Azesmbog for the FPGA test report) and the CPC tape analysis (conflict between Mikrogen and Hi-Tec).
CHIPNSFX 20210127 -- 32nd public release. Major rewrite: CHIPNSFX can be compiled with SDL2 ("gcc -O2 -DSDL2 -xc chipnsfx.c -lSDL2 -ochipnsfx") in other platforms than Windows. Added HEROBOTX.CHP, HISTEEL3.CHP, IKPLUS.CHP and TWINTUV8.CHP.
(if you can't see the banner right now my server is currently offline)

cpcitor

Thanks @cngsoft for several updates again, published in :
cpcec-20210219.zip
cpcec-20210129.zip
cpcec-20210127.zip
cpcec-20210115.zip

Latest changelog from @cngsoft says:

    minor patch adding a new option, "Video: Blend scanlines" that handles
    Gigascreen effects (Spectrum demos "Mescaline Synesthesia" and
    "Tiratok", CPC demos "Batman Forever" and "Mad Leprechaun") and
    changing the sound synchronisation in SDL2. The AY chip noise generator
    is now a LFSR. SNA files saved from Spectrum Plus3 set bit 4 of byte
    0x0C01E to state that the snapshot requires a Plus3 (Easter egg "Hello
    There I'm a +3"). The CPC debugger adds an information panel (key 'X')
    for Dandanator status, and its graphics viewer can show MODE 2 images.


https://github.com/cpcitor/cpcec is updated again with comprehensive history.

Congrats @cngsoft for the impressive work!
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

SerErris

Anyone has an idea what happend to the cpcec website? Looks like it is down - not answering.
Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

robcfg

I've told @cngsoft about it, it will be up again soon, I'm pretty sure.

cngsoft

#138
Good evening. The server needs some rest every once in a while, so it was off during the past night.

Just in time for an update, after several busy and difficult months: - 20210418 -- twentieth public release. Pixel and scanline filters are now saturation-based (colour aberration, desaturation) rather than luminosity-based (horizontal blur, shading). Fixed bug in XRF-to-AVI recording: VFW32 operations always assumed 16-bit stereo. The film recording options "High resolution" and "High framerate" now stick between sessions, and the first one also applies to BMP screenshots. Aded support for block types $19 and $4B in CDT/TZX tape files, as well as the new disc option "Read-only as default" so the user can choose whether discs are by default read-only or read-write, and this option stacks together with the already extant "Strict disc writes". Added new option "Flip joystick buttons" to CPCEC so users can swap the value of the two CPC joystick buttons, as suggested by SB1903. PSG emulation now catches overflows, regardless of whether they're programming errors (music distortion in "Thing on a Spring") or done on purpose (pipe sound effect in "Thing Bounces Back"). Fixed bug in ZXSEC's Plus3 memory contention ("Firefly" disc release) and improved the beeper (oversampling: Utz's "Quattropic"). ZXSEC snapshot handling is now more strict or flexible (changing models as often or as seldom as possible) depending on the option "Strict SNA files".




CHIPNSFX also got an update, although a small one: - 20210418 -- minor patch fixing a bug in the WaveOut timer and a glitch when testing instruments: sound must play even if channels are disabled. Pressing Control-U on the instrument panel removes unused instruments. Added M_U_L_F-G_.CHP, OUTWORLD.CHP, PULSOIDS.CHP and PULSOIDZ.CHP.
(if you can't see the banner right now my server is currently offline)

cpcitor

Quote from: cngsoft on 20:47, 18 April 21
Just in time for an update, after several busy and difficult months: - 20210418 -- twentieth public release. Pixel and scanline filters are now saturation-based (colour aberration, desaturation) rather than luminosity-based (horizontal blur, shading). Fixed bug in XRF-to-AVI recording: VFW32 operations always assumed 16-bit stereo. The film recording options "High resolution" and "High framerate" now stick between sessions, and the first one also applies to BMP screenshots. Aded support for block types $19 and $4B in CDT/TZX tape files, as well as the new disc option "Read-only as default" so the user can choose whether discs are by default read-only or read-write, and this option stacks together with the already extant "Strict disc writes". Added new option "Flip joystick buttons" to CPCEC so users can swap the value of the two CPC joystick buttons, as suggested by SB1903. PSG emulation now catches overflows, regardless of whether they're programming errors (music distortion in "Thing on a Spring") or done on purpose (pipe sound effect in "Thing Bounces Back"). Fixed bug in ZXSEC's Plus3 memory contention ("Firefly" disc release) and improved the beeper (oversampling: Utz's "Quattropic"). ZXSEC snapshot handling is now more strict or flexible (changing models as often or as seldom as possible) depending on the option "Strict SNA files".

I'm always impressed by the level of precision cpcec appears to reach.

Anyway, latest release is now reflected on https://github.com/cpcitor/cpcec .
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cpcitor

Quote from: cpcitor on 21:14, 18 April 21
I'm always impressed by the level of precision cpcec appears to reach.

Anyway, latest release is now reflected on https://github.com/cpcitor/cpcec .

Propagated this update from http://cngsoft.no-ip.org/cpcec.htm

Quote20210428 -- minor patch fixing bugs in the firmware INI handler (spaces must be trimmed on both sides of each string) and in several tape fastloaders, and adding inverse video 8-bit characters to the debugger's memory dump.

Updated repo is as always on https://github.com/cpcitor/cpcec .
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

genesis8

Happy birthday César (god bless FB for remembering it) !
____________
Amstrad news site at Genesis8 Amstrad Page

cpcitor

Video recording feature: it works somehow

Hi! I just discovered how to use the video recording feature. I had seen it existed but all capture options seemed to do nothing. Looks like they actually write files in the directory containing cpcec executable and config and ROM file, without visual feedback.

Generating a very specific but well adapted file format, with a companion program that can pipe a dumb-but-not-written-to-disk AVI file to stdout for consumption by e.g. ffmpeg is actually a good design (weak coupling, no dependency hell, just works).

Video captured is 25fps not 50fps.

Something surprised me a lot: the generated XRF files have 25fps.

What? CPCEC is able to emulate for most demanding demos with 50fps solid effects, and it could record, but not at 50fps?

So I digged in source code. Source code seems to have provisions to change flags session_filmscale and session_filmtimer but no obvious key shortcut. I noticed that in .cpcecrc film reflects the values of these flags as bits.

Values where (film&2)==0 produce 50fps video files.
Values where (film&2)==1 produce 25fps video files.

Buggy flag in video capture: scale image or... ?

Values where (film&1)==1 produce working video files.
Values where (film&1)==0 make xrf crash.


for a in film_*xrf ; do echo ; echo $a ; ./xrf $a - > /dev/null ; done

film_1.xrf
VIDEO 384x268px 50Hz - AUDIO 2ch08b 44100Hz
ok: 210 frames, 0 unused.

film_2.xrf
VIDEO 768x536px 25Hz - AUDIO 2ch16b 44100Hz
Erreur de segmentation (core dumped)

film_3.xrf
VIDEO 384x268px 25Hz - AUDIO 2ch08b 44100Hz
ok: 127 frames, 0 unused.

film_O.xrf
VIDEO 768x536px 50Hz - AUDIO 2ch16b 44100Hz
Erreur de segmentation (core dumped)


Looking at the source code more, there seem to be a mixture between (film&1) meaning "scale the images 2x" and "generate an AVI with 16bit sound"?

Generated AVI causes inconsistent conversion

Anyway, last but not least, conversion as documented:

xrf source.xrf - | ffmpeg -i - target.avi

Produces a working AVI, but AVI, while based on the nice-for-its-time IFF format https://en.wikipedia.org/wiki/Interchange_File_Format, is a relic of the past.

Strangely, total file duration is reported (in mpv and vlc and mediainfo) as twice the actual duration of the video.
mediainfo provides more details: it is the audio track that is announced twice as long as the real duration, so something is clearly invalid.

Curiously, the directly generated stream:
./xrf film_3.xrf - > direct.avi
does not play correctly in mplayer or VLC, although mediainfo reports consistent time for video and audio,

mpv reports a warning on playing:

QuoteAudio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).


Trying to convert directly to mp4 or mkv:

xrf source.xrf - | ffmpeg -i - target.mp4
xrf source.xrf - | ffmpeg -i - target.mkv

produce movies that play with the same problem as the direct AVI, with the same warning.

It looks like direct AVI file plays all video frames first then all audio?

Hope this helps to improve cpcec even further.

Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cpcitor

Workaround and bonus!

Workaround to get a clean video+audio file.

Experimenting with ffmpeg options -vn and -an seem to indicate that indeed problems are on the audio side: most extraction operations provide an audio file that starts with a silence for as long as the whole recording time, and only then starts audio normally.

I managed to find a sequence of conversions that allows to "clean up" the thing.
It looks like exporting to a format that does not understand timestamps, like AVI or WAV, produces a working audio file without the delay. Then one can combine that audio with the video (which has no such problem).


# Extract only the audio part in a container that does not understand timestamps
./xrf source.xrf - | ffmpeg -y -vn -i -  -c copy audio_unbroken.wav
# Extract again, with audio from "dumb" container, ignoring audio from xrf.
./xrf source.xrf - | ffmpeg -y -i audio_unbroken.wav -an -i - audioandvideo.mkv


One can use the regular ffmpeg options for audio and video codec in the second command.

The resulting mkv (or mp4) file plays without warning, without problem.

Bonus: high speed recording of CPC emulation

Bonus: compared to screen capture (with VLC, ffmpeg, OBS or others), this method of recording has two benefits:

* it is robust, it won't frop a frame, independent of system activity, won't mix with other programs playing sounds or other windows obscuring the cpcec window, you can even minimize the cpcec window
* it does not require to play the whole thing real time. While recording, you can press shift-F6 to speed up the whole thing, the recording will be exactly the same!
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cngsoft

#144
Quote from: cpcitor on 13:14, 21 May 21
Workaround and bonus!

Workaround to get a clean video+audio file.

Experimenting with ffmpeg options -vn and -an seem to indicate that indeed problems are on the audio side: most extraction operations provide an audio file that starts with a silence for as long as the whole recording time, and only then starts audio normally.

I managed to find a sequence of conversions that allows to "clean up" the thing.
It looks like exporting to a format that does not understand timestamps, like AVI or WAV, produces a working audio file without the delay. Then one can combine that audio with the video (which has no such problem).


# Extract only the audio part in a container that does not understand timestamps
./xrf source.xrf - | ffmpeg -y -vn -i -  -c copy audio_unbroken.wav
# Extract again, with audio from "dumb" container, ignoring audio from xrf.
./xrf source.xrf - | ffmpeg -y -i audio_unbroken.wav -an -i - audioandvideo.mkv


One can use the regular ffmpeg options for audio and video codec in the second command.

The resulting mkv (or mp4) file plays without warning, without problem.

Bonus: high speed recording of CPC emulation

Bonus: compared to screen capture (with VLC, ffmpeg, OBS or others), this method of recording has two benefits:

* it is robust, it won't frop a frame, independent of system activity, won't mix with other programs playing sounds or other windows obscuring the cpcec window, you can even minimize the cpcec window
* it does not require to play the whole thing real time. While recording, you can press shift-F6 to speed up the whole thing, the recording will be exactly the same!

I posted a new version today, the bugs you're talking about are several versions old. However, just in case, I tested the current versions of CPCEC and XRF with all the four possible configurations (neither option, hi-resolution only, hi-framerate only, both options) and everything works fine either with the Windows codecs (i.e. including the third parameter) or with the built-in video output (either fed to FFMPEG, or straight to a gigantic file); all four configurations generated valid files. (if anything, not specifying any codecs in FFMPEG led to bad audio because the default lossy audio codec is completely unsuited for loud chiptunes)

Here are the test XRF files: the first four pages of the intro of "La Abadía del Crimen", http://cngsoft.no-ip.org/XRF-TEST-ABADIA.zip

(also, why Shift+F6 rather than just F6? in other function keys Shift is relevant, but in this one it's not)
(if you can't see the banner right now my server is currently offline)

cpcitor

#145
Summary: interesting test files, XRF still crashes, problem not solved, more hints below.

cpcec version: was latest one, double checked

Thanks you cngsoft for your reply.

Quote from: cngsoft on 17:49, 23 May 21I posted a new version today, but the bugs you're talking about are several versions old.

I think I was using cpcec version 20210418, not 100% sure. Below I'll be using latest today's cpcec-20210522.zip .

Quote from: cngsoft on 17:49, 23 May 21Just in case, I tested the current versions of CPCEC and XRF with all the four possible configurations (neither option, hi-resolution only, hi-framerate only, both options) and everything works fine either with the Windows codecs (i.e. including the third parameter) or with the built-in video output (either fed to FFMPEG, or straight to a gigantic file); all four configurations generated valid files. (if anything, not specifying any codecs in FFMPEG led to bad audio because the default lossy audio codec is completely unsuited for loud chiptunes)

Thanks for performing those tests.

Quote from: cngsoft on 17:49, 23 May 21Here are the test XRF files: the first four pages of the intro of "La Abadía del Crimen", http://cngsoft.no-ip.org/XRF-TEST-ABADIA.zip

Special thanks for providing sample XRF files.

With the XRF files you provide and the latest cpcec/xrf I can reproduce similar bugs as with the XRF files I generate.
I see xrf.c was last mofidied in cpcec-20210418.zip .

Reproduced with latest version and sample XRF files: xrf crash

for a in abadia-*xrf ; do echo ; echo $a ; xrf $a - > /dev/null ; done

abadia-1.xrf
VIDEO 384x268px 25Hz - AUDIO 2ch08b 44100Hz
ok: 1510 frames, 0 unused.

abadia-2.xrf
VIDEO 768x536px 25Hz - AUDIO 2ch16b 44100Hz
Erreur de segmentation (core dumped)

abadia-3.xrf
VIDEO 384x268px 50Hz - AUDIO 2ch08b 44100Hz
ok: 3148 frames, 0 unused.

abadia-4.xrf
VIDEO 768x536px 50Hz - AUDIO 2ch16b 44100Hz
Erreur de segmentation (core dumped)


We'll ignore case 2 and 4 then.

Reproduced with latest version and sample XRF files: wrong duration reported in VLC, mpv, mediainfo

Here's my ffmpeg version. On latest Xubuntu stable, 20.04 with latest updated applied.

ffmpeg version 4.2.4-1ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.3.0-10ubuntu2)
  configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Hyper fast Audio and Video encoder


The code below generates direct-from-xrf AVI files and through ffmpeg as documented in cpcec*.txt.

for XRF in *xrf ; do
STEM=${XRF%%.xrf} ;
xrf $XRF - >| ${STEM}.direct.avi 2>|${STEM}.xrf.log ;
xrf $XRF - | ffmpeg -y -i - ${STEM}.avi 2>|${STEM}.ffmpeg.log ;
done


Code below reports duration of generated AVI files, and reports 2 durations when audio and video are inconsistent with each other.


for a in abadia-{1,3}*.mediainfo.txt ; do egrep '^(Duration)' $a | sort | uniq | xargs echo $a ; done | sed 's/Duration *//g' | column  -t -s ":"

abadia-1.avi.mediainfo.txt           1 min 0 s    2 min 0 s
abadia-1.direct.avi.mediainfo.txt    1 min 0 s
abadia-3.avi.mediainfo.txt           1 min 3 s    2 min 5 s
abadia-3.direct.avi.mediainfo.txt    1 min 2 s


So, both converted files report inconsistent durations, like before.

Something changes: audio starts synced with video, not after, always. This is better.

Still, problems remain.

Playing the converted videos abadia-?.avi stops after around 1 minute, with progress bar showing 50% in VLC, also in mpv.

Playing the direct videos abadia-?.direct.avi (the huge ones) has another funny behavior:

* in VLC: sound is hashed, about 0.1s audio 0.1s silence, etc. Total duration 02:00 .
* in mpv: plays normally, progress bar goes from 0% to 100% regularly within 1 minute, then progress bar jumps back to 50%, image stays still and audio continues playing till 02:00
* mpv shows again warning: "Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field)."

Workaround: somehow fails now

This code applies workaround to files that can be converted:

for a in abadia-{1,3}*.xrf ; do
xrf $a - | ffmpeg -i - -an ${a}.videoonly.mkv  ;
xrf $a - | ffmpeg -i - -vn ${a}.audioonly.mkv ;
ffmpeg -i ${a}.audioonly.mkv -i ${a}.videoonly.mkv -c copy ${a}.audioandvideo.mkv ;
done


Files appear to play properly at the start. Total duration is 02:00. No progress bar jump. But video is frozen after 50%. Perhaps it was playing at double speed? I don't know the normal speed in that CPC prod.

Quote from: cngsoft on 17:49, 23 May 21(also, why Shift+F6 rather than just F6? in other function keys Shift is relevant, but in this one it's not)

Thanks for pointing out. I'm always lost with Ctrl and Shift variants in cpcec and always have to look it up by pressing F1 first.

Now what?

* There is something wrong in xrf since it crashes with abadia-2.xrf and abadia-4.xrf.
* Direct files play with funny behavior in VLC and mpv, so there is most certainly something wrong here.
* Straight conversion using documented ffmpeg yields other funny behavior.
* Workaround no longer works properly, but hey I just selected a combination that happened to work before.
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cpcitor

You will find attached valgrind's report in the crashing case.

There are several invalid reads and writes in xrf, also access after valid buffer, invalid writes.

(If you don't know valgrind, it verifies read, write, memory access for things that a compiler cannot always do, and reports them at run time.)

Hope this helps.
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cngsoft

#147
Quote from: cpcitor on 19:26, 23 May 21
You will find attached valgrind's report in the crashing case.

There are several invalid reads and writes in xrf, also access after valid buffer, invalid writes.

(If you don't know valgrind, it verifies read, write, memory access for things that a compiler cannot always do, and reports them at run time.)

Hope this helps.

It really helps -- it shows 8-byte operations where a 4-byte DWORD should be used! The line `#define DWORD unsigned long` for non-Windows systems is fine here at home (32-bit OS) but not on a 64-bit OS! Please replace that definition in (line 50 in xrf.c) with `#define DWORD unsigned __int32` or `#define DWORD u_int32_t` (some OSes use the former, others use the later) and tell me what happens.
(if you can't see the banner right now my server is currently offline)

cpcitor

Summary: Tested your change. + XRF no longer crashes. = AVI problems remain.

Quote from: cngsoft on 20:02, 23 May 21
It really helps -- it shows 8-byte operations where a 4-byte DWORD should be used! The line `#define DWORD unsigned long` for non-Windows systems is fine here at home (32-bit OS) but not on a 64-bit OS! Please replace that definition in (line 50 in xrf.c) with `#define DWORD unsigned __int32` or `#define DWORD u_int32_t` (some OSes use the former, others use the later) and tell me what happens.

Why choose non-standard option accepted by some OS when there is a standard?

Here's a patch I just tested:

git diff xrf.c

diff --git a/xrf.c b/xrf.c
index 5cd8e28..9817c30 100644
--- a/xrf.c
+++ b/xrf.c
@@ -36,6 +36,7 @@ Contact information: <mailto:cngsoft@gmail.com> */
#include <stdio.h> // printf...
#include <string.h> // strcmp...
#include <stdlib.h> // malloc...
+#include <stdint.h> // uint32_t...

#ifdef _WIN32

@@ -47,7 +48,7 @@ Contact information: <mailto:cngsoft@gmail.com> */

#define BYTE unsigned char
#define WORD unsigned short
-#define DWORD unsigned long
+#define DWORD uint32_t

#endif


No more crash of xrf!

for a in abadia-*xrf ; do echo ; echo $a ; xrf $a - > /dev/null ; done

abadia-1.xrf
VIDEO 384x268px 25Hz - AUDIO 2ch08b 44100Hz
ok: 1510 frames, 0 unused.

abadia-2.xrf
VIDEO 768x536px 25Hz - AUDIO 2ch16b 44100Hz
ok: 1425 frames, 0 unused.

abadia-3.xrf
VIDEO 384x268px 50Hz - AUDIO 2ch08b 44100Hz
ok: 3148 frames, 0 unused.

abadia-4.xrf
VIDEO 768x536px 50Hz - AUDIO 2ch16b 44100Hz
ok: 3141 frames, 0 unused.


Still inconsistent parameters in generated avi:

for a in abadia-*.avi ; do mediainfo $a | egrep '^Duration' | sort | uniq | xargs echo $a ; done | sed 's/Duration *//g' | column  -t -s ":"

abadia-1.avi    1 min 0 s     2 min 0 s
abadia-2.avi    57 s 40 ms    57 s 51 ms
abadia-3.avi    1 min 3 s     2 min 5 s
abadia-4.avi    1 min 2 s



Playing yields this in mpv and in VLC (same behavior)

* abadia-1.avi plays and exits after 1:00 (one minute), having played the last video frame (scroll completely written), but the progress bar only attains 50%, while end is at 2:00
* abadia-2.avi seems normal: it plays and exits after 56 s, having played the last video frame (scroll completely written), with normal progress bar to 100% at 0:56 (0:57 in VLC).
* abadia-3.avi plays and exits after 1:02 (1:03 in VLC), having played the last video frame (scroll completely written), but the progress bar only attains 50%, at 1:02 while end is at 2:05
* abadia-4.avi seems normal: it plays and exits after 1:02, having played the last video frame (scroll completely written), with normal progress bar to 100% at 1:02

1 and 3 have problem and have both small size
2 and 4 have no problem and have both big size

So, problem is correlated to image size.

So, looks like the issue depending on fps is solved, while the issue depending on image size is not solved.

At the moment, the workaround would be to only use big size until small size is fixed.

Hope this helps again.


Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cpcitor

Quote from: cpcitor on 23:39, 23 May 21
1 and 3 have problem and have both small size
2 and 4 have no problem and have both big size

So, problem is correlated to image size.

So, looks like the issue depending on fps is solved, while the issue depending on image size is not solved.

At the moment, the workaround would be to only use big size until small size is fixed.

Looking again, there is a strange thins also correlated to image size:

for a in abadia-*xrf ; do echo ; echo $a ; xrf $a - > /dev/null ; done

abadia-1.xrf
VIDEO 384x268px 25Hz - AUDIO 2ch08b 44100Hz
ok: 1510 frames, 0 unused.

abadia-2.xrf
VIDEO 768x536px 25Hz - AUDIO 2ch16b 44100Hz
ok: 1425 frames, 0 unused.

abadia-3.xrf
VIDEO 384x268px 50Hz - AUDIO 2ch08b 44100Hz
ok: 3148 frames, 0 unused.

abadia-4.xrf
VIDEO 768x536px 50Hz - AUDIO 2ch16b 44100Hz
ok: 3141 frames, 0 unused.


Problem comes when XRF generates 2ch08b, no problem when XRF generated 2ch16b.

Why would sound channel format depend on image size? Does cpcec generate different audio format in XRF depending on film option? Does XRF format even support that? 
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

Powered by SMFPacks Menu Editor Mod