usbcamcord - simultaneous display & record of usb cam

[greengeek]

Using USB webcam (without audio) to display monitored area and make video recording.
- Cheap security camera surveillance.

This is a trial gtkdialog gui that allows the user to choose one of their usb webcams as a source for recording and simultaneous display.
Intended for use with Ozsouth's FossaMid variants (as they seem quite fast) but may work elsewhere.
(Further development is planned to allow video output to be in x minute segments but for now record start/stop is manually controlled)

I don't know yet which pups or which hardware will permit the in-sync display and recording - but so far on my machines this is successful - and useful for monitoring purposes as a sort of poor man's security camera.

usbcamcordv08.jpg (38.82 KiB) Viewed 1591 times

.
The "Interrogate" function helps the user decide what formats and resolutions are supported by their chosen usb cam.
(Please let me know if your usbcam supports a specific format that you think I should add...)

NOTE: If your webcam supports a compressed stream such as mjpeg this is the best option for speed and will allow you to choose higher resolutions.
(Current default is yuyv422 as that is more common than mjpeg but just select whatever stream is available from your cam. May need to add other formats depending on cam model)

Currently the gui is only preprogrammed with resolutions up to 640x480 for testing purposes. Higher res can cause image tearing - but all depends on your machine and graphics card. You can type whatever you wish to try in each field.

For testing purposes place the file in /root (That is where it will store the video output by default).

Please rename and delete the false .gz suffix - then make executable. Click to run.

V08 released:
(Better gui arrangement and choice of mkv/avi/mp4 output formats)

usbcamcord_v08.gz

(4.26 KiB) Downloaded 57 times

.
.
V05 superceeded
Improved the code for interrogation of the cam stream formats to make it easier for user to know what formats are available (requires gxmessage which i think is pretty standard in most pups):

usbcamcord_v05.gz

Delete false .gz suffix

(4.47 KiB) Downloaded 42 times

.
.
Changelog:
v08 - Current. Combined interrogation of raw & compressed format buttons using MochiMoppel syntax. Extra output formats.
v05 - Superceeded. Improved interrogation of raw & compressed formats.
v04 - Superceeded. Cam format interrogation direct from gui was not easy to view.

[Rantanplan]

Hi @greengeek,

Bravo and Hurrah !
Tested and approved with an old packard-bell 1go ram, 40 go hdd, 2 go swap and webcam logitech (model unknow).

This works very well with Toutou Linux Slaxen 6.0 (32 bit french derivative created by Esmourguit).

Later, will have another output format ?

Many thanks to you.

[mikewalsh]

@greengeek :-

VERY nice, Ian. I did wonder if you were continuing with this; I suspected you would. Working well for me in my recent, heavily-customized install of Tahr64. I'm using one of John van Sickle's recent static ffmpeg builds here.....v5.1.1. Wouldn't suit you, I suppose, 'cos it's around 75 MB in size.....but the beauty of these is that every single AV dependency is already built-in to them, so regardless of what else you might have on the system, you can drop these in and just start using them straight away.

All credit to you for the GTKdialog GUI. It takes a lot of messing around with XML markup, doesn't it? I never had the patience with it, which is why I switched to using YAD years ago!

One little glitch.....and even then, it's all very subjective. Like everything else, I run a range of different media players. For me, VLC doesn't want to know for playback.......but anything mPlayer-based (mPlayer itself, SMPlayer, MPV, Gnome MPlayer, etc) is perfectly happy to play it back. Even Kodi seems happy with it....

I suspect summat is missing that VLC wants. No biggie.

----------------------------------------

Nice to see you got the "sync" problem licked! A query (you might have known this was coming); any plans to add audio as well? I've been experimenting a bit with ffmpeg myself, but where video seems relatively easy to obtain, audio is a whole different ball-game. Where mPlayer seems able to combine audio & video at source, ffmpeg appears to want to record the two as separate files, following which it's then up to the user to combine the two into a final complete item prior to playback. It's great to give the user such granular control, but it seems counterproductive to ease-of-use to insist on doing things this way.

