Recherche avancée

Sur d’autres sites (8970)

• Revision 100192 : $val[’htpass’] est défini plus haut, qui plus est là on le rendait vide

  26 octobre 2016, par kent1@… — Log

  $valhtpass ? est défini plus haut, qui plus est là on le rendait vide

• 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...

• avcodec/omx : Fix handling of fragmented buffers

  17 janvier 2019, par Dave Stevenson

  avcodec/omx : Fix handling of fragmented buffers
  See https://trac.ffmpeg.org/ticket/7687
  If an encoded frame is returned split over two or more
  
  IL buffers due to the size, then there is a race between
  
  whether get_buffer will fail, return NULL, and a truncated
  
  frame is passed on, or IL will return the remaining part
  
  of the encoded frame.
  
  If get_buffer returns NULL, part of the frame is left behind
  
  in the codec, and will be collected on the next call. That
  
  then leaves a frame stuck in the codec. Repeat enough times
  
  and the codec FIFO is full, and the pipeline stalls.
  A performance improvement in the Raspberry Pi firmware means
  
  that the timing has changed, and now frequently drops into the
  
  case where get_buffer returns NULL.
  Add code such that should a buffer be received without
  
  OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
  
  set, so we wait for the remainder of the frame.
  
  This code has been made conditional on the Pi build in case
  
  other IL implementations don't handle ENDOFFRAME correctly.
  Signed-off-by : Dave Stevenson <dave.stevenson@raspberrypi.org>
  
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/omx.c