Recherche avancée
Autres articles (112)
-
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...) -
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
Problèmes fréquents
10 mars 2010, parPHP et safe_mode activé
Une des principales sources de problèmes relève de la configuration de PHP et notamment de l’activation du safe_mode
La solution consiterait à soit désactiver le safe_mode soit placer le script dans un répertoire accessible par apache pour le site
Sur d’autres sites (13477)
-
How to convert AVFrame to cv::cuda::GpuMat
29 mai 2021, par BumpAfter I decode a frame use FFmpeg(Hardware decoding like this : https://github.com/FFmpeg/FFmpeg/blob/release/4.1/doc/examples/hw_decode.c)the decoded frames still remain on GPU memory. How can I convert AVFrame to GpuMat ?


I tried to do it using this code :


__global__ void NV12ToBGRkernel(uchar* ydata, uchar* uvdata, int ywidth, int uvwidth, cv::cuda::PtrStepSz<uchar3> rgbFrame) {
 int i = threadIdx.x + blockIdx.x * blockDim.x; 
 int j = threadIdx.y + blockIdx.y * blockDim.y; 

 int indexY = j * ywidth + i;
 int id2 = i % 2;
 int indexU = j / 2 * uvwidth + i - id2;
 int indexV = indexU + 1;

 if (j < rgbFrame.rows && i < rgbFrame.cols) {
 uchar Y = ydata[indexY];
 uchar U = uvdata[indexU];
 uchar V = uvdata[indexV];
 int R = Y + 1.402*(V - 128);
 int G = Y - 0.34414*(U - 128) - 0.71414*(V - 128);
 int B = Y + 1.772*(U - 128);

 if (R < 0)
 R = 0;
 if (G < 0)
 G = 0;
 if (B < 0)
 B = 0;

 rgbFrame(j, i).x = (B>255) ? 255 : (uchar)B;
 rgbFrame(j, i).y = (G>255) ? 255 : (uchar)G;
 rgbFrame(j, i).z = (R>255) ? 255 : (uchar)R;
 }
 return;
}

extern "C" int cuda_NV12ToBGR(AVFrame *frame, cv::cuda::GpuMat* out) {
 int width = out->cols;
 int height = out->rows;
 int byteCount = out->elemSize();
 int bx = ceil((double)width / BLOCKDIM_X); 
 int by = ceil((double)height / BLOCKDIM_Y);

 if (bx > GRIDDIM_X) bx = GRIDDIM_X;
 if (by > GRIDDIM_Y) by = GRIDDIM_Y;

 dim3 grid(bx, by);
 dim3 block(BLOCKDIM_X, BLOCKDIM_Y);

 uchar* ydata = frame->data[0];
 uchar* uvdata = frame->data[1];
 int ywidth = frame->linesize[0];
 int uvwidth = frame->linesize[1];

 NV12ToBGRkernel << > >(ydata, uvdata, ywidth, uvwidth, *out);

 cudaDeviceSynchronize();
 gpuErrchk(cudaPeekAtLastError());
 return 1;
}
</uchar3>

Using the above code I can get a GpuMat, but after I download the GpuMat to Mat and imshow it, I found the decode frames to be the same sometimes (two adjacent frames),and if I use av_hwframe_transfer_data bofore, then convert AVFrame to GpuMat ,it won't happen again. When I checked in the source code in av_hwframe_transfer_data, I found this :


static int cuda_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
 const AVFrame *src) {
 CUDAFramesContext *priv = ctx->internal->priv;
 AVHWDeviceContext *device_ctx = ctx->device_ctx;
 AVCUDADeviceContext *hwctx = device_ctx->hwctx;
 CudaFunctions *cu = hwctx->internal->cuda_dl;

 CUcontext dummy;
 int i, ret;

 ret = CHECK_CU(cu->cuCtxPushCurrent(hwctx->cuda_ctx));
 if (ret < 0)
 return ret;

 for (i = 0; i < FF_ARRAY_ELEMS(src->data) && src->data[i]; i++) {
 CUDA_MEMCPY2D cpy = {
 .srcMemoryType = CU_MEMORYTYPE_DEVICE,
 .dstMemoryType = CU_MEMORYTYPE_HOST,
 .srcDevice = (CUdeviceptr)src->data[i],
 .dstHost = dst->data[i],
 .srcPitch = src->linesize[i],
 .dstPitch = dst->linesize[i],
 .WidthInBytes = FFMIN(src->linesize[i], dst->linesize[i]),
 .Height = src->height >> (i ? priv->shift_height : 0),
 };

 ret = CHECK_CU(cu->cuMemcpy2DAsync(&cpy, hwctx->stream));
 if (ret < 0)
 goto exit;
 }

 ret = CHECK_CU(cu->cuStreamSynchronize(hwctx->stream));
 if (ret < 0)
 goto exit;

exit:
 CHECK_CU(cu->cuCtxPopCurrent(&dummy));
 return 0;
}