Or perhaps I simply haven't found the right bit of the documentation yet. There IS a hell of a lot of it.....

Anyhoo; well done!

Mike.

[wiak]

@greengeek :-
...
All credit to you for the GTKdialog GUI. It takes a lot of messing around with XML markup, doesn't it? I never had the patience with it, which is why I switched to using YAD years ago!
...

Fortunately, gtkdialog GUI results can end up pretty good if coder has enough patience. However... my own opinion of coding with gtkdialog is indeed: it is horrible! One tag in the wrong place and a nightmare to debug sometimes. Life is too short and unfortunately many a currently used gtkdialog video capture type app, for example, is not going to work in future because of Wayland (or need remade accordingly...sigh). I do not myself plan to keep, as an example, wex alive in that scenario - could be done, but fundamental changes would be required, which I simply won't spend time on. Admittedly, the Wayland issue is not so much to do with the gtkdialog, but rather the functional ffmpeg-related code underneath and more specifically the code involved in the screen capturing.

[mikewalsh]

@greengeek :-

Okay. After some research - and a fair bit of head-scratching! - here's a line that will record both video AND audio, AND give a real-time sync'd preview, too:-

Code: Select all

ffmpeg -f alsa -ac 2 -i hw:5 -f v4l2 -i /dev/video0 -vcodec libx264 recording.mp4 -map 0:v? -vf "format=yuv420p" -f xv Camera_display_output

You'll notice I've borrowed some of the last part of your own command; changed the window title, and the output file name & format. There's a reason for that "?" after the -map clause. According to the ffmpeg documentation - and don't ask me to find it again, 'cos I can't recall quite how I found it the first time! - if ffmpeg can't find the exact parameters as specified, then the addition of the question mark will permit it to hunt around & cobble together something that will work from what it CAN find.

"hw:5" is the sound card of my Logitech c920 in Tahrpup64. If you want to use it to record from your own webcam, run

Code: Select all

arecord -l

.....in the terminal to discover the sound card number for your cam, and just substitute accordingly. This one is quite happy playing back under VLC, too.....

(Of course, you CAN record from any sound card you want, so long as it has a microphone. Again, just run "arecord -l" to make sure you obtain the correct device number for that card.)

Just out of curiosity, where did you dig that "format=yuv420p" up from? I'm still trying to figure out exactly what it IS specifying! Seems to work, though.....and 'xv' I recognise as one of the output formats listed by SMPlayer.

-------------------------------------------

I may look into re-writing MultiCam to use ffmpeg instead of mplayer as the 'engine'. It'll take me a while, though. I'll have to crank up the enthusiasm levels to get back into that as a project again!

Mike.

[greengeek]

Uploaded v05 which is much better in terms of showing the user what raw stream formats and compressed stream formats (and resolutions) their selected cam is capable of.

[greengeek]

Tested and approved with an old packard-bell 1go ram, 40 go hdd, 2 go swap and webcam logitech (model unknow).
This works very well with Toutou Linux Slaxen 6.0 (32 bit french derivative created by Esmourguit)

Excellent, thanks for the report. Nice to know it can work on such a low ram machine.

Later, will have another output format ?

Probably. For testing purposes I found .mkv gave the best output quality so I decided to stick with that for now - but it should be easy for me to add a selection box for mkv, avi and mp4 and then the user can choose. I will do a bit more testing first...

[greengeek]

Working well for me in my recent, heavily-customized install of Tahr64.

Hi Mike thanks, for the report - I am glad it is working elsewhere too.

I'm using one of John van Sickle's recent static ffmpeg builds here.....v5.1.1. Wouldn't suit you, I suppose, 'cos it's around 75 MB in size.....but the beauty of these is that every single AV dependency is already built-in to them, so regardless of what else you might have on the system, you can drop these in and just start using them straight away.

I am definitely likely to use it on a variety of machines - however my current testing machine is running Ozsouth's Fossa9.5 Mid which apparently has a cutdown "ffmpeg-sml" so I just wanted to see what it was capable of. (actually seems pretty good!)

