[FFmpeg-devel] [PATCH] libavcodec/qsvenc: Change the parameter log to be thread safe
Dividing one line log into several av_log() call is not thread safe. Now
merge these strings into one av_log() call.
Signed-off-by: Wenbin Chen
---
libavcodec/qsvenc.c | 87 ++---
1 file changed, 42 insertions(+), 45 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2382c2f5f7..5729292f94 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -182,6 +182,7 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
mfxExtCodingOption2 *co2 = NULL;
mfxExtCodingOption3 *co3 = NULL;
mfxExtHEVCTiles *exthevctiles = NULL;
+const char *tmp_str = NULL;
if (q->co2_idx > 0)
co2 = (mfxExtCodingOption2*)coding_opts[q->co2_idx];
@@ -195,13 +196,12 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
print_profile(avctx->codec_id, info->CodecProfile),
info->CodecLevel);
-av_log(avctx, AV_LOG_VERBOSE, "GopPicSize: %"PRIu16"; GopRefDist:
%"PRIu16"; GopOptFlag: ",
- info->GopPicSize, info->GopRefDist);
-if (info->GopOptFlag & MFX_GOP_CLOSED)
-av_log(avctx, AV_LOG_VERBOSE, "closed ");
-if (info->GopOptFlag & MFX_GOP_STRICT)
-av_log(avctx, AV_LOG_VERBOSE, "strict ");
-av_log(avctx, AV_LOG_VERBOSE, "; IdrInterval: %"PRIu16"\n",
info->IdrInterval);
+av_log(avctx, AV_LOG_VERBOSE,
+ "GopPicSize: %"PRIu16"; GopRefDist: %"PRIu16"; GopOptFlag:%s%s;
IdrInterval: %"PRIu16"\n",
+ info->GopPicSize, info->GopRefDist,
+ info->GopOptFlag & MFX_GOP_CLOSED ? " closed" : "",
+ info->GopOptFlag & MFX_GOP_STRICT ? " strict" : "",
+ info->IdrInterval);
av_log(avctx, AV_LOG_VERBOSE, "TargetUsage: %"PRIu16"; RateControlMethod:
%s\n",
info->TargetUsage, print_ratecontrol(info->RateControlMethod));
@@ -269,45 +269,46 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
av_log(avctx, AV_LOG_VERBOSE, "IntRefType: %"PRIu16"; IntRefCycleSize:
%"PRIu16"; IntRefQPDelta: %"PRId16"\n",
co2->IntRefType, co2->IntRefCycleSize, co2->IntRefQPDelta);
-av_log(avctx, AV_LOG_VERBOSE, "MaxFrameSize: %d; ", co2->MaxFrameSize);
-av_log(avctx, AV_LOG_VERBOSE, "MaxSliceSize: %d; ", co2->MaxSliceSize);
-av_log(avctx, AV_LOG_VERBOSE, "\n");
+av_log(avctx, AV_LOG_VERBOSE, "MaxFrameSize: %d; MaxSliceSize: %d\n",
+ co2->MaxFrameSize, co2->MaxSliceSize);
av_log(avctx, AV_LOG_VERBOSE,
"BitrateLimit: %s; MBBRC: %s; ExtBRC: %s\n",
print_threestate(co2->BitrateLimit),
print_threestate(co2->MBBRC),
print_threestate(co2->ExtBRC));
-av_log(avctx, AV_LOG_VERBOSE, "Trellis: ");
if (co2->Trellis & MFX_TRELLIS_OFF) {
-av_log(avctx, AV_LOG_VERBOSE, "off");
+av_log(avctx, AV_LOG_VERBOSE, "Trellis: off\n");
} else if (!co2->Trellis) {
-av_log(avctx, AV_LOG_VERBOSE, "auto");
+av_log(avctx, AV_LOG_VERBOSE, "Trellis: auto\n");
} else {
-if (co2->Trellis & MFX_TRELLIS_I) av_log(avctx, AV_LOG_VERBOSE,
"I");
-if (co2->Trellis & MFX_TRELLIS_P) av_log(avctx, AV_LOG_VERBOSE,
"P");
-if (co2->Trellis & MFX_TRELLIS_B) av_log(avctx, AV_LOG_VERBOSE,
"B");
+char trellis_type[4];
+int i = 0;
+if (co2->Trellis & MFX_TRELLIS_I) trellis_type[i++] = 'I';
+if (co2->Trellis & MFX_TRELLIS_P) trellis_type[i++] = 'P';
+if (co2->Trellis & MFX_TRELLIS_B) trellis_type[i++] = 'B';
+trellis_type[i] = 0;
+av_log(avctx, AV_LOG_VERBOSE, "Trellis: %s\n", trellis_type);
}
-av_log(avctx, AV_LOG_VERBOSE, "\n");
-av_log(avctx, AV_LOG_VERBOSE,
- "RepeatPPS: %s; NumMbPerSlice: %"PRIu16"; LookAheadDS: ",
- print_threestate(co2->RepeatPPS), co2->NumMbPerSlice);
switch (co2->LookAheadDS) {
-case MFX_LOOKAHEAD_DS_OFF: av_log(avctx, AV_LOG_VERBOSE, "off");
break;
-case MFX_LOOKAHEAD_DS_2x: av_log(avctx, AV_LOG_VERBOSE, "2x");
break;
-case MFX_LOOKAHEAD_DS_4x: av_log(avctx, AV_LOG_VERBOSE, "4x");
break;
-default: av_log(avctx, AV_LOG_VERBOSE, "unknown");
break;
+case MFX_LOOKAHEAD_DS_OFF: tmp_str = "off"; break;
+case MFX_LOOKAHEAD_DS_2x: tmp_str = "2x"; break;
+case MFX_LOOKAHEAD_DS_4x: tmp_str = "4x"; break;
+default: tmp_str = "unknown"; break;
}
-av_log(avctx, AV_LOG_VERBOSE, "\n");
+av_log(avctx, AV_LOG_VERBOSE,
+ "RepeatPPS: %s; NumMbPerSlice: %"PRIu16"; LookAheadDS: %s\n",
+ print_threestate(co2->RepeatPPS), co2->NumMbPerSlice, tmp_str);
-av_log(avctx, AV_LOG_VERBOSE, "A
Re: [FFmpeg-devel] FFmpeg 5.1
On Thu, 7 Jul 2022, at 22:47, Michael Niedermayer wrote: > previosuly suggested names i found in my very unorgnaized notes: > Mellin, Gauss, Galois, Viterbi, Darwin, Von Neumann, lorentz, poincaré, > desitter, de broglie Did we not use Lorentz for 5.0? I'm ok for re-using it, though. Else, I would suggest Maxwell. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
On Fri, Jul 8, 2022 at 10:37 AM Jean-Baptiste Kempf wrote: > On Thu, 7 Jul 2022, at 22:47, Michael Niedermayer wrote: > > previosuly suggested names i found in my very unorgnaized notes: > > Mellin, Gauss, Galois, Viterbi, Darwin, Von Neumann, lorentz, poincaré, > > desitter, de broglie > > Did we not use Lorentz for 5.0? I'm ok for re-using it, though. > Else, I would suggest Maxwell. > Carl, there are many famous people with that name: Sagan, Gauss, Jacobi, Wieman, Anderson, etc.. > > jb > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
The lavfi changes, more specifically wrapped_avframe, still rely on sizeof(AVFrame) being used outside lavu. We really need to stop spreading its use and find a way to change this behavior. I have tried like two different solutions and both were rejected, so it's not going to be me. wrapped_avframe is used all over the place in lavd already. Is that really a problem, as long as it's within another libav* library? Given we don't support mix-matching library versions in the first place. The only real way around that would be a get_size function in lavu, and never using AVFrames on the stack, which is done in quite a lot of places. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
On 08/07/2022 12:17, Timo Rothenpieler wrote: The lavfi changes, more specifically wrapped_avframe, still rely on sizeof(AVFrame) being used outside lavu. We really need to stop spreading its use and find a way to change this behavior. I have tried like two different solutions and both were rejected, so it's not going to be me. wrapped_avframe is used all over the place in lavd already. Is that really a problem, as long as it's within another libav* library? Given we don't support mix-matching library versions in the first place. Also, thinking about it, wrapped_avframe does not actually rely on the size of AVFrame at all. It's only set on the buffer as a purely informational thing. The only actual data in the buffer is a pointer to the frame. So more accurately, the size of the wrapped package could be sizeof(void*). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
On 7/8/2022 7:23 AM, Timo Rothenpieler wrote: On 08/07/2022 12:17, Timo Rothenpieler wrote: The lavfi changes, more specifically wrapped_avframe, still rely on sizeof(AVFrame) being used outside lavu. We really need to stop spreading its use and find a way to change this behavior. I have tried like two different solutions and both were rejected, so it's not going to be me. wrapped_avframe is used all over the place in lavd already. Is that really a problem, as long as it's within another libav* library? Given we don't support mix-matching library versions in the first place. Also, thinking about it, wrapped_avframe does not actually rely on the size of AVFrame at all. It's only set on the buffer as a purely informational thing. No, it's used by the "decoder" https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/wrapped_avframe.c;h=06c274eed0b99e9ba5a703df963ef4c8f67dbe1c;hb=HEAD#l90 The only actual data in the buffer is a pointer to the frame. So more accurately, the size of the wrapped package could be sizeof(void*). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
On Fri, Jul 08, 2022 at 10:36:54AM +0200, Jean-Baptiste Kempf wrote: > On Thu, 7 Jul 2022, at 22:47, Michael Niedermayer wrote: > > previosuly suggested names i found in my very unorgnaized notes: > > Mellin, Gauss, Galois, Viterbi, Darwin, Von Neumann, lorentz, poincaré, > > desitter, de broglie > > Did we not use Lorentz for 5.0? I'm ok for re-using it, though. > Else, I would suggest Maxwell. as said, my notes are poorly organized :) ive removed Lorentz and added Maxwell thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1
On 7/8/22 09:52, Michael Niedermayer wrote: On Fri, Jul 08, 2022 at 10:36:54AM +0200, Jean-Baptiste Kempf wrote: On Thu, 7 Jul 2022, at 22:47, Michael Niedermayer wrote: previosuly suggested names i found in my very unorgnaized notes: Mellin, Gauss, Galois, Viterbi, Darwin, Von Neumann, lorentz, poincaré, desitter, de broglie Did we not use Lorentz for 5.0? I'm ok for re-using it, though. Else, I would suggest Maxwell. as said, my notes are poorly organized :) ive removed Lorentz and added Maxwell thx If this is going to be an LTS release why not Riemann, after a very LTS problem in mathematics :) - Leo Izen (thebombzen) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/35] fftools/ffmpeg_mux: add private muxer context
On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote: > The current version of this set can also be found in my tree > git://git.khirnov.net/libav > branch ffmpeg_mt/mux There are really many files changing, its hard to say for sure that all are the same issue, but basically it all seems more or less frames in some streams including cases where there are hugely more or 0 Here are some examples: ffmpeg -i matrixbench_mpeg2.mpg -vcodec rawvideo -pix_fmt rgb555 -allow_raw_vfw 1 -vframes 1 -bitexact file-rgb555.mkv the new file is much bigger (due to the audio track) -rw-r- 1 michael michael 2765813 Jul 8 16:57 file-rgb555.mkv -rw-r- 1 michael michael 834643 Jul 8 17:02 file-rgb555-ref.mkv another one: ./ffmpeg -y -i vlcticket/8344/DVR_NVR_IP\ Camera01_20130321162325_20130321162358_576877.mp4 -vframes 1 -aframes 1 -bitexact -f framecrc - This appears to loose the video stream #channel_layout_name 1: mono -0, 0, 0,1, 288, 0x4136bc92 1,112,112, 320, 640, 0x2cd73b36 sample in https://samples.ffmpeg.org/camera-dvr/hikvision/ This one fails a bit worse than before (ffmpeg succeeds before besides producing errors as well) my notes say this worked better only before 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8 the file is a little big and i havnt found it anywhere online, i will try to send it privately to you ffmpeg -i 2014-10-17\ 11.31\ i95Dev\ -\ Carlo\ Pazolini\ _\ KWI\ -\ Meeting.g2m -bitexact -max_muxing_queue_size 8000 -vframes 2 file-g2m5.avi Metadata: DeviceConformanceTemplate: L2 WMFSDKNeeded: 0.0.0. WMFSDKVersion : 12.0.7601.17514 IsVBR : 1 WM/ToolVersion : 6.4.3 Build 1767 WM/ToolName : GoToMeeting BitRateFrom the writer: 97087 Audio samples : 34341 Video samples : 3740 recording time : Fri, 17 Oct 2014 12:28:16 Eastern Daylight Time Duration: 00:57:13.86, start: 0.00, bitrate: 100 kb/s Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, mono, fltp, 48 kb/s Stream #0:1: Data: none, 2 kb/s Stream #0:2: Video: g2m (G2M5 / 0x354D3247), rgb24, 1440x900, 49 kb/s, 1k tbr, 1k tbn Stream mapping: Stream #0:2 -> #0:0 (g2m (native) -> mpeg4 (native)) Stream #0:0 -> #0:1 (wmav2 (native) -> mp3 (libmp3lame)) Press [q] to stop, [?] for help [libmp3lame @ 0x55c17cf03140] Queue input is backward in time Output #0, avi, to 'file-g2m5.avi': Metadata: DeviceConformanceTemplate: L2 WMFSDKNeeded: 0.0.0. WMFSDKVersion : 12.0.7601.17514 IsVBR : 1 WM/ToolVersion : 6.4.3 Build 1767 WM/ToolName : GoToMeeting BitRateFrom the writer: 97087 Audio samples : 34341 Video samples : 3740 recording time : Fri, 17 Oct 2014 12:28:16 Eastern Daylight Time Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p(tv, progressive), 1440x900, q=2-31, 200 kb/s, 1k fps, 1k tbn Metadata: encoder : Lavc mpeg4 Side data: cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, mono, fltp Metadata: encoder : Lavc libmp3lame [avi @ 0x55c17cf31340] Too large number of skipped frames 194184 > 60kbits/s speed= 140x av_interleaved_write_frame(): Invalid argument Error muxing a packet for output file #0 [avi @ 0x55c17cf31340] Too large number of skipped frames 194085 > 6 frame=2 fps=1.3 q=2.0 Lsize=1855kB time=00:03:14.18 bitrate= 78.3kbits/s speed= 129x video:149kB audio:1517kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 11.381945% Conversion failed! ./ffmpeg -i tickets/1666/avc-intra-panasonic-AG-HPX301E.mov -vframes 3 -aframes 2 -bitexact -f framecrc - duplicate behavior of the a/vframe issue above, one stream disappears sample in https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1666/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Allow exporting of RGB and BGR images to CUDA.
Use the step size when calculating the number of channels to allow for more
than two channels per plane. This allows the use of AV_PIX_FMT_0BGR32 when
using av_hwframe_transfer_data to transfer data from a Vulkan frame to a CUDA
frame.
Signed-off-by: David Peeters
---
libavutil/hwcontext_vulkan.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 237caa4bc0..05e8fc5268 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -2992,6 +2992,8 @@ static int vulkan_export_to_cuda(AVHWFramesContext *hwfc,
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(hwfc->sw_format);
VulkanDevicePriv *p = ctx->internal->priv;
FFVulkanFunctions *vk = &p->vkfn;
+int max_pixsteps[4];
+int max_pixstep_comps[4];
AVHWFramesContext *cuda_fc = (AVHWFramesContext*)cuda_hwfc->data;
AVHWDeviceContext *cuda_cu = cuda_fc->device_ctx;
@@ -3001,6 +3003,8 @@ static int vulkan_export_to_cuda(AVHWFramesContext *hwfc,
CUarray_format cufmt = desc->comp[0].depth > 8 ?
CU_AD_FORMAT_UNSIGNED_INT16 :
CU_AD_FORMAT_UNSIGNED_INT8;
+av_image_fill_max_pixsteps(max_pixsteps, max_pixstep_comps, desc);
+
dst_f = (AVVkFrame *)frame->data[0];
dst_int = dst_f->internal;
@@ -3023,7 +3027,9 @@ static int vulkan_export_to_cuda(AVHWFramesContext *hwfc,
.arrayDesc = {
.Depth = 0,
.Format = cufmt,
-.NumChannels = 1 + ((planes == 2) && i),
+.NumChannels = desc->comp[max_pixstep_comps[i]].depth > 8
+? max_pixsteps[i] / 2
+: max_pixsteps[i],
.Flags = 0,
},
.numLevels = 1,
--
2.36.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/8] avutil/hwcontext_d3d11va: fix mixed declaration and code
---
libavutil/hwcontext_d3d11va.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 904d14bbc8..e5afcb2a9d 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -397,6 +397,7 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx,
AVFrame *dst,
D3D11_TEXTURE2D_DESC desc;
D3D11_MAPPED_SUBRESOURCE map;
HRESULT hr;
+int res;
if (frame->hw_frames_ctx->data != (uint8_t *)ctx || other->format !=
ctx->sw_format)
return AVERROR(EINVAL);
@@ -405,7 +406,7 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx,
AVFrame *dst,
if (!s->staging_texture) {
ID3D11Texture2D_GetDesc((ID3D11Texture2D *)texture, &desc);
-int res = d3d11va_create_staging_texture(ctx, desc.Format);
+res = d3d11va_create_staging_texture(ctx, desc.Format);
if (res < 0)
return res;
}
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/8] avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools
---
libavutil/hwcontext_d3d11va.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index e5afcb2a9d..6355bd1e29 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -166,6 +166,17 @@ static AVBufferRef *wrap_texture_buf(AVHWFramesContext
*ctx, ID3D11Texture2D *te
return NULL;
}
+if (s->nb_surfaces <= s->nb_surfaces_used) {
+frames_hwctx->texture_infos = av_realloc_f(frames_hwctx->texture_infos,
+ s->nb_surfaces_used + 1,
+
sizeof(*frames_hwctx->texture_infos));
+if (!frames_hwctx->texture_infos) {
+ID3D11Texture2D_Release(tex);
+return NULL;
+}
+s->nb_surfaces = s->nb_surfaces_used + 1;
+}
+
frames_hwctx->texture_infos[s->nb_surfaces_used].texture = tex;
frames_hwctx->texture_infos[s->nb_surfaces_used].index = index;
s->nb_surfaces_used++;
@@ -284,7 +295,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
}
}
-hwctx->texture_infos = av_calloc(ctx->initial_pool_size,
sizeof(*hwctx->texture_infos));
+hwctx->texture_infos = av_realloc_f(NULL, ctx->initial_pool_size,
sizeof(*hwctx->texture_infos));
if (!hwctx->texture_infos)
return AVERROR(ENOMEM);
s->nb_surfaces = ctx->initial_pool_size;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 4/8] avutil/hwcontext_d3d11va: update hwctx flags from input texture
At least QSV relies on those being set correctly when deriving a hwctx.
---
libavutil/hwcontext_d3d11va.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6355bd1e29..d492489b79 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -287,6 +287,10 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
av_log(ctx, AV_LOG_ERROR, "User-provided texture has mismatching
parameters\n");
return AVERROR(EINVAL);
}
+
+ctx->initial_pool_size = texDesc2.ArraySize;
+hwctx->BindFlags = texDesc2.BindFlags;
+hwctx->MiscFlags = texDesc2.MiscFlags;
} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
texDesc.ArraySize > 0) {
hr = ID3D11Device_CreateTexture2D(device_hwctx->device, &texDesc,
NULL, &hwctx->texture);
if (FAILED(hr)) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/8] fftools/ffmpeg: make debug_ts print raw filter output
---
fftools/ffmpeg.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..a69364c0d4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -765,7 +765,9 @@ static double adjust_frame_pts_to_encoder_tb(OutputFile
*of, OutputStream *ost,
AVFrame *frame)
{
double float_pts = AV_NOPTS_VALUE; // this is identical to frame.pts but
with higher precision
+int64_t orig_pts = AV_NOPTS_VALUE;
AVCodecContext *enc = ost->enc_ctx;
+AVRational filter_tb = (AVRational){ -1, -1 };
if (!frame || frame->pts == AV_NOPTS_VALUE ||
!enc || !ost->filter || !ost->filter->graph->graph)
goto early_exit;
@@ -774,9 +776,10 @@ static double adjust_frame_pts_to_encoder_tb(OutputFile
*of, OutputStream *ost,
AVFilterContext *filter = ost->filter->filter;
int64_t start_time = (of->start_time == AV_NOPTS_VALUE) ? 0 :
of->start_time;
-AVRational filter_tb = av_buffersink_get_time_base(filter);
AVRational tb = enc->time_base;
int extra_bits = av_clip(29 - av_log2(tb.den), 0, 16);
+filter_tb = av_buffersink_get_time_base(filter);
+orig_pts = frame->pts;
tb.den <<= extra_bits;
float_pts =
@@ -794,9 +797,14 @@ static double adjust_frame_pts_to_encoder_tb(OutputFile
*of, OutputStream *ost,
early_exit:
if (debug_ts) {
+av_log(NULL, AV_LOG_INFO, "filter_raw -> pts:%s pts_time:%s
time_base:%d/%d\n",
+ frame ? av_ts2str(orig_pts) : "NULL",
+ frame ? av_ts2timestr(orig_pts, &filter_tb) : "NULL",
+ filter_tb.num, filter_tb.den);
+
av_log(NULL, AV_LOG_INFO, "filter -> pts:%s pts_time:%s exact:%f
time_base:%d/%d\n",
frame ? av_ts2str(frame->pts) : "NULL",
- frame ? av_ts2timestr(frame->pts, &enc->time_base) : "NULL",
+ (enc && frame) ? av_ts2timestr(frame->pts, &enc->time_base) :
"NULL",
float_pts,
enc ? enc->time_base.num : -1,
enc ? enc->time_base.den : -1);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
Since a bunch small stuff has changed since the last time I sent these one by one, here's the whole collection again. I intend to push the whole lot within the next 48h, so they all make it in before 5.1 gets branched. Timo Rothenpieler (8): fftools/ffmpeg: make debug_ts print raw filter output avutil/hwcontext_d3d11va: fix mixed declaration and code avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools avutil/hwcontext_d3d11va: update hwctx flags from input texture avutil/hwcontext_d3d11va: add BGRA/RGBA10 formats support avdevice/lavfi: output wrapped AVFrames avdevice/lavfi: pass forward video framerate avfilter: add vsrc_ddagrab Changelog | 1 + configure | 7 + doc/filters.texi | 68 ++ fftools/ffmpeg.c | 12 +- libavdevice/lavfi.c | 94 +-- libavdevice/version.h | 2 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vsrc_ddagrab.c| 980 ++ libavfilter/vsrc_ddagrab_shaders.h| 120 +++ libavutil/hwcontext_d3d11va.c | 22 +- tests/ref/fate/filter-metadata-cropdetect | 3 +- 13 files changed, 1252 insertions(+), 61 deletions(-) create mode 100644 libavfilter/vsrc_ddagrab.c create mode 100644 libavfilter/vsrc_ddagrab_shaders.h -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 6/8] avdevice/lavfi: output wrapped AVFrames
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames continue to be copied.
Additionally, this enabled passing through video frames that previously
were impossible to process, like hardware frames or other special
formats that couldn't be packed into a rawvideo packet.
---
libavdevice/lavfi.c | 89 +--
libavdevice/version.h | 2 +-
tests/ref/fate/filter-metadata-cropdetect | 3 +-
3 files changed, 38 insertions(+), 56 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index db5d0b94de..1b282a70cb 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -54,32 +54,10 @@ typedef struct {
int *sink_eof;
int *stream_sink_map;
int *sink_stream_subcc_map;
-AVFrame *decoded_frame;
int nb_sinks;
AVPacket subcc_packet;
} LavfiContext;
-static int *create_all_formats(int n)
-{
-int i, j, *fmts, count = 0;
-
-for (i = 0; i < n; i++) {
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(i);
-if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
-count++;
-}
-
-if (!(fmts = av_malloc_array(count + 1, sizeof(*fmts
-return NULL;
-for (j = 0, i = 0; i < n; i++) {
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(i);
-if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
-fmts[j++] = i;
-}
-fmts[j] = AV_PIX_FMT_NONE;
-return fmts;
-}
-
av_cold static int lavfi_read_close(AVFormatContext *avctx)
{
LavfiContext *lavfi = avctx->priv_data;
@@ -90,7 +68,6 @@ av_cold static int lavfi_read_close(AVFormatContext *avctx)
av_freep(&lavfi->sink_stream_subcc_map);
av_freep(&lavfi->sinks);
avfilter_graph_free(&lavfi->graph);
-av_frame_free(&lavfi->decoded_frame);
return 0;
}
@@ -125,15 +102,11 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
LavfiContext *lavfi = avctx->priv_data;
AVFilterInOut *input_links = NULL, *output_links = NULL, *inout;
const AVFilter *buffersink, *abuffersink;
-int *pix_fmts = create_all_formats(AV_PIX_FMT_NB);
enum AVMediaType type;
int ret = 0, i, n;
#define FAIL(ERR) { ret = ERR; goto end; }
-if (!pix_fmts)
-FAIL(AVERROR(ENOMEM));
-
buffersink = avfilter_get_by_name("buffersink");
abuffersink = avfilter_get_by_name("abuffersink");
@@ -264,8 +237,6 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
ret = avfilter_graph_create_filter(&sink, buffersink,
inout->name, NULL,
NULL, lavfi->graph);
-if (ret >= 0)
-ret = av_opt_set_int_list(sink, "pix_fmts", pix_fmts,
AV_PIX_FMT_NONE, AV_OPT_SEARCH_CHILDREN);
if (ret < 0)
goto end;
} else if (type == AVMEDIA_TYPE_AUDIO) {
@@ -321,15 +292,12 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
avpriv_set_pts_info(st, 64, time_base.num, time_base.den);
par->codec_type = av_buffersink_get_type(sink);
if (par->codec_type == AVMEDIA_TYPE_VIDEO) {
-int64_t probesize;
-par->codec_id = AV_CODEC_ID_RAWVIDEO;
+par->codec_id = AV_CODEC_ID_WRAPPED_AVFRAME;
par->format = av_buffersink_get_format(sink);
par->width = av_buffersink_get_w(sink);
par->height = av_buffersink_get_h(sink);
-probesize = par->width * par->height * 30 *
-
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(par->format));
-avctx->probesize = FFMAX(avctx->probesize, probesize);
-st ->sample_aspect_ratio =
+avctx->probesize = FFMAX(avctx->probesize, sizeof(AVFrame) * 30);
+st ->sample_aspect_ratio =
par->sample_aspect_ratio =
av_buffersink_get_sample_aspect_ratio(sink);
} else if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
par->sample_rate = av_buffersink_get_sample_rate(sink);
@@ -348,11 +316,7 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
if ((ret = create_subcc_streams(avctx)) < 0)
goto end;
-if (!(lavfi->decoded_frame = av_frame_alloc()))
-FAIL(AVERROR(ENOMEM));
-
end:
-av_free(pix_fmts);
avfilter_inout_free(&input_links);
avfilter_inout_free(&output_links);
return ret;
@@ -378,15 +342,20 @@ static int create_subcc_packet(AVFormatContext *avctx,
AVFrame *frame,
return 0;
}
+static void lavfi_free_frame(void *opaque, uint8_t *data)
+{
+AVFrame *frame = (AVFrame*)data;
+av_frame_free(&frame);
+}
+
static int lavfi_read_packet(AVForm
[FFmpeg-devel] [PATCH v2 5/8] avutil/hwcontext_d3d11va: add BGRA/RGBA10 formats support
Desktop duplication outputs those
---
libavutil/hwcontext_d3d11va.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index d492489b79..27c0c80413 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -86,6 +86,8 @@ static const struct {
} supported_formats[] = {
{ DXGI_FORMAT_NV12, AV_PIX_FMT_NV12 },
{ DXGI_FORMAT_P010, AV_PIX_FMT_P010 },
+{ DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
+{ DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 7/8] avdevice/lavfi: pass forward video framerate
---
libavdevice/lavfi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 1b282a70cb..246f7dff3b 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -287,6 +287,7 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
for (i = 0; i < lavfi->nb_sinks; i++) {
AVFilterContext *sink = lavfi->sinks[lavfi->stream_sink_map[i]];
AVRational time_base = av_buffersink_get_time_base(sink);
+AVRational frame_rate = av_buffersink_get_frame_rate(sink);
AVStream *st = avctx->streams[i];
AVCodecParameters *const par = st->codecpar;
avpriv_set_pts_info(st, 64, time_base.num, time_base.den);
@@ -299,6 +300,10 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
avctx->probesize = FFMAX(avctx->probesize, sizeof(AVFrame) * 30);
st ->sample_aspect_ratio =
par->sample_aspect_ratio =
av_buffersink_get_sample_aspect_ratio(sink);
+if (frame_rate.num > 0 && frame_rate.den > 0) {
+st->avg_frame_rate = frame_rate;
+st->r_frame_rate = frame_rate;
+}
} else if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
par->sample_rate = av_buffersink_get_sample_rate(sink);
ret = av_buffersink_get_ch_layout(sink, &par->ch_layout);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 8/8] avfilter: add vsrc_ddagrab
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c | 980 +
libavfilter/vsrc_ddagrab_shaders.h | 120
8 files changed, 1179 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vsrc_ddagrab.c
create mode 100644 libavfilter/vsrc_ddagrab_shaders.h
diff --git a/Changelog b/Changelog
index 1a7c84b7f8..9467e92dd1 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version 5.1:
- VDPAU AV1 hwaccel
- PHM image format support
- remap_opencl filter
+- ddagrab (Desktop Duplication) video source filter
version 5.0:
diff --git a/configure b/configure
index 7d5c4900bf..5a1794ebdc 100755
--- a/configure
+++ b/configure
@@ -2309,6 +2309,7 @@ SYSTEM_FUNCS="
SetDllDirectory
setmode
setrlimit
+SetThreadDpiAwarenessContext
Sleep
strerror_r
sysconf
@@ -2352,6 +2353,7 @@ TOOLCHAIN_FEATURES="
"
TYPES_LIST="
+IDXGIOutput5
kCMVideoCodecType_HEVC
kCMVideoCodecType_HEVCWithAlpha
kCMVideoCodecType_VP9
@@ -3154,6 +3156,8 @@ overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
sharpen_npp_filter_deps="ffnvcodec libnpp"
+ddagrab_filter_deps="d3d11va IDXGIOutput1"
+
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
nvenc_deps_any="libdl LoadLibrary"
@@ -6389,10 +6393,13 @@ check_struct "sys/time.h sys/resource.h" "struct
rusage" ru_maxrss
check_type "windows.h dxva.h" "DXVA_PicParams_AV1"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
check_type "windows.h dxva.h" "DXVA_PicParams_VP9"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
+check_type "windows.h dxgi1_2.h" "IDXGIOutput1"
+check_type "windows.h dxgi1_5.h" "IDXGIOutput5"
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "windows.h d3d11.h" "ID3D11VideoContext"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
+check_func_headers windows.h SetThreadDpiAwarenessContext -D_WIN32_WINNT=0x0A00
check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
check_type "vdpau/vdpau.h" "VdpPictureInfoVP9"
diff --git a/doc/filters.texi b/doc/filters.texi
index 296b0693ae..bb651112f6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -26390,6 +26390,74 @@ need for a nullsrc video source.
@end itemize
+@section ddagrab
+
+Captures the Windows Desktop via Desktop Duplication API.
+
+The filter exclusively returns D3D11 Hardware Frames, for on-gpu encoding
+or processing. So an explicit @ref{hwdownload} is needed for any kind of
+software processing.
+
+It accepts the following options:
+
+@table @option
+@item output_idx
+DXGI Output Index to capture.
+
+Usually corresponds to the index Windows has given the screen minus one,
+so it's starting at 0.
+
+Defaults to output 0.
+
+@item draw_mouse
+Whether to draw the mouse cursor.
+
+Defaults to true.
+
+Only affects hardware cursors. If a game or application renders its own cursor,
+it'll always be captured.
+
+@item framerate
+Framerate at which the desktop will be captured.
+
+Defaults to 30 FPS.
+
+@item video_size
+Specify the size of the captured video.
+
+Defaults to the full size of the screen.
+
+Cropped from the bottom/right if smaller than screen size.
+
+@item offset_x
+Horizontal offset of the captured video.
+
+@item offset_y
+Vertical offset of the captured video.
+
+@end table
+
+@subsection Examples
+
+Capture primary screen and encode using nvenc:
+@example
+ffmpeg -f lavfi -i ddagrab -c:v h264_nvenc -cq 18 output.mp4
+@end example
+
+You can also skip the lavfi device and directly use the filter.
+Also demonstrates downloading the frame and encoding with libx264.
+Explicit output format specification is required in this case:
+@example
+ffmpeg -filter_complex
ddagrab=output_idx=1:framerate=60,hwdownload,format=bgra -c:v libx264 -crf 18
output.mp4
+@end example
+
+If you want to capture only a subsection of the desktop, this can be achieved
+by specifying a smaller size and its offsets into the screen:
+@example
+ddagrab=video_size=800x600:offset_x=100:offset_y=100
+@end example
+
+
@section gradients
Generate several gradients.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 139f7cb751..e161196d87 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -555,6 +555,7 @@ OBJS-$(CONFIG_COLOR_FILTER) +=
vsrc_testsrc.o
OBJS-$(CONFIG_COLORCHART_FILTER) += vsrc_testsrc.o
OBJS-$(CONFIG_COLORSPECTRUM_FILTER) += vsrc_testsrc.o
OBJS-$(CONFIG_COREIMAGESRC_FILTER) += vf_coreima
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 12:54 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Timo Rothenpieler > Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c > wrapped_avframe and dependent changes > > Since a bunch small stuff has changed since the last time I sent > these > one by one, here's the whole collection again. > I intend to push the whole lot within the next 48h, so they all make 48h? If I'm not mistaken, the first submission was just two days ago: avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools I hadn't seen that one before: avutil/hwcontext_d3d11va: update hwctx flags from input texture Please give me some time to take a look. Thanks, sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Soft Works > Sent: Saturday, July 9, 2022 1:46 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Timo Rothenpieler > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Timo Rothenpieler > > Sent: Saturday, July 9, 2022 12:54 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Timo Rothenpieler > > Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c > > wrapped_avframe and dependent changes > > > > Since a bunch small stuff has changed since the last time I sent > > these > > one by one, here's the whole collection again. > > I intend to push the whole lot within the next 48h, so they all > make > > 48h? > > If I'm not mistaken, the first submission was just two days ago: > > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size > pools > > I hadn't seen that one before: > > avutil/hwcontext_d3d11va: update hwctx flags from input texture > > > Please give me some time to take a look. Could you please also explain which situations this is supposed to fix? Thank you, sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
On 09.07.2022 01:46, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Timo Rothenpieler Sent: Saturday, July 9, 2022 12:54 AM To: ffmpeg-devel@ffmpeg.org Cc: Timo Rothenpieler Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes Since a bunch small stuff has changed since the last time I sent these one by one, here's the whole collection again. I intend to push the whole lot within the next 48h, so they all make 48h? If I'm not mistaken, the first submission was just two days ago: Yeah, and then a release deadline came up. avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed-size pools I hadn't seen that one before: avutil/hwcontext_d3d11va: update hwctx flags from input texture Those were already discussed on IRC, and are basically fixing up a mess that was made when adding QSV interop. Right now it just trashes the heap without those patches. Just look at all the stuff happening in the qsv hwcontext. It relies on all of those flags being correct, but only did the bare minimum to ensure that. So this is a bunch of missing bits and pieces to at least not make it crash and burn. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 1:49 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > On 09.07.2022 01:46, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Timo Rothenpieler > >> Sent: Saturday, July 9, 2022 12:54 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Cc: Timo Rothenpieler > >> Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c > >> wrapped_avframe and dependent changes > >> > >> Since a bunch small stuff has changed since the last time I sent > >> these > >> one by one, here's the whole collection again. > >> I intend to push the whole lot within the next 48h, so they all > make > > > > 48h? > > > > If I'm not mistaken, the first submission was just two days ago: > > Yeah, and then a release deadline came up. > > > avutil/hwcontext_d3d11va: fix texture_infos writes on non-fixed- > size pools > > > > I hadn't seen that one before: > > > > avutil/hwcontext_d3d11va: update hwctx flags from input texture > > Those were already discussed on IRC, and are basically fixing up a > mess > that was made when adding QSV interop. This was my code which I had done in 2019 and Intel had later adopted it. One Part of the 5% differences where the deviated from my implementation was -- guess what: Setting of those flags... > Right now it just trashes the heap without those patches. > > Just look at all the stuff happening in the qsv hwcontext. > It relies on all of those flags being correct, but only did the bare > minimum to ensure that. > So this is a bunch of missing bits and pieces to at least not make it > crash and burn. I can submit the missing bit of differences as a patch. I thought it was no longer needed. The requirements have also changed over MSDK versions. The 8bit file mapping that I've shown recently exists in fact because an earlier MSDK version was requesting such texture. Anyway, when something is causing trouble, then it should be fixed in hwcontext_qsv. Thanks, sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
On 09.07.2022 02:01, Soft Works wrote: I can submit the missing bit of differences as a patch. I thought it was no longer needed. The requirements have also changed over MSDK versions. The 8bit file mapping that I've shown recently exists in fact because an earlier MSDK version was requesting such texture. Anyway, when something is causing trouble, then it should be fixed in hwcontext_qsv. Settings those flags correctly isn't at all a bad idea though, and not fixing any issue I actively experienced. Just an oversight I noticed while reading the code. Fixing the heap overflow is the major issue and can really only be done in the d3d11 hwcontext. Look at the texture_flags array. It only ever gets initialized to the size of the initial pool size. With a non-fixed-size pool, that grows over time, that obviously is an issue, and will trash whatever comes after the hwcontext on the heap whenever more frames are requested than initially allocated. With a initial size of 0, that is... immediately. An entire other issue this does not address at all, but which also does not cause any memory corruption at least: QSV can't properly deal with a non-fixed-size pool. What happens if more fresh frames are allocated after the qsv hwctx has been derived? From the looks of it, it iterates and maps all the textures only once at init. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Timo Rothenpieler > Sent: Saturday, July 9, 2022 2:15 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, > lavfi.c wrapped_avframe and dependent changes > > On 09.07.2022 02:01, Soft Works wrote: > > I can submit the missing bit of differences as a patch. I thought > > it was no longer needed. The requirements have also changed over > > MSDK versions. The 8bit file mapping that I've shown recently > exists > > in fact because an earlier MSDK version was requesting such > texture. > > > > Anyway, when something is causing trouble, then it should be fixed > > in hwcontext_qsv. > > Settings those flags correctly isn't at all a bad idea though, and > not > fixing any issue I actively experienced. Just an oversight I noticed > while reading the code. > > Fixing the heap overflow is the major issue and can really only be > done > in the d3d11 hwcontext. > Look at the texture_flags array. > It only ever gets initialized to the size of the initial pool size. > With a non-fixed-size pool, that grows over time, that obviously is > an > issue, and will trash whatever comes after the hwcontext on the heap > whenever more frames are requested than initially allocated. > With a initial size of 0, that is... immediately. > > > An entire other issue this does not address at all, but which also > does > not cause any memory corruption at least: > > QSV can't properly deal with a non-fixed-size pool. > What happens if more fresh frames are allocated after the qsv hwctx > has > been derived? > From the looks of it, it iterates and maps all the textures only > once > at init. There's an allocator pattern which filters are using, so when using non-array textures it might be possible to have bigger pools than textures allocated. But that's just a "might". Please give me one or two days to respond with a better and more comprehensive answer. Right now, I'm deeply drowned into something else ;-) Thanks, sw ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes
On 09.07.2022 02:28, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Timo Rothenpieler Sent: Saturday, July 9, 2022 2:15 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes On 09.07.2022 02:01, Soft Works wrote: I can submit the missing bit of differences as a patch. I thought it was no longer needed. The requirements have also changed over MSDK versions. The 8bit file mapping that I've shown recently exists in fact because an earlier MSDK version was requesting such texture. Anyway, when something is causing trouble, then it should be fixed in hwcontext_qsv. Settings those flags correctly isn't at all a bad idea though, and not fixing any issue I actively experienced. Just an oversight I noticed while reading the code. Fixing the heap overflow is the major issue and can really only be done in the d3d11 hwcontext. Look at the texture_flags array. It only ever gets initialized to the size of the initial pool size. With a non-fixed-size pool, that grows over time, that obviously is an issue, and will trash whatever comes after the hwcontext on the heap whenever more frames are requested than initially allocated. With a initial size of 0, that is... immediately. An entire other issue this does not address at all, but which also does not cause any memory corruption at least: QSV can't properly deal with a non-fixed-size pool. What happens if more fresh frames are allocated after the qsv hwctx has been derived? From the looks of it, it iterates and maps all the textures only once at init. There's an allocator pattern which filters are using, so when using non-array textures it might be possible to have bigger pools than textures allocated. But that's just a "might". Please give me one or two days to respond with a better and more comprehensive answer. Right now, I'm deeply drowned into something else ;-) That issue is entirely unrelated to the ddagrab filter. All it needs is the heap overflow fixed, since it very much does run into that. The other stuff are just follow ups I found while skimming through that code. So if you want more time to look into those, that's no big deal at all from my end. And the fix for the heap overflow is as straight forward as it gets. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Remove unsafe bitwise OR on FFVulkanExtensions enum
FFVulkanExtensions enum does not have a value for 0 defined, and bitwise OR on
enums is not safe. The function returns uint64_t, so it makes more sense and is
safer to do arithmetic in terms of uint64_t
Signed-off-by: Amir Mazzarella
---
libavutil/vulkan_loader.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
index 3f1ee6aa46..0b2de4ab94 100644
--- a/libavutil/vulkan_loader.h
+++ b/libavutil/vulkan_loader.h
@@ -50,12 +50,12 @@ static inline uint64_t ff_vk_extensions_to_mask(const char
* const *extensions,
#endif
};
-FFVulkanExtensions mask = 0x0;
+uint64_t mask = 0x0;
for (int i = 0; i < nb_extensions; i++) {
for (int j = 0; j < FF_ARRAY_ELEMS(extension_map); j++) {
if (!strcmp(extensions[i], extension_map[j].name)) {
-mask |= extension_map[j].flag;
+mask |= (uint64_t) extension_map[j].flag;
continue;
}
}
--
2.37.0.rc0.161.g10f37bed90-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Make implicit void pointer cast explicit
Signed-off-by: Amir Mazzarella
---
libavutil/vulkan_loader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
index 3f1ee6aa46..fa8e5ed171 100644
--- a/libavutil/vulkan_loader.h
+++ b/libavutil/vulkan_loader.h
@@ -82,7 +82,7 @@ static inline int ff_vk_load_functions(AVHWDeviceContext *ctx,
uint64_t extensions_mask,
int has_inst, int has_dev)
{
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = (AVVulkanDeviceContext *) ctx->hwctx;
static const struct FunctionLoadInfo {
int req_inst;
--
2.37.0.rc0.161.g10f37bed90-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 8/8] avfilter: add vsrc_ddagrab
On 2022-07-09 04:24 am, Timo Rothenpieler wrote:
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c | 980 +
libavfilter/vsrc_ddagrab_shaders.h | 120
8 files changed, 1179 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vsrc_ddagrab.c
create mode 100644 libavfilter/vsrc_ddagrab_shaders.h
diff --git a/Changelog b/Changelog
index 1a7c84b7f8..9467e92dd1 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version 5.1:
- VDPAU AV1 hwaccel
- PHM image format support
- remap_opencl filter
+- ddagrab (Desktop Duplication) video source filter
The source filters are all generative filters. This should be called a
capture filter.
Why is it a filter instead of in lavd?
Regards,
Gyan
version 5.0:
diff --git a/configure b/configure
index 7d5c4900bf..5a1794ebdc 100755
--- a/configure
+++ b/configure
@@ -2309,6 +2309,7 @@ SYSTEM_FUNCS="
SetDllDirectory
setmode
setrlimit
+SetThreadDpiAwarenessContext
Sleep
strerror_r
sysconf
@@ -2352,6 +2353,7 @@ TOOLCHAIN_FEATURES="
"
TYPES_LIST="
+IDXGIOutput5
kCMVideoCodecType_HEVC
kCMVideoCodecType_HEVCWithAlpha
kCMVideoCodecType_VP9
@@ -3154,6 +3156,8 @@ overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
sharpen_npp_filter_deps="ffnvcodec libnpp"
+ddagrab_filter_deps="d3d11va IDXGIOutput1"
+
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
nvenc_deps_any="libdl LoadLibrary"
@@ -6389,10 +6393,13 @@ check_struct "sys/time.h sys/resource.h" "struct
rusage" ru_maxrss
check_type "windows.h dxva.h" "DXVA_PicParams_AV1"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
check_type "windows.h dxva.h" "DXVA_PicParams_VP9"
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
+check_type "windows.h dxgi1_2.h" "IDXGIOutput1"
+check_type "windows.h dxgi1_5.h" "IDXGIOutput5"
check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
check_type "windows.h d3d11.h" "ID3D11VideoContext"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
+check_func_headers windows.h SetThreadDpiAwarenessContext -D_WIN32_WINNT=0x0A00
check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
check_type "vdpau/vdpau.h" "VdpPictureInfoVP9"
diff --git a/doc/filters.texi b/doc/filters.texi
index 296b0693ae..bb651112f6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -26390,6 +26390,74 @@ need for a nullsrc video source.
@end itemize
+@section ddagrab
+
+Captures the Windows Desktop via Desktop Duplication API.
+
+The filter exclusively returns D3D11 Hardware Frames, for on-gpu encoding
+or processing. So an explicit @ref{hwdownload} is needed for any kind of
+software processing.
+
+It accepts the following options:
+
+@table @option
+@item output_idx
+DXGI Output Index to capture.
+
+Usually corresponds to the index Windows has given the screen minus one,
+so it's starting at 0.
+
+Defaults to output 0.
+
+@item draw_mouse
+Whether to draw the mouse cursor.
+
+Defaults to true.
+
+Only affects hardware cursors. If a game or application renders its own cursor,
+it'll always be captured.
+
+@item framerate
+Framerate at which the desktop will be captured.
+
+Defaults to 30 FPS.
+
+@item video_size
+Specify the size of the captured video.
+
+Defaults to the full size of the screen.
+
+Cropped from the bottom/right if smaller than screen size.
+
+@item offset_x
+Horizontal offset of the captured video.
+
+@item offset_y
+Vertical offset of the captured video.
+
+@end table
+
+@subsection Examples
+
+Capture primary screen and encode using nvenc:
+@example
+ffmpeg -f lavfi -i ddagrab -c:v h264_nvenc -cq 18 output.mp4
+@end example
+
+You can also skip the lavfi device and directly use the filter.
+Also demonstrates downloading the frame and encoding with libx264.
+Explicit output format specification is required in this case:
+@example
+ffmpeg -filter_complex
ddagrab=output_idx=1:framerate=60,hwdownload,format=bgra -c:v libx264 -crf 18
output.mp4
+@end example
+
+If you want to capture only a subsection of the desktop, this can be achieved
+by specifying a smaller size and its offsets into the screen:
+@example
+ddagrab=video_size=800x600:offset_x=100:offset_y=100
+@end example
+
+
@section gradients
Generate several gradients.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 139f7cb751..e161196d87 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -555,6 +5
Re: [FFmpeg-devel] [PATCH] Add metadatareader filter.
Thanks, it will probably take me a couple days to incorporate some of the
feedback regarding style, but some comments:
1) The intent of metadatareader is to read what the metadata filter wrote to a
file, which as you already know, does not make use of any established format.
It simply calls vsnprintf. This intent is backed by FATE test, so any breaking
changes ought to hopefully be caught (and if not, the tests can be enhanced).
If I were to follow your suggestion of adopting a format, then I think I'd
choose VTT, and this would be a much bigger change. It would necessitate that
the metadata filter also be modified to output to VTT rather than use its
current log format. I think if we wanted to do that, I'd still prefer to do
that as a stage 2, and start with a stage 1 where f_metadata.c is UNMODIFIED
but we still have a f_metadatareader.c which can read what it writes to a log
file. Are you suggesting that we can have such a stage 1, with unmodified
f_metadata.c, where f_metadatareader.c is using an already established format
already available in ffmpeg? I think I would be hesitant to go that path d
ue to the asymmetry (f_metadatareader.c uses an existing libavformat to parse,
but f_metadata.c does not and calls vsnprintf directly).
2) Regarding error_tracing.h, I'm all for having a discussion (I assume you are
suggesting to start a new discussion thread), but perhaps also as a stage 2,
maybe for stage 1, I will just delete the file and only move the macros
currently being used into f_metadatareader.c so that they are self-contained
and not intended for general use.
...Cheng
-Original Message-
From: ffmpeg-devel On Behalf Of Nicolas George
Sent: Thursday, July 7, 2022 3:09 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Add metadatareader filter.
Raymond Cheng (12022-07-06):
> FFmpeg has a handy set of filters, metadata/ametadata, which allow us
> to add, print or save per-frame metadata to a file. I will use these
> filters when I want to save the results from speech transcription,
> for instance. What is missing is a way to round-trip the saved
> metadata, so I decided to add filters which go in the opposite
> direction: metadatareader/ametadatareader. These filters inject
> per-frame metadata into the filter graph from a previously saved
> metadata/ametadata file.
>
> If you had a speech transcription filter called speech_recognition
> which produced per-frame metadata using the key "transcription",
> here is how you might use the metadata reader to burn hard subtitles:
>
> Pass 1: ffmpeg -i input -vn -sn -af
> speech_recognition,ametadata=mode=print:file=transcription.txt -f null
> /dev/null
> Pass 2: ffmpeg -i input -vf
> metadatareader=file=transcription.txt,drawtext=fontsize=30:x=30:y=30:fontcolor=yellow:text="'%{metadata\:transcription}'"
> out.mp4
>
> It should be noted in the example above that the metadata crossed
> over from audio to video. It was saved from audio in Pass 1, and
> applied to video on Pass 2. This is perfectly valid, as well as
> non-crossover applications.
Thanks for the contribution. The feature is interesting, but details
will need to be worked on.
The coding style needs to be consistent with the rest of FFmpeg's code.
In particular, only use CamelCase for types, not for variables and
functions. And we definitely do not include the type of variables in
their names.
>
> Signed-off-by: Raymond Cheng
> ---
> Changelog | 1 +
> configure | 2 +
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> libavfilter/f_metadatareader.c| 455 +
It looks to me the file from which the metadata is taken gets parsed in
this patch, and the syntax was invented for the occasion.
First, if the syntax is invented for the occasion, it must be
documented.
Second, we try to avoid inventing a syntax for the occasion. Note that
this objection could have been applied to the print option of the
metadata filter; but printing is a much simpler task than parsing and is
often done the quick-and-dirty way.
I suggest to use libavformat to read frames metadata from a supported
format.
If libavformat does not contain a format that supports frame metadata
and is easy to write, then we can invent a syntax there.
But before inventing a syntax for the whole format, we can consider
using a subtitle format and only invent a syntax to encode frame
metadata in the subtitles text.
> libavutil/error_tracing.h | 126 +
I am all for adding syntactic sugar in libavutil to make error checking
more lightweight. But it needs to be discussed in its own right to meet
the needs and style of more developers.
> tests/fate-run.sh | 3 +
Spurious unrelated changes, debug?
> tests/fate/filter-audio.mak | 7 +
> tests/fate/filter-video.mak | 6 +
>
Re: [FFmpeg-devel] [PATCH] Add metadatareader filter.
I also feel, btw, that there is already precedent for this kind of implied
relationship between f_metadata.c and f_metadatareader.c. For example, the
demuxer/muxer pairs in libavformat, such as movenc.c and mov.c are
complimentary, the latter is implicitly meant to read what the former has
written, and there is no obligation to go to some third component as neutral
ground. Same goes for the encoder/decoder pairs in libavcodec. I want the same
"mated pair" status for f_metadata.c and f_metadatareader.c.
Having said that, I am not at all opposed to modifying f_metadata.c to write
VTT instead of its current format, and having f_metadatareader.c read VTT. The
benefit of that is that VTT is a standalone format understood everywhere, so
that producing such a VTT file can be used by browsers, not just
f_metadatareader.c. You wouldn't have to burn hard subs by reading the VTT into
f_metadatareader.c, you could just place it alongside the MP4 and the browser
will render soft subs. But I'd prefer to do that in stages, with first stage
making no modifications to f_metadata.c.
...Cheng
-Original Message-
From: Raymond Cheng
Sent: Saturday, July 9, 2022 9:26 AM
To: FFmpeg development discussions and patches
Subject: RE: [FFmpeg-devel] [PATCH] Add metadatareader filter.
Thanks, it will probably take me a couple days to incorporate some of the
feedback regarding style, but some comments:
1) The intent of metadatareader is to read what the metadata filter wrote to a
file, which as you already know, does not make use of any established format.
It simply calls vsnprintf. This intent is backed by FATE test, so any breaking
changes ought to hopefully be caught (and if not, the tests can be enhanced).
If I were to follow your suggestion of adopting a format, then I think I'd
choose VTT, and this would be a much bigger change. It would necessitate that
the metadata filter also be modified to output to VTT rather than use its
current log format. I think if we wanted to do that, I'd still prefer to do
that as a stage 2, and start with a stage 1 where f_metadata.c is UNMODIFIED
but we still have a f_metadatareader.c which can read what it writes to a log
file. Are you suggesting that we can have such a stage 1, with unmodified
f_metadata.c, where f_metadatareader.c is using an already established format
already available in ffmpeg? I think I would be hesitant to go that path d
ue to the asymmetry (f_metadatareader.c uses an existing libavformat to parse,
but f_metadata.c does not and calls vsnprintf directly).
2) Regarding error_tracing.h, I'm all for having a discussion (I assume you are
suggesting to start a new discussion thread), but perhaps also as a stage 2,
maybe for stage 1, I will just delete the file and only move the macros
currently being used into f_metadatareader.c so that they are self-contained
and not intended for general use.
...Cheng
-Original Message-
From: ffmpeg-devel On Behalf Of Nicolas George
Sent: Thursday, July 7, 2022 3:09 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Add metadatareader filter.
Raymond Cheng (12022-07-06):
> FFmpeg has a handy set of filters, metadata/ametadata, which allow us
> to add, print or save per-frame metadata to a file. I will use these
> filters when I want to save the results from speech transcription,
> for instance. What is missing is a way to round-trip the saved
> metadata, so I decided to add filters which go in the opposite
> direction: metadatareader/ametadatareader. These filters inject
> per-frame metadata into the filter graph from a previously saved
> metadata/ametadata file.
>
> If you had a speech transcription filter called speech_recognition
> which produced per-frame metadata using the key "transcription",
> here is how you might use the metadata reader to burn hard subtitles:
>
> Pass 1: ffmpeg -i input -vn -sn -af
> speech_recognition,ametadata=mode=print:file=transcription.txt -f null
> /dev/null
> Pass 2: ffmpeg -i input -vf
> metadatareader=file=transcription.txt,drawtext=fontsize=30:x=30:y=30:fontcolor=yellow:text="'%{metadata\:transcription}'"
> out.mp4
>
> It should be noted in the example above that the metadata crossed
> over from audio to video. It was saved from audio in Pass 1, and
> applied to video on Pass 2. This is perfectly valid, as well as
> non-crossover applications.
Thanks for the contribution. The feature is interesting, but details
will need to be worked on.
The coding style needs to be consistent with the rest of FFmpeg's code.
In particular, only use CamelCase for types, not for variables and
functions. And we definitely do not include the type of variables in
their names.
>
> Signed-off-by: Raymond Cheng
> ---
> Changelog | 1 +
> configure | 2 +
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> li
[FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext
Patch attached in the email. In some cases, the submit packet can result in configurations changes of the hardware decoders. The previous HW context is then freed and a new one created. That context is supposed to move up to the main context and the other threads. It appears that when more than 2 frame threads are involved, the new context doesn't move in the right place (or rather at the right time). And it can create a crash when reusing the old HW context. This patch fixes the issue I could reproduce in VLC with DXVA decoding. I have no idea if this is correct or the side effects induced by this. It seems the right thing to do. Keeping the previous call exhibits the issue. It seems odd the other existing thread context are not updated with the current hwaccel_priv_data. But maybe they are updated later from the "main" thread context, in which case this patch seems solid.From e8abeeff92f5d7b3b553acdb7595d40153cbec1e Mon Sep 17 00:00:00 2001 From: Steve Lhomme Date: Fri, 8 Jul 2022 11:49:27 +0200 Subject: [PATCH] avcodec/pthread_frame: update the main avctx from the current ThreadContext After a submit_decoder() the hwaccel_priv_data may have changed in that avctx. Doing it after the "next available frame" loop will likely point to the hwaccel_priv_data from another PerThreadContext which had the old value which might have been freed, if the submit_decoder() resulting in a format change. --- libavcodec/pthread_frame.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index 8faea75a49..eff09c3510 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -529,6 +529,8 @@ int ff_thread_decode_frame(AVCodecContext *avctx, if (err) goto finish; +update_context_from_thread(avctx, p->avctx, 1); + /* * If we're still receiving the initial packets, don't return a frame. */ @@ -578,8 +580,6 @@ int ff_thread_decode_frame(AVCodecContext *avctx, if (finished >= avctx->thread_count) finished = 0; } while (!avpkt->size && !*got_picture_ptr && err >= 0 && finished != fctx->next_finished); -update_context_from_thread(avctx, p->avctx, 1); - if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding = 0; fctx->next_finished = finished; -- 2.27.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
