| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
calls instead
|
| |
|
|
| |
cancellation
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lets a camera's own H.264 or MJPEG go straight onto the network on Windows as
it already could on Linux, so nothing has to be decoded and re-encoded.
Finding out what a camera offers takes rather more than the single v4l2 ioctl
it takes on Linux: the camera has to be instantiated, its output pins found,
and each pin's stream capabilities walked through IAMStreamConfig, reading the
FourCC out of the BITMAPINFOHEADER in every media type. Asking for the result
is spelled differently too - dshow has no input_format option and takes the
choice from AVFormatContext::video_codec_id instead, which is what
"-vcodec mjpeg" ahead of "-i" sets, and which has to be set on a context
allocated by us rather than by avformat_open_input().
Opening now loosens its constraints a step at a time rather than giving up on
the format at the first refusal. Listing a format, producing it at a given
size, and producing it at a given frame rate are three separate claims, and
cameras honour them independently: an integrated webcam here offers MJPEG but
not at 640x480 15fps, and was falling all the way back to re-encoding. The
frame rate is given up first, then the size, and the format last, since the
format is the one that decides whether anything has to be re-encoded at all.
What the camera settles on is what gets announced to the peer, so this changes
what is sent rather than what is claimed about it.
That relaxation exposed an assumption that was already wrong: the encoder was
hard-wired to kFrameRate with a plain incrementing pts, while the pre-existing
"let the camera choose" fallback had always been able to open without a frame
rate at all. A camera delivering 30fps therefore produced a stream whose
timestamps claimed half that. It now takes the rate from the opened stream,
and the keyframe interval with it, so two seconds between keyframes stays two
seconds - kGopSize is gone, a fixed frame count no longer meaning a fixed
duration.
Every FourCC a camera reports is logged, mapped or not. An integrated camera
offering nothing but uncompressed types while advertising MJPEG under v4l2
would have meant the Windows Camera Frame Server had already decoded it, with
nothing to be done from here - worth being able to tell apart from a FourCC we
simply failed to map, which is what this turned out not to be.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBqDgvq3Ty6C6BjLFH16bw
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Capture already went through FFmpeg's "dshow" demuxer, which does the job -
unlike the audio case there is nothing here the platform offers that we cannot
reach any other way, so there is no reason to drive DirectShow ourselves. Two
things were missing to make it work.
Enumeration, because the demuxer has none: it can only print device names to
the log with -list_devices, which is no use to a settings dialog. The list is
built in videodshow.cpp instead, walking the same CLSID_VideoInputDeviceCategory
the demuxer walks, so the names handed back are the ones it matches on. Where a
friendly name is not unique - two identical cameras - later duplicates fall
back to the device path, which the demuxer also accepts.
And the "video=" prefix, since DirectShow namespaces its devices by type and
the same name behind "audio=" would be a microphone. The name is stored
unprefixed and decorated at open time, so what the settings dialog shows and
writes stays readable.
Also adds a last-resort open with no constraints at all. DirectShow refuses a
video_size or framerate it cannot produce exactly rather than settling for the
nearest, so a camera with an unusual set of modes would otherwise give no
picture; whatever comes back is scaled by the transcode loop anyway.
The failure message on Windows now names the likely cause. A camera that
enumerated but will not open is usually not a broken camera: Windows lists
devices it then refuses to instantiate, which is what the "Let desktop apps
access your camera" privacy setting being off looks like from here, and what
another application holding the camera looks like too. None of them are
distinguishable from a real fault at that level, and the bare "I/O error" sent
me looking at the wrong layer entirely.
compressedFormats is left empty on Windows, so "prefer compressed formats" has
no effect there - finding out what a DirectShow camera can deliver means
walking its output pin's media types through IAMStreamConfig, which is a good
deal more than the one v4l2 ioctl that fills this in on Linux.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBqDgvq3Ty6C6BjLFH16bw
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PlatformDriverName() now takes a direction, and answers with one of two kinds
of name. A bare one - "alsa", "pulse", "oss" - is an FFmpeg libavdevice driver
opened the way everything else here is opened. One prefixed "platform-" is not
an FFmpeg driver at all: what follows names a platform audio API the caller
drives itself through NativeAudioBackend.
Windows and macOS take the second route, because both provide acoustic echo
cancellation but only to streams that declare themselves part of a voice call
- AudioCategory_Communications on WASAPI, the VoiceProcessingIO audio unit on
CoreAudio - and libavdevice's wrappers have no way to ask for either. Doing our
own cancelling on platforms that would have done it better below us is not a
trade worth making.
Where the platform will not do it, speexdsp does: one EchoCanceller per call,
shared by both directions through a QSharedPointer, since the call is torn down
without joining either audio thread. Playback feeds it the far end as it hands
it to the device; capture subtracts before encoding. Alignment is left to the
FIFO - in steady state its backlog settles at the sound card's buffer depth,
which is also how far ahead of the speaker the playback side runs, leaving only
the room for the filter tail to model. Measured 27 dB ERLE on a 60 ms echo with
1.6 dB of loss on speech when nothing is playing.
On macOS the canceller is a single audio unit that renders and captures at
once, so both directions share one refcounted instance. Ringtones deliberately
get a plain HALOutput unit instead - opening a voice unit to play a bell would
switch the microphone on and prompt for permission.
Linux gains a choice of alsa or pulse, with PulseAudio device enumeration
through libpulse when configure finds it.
Info.plist gains NSMicrophoneUsageDescription and NSCameraUsageDescription.
Without them macOS 10.14 and later kills the process on first use of the
microphone or camera rather than asking, so calls did not merely fail, they
took the application with them.
Two things fixed along the way that were not about echo at all: the settings
dialog's microphone test paced playback by counting timer ticks, which on
Windows meant a 20 ms packet every ~31 ms because the system timer granularity
is 15.6 ms - the recording came out slowed down and chopped up. It now paces
against a QElapsedTimer. And chooseEncoderSampleFmt() uses
avcodec_get_supported_config() where available, the AVCodec format arrays it
replaced having been removed in FFmpeg 9.
Only the Linux paths are verified here; the Windows and macOS backends compile
to nothing on this machine and have been reviewed by hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBqDgvq3Ty6C6BjLFH16bw
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
hevc, h264, mjpeg
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
AudioVideoCallController never cleared its callwindow pointer after a
call ended, so start_call()/call_from() would see it as non-null
forever and silently refuse every subsequent call.
CallWindow now sets WA_DeleteOnClose and emits callwindow_closed() from
closeEvent(), mirroring the ChatWindow/MsgUIRouter pattern. The
controller resets its pointer to 0 in response, and end_call() closes
the window once the hangup/reject has been handled.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wires ringback, busy, special-information (unreachable) and an
electromechanical-bell incoming ringtone into
AudioVideoCallController, each played on its own QThread since
TonePlayer::play() blocks. Device selection reads audio.playback_device
and audio.ring_device from Settings so it follows what's configured in
SettingsDialog.
Centralizes the FFmpeg libavdevice output driver name
(alsa/audiotoolbox/dsound) in AudioDevice::PlatformDriverName() rather
than hardcoding ALSA, so it can also back capture/playback later.
Adds toneplayer.{h,cpp} to the autotools build and adds the missing
GPL v3 header to the touched files that lacked it.
|
| |
|
|
| |
audiovideocallscontroller and callwindow
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
for Linux
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
in contact list
|
| | |
|
