Hacker News new | ask | show | jobs
by irishcoffee 91 days ago
> Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.

This example seems very hand-wavy. What camera?

1 comments

A Logitech FullHD camera on USB, but I doubt that the problem was camera-specific. I believe that I would have seen the same behavior on any high-resolution USB camera.

In FreeBSD, the command required for recording was very simple and it worked flawlessly. In Linux, it was more complex and there were various stuttering problems at maximum resolution. I am still using those cameras, but I have not tried them again in Linux. In Linux they worked worse than in FreeBSD around 5 years ago, perhaps nowadays there is no longer any problem in Linux.

This was intended to be an example that you cannot know a priori whether a given device will work better on FreeBSD or on Linux. In general, there is a greater probability for Linux to have good support than for FreeBSD, but there are also counterexamples, so you cannot be certain which is better until you try both.

I am sorry, I have a hard time accepting this level of detail, acknowledging it was half a decade ago.

In a nutshell, you content that FreeBSD running on the same hardware as "a linux" performed better with camera operations. However, you did not specify even a specific camera model, or the interface(s) used to interact with the camera.

I have zero issue accepting that a BSD is better than a linux at things, pretending otherwise is foolish. However, this specific example isn't tracking.

I have already said that it was an USB camera, using the UVC protocol, and that it had FullHD resolution. Nothing else really matters about the interface.

FreeBSD has a dedicated service for USB cameras, webcamd, and it worked very well for capturing video and audio at maximum resolution, and without interference from any other programs that were running concurrently on the server. As I have said, in Linux not only the required configuration was more complex, but I tried several programs and all had stutter problems at FullHD resolution (while other programs were also running on the computer). That was the status at that time. Now, many kernel versions later, I assume that such problems no longer exist, at least not with old cameras.

I do not see what is not tracking for you in this example. It is not an isolated example, for many years FreeBSD was known to have less problems than Linux in handling video streams and audio streams with low latency and constant throughput. More recently, Linux has also improved, but in the past unreliable performance with certain video/audio devices was not unusual (i.e. where other programs running concurrently caused video/audio drops or delays).

That’s fair. I’m struggling to understand how Linux had a harder time interfacing with a USB byte stream than a bsd would. A model for the camera would be great!
I think that it was the Logitech C920, which is still available.

But like I have said, I do not think that the model mattered much. IIRC the camera had an internal video encoder, because otherwise uncompressed FullHD video would not pass through USB 2.0.

The differences between FreeBSD and Linux at that time were at 2 levels. Regarding the user interface, FreeBSD happened to include in the base system programs dedicated for using such a camera, so their use was very simple. On Linux I had to search and install a suitable package, and those that were available were more general video applications and because of that their configuration to do the specific thing that I needed was more complex.

Besides the simpler interface, there was the stuttering problem on Linux, which was caused by the scheduling policies of the kernel. Perhaps it would have been possible on Linux to find a way to ensure a higher priority for the video and audio handling, to not be preempted by the concurrent programs running on the server, but since on FreeBSD everything worked fine out of the box there was no reason for me to investigate how that could be done on Linux.