Recherche avancée

Sur d’autres sites (8797)

• iOs : Low frame per second(fps) for VGA resolution

  26 juillet 2014, par Bhuvan Balasubramanian

  I’m facing an issue in broadcasting video from one iPhone to another iPhone.

  The issue is when I view the friend’s live video in my iPhone, the frame per second(fps) is very low(it is 12fps). Video quality and audio is looking fine but the only problem is fps.

  I don’t know where I need to config/change the code to convert from variable fps to constant fps. Also to increase the fps as **24/30**.

  The resolution I used for broadcasting

  RESOLUTION_VGA,     // 480x640px (landscape) & 640x480px (portrait)

  I’m using following libraries for streaming

  1. MediaLibiOS - link
  2. Ffmpeg-2.2.1
  3. CommLibiOS
  4. libx264-r2409

  Wowza is a Media Server and iOS target version is 7.0

  Please help !

  Thanks in advance.

• Revision 30246 : Corrections de grosses boulettes sql Correction d’une boulette dans la ...

  27 juillet 2009, par kent1@… — Log

  Corrections de grosses boulettes sql
  Correction d’une boulette dans la déclaration des champs
  On ne permet la demande de réencodage que depuis le document original sinon vive ma perte de qualité
  On affiche un message indiquant que c’est une version encodée issue d’un autre document s’il y a lieu de le faire
  On encode les sons dorénavant

• Last bytes of AVPacket

  3 avril 2018, par João Gueifão

  I have been experimenting with FFmpeg libav C libraries to open, read and demux a video file with both video and KLV (key-lengh-value) streams. The data stream is built according to the UAS Datalink Local Metadata Set as per the MISB ST 0601.11 standard.
  At the moment I am able to play the video on a window and dump the KLV metadata on the console just fine. I came to realise that whenever I dump the content of a AVPacket on the console, the last 14 bytes are constant, throughout different video files. I was provided a KLV decoder according to that MISB standard, which is working just fine, but ONLY WHEN I REMOVE THOSE last 14 bytes from every AVPacket data array given by FFmpeg.

  My question is : what are those 14 bytes in the first place ? I could not find them in the video file itself. I inspected the raw binary stream at one of the files and could not find those bytes anywhere. That makes me hypothesise that it is FFmpeg that is computing them itself ?

  Further details

  I discovered the following :

  • for a same video file, the value of those 14 bytes never change ;
  • when switching to a different video file, only the first 2 bytes of those 14 final bytes change ;
  • when I dump the content of a AVPacket corresponding to a video frame, those 14 bytes also are very similar.

  Here are two examples of the different 14 byte strings that I got until so far :

  • FC00 0000 01CE 8C4D 9D10 8E25 E9FE
  • BD00 0000 01CE 8C4D 9D10 8E25 E9FE

  As you may see, they are all very similar.

  Below is an example of the dump of an AVPacket::data array on the console. First we can see the the 16-byte Universal Key for this UAS Datalink Local Data Set, followed by the remaining of the packet, finishing with the mysterious 14-byte footer. I provide newlines just for readability.

  06 0E2B 3402 0B01 010E 0103 0101 0000 00
  
  81 F102 0800 04CA 140D 4323 0B03 1545 5352 495F 4D65 7461 6461 7461 5F43 6F6C 6C65 6374 0406 4E39 3738 3236 0502 F86E 0602 119A 0702 ED0B 0A05 4332 3038 420B 000C 000D 043A 841D A40E 04B5 80F4 A10F 0231 C710 0201 8B11 0200 DE12 04CD 0444 4513 04F1 2666 6614 0400 0000 0015 0400 2037 BB16 0200 0017 043A 8562 8718 04B5 7C46 AC19 0223 811A 02FF BA1B 02FF 551C 0200 6F1D 02FF 801E 0200 451F 0200 A820 02FF 9421 0200 7E2F 0100 302A 0101 0102 0101 0304 2F2F 4341 0400 0500 0602 4341 1510 0000 0000 0000 0000 0000 0000 0000 0000 1602 0005 3801 003B 0846 6972 6562 6972 6441 0101 4808 0000 0000 0000 0000 0102 DA78 
  
  FC00 0000 01CE 8C4D 9D10 8E25 E9FE

  I tried to follow the metadata.c example file on FFmpeg source examples, but it was unhelpful, as it only shows how to leverage the decoding of metadata from streams for which FFmpeg was an appropriate metadata codec. Again, in my case, the data stream is structured according to the UAS Datalink Local Metadata Set, and FFmpeg does not provide an appropriate codec.

  Thank you for your help.