а если устройство захвата звука поменять ?

(Ответ для Anton Farygin на комментарий #1)
> а если устройство захвата звука поменять ?
Только один вариант предлагается.
Поправка
> аудио hw:0,0

Ошибка воспроизводится также в p10.
Стенд в тестировании: server 10.0 x86_64

Спасибо за информацию.

Также актуально для архитектуры aarch64
В тестировании
http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/server/aarch64/alt-server-10.1-aarch64.iso

Версия в сизифе 3.0.18-alt2

Поведение поменялось.

VLC некорректно записывает видео и звук.
После настройки устройств записи изображение с камеры передается на экран проигрывателя и фиксируется в одном положении. Нажимаем на кнопку "Запись",  прибавляются секунды и в фоне слышно звук, которые якобы записался. При нажатии на кнопку "Стоп" изображение на экране проигрывателя пропадает, а файл записи не появляется по ранее указанному пути.

Ошибка актуальна, уточняю поведение в 3.0.20 и 3.0.21.

Шаги:
0. # apt-get install -y vlc vlc-plugin-h264
(Иначе "Ошибка вещания/перекодирования: VLC не может открыть кодер h264 видео.")
1. Открыть приложение VLC.
2. В меню выбрать Медиа -> Открыть устройство захвата
3. На вкладке выбрать режим захвата "Video camera", указать аудио и видеоустройства, далее нажать на стрелку рядом с Воспроизвести -> Конвертировать.
4. В открывшемся окне выбрать опцию "Преобразовать", выбрать опцию "Проигрывать результат" и указать место сохранения в параметре "Конечный файл".
5. Нажать кнопку "Начать", сказать что-нибудь в микрофон.
6. Нажать кнопку со значком "стоп" в плеере.
7. Открыть созданный файл.

Фактическое поведение:
- При записи слышно эхо звука (ожидаемо ввиду "Проигрывать результат").
- При записи видео появляется не сразу и после появления зависает.
- При воспроизведении завершенной записи корректно воспроизводится аудио и видео.

Ожидаемое поведение:
- При записи видео не должно зависать.

Дополнительно:
- Если был открыт вид "Плейлист" (Ctrl + L), видео может вообще не отобразится при записи (появляется черный экран).
- Если выбрать просто "Воспроизвести" вместо "Конвертировать", видео не зависает.


Проверялось на виртуальных машинах (увеличение RAM, CPU, видеопамяти не влияет на результат):

[sisyphus] vlc-3.0.21-alt1.x86_64
[p11+377171] vlc-3.0.20-alt1.x86_64
[p11] vlc-3.0.20-alt1.x86_64

ALT Workstation 11.0 x86_64
ALT Workstation K 11.0 beta20250213 x86_64


Видеоустройство: /dev/video0 (камера ноутбука через SPICE):

lsusb:
> Bus 002 Device 005: ID 174f:2459 Syntek Integrated Camera

inxi:
>  Device-2: Syntek Integrated Camera driver: uvcvideo type: USB rev: 2.0 speed: 480 Mb/s
>    lanes: 1 mode: 2.0 bus-ID: 2-4:5 chip-ID: 174f:2459 class-ID: fe01 serial: <filter>


Аудиоустройство: hw:0,0 (SPICE ich9-intel-hda):

lspci:
> 00:17.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)

inxi:
> Audio:
>   Device-1: Intel 82801I HD Audio vendor: Red Hat QEMU Virtual Machine driver: snd_hda_intel
>     v: kernel bus-ID: 00:17.0 chip-ID: 8086:293e class-ID: 0403
>   API: ALSA v: k6.12.24-6.12-alt1 status: kernel-api tools: alsactl,alsamixer,amixer
>   Server-1: PipeWire v: 1.2.7 status: off with: 1: pipewire-pulse status: active
>     2: pipewire-media-session status: off 3: wireplumber status: active tools: pw-cat,pw-cli,wpctl

Ошибка актуальна для версии vlc-3.0.23-alt2

После уточнения в комментарии 7 звук записывается корректно, и осталось ровно то, что описано в 39942: при "Конвертировать" с включённым "Проигрывать результат" предпросмотр показывает первый кадр и замирает, при простом "Воспроизвести" всё работает, а записанный файл корректен.

Причина общая: в Qt-диалоге цепочка вывода строится как #transcode{...}:duplicate{dst=std{...},dst=display}, то есть предпросмотр декодирует уже закодированный x264 поток. Задержка кодировщика (lookahead и B-кадры, порядка секунды-двух) намного больше задержки модуля display (100 мс), поэтому для живого источника кадры предпросмотра приходят "опоздавшими" и отбрасываются. Исправление будет в 39942.

*** This bug has been marked as a duplicate of bug 39942 ***

*** This bug has been marked as a duplicate of bug 39942 ***