One little glitch.....and even then, it's all very subjective. Like everything else, I run a range of different media players. For me, VLC doesn't want to know for playback.......but anything mPlayer-based (mPlayer itself, SMPlayer, MPV, Gnome MPlayer, etc) is perfectly happy to play it back. Even Kodi seems happy with it....
I suspect summat is missing that VLC wants. No biggie.

Do you mean that the mkv output file is unable to be read by VLC?

Nice to see you got the "sync" problem licked!

I was fortunate to find a post from SuperUser member Mario Mey here (Can only wish I was smart enough to do this stuff myself...)

A query (you might have known this was coming); any plans to add audio as well? I've been experimenting a bit with ffmpeg myself, but where video seems relatively easy to obtain, audio is a whole different ball-game.

From your other post it looks as if you have this sorted. That Mario Mey link did originally contain alsa switches (arguments?) to allow ffmpeg to record the audio - but i was keen to limit the variables and did not need audio at this stage.

Either in that post (or some other...) I read that the key with getting successful ffmpeg results is to ensure that you specify EXACTLY what arguments and formats you want to use - leaving nothing for ffmpeg to guess and waste time over.
(Which is interesting in the light of your other comment about the use of the "?" to have ffmpeg search for meaningful options... Maybe using the "?" kicks off some code in ffmpeg that is specifically designed to handle such things. And maybe not using the "?" creates some of the ffmpeg errors I have often seen wasting time in the terminal in various other previous ffmpeg experiments)

I will be interested to keep testing this and watching further development. FFmpeg seems such a powerful tool and it would be great to get to grips with it more.

[fredx181]

One little glitch.....and even then, it's all very subjective. Like everything else, I run a range of different media players. For me, VLC doesn't want to know for playback.......but anything mPlayer-based (mPlayer itself, SMPlayer, MPV, Gnome MPlayer, etc) is perfectly happy to play it back. Even Kodi seems happy with it....
I suspect summat is missing that VLC wants. No biggie.

Do you mean that the mkv output file is unable to be read by VLC?

I've often experienced that VLC has problems with videos created by ffmpeg (not just mkv), first thought it had to do with the VLC version, but later versions seem to have the same problem, e.g. not being able to seek, or static picture only, or distorted view (can't really remember), indeed with Mplayer or MPV it's fine.

[greengeek]

where did you dig that "format=yuv420p" up from?

I think this can be replaced with "yuyv422" - which seems to be a common output format from usb webcams.
One way to find what formats a webcam supports is to enter the following into a terminal
(Changing dev/video value as needed according to which webcam...):

Code: Select all

x=$(ffmpeg -f v4l2 -list_formats all -i /dev/video0 2>&1 | grep -Eo 'Raw.*$'); gxmessage "$x"

I suspect it is best to use exactly the format specified by the webcam.

[greengeek]

@greengeek :-

Okay. After some research - and a fair bit of head-scratching! - here's a line that will record both video AND audio, AND give a real-time sync'd preview, too:-

Code: Select all

ffmpeg -f alsa -ac 2 -i hw:5 -f v4l2 -i /dev/video0 -vcodec libx264 recording.mp4 -map 0:v? -vf "format=yuv420p" -f xv Camera_display_output

My audio card is "0" rather than "5" so I changed that - but still had issues. The sound worked at the beginning for a short burst - then again at the end for another short burst. Weird.
However, using the Mey syntax it worked if I changed the sound card spec to hw:0,0

Code: Select all

ffmpeg -f v4l2 \
    -framerate 30 \
    -video_size 1024x768 \
    -input_format mjpeg \
    -i /dev/video0 \
    -f alsa \
    -i hw:0,0 \
    -c:a pcm_s16le \
    -c:v mjpeg \
    -b:v 64000k \
    output.avi \
    -map 0:v \
    -vf "format=yuv420p" \
    -f xv display

