2011-10-13 12 views
13

veo un desempeño terrible al intentar reproducir vídeos con QtMobility 1.2.0 y Qt 4.7.4 en Ubuntu 10.10 (Pentium 4 2.80GHz).rendimiento Terrible con QMediaPlayer y QVideoWidget

Lo curioso es que tótem (que también utilizan gstreamer como back-end) y VLC son capaces de reproducir estos vídeos sin un problema en esta máquina, incluso con resoluciones más altas (pantalla completa, etc).

Según superior, mi solicitud consume 100% de la CPU mientras tótem y VLC consume sólo ~ 40%. ¡Eso es raro! Así que estoy compartiendo el código fuente de la aplicación a continuación. Utiliza QMediaPlayer y QVideoWidget para hacer el trabajo.

movie.cpp:

#include <QtGui/QMainWindow> 
#include <QtGui> 
#include <qmediaplayer.h> 
#include <qvideowidget.h> 

int main(int argc, char* argv[]) 
{ 
    QApplication app(argc, argv); 

    QMainWindow mainWindow; 

    mainWindow.resize(QSize(1280, 500)); 

    QMediaPlayer* mplayer = new QMediaPlayer; 
    QVideoWidget* vid_widget = new QVideoWidget(&mainWindow); 
    vid_widget->setAspectRatioMode(Qt::IgnoreAspectRatio); 

    mainWindow.setCentralWidget(vid_widget); 

    mplayer->setVideoOutput(vid_widget); 
    mplayer->setMedia(QUrl::fromLocalFile(argv[1])); 
    mplayer->setVolume(50); 
    mplayer->setPlaybackRate(1); 
    mplayer->play(); 

    mainWindow.show(); 

    return app.exec(); 
} 

movie.pro:

TEMPLATE = app 
QT += gui 

CONFIG += mobility 
MOBILITY = multimedia 

QMAKE_RPATHDIR += $$DESTDIR 

SOURCES = \ 
movie.cpp 

El rendimiento sigue siendo terrible, incluso si se crea una ventana más pequeña, como por ejemplo:

mainWindow.resize(QSize(960, 540)); 

¿Alguien k ahora ¿qué podría estar causando este comportamiento y cómo lo soluciono?

Si alguien está interesado, ffmpeg muestra esta información sobre uno de los archivos de vídeo que estoy usando para la prueba:

Input #0, matroska, from '/home/user/movie.mkv': 
    Duration: 00:02:23.22, start: 0.000000, bitrate: N/A 
    Stream #0.0(eng): Video: h264, yuvj420p, 1280x536 [PAR 1:1 DAR 160:67], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc 
    Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16 
+0

Si el código fuente está disponible, sugiero prepararme para un depurador largo que busque bucles ocupados – Ulterior

+3

@Ulterior No hay nada que depurar. Parece un error en la biblioteca de qt. No sería el primero –

Respuesta

3

No hay nada malo con su código, se le acaba de pasar la pelota a Qt para la decodificación y reproducción de la película.

Está utilizando una compilación de Qt que no tiene habilitada la aceleración de hardware o su sistema no tiene el hardware adecuado para que Qt acelere la decodificación y la reproducción.

+2

El rendimiento de video deficiente es frustrantemente común en Linux. Es difícil de creer que a 2.8 GHz uno necesitaría _ cualquier_ aceleración de hardware para obtener un rendimiento decente, pero aquí estamos.

+0

h264 especialmente puede ser un problema para la reproducción, y un Pentium 4 de 2,8 Ghz no está realmente a la altura de la tarea. Afortunadamente para nosotros los usuarios de Linux VAAPI ha llegado lo suficientemente lejos con los controladores de código abierto que ya no estamos obligados a nVidia VDPAU para reproducir incluso 1080p. Encontré que mi 1.La computadora portátil 2Ghz Core i3 funciona bien, incluso los controladores ATI de código abierto logran trabajar con VAAPI si cambio al híbrido incorporado. 5950 –

+0

Aparentemente VAAPI aún no es compatible con Qt Multimedia: https: //bugreports.qt-project .org/browse/QTBUG-23761 – RzR

5

Comencé a usar QML Video Element y después de tener varios problemas de representación/rendimiento con él, finalmente me di por vencido y escribí un elemento de reproductor de video para reemplazar el de QtMobility.

A quien le pueda interesar, GStreamer has a C++ interface que es muy fácil de usar.

+0

Tengo el mismo problema, el reproductor de video reproduce el video a velocidad normal pero Phonon es demasiado lento. ¿Podría explicar con más detalle cómo resuelve el problema? Sigo que GStreamer tiene un enlace de interfaz C++ pero no encontré nada allí. Gracias. – HMarioD

+0

Bueno, esa es una pregunta que merece su propio hilo, así que seré breve: estudie algunos tutoriales de GStreamer hasta que pueda escribir una aplicación que pueda leer un archivo de video, recuperar sus cuadros y mostrarlo en una ventana. Durante este proceso, encontrará que el marco almacena sus píxeles en un formato que probablemente no sea RGB. Para mostrar los marcos correctamente, cada cuadro debe convertirse a cualquier formato en que se encuentren (digamos YUV) a RGB. – karlphillip

+0

El proceso de conversión es realmente responsable del bajo rendimiento que observamos con Phonon porque lo hace la CPU. Para agilizar las cosas, puede escribir un código de conversión de espacio de color (es decir, YUV a RGB) para que se ejecute en la GPU a través de [Sombreadores GLSL] (http://stackoverflow.com/q/8977489/176769). Siéntase libre de votar mis preguntas/respuestas. ¡Buena suerte! – karlphillip

Cuestiones relacionadas