Comment #1: Tue, 14 Jan 2020, 11:13 (GMT+1, DST)

Quote

Running the script on Windows python 3.8 64bit results in error:

If "close" is removed.

It seems that functions of modules are not properly prefixed.
(import numpy as np then np.array is used or matplot.array).

Last modified: Tue, 14 Jan 2020, 11:15 (GMT+1, DST)

Comment #2: Sun, 29 Dec 2019, 14:40 (GMT+1, DST)

Quote

I'm not sure what could be causing this. Do you have the same problem if you use the ALSA backend and configure it to record from the sound card directly (i.e. hw:0,0)?

Can you send me a recording with SSR that shows the issue, and also an audio recording from the same mic with different software (e.g. Audacity) that doesn't show the issue?

Last modified: Sun, 29 Dec 2019, 14:40 (GMT+1, DST)

Comment #3: Sat, 28 Dec 2019, 20:38 (GMT+1, DST)

Quote

Hello. I really like the screen recorder and was happy that I found it. I do have one problem with the audio. I'm hearing a very high pitch tone in the background on playback. I don't believe it's related to my mic because I've recorded with other recorder apps and the audio track doesn't have this tone. It's not really loud, but you can hear it and sounds similar to tinnitus (ringing in ears).

I've tested WebM and MP4, and they both have this high pitch tone. I'm recording from a headset mic. It's not a deal-breaker, but it's a shame I can hear it because the test of the app is great.

Do you have any advice on how to fix?

System is Intel PC/Arch linux desktop, mic going through onboard sound card via PulseAudio backend.

Comment #4: Tue, 26 Nov 2019, 23:48 (GMT+1, DST)

Quote

This isn't supported, see:
https://github.com/MaartenBaert/ssr/issues/196

Comment #5: Mon, 25 Nov 2019, 11:45 (GMT+1, DST)

Quote

Hi there. At first - I very like this application, thank you author very much for it.
My question is - what codec should I use for gif container? I've tried about a half of them and I had "Can't write header" error for each.

Comment #6: Fri, 15 Nov 2019, 8:33 (GMT+1, DST)

Quote

no, unfortunately, there is not. but you are free to test for yourselves and prove me wrong.

Last modified: Fri, 15 Nov 2019, 8:33 (GMT+1, DST)

Comment #7: Wed, 11 Sep 2019, 11:25 (GMT+1, DST)

Quote

Yes the connectors definitely do have an effect, especially the cheaper ones. Typically the reflected signal changes by a few percent when adding an adapter.

Comment #8: Wed, 11 Sep 2019, 11:20 (GMT+1, DST)

Quote

It is real but it's coincidental. Due to constructive and destructive interference it is possible that at some point, all reflections cancel each other out, and the total reflected signal will be almost zero. But since this is at -30dB we're talking about a difference of 0.1%, which is not significant. Basically it's noise, it will be different for every unit due to manufacturing tolerances.

Comment #9: Wed, 11 Sep 2019, 10:52 (GMT+1, DST)

Quote

Are you sure there are no other differences between the files? crf=0 should definitely look better.

keyint is expressed in frames, not seconds. keyint=1 means every frame is a keyframe. If you want a keyframe every second at, say, 30 fps, you would use keyint=30. Note that the actual keyframes may not be exactly 30 frames apart though, since the encoder tries to align keyframes with scene changes whenever possible. So you can't really rely on this. The default keyframe interval is something like 250 frames I believe, which isn't very good for editing.

Comment #10: Fri, 30 Aug 2019, 18:54 (GMT+1, DST)

Quote

I imagine any lossy materials used in the connector or coax that change the Q may cause these to be a little broader.

And 5.8GHz do you actually see the impedance bump from the connectors?

Have you ever popped a few adapters inline to see how it changes?

Comment #11: Fri, 30 Aug 2019, 18:40 (GMT+1, DST)

Quote

Wish I had some nice test equipment for this stuff.
I have an old thing that only goes up to 1GHz.

Have you ever pulled off the plastic radomes just to see if it changes much?
I will sometimes pop a radome itself in the microwave for a few seconds.
If it gets warm or hot it's not good material for 2.4Ghz+

Comment #12: Fri, 30 Aug 2019, 18:33 (GMT+1, DST)

Quote

I'm curious about the total dropout below -30 on the one antenna.
Is that real?
And why would the other antenna not have a similar dropout?

