MPlayer: Ваша система также не спешит играть это!

Question 1

Я просто попытался воспроизвести видеофайл AVCHD на 1 080 пунктов, зарегистрированный на уровне 60 кадр/с с моим цифровым однообъективным зеркальным фотоаппаратом Sony на моей рабочей станции Ubuntu 12.04, и к моему удивлению MPlayer не смог играть видео гладко. Я скопировал файл в локальный жесткий диск.

Видео играет медленнее, чем оно должно и A-V desync продолжить расти постоянно (приблизительно 1 секунда desync в 10 секунд воспроизведения). Один из этих 8 потоков ЦП стреляет в 100%.

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

Спецификации рабочей станции:

ЦП: Intel Quad Core i7-920 @2.67GHz
GPU: Nvidia GeForce 9600 GSO 512
RAM: 8 ГБ
Compiz при функционировании гладко, хотя я выключил его для этого тестирования (никакое улучшение воспроизведения видео)
Система обычно является молнией, быстрой и быстро реагирующей.
Проигрывание MP4 с h264 потоком на 1 080 пунктов на уровне 30 кадр/с хорошо работает.

  
root@boss:~# glxinfo | grep direct
direct rendering: Yes

root@boss:~# glxinfo | grep vendor
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation

Mplayer производят:

valprj@boss:~$ mplayer 00006.MTS 
MPlayer svn r34540 (Ubuntu), built with gcc-4.6 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 00006.MTS.
libavformat version 53.21.1 (external)
Mismatching header version 53.19.0
TS file format detected.
VIDEO H264(pid=4113) AUDIO A52(pid=4352) SUB Teletext(pid=4608)  PROGRAM N. 1
FPS seems to be: 59.940060
Load subtitles in ./
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.35.0 (external)
Mismatching header version 53.32.2
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12 
A:   6.6 V:   6.1 A-V:  0.496 ct: -0.017 453/453 96% 10%  0.6% 221 0 


           ************************************************
           **** Your system is too SLOW to play this!  ****
           ************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
    e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

A:   7.8 V:   7.2 A-V:  0.602 ct: -0.017 520/520 97% 10%  0.6% 286 0 
[h264 @ 0x7fe0a0468380]concealing 136 DC, 136 AC, 136 MV errors
A:  17.1 V:  15.6 A-V:  1.495 ct: -0.017 1022/1022 97%  9%  0.6% 779 0 

Exiting... (Quit)

Вещи я попробовал

Проигрывание с -vc ffh264vdpau помогший немного. desync отношение стало 1 секундой desync в 34 секунды воспроизведения, и видео скорость является почти правильной. Использование ЦП значительно понизилось (20% на самом высоком потоке ЦП). Все же я все еще добираюсь:

Ваша система также НЕ СПЕШИТ играть это!

сообщение от MPlayer.
Проигрывание с -lavdopts skiploopfilter=all сделанный видео игрой правильно. ЦП колеблется приблизительно в 93% и парения синхронизации A-V приблизительно 0,263 с

Вопрос

Таким образом, мой вопрос - это - Вы сказали бы, что разумно для mplayer испытать это много затруднений при воспроизведении того видео на моих аппаратных средствах, или Вы полагаете, что существует программная проблема здесь? Возможно, драйвер Nvidia?

Любые идеи ценились бы!

Question 2

Я не уверен, что вам все еще нужна помощь, но я буду публиковать сообщения для будущих пользователей ... Я считаю, что проблема в том, что в конфигурации mplayer по умолчанию используется только одно ядро процессора ... Попробуйте передать опцию -lavdopts threads = n (где n - количество используемых потоков).

mplayer -lavdopts threads=4 00006.MTS

Question 3

Question 4

TLDR? Удостоверьтесь, что Ваш регулятор частоты ЦП не изменяется некоторым демоном или инициированным событием сценарием (например, сценарием управления питанием).

(Скучная) история

