
Recherche avancée
Médias (1)
-
The Great Big Beautiful Tomorrow
28 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Texte
Autres articles (56)
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs
Sur d’autres sites (8037)
-
Encode Android's frame's .raw file to .png file format using ffmpeg
12 avril 2017, par GlexI used the script from source. What it does is that it reads the frame-buffer information from the mobile (android) phone and save it as a .raw file. It then uses ffmpeg encoder to create .png file. Unfortunately the png image that I am getting is like (attached below). I tried to play with the "-pix_fmt" option used and tried using rgba instead of rgb32 used in that code (none of them work btw). I used another script (ascreenshooter.py) to analyse the header for this raw image to find few image headers. they are listed as :
version : 1
bpp : 32
size : 2088960
width : 544
height : 960
red_offset : 0
red_length : 8
blue_offset : 16
blue_length : 8
green_offset : 8
green_length : 8
alpha_offset : 0
alpha_length : 8Please suggest if it is possible to encode this .raw image file to png format. If it is possible than what ffmpeg options I should use and if some other more efficient tool does exit for this encoding process.
Sample raw image as requested :
http://tabak.csc.ncsu.edu/arpit.raw
-
Decode AAC to PCM with ffmpeg on android
26 novembre 2012, par JeffGI have built ffmpeg 0.8.12 (love) with the android NDK (r8c) on ubuntu.
I then use the generated library in another android application through JNI.Essentially what I want to do is pass a byte stream from java to my c jni function and use ffmpeg to decode it into a PCM audio buffer which will then be passed back to java to be played using Android's AudioTrack. I can successfully pass the buffer through to jni (have checked the values) and ffmpeg seems to initialise correctly, but when it tries to decode the first frame, it throws an error in the aac_decode_frame_int method in aacdec.c "channel element 0.0 is not allocated". The aac file plays fine and is valid.
Here is my jni code to do the decoding
jint Java_com_example_testffmpeg_MainActivity_decodeAacBytes(JNIEnv * env,
jobject this, jbyteArray input, jint numBytes) {
//copy bytes from java
jbyte* bufferPtr = (*env)->GetByteArrayElements(env, input, NULL);
uint8_t inputBytes[numBytes + FF_INPUT_BUFFER_PADDING_SIZE];
memset(inputBytes, 0, numBytes + FF_INPUT_BUFFER_PADDING_SIZE);
memcpy(inputBytes, bufferPtr, numBytes);
(*env)->ReleaseByteArrayElements(env, input, bufferPtr, 0);
av_register_all();
AVCodec *codec = avcodec_find_decoder(CODEC_ID_AAC);
if (codec == NULL) {
LOGE("Cant find AAC codec\n");
return 0;
}
LOGI("AAC codec found\n");
AVCodecContext *avCtx = avcodec_alloc_context();
if (avCtx == NULL) {
LOGE("Could not allocate codec context\n");
return 0;
}
LOGI("codec context allocated\n");
if (avcodec_open2(avCtx, codec, NULL) < 0) {
LOGE("Could not open codec\n");
return 0;
}
LOGI("AAC codec opened");
//the input buffer
AVPacket avPacket;
av_init_packet(&avPacket);
LOGI("AVPacket initialised\n");
avPacket.size = numBytes; //input buffer size
avPacket.data = inputBytes; // the input buffer
int outSize;
int len;
uint8_t *outbuf = malloc(AVCODEC_MAX_AUDIO_FRAME_SIZE);
while (avPacket.size > 0) {
outSize = AVCODEC_MAX_AUDIO_FRAME_SIZE;
len = avcodec_decode_audio3(avCtx, (short *) outbuf, &outSize,
&avPacket);
if (len < 0) {
LOGE("Error while decoding\n");
return 0;
}
if (outSize > 0) {
LOGI("Decoded some stuff\n");
}
avPacket.size -= len;
avPacket.data += len;
}
LOGI("Freeing memory\n");
av_free_packet(&avPacket);
avcodec_close(avCtx);
av_free(avCtx);
return 0;
}The problem occurs in the call to avcodec_decode_audio3, when the decoding first occurs. I have stepped through the ffmpeg code, but can't find the problem. Any help would be greatly appreciated !
-
Android RTSP streaming buffer size for delayed playback
19 novembre 2012, par frijj2kI can access and view RTSP streams from IP cameras on Android via the VideoView component without problems.
Now I need to play the RTSP stream with a delay (i.e. if I specify a 30 second delay, the playback on screen should be 30 seconds behind the source and the delay needs to be variable though not during playback, only at the point of connecting to the source).
I originally thought this would not be a problem as I could simply change the RTSP buffer duration before connecting to the camera but unfortunately it seems the buffer size is baked into the firmware and cannot be changed in software. Now I have got a horrible feeling that my way forward will be to compile a version of FFMpeg for Android and somehow get the stream data out from the library, buffer it and then render it myself and I have no experience with FFMpeg.
I am unsure how I would now go about solving this problem and any help or pointers in the right direction would be greatly appreciated.
Update :
Sorry I forgot to mention, the RTSP stream is being accessed over WiFi on a LAN so no huge latency issues here from going over the Internet.