
Recherche avancée
Médias (1)
-
Publier une image simplement
13 avril 2011, par ,
Mis à jour : Février 2012
Langue : français
Type : Video
Autres articles (97)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Multilang : améliorer l’interface pour les blocs multilingues
18 février 2011, parMultilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela. -
(Dés)Activation de fonctionnalités (plugins)
18 février 2011, parPour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)
Sur d’autres sites (9427)
-
mpeg2 ts android ffmpeg openmax
10 octobre 2014, par WLGfxThe setup is as follows :
- Multicast server 1000Mbs, UDP, Mpeg2-TS Part 1 (H.222) streaming live TV-channels.
- Quad core 1.5Ghz Android 4.2.2 GLES 2.0 renderer.
- FFMpeg library.
- Eclipse Kepler, Android SDK/NDK, etc. Running on Windows 8.1.
- Output screen 1920 x 1080, I am using a texture of 2048 x 1024 and getting between 35 and 45 Frames per second.
The app :
- Renderer thread runs continuously and updates a single texture by uploading segments to the gpu when media images are ready.
- Media handler thread, downloads and processes media from server/or local storage.
- Video thread(s), one for buffering the UDP packets and another for decoding the packets into frames.
I am connecting ffmpeg to the UDP stream just fine and the packets are being buffered and seemingly decoded fine. The packet buffers are plenty, no under/over-flows. The problem I am facing is it appears to be chopping up frames (ie only playing back 1 out of every so many frames). I understand that I need to distinguish I/P/B frames, but at the moment, hands up, I ain’t got a clue. I’ve even tried a hack to detect I frames to no avail. Plus, I am only rendering the frames to less than a quarter of the screen. So I’m not using full screen decoding.
The decoded frames are also stored in separate buffers to cut out page tearing. The number of buffers I’ve changed too, from 1 to 10 with no luck.
From what I’ve found about OpenMax IL, is it only handles MPeg2-TS Part 3 (H.264 and AAC), but you can use your own decoder. I understand that you can add your own decode component to it. Would it be worth me trying this route or should I continue on with ffmpeg ?
The frame decoder (only the renderer will convert and scale the frames when ready)
/*
* This function will run through the packets and keep decoding
* until a frame is ready first, or out of packets
*/while (packetsUsed[decCurrent])
{
hack_for_i_frame:
i = avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packets[decCurrent]);
packetsUsed[decCurrent] = 0; // finished with this one
i = packets[decCurrent].flags & 0x0001;
decCurrent++;
if (decCurrent >= MAXPACKETS) decCurrent = 0;
if (frameFinished)
{
ready_pFrame = pFrame;
frameReady = true; // notify renderer
frameCounter++;
if (frameCounter>=MAXFRAMES) frameCounter = 0;
pFrame = pFrames[frameCounter];
return 0;
}
else if (i)
goto hack_for_i_frame;
}
return 0;The packet reader (spawned as a pthread)
void *mainPacketReader(void *voidptr)
int res ;while ( threadState == TS_RUNNING )
{
if (packetsUsed[prCurrent])
{
LOGE("Packet buffer overflow, dropping packet...");
av_read_frame( pFormatCtx, &packet );
}
else if ( av_read_frame( pFormatCtx, &packets[prCurrent] ) >= 0 )
{
if ( packets[prCurrent].stream_index == videoStream )
{
packetsUsed[prCurrent] = 1; // flag as used
prCurrent++;
if ( prCurrent >= MAXPACKETS )
{
prCurrent = 0;
}
}
// here check if the packet is audio and add to audio buffer
}
}
return NULL;And the renderer just simply does this
// texture has already been bound before calling this functionif ( frameReady == false ) return;
AVFrame *temp; // set to frame 'not' currently being decoded
temp = ready_pFrame;
sws_scale(sws_ctx,(uint8_t const* const *)temp->data,
temp->linesize, 0, pCodecCtx->height,
pFrameRGB->data, pFrameRGB->linesize);
glTexSubImage2D(GL_TEXTURE_2D, 0,
XPOS, YPOS, WID, HGT,
GL_RGBA, GL_UNSIGNED_BYTE, buffer);
frameReady = false;In the past, libvlc had audio syncing problems too, so that is my decision for going with ffmpeg and doing all the donkey work from scratch.
If anybody has any pointers of how to stop the choppiness of the video playback (works great in VLC player) or possibly another route to go down, it would be seriously appreciated.
EDIT I removed the hack for the I-frame (completely useless). Move the sws_scale function from the renderer to the packet decoder. And I left the udp packet reader thread alone.
In the meantime I’ve also changed the packet reader thread and the packet decoder threads priority to real-time. Since doing that I don’t get shed loads of dropped packets.
-
Find better VP8 parameters for robustness in UDP streaming with libav/ffmpeg
24 octobre 2014, par lmNtI’m facing some problems in my video chat application, which is using libav libraries. I am sending 1080p videos encoded in VP8 as WebM container via UDP and it works quite well. Most of the time, the decoder on either side recovers from packet losses due to the transmission.
However at some point in time it just freezes and never recovers again. This happens on both sides eventually. I was searching for VP8 codec parameters to set for increased robustness, when sending over lossy transmission channels. And I combined some of which I found, in order to increase robustness. However, it still freezes after some time of video chat.
Here are the parameters I am currently using.
pVidCodecCtx->codec_id = AV_CODEC_ID_VP8;
pVidCodecCtx->codec_type = AVMEDIA_TYPE_VIDEO;
pVidCodecCtx->width = frmQ->pCodecCtx->width; //1920
pVidCodecCtx->height = frmQ->pCodecCtx->height; //1080
pVidCodecCtx->time_base = frmQ->pCodecCtx->time_base;
pVidCodecCtx->pix_fmt = PIX_FMT_YUV420P;
pVidCodecCtx->qmin = 4;
pVidCodecCtx->qmax = 56;
pVidCodecCtx->bit_rate = pVidCodecCtx->width * pVidCodecCtx->height * 6;
pVidCodecCtx->slices = 8;
pVidCodecCtx->profile = 3;
pVidCodecCtx->thread_count = 3;
pVidCodecCtx->keyint_min = 5;
av_dict_set(&pDictCodecOpts, "rc_lookahead", "0", 0);
av_dict_set(&pDictCodecOpts, "quality", "realtime", 0);
av_dict_set(&pDictCodecOpts, "deadline", "realtime", 0);
av_dict_set(&pDictCodecOpts, "max-intra-rate", "0", 0);
av_dict_set(&pDictCodecOpts, "qcomp", "0", 0);
av_dict_set(&pDictCodecOpts, "default", "er", 0);
av_dict_set(&pDictCodecOpts, "error_resilient", "er", 0);
av_dict_set(&pDictCodecOpts, "partitions", "er", 0);Most of the parameters I extracted from the ffmpeg code for the vpx encoder.
Do I also have to set parameters for the decoder in order to increase error resilience ?
Or am I missing some parameters in the encoder or setting them incorrectly. Any help or hints are greatly appreciated. -
invalid frame size while using ffmpeg
3 décembre 2020, par Rishabh MishraI am trying scale and convert a video :



ffmpeg -i input.mkv -s 1920×1080 output.mp4




But every time it shows error (Windows) :



Invalid frame size: 1920×1080.




or on Linux :



Invalid frame size: 1920×1080.