У меня была эта проблема в двух различных системах Ubuntu, особенно при воспроизведении h264/x264 видео. Воспроизведение видео замедляется, в то время как аудио продолжается как нормальное. Иногда это нагоняет отдельно, но иногда это вступает во владение за 30 секунд до того, как это происходит!

Используя диаграмму в реальном времени использования ЦП, я заметил, что использование ЦП становится намного больше, когда проблема происходит (по крайней мере, как пропорция частоты тока, которую я, к сожалению, не отслеживаю).

Одно временное приспособление должно взаимодействовать с MPlayer, заставляя это нагнать справедливо быстро, при помощи одного из следующих методов:

Измените скорость воспроизведения путем нажатия [ затем ]
Переключатель в/из полном экране путем нажатия F дважды
Перемотка и перемотка вперед путем нажатия Left затем Право

Но любопытно когда я записал сценарий для отправки тех ключей автоматически, обходное решение не нагнало как ожидалось! Кажется, что фактическое физическое взаимодействие с клавиатурой требовалось...

Причина: регулятор powersave!

Наконец, я нашел, что проблема относилась к регулятору ЦП. Это кажется сценарием /etc/pm/power.d/cpu_frequency (на моей Ubuntu 12.04), периодически устанавливает регулятор частоты на powersave, даже при том, что я остаюсь включенным к питанию переменным током. (Это может произойти из-за программной ошибки, или аппаратных средств, например, изворотливого силового кабеля.)

Вскоре после этого (иногда секунды, иногда минуты) сценарий задерживает регулятор к ondemand, таким образом, не могло бы быть легко обнаружить этот случай! (Я обнаружил его путем добавления некоторых входящих в сценарий: echo "[$(date)] $0 was run with args $*" >> /tmp/cpu_frequency.log)

Временное обходное решение (хороший для тестирования)

Первоначально я работал вокруг проблемы путем запущения этого небольшого скрипта в терминале при просмотре видео:

while true; do cpufreq-set -c 0 -g performance ; cpufreq-set -c 1 -g performance ; sleep 2; done

Этот сценарий требует, чтобы у Вас был пакет cpufrequtils установленный: sudo apt-get install cpufrequtils.

Это просто гарантирует, что ЦП будет работать в полной скорости в любом случае, осуществляемый каждые 2 секунды. (Достаточно редко я мог бы видеть, что A/V потерял синхронизацию на мгновение, но затем это нагоняет.)

Как Вы видите, тот сценарий был записан для двух ядер. Но я адаптировал этот сценарий для работы на любое количество ядер:

#!/bin/bash
while [[ 1 ]]
do
  for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
  done
  sleep 2
done

Это делает точно то же самое и не требует cpufrequtils пакет, но это не острота.

Постоянное решение

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

Один способ сделать, который должен удалить неприятный сценарий:

sudo rm  /etc/pm/power.d/cpu_frequency

Но менее разрушительный путь состоял бы в том, чтобы отредактировать сценарий. Просто добавьте две строки где-нибудь около вершины файла:

# <date_here> Disabled by <your_name> to assist mplayer A/V sync
exit 0

Но остерегайтесь, это постоянное решение будет означать, что сценарий не переключится на powersave, когда Вы действительно будете отключены от питания переменным током, таким образом, Ваша батарея не может служить настолько же долго, как обычно!

(Хотя в моей системе, Asus X453M, это на самом деле не переключалось на powersave постоянно, пока заряд батареи не отбросил действительно низко так или иначе.)

Я надеюсь, что это помогает Вам. Эта проблема была очень печальна для меня!

BuddyLuvve · Answer 1 · 8 March 2013 в 12:19

Я не уверен, что вам все еще нужна помощь, но я буду публиковать сообщения для будущих пользователей ... Я считаю, что проблема в том, что в конфигурации mplayer по умолчанию используется только одно ядро процессора ... Попробуйте передать опцию -lavdopts threads = n (где n - количество используемых потоков).

mplayer -lavdopts threads=4 00006.MTS

Community · Answer 2 · 8 March 2013 в 12:19

TLDR? Удостоверьтесь, что Ваш регулятор частоты ЦП не изменяется некоторым демоном или инициированным событием сценарием (например, сценарием управления питанием).

(Скучная) история

У меня была эта проблема в двух различных системах Ubuntu, особенно при воспроизведении h264/x264 видео. Воспроизведение видео замедляется, в то время как аудио продолжается как нормальное. Иногда это нагоняет отдельно, но иногда это вступает во владение за 30 секунд до того, как это происходит!

Используя диаграмму в реальном времени использования ЦП, я заметил, что использование ЦП становится намного больше, когда проблема происходит (по крайней мере, как пропорция частоты тока, которую я, к сожалению, не отслеживаю).

Одно временное приспособление должно взаимодействовать с MPlayer, заставляя это нагнать справедливо быстро, при помощи одного из следующих методов:

Измените скорость воспроизведения путем нажатия [ затем ]
Переключатель в/из полном экране путем нажатия F дважды
Перемотка и перемотка вперед путем нажатия Left затем Право

Но любопытно когда я записал сценарий для отправки тех ключей автоматически, обходное решение не нагнало как ожидалось! Кажется, что фактическое физическое взаимодействие с клавиатурой требовалось...

Причина: регулятор powersave!

Наконец, я нашел, что проблема относилась к регулятору ЦП. Это кажется сценарием /etc/pm/power.d/cpu_frequency (на моей Ubuntu 12.04), периодически устанавливает регулятор частоты на powersave, даже при том, что я остаюсь включенным к питанию переменным током. (Это может произойти из-за программной ошибки, или аппаратных средств, например, изворотливого силового кабеля.)

Вскоре после этого (иногда секунды, иногда минуты) сценарий задерживает регулятор к ondemand, таким образом, не могло бы быть легко обнаружить этот случай! (Я обнаружил его путем добавления некоторых входящих в сценарий: echo "[$(date)] $0 was run with args $*" >> /tmp/cpu_frequency.log)

Временное обходное решение (хороший для тестирования)

Первоначально я работал вокруг проблемы путем запущения этого небольшого скрипта в терминале при просмотре видео:

while true; do cpufreq-set -c 0 -g performance ; cpufreq-set -c 1 -g performance ; sleep 2; done

Этот сценарий требует, чтобы у Вас был пакет cpufrequtils установленный: sudo apt-get install cpufrequtils.

Это просто гарантирует, что ЦП будет работать в полной скорости в любом случае, осуществляемый каждые 2 секунды. (Достаточно редко я мог бы видеть, что A/V потерял синхронизацию на мгновение, но затем это нагоняет.)

Как Вы видите, тот сценарий был записан для двух ядер. Но я адаптировал этот сценарий для работы на любое количество ядер:

#!/bin/bash
while [[ 1 ]]
do
  for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
  done
  sleep 2
done

Это делает точно то же самое и не требует cpufrequtils пакет, но это не острота.

Постоянное решение

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

Один способ сделать, который должен удалить неприятный сценарий:

sudo rm  /etc/pm/power.d/cpu_frequency

Но менее разрушительный путь состоял бы в том, чтобы отредактировать сценарий. Просто добавьте две строки где-нибудь около вершины файла:

# <date_here> Disabled by <your_name> to assist mplayer A/V sync
exit 0

Но остерегайтесь, это постоянное решение будет означать, что сценарий не переключится на powersave, когда Вы действительно будете отключены от питания переменным током, таким образом, Ваша батарея не может служить настолько же долго, как обычно!

(Хотя в моей системе, Asus X453M, это на самом деле не переключалось на powersave постоянно, пока заряд батареи не отбросил действительно низко так или иначе.)

Я надеюсь, что это помогает Вам. Эта проблема была очень печальна для меня!

MPlayer: Ваша система также не спешит играть это!

Спецификации рабочей станции:

Mplayer производят:

Вещи я попробовал

Вопрос

2 ответа

(Скучная) история

Причина: регулятор powersave!

Временное обходное решение (хороший для тестирования)

Постоянное решение

Другие вопросы по тегам:

Похожие вопросы: