Comment #1: Mon, 1 Jun 2020, 15:29 (GMT+1, DST)

Quote

Yes, it worked, thank you!

Comment #2: Thu, 28 May 2020, 15:58 (GMT+1, DST)

Quote

    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)

    buffer_clear(buff_save) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff_save,'test.txt')
        buffer_write_buffer(buff,buff_save)
    }
    else buffer_write_string(buff, 'null')

    socket_write_message(server, buff);

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)
buffer_write_to_file(buffer_save,'test.txt');

The problem is this:

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)

Although the data is not null-terminated, Game Maker cannot handle binary strings. It's Game Maker itself which is dropping part of the data, not the DLL. You need to use buffer_write_buffer_part to copy the data to buffer_save:

buffer_write_buffer_part(buffer_save,buff,buffer_get_pos(buff),buffer_get_length(buff) - buffer_get_pos(buff))

Last modified: Thu, 28 May 2020, 15:59 (GMT+1, DST)

Comment #3: Thu, 28 May 2020, 12:16 (GMT+1, DST)

Quote

Made new code on client:

    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)

    buffer_clear(buff_save) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff_save,'test.txt')
        buffer_write_buffer(buff,buff_save)
    }
    else buffer_write_string(buff, 'null')

    socket_write_message(server, buff);

And this on server:

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)
buffer_write_to_file(buffer_save,'test.txt');

This faild, file on server is still only a part of original.
If I understood correctly buffer_read_data and buffer_write_data are not null-terminated, and could be used in my case. But there is no expamples on how does it work. How does work buffer_get_length(buff); buffer_get_pos(buff), and at what point should I calculate the end of a buffer? When do buffer understand, if I want it to read from a specific position? Would buffer_read_data work like I think? Where can I find more code examples to understand, how to use it?

Last modified: Thu, 28 May 2020, 12:22 (GMT+1, DST)

Comment #4: Thu, 28 May 2020, 0:53 (GMT+1, DST)

Quote

buffer_save = buffer_create();
buffer_write_string(buffer_save,ds_list_write(save_list));
buffer_zlib_compress(buffer_save)
buffer_rc4_crypt(buffer_save,'test')
buffer_write_to_file(buffer_save,'test.txt');
buffer_destroy(buffer_save);

buffer_load = buffer_create()
buffer_read_from_file(buffer_load,'test.txt')
buffer_rc4_crypt(buffer_load,'test')
buffer_zlib_uncompress(buffer_load)
ds_list_read(load_list,buffer_read_string(buffer_load))
buffer_destroy(buffer_load)

    buffer_clear(buff) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff,'test.txt')
        player_save = buffer_read_string(buff)
    }
    else player_save = 'null'
    
    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)
    buffer_write_string(buff, player_save)
    socket_write_message(server, buff);

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

        if psave <> "null" then 
        {
            txt=file_text_open_write("u"+string(pid)+".txt");
            file_text_write_string(txt,string(psave)); 
            file_text_close(txt) 
        }

The functions buffer_read_string and buffer_write_string use null-terminated strings, meaning that the end of the string is marked by a null (zero) byte. Your file contains binary data which likely contains null bytes, so this won't work. Also, you can't transfer a binary string between Game Maker and an extension for the same reason.

What you need to do instead is use the function buffer_write_buffer or buffer_write_buffer_part to copy the content of one buffer to the other. Also, there is no need to save the file first, you can also send the buffer directly to the server.

You should probably prefix the compressed data with the size (e.g. as uint32 or uintv), otherwise the receiver won't know how many bytes to read. Alternatively you can use buffer_get_pos and buffer_get_length in order to calculate how many bytes are left in the buffer, but that only works if the compressed data is the last thing stored in the buffer.

PS: You will get better compression if you store the values from the ds_list into the buffer one by one in an appropriate format, rather than converting the entire ds_list to a string.

Last modified: Thu, 28 May 2020, 0:57 (GMT+1, DST)

Comment #5: Wed, 27 May 2020, 11:03 (GMT+1, DST)

Quote

I have another one question:

I made a save file like this:

buffer_save = buffer_create();
buffer_write_string(buffer_save,ds_list_write(save_list));
buffer_zlib_compress(buffer_save)
buffer_rc4_crypt(buffer_save,'test')
buffer_write_to_file(buffer_save,'test.txt');
buffer_destroy(buffer_save);

On loading I do:

buffer_load = buffer_create()
buffer_read_from_file(buffer_load,'test.txt')
buffer_rc4_crypt(buffer_load,'test')
buffer_zlib_uncompress(buffer_load)
ds_list_read(load_list,buffer_read_string(buffer_load))
buffer_destroy(buffer_load)

This works very well, and in the end I have 3kb test.txt.
What I wanted to do, is to send this file to server, but there's no such command.
I tried to do this on client:

    buffer_clear(buff) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff,'test.txt')
        player_save = buffer_read_string(buff)
    }
    else player_save = 'null'
    
    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)
    buffer_write_string(buff, player_save)
    socket_write_message(server, buff);

And this on server:

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

        if psave <> "null" then 
        {
            txt=file_text_open_write("u"+string(pid)+".txt");
            file_text_write_string(txt,string(psave)); 
            file_text_close(txt) 
        }

I do recieve some data and save it to file on server, but this server save file is not equal to original player's save file.
For some reason, it works fine if I would not compress and crypt a test.txt (or uncompress and decrypt before writing to 'player_save', and need to compress and crypt again when server recieves info).
What I'm doing wrong?

Last modified: Wed, 27 May 2020, 19:10 (GMT+1, DST)

Comment #6: Tue, 26 May 2020, 18:24 (GMT+1, DST)

Quote

Thank you!

Comment #7: Tue, 26 May 2020, 16:13 (GMT+1, DST)

Quote

1. buffer_read_from_file does the actual reading and returns whether it was successful.

2. RC4 is a stream cipher, so encrypting and decrypting is the same operation. If you give it plain data it will be encrypted, if you then give it the same data again with the same key it will be decrypted.

Last modified: Tue, 26 May 2020, 16:14 (GMT+1, DST)

Comment #8: Tue, 26 May 2020, 1:17 (GMT+1, DST)

Quote

Hello! I'm using Http Dll 2 for GM8.1 and I have few qestions.

1. Is there a missing line in the "Usage example" when reading data from a buffer? I can see file missing error handling, but I can't find, where do you read data from a file.

2. For buffer_rc4_crypt it says "Encrypts or decrypts the buffer". How does game know when encrypting or decypting needed? I mean, ther's no buffer_rc4_decrypt or something, so how can I properly decrypt a buffer?

Last modified: Tue, 26 May 2020, 12:22 (GMT+1, DST)

Comment #9: Thu, 7 May 2020, 17:32 (GMT+1, DST)

Quote

It appears to be caused by specific combinations of window managers and graphics drivers. I hadn't heard any reports of issues with Compiz yet, I will add it.

Comment #10: Thu, 7 May 2020, 16:09 (GMT+1, DST)

Quote

Hi Maarten,

Just wanted to let you and other users know that on Ubuntu 18.04 with simplescreenrecorder 0.3.8-3 from the repo, there's similar glitches as described on "The recording occasionally flickers, showing parts of the desktop background instead of windows" with Compiz on Intel graphics. No problem when I switched to Marco as window manager to give it a go. So it may be worth adding Compiz next to Mutter under that question, as the amount of glitches was quite high.

Thank you for your great software! :)

Bert

Comment #11: Sun, 26 Apr 2020, 19:28 (GMT+1, DST)

Quote

The FFmpeg version (or one of the underlying libraries like libvpx) that SSR was compiled against does not match the version that you are currently using. In the 'about SimpleScreenRecorder' dialog you can see the versions of the FFmpeg headers and libraries, these should be the same. E.g.:

The solution is to install the correct version of FFmpeg and the underlying libraries, or recompile SSR and/or FFmpeg yourself.

Based on your error message I suspect that the mismatch is between FFmpeg and libvpx, which means that you would have to either update FFmpeg, update libvpx or recompile FFmpeg. After that you may have to update or recompile SSR as well.

This is normally something which is handled by package maintainers, so if you are only using the standard repository, you should probably report this to the maintainer.

Last modified: Sun, 26 Apr 2020, 19:32 (GMT+1, DST)

Comment #12: Fri, 24 Apr 2020, 19:18 (GMT+1, DST)

Quote

I'm trying to use ssr 0.4.0 (recently released) on Slackware 14.2. I installed it by the command 'slpkg -s sbo ssr'; which automatically installed the ffmpeg-3.2.4 dependency. However, even with ssr in version 0.3.11, the same problem happened: when I try to write to the webm container, and use the VP8 codec, the error appears:

[Muxer::Init] Using format webm (WebM).
[Muxer::AddStream] Using codec libvpx (libvpx VP8).
[VideoEncoder::PrepareStream] Using pixel format yuv420.
[libvpx @ 0x2824da0] v1.5.0
[libvpx @ 0x2824da0] Failed to initialize encoder: ABI version mismatch
[BaseEncoder::Init] Error: Can't open codec!
[PageRecord::StartOutput] Error: Something went wrong during initialization.

What can I do to solve this problem?

Comment #13: Sun, 19 Apr 2020, 13:30 (GMT+1, DST)

Quote

Hi Maarten,

many thanks, SimpelScreenRecorder lives up to it's name and expectations.

I did not manage to download a video on Youtube but this utility recorded it with perfect sound.

Keep up the good work.

Comment #14: Thu, 16 Apr 2020, 13:34 (GMT+1, DST)

Quote

Thank you very much! Now it all makes sense. My plan was to use the TV HAT for the Rpi4 along with a small antenna to play local digital channels. Then I want to use a screen recorder to record my favorite programs. Now that you explained that the RPi does not have an audio input I am not so sure that this is possible using a desktop pc screen but I 'll look more into it.

Comment #15: Thu, 16 Apr 2020, 12:02 (GMT+1, DST)

Quote

IIRC the raspberry pi does not have an audio input, so I'm not sure what you were trying to record in the first place.

When you connect it to a TV, the default audio interface changes to HDMI, which may have different behavior.

Comment #16: Thu, 16 Apr 2020, 1:20 (GMT+1, DST)

Quote

Hello!
I am trying to use SimpleScreenRecorder in a Raspberry Pi 4. It installs perfectly but each time I try to record something I get the following audio related error:

ALSA Input: Can't open PCM device!
Error: Something went wrong during initialization.

Any idea what it means and if I could somehow fix it?

By the way, if I do not check the "record sound" box, then SimpleScreenRecorder works just fine.

I am currently using the built-in speakers of my screen. The plan is to fix this issue and then connect the Pi to a TV.

Stay safe!

Update: I connected the Pi to a TV and SimpleScreenRecorder works just fine capturing video and audio. Strange.

Last modified: Thu, 16 Apr 2020, 2:05 (GMT+1, DST)

Comment #17: Mon, 30 Mar 2020, 0:25 (GMT+1, DST)

Quote

I'm glad you appreciate my work. I don't take donations though, but thanks for the offer :).

Comment #18: Sat, 28 Mar 2020, 16:30 (GMT+1, DST)

Quote

Geachte Maarten,
Where can I offer you a drink?
Your job's good and I totally want to donate!
Is it possible via Paypal?
Thanks!
Frédéric

Comment #19: Fri, 27 Mar 2020, 15:35 (GMT+1, DST)

Quote

nvidia_disable_flipping=yes

You don't need to scale it.
Youtube will accept MKV as well, there is no need to convert it to MP4.
I would recommend using the Youtube preset if you want to upload to youtube. If you want to improve the quality you could lower the 'constant rate factor' from 23 to 20, but it won't make a huge difference since youtube re-encodes the video anyway.

Comment #20: Fri, 27 Mar 2020, 1:41 (GMT+1, DST)

Quote

nvidia_disable_flipping=yes

Thanks for the reply. I fixed the NVIDIA issue.

If I understand correctly, I should record in full screen, my monitor is 1080p. Should I scale it or not?

I guess for videos that I don't need to do any editing on, I was hoping to use MP4 so I don't have to import it into kdenlive just to export it as an MP4, but I understand why now.

Do I use the Youtube container or no? Are you saying it will or won't be useful for Youtube uploads?

Comment #21: Thu, 26 Mar 2020, 22:47 (GMT+1, DST)

Quote

Assuming your monitor resolution is 1920x1080, and you are presenting in full screen, you will get the best quality if you let SSR record the entire screen with the resolution set to 1920x1080. But note that as a result of the higher-than-normal internet usage due to the Corona pandemic, Youtube has temporarily reduced the default video quality in order to reduce the overall network load. So you may not be seeing the full quality of your video unless you manually set the video player to 1080p when you view the video.

The Youtube setting will pick settings that are reasonable for uploading to Youtube with decent quality. Youtube will re-encode videos anyway so you won't see much improvement if you try to further increase the quality in SSR.

I do not recommend using MP4 in SSR because if your recording is interrupted for any reason, the MP4 file will become corrupted and you will have to restart from the beginning. WIth MKV you don't have this problem, you can always open the file and read it up to the point where it crashed. But you can export to MP4 from kdenlive if you want, since there's no risk of losing data in that case.

