As I said before they play fine with MUIMPlayer and VLC (on PC).
LiveForIt seems to not have the ZMBV codec enabled in his MPlayer build, but that is something you will have to take up with him.
DvPlayer doesn't support MKV at all but that is not a problem of SRec either.
As far as codecs go that are suitable for this purpose (support RGB source data and have decent delta compression between frames) there is not much to choose from unfortunately.
If I use a standard codec made for video then I will have to add RGB to YUV conversion in software as an extra step to the encoding.
Blender loads the files okay (most recent build at least) and ffmpeg can convert them.
I think your choice of fastest to encode make good sense. Conversion tools abound.
The screen capture routine I have on linux, writes to a temp format and then encodes on exit, to give max speed. This is not so different is practice, just using ffmpeg as an intermediate stage instead of built in.
Could someone else please try compiling the latest SRec from github with ENABLE_AVI defined (add -DENABLE_AVI to CFLAGS in the root level Makefile)?
When I do this here it generates an executable that crashes immediately on startup before it even has reached any of the code that is enabled by the ENABLE_AVI define.
However if I change in avilib-0.6.10/xio.c the ftruncate64() call to ftruncate() it generates a binary that is about 64kB smaller and works fine.
I'm thinking it might be a problem with my cross-compiler but I'm not sure.
I link the executable with -static option so it's not shared objects related at least.
The stack trace seemed nonsensical at first so I ignored it but looking at the disassembly it looks like it crashes because the global IDOS variable contains a NULL pointer.
The stack trace seemed nonsensical at first so I ignored it but looking at the disassembly it looks like it crashes because the global IDOS variable contains a NULL pointer.
I added the following near the start of my main() function and it confirms that the IDOS pointer is really NULL both when I start SRec from CLI and from WB:
but only when I run it on my Final Edition system. If I run it on my beta system it runs perfectly so it might be related to the newlib.library version (it's newlib.library that inits the IDOS and DOSBase globals, the others are done by statically linked startup code).
@salass00 I compiled SRec on my X1000 and the binary crashes with -DENABLE_AVI. I had to edit the Makefile and get rid of -Werror because of some warnings in gui.c. While editing it I noticed that the "SRCS :=" line has src/cli.o & src/gui.o instead of src/cli.c src/gui.c. Surprisingly it still compiles that way.
If IDOS is only NULL when the avilib is linked in, it seems like the problem is avilib.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
If IDOS is only NULL when the avilib is linked in, it seems like the problem is avilib.
No, as it turned out it was an obscure newlib bug which is why it didn't crash when I ran it on my beta install which has a fixed newlib.
The bug is only triggered when the startup code sets a higher minimum version than 52.39, and using ftruncate64() increases this from the default 52.20 to 53.24.
I'd already seen the buggy code in newlib and the trigger was staring me right in the face with the ftruncate()/ftruncate64() thing but I didn't connect the dots right away.
I guess no-one had used post-newlib 52.39 functions and IDOS both in the same binary linked with startup code before now, because if they had they would have run into the same problem.
@salass00 O.K. I replaced "return ftruncate64(fd, length);" with "return 0;" in xio.c and after compiling and entering "SRec ?" in a shell, a template is printed and there is no crash. Of course SRec probably won't work right with "return 0;" but it confirms that ftruncate64 is triggering the crash.
Could you borrow the unistd_ftruncate.c file in the clib2 sources at Github and update it to 64 bits as a replacement for newlib's ftruncate64 in SRec??
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I do my own version checking in main() so that the built-in check is not needed.
Also I got rid of the ftruncate64() because unbuffered file descriptor I/O is too slow and there seems to be no equivalent of this function for fopen() streams so I replaced the file I/O layer with buffered dos.library functions.
@salass00 I never used SRec before so I D/L the SRec archive from OS4 depot and copied the compiled SRec binary into the SRec directory. I added a filename to the SRec tooltype and started SRec. It appears that SRec is not using the tooltypes. There was no filename in the GUI, the height and width were different than in the tooltypes etc. When I open Exchange to check SRec it always shows it as inactive even if the GUI is open or recording. The CX_POPKEY (ctrl alt r) doesn't work unless I change SRec to "active" in Exchange. Also, the CX_POPKEY is displayed in the window toolbar but the window isn't wide enough to show the whole key combination.
I made an avi recording and an mkv recording. I could only play them in MUI_MPlayer and all the colors were wrong. Maybe that's an MUI_Mplayer problem or I'm doing something wrong.
The Autoinstall in the SRec archive at OS4Depot has lines to copy libraries from the SRec directory to LIBS: but there are no libraries in the SRec directory.
I haven't had time to try converting the output to work in DVPlayer or MPlayer.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
SRec 2 only uses tooltypes for the commodity settings and key combinations.
Instead of using an icon from an older version you should use the one from the github repository.
To save settings for future use so you don't have to set them again every time use "Settings -> Save As Defaults" menu item. Assuming your version is new enough it should write an xml prefs file to ENV: and ENVARC:.
I made an avi recording and an mkv recording. I could only play them in MUI_MPlayer and all the colors were wrong. Maybe that's an MUI_Mplayer problem or I'm doing something wrong.
What pixel format was the screen you recorded in? I've only tested ARGB32 and RGB16PC formats, but RGB16, RGB15 and RGB15PC formats should be supported as well.
If you try to record a screen with an unsupported pixel format there will be a DebugPrintF() message ("unsupported pixel format: %lu!") and nothing will get recorded until you switch to a supported screen.
What pixel format was the screen you recorded in? I've only tested ARGB32 and RGB16PC formats, but RGB16, RGB15 and RGB15PC formats should be supported as well.
I use all RGB16 screens on my X1000. I switched Workbench to ARGB32 and recorded a short avi video and it plays back correctly with MUI_MPlayer.
Recording on an ARGB32 screen plays back with normal colors. Recording on an RGB16 screen plays back with wrong colors.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
SRec 2 only uses tooltypes for the commodity settings and key combinations.
Instead of using an icon from an older version you should use the one from the github repository.
To save settings for future use so you don't have to set them again every time use "Settings -> Save As Defaults" menu item. Assuming your version is new enough it should write an xml prefs file to ENV: and ENVARC:.
OK. I used the icon from the github repository but the POPUP key combination still doesn't work until I open Exchange and change SRec from Inactive to Active.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
OK. I used the icon from the github repository but the POPUP key combination still doesn't work until I open Exchange and change SRec from Inactive to Active.
This was just a missing ActivateCxObj() call. Already fixed: