Le mar. 26 nov. 2024 à 19:26, Mathieu Prevot <mathieu.pre...@gmail.com> a écrit :
> > > Le ven. 22 nov. 2024 à 13:55, Mathieu Prevot <mathieu.pre...@gmail.com> a > écrit : > >> >> Le mer. 20 nov. 2024 à 18:03, Mathieu Prevot <mathieu.pre...@gmail.com> >> a écrit : >> >>> >>> >>> Le mar. 19 nov. 2024 à 00:39, Mathieu Prevot <mathieu.pre...@gmail.com> >>> a écrit : >>> >>>> >>>> >>>> Le dim. 17 nov. 2024 à 20:57, Mathieu Prevot <mathieu.pre...@gmail.com> >>>> a écrit : >>>> >>>>> Hello, >>>>> >>>>> I am using code, based on >>>>> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/hw_decode.c, >>>>> but I am not transferring the decoded data to the host, I keep it on the >>>>> device for later use with cuda code (my goal will be to use RGB 8-12 bits >>>>> per channel data). >>>>> >>>>> I could not find a way to get the data format >>>>> ((AVPixelFormat)frame->format translates to: "HW acceleration through >>>>> CUDA. >>>>> data[i] contain CUdeviceptr pointers exactly as for system memory >>>>> frames.") >>>>> >>>>> I understand that I have two arrays: frame->data[0] and frame->data[1]. >>>>> >>>>> I would like to translate the data into a cuda native structure like: >>>>> >>>>> cudaPitchedPtr CUdeviceptr{}; >>>>> CUdeviceptr.ptr = frame->data[0]; >>>>> CUdeviceptr.ysize = frame->height; >>>>> CUdeviceptr.xsize = frame->width; >>>>> >>>>> Which is probably wrong, since width==1920 height==1080 and should >>>>> have colors or YUV data. >>>>> >>>>> How to get to know the data format (RGB, BGR, YUV, 8/10/12bits per >>>>> channel etc) and the size of the array ? >>>>> If it is not RGB8 (or 10-12), can I get that through some ffmpeg >>>>> implementation, maybe with an nvdec based function ? >>>>> What is the correct cuda-native data ? cudaPitchedPtr or something >>>>> else ? >>>>> frame->data[0] is uint8_t, but the array is probably something else in >>>>> the general case; so what is it (as redundancy or extension of "what is >>>>> the >>>>> data format") ? >>>>> >>>> >>>> It seems that frame->data[0] is the Y component of YUV, if not, one of >>>> RGB channels, but I could not figure out what frame->data[1] is. >>>> Can someone confirm ? >>>> >>> >>> I got no answer from libav-user@, maybe is it a question for >>> ffmpeg-devel@ (not subscribed, please cc) ? >>> >> >> There seems to be no other data except that of `frame->data[0]`. >> >> I verified, there is nothing beyond `frame->data[0] + >> frame->linesize[0]*frame->height`. >> >> frame->data[1] has another address but there is no data. >> >> frame->buf[0]->data and frame->extended_data both point to the same >> address as frame->data[0]. >> >> no side_data or extended_buf, >> >> opaque_ref is NULL >> >> frame->ch_layout->order is AV_CHANNEL_ORDER_UNSPEC >> >> In the end, it comes down to this questions: >> >> 1. where are UV data of YUV when decoded by cuda ? Y is at frame->data[0]. >> 2. frame->linesize[1] is set too, what is this for ? >> > For those interested. <https://stackoverflow.com/posts/79242422/timeline> For a given frame of a video that can be decoded with nvdec in ffmpeg, (AVPixelFormat)frame->format will give: AV_PIX_FMT_CUDA: HW acceleration through CUDA. data[i] contain CUdeviceptr pointers exactly as for system memory frames. which is not helpful, but ((AVHWFramesContext*)frame->hw_frames_ctx->data)->sw_format will give: AV_PIX_FMT_NV12: planar YUV 4:2:0, 12bpp, 1 plane for Y and 1 plane for the UV components, which are interleaved (first byte U and the following byte V) which is everything that is needed. Both are pitched arrays, which can be used directly as cudaPitchedPtr.ptr. Their pitch is frame->linesize[0] and frame->linesize[1]. M
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email libav-user-requ...@ffmpeg.org with subject "unsubscribe".