Regarding the NVidia message, if you are not seeing any glitches or flashes in your recordings then it's probably not an issue. In any case, if the dialog doesn't appear it's probably because you selected 'yes, always' or 'no, never'. To change it, open ~/.ssr/settings.conf and find the following line:

nvidia_disable_flipping=yes

Set it to 'ask' instead of 'yes' or 'no' and you will get the dialog again.

Last modified: Thu, 26 Mar 2020, 22:51 (GMT+1, DST)

Comment #22: Thu, 26 Mar 2020, 0:42 (GMT+1, DST)

Quote

I've been recording some educational videos for my students during this period of school closures. I like how simple SSR is to use. I want to improve my quality.

I record in SSR, upload to Youtube, and share the links. Sometimes I edit the videos in kdenlive, it just depends on if I have to do anything post-production.

The latest comments are years old so I wanted to ask a few questions to see if things are still the same.

I read that we should use either 720p 1280 X 720 or 1080p 1920 X 1080.

Does that mean our window size or our monitor resolution?

My monitor resolution is 1920 x 1080 so if I put it in full screen, will that get me the best quality?

Does a blurry screen result from putting my window size for Firefox to 1280 x 720 but my resolution is 1080p? I don't understand.

Also, some of the settings I have questions about.

I choose the Youtube setting from the Profile area, but what does that do? Does this somehow optimize the recording for YT?

What should I choose as the container? I've done it with MKV and MP4. When I've used MKV, I put it into kdenlive to edit, then exported it MP4. When I do MP4, I get an MP4 and I can upload directly into YT.

What's the difference in using these containers?

I used to get the error message about Flipping, and I have NVIDIA, but whether I turn it on or off in OpenGL settings, I am not getting the message anymore.

Does that mean this issue was fixed? I have a new custom built desktop and want to take advantage of hardware acceleration so I want the setting to be right for when I'm editing video elsewhere.

Comment #23: Mon, 23 Mar 2020, 12:52 (GMT+1, DST)

Quote

This was already fixed in the SSR git repository but the fix hasn't been released yet. If you can't compile from source, try running SSR with:

QT_SCREEN_SCALE_FACTORS="" simplescreenrecorder

More info here.

Comment #24: Mon, 23 Mar 2020, 12:49 (GMT+1, DST)

Quote

Try going into the properties of the Model Creator executable and run it in Windows 7 compatibility mode.

You're welcome :).

Comment #25: Mon, 23 Mar 2020, 1:50 (GMT+1, DST)

Quote

Generally it works well, but the result is a zoomed-in (scaled up?) view of the upper left-hand portion of the recorded rectangle/window/screen (depending on setting). In other words the lower and right -hand side parts are cut off. It may have something to do with screen resolution. My laptop is set for 3200:1800, but the only choice I'm given for Record the entire screen is 1600:900. I suppose I might work around this problem by setting the display to that resolution, but I'd rather not.

Comment #26: Sun, 22 Mar 2020, 16:49 (GMT+1, DST)

Quote

Hi Maarten,

Just want to thank you! I'm a Flemish person, living in Brazil. I have a language school here. Here the Covid 19 crisis is starting and schools are closed. We give classes online now. I've downloaded simplescreenrecorder to record my classes, so I can share them with students who weren't able to follow the class. Works perfectlyi! Thanks again!

Comment #27: Sun, 22 Mar 2020, 0:25 (GMT+1, DST)

Quote

hello, I'm not able to open models or save in this program, errors always appear like: "Failed to create the file" or "Failed to open the file. Make sure you have read access to the folder". What I do?

Comment #28: Thu, 27 Feb 2020, 11:56 (GMT+1, DST)

Quote

I cannot guarantee this, but it is unlikely that you will have any issues. Back in 2017 there was one SSR user that got VAC banned, but he was unbanned again fairly quickly once he contacted Valve:
https://github.com/ValveSoftware/csgo-osx-linux/issues/1454

Comment #29: Mon, 24 Feb 2020, 11:07 (GMT+1, DST)

Quote

Well, if I understood correctly, I won’t get a VAC ban if I follow this instruction. I want to record CS: GO.
^{P.S. Sorry for my broken English, this is not a oh native language.}

Comment #30: Sun, 19 Jan 2020, 1:34 (GMT+1, DST)

Quote

Those prefixes should not be necessary since I'm importing pylab into the main namespace. Which version of matplotlib are you using?

Last modified: Sun, 19 Jan 2020, 1:35 (GMT+1, DST)