I could possibly build the choice of audio card into the gui. But how many different permutations might there be??
(And in my case I am using a non-audio webcam on a laptop that has a separate audio card - so i can't really emulate the situation that is in play when the user has a usb webcam with an inbuilt additional audio interface)

NOTE :Obviously this syntax does not work for webcams that only have raw stream and lack a compressed stream.

[greengeek]

Later, will have another output format ?

If you have time please give this a try and tell me if this is helpful (s'il vous plait!! )

usbcamcord_v06.gz

Delete false .gz suffiz

(4.6 KiB) Downloaded 83 times

[mikewalsh]

@greengeek :-

Yup; I agree with you about the addition of audio being a minefield. It not only varies from machine to machine, but OS to OS.......and playback even varies a bit from one media player to another. In Tahr64, audio quits recording 5 seconds before the video; try as I might, I cannot figure out why. Yet in, say, Bionic or Fossa it doesn't...?

*scratches head...*

(Admittedly, My Tahr64 install IS something of a "Frankenpup", so that might have some bearing on it..!)

And yes; ffmpeg certainly is powerful.....from what I can see of it, you could spend a lifetime learning all the ins & outs of the thing, and still never manage to exhaust the possibilities inherent in it. The options are, well..........."extensive" doesn't really do the options list justice, does it?

@fredx181 :-

Heh. Coo, I'm glad to hear I'm not the only one that's found that with VLC. It annoys me a bit, 'cos really VLC is my favourite media player (when it behaves itself!)

Mike.

[greengeek]

Released v08.
Improves the gui interrogation of formats & resolutions supported by selected usbcam.
Adds extra output formats.

(Please report any issues - much appreciated!)

[mikewalsh]

My audio card is "0" rather than "5" so I changed that - but still had issues. The sound worked at the beginning for a short burst - then again at the end for another short burst. Weird.
However, using the Mey syntax it worked if I changed the sound card spec to hw:0,0

Yeah, this seems to be another part of the minefield, apparently.

For some machines/apps, specifying "hw:0" seems to be enough. Others insist on the sub-device being listed as well ("hw:0,0"). In still other cases, "plughw:0" or "plughw:0,0" is used. Never quite understood this one; @wiak used it in his WeX screencaster OOTB, though it didn't see MY cards, and I had to remove the 'plug' portion in order to regain functionality.

But this is what I mean; for his hardware/software/OS set-up, it probably worked fine..... (*shrug...*)

(Seems that "plughw:0,0" does some initial samplerate conversions plus one or two other 'house-keeping' chores, and generally "looks after" the user a wee bit more. There again, it very much depends on the coding in use, the hardware in use, the kernel in use.....)

Let's take a squizz at v08, shall we?

Mike.

[mikewalsh]

@greengeek :-

Okey-doke. Initial tests in my Tahr64 "Frankenpup" (sorry 'bout this; it's not really representative of a 'standard' Pup/Dog/KL-type OS as they come OOTB, I know...)

Various combos all seem to work fine here; I'm now using a 'remote' install of the newest JvS 'static' ffmpeg, sym-linked into each of my Pups. At 90MB+ for all the binaries (ffmpeg, ffprobe, qt-faststart), it seems crazy installing these in each and every Puppy; a sym-linked set works nicely.

'Yuyv422'; yup. 'Mjpeg' is OK, too. 'Mkv', 'avi', 'mp4'.....all fine. Again, this c920 Logitech isn't really representative of the run-of-the-mill user's hardware; the c920 may be over 10 years old at this point, but it was THE top-end Logitech cam when it was released, and was so far ahead of the competition in terms of what it supported & what it was capable of it was, shall we say, a bit "eerie"! It's still in demand globally, it seems; good things stand the test of time, I guess. Me, I have 2; one for the HP desktop rig, and another I bought for the Latitude earlier this year....

I DO like the listing for streams, formats, etc. Nicely done, mate.

I'm working on a modified MultiCam-portable; ffmpeg-based instead of mplayer, re-designed GUI, etc. I'll let you have the link when I'm happy with it; you can let me know what ya think.

I'll test in other Pups, AND on the lappie when I get time. All looking good, ATM.

Cheers!

Mike.

[Rantanplan]

Later, will have another output format ?

If you have time please give this a try and tell me if this is helpful (s'il vous plait!! )

usbcamcord_v06.gz

Hi @greengeek ,

Thank you for the last version (v08).

I have tested with yuyv422 and mjpeg : only mp4 doesn't work.
May be, the ffmpeg version is too old, or not compiled to support mp4 format. It's not important.

"My" ffmpeg" (9 years old) :

Code: Select all

ffmpeg version 2.2.3 Copyright (c) 2000-2014 the FFmpeg developers
  built on Jun 17 2014 16:13:40 with gcc 4.8.2 (GCC)
  configuration: --prefix=/usr --enable-libmp3lame --enable-libx264 --enable-libfaac --enable-pthreads --enable-small --enable-postproc --enable-libvorbis --enable-gpl --enable-shared --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-debug --enable-bzlib --enable-zlib --enable-libspeex --enable-version3 --enable-runtime-cpudetect --enable-x11grab --enable-libschroedinger --enable-libtheora --enable-libxvid --enable-swscale --enable-libvpx
  libavutil      52. 66.100 / 52. 66.100
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 33.100 / 55. 33.100
  libavdevice    55. 10.100 / 55. 10.100
  libavfilter     4.  2.100 /  4.  2.100
  libswscale      2.  5.102 /  2.  5.102
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100

mkv and avi give very goods results : splendid !

ffmpeg's power and your inventivity and creativity product beautiful things.

Bravo greengeek.

Good sunday.

[greengeek]

Various combos all seem to work fine here;...
'Yuyv422'; yup. 'Mjpeg' is OK, too. 'Mkv', 'avi', 'mp4'.....all fine.

That's great news, thanks for testing.

I'm working on a modified MultiCam-portable; ffmpeg-based instead of mplayer, re-designed GUI, etc. I'll let you have the link when I'm happy with it; you can let me know what ya think.

[greengeek]

I have tested with yuyv422 and mjpeg : only mp4 doesn't work.
May be, the ffmpeg version is too old, or not compiled to support mp4 format. It's not important.

Thanks for testing.
The following commands may be useful (They will create text files that list your codecs and formats)

Code: Select all

ffmpeg -codecs > codecs.txt

Code: Select all

ffmpeg -formats > formats.txt

Is mp4 shown in these lists?

[Rantanplan]

Hi @greengeek

Is mp4 shown in these lists?

In formats's list : yes, mp4 is for D(ecode) and E(ncode).
But, in codecs's list it is not.

I'll try with Lunar Lobster and/or Triton-8 as soon as possible.

I'll feed back to you.

Thanks.

[mikewalsh]

@greengeek :-

'Kay. I have it running okay in Tahrpup32. However; I am already noticing one thing. Older Pups - and the Tahrs in particular - do need ffmpeg upgrading. The inbuilt one doesn't recognise half the commands you're using here, and the Tahrs have their own peculiarity.......that being the mystifying use of libav/avconv for all media commands by default. Ffmpeg doesn't even get used in Tahr, unless you specify it (this all dates back to the ffmpeg/libav 'fork' split a few years earlier, which was pretty near the closest thing ever seen to civil war in the open-source community. It was NOT amicable, and a lot of very strong-willed people voiced many extremely nasty things about each other; personality clashes & near-continuous arguments about working methods were the order of the day, apparently.)

Here's a blog posting from about 18 months after the row erupted. It gives a very good picture of what was going on at that time:-

http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

-------------------------------------------

That aside, if you're serious about using ffmpeg, this is why I recommend the use of John van Sickle's 'static' ffmpeg packages. They're a good way to get an up-to-date ffmpeg package even in an elderly OS that wouldn't normally support that new a version; most Puppies use a dynamically-compiled build, that has to hunt around the system for exactly the right dependencies. And that's why trying to transplant ffmpeg from a newer Puppy into an older one won't usually work, because it's very fussy about the libs it was compiled against.

I know they're huge compared to Puppy's tiny version, but that's because they already contain everything they need. They don't need to look for anything in the system.

One suggestion.....if I may? It might be prudent to also offer a greater range of framerates, too; lower framerates are one of the best ways to keep the overall size of recordings down. I'd suggest adding 10, 15 and 20.... I know 10's getting a bit low, but for long term monitoring of your property, say, 10 fps is quite detailed enough. When I worked for a local security firm 25 years ago, our 'statics' - guys who were were stationed in one location all night, as opposed to 'mobile' officers like myself who drove around all over the place - never had their company CCTV recorders dialled up very high in that respect.

------------------------------------------

More reports will be forthcoming. We WILL find the point at which Pup's native build starts to recognise the commands..... Next, I'm going to see how my custom Slacko 560 handles the JvS statics, and if usbcamcord works okay there. Watch this space.

Mike.

[Rantanplan]

greengeek,

I've tried with another puppy (Triton-8 by petihar).

mp4 format is OK with it.

So tested and approved

Thanks

Bests regards

[mikewalsh]

Okay. Slacko 560 won't have it, in any way, shape or form.

I "upgraded" the ffmpeg to the newer version, but neither your usbcamcord, nor my test re-working of MultiCam wanted to know. I then made an interesting discovery. Although MultiCam is mPlayer-based, mPlayer itself must call ffmpeg at least some of the time, because the original MultiCam suddenly doesn't work, either!

So; back in with the 'old' ffmpeg, and MultiCam is now behaving again. My re-work of MultiCam now uses a sym-link to an "external" NEW ffmpeg, with a small re-write to the recording script which lets it use this instead. I've scripted a switcher for a small, external directory which allows me to link the appropriate version of ffmpeg for testing your script, too.

The things we do, eh? Mind you, try doing all this stuff anywhere other than Puppy and yr OS would tie itself up in knots!

Mike.

[mikewalsh]

Okay here in Xenialpup32 - again with sym-linked 'newer' ffmpeg. Notice the Pups are gradually getting newer..!

.....and the same goes for my own "test-bed" (the MultiCam upgrade).

Mike.

[greengeek]

I've tried with another puppy (Triton-8 by petihar).
mp4 format is OK with it.
So tested and approved

Appreciate the testing & report - thank you!

[greengeek]

One suggestion.....if I may? It might be prudent to also offer a greater range of framerates, too; lower framerates are one of the best ways to keep the overall size of recordings down. I'd suggest adding 10, 15 and 20.... I know 10's getting a bit low, but for long term monitoring of your property, say, 10 fps is quite detailed enough.

Yeah, this is an area where I just don't have a feel for the best way forward and initially just stuck with fps values I had seen elsewhere.
If I select say fps30 and push the resolution up to say 1280x800 I see messages saying that "the driver changed fps from 1/30 to 1/10" - so the fps choice seems somehow self-limiting. Probably based on OS, hware, graphics card, ffmpeg version, v4l2 version etc etc.

If I use this syntax to display my webcam it is interesting to look at the output:
ffmpeg -framerate 30 -video_size 1280x800 -i /dev/video0 -f xv display

Code: Select all

root# ffmpeg -framerate 30 -video_size 1280x800 -i /dev/video0 -f xv display
ffmpeg version 3.4.2 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.3.0 (GCC)
...much blurb deleted
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
[video4linux2,v4l2 @ 0xc4f480] The driver changed the time per frame from 1/30 to 1/10
Input #0, video4linux2,v4l2, from '/dev/video0':
...

Clearly it says "Nope - you shall have 10fps and that's it..."

By the way - thanks for all the testing Mike. Very helpful to see where it works and where it doesn't.
(Had not even thought about trying it in my old favourite Slacko 5.6. Did try your special version in a couple of machines but had no mouse or kbd so unsuitable kernel for me i suspect...)

Later EDIT : It was bothering me that the default stream of my webcam could not be displayed at 30fps when 1280x800 was selected so I played around a bit. Do you have a webcam that supports both raw and mjpeg streams? If so i am keen to know if the following comparison works for you too:

This syntax gives me a live feed from the webcam but not at the combo of fps and resolution that I specify.
(Obviously too much data to handle so the ffmpeg messages show that the driver drops the fps to 10...)

Code: Select all

ffmpeg -framerate 30 -video_size 1280x800 -i /dev/video0 -f xv LIVE_FEED_FROM_WEBCAM

However, this syntax seems to tap into the mjpeg stream out of the cam and DOES allow the combo of higher fps and higher resolution:

Code: Select all

ffmpeg -framerate 30 -video_size 1280x800 -input_format mjpeg -i /dev/video0 -vf "format=yuyv422" -f xv LIVE_FEED_FROM_WEBCAM

Comparison of the messages in the ffmpeg window shows that the incoming mjpeg stream allows the system to handle the higher data flow successfully.

(These last 2 syntax are useful on puppies that do not have ffplay installed - such as Ozsouth's F95Mid that I am using for these tests)

[mikewalsh]

@greengeek :-

Yup. Both of those one liners work fine with the c920. Why d'you think I'd been after getting one for so many years?

Even when it was released to market over 10 years ago, the c920 stood head & shoulders above anything else then available. It supported so MUCH stuff, OOTB, it was enough to make most multimedia freaks dribble at the thought of it....

There's a lot of stuff on the market nowadays that is easily its equal.....even superior in some respects. But those cams also have some pretty hefty price tags attached. The c920 was for many years up in 3-figure plus price territory here in the UK.....but in recent years, many retailers are selling them off at half-price or less, just to 'make way' for newer, more expensive tech.

Be that as it may, for many folks they're still one of the best all-rounders on the market, and work nicely in Linux, as they're plug'n'play, and support the UVC kernel driver OOTB (which has been in the kernel for years). Plug it in, and off ya go! Global demand is still high a full decade after they launched, which gives you some idea of just how competent the original design really was..!

There's an excellent, in-depth review of it over at TechRadar:-

https://www.techradar.com/reviews/logitech-c920

And that's why I bought a second one, for last year's purchase; the refurbished Dell Latitude D630. On top of those, I've got another half-dozen or so assorted 'cams kicking around, from various price points across the spectrum.....yet in every case, I made certain to do my research before buying them, ensuring they supported the UVC driver. When you dig a bit, and start looking into it, it's surprising just how many of them do.

Finding a webcam to work with Linux, OOTB, is not the chore it used to be years ago. Not any more.

Mike.

[mikewalsh]

@greengeek :-

Running nicely in Xenialpup64 on the Dell Latitude. Still needs the newer ffmpeg, however. And in Fossapup64 9.5 - Phil B's original - working as you would expect. Ffmpeg is up to the task here, so the newer JvS 'static' is not required.....

Mike.

[greengeek]

Running nicely in Xenialpup64 on the Dell Latitude. Still needs the newer ffmpeg, however. And in Fossapup64 9.5 - Phil B's original - working as you would expect. Ffmpeg is up to the task here, so the newer JvS 'static' is not required.....

Hi Mike, quick question about ffmpeg if i may - what is your experience about whether or not ffmpeg statics can be treated as a "portable" sort of thing? Is it something you can drop into a variety of pups without damage? Or is it necessary to chop out any previous "native" ffmpegs?

As you mentioned - Tahr32 was a strange beast in ffmpeg terms - is there an easy way to give Tahr32/64 a nice ffmpeg upgrade (as a single pet or portable maybe??).

I see so much potential in the power of ffmpeg it would be nice to have it's behaviour consistent from pup to pup.
(Maybe a wider topic for a dedicated thread?)

[ozsouth]

@greengeek - ffmpeg-sml .pet should work with non-usrmerge Ubuntu type pups (as well as Fossa64 pups) - it is actually from ScPup64-20.06, with lib paths adjusted.