Recherche avancée

Sur d’autres sites (10330)

• Using Qt Media Player on Raspberry Pi 1

  18 mai 2015, par Mauker

  I have a project built using Qt5 which has to play a video. Just like in the videowidget sample code.

  I’ve followed these instructions to build qt5 on my Pi. And it went just fine. But when I try to run any qt program that uses QMediaPlayer, I get the error message :

  defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.mediaplayer"

  Which means I don’t have a backend to play the video, right ? Is there any one that I can use which will with Qt, like ffmpeg ? And how can I get it to work ? Specially for h264 videos.

  I’ve tried to install gstreamer as is told on this link, but it’s not working. Will I have to rebuild the entire qt5 again ?

  P.S. : I have the raspberry pi 1 model B with raspbian installed.

  Edit : As mentioned by Greenflow, I checked the ./configure log and saw that the GStreamer was compiled in, but the video apps are still not working...

  The message on the log was like this :

  GStreamer .............. yes (0.10)

  And the message on Greenflow’s log was like this :

  GStreamer .............. yes (1.0)

  Clearly it’s another version of GStreamer, but is it the problem ?

  I’ve also found this post which says QtMultimedia on the Pi is rather useless, but the post is from 2013, so I’m not sure if it’s really relevant. I’d like to have this app playing hardware accelerated videos on my Raspberry Pi, but I’m almost dropping the idea.

  Anyways, thanks Greenflow for the head start.

  Edit 2 : Found this thread on the Qtcentre. Damn, this thing is not going to be easy to solve, I guess...

• Decoder return of av_find_best_stream vs. avcodec_find_decoder

  7 octobre 2016, par Jason C

  The docs for libav’s av_find_best_stream function (libav 11.7, Windows, i686, GPL) specify a parameter that can be used to receive a pointer to an appropriate AVCodec :

  decoder_ret - if non-NULL, returns the decoder for the selected stream

  There is also the avcodec_find_decoder function which can find an AVCodec given an ID.

  However, the official demuxing + decoding example uses av_find_best_stream to find a stream, but chooses to use avcodec_find_decoder to find the codec in lieu of av_find_best_stream’s codec return parameter :

  ret = av_find_best_stream(fmt_ctx, type, -1, -1, NULL, 0);
  
  ...
  
  stream_index = ret;
  
  st = fmt_ctx->streams[stream_index];
  
  ...
  
  /* find decoder for the stream */
  
  dec = avcodec_find_decoder(st->codecpar->codec_id);

  As opposed to something like :

  ret = av_find_best_stream(fmt_ctx, type, -1, -1, &dec, 0);

  My question is pretty straightforward : Is there a difference between using av_find_best_stream’s return parameter vs. using avcodec_find_decoder to find the AVCodec ?

  The reason I ask is because the example chose to use avcodec_find_decoder rather than the seemingly more convenient return parameter, and I can’t tell if the example did that for a specific reason or not. The documentation itself is a little spotty and disjoint, so it’s hard to tell if things like this are done for a specific important reason or not. I can’t tell if the example is implying that it "should" be done that way, or if the example author did it for some more arbitrary personal reason.

• Révision 22576 : Suppression d’un code mort, mort depuis longtemps.

  23 novembre 2015, par marcimat@rezo.net

  Déjà signalé par rénato en 2006 (http://spip-dev.rezo.narkive.com/mHG6Qlt6/small-bug-in-phraser-champs),
  ce if () vaut toujours true. On l’enlève du coup.

  Précisément, cela vient tout à l’origine d’une erreur lors d’un passage de ereg à strpos en r3964, strpos ne comprennant
  pas l’expression [0-9]. Redmine n’affichant plus les révisions / diff avant la révision 9600, je mais des liens git :
  https://git.spip.net/rCSPIP57683758d1ebe3a6ffa5095035e88768b14d86f2 ou https://github.com/spip/SPIP/commit/57683758d1ebe3a6ffa5095035e88768b14d86f2

  C’était à une époque ou la constante NOM_DE_CHAMP coupait les balises nommées en héxadécimal en 2 : `#FF3300` par exemple avait `#FF` en balise, et
  le reste était dans la suite, et il fallait potentiellement recorriger ce problème.
  Cette constante a été améliorée ensuite, pas longtemps après en r4407, pour attraper tout le contenu de ces balises :
  https://github.com/spip/SPIP/commit/fef3ff59fad8896d1c8946346eac1b47befc588f

  Donc, en théorie, depuis cette date, le test if() n’a plus lieu d’être.