
Recherche avancée
Autres articles (40)
-
Submit bugs and patches
13 avril 2011Unfortunately a software is never perfect.
If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
You may also (...) -
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 is the first MediaSPIP stable release.
Its official release date is June 21, 2013 and is announced here.
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 (...) -
Des sites réalisés avec MediaSPIP
2 mai 2011, parCette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.
Sur d’autres sites (6819)
-
Repairing corrupt MOV file
28 août 2016, par Simon RidleyI’m attempting to recover / repair MOV files from a formatted SD card. In the first instance I’ve made a copy of the physical disk using the unix command-line utility "DD". Once that completed I’ve used a working MOV file from the same recording device as a reference file to manually extract the required files using a Hex editor and Python.
I have attempted to use other recovery tools such as Photorec, and X-Ways, however the extractions appear damaged. This is why I’m using a Hex editor to manually inspect the data to determine what is damaged.
The software FFMPEG is reporting "moov atom not found" when attempting to process the damaged MOV file.
When the file is examined in a hex editor I can clearly see that the header appears intact. Offsets 4 to 10 show the ’ftypqt’ signature, then offsets 17 and 16 display ’qt’ and finally the ’mdat’ identifier is at offsets 36 to 39. This is identical to the reference file I have. The mdat container doesn’t appear to finish until ’moov’ which is found at offset 733093392 followed by ’lmvhd’.
This all appears in the reference file too and as far as I can tell all seems intact. am I correct in thinking that the mdat data is broken in chunks, this is possibly what is referred to as atoms ?
In which case I appreciate that the data could be damaged somewhere within the mdat. Is it possible to extract the raw data out and rebuild the container ? I’m happy to attempt this with python but I need to understand the structure of the file in more detail. Can anyone help with this please ?
-
ffmpeg sws_scale converting from YUV420P to RGB24 results in wrong color values
3 novembre 2016, par DrazurhI’m using sws_scale to convert a video from YUV420P to RGB24. The resulting RGB values are wrong, looking much more saturated/contrasted. For example, the first pixel should have an RGB value of (223,73,30) but using sws_scale results in (153,0,0).
Here’s the code I’m using :
uint8_t *buffer = NULL;
int numBytes;
// Determine required buffer size and allocate buffer
numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
pCodecCtx->height);
buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
// Assign appropriate parts of buffer to image planes in pFrameRGB
// Note that pFrameRGB is an AVFrame, but AVFrame is a superset
// of AVPicture
std::cout << "Filling picture of size " << pCodecCtx->width <<" x "<height << std::endl;
avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
pCodecCtx->width, pCodecCtx->height);
// initialize SWS context for software scaling
std::cout << "initializing SWS context\n";
sws_ctx = sws_getContext(pCodecCtx->width,
pCodecCtx->height,
pCodecCtx->pix_fmt,
pCodecCtx->width,
pCodecCtx->height,
PIX_FMT_RGB24,
SWS_FAST_BILINEAR,
NULL,
NULL,
NULL
);
while(frameFinished == 0)
{
if(av_read_frame(pFormatCtx, &packet)<0){
std::cerr << "Could not read frame!\n";
return false;
}
if(packet.stream_index==videoStream)
{
avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
}
}
sws_scale(sws_ctx, (uint8_t const * const *)pFrame->data,
pFrame->linesize, 0, pCodecCtx->height,
pFrameRGB->data, pFrameRGB->linesize);The values in pFrameRGB are incorrect. I’ve tried troubleshooting this for hours :-( Any ideas on how to track down my mistake ?
Here’s a link to the repo. The offending code is in Icosahedron Video Player/mesh.cpp, Mesh::LoadVideo and Mesh::NextFrame().
-
Cleaning up after av_frame_get_buffer
4 novembre 2016, par Jason CThere are two aspects of my question. I’m using libav, ffmpeg, 3.1.
First, how do you appropriately dispose of a frame whose buffer has been allocated with
av_frame_get_buffer
? E.g. :AVFrame *frame = av_frame_alloc();
frame->width = ...;
frame->height = ...;
frame->format = ...;
av_frame_get_buffer(frame, ...);Do any buffers have to be freed manually, beyond the call to
av_frame_free(frame)
? The documentation doesn’t mention anything special, but in my experience the ffmpeg documentation often leaves out important details, or at least hides them in places far away from the obvious spots. I took a look at the code forav_frame_free
andav_frame_unref
but it branched out quite a bit and I couldn’t quite determine if it covered everything.
Second, if something beyond
av_frame_free
needs to be done, then is there any catch-all way to clean up a frame if you don’t know how its data has been allocated ? For example, assumingsomeBuffer
is already allocated with the appropriate size :AVFrame *frame2 = av_frame_alloc();
frame2->width = ...;
frame2->height = ...;
frame2->format = ...;
av_image_fill_arrays(frame2->data, frame2->linesize, someBuffer,
frame2->format, frame2->width, frame2->height, 1);Is there a way to free both
frame
andframe2
in the above examples using the exact same code ? That isframe
and its data should be freed, andframe2
should be freed, but notsomeBuffer
, since libav did not allocate it.