LINUX.ORG.RU

Сильно тормозит прокрутка в VLC на аудио

 


0

1

Я кончено понимаю, что видео файлы воспроизводить непросто. А чего с аудио 🎵?

Берём тестовый файл

wget http://traffic.libsyn.com/anjunabeats/ABGT321_LiveShow0803196392.m4a

Открываем. Слушаем чуть-чуть. И перематываем (просто тыкаем ползунок) в середину. Всё - полминуты ждать до воспроизведения. Пробовал и на Linux и на macOS. Виснет интерфейс с большим CPU больше минуты.

Есть какие аудиоплееры, чтобы показывали разбиение по трекам у прогрессбара как VLC?

★★★★★

Последнее исправление: fornlr (всего исправлений: 4)

Секунд 10 задержка есть. Это формат какой-то дегенератский, туда видеопоток mjpeg ещё засунут.

Deleted
()
Ответ на: комментарий от Deleted

Ну обложка в одну картинку, не?

fornlr ★★★★★
() автор топика

mpv показывает разметку по трекам, не тормозит. на файл какой-то кривой:

mpv ABGT321_LiveShow0803196392.m4a 
Playing: ABGT321_LiveShow0803196392.m4a
[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set
 (+) Video --vid=1 (*) (mjpeg 300x300 0.000fps)
     Video --vid=2 [P] (mjpeg)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
File tags:
 Artist: Above & Beyond
 Album: ABGT083
 Composer: Above & Beyond
 Title: ABGT321_LiveShow0803196392
[autoconvert] Converting yuv444p -> yuv420p
VO: [vdpau] 300x300 yuv420p
[vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate.
AO: [alsa] 48000Hz stereo 2ch float
Invalid video timestamp: 0.000000 -> 0.000000
AV: 00:00:00 / 02:00:00 (0%) A-V:  0.000
[lavf] Too many packets in the demuxer packet queues:
[lavf]   audio/0: 200493 packets, 157287040 bytes
[lavf]   video/1: 0 packets, 0 bytes

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:15:59 / 02:00:00 (13%) A-V:  0.000
No video PTS! Making something up. Using 0.000139 FPS.
(...) AV: 00:15:59 / 02:00:00 (13%) A-V:  0.000
[lavf] Too many packets in the demuxer packet queues:
[lavf]   audio/0: 200476 packets, 157286400 bytes
[lavf]   video/1: 0 packets, 0 bytes
AV: 00:16:05 / 02:00:00 (13%) A-V:  0.000

Exiting... (Quit)

bass ★★★★★
()
Ответ на: комментарий от bass

Мне кажется, что там верно написано, что у тебя что-то кривое 😉

mpv ABGT320_LiveShow0103196392.m4a
Playing: ABGT320_LiveShow0103196392.m4a
[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set
 (+) Video --vid=1 (*) [P] (mjpeg 300x300 0.000fps)
     Video --vid=2 [P] (mjpeg)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
File tags:
 Artist: Above & Beyond
 Album: Neil Ribbens's Album
 Composer: Above & Beyond
 Title: ABGT320_LiveShow0103196392
Displaying attached picture. Use --no-audio-display to prevent this.
VO: [opengl] 300x300 yuv444p
AO: [pulse] 44100Hz stereo 2ch float
AV: 00:00:07 / 02:00:00 (0%)


Exiting... (Quit)
fornlr ★★★★★
() автор топика
Ответ на: комментарий от athost

Не суть. От процессора время зависит, КЭП.

Дольше всего, если в конец ткнуть. Прям мотает плёнку на кассете :D

На медленном проце может и полминуты быть. У меня 10 секунд на старом Intel i5 3450

fornlr ★★★★★
() автор топика
Последнее исправление: fornlr (всего исправлений: 1)

Есть какие аудиоплееры, чтобы показывали разбиение по трекам

DeaDBeeF

А чего с аудио 🎵?

Что-то с индексом. В Audacious и SMPlayer вообще не работает перемотка, сам понимаешь, значит дело не в плеерах. Лечится:

ffmpeg -i ABGT321_LiveShow0803196392.m4a -map 0:2 -map 0:4 -c copy ABGT321_LiveShow0803196392-fixed.m4a
Правда в этом случае потеряется названия первых двух треков, а в DeaDBeeF разбиение по трекам полностью испортится. Я так понимаю чаптеры хранятся в двух местах.
1. В виде Metadata контейнера и здесь можно увидеть, что там нет названий первых двух треков:
ffmpeg -i ABGT321_LiveShow0803196392.m4a
    Chapter #0:0: start 0.000000, end 3640.365000
    Metadata:
      title           : 
                      : 			
    Chapter #0:1: start 3640.365000, end 7200.506667
    Metadata:
      title           : 
                      : 				
    Chapter #0:2: start 274.683333, end 688.225000
    Metadata:
      title           : 2. DT8 Project ‘Cycles’ (Anjunabeats)
    Chapter #0:3: start 688.225000, end 1048.800000
2. И видимо в tx3g в потоке 0:1
    Stream #0:0(eng): Data: bin_data (tx3g / 0x67337874), 0 kb/s
    Metadata:
      handler_name    : Apple Text Media Handler
    Stream #0:1(eng): Data: bin_data (tx3g / 0x67337874) (default)
    Metadata:
      handler_name    : Apple Text Media Handler
Но ffmpeg отказывается переносить эти потоки в m4a
Tag tx3g incompatible with output codec id '100359'
В mp4 переносит, но плееры тогда теряют разбивку.
А может быть дело не в tx3g, а вторые теги хранятся в APEv2 (или что там используется в m4a контейнере). Причем возможно распиханы они по всему файлу на границах песен, а при перепаковке ffmpeg их оттуда удаляет. Да, кривоватый потоковый файл. Я бы на твоем месте его не трогал, слушай в DeaDBeeF.

anonymous
()
Ответ на: комментарий от anonymous

Вот так можно очистить файл от ненужной метаинформации:

ffmpeg -i input.m4a -map 0:2 -map_metadata -1 -map_chapters -1 -c copy innocent.m4a
или
ffmpeg -i input.m4a -map_metadata -1 -map_chapters -1 -c:a copy -vn -sn innocent.m4a
А cue написать самому. Или сконвертировать chapters в cue.
-c это аналог -c:v copy -c:a copy -c:s copy
-map указать свой
-vn -sn значит видео (и jpg обложки) и субтитры не копировать.
Если указать -map 0 наоборот, будут скопированы все треки, а не только дефолтные.

Дольше всего, если в конец ткнуть. Прям мотает плёнку на кассете

Судя по скорости декодирует все до запрошенной отметки.

anonymous
()
Ответ на: комментарий от anonymous

VLC судя по скорости декодирует все до запрошенной отметки.

А мог бы послать тебя лесом как SMPlayer и Audacious и отказаться перематывать.

anonymous
()
Ответ на: комментарий от anonymous

Да, правильные главы (теги) хранятся в Data: bin_data (tx3g). В потоке 0:1 или 0:0. Обратите внимание, ffmpeg не признает их за субтитры (опция -scodec или -c:s будет игнорироваться), а считает как data. SMPlayer показывает название песен как субтитры, если их включить в меню. А извлечь можно в Yamb https://www.videohelp.com/software/YAMB Редактирование-Разделение потоков из файлов Скрин http://www.imagebam.com/image/0f642b1158273634
Yamb это GUI над mp4box, а mp4box доступен в линуксе в пакете gpac. Командная строка

mp4box -srt 1 ABGT321_LiveShow0803196392.m4a
Извлек для тебя https://pastebin.com/1kbmMCXC

anonymous
()
Ответ на: комментарий от anonymous

ffmpeg не признает их за субтитры (опция -scodec или -c:s будет игнорироваться)

Также будет игнорироваться -sn

а считает как data

Но, если эту data все-таки впихнуть

ffmpeg -i ABGT321_LiveShow0803196392.m4a -map 0:2 -map 0:1 -map 0:0 -c copy output.mp4
то ffmpeg ее преобразует в bin_data (gpmd), такой формат используют камеры GoPro. Короче, лучше использовать mp4box.

anonymous
()
Ответ на: комментарий от EXL

mpv не перематывает

У меня перематывает. Но версия старая 0.27.2 из Ubuntu 18.04, ибо забил на обновления из-за глюков

fornlr ★★★★★
() автор топика

Если хочешь слушать именно в VLC, можешь перепаковать в mka с помощью mkvtoolnix. Только галочку с jpeg сними, а иначе VLC будет также тормозить, похоже эта jpg и вызывает тормоза у VLC. mka Deadbeef не поймет, а Audacious покажет без разбивки на главы. SMPlayer такой mka будет играть нормально, треки переключаются в меню Обзор-Главы, названия доступны.

anonymous
()
Ответ на: комментарий от fornlr

Ничего себе старая, всего на две версии отстает от апстрима. Вот в 16.04 старая 0.14. Кроме того в Ubuntu mpv версии не меняет, сюрпризов ждать неоткуда.

anonymous
()

Зато видео в VLC так не тормозит, как в SMPlayer'е. На не самом новом железе, на нагруженной системе это хорошо заметно. Но MPC-HC все равно быстрее всех.

anonymous
()
Ответ на: комментарий от anonymous

Хейтерам я напомню, что он под GPL, как и Wine. Даже в новостях на opennet по идее публиковать можно.

anonymous
()
Ответ на: комментарий от anonymous

MPC-HC юзает системные кодеки. Ксли ты китайский klite поставил (как и должен был) то я бы не взялся утверждать, что там всё соответствует gpl.

anonymous
()
Ответ на: комментарий от anonymous

Вспомнились две цитаты. Я уже не могу найти исходник, поэтому привожу приблизительно.

1. Одному исполнителю надоело проверять совместим ли очередной плагин с OS X, в конце концов он просто купил ноуты с виндой, чем очень удивил коллег-музыкантов яблочников.

2. Фильм «Таинственный лес» 2004.
Героя Хоакина Феникса ранил ножом ревнивый сумасшедший. Старейшина закрытого ото всех лагеря разговаривает с местным врачом:
- Что мы можем сделать?
- В данной ситуации мы можем только молиться и надеяться на лучшее.
- А что мы можем сделать, если забыть об ограничениях?...

anonymous
()
Ответ на: комментарий от anonymous

Ну наверно всё же в плеерах

Берём Tiësto https://feed.pippa.io/public/streams/593eded1acfa040562f3480b/episodes/5bc1ab...

Тоже самое. Ну он по часу делает (а не два), поэтому эффект меньше. Но всё же заметен, если тыкать прокруткой около в конец.

И да, в iTunes всё нормально. Но на линуксах то его нет.

fornlr ★★★★★
() автор топика
Последнее исправление: fornlr (всего исправлений: 3)
Ответ на: комментарий от fornlr

Ну наверно всё же в плеерах

Возможно это баг libavcodec декодеров/демуксеров, которые используют почти все линуксовые плееры. В данном случае дело как ни странно в jpg coverе, именно картинка вызывает тормоза и глюки перемотки в плеерах (по крайней мере в VLC точно). Проблема в том, что, чтобы ее убрать и не потерять главы, надо перемуксить контейнер, для этого софт должен корректно обращаться с bin_data tx3g информацией, но ни ffmpeg, ни mp4box корректно не переносит эти данные. Конечно, если нужна разбивка на теги (и правильная), а иначе проблем нет (выше давал команду очистки файла от лишнего). mkvtoolnix корректно обрабатывает tx3g чаптеры, но он переводит в свой mka/mkv формат, в случае со звуком менее подходящий и корректно-поддерживаемый.

anonymous
()
Ответ на: комментарий от fornlr

в iTunes всё нормально

В Foobar тоже, хотя он не показывает разбивку на треки, так как это прерогатива скорее видео плееров (чаптеры mp4).

на линуксах то его нет

На линуксах много плееров, но в основном они базируются на одних компонентах и, если баг в апстриме, это затронет всех. Нет действительно независимого разнообразия, полностью с нуля написанных решений от разных разработчиков (не считая разве что GUI и небольших фиксов).

anonymous
()

Прочитал всю портянку но так и не нашёл понятного ответа на вопрос: прекращает ли тормозить vlc, если вырезать из аудиофайла видеокадр длинной в несколько минут? В конце концов, если для этой ереси ещё и vdpau задействовать, то что вообще могло пойти не так?

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Прекращает, если перепаковать в mka. На mka с jpg также тормозит.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.