Comment #13: Fri, 30 Aug 2019, 18:27 (GMT+1, DST)

Quote

And all of this said and tested.
At the end of the day it works very poorly.
In all of my tests comparing this antenna to a simple dipole the dipole has always
captured much more signal at a distance over the same test range.

Comment #14: Sun, 28 Jul 2019, 20:05 (GMT+1, DST)

Quote

thanks for clarifying.

actually, crf value was a typo, was 0 already.

zooming in and comparing the 2 pngs (lossless crf:0 vs lossy crf:20), the latter is definitely the winner - though it makes no sense to me?

regarding the keyinterval, what would be the drawback of leaving this at a default value of 1? this way, accurate cuts of at least 1sec intervals would be possible, after all.

Last modified: Sun, 28 Jul 2019, 20:06 (GMT+1, DST)

Comment #15: Sun, 28 Jul 2019, 17:51 (GMT+1, DST)

Quote

What you describe:

codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1

... isn't lossless. If you want actual lossless, try:

codec:other, libx264, bitrate:0, preset=veryfast,crf=0,keyint=1,pixelformat=yuv444

or if your editing software supports H.264 RGB:

codec:other, libx264rgb, bitrate:0, preset=veryfast,crf=0,keyint=1

The option crf=0 is what makes it lossless. keyint=1 turns every frame into a keyframe to make editing easier.

Last modified: Sun, 28 Jul 2019, 17:52 (GMT+1, DST)

Comment #16: Wed, 24 Jul 2019, 13:13 (GMT+1, DST)

Quote

hi maarten,

there you go, i've only ever used avidemux with my h.264 screencasts (ssr default settings + crf 20) and cutting (without errors) is only possible on i-frame base in this mode. i wished accurate cutting was also possible with these final encodes.

now, i noticed something strange when recording losslessly (codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1). i took stills of a scene from a lossless screencast vs lossy sc (h.264, crf 20, preset veryfast) and i could clearly spot artefacts in the lossless picture. the lossy one looks far superior. how is that possible after all?

apart from crf, bitrate and the keyinterval, the settings should be identical, i guess.

Comment #17: Tue, 23 Jul 2019, 2:38 (GMT+1, DST)

Quote

H.264 should definitely allow accurate cuts, if it doesn't its a limitation of the editing software, not the codec. In any case, H.264 lossless should work about as well for editing as mjpeg if you add the keyint=1 option. There are some other lossless alternatives (like huffyuv) but they don't compress as well as H.264.

By the way, you may want to use libx264rgb instead of libx264, or use libx264 with pixelformat=yuv444.

Comment #18: Tue, 23 Jul 2019, 2:29 (GMT+1, DST)

Quote

Currently I'm not working on this, but I will keep it in mind for the future. It should be possible to make a size-optimized design at the expense of some of the other specs.

Comment #19: Sun, 14 Jul 2019, 10:44 (GMT+1, DST)

Quote

just a quick question: is lossless mjpg recording possible with ssr? if not, which lossless codec to choose from in order to do precise cuts with avidemux later on? h.264 (lossless) unfortunately does not allow accurate cuts.

Comment #20: Thu, 11 Jul 2019, 11:54 (GMT+1, DST)

Quote

I have put pagoda and a triple feed antennae on my receiver, and subjectively - ie amount of breakup and range - when compared to other antennae (I do not have the necessary test equipment) they really do seem to work very well indeed.

They are impressive designs.

I would like to use a pagoda on the craft, but as it is a small quad, weight becomes a big issue. I notice that the pagoda is designed specifically for RG402. RG402 is quite heavy, and so are SMA connectors. RG178 is much lighter, and so are MMCX connectors.

I did find this - https://uk.banggood.com/5_8GHz-2_2dBi-RHCP-Mini-Pagoda-Antenna-MMCX-Connector-for-FPV-RC-Airplane-p-1341375.html?gmcCountry=GB&currency=GBP&createTmp=1&utm_source=googleshopping&utm_medium=cpc_bgcs&utm_content=garman&utm_campaign=ssc-gbg-all&ad_id=332556156911&gclid=EAIaIQobChMIopjXlMis4wIVqrvtCh14bw7pEAQYDyABEgKLaPD_BwE&ID=224&cur_warehouse=CN - on the Banggood website which is pretty light (2-3g all in), but having read the comments above and your replies, I doubt it is likely to work that well. (1) It isn't RG402 - difficult to be sure but more likely RG178 or similar, and (2) the bottom PCB is missing.

I assume they have just modified your design, unclear whether it has been tested.

I wondered if there was any likelihood of a pagoda design based round RG178 (or RG316 at a pinch) being produced? I accept your point in the comments that flexible coax is not ideal in terms of keeping everything in place (so would need styrofoam spacering), and of course, RG178 is much higher loss at 6GHz. However flexible coax is what is needed here from a mechanical mounting perspective.

Also, on the other hand, tiny quads don't tend to fly so far, so maybe some inefficiency is less of an issue.

I would be interested to know if anything like this is on the cards?

Comment #21: Wed, 3 Jul 2019, 16:24 (GMT+1, DST)

Quote

I panelized some antennas. https://github.com/japhillips87/pagodas

The first gerber is the Pagoda 2 version. It has 3 RHCP and 3 LHCP on one PCB. The second gerber is the Pagoda 2B version. It also has 3 RHCP and 3 LHCP. I have not ordered these, but I uploaded it to JLCPCB and it doesn't have any errors.

Comment #22: Mon, 10 Jun 2019, 21:53 (GMT+1, DST)

Quote

Theoretically possible but very tricky - at 5.8 GHz the value would end up being extremely small (in the range of 0.1 pF). The parasitics of the pads and solder would be higher than the actual capacitance value.

Comment #23: Mon, 10 Jun 2019, 21:50 (GMT+1, DST)

Quote

Http Dll 2 doesn't compress the data unless you do it manually. Are you sure that the buffer is actually compressed? Have you taken care of the length prefix of the message properly?

Comment #24: Mon, 10 Jun 2019, 12:24 (GMT+1, DST)

Quote

Perhaps a stupid idea: Wouldn´t it be possible to add a trimmer capacitor in the design to do some frequency tuning and compensate tolerances during assembly?

Comment #25: Tue, 28 May 2019, 2:40 (GMT+1, DST)

Quote

Hello, I'm trying to write a custom server for a client that uses HTTP DLL 2 to send data to a socket.

I would like to code the server in nodejs (or perhaps even python), but the data sent to the socket cannot be simply uncompressed using zlib.inflate (it says there's a bad header check)

Do you know how you would be able to make a receiver (in another language) that can read HTTP DLL 2 socket messages?

Comment #26: Mon, 13 May 2019, 11:49 (GMT+1, DST)

Quote

ok, so to sum it up, recording at a given framerate (say 60) in ssr will be maintained, even after trimming with avidemux, though probably reported differently, because of changes in depending libraries?

good to know ;)

Comment #27: Sun, 12 May 2019, 18:16 (GMT+1, DST)

Quote

The length of the coax is not very important, but the diameter is. RG178 is thinner than RG402 and this will affect the performance.

Comment #28: Sun, 12 May 2019, 18:15 (GMT+1, DST)

Quote

mkv, 60fps, h.264 + crf 20 + veryfast preset + uncompressed audio

Since your screen runs at 60 Hz, recording at anything other than 60 fps will likely just results in some frames being duplicated or dropped. So it makes sense to record at the same frame rate as your screen. So unless you can change your screen to 50 Hz I would stick to 60 fps. The exception would be if you disable vsync in your compositor as well as the application being recorded, and configure the application to run at a much higher frame rate than your recording frame rate. But this will likely cause tearing.

Whether disabling the compositor will introduce screen tearing depends on your GPU driver as well as the application being recorded. The only way to eliminate screen tearing completely is to use OpenGL recording.

This is a common feature request, but it hasn't been implemented yet.

Comment #29: Sun, 12 May 2019, 17:59 (GMT+1, DST)

Quote

This is because the underlying libraries (ffmpeg) have changed. It also depends on the choice of codecs and file format. It shouldn't affect the frame rate of the actual video though, since each frame has its own timestamp.

Comment #30: Wed, 8 May 2019, 11:47 (GMT+1, DST)

Quote

hello there,

i am not sure where to address this in first place, perhaps you can help here already?

recently, i found out that the reported framerate of my 60.000 ssr mkv (h.264) recordings are interpreted differently, depending on the software in use.

while mediainfo shows a framerate of 60.119 fps, avidemux' file properties states a value of 62.500 fps, which is on par with shotcut on the other hand.

there is old ssr mkv recordings of mine, which report a uniform framerate of 60.000 fps in every software, also after trimming/exporting with avidemux, so i wonder what has changed after all?