My questions are :


- 

- Maybe cuCtxPushCurrent and cuCtxPopCurrent lead to the repeated frames ?
- I don't want to use av_hwframe_transfer_data to transfer data to the CPU. How can I do it ?






-
avcodec/vorbisenc : Combine codebooks, avoid relocations
7 mai 2021, par Andreas Rheinhardtavcodec/vorbisenc : Combine codebooks, avoid relocations
The Vorbis encoder has an array of a structure containing all
the ingredients for a codebook ; this includes a pointer to
the actual codebook and some even have a pointer to an array
containing quant values. Each of these real codebooks is
an array of its own.
These pointers lead to relocations and therefore the array will
be placed in .data.rel.ro and not in .rodata.This commit avoids the pointers altogether by combining all the actual
codebooks into one big array ; the actual codebooks are now accessed
consecutively by incrementing the pointer used to access them by the
length of the actual codebook that has just been dealt with (said length
is contained in the structure describing the codebook). There is
no downside to this given that these codebooks are already only used
once during init.Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Revert "avcodec : add FF_CODEC_CAP_INIT_CLEANUP for all codecs which use ff_mpv_common...
24 décembre 2020, par Andreas RheinhardtRevert "avcodec : add FF_CODEC_CAP_INIT_CLEANUP for all codecs which use ff_mpv_common_init()"
This mostly reverts commit 4b2863ff01b1fe93d9a518523c9098d17a9d8c6f.
Said commit removed the freeing code from ff_mpv_common_init(),
ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc() and
instead added the FF_CODEC_CAP_INIT_CLEANUP to several codecs that use
ff_mpv_common_init(). This introduced several bugs :a) Several decoders using ff_mpv_common_init() in their init function were
forgotten : This affected FLV, Intel H.263, RealVideo 3.0 and V4.0 as well as
VC-1/WMV3.
b) ff_mpv_common_init() is not only called from the init function of
codecs, it is also called from AVCodec.decode functions. If an error
happens after an allocation has succeeded, it can lead to memleaks ;
furthermore, it is now possible for the MpegEncContext to be marked as
initialized even when ff_mpv_common_init() returns an error and this can
lead to segfaults because decoders that call ff_mpv_common_init() when
decoding a frame can mistakenly think that the MpegEncContext has been
properly initialized. This can e.g. happen with H.261 or MPEG-4.
c) Removing code for freeing from ff_mpeg_framesize_alloc() (which can't
be called from any init function) can lead to segfaults because the
check for whether it needs to allocate consists of checking whether the
first of the buffers allocated there has been allocated. This part has
already been fixed in 76cea1d2ce3f23e8131c8664086a1daf873ed694.
d) ff_mpv_common_frame_size_change() can also not be reached from any
AVCodec.init function ; yet the changes can e.g. lead to segfaults with
decoders using ff_h263_decode_frame() upon allocation failure, because
the MpegEncContext will upon return be flagged as both initialized and
not in need of reinitialization (granted, the fact that
ff_h263_decode_frame() clears context_reinit before the context has been
reinited is a bug in itself). With the earlier version, the context
would be cleaned upon failure and it would be attempted to initialize
the context again in the next call to ff_h263_decode_frame().While a) could be fixed by adding the missing FF_CODEC_CAP_INIT_CLEANUP,
keeping the current approach would entail adding cleanup code to several
other places because of b). Therefore ff_mpv_common_init() is again made
to clean up after itself ; the changes to the wmv2 decoder and the SVQ1
encoder have not been reverted : The former fixed a memleak, the latter
allowed to remove cleanup code.Fixes : double free
Fixes : ff_free_picture_tables.mp4
Fixes : ff_mpeg_update_thread_context.mp4
Fixes : decode_colskip.mp4
Fixes : memset.mp4Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Syndiquer tout le site
