Re: [FFmpeg-devel] [PATCH] avfilter: add vf_overlay_cuda
Hi!Is it working? I try everything but constantly get error from overlay_cuda: ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid -c:v h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png -filter_complex "[1:v]format=nv12,hwupload[img];[0:v][img]overlay_cuda=x=50:y=800[out]" -map [out] -c:v h264_nvenc -b:v 6M -an -preset fast -y out_nvenc_overlay.mp4 ... ffmpeg version git-2020-04-01-afa5e38 ... [h264_cuvid @ 01dd1b356d00] CUVID capabilities for h264_cuvid: [h264_cuvid @ 01dd1b356d00] 8 bit: supported: 1, min_width: 48, max_width: 4096, min_height: 16, max_height: 4096 [h264_cuvid @ 01dd1b356d00] 10 bit: supported: 0, min_width: 0, max_width: 0, min_height: 0, max_height: 0 [h264_cuvid @ 01dd1b356d00] 12 bit: supported: 0, min_width: 0, max_width: 0, min_height: 0, max_height: 0 Stream mapping: Stream #0:0 (h264_cuvid) -> overlay_cuda:main Stream #1:0 (png) -> format overlay_cuda -> Stream #0:0 (h264_nvenc) Press [q] to stop, [?] for help [h264_cuvid @ 01dd1b356d00] Formats: Original: cuda | HW: cuda | SW: nv12 [graph 0 input from stream 1:0 @ 01dd2e84a100] w:1894 h:302 pixfmt:rgba tb:1/25 fr:25/1 sar:11811/11811 [graph 0 input from stream 0:0 @ 01dd2e84ae00] w:1920 h:1080 pixfmt:cuda tb:1/24000 fr:24000/1001 sar:1/1 [auto_scaler_0 @ 01dd2ebf4cc0] w:iw h:ih flags:'bilinear' interl:0 [Parsed_format_0 @ 01dd2e849780] auto-inserting filter 'auto_scaler_0' between the filter 'graph 0 input from stream 1:0' and the filter 'Parsed_format_0' [auto_scaler_0 @ 01dd2ebf4cc0] w:1894 h:302 fmt:rgba sar:11811/11811 -> w:1894 h:302 fmt:nv12 sar:1/1 flags:0x2 [overlay_cuda @ 01dd2ebc87c0] cu->cuModuleLoadData(&ctx->cu_module, vf_overlay_cuda_ptx) failed -> CUDA_ERROR_INVALID_IMAGE: device kernel image is invalid [Parsed_overlay_cuda_2 @ 01dd2e84b6c0] Failed to configure output pad on Parsed_overlay_cuda_2 Error reinitializing filters! Failed to inject frame into filter network: Generic error in an external library Error while processing the decoded data for stream #0:0 ... --- Original message --- From: "Yaroslav Pogrebnyak" Date: 18 March 2020, 09:29:15 This patch adds 'vf_overlay_cuda' filter. It draws one picture on top of another on CUDA GPU. For the end-user, it's similar to 'vf_overlay_opencl' and other overlay filters. This filter would be especially useful for building video processing pipelines that execute fully on the CUDA GPU. For example, the following pipeline would be possible: decode -> scale -> overlay -> encode, without copying frames between CPU and GPU in between. Technical details. Supported sw input formats are NV12 and YUV420P for main input, and NV12, YUV420P and YUVA420P for overlay input. Main and overlay sw formats should match (i.e, overlaying YUVA420P on NV12 is not implemented). All pixel format conversions are needed to be done with 'format' or 'scale_npp' filters before 'overlay_cuda'. It was needed to slightly modify 'hwcontext_cuda.c' to allow overlays with alpha channel: - Allow AV_PIX_FMT_YUVA420P to enable hwuploading frames with alpha channel to GPU. - Do not shift Height of 4rd plane (alpha) when uploading to GPU. Examples. - Overlay picture on top of video (main: YUVJ420P->NV12, overlay: NV12) $ ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid \ -c:v h264_cuvid -i main.mp4 \ -i ~/overlay.jpg \ -filter_complex "[1:v]format=nv12, hwupload[overlay], [0:v][overlay]overlay_cuda=x=0:y=0:shortest=false" \ -an -c:v h264_nvenc -b:v 5M output.mp4 - Overlay one video on top of another (main: NV12, overlay: NV12) $ ffmpeg -y \ -hwaccel cuvid -c:v h264_cuvid -i main.mp4 \ -hwaccel cuvid -c:v h264_cuvid -i overlay.mp4 \ -filter_complex "[1:v]scale_npp=512:-1[o], [v:0][o]overlay_cuda=x=100:y=100:shortest=true" \ -an -c:v h264_nvenc -b:v 5M output.mp4 - Overlay picture with alpha channel on top of video (main: NV12->YUV420P, overlay: RGBA->YUVA420P) $ ffmpeg -y \ -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid \ -c:v h264_cuvid -i ~/main.mp4 \ -i ~/overlay.png \ -filter_complex "[1:v]format=yuva420p, hwupload[o], [v:0]scale_npp=format=yuv420p[m], [m][o]overlay_cuda=x=0:y=0:shortest=false" \ -an -c:v h264_nvenc -b:v 5M output.mp4 Patch attached. P.S. This is my first patch, I would be grateful for any feedback to know if I'm doing things correctly or not. Thanks! Signed-off-by: Yaroslav Pogrebnyak --- configure | 2 + libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_overlay_cuda.c | 451 + libavfilter/vf_overlay_cuda.cu | 54 libavutil/hwcontext_cuda.c | 3 +- 6 files changed, 511 insertions(+), 1 deletion(-) create mode 100644 libavfilter/vf_overlay_cuda.c create mode 100644 libavfilter/vf_overlay_cuda.cu ___ ffmpeg-devel mailing list f
Re: [FFmpeg-devel] [PATCH] avfilter: add vf_overlay_cuda
Hi!My GPU is GTX 1080Ti. Trying Your command but same error result. I tested on windows build downloaded from https://ffmpeg.zeranoe.com/builds/ Stream mapping: Stream #0:0 (h264) -> overlay_cuda:main Stream #1:0 (png) -> format overlay_cuda -> Stream #0:0 (h264_nvenc) Press [q] to stop, [?] for help [h264 @ 0231eee7ce40] NVDEC capabilities: [h264 @ 0231eee7ce40] format supported: yes, max_mb_count: 65536 [h264 @ 0231eee7ce40] min_width: 48, max_width: 4096 [h264 @ 0231eee7ce40] min_height: 16, max_height: 4096 [h264 @ 0231eee7ce40] Reinit context to 1280x720, pix_fmt: cuda [graph 0 input from stream 1:0 @ 023182422180] w:1894 h:302 pixfmt:rgba tb:1/25 fr:25/1 sar:11811/11811 [graph 0 input from stream 0:0 @ 02318bbe1540] w:1280 h:720 pixfmt:cuda tb:1/24000 fr:24000/1001 sar:1/1 [auto_scaler_0 @ 02318bbe55c0] w:iw h:ih flags:'bilinear' interl:0 [Parsed_format_0 @ 0231825e4bc0] auto-inserting filter 'auto_scaler_0' between the filter 'graph 0 input from stream 1:0' and the filter 'Parsed_format_0' [auto_scaler_0 @ 02318bbe55c0] w:1894 h:302 fmt:rgba sar:11811/11811 -> w:1894 h:302 fmt:nv12 sar:1/1 flags:0x2 [overlay_cuda @ 023182798140] cu->cuModuleLoadData(&ctx->cu_module, vf_overlay_cuda_ptx) failed -> CUDA_ERROR_INVALID_IMAGE: device kernel image is invalid [Parsed_overlay_cuda_2 @ 023182431d40] Failed to configure output pad on Parsed_overlay_cuda_2 Error reinitializing filters! Failed to inject frame into filter network: Generic error in an external library Error while processing the decoded data for stream #0:0 [AVIOContext @ 023182437840] Statistics: 0 seeks, 0 writeouts [AVIOContext @ 0231eee87b80] Statistics: 409657 bytes read, 2 seeks [AVIOContext @ 02318248e700] Statistics: 67602 bytes read, 0 seeks Conversion failed! --- Original message --- From: "Dennis Mungai" Date: 1 April 2020, 16:51:16 On Wed, 1 Apr 2020 at 16:43, Alex <3.1...@ukr.net> wrote: > Hi!Is it working? I try everything but constantly get error from > overlay_cuda: > > > ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid > -c:v h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png > -filter_complex > "[1:v]format=nv12,hwupload[img];[0:v][img]overlay_cuda=x=50:y=800[out]" > -map [out] -c:v h264_nvenc -b:v 6M -an -preset fast -y > out_nvenc_overlay.mp4 > ... > ffmpeg version git-2020-04-01-afa5e38 > ... > [h264_cuvid @ 01dd1b356d00] CUVID capabilities for h264_cuvid: > [h264_cuvid @ 01dd1b356d00] 8 bit: supported: 1, min_width: 48, > max_width: 4096, min_height: 16, max_height: 4096 > [h264_cuvid @ 01dd1b356d00] 10 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > [h264_cuvid @ 01dd1b356d00] 12 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > Stream mapping: > Stream #0:0 (h264_cuvid) -> overlay_cuda:main > Stream #1:0 (png) -> format > overlay_cuda -> Stream #0:0 (h264_nvenc) > Press [q] to stop, [?] for help > [h264_cuvid @ 01dd1b356d00] Formats: Original: cuda | HW: cuda | SW: > nv12 > [graph 0 input from stream 1:0 @ 01dd2e84a100] w:1894 h:302 > pixfmt:rgba tb:1/25 fr:25/1 sar:11811/11811 > [graph 0 input from stream 0:0 @ 01dd2e84ae00] w:1920 h:1080 > pixfmt:cuda tb:1/24000 fr:24000/1001 sar:1/1 > [auto_scaler_0 @ 01dd2ebf4cc0] w:iw h:ih flags:'bilinear' interl:0 > [Parsed_format_0 @ 01dd2e849780] auto-inserting filter 'auto_scaler_0' > between the filter 'graph 0 input from stream 1:0' and the filter > 'Parsed_format_0' > [auto_scaler_0 @ 01dd2ebf4cc0] w:1894 h:302 fmt:rgba sar:11811/11811 > -> w:1894 h:302 fmt:nv12 sar:1/1 flags:0x2 > [overlay_cuda @ 01dd2ebc87c0] cu->cuModuleLoadData(&ctx->cu_module, > vf_overlay_cuda_ptx) failed -> CUDA_ERROR_INVALID_IMAGE: device kernel > image is invalid > [Parsed_overlay_cuda_2 @ 01dd2e84b6c0] Failed to configure output pad > on Parsed_overlay_cuda_2 > Error reinitializing filters! > Failed to inject frame into filter network: Generic error in an external > library > Error while processing the decoded data for stream #0:0 > ... > > > > --- Original message --- > From: "Yaroslav Pogrebnyak" > Date: 18 March 2020, 09:29:15 > > This patch adds 'vf_overlay_cuda' filter. > It draws one picture on top of another on CUDA GPU. > For the end-user, it's similar to 'vf_overlay_opencl' and other overlay > filters. > > This filter would be especially useful for building video processing > pipelines that execute fully on the CUDA GPU. For example, the following > pipeline would be possible: decode -> scale
Re: [FFmpeg-devel] [PATCH] avfilter: add vf_overlay_cuda
My GPU is GTX 1080Ti. --- Original message --- From: "Timo Rothenpieler" Date: 1 April 2020, 16:51:27 On 01.04.2020 15:43, Alex wrote: > Hi!Is it working? I try everything but constantly get error from overlay_cuda: > > > ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid > -c:v h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png > -filter_complex > "[1:v]format=nv12,hwupload[img];[0:v][img]overlay_cuda=x=50:y=800[out]" -map > [out] -c:v h264_nvenc -b:v 6M -an -preset fast -y out_nvenc_overlay.mp4 > ... > ffmpeg version git-2020-04-01-afa5e38 > ... > [h264_cuvid @ 01dd1b356d00] CUVID capabilities for h264_cuvid: > [h264_cuvid @ 01dd1b356d00] 8 bit: supported: 1, min_width: 48, > max_width: 4096, min_height: 16, max_height: 4096 > [h264_cuvid @ 01dd1b356d00] 10 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > [h264_cuvid @ 01dd1b356d00] 12 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > Stream mapping: > Stream #0:0 (h264_cuvid) -> overlay_cuda:main > Stream #1:0 (png) -> format > overlay_cuda -> Stream #0:0 (h264_nvenc) > Press [q] to stop, [?] for help > [h264_cuvid @ 01dd1b356d00] Formats: Original: cuda | HW: cuda | SW: nv12 > [graph 0 input from stream 1:0 @ 01dd2e84a100] w:1894 h:302 pixfmt:rgba > tb:1/25 fr:25/1 sar:11811/11811 > [graph 0 input from stream 0:0 @ 01dd2e84ae00] w:1920 h:1080 pixfmt:cuda > tb:1/24000 fr:24000/1001 sar:1/1 > [auto_scaler_0 @ 01dd2ebf4cc0] w:iw h:ih flags:'bilinear' interl:0 > [Parsed_format_0 @ 01dd2e849780] auto-inserting filter 'auto_scaler_0' > between the filter 'graph 0 input from stream 1:0' and the filter > 'Parsed_format_0' > [auto_scaler_0 @ 01dd2ebf4cc0] w:1894 h:302 fmt:rgba sar:11811/11811 -> > w:1894 h:302 fmt:nv12 sar:1/1 flags:0x2 > [overlay_cuda @ 01dd2ebc87c0] cu->cuModuleLoadData(&ctx->cu_module, > vf_overlay_cuda_ptx) failed -> CUDA_ERROR_INVALID_IMAGE: device kernel image > is invalid Looks like your GPU does not support some of the required features of this filters CUDA Kernel. Which seems odd, given it's general simplicity. What GPU is that? ___ 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] [PATCH] avfilter: add vf_overlay_cuda
Driver 445.75 (Win 10) --- Original message --- From: "Alex" <3.1...@ukr.net> Date: 1 April 2020, 17:01:28 My GPU is GTX 1080Ti. --- Original message --- From: "Timo Rothenpieler" Date: 1 April 2020, 16:51:27 On 01.04.2020 15:43, Alex wrote: > Hi!Is it working? I try everything but constantly get error from overlay_cuda: > > > ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid > -c:v h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png > -filter_complex > "[1:v]format=nv12,hwupload[img];[0:v][img]overlay_cuda=x=50:y=800[out]" -map > [out] -c:v h264_nvenc -b:v 6M -an -preset fast -y out_nvenc_overlay.mp4 > ... > ffmpeg version git-2020-04-01-afa5e38 > ... > [h264_cuvid @ 01dd1b356d00] CUVID capabilities for h264_cuvid: > [h264_cuvid @ 01dd1b356d00] 8 bit: supported: 1, min_width: 48, > max_width: 4096, min_height: 16, max_height: 4096 > [h264_cuvid @ 01dd1b356d00] 10 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > [h264_cuvid @ 01dd1b356d00] 12 bit: supported: 0, min_width: 0, > max_width: 0, min_height: 0, max_height: 0 > Stream mapping: > Stream #0:0 (h264_cuvid) -> overlay_cuda:main > Stream #1:0 (png) -> format > overlay_cuda -> Stream #0:0 (h264_nvenc) > Press [q] to stop, [?] for help > [h264_cuvid @ 01dd1b356d00] Formats: Original: cuda | HW: cuda | SW: nv12 > [graph 0 input from stream 1:0 @ 01dd2e84a100] w:1894 h:302 pixfmt:rgba > tb:1/25 fr:25/1 sar:11811/11811 > [graph 0 input from stream 0:0 @ 01dd2e84ae00] w:1920 h:1080 pixfmt:cuda > tb:1/24000 fr:24000/1001 sar:1/1 > [auto_scaler_0 @ 01dd2ebf4cc0] w:iw h:ih flags:'bilinear' interl:0 > [Parsed_format_0 @ 01dd2e849780] auto-inserting filter 'auto_scaler_0' > between the filter 'graph 0 input from stream 1:0' and the filter > 'Parsed_format_0' > [auto_scaler_0 @ 01dd2ebf4cc0] w:1894 h:302 fmt:rgba sar:11811/11811 -> > w:1894 h:302 fmt:nv12 sar:1/1 flags:0x2 > [overlay_cuda @ 01dd2ebc87c0] cu->cuModuleLoadData(&ctx->cu_module, > vf_overlay_cuda_ptx) failed -> CUDA_ERROR_INVALID_IMAGE: device kernel image > is invalid Looks like your GPU does not support some of the required features of this filters CUDA Kernel. Which seems odd, given it's general simplicity. What GPU is that? ___ 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". ___ 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] avfilter: add vf_overlay_cuda
Driver is ok (I just updated it and same result), and nvenc working without without cuda filters. But with overlay_cuda or scale_cuda ffmpeg is failing. Then I try to install ffmpeg on linux machine and looks like all working ok, but not on windows for me. --- Original message --- From: "Timo Rothenpieler" Date: 1 April 2020, 18:04:05 On 01.04.2020 16:14, Alex wrote: > Driver 445.75 (Win 10) I just tested a similar commandline on the same driver: ./ffmpeg_g.exe -v verbose -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel_output_format cuda -hwaccel cuda -i recode.mkv -i test.png -filter_complex "[1:v]format=nv12,hwupload[p],[0:v][p]overlay_cuda=x=100:y=100" -an -c:v h264_nvenc -y out.mp4 And that works perfectly fine on a RTX2070S. Make sure your driver installation is not somehow damaged. ___ 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] [PATCH] avfilter: add vf_overlay_cuda
But on my linux machine is rtx2070 card, not 1080ti. Do You testing filter on 10xx gpu card? 1 April 2020, 18:12:22, by "Alex" < 3.1...@ukr.net >: Driver is ok (I just updated it and same result), and nvenc working without without cuda filters. But with overlay_cuda or scale_cuda ffmpeg is failing. Then I try to install ffmpeg on linux machine and looks like all working ok, but not on windows for me. --- Original message --- From: "Timo Rothenpieler" Date: 1 April 2020, 18:04:05 On 01.04.2020 16:14, Alex wrote: > Driver 445.75 (Win 10) I just tested a similar commandline on the same driver: ./ffmpeg_g.exe -v verbose -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel_output_format cuda -hwaccel cuda -i recode.mkv -i test.png -filter_complex "[1:v]format=nv12,hwupload[p],[0:v][p]overlay_cuda=x=100:y=100" -an -c:v h264_nvenc -y out.mp4 And that works perfectly fine on a RTX2070S. Make sure your driver installation is not somehow damaged. ___ 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". ___ 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] vp9_qsv encoder
Is it vp9_qsv encoder will work on i9-9900k Intel CPU or we need to wait for new CPU release from Intel? ___ 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] Overlay_cuda filter
Hi! We have overlay_opencl, overlay_qsv, ... etc, but don't have overlay_cuda what can be speed up video processing without copy frame between cpu and gpu. So, doy You guys planning to implement overlay_cuda filter? Alex ___ 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] Overlay_cuda filter
Ok, thank for answering.Can I help to speed up implementation of GPU overlay? From my side I can pay from my pocket around 100USD for this features. Alex --- Исходное сообщение --- От кого: "Timo Rothenpieler" Дата: 20 ноября 2019, 12:49:59 On 20/11/2019 10:30, Alex wrote: > Hi! > We have overlay_opencl, overlay_qsv, ... etc, but don't have overlay_cuda > what can be speed up video processing without copy frame between cpu and gpu. > So, doy You guys planning to implement overlay_cuda filter? > Alex Ideally, there would soon be CUDA/Vulkan interop, and an overlay_vulkan filter, which can do this in a more vendor agnostic way. But there have been some hurdles with that work. ___ 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".
[FFmpeg-devel] Can anyone write simple "http" filter for 100$ ?
Hi!Can any one write simple "http" filter for ffmpeg and I'm paying for this job 100$. Filter must accept server address, port, path, query as options. This filter, just send post request with attached raw image/frame data to the server and server will respond with new post-processed image/frame then this frame must be injected to next filter in ffmpeg filter complex. In other word I need to do post-processing of image/frame on remote server. Filter must be used like so: ffmpeg -i video.mp4 -vf scale=1920:-1,format=rgb24,http=http//127.0.0.1:8080/image-post-processing?param1=abc¶m2=123,format=yuv420p -c:v h264 -an -y out.mp4 Is it possible to use libcurl for post requests in ffmpeg filter? https://curl.haxx.se/libcurl/c/postinmemory.html ___ 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] Can anyone write simple "http" filter for 100$ ?
I think it's not so bad if in my case server post-process of images is very slow (max 3-10fps). And I'ts easy way to communicate between ffmpeg filter and other process/server.Why not? --- Original message --- From: "Paul B Mahol" Date: 8 September 2020, 14:30:05 On Tue, Sep 08, 2020 at 01:58:44PM +0300, Alex wrote: > Hi!Can any one write simple "http" filter for ffmpeg and I'm paying for this > job 100$. > Filter must accept server address, port, path, query as options. This filter, > just send post request with attached raw image/frame data to the server and > server will respond with new post-processed image/frame then this frame must > be injected to next filter in ffmpeg filter complex. > In other word I need to do post-processing of image/frame on remote server. > > Filter must be used like so: > ffmpeg -i video.mp4 -vf > scale=1920:-1,format=rgb24,http=http//127.0.0.1:8080/image-post-processing?param1=abc¶m2=123,format=yuv420p > -c:v h264 -an -y out.mp4 This is just a bad idea to do. > > Is it possible to use libcurl for post requests in ffmpeg filter? > https://curl.haxx.se/libcurl/c/postinmemory.html Even if it is really possible, it would be bad idea to write filter which would do it. Would filter need to wait indefinetely for server response, etc. There are so many issue with such idea. There are much better ways to do what you want. ___ 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] Can anyone write simple "http" filter for 100$ ?
It just send raw frames/images to other process/server and wait for response. Nothing complicated. --- Original message --- From: "Nicolas George" Date: 8 September 2020, 14:36:45 Alex (12020-09-08): > Hi!Can any one write simple "http" filter for ffmpeg and I'm paying > for this job 100$. > Filter must accept server address, port, path, query as options. This > filter, just send post request with attached raw image/frame data to > the server and server will respond with new post-processed image/frame > then this frame must be injected to next filter in ffmpeg filter > complex. > In other word I need to do post-processing of image/frame on remote server. There have been talk or external filters for a long time, including systems to run filters in separate processes or hosts. That means the principle of doing it is accepted, but it needs to be done in a way that suits all the use cases that were evoked; it requires careful design. So I want to make it clear that I would strongly oppose, and I would not be alone, to a quick-and-dirty solution designed just to catch this bounty. Regards, -- Nicolas George ___ 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".
[FFmpeg-devel] [PATCH] avfilter: add http video filter.
Signed-off-by: alex_qt <3.1...@ukr.net>
---
Changelog| 1 +
configure| 4 +
doc/filters.texi | 28 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 2 +-
libavfilter/vf_http.c| 221 +++
7 files changed, 257 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_http.c
diff --git a/Changelog b/Changelog
index cd8be931ef..777cca679a 100644
--- a/Changelog
+++ b/Changelog
@@ -22,6 +22,7 @@ version :
- MODS demuxer
- PhotoCD decoder
- MCA demuxer
+- http video filter, send raw frames to remote url for postprocessing
version 4.3:
diff --git a/configure b/configure
index ae8c6e61c8..f5131d4669 100755
--- a/configure
+++ b/configure
@@ -325,6 +325,7 @@ External library support:
--enable-vulkan enable Vulkan code [no]
--disable-xlib disable xlib [autodetect]
--disable-zlib disable zlib [autodetect]
+ --enable-libcurl enable http filter that send raw frames to remote server
The following libraries provide various hardware acceleration features:
--disable-amfdisable AMF video encoding code [autodetect]
@@ -1827,6 +1828,7 @@ EXTERNAL_LIBRARY_LIST="
opengl
pocketsphinx
vapoursynth
+libcurl
"
HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3650,6 +3652,7 @@ vpp_qsv_filter_select="qsvvpp"
xfade_opencl_filter_deps="opencl"
yadif_cuda_filter_deps="ffnvcodec"
yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+http_filter_deps="libcurl"
# examples
avio_list_dir_deps="avformat avutil"
@@ -6367,6 +6370,7 @@ enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h mys
enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig -lnppicc -lnppc -lnppidei ||
check_lib libnpp npp.h nppGetLibVersion -lnppi -lnppc -lnppidei ||
die "ERROR: libnpp not found"; }
+enabled libcurl && require "libcurl >= 7.68.0" curl/curl.h curl_easy_init -lcurl
enabled libopencore_amrnb && require libopencore_amrnb opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
enabled libopencv && { check_headers opencv2/core/core_c.h &&
diff --git a/doc/filters.texi b/doc/filters.texi
index cbb16f22b2..660ef8b4d9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12078,6 +12078,34 @@ For example, to horizontally flip the input video with @command{ffmpeg}:
ffmpeg -i in.avi -vf "hflip" out.avi
@end example
+@anchor{http}
+@section http
+
+Send raw frame data to the remote server for postprocessing and await response as new frame in same format and size. To enable filter configure ffmpeg with @code{./configure --enable-libcurl}.
+
+The filter accepts the following options:
+
+@table @option
+@item url
+Specify remote server url location.
+
+@item content_type
+Specify content-type header in request header, default to "application/octet-stream".
+@end table
+
+Simple demo http server for postprocessing frames can be found here: @url{https://github.com/devalexqt/simple_ffmpeg_http_filter_server}
+
+@subsection Examples
+@itemize
+
+@item
+Send raw frames to "http://localhost:3000/frame?param=abc";
+
+@example
+ffmpeg -i input.mp4 -vf format=rgb24,http=url="http\\\://localhost\\\:3000/frame?param=abc":content_type=application/octet-stream -t 10 out.mp4
+@end example
+@end itemize
+
@section histeq
This filter applies a global color histogram equalization on a
per-frame basis.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e6d3c283da..38eb1f4204 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -467,6 +467,7 @@ OBJS-$(CONFIG_YAEPBLUR_FILTER) += vf_yaepblur.o
OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
+OBJS-$(CONFIG_HTTP_FILTER) += vf_http.o
OBJS-$(CONFIG_ALLRGB_FILTER) += vsrc_testsrc.o
OBJS-$(CONFIG_ALLYUV_FILTER) += vsrc_testsrc.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index fa91e608e4..8626fbc331 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -445,6 +445,7 @@ extern AVFilter ff_vf_yaepblur;
extern AVFilter ff_vf_zmq;
extern AVFilter ff_vf_zoompan;
extern AVFilter ff_vf_zscale;
+extern AVFilter ff_vf_http;
extern AVFilter ff_vsrc_allrgb;
extern AVFilter ff_vsrc_allyuv;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 308fbe07c3..b8ba489da7 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFILTER_VERSION_MAJOR 7
-#define LIBAVFILTER_VERSION_MINOR 87
+#define LIBAVFILTER_VERSION_MINOR 88
#d
Re: [FFmpeg-devel] [PATCH] avfilter: add http video filter.
> Hard-coded URL parameters, >nothing to set the formats, not even the possibility of a filter that >changes the resolution. This filter has options: url and content-type header for requests and it's not hardcoded. Format and resolution can be changed after this filter later in filter graph, it's not a job for this filter, for example: ffmpeg -i video.mp4 -vf scale=1920:-1,format=rgb24,http=url="http://localhost:3000/frame?type=ffmpeg":content_type="application/octet-stream",scale=1280:-1,format=yuv420p -c:v h264 -y out.mp4 And it will be send raw frames to servers with additional parameters in url query, like that: "POST http://localhost:3000/frame?type=ffmpeg&width=1280&height=720&format=2&linesize=344336064&size=2764800&pts=22012 For my opportunity this filter open door for postprocess frames outside of ffmpeg, so filter can be written or at least prototyped in other languages: js, python, go, etc without touching ffmpeg code and quick start for people who don't know c language or may be script is to big for porting to ffmpeg code. For my use case I will be used it to "connect" ffmpeg to python (this script is huge and complicated to porting to c language and ffmpeg) script that postprocess frame/image in different process (docker container). Without this http filter I must do the same stuff in multiple steps, for example (it's typical usage): #1 use ffmpeg to extract jpg's images for every frame from video and save it to folder on disk #2 run custom python script on every images in folder and create output images #3 use ffmpeg to marge images into video and do something to sink movie But instead of multistage flow I can convert video in single step with injection of "http" filter in filter graph like in example. --- Original message --- From: "Nicolas George" Date: 11 September 2020, 12:40:23 Timo Rothenpieler (12020-09-11): > Entirely outside of this filter being acceptable at all, > pulling in libcurl is not an option without major safeguards for every > single overlapping tls library both ffmpeg and curl support. > If both are using the same library, there is a huge potential for libcurl > being linked at all breaks ffmpegs ability to talk TLS. > > On top of that, ffmpeg already has code to talk to http servers, so pulling > in a library to do it is even less acceptable. I completely agree with this. > I also really fail to see the utility of this filter. What's stopping you > from just making ffmpeg output raw frames and then sending them off via the > curl cli tool or whatever else? This would happen at the end of the filter graph. This patch is for something in the middle. For a complex graph, I do not think there is an easy way of implementing with just command-line tools. We would need some kind of movie sink for that. But this is way too specific to be accepted. Hard-coded URL parameters, nothing to set the formats, not even the possibility of a filter that changes the resolution. This is exactly what I was warning about in this mail: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269348.html And do not let us forget that the coding style is not at all what we do. Regards, -- Nicolas George ___ 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] [PATCH] avfilter: add http video filter.
>The format for the parameters is hard-coded.Please, tell me more I don't >understand that do You mean? --- Original message --- From: "Nicolas George" Date: 11 September 2020, 14:09:47 Alex (12020-09-11): > This filter has options: url and content-type header for requests and it's > not hardcoded. The format for the parameters is hard-coded. > Format and resolution can be changed after this filter later in filter > graph, it's not a job for this filter, for example: It is a job for this filter if the external processing requires it. As it is, the external processing must return frames with the same format and resolution as its input, which is a completely unacceptable limitation. > For my opportunity this filter open door for postprocess frames outside of > ffmpeg We do not accept patches for somebody's opportunity. Patches need to be generic enough to work for many people. The hard-coding of HTTP, the hard-coding of the parameters passing, the arbitrary limitations make this unacceptable. The sooner you accept it and start thinking more globally, the sooner you can consider making something that would be accepted. I have given an indication: what you need a movie sink. Regards, -- Nicolas George ___ 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] [PATCH] avfilter: add http video filter.
> The hard-coding of HTTP, the hard-coding of the parameters passing, the > arbitrary limitations make> this unacceptable. Can You explain more, because I not fully understand "hard-coding " params, http. > It is a job for this filter if the external processing requires it. As > it is, the external processing must return frames with the same format > and resolution as its input, which is a completely unacceptable > limitation I found way for fixing that, server must set headers with new image params in response and then it's possible to create new frame with right width, height, pix format, etc. I will fix it. --- Original message --- From: "Nicolas George" Date: 11 September 2020, 14:09:47 Alex (12020-09-11): > This filter has options: url and content-type header for requests and it's > not hardcoded. The format for the parameters is hard-coded. > Format and resolution can be changed after this filter later in filter > graph, it's not a job for this filter, for example: It is a job for this filter if the external processing requires it. As it is, the external processing must return frames with the same format and resolution as its input, which is a completely unacceptable limitation. > For my opportunity this filter open door for postprocess frames outside of > ffmpeg We do not accept patches for somebody's opportunity. Patches need to be generic enough to work for many people. The hard-coding of HTTP, the hard-coding of the parameters passing, the arbitrary limitations make this unacceptable. The sooner you accept it and start thinking more globally, the sooner you can consider making something that would be accepted. I have given an indication: what you need a movie sink. Regards, -- Nicolas George ___ 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".
[FFmpeg-devel] scale2ref throw segmentation fault if reference frame is HW (cuda)
scale2ref video filter failed with message "segmentation fault". Command to reproduce: I just want to scale watermark depending of size of the main video. ffmpeg -init_hw_device cuda=cuda hwaccel cuda -hwaccel_output_format cuda -filter_hw_device cuda -i 720p.mp4 -ss 10 -t 10 -filter_complex scale_npp=1920:1080:force_original_aspect_ratio=1:format=yuv420p[scaled],movie=logo.png[watermark_in],[watermark_in][scaled]scale2ref=iw/2:ih/2[watermark_out][scaled_out],[watermark_out]hwupload[watermark_hw],[scaled_out][watermark_hw]overlay_cuda=x=0:y=0 -c:v h264_nvenc -an -y out.mp4 ___ 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] Fixing scale2ref filter in case if reference frame is hw frame
This path fixing scale2ref filter if reference frame is HW frame.Command for
add watermark (resize it based on the main/reference video size:
[watermark][scaled]scale2ref=oh*mdar:ih*0.5[watermark2][scaled2] ) on video in
case of HW pipeline:>./ffmpeg -init_hw_device cuda=cuda -hwaccel cuda
-hwaccel_output_format cuda -filter_hw_device cuda -i input -t 60
-filter_complex
scale_npp=1920:1080:format=yuv420p[scaled],movie=/media/converter/watermark/watermark_ai.png,format=yuva420p[watermark],[watermark][scaled]scale2ref=oh*mdar:ih*0.5[watermark2][scaled2],[watermark2]hwupload[watermark_hw],[scaled2][watermark_hw]overlay_cuda=x=0:y=0
-c:v h264_nvenc -an -y out.mp4
Command for add watermark on video in case of SW pipeline:>./ffmpeg -i
input.mp4 -t 60 -filter_complex
scale=1920:1080,format=yuv420p[scaled],movie=/media/converter/watermark/watermark_ai.png,format=yuva420p[watermark],[watermark][scaled]scale2ref=oh*mdar:ih*0.5[watermark2][scaled2],[scaled2][watermark2]overlay=x=0:y=0
-c:v h264 -an -y out.mp4
Signed-off-by: alex_qt <3.1...@ukr.net>
---
libavfilter/vf_scale.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 58eee96744..6b587e8cd4 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -609,7 +609,9 @@ static int config_props_ref(AVFilterLink *outlink)
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->time_base = inlink->time_base;
outlink->frame_rate = inlink->frame_rate;
-
+if (inlink->hw_frames_ctx) {
+outlink->hw_frames_ctx = av_buffer_ref(inlink->hw_frames_ctx);
+}
return 0;
}
___
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] Added support for expressions main_w, main_h, overlay_w, overlay_h in cuda_overlay filter
Signed-off-by: alex_qt <3.1...@ukr.net>
---
libavfilter/vf_overlay_cuda.c | 146 --
1 file changed, 120 insertions(+), 26 deletions(-)
diff --git a/libavfilter/vf_overlay_cuda.c b/libavfilter/vf_overlay_cuda.c
index 2f0f860e50..636ddbedb0 100644
--- a/libavfilter/vf_overlay_cuda.c
+++ b/libavfilter/vf_overlay_cuda.c
@@ -30,11 +30,15 @@
#include "libavutil/hwcontext.h"
#include "libavutil/hwcontext_cuda_internal.h"
#include "libavutil/cuda_check.h"
+#include "libavutil/eval.h"
#include "avfilter.h"
#include "framesync.h"
#include "internal.h"
+#define OFFSET(x) offsetof(OverlayCUDAContext, x)
+#define FLAGS (AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM)
+
#define CHECK_CU(x) FF_CUDA_CHECK_DL(ctx, ctx->hwctx->internal->cuda_dl, x)
#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
@@ -54,6 +58,16 @@ static const enum AVPixelFormat supported_overlay_formats[] = {
AV_PIX_FMT_NONE,
};
+enum var_name {
+VAR_MAIN_W, VAR_MW,
+VAR_MAIN_H, VAR_MH,
+VAR_OVERLAY_W, VAR_OW,
+VAR_OVERLAY_H, VAR_OH,
+VAR_OVERLAY_X, VAR_OX,
+VAR_OVERLAY_Y, VAR_OY,
+VAR_VARS_NB
+};
+
/**
* OverlayCUDAContext
*/
@@ -69,14 +83,77 @@ typedef struct OverlayCUDAContext {
CUmodule cu_module;
CUfunction cu_func;
CUstream cu_stream;
+CUfunction cu_func_uchar;
FFFrameSync fs;
int x_position;
int y_position;
+double var_values[VAR_VARS_NB];
+char *x_expr,*y_expr;
} OverlayCUDAContext;
+static const char *const var_names[] = {
+"main_w","W", ///< width of the mainvideo
+"main_h","H", ///< height of the mainvideo
+"overlay_w", "w", ///< width of the overlay video
+"overlay_h", "h", ///< height of the overlay video
+NULL
+};
+
+static const AVOption overlay_cuda_options[] = {
+{ "x", "set the x expression", OFFSET(x_expr), AV_OPT_TYPE_STRING, {.str = "0"}, 0, 0, FLAGS },
+{ "y", "set the y expression", OFFSET(y_expr), AV_OPT_TYPE_STRING, {.str = "0"}, 0, 0, FLAGS },
+{ "eof_action", "Action to take when encountering EOF from secondary input ",
+OFFSET(fs.opt_eof_action), AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_REPEAT },
+EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
+{ "repeat", "Repeat the previous frame.", 0, AV_OPT_TYPE_CONST, { .i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
+{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, { .i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
+{ "pass", "Pass through the main input.", 0, AV_OPT_TYPE_CONST, { .i64 = EOF_ACTION_PASS }, .flags = FLAGS, "eof_action" },
+{ "shortest", "force termination when the shortest input terminates", OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
+{ "repeatlast", "repeat overlay of the last overlay frame", OFFSET(fs.opt_repeatlast), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
+{ NULL },
+};
+
+FRAMESYNC_DEFINE_CLASS(overlay_cuda, OverlayCUDAContext, fs);
+
+static int eval_expr(AVFilterContext *ctx)
+{
+OverlayCUDAContext *c = ctx->priv;
+double *var_values = c->var_values;
+intret = 0;
+AVExpr *x_expr = NULL, *y_expr = NULL;
+
+#define PASS_EXPR(e, s) {\
+ret = av_expr_parse(&e, s, var_names, NULL, NULL, NULL, NULL, 0, ctx); \
+if (ret < 0) {\
+av_log(ctx, AV_LOG_ERROR, "Error when passing '%s'.\n", s);\
+goto release;\
+}\
+}
+PASS_EXPR(x_expr, c->x_expr);
+PASS_EXPR(y_expr, c->y_expr);
+#undef PASS_EXPR
+
+var_values[VAR_OVERLAY_X] =
+var_values[VAR_OX]= av_expr_eval(x_expr, var_values, NULL);
+var_values[VAR_OVERLAY_Y] =
+var_values[VAR_OY]= av_expr_eval(y_expr, var_values, NULL);
+
+/* calc again in case ox is relative to oy */
+var_values[VAR_OVERLAY_X] =
+var_values[VAR_OX]= av_expr_eval(x_expr, var_values, NULL);
+
+c->x_position=(int)var_values[VAR_OVERLAY_X];
+c->y_position=(int)var_values[VAR_OVERLAY_Y];
+release:
+av_expr_free(x_expr);
+av_expr_free(y_expr);
+
+return ret;
+}
+
/**
* Helper to find out if provided format is supported by filter
*/
@@ -174,8 +251,6 @@ static int overlay_cuda_blend(FFFrameSync *fs)
return ret;
}
-// overlay first plane
-
overlay_cuda_call_kernel(ctx,
ctx->x_position, ctx->y_position,
input_main->data[0], input_main->linesize[0],
@@ -280,11 +355,49 @@ static int overlay_cuda_query_formats(AVFilterContext *avctx)
}
/**
- * Configure output
+ * Configure inputs
*/
-static int overlay_cuda_config_output(AVFilterLink *outlink)
+ static int config_main_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+OverlayCUDAContext*o = ctx->priv;
+
+av_log(ctx, AV_LOG_DEBUG, "Input[%d] is of %s.\n", FF_INLINK_IDX(inlink),
+ av_get_pix_fmt_name(inlink->format));
+
[FFmpeg-devel] python filter
Is it possible to implement python backend as ffmpeg video filter, like https://openvinotoolkit.github.io/dlstreamer_gst/ ? ___ 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] python filter
Yes. I wat to do filtering inside python script. 7 December 2021, 05:16:50, by "Steven Liu" : Alex <3.1...@ukr.net> 于2021年12月7日周二 上午9:12写道： > > Is it possible to implement python backend as ffmpeg video filter, like > https://openvinotoolkit.github.io/dlstreamer_gst/ ? Do you mean add a Python parser into libavfilter looks like a GLSL parser? > ___ > 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". ___ 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] DNN data layout CHW or HWC and data normalization or denormalization?
Hi! Can any one tell me is it layout of DNNData->data are chw or hwc or nchw or nhwc? And how to perform convertion from hwc to chw and reverse? How to normalize and denormalize data (-1..0..1 <=> 0...255) ? ___ 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] DNN data layout CHW or HWC and data normalization or denormalization?
Do anyone know fastest way to divide the chw array of pixel data for frame? 1 January 2022, 04:48:03, by "Guo, Yejun" : -Original Message- From: ffmpeg-devel On Behalf Of Alex Sent: 2022年1月1日 3:16 To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] DNN data layout CHW or HWC and data normalization or denormalization? Hi! Can any one tell me is it layout of DNNData->data are chw or hwc or nchw or nhwc? And how to perform convertion from hwc to chw and reverse? How to normalize and denormalize data (-1..0..1 <=> 0...255) ? Just NHWC is supported now, and patches are welcome. ___ 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] [PATCH 7/7] lavfi/metal: fix build with pre-10.11 deployment targets
Can you tell me more where this come from ?
extern char ff_vf_yadif_videotoolbox_metallib_data[];
extern unsigned int ff_vf_yadif_videotoolbox_metallib_len;
22 December 2021, 02:15:23, by "rcombs" :
- Ensure the yadif .metal compiles when targeting any Metal runtime version
- Use some preprocessor awkwardness to ensure Core Video's Metal-specific
functionality is exposed regardless of our deployment target (this works
around what seems to be an SDK header bug, filed as FB9816002)
- Ensure all direct references to Metal functions and classes are gated
behind runtime version checks (this satisfies clang's deployment-target
violation warnings provided by -Wunguarded-availability).
---
libavfilter/metal/utils.h | 28 +++-
libavfilter/metal/vf_yadif_videotoolbox.metal | 11 ++-
libavfilter/vf_yadif_videotoolbox.m | 67 ---
3 files changed, 94 insertions(+), 12 deletions(-)
diff --git a/libavfilter/metal/utils.h b/libavfilter/metal/utils.h
index bd0319f63c..7350d42a35 100644
--- a/libavfilter/metal/utils.h
+++ b/libavfilter/metal/utils.h
@@ -20,16 +20,40 @@
#define AVFILTER_METAL_UTILS_H
#include
+
+#include
+
+// CoreVideo accidentally(?) preprocessor-gates Metal functionality
+// on MAC_OS_X_VERSION_MIN_REQUIRED >= 101100 (FB9816002).
+// There doesn't seem to be any particular reason for this,
+// so here we temporarily redefine it to at least that value
+// so CV will give us CVMetalTextureRef and the related functions.
+
+#if defined(MAC_OS_X_VERSION_MIN_REQUIRED) && (MAC_OS_X_VERSION_MIN_REQUIRED <
101100)
+#define ORIG_MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_MIN_REQUIRED
+#undef MAC_OS_X_VERSION_MIN_REQUIRED
+#define MAC_OS_X_VERSION_MIN_REQUIRED 101100
+#endif
+
#include
+#ifdef ORIG_MAC_OS_X_VERSION_MIN_REQUIRED
+#undef MAC_OS_X_VERSION_MIN_REQUIRED
+#define MAC_OS_X_VERSION_MIN_REQUIRED ORIG_MAC_OS_X_VERSION_MIN_REQUIRED
+#undef ORIG_MAC_OS_X_VERSION_MIN_REQUIRED
+#endif
+
void ff_metal_compute_encoder_dispatch(id device,
id pipeline,
id encoder,
- NSUInteger width, NSUInteger height);
+ NSUInteger width, NSUInteger height)
+ API_AVAILABLE(macos(10.11), ios(8.0));
CVMetalTextureRef ff_metal_texture_from_pixbuf(void *avclass,
CVMetalTextureCacheRef
textureCache,
CVPixelBufferRef pixbuf,
int plane,
- MTLPixelFormat format);
+ MTLPixelFormat format)
+ API_AVAILABLE(macos(10.11),
ios(8.0));
+
#endif /* AVFILTER_METAL_UTILS_H */
diff --git a/libavfilter/metal/vf_yadif_videotoolbox.metal
b/libavfilter/metal/vf_yadif_videotoolbox.metal
index 50783f2ffe..8a3d41a30f 100644
--- a/libavfilter/metal/vf_yadif_videotoolbox.metal
+++ b/libavfilter/metal/vf_yadif_videotoolbox.metal
@@ -26,6 +26,15 @@
using namespace metal;
+/*
+ * Version compat shims
+ */
+
+#if __METAL_VERSION__ < 210
+#define max3(x, y, z) max(x, max(y, z))
+#define min3(x, y, z) min(x, min(y, z))
+#endif
+
/*
* Parameters
*/
@@ -44,7 +53,7 @@ struct deintParams {
*/
#define accesstype access::sample
-const sampler s(coord::pixel);
+constexpr sampler s(coord::pixel);
template
T tex2D(texture2d tex, uint x, uint y)
diff --git a/libavfilter/vf_yadif_videotoolbox.m
b/libavfilter/vf_yadif_videotoolbox.m
index 65f155982e..455745817f 100644
--- a/libavfilter/vf_yadif_videotoolbox.m
+++ b/libavfilter/vf_yadif_videotoolbox.m
@@ -26,10 +26,12 @@
#include "libavutil/hwcontext.h"
#include "libavutil/objc.h"
+#include
+
extern char ff_vf_yadif_videotoolbox_metallib_data[];
extern unsigned int ff_vf_yadif_videotoolbox_metallib_len;
-typedef struct YADIFVTContext {
+typedef struct API_AVAILABLE(macos(10.11), ios(8.0)) YADIFVTContext {
YADIFContext yadif;
AVBufferRef *device_ref;
@@ -44,7 +46,12 @@ typedef struct YADIFVTContext {
id mtlParamsBuffer;
CVMetalTextureCacheRef textureCache;
-} YADIFVTContext;
+} YADIFVTContext API_AVAILABLE(macos(10.11), ios(8.0));
+
+// Using sizeof(YADIFVTContext) outside of an availability check will error
+// if we're targeting an older OS version, so we need to calculate the size
ourselves
+// (we'll statically verify it's correct in yadif_videotoolbox_init behind a
check)
+#define YADIF_VT_CTX_SIZE (sizeof(YADIFContext) + sizeof(void*) * 10)
struct mtlYadifParams {
uint channels;
@@ -62,7 +69,7 @@ static void call_kernel(AVFilterContext *ctx,
id next,
int channels,
int parity,
-int tff)
+
[FFmpeg-devel] filter queue question
Hi! I developing custom GPU filter that require lot of time to process frames and as result overal fps is low ( around 20 fps): ffmpeg -i 720p.mp4 -filter_complex "format=rgb24,myfilter" -f null - But then I added actual encoding part to ffmpeg command, result fps is down to 16 fps (-4 fps, around 20%!!!): ffmpeg -i 720p.mp4 -filter_complex "format=rgb24,myfilter" -c:v h264 -y out.mp4 If I look at timeline of overla process in each cycle: |decoding time---| ---> |--filtering time-| ---> |---encoding time---| So, basically can I process frame in my custom filter without waiting for encoding to finish? In other word I want to process frames in my custom filter in parallel/queue to encoding process??? ___ 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] filter queue question
Thanks I will chek it out! For now my filter use standart filter_frame() function callback. But how to request next frame from decoder in my filter? 5 July 2022, 16:19:49, by "Felix LeClair" : From: ffmpeg-devel on behalf of Alex <3.1...@ukr.net> Sent: July 5, 2022 9:00 AM To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] filter queue question Hi! I developing custom GPU filter that require lot of time to process frames and as result overal fps is low ( around 20 fps): ffmpeg -i 720p.mp4 -filter_complex "format=rgb24,myfilter" -f null - But then I added actual encoding part to ffmpeg command, result fps is down to 16 fps (-4 fps, around 20%!!!): ffmpeg -i 720p.mp4 -filter_complex "format=rgb24,myfilter" -c:v h264 -y out.mp4 If I look at timeline of overla process in each cycle: |decoding time---| ---> |--filtering time-| ---> |---encoding time---| So, basically can I process frame in my custom filter without waiting for encoding to finish? In other word I want to process frames in my custom filter in parallel/queue to encoding process??? ___ 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". In concept yes, but you may be better off improving the speed of the underlying filter itself. Part of the cost of encoding is beyond the encoder itself, you have to account for file-system overhead, disk I/O speed etc. Depending on your implementation, you may be running into issues with memory copies from system to GPU memory and back, which is quite expensive. try testing using a "hardware decoder--> your filter-->hardware encoder" chain to keep everything in GPU memory. Beyond that, standard GPU acceleration rules apply. Make sure your wave fronts/work groups are aligned, check for system utilization, use non-blocking/async calls when possible, etc. -Felix (FCLC) ___ 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".
[FFmpeg-devel] How to use threads inside custom encoder
Hi! I write custom encoder codec and want to use threads to speed up encoding process. I know what ffmpeg have frame level threads and slices threads, but in my case best option is to use frame level threads with FF_CODEC_ENCODE_CB() function. But I have couple of questions: 1) Then I add AV_CODEC_CAP_FRAME_THREADS flag to capabilities of my encoder then ffmpeg call init function of my encoder for each spawned threads (for example 9 times because I have 8 core cpu ). How to prevent this and call init function only once? (I need to reuse encoder context.) 2) Is it possible to request more decoded frames inside encode callback function? ___ 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] avformat/mpegtsenc: Dont include adaptation field in teletext TS packets.
>From ETSI EN 300 472 V1.3.1 (2003-05) Specification for conveying ITU-R System
>B Teletext in DVB bitstreams:
4.1 Transport Stream (TS) packet format
The standard TS packet syntax and semantics are followed, noting the following
constraint:
- adaptation_field_control only the values "01" and "10" are permitted.
Some set top boxes (Motorola, Arris, Zyxel) refuse non-conforming packets.
Signed-off-by: Alex Shumsky
---
libavformat/mpegtsenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 184bb52f75..3d630e2500 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1564,7 +1564,8 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream
*st,
q = get_ts_payload_start(buf);
ts_st->discontinuity = 0;
}
-if (key && is_start && pts != AV_NOPTS_VALUE) {
+if (key && is_start && pts != AV_NOPTS_VALUE
+&& !is_dvb_teletext /* adaptation+payload forbidden for teletext
(ETSI EN 300 472 V1.3.1 4.1) */ ) {
// set Random Access for key frames
if (ts_st->pcr_period)
write_pcr = 1;
--
2.25.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] avformat/demux: preserve AV_PKT_FLAG_CORRUPT in parse_packet
If original packet is corrupted, then parsed packet is probably corrupted too. Let the application decide what to do. Signed-off-by: Alex Shumsky --- libavformat/demux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/demux.c b/libavformat/demux.c index 6a4b687bf1..71a1a9bf03 100644 --- a/libavformat/demux.c +++ b/libavformat/demux.c @@ -1179,7 +1179,7 @@ static int parse_packet(AVFormatContext *s, AVPacket *pkt, out_pkt->pts = sti->parser->pts; out_pkt->dts = sti->parser->dts; out_pkt->pos = sti->parser->pos; -out_pkt->flags |= pkt->flags & AV_PKT_FLAG_DISCARD; +out_pkt->flags |= pkt->flags & (AV_PKT_FLAG_DISCARD | AV_PKT_FLAG_CORRUPT); if (sti->need_parsing == AVSTREAM_PARSE_FULL_RAW) out_pkt->pos = sti->parser->frame_offset; -- 2.25.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".
Re: [FFmpeg-devel] [PATCH 1/1] libavformat/rtmp: Implements RTMP reconnect feature
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)
It seems like this approach is operating from the assumption that the
time to setup a new connection and process all RPCs necessary to send
media is on the order of normal jitter. Or am I misunderstanding?
For many services I don't really think that's the case.
And even with a very fast publish response we are looking at like 1.5
RTTs for TCP, another 1.5 for TLS, another 1.5 for RTMP handshake,
another 1 RTT for RTMP connect, an RTT on createStream, and an RTT on
publish. That's like 7.5 RTTs (or 300 ms at 40ms RTT) where we are
leaving the media flow on pause while we are re-building the connection.
This also seems to conflate rebootstrapping a media decode session vs
re-bootstrapping an RMTP session. The cost of doing this seems to be
sending your biggest frame after a pause to resolve a bunch of
synchronous RPCs on a relatively fresh TCP connection.
> ---
> libavformat/rtmppkt.c | 19 +++
> libavformat/rtmppkt.h | 10 ++
> libavformat/rtmpproto.c | 356 +---
> 3 files changed, 359 insertions(+), 26 deletions(-)
>
>[...]
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
> RTMP_PT_SHARED_OBJ, ///< shared object
> RTMP_PT_INVOKE, ///< invoke some stream action
> RTMP_PT_METADATA = 22, ///< FLV metadata
> +RTMP_PT_GO_AWAY = 32, ///< Indicates please reconnect ASAP, server
> is about to go down
> } RTMPPacketType;
>
I'm curious as to why this is a new top level message rather than just another
type 20 command message. Message types have a small address space while
commands have a large address space and a well chosen command name is unlikely
to conflict with (and therefore can be used in concert with) any other protocol
extensions.
> [snip]
On Sun, Sep 26, 2021 at 1:52 PM Jordi Cenzano wrote:
>
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)
> ---
> libavformat/rtmppkt.c | 19 +++
> libavformat/rtmppkt.h | 10 ++
> libavformat/rtmpproto.c | 356 +---
> 3 files changed, 359 insertions(+), 26 deletions(-)
>
> diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
> index 4b97c0833f..84ec72740d 100644
> --- a/libavformat/rtmppkt.c
> +++ b/libavformat/rtmppkt.c
> @@ -405,6 +405,25 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
> return written;
> }
>
> +int ff_rtmp_packet_clone(RTMPPacket *pkt_dst, const RTMPPacket *pkt_src)
> +{
> +if (pkt_src->size) {
> +pkt_dst->data = av_realloc(NULL, pkt_src->size);
> +if (!pkt_dst->data)
> +return AVERROR(ENOMEM);
> +else
> +memcpy(pkt_dst->data, pkt_src->data, pkt_src->size);
> +}
> +pkt_dst->size = pkt_src->size;
> +pkt_dst->channel_id = pkt_src->channel_id;
> +pkt_dst->type = pkt_src->type;
> +pkt_dst->timestamp = pkt_src->timestamp;
> +pkt_dst->extra = pkt_src->extra;
> +pkt_dst->ts_field = pkt_src->ts_field;
> +
> +return 0;
> +}
> +
> int ff_rtmp_packet_create(RTMPPacket *pkt, int channel_id, RTMPPacketType
> type,
>int timestamp, int size)
> {
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
> RTMP_PT_SHARED_OBJ, ///< shared object
> RTMP_PT_INVOKE, ///< invoke some stream action
> RTMP_PT_METADATA = 22, ///< FLV metadata
> +RTMP_PT_GO_AWAY = 32, ///< Indicates
[FFmpeg-devel] Flush muxer in av_interleaved_write_frame
Hi. Currently, there is no legitimate way to flush data buffered within the muxer for applications that choose to use av_interleaved_write_frame. Actually one could flush muxer buffers with av_write_frame, but docs forbid mixing av_interleaved_write_frame/av_write_frame within a single muxing context. Either docs should explicitly allow mixing av_write_frame(s, NULL) with av_interleaved_write_frame or av_interleaved_write_frame should flush not only interleaving queues but muxer too (I prefer the latter as it looks more expected, will send patch shortly) ___ 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] Flush muxer in av_interleaved_write_frame
Oh, there is a problem with return codes. av_interleaved_write_frame: * @return 0 on success, a negative AVERROR on error. av_write_frame: * @return < 0 on error, = 0 if OK, 1 if flushed and there is no more data to flush I could: - add "1" to the list of possible return codes of av_interleaved_write_frame (not sure whether it should be considered as API breaking change) - do not change the return codes list but lose "there is more data to flush" information (bad) - reconsider patch: do not change any code but allow av_interleaved_write_frame/av_write_frame(s, NULL) mixing in documentation. Any thoughts? On Fri, Oct 22, 2021 at 1:32 PM Alex ThreeD wrote: > Hi. > > Currently, there is no legitimate way to flush data buffered within the > muxer for applications that choose to use av_interleaved_write_frame. > Actually one could flush muxer buffers with av_write_frame, but docs > forbid mixing av_interleaved_write_frame/av_write_frame within a single > muxing context. > > Either docs should explicitly allow mixing av_write_frame(s, NULL) with > av_interleaved_write_frame or av_interleaved_write_frame should flush not > only interleaving queues but muxer too (I prefer the latter as it looks > more expected, will send patch shortly) > ___ 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] VP9 RTP encoder and WebRTC
Hello,
I'm trying to play some realtime video sources (web/IP cam) using WebRTC
in a browser. I'm sending RTP stream via Janus gateway using VP9 codec,
hardware transcoded using ffmpeg.
Everything works fine except random frame corruption happening around
moving objects, portions of frame "flowing off the screen" and such
until next keyframe fixes it. This happens consistently especially at
higher framerates.
It turns out the issue could be narrowed down to the VP9 RTP
packetizer. The problem is it's not marking P frames vs I frames in the
VP9 payload descriptor octet (the P bit). Gstreamer does that and
doesn't experience any such corruption issues.
I added this simple change and now WebRTC plays any stream 100% solid
and corruption free for me.
Could somebody implement this simple fix in the upstream. Basically
in libavformat/rtpenc_vp9.c add something to the effect of the following
two lines (to set the P bit for all but I frames):
/* mark the first fragment */
*rtp_ctx->buf_ptr++ = 0x08;
+ if (!keyframe) {
+ rtp_ctx->buf[0] |= 0x40;
Where the "keyframe" is an additional boolean parameter to the
ff_rtp_send_vp9 function which could be called as:
ff_rtp_send_vp9(s1, pkt->data, size, pkt->flags & AV_PKT_FLAG_KEY);
Thanks
Alex
___
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] VP9 RTP encoder and WebRTC
Jan,
Yes, that's the one, the latest draft I believe. The descriptor byte is
the bare minimum required for VP9, which could optionally be followed by
one or two byte serial picture ID (used by receiver to identify
problematic frames in its RTCP feedback to the sender), and some more
opaque scalability structure information (which could store frame
resolution among other things). The optional parts don't seem to affect
my use case (I added the gstreamer take on it at some point but didn't
see any changes for better or worth),
Thanks
Alex
On 6/1/19 2:14 PM, Jan Ekström wrote:
Hi,
On Sat, Jun 1, 2019 at 8:35 PM Alex Protasenko wrote:
Hello,
I'm trying to play some realtime video sources (web/IP cam) using WebRTC
in a browser. I'm sending RTP stream via Janus gateway using VP9 codec,
hardware transcoded using ffmpeg.
Everything works fine except random frame corruption happening around
moving objects, portions of frame "flowing off the screen" and such
until next keyframe fixes it. This happens consistently especially at
higher framerates.
It turns out the issue could be narrowed down to the VP9 RTP
packetizer. The problem is it's not marking P frames vs I frames in the
VP9 payload descriptor octet (the P bit). Gstreamer does that and
doesn't experience any such corruption issues.
I added this simple change and now WebRTC plays any stream 100% solid
and corruption free for me.
Could somebody implement this simple fix in the upstream. Basically
in libavformat/rtpenc_vp9.c add something to the effect of the following
two lines (to set the P bit for all but I frames):
/* mark the first fragment */
*rtp_ctx->buf_ptr++ = 0x08;
+if (!keyframe) {
+rtp_ctx->buf[0] |= 0x40;
Where the "keyframe" is an additional boolean parameter to the
ff_rtp_send_vp9 function which could be called as:
ff_rtp_send_vp9(s1, pkt->data, size, pkt->flags & AV_PKT_FLAG_KEY);
Is https://tools.ietf.org/html/draft-ietf-payload-vp9-06#page-7 the
correct specification for VP9 in RTP?
Best regards,
Jan
___
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] [PATCH] libavutil: AVEncodeInfo data structures
On Thu, Aug 15, 2019 at 11:07 AM Nicolas George wrote: > Juan De León (12019-08-15): > > Ping. Does anyone have any more feedback? > > If not, can anyone review this for pushing. > > Less than 24 hours feel a bit short to get impatient. > > Regards, > > -- > Nicolas George > ___ > 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". Time is important here. Juan's internship is ending soon. Juan has been working with Lynne on this design. Since there is back and forth emails in this thread, it would be very helpful for Juan if Nicolas and Lynne get to some agreement, rather than have intern trying to satisfy them while having different views. Juan needs clear guidance from ffmpeg community here. Please help. ___ 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] avformat: add H264 and HEVC support in IVF muxer
On Sun, Sep 30, 2018 at 2:09 PM Jan Ekström wrote:
> Sn Sun, Sep 30, 2018 at 8:56 PM wrote:
> >
> > ...
> > +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> > +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> > + (AV_RB24(pkt->data) != 0x01 ||
> > + (st->codecpar->extradata_size > 0 &&
> > + st->codecpar->extradata[0] == 1)))
> > +ret = ff_stream_add_bitstream_filter(st,
> "h264_mp4toannexb", NULL);
> > +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> > +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> > + (AV_RB24(pkt->data) != 0x01 ||
> > + (st->codecpar->extradata_size > 0 &&
> > + st->codecpar->extradata[0] == 1)))
> > +ret = ff_stream_add_bitstream_filter(st,
> "hevc_mp4toannexb", NULL);
>
> Please verify that there is no AVCc/Annex B deciding helper function
> within lavf/lavc that could be used here. I tried to ask about this on
> IRC but didn't get responses so I can't straight up note you a
> function name. If there's none, then it might be worth making a lavf
> helper for that since I think at least movenc/matroskaenc try to
> figure out if the input bit stream is Annex B and convert it the other
> way.
>
> Additionally, please make sure that the files created with these
> changes can be demuxed with the FFmpeg IVF demuxer (ivfdec.c). I would
> guess the H.264 stuff would work, but since the IVF demuxer utilizes
> the ff_codec_bmp_tags list, which doesn't seem to contain HEVC entries
> I would guess additional stuff would be required there.
>
>
Verified that demuxer can handle the files by running ffplay.
Thank you.
> That of course doesn't have to be within this patch, but just within
> this patch set (one patch for demuxer, one for muxer).
>
> Best regards,
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Mon, Oct 1, 2018 at 11:01 AM wrote:
> From: Alex Sukhanov
>
> ---
> libavformat/ivfenc.c | 50 +---
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 66441a2a43..6410828533 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
> return AVERROR(EINVAL);
> }
> par = s->streams[0]->codecpar;
> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> -!(par->codec_id == AV_CODEC_ID_AV1 ||
> - par->codec_id == AV_CODEC_ID_VP8 ||
> - par->codec_id == AV_CODEC_ID_VP9)) {
> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> supported!\n");
> -return AVERROR(EINVAL);
> -}
> avio_write(pb, "DKIF", 4);
> avio_wl16(pb, 0); // version
> avio_wl16(pb, 32); // header length
> -avio_wl32(pb,
> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> AV_RL32("AV01"));
> +switch (par->codec_id) {
> + case AV_CODEC_ID_AV1:
> +avio_wl32(pb, AV_RL32("AV01"));
> +break;
> + case AV_CODEC_ID_H264:
> +avio_wl32(pb, AV_RL32("H264"));
> +break;
> + case AV_CODEC_ID_HEVC:
> +avio_wl32(pb, AV_RL32("HEVC"));
> +break;
> + case AV_CODEC_ID_VP8:
> +avio_wl32(pb, AV_RL32("VP80"));
> +break;
> + case AV_CODEC_ID_VP9:
> +avio_wl32(pb, AV_RL32("VP90"));
> +break;
> + default:
> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8 and
> VP9 and AV1 are supported!\n");
> +return AVERROR(EINVAL);
> +}
> avio_wl16(pb, par->width);
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> @@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct AVFormatContext
> *s, const AVPacket *pkt)
> int ret = 1;
> AVStream *st = s->streams[pkt->stream_index];
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> + (AV_RB24(pkt->data) != 0x01 ||
> + (st->codecpar->extradata_size > 0 &&
> + st->codecpar->extradata[0] == 1)))
> +ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb",
> NULL);
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
> +}
>
> return ret;
> }
>
> static const AVCodecTag codec_ivf_tags[] = {
> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> { AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
> -{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> +
> { AV_CODEC_ID_NONE, 0 }
> };
>
> --
> 2.19.0.605.g01d371f741-goog
>
>
Can you please take a look on this patch?
Thank you
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sat, Oct 6, 2018 at 10:37 AM Mark Thompson wrote:
> On 05/10/18 21:45, Alex Sukhanov wrote:
> > On Mon, Oct 1, 2018 at 11:01 AM wrote:
> >
> >> From: Alex Sukhanov
> >>
> >> ---
> >> libavformat/ivfenc.c | 50 +---
> >> 1 file changed, 38 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> >> index 66441a2a43..6410828533 100644
> >> --- a/libavformat/ivfenc.c
> >> +++ b/libavformat/ivfenc.c
> >> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
> >> return AVERROR(EINVAL);
> >> }
> >> par = s->streams[0]->codecpar;
> >> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> >> -!(par->codec_id == AV_CODEC_ID_AV1 ||
> >> - par->codec_id == AV_CODEC_ID_VP8 ||
> >> - par->codec_id == AV_CODEC_ID_VP9)) {
> >> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> >> supported!\n");
> >> -return AVERROR(EINVAL);
> >> -}
> >> avio_write(pb, "DKIF", 4);
> >> avio_wl16(pb, 0); // version
> >> avio_wl16(pb, 32); // header length
> >> -avio_wl32(pb,
> >> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> >> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> >> AV_RL32("AV01"));
> >> +switch (par->codec_id) {
> >> + case AV_CODEC_ID_AV1:
> >> +avio_wl32(pb, AV_RL32("AV01"));
> >> +break;
> >> + case AV_CODEC_ID_H264:
> >> +avio_wl32(pb, AV_RL32("H264"));
> >> +break;
> >> + case AV_CODEC_ID_HEVC:
> >> +avio_wl32(pb, AV_RL32("HEVC"));
> >> +break;
> >> + case AV_CODEC_ID_VP8:
> >> +avio_wl32(pb, AV_RL32("VP80"));
> >> +break;
> >> + case AV_CODEC_ID_VP9:
> >> +avio_wl32(pb, AV_RL32("VP90"));
> >> +break;
> >> + default:
> >> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8
> and
> >> VP9 and AV1 are supported!\n");
> >> +return AVERROR(EINVAL);
> >> +}
> >> avio_wl16(pb, par->width);
> >> avio_wl16(pb, par->height);
> >> avio_wl32(pb, s->streams[0]->time_base.den);
> >> @@ -95,16 +105,32 @@ static int ivf_check_bitstream(struct
> AVFormatContext
> >> *s, const AVPacket *pkt)
> >> int ret = 1;
> >> AVStream *st = s->streams[pkt->stream_index];
> >>
> >> -if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "h264_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "hevc_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> >> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe",
> NULL);
> >> +}
> >>
> >> return ret;
> >> }
> >>
> >> static const AVCodecTag codec_ivf_tags[] = {
> >> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> >> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
> >> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> >> { AV_
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 2:47 PM Derek Buitenhuis wrote: > On 11/10/2018 22:21, Jan Ekström wrote: > > I'd probably disable creation of such files unless you enable a less > > standards-compliant strictness mode. > > Is there even an IVF spec, though? If not, there's not really such a > thing as "standards-compliant". > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel The only "spec" I'm aware of: https://wiki.multimedia.cx/index.php/IVF ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Mon, Oct 15, 2018 at 9:35 AM Vittorio Giovara wrote: > On Thu, Oct 11, 2018 at 5:28 PM Jan Ekström wrote: > > > On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov > > wrote: > > > > > > Hi Mark, > > > > > > at Google we have some old service which is still running and it works > > only > > > with the IVF container. It would be great if ffmpeg could generate such > > > videos so we could give them to the service then. Given that ffmpeg IVF > > > demuxer already supports reading such files, I think it's reasonable to > > > make IVF muxer be able to generate them. > > > Hope it answers the question. > > > > > > Thank you > > > > Given the amount of code is not large I'm not against having it in, > > but if it's not something that ever was meant to go into the public > > I'd probably disable creation of such files unless you enable a less > > standards-compliant strictness mode. > > > > maybe creation of such files could be allowed only with a strict compliance > flag? > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Vittorio, can you please elaborate your proposal? Is there already a flag in ffmpeg that we can consider use for that? What would be a benefit of guarding h264/hevc muxing into the IVF container by the flag? Thank you ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/aacdec: Translate PCE to avutil channel layouts
> From a12637c97c3140a1676f20b19c91647313379b39 Mon Sep 17 00:00:00 2001
> From: pkviet
> Date: Sun, 9 Sep 2018 16:47:32 +0200
> Subject: [PATCH 3/3] avcodec/aacdec: Translate pce to avutil channel_layout
>
> This commit enables the native aac decoder to translate pce to
> ffmpeg channel layouts without any user input.
> For all pce generated by the native aac encoder a table is used.
> For more general pce (up to 20 channels) a custom layout is built.
> Fixes trac issue 7273 with patch 1 of the series.
>
> Signed-off-by: pkviet
> ---
> libavcodec/aacdec_template.c | 195
> +--
> libavcodec/aacdectab.h | 43 ++
> 2 files changed, 233 insertions(+), 5 deletions(-)
>
Thanks for the patch. Overall I like this approach, but this patch has some
must-fix issues. In general make sure make fate-aac works with address
sanitizer.
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index b60b31a92c..53b7ea6669 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -155,6 +155,26 @@ static av_cold int che_configure(AACContext *ac,
> return 0;
> }
>
> +static uint8_t* pce_reorder_map(uint64_t layout)
> +{
> +uint8_t map[8] = {0, 1, 2, 3, 4, 5, 6, 7};
> +uint8_t map8[8] = { 2, 0, 1, 6, 7, 4, 5, 3 };
> +uint8_t map7[7] = { 2, 0, 1, 4, 5, 6, 3 };
> +uint8_t map6[6] = { 2, 0, 1, 4, 5, 3 };
> +uint8_t map5[5] = { 2, 0, 1, 4, 3 };
> +if (layout == AV_CH_LAYOUT_7POINT1 || layout ==
> AV_CH_LAYOUT_7POINT1_WIDE ||
> +layout == AV_CH_LAYOUT_7POINT1_WIDE_BACK)
> +return map8;
> +if (layout == AV_CH_LAYOUT_6POINT1 || layout ==
> AV_CH_LAYOUT_6POINT1_BACK ||
> +layout == AV_CH_LAYOUT_6POINT1_FRONT)
> +return map7;
> +if (layout == AV_CH_LAYOUT_5POINT1 || layout ==
> AV_CH_LAYOUT_5POINT1_BACK)
> +return map6;
> +if (layout == AV_CH_LAYOUT_4POINT1)
> + return map5;
> +return map;
You can't return local stack arrays like this. Return pointers to const arrays
that live outside the function. Consider building with -Wreturn-stack-address.
> +}
> +
> static int frame_configure_elements(AVCodecContext *avctx)
> {
> AACContext *ac = avctx->priv_data;
> @@ -180,10 +200,15 @@ static int frame_configure_elements(AVCodecContext
> *avctx)
> if ((ret = ff_get_buffer(avctx, ac->frame, 0)) < 0)
> return ret;
>
> +/* reorder channels in case pce table was used with LFE channel */
> +uint8_t reorder[8] = { 0 };
> +if (ac->oc[1].m4ac.chan_config == 0 && ac->oc[1].channel_layout &&
> avctx->channels < 9)
Can we ever hit this if with channel_layout == 0? If we can it seems
like all zero output is not what we want.
If we can't then what are we checking it for?
> +memcpy(reorder, pce_reorder_map(ac->oc[1].channel_layout),
> avctx->channels * sizeof(uint8_t));
> /* map output channel pointers to AVFrame data */
> for (ch = 0; ch < avctx->channels; ch++) {
> +int ch_remapped = avctx->channels < 9 ? reorder[ch] : ch;
> if (ac->output_element[ch])
> -ac->output_element[ch]->ret = (INTFLOAT
> *)ac->frame->extended_data[ch];
> +ac->output_element[ch]->ret = (INTFLOAT
> *)ac->frame->extended_data[ch_remapped];
> }
>
> return 0;
[...]
> +static uint64_t convert_layout_map_to_av_layout(uint8_t
> layout_map[MAX_ELEM_ID * 4][3])
> +{
> +int i, config;
> +config = 0;
> +// look up pce table for channel layout correspondance used by native
> encoder and decoder
nit: "correspondence"
> +for (i = 1; i < PCE_LAYOUT_NBR; i++) {
> +if (memcmp(layout_map, pce_channel_layout_map[i], sizeof(uint8_t) *
> 3 * PCE_MAX_TAG) == 0) {
nit: use variables with sizeof. e.g. PCE_MAX_TAG * sizeof(layout_map[0])
> +config = i;
> +break;
> +}
> +}
> +
> +switch(config) {
nit: this should probably live as a table with: pce_channel_layout_map
> +case 1: return AV_CH_LAYOUT_HEXADECAGONAL;
> +case 2: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> + AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> + AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_CENTER |
> + AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT;
> +case 3: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> + AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> + AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_LEFT |
> + AV_CH_TOP_BACK_RIGHT;
> +case 4: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> + AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> + AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_CENTER;
> +case 5: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> + AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> + AV_CH_TOP_FRONT_CENTER;
> +case 6: return AV_CH_L
Re: [FFmpeg-devel] [PATCH v3 3/3] avcodec/aacdec: Translate PCE to avutil channel layouts
On Wed, Oct 24, 2018 at 1:03 PM pkv.stream wrote: > > Patch updated ; passes all FATE tests. > > Comments from Alex Converse review incorporated (much thanks to him). > Hey, I'm a bit concerned with the outputs this generates for low channel count streams. al17_44.mp4 has two front SCEs. "ISO/IEC 13818-7:2005(E), 8.5.3.2 Explicit channel mapping using a program_config_element" says: Included in the PCE are “list of front channels”, using the rule center outwards, left before right. In this list, a center channel SCE, if any, must come first, and any other SCE’s must appear in pairs, constituting an LR pair. If only two SCE’s are specified, this signifies one LR stereophonic pair. Before the patch we were getting L+R. With the patch we are getting (FC+TFC) (0x2004). I know of at least one commercial encoder that supports unpaired dual mono. Do you know which spec the contains the eratta for top channels? There doesn't seem to be much of value in Amd.6. Do you have any real examples of a multichannel stream with a top center speaker or any supporting documentation you could point me at? Thanks, Alex ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sat, Oct 13, 2018 at 5:17 PM Michael Niedermayer wrote: > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > > > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Michael, can you please apply this patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mjpegbdec: Fix yuv444 pix_fmt detection
by default adobe_transform set to 0 and because of that mjpegb decoder detects yuv444 pix fmt as bgrp --- libavcodec/mjpegbdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mjpegbdec.c b/libavcodec/mjpegbdec.c index 37d7bb8228..70ff4cf563 100644 --- a/libavcodec/mjpegbdec.c +++ b/libavcodec/mjpegbdec.c @@ -56,6 +56,7 @@ static int mjpegb_decode_frame(AVCodecContext *avctx, buf_ptr = buf; buf_end = buf + buf_size; s->got_picture = 0; +s->adobe_transform = -1; read_header: /* reset on every SOI */ -- 2.20.1 (Apple Git-117) ___ 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] avcodec/mjpegbdec: Fix yuv444 pix_fmt detection
On Wed, Nov 20, 2019 at 2:57 PM Carl Eugen Hoyos wrote: > > > > Am 20.11.2019 um 12:22 schrieb Alex Mogurenko : > > > > by default adobe_transform set to 0 and because of that mjpegb decoder > detects yuv444 pix fmt as bgrp > > Please provide a sample that gets fixed by this patch. > > Where is preferable to upload it? -- Kind Regards, Alex ___ 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] avcodec/mjpegbdec: Fix yuv444 pix_fmt detection
On Wed, Nov 20, 2019 at 3:57 PM Carl Eugen Hoyos wrote: > > Am 20.11.2019 um 14:41 schrieb Alex Mogurenko : > > > >> On Wed, Nov 20, 2019 at 2:57 PM Carl Eugen Hoyos > wrote: > >> > >> > >> > >>> Am 20.11.2019 um 12:22 schrieb Alex Mogurenko : > >>> > >>> by default adobe_transform set to 0 and because of that mjpegb decoder > >> detects yuv444 pix fmt as bgrp > >> > >> Please provide a sample that gets fixed by this patch. > >> > >> > > Where is preferable to upload it? > > Any file hoster that does not require registration. > https://send.firefox.com/download/12d9f70cb957832d/#JAWkB77yZQ0OxM8x95fOvg -- Kind Regards, Alex ___ 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] avformat/av_get_frame_filename2: Add timecode image extract option
From: Marcus Johansson
Added the option to extract images with timecode as token
The '%t' parameter is now supported for for images sequences just like the '%d'
param
When using '%t', images will have HH.MM.SS.XXX appended.
Minor changes were made to the code by Marcus Johansson.
See https://trac.ffmpeg.org/ticket/1452 for more details
Signed-off-by: Alex Mi
---
doc/muxers.texi| 3 +++
libavformat/avformat.h | 3 ++-
libavformat/img2enc.c | 8 +---
libavformat/utils.c| 31 +++
4 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index e77055e7ef..91997bd4fa 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1384,6 +1384,9 @@ If the pattern contains "%d" or "%0@var{N}d", the first
filename of
the file list specified will contain the number 1, all the following
numbers will be sequential.
+The pattern can also contain "%t" which writes out the timestamp of the
+frame in the format "HH.mm.ss.fff"
+
The pattern may contain a suffix which is used to automatically
determine the format of the image files to write.
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index cd7b0d941c..513de9e477 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2602,10 +2602,11 @@ void av_dump_format(AVFormatContext *ic,
* @param path numbered sequence string
* @param number frame number
* @param flags AV_FRAME_FILENAME_FLAGS_*
+ * @param ts frame timestamp in seconds
* @return 0 if OK, -1 on format error
*/
int av_get_frame_filename2(char *buf, int buf_size,
- const char *path, int number, int flags);
+ const char *path, int number, int flags, int64_t ts);
int av_get_frame_filename(char *buf, int buf_size,
const char *path, int number);
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 7b5133d300..55dca272ea 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -131,9 +131,11 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
AVIOContext *pb[4] = {0};
char filename[1024];
AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
+AVStream *stream = s->streams[ pkt->stream_index ];
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(par->format);
int ret, i;
int nb_renames = 0;
+int64_t ts = av_rescale_q(pkt->pts, stream->time_base, AV_TIME_BASE_Q);
AVDictionary *options = NULL;
if (img->update) {
@@ -148,13 +150,13 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
return AVERROR(EINVAL);
}
} else if (img->frame_pts) {
-if (av_get_frame_filename2(filename, sizeof(filename), img->path,
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
+if (av_get_frame_filename2(filename, sizeof(filename), img->path,
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE, 0) < 0) {
av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the
frames.");
return AVERROR(EINVAL);
}
} else if (av_get_frame_filename2(filename, sizeof(filename), img->path,
- img->img_number,
- AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0 &&
+ img->img_number, 0,
+ ts) < 0 &&
img->img_number > 1) {
av_log(s, AV_LOG_ERROR,
"Could not get frame filename number %d from pattern '%s'. "
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 0df14682a4..d2e7cb7d34 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4589,15 +4589,17 @@ uint64_t ff_parse_ntp_time(uint64_t ntp_ts)
return (sec * 100) + usec;
}
-int av_get_frame_filename2(char *buf, int buf_size, const char *path, int
number, int flags)
+int av_get_frame_filename2(char *buf, int buf_size, const char *path, int
number, int flags, int64_t ts)
{
const char *p;
char *q, buf1[20], c;
-int nd, len, percentd_found;
+int nd, len, percentd_found, percentt_found;
+int hours, mins, secs, ms;
q = buf;
p = path;
percentd_found = 0;
+percentt_found = 0;
for (;;) {
c = *p++;
if (c == '\0')
@@ -4629,6 +4631,27 @@ int av_get_frame_filename2(char *buf, int buf_size,
const char *path, int number
memcpy(q, buf1, len);
q += len;
break;
+case 't':
+if (percentd_found)
+ goto fail;
+if (ts < 0)
+ goto fail;
+percentt_found = 1;
+ms = (ts/1000)%1000;
+ts /
[FFmpeg-devel] [PATCH] fixed luma quantizing when q >= MAX_STORED_Q
---
libavcodec/proresenc_kostya.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 9a77d24fb6..e045a972f1 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -222,6 +222,7 @@ typedef struct ProresThreadData {
DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16 * 16];
int16_t custom_q[64];
+int16_t custom_chroma_q[64];
struct TrellisNode *nodes;
} ProresThreadData;
@@ -232,6 +233,7 @@ typedef struct ProresContext {
int16_t quants[MAX_STORED_Q][64];
int16_t quants_chroma[MAX_STORED_Q][64];
int16_t custom_q[64];
+int16_t custom_chroma_q[64];
const uint8_t *quant_mat;
const uint8_t *quant_chroma_mat;
const uint8_t *scantable;
@@ -574,7 +576,7 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
qmat_chroma = ctx->quants_chroma[quant];
} else {
qmat = ctx->custom_q;
-qmat_chroma = ctx->custom_q;
+qmat_chroma = ctx->custom_chroma_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * quant;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
@@ -902,7 +904,7 @@ static int find_slice_quant(AVCodecContext *avctx,
qmat_chroma = ctx->quants_chroma[q];
} else {
qmat = td->custom_q;
-qmat_chroma = td->custom_q;
+qmat_chroma = td->custom_chroma_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * q;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * q;
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fixed luma quantizing when q >= MAX_STORED_Q
problem occurs in slice quant estimation and slice encoding.
if slice quant >= MAX_STORED_Q we dont use pre-calculated quant matrices
but generate new:
qmat = ctx->custom_q;
qmat_chroma = ctx->custom_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * quant;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
}
as you see both qmat and qmat_chroma both point to same ctx -> custom_q
as result they will contain chroma qunatizers as
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
last in loop, after all we pass qmat/qmat_chroma to function where we
estimate encoded slice size or encode slice:
estimate_slice_plane / encode_slice_plane
I will make new patch with detailed description
пт, 28 дек. 2018 г. в 18:43, Derek Buitenhuis :
> On 27/12/2018 19:28, Alex Mogurenko wrote:
> > ---
> > libavcodec/proresenc_kostya.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Can you give a little more detail about what's changed and why,
> in the commit message?
>
> It looks like custom_chroma_q is zero initialized and never set to
> anything?
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/prores_ks: fixed luma quantize if q >= MAX_STORED_Q
problem occurs in slice quant estimation and slice encoding.
if slice quant >= MAX_STORED_Q we dont use pre-calculated quant matrices but
generate new:
qmat = ctx->custom_q;
qmat_chroma = ctx->custom_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * quant;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
}
as you see qmat and qmat_chroma both point to same ctx->custom_q
result it will contain chroma qunatizers as
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
last in the loop, after all we pass qmat/qmat_chroma to function where we
estimate encoded slice size or encode slice:
estimate_slice_plane / encode_slice_plane
custom_chroma_q was added same way as custom_q e.g to encoder context I would
prefer to have it on stack thought
---
libavcodec/proresenc_kostya.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 9a77d24fb6..e045a972f1 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -222,6 +222,7 @@ typedef struct ProresThreadData {
DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16 * 16];
int16_t custom_q[64];
+int16_t custom_chroma_q[64];
struct TrellisNode *nodes;
} ProresThreadData;
@@ -232,6 +233,7 @@ typedef struct ProresContext {
int16_t quants[MAX_STORED_Q][64];
int16_t quants_chroma[MAX_STORED_Q][64];
int16_t custom_q[64];
+int16_t custom_chroma_q[64];
const uint8_t *quant_mat;
const uint8_t *quant_chroma_mat;
const uint8_t *scantable;
@@ -574,7 +576,7 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
qmat_chroma = ctx->quants_chroma[quant];
} else {
qmat = ctx->custom_q;
-qmat_chroma = ctx->custom_q;
+qmat_chroma = ctx->custom_chroma_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * quant;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * quant;
@@ -902,7 +904,7 @@ static int find_slice_quant(AVCodecContext *avctx,
qmat_chroma = ctx->quants_chroma[q];
} else {
qmat = td->custom_q;
-qmat_chroma = td->custom_q;
+qmat_chroma = td->custom_chroma_q;
for (i = 0; i < 64; i++) {
qmat[i] = ctx->quant_mat[i] * q;
qmat_chroma[i] = ctx->quant_chroma_mat[i] * q;
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
fdct done twice for each block. first time during quant calculation, second
during slice encoding. so if we pre-save dct coefficients no need to do fdct
second time.
disadvantages: requires more memory
advantages: improves performance ~4-5%
---
libavcodec/proresenc_kostya.c | 74 ---
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index e045a972f1..4d49d6521a 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -219,7 +219,6 @@ struct TrellisNode {
#define MAX_STORED_Q 16
typedef struct ProresThreadData {
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16 * 16];
int16_t custom_q[64];
int16_t custom_chroma_q[64];
@@ -228,7 +227,6 @@ typedef struct ProresThreadData {
typedef struct ProresContext {
AVClass *class;
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16*16];
int16_t quants[MAX_STORED_Q][64];
int16_t quants_chroma[MAX_STORED_Q][64];
@@ -237,6 +235,7 @@ typedef struct ProresContext {
const uint8_t *quant_mat;
const uint8_t *quant_chroma_mat;
const uint8_t *scantable;
+int16_t *blocks[MAX_PLANES];
void (*fdct)(FDCTDSPContext *fdsp, const uint16_t *src,
ptrdiff_t linesize, int16_t *block);
@@ -562,6 +561,8 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
int plane_factor, is_chroma;
uint16_t *qmat;
uint16_t *qmat_chroma;
+int16_t *blocks;
+DECLARE_ALIGNED(16, int16_t, dct_blocks)[16 * 16 * MAX_MBS_PER_SLICE];
if (ctx->pictures_per_frame == 1)
line_add = 0;
@@ -604,28 +605,38 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
src = (const uint16_t*)(pic->data[i] + yp * linesize +
line_add * pic->linesize[i]) + xp;
+if (!ctx->force_quant) {
+blocks = ctx->blocks[i] + (y * ctx->slices_width + x /
ctx->mbs_per_slice) * 16 * 16 * ctx->mbs_per_slice;
+} else {
+blocks = dct_blocks;
+}
+
if (i < 3) {
-get_slice_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], ctx->emu_buf,
- mbs_per_slice, num_cblocks, is_chroma);
+if (ctx->force_quant) {
+get_slice_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, ctx->emu_buf,
+ mbs_per_slice, num_cblocks, is_chroma);
+}
if (!is_chroma) {/* luma quant */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat);
} else { /* chroma plane */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat_chroma);
}
} else {
-get_alpha_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], mbs_per_slice, ctx->alpha_bits);
+if (ctx->force_quant) {
+get_alpha_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, mbs_per_slice, ctx->alpha_bits);
+}
sizes[i] = encode_alpha_plane(ctx, pb, mbs_per_slice,
- ctx->blocks[0], quant);
+ blocks, quant);
}
total_size += sizes[i];
if (put_bits_left(pb) < 0) {
@@ -730,15 +741,15 @@ static int estimate_slice_plane(ProresContext *ctx, int
*error, int plane,
const uint16_t *src, ptrdiff_t linesize,
int mbs_per_slice,
int blocks_per_mb, int plane_size_factor,
-const int16_t *qmat, ProresThreadData *td)
+const int16_t *qmat, int16_t *blocks)
{
int blocks_per_slice;
int bits;
blocks_per_slice = mbs_per_slice * blocks_per_mb;
-bits
Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
I seems to be lame as failed to find how to run fate to check prores_ks :( On Mon, Dec 31, 2018 at 4:46 AM Michael Niedermayer wrote: > On Sun, Dec 30, 2018 at 10:57:23PM +0200, Alex Mogurenko wrote: > > fdct done twice for each block. first time during quant calculation, > second during slice encoding. so if we pre-save dct coefficients no need to > do fdct second time. > > disadvantages: requires more memory > > advantages: improves performance ~4-5% > > --- > > libavcodec/proresenc_kostya.c | 74 --- > > 1 file changed, 52 insertions(+), 22 deletions(-) > > breaks fate > > TESTvsynth1-prores_ks > --- ./tests/ref/vsynth/vsynth1-prores_ks2018-12-28 > 17:54:41.361383177 +0100 > +++ tests/data/fate/vsynth1-prores_ks 2018-12-31 03:45:17.207673799 +0100 > @@ -1,4 +1,4 @@ > -fe41a284da97ea5ec8866ca9a55b84da *tests/data/fate/vsynth1-prores_ks.mov > -3858911 tests/data/fate/vsynth1-prores_ks.mov > -100eb002413fe7a632d440dfbdf7e3ff > *tests/data/fate/vsynth1-prores_ks.out.rawvideo > -stddev:3.17 PSNR: 38.09 MAXDIFF: 39 bytes: 7603200/ 7603200 > +ba6294d95b96f032b90f804f112ab98a *tests/data/fate/vsynth1-prores_ks.mov > +3867422 tests/data/fate/vsynth1-prores_ks.mov > +e85510eadb1ff115e85c480d8e1011a4 > *tests/data/fate/vsynth1-prores_ks.out.rawvideo > +stddev: 19.38 PSNR: 22.38 MAXDIFF: 210 bytes: 7603200/ 7603200 > Test vsynth1-prores_ks failed. Look at > tests/data/fate/vsynth1-prores_ks.err for details. > make: *** [fate-vsynth1-prores_ks] Error 1 > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
fdct done twice for each block. first time during quant calculation, second
during slice encoding. so if we pre-save dct coefficients no need to do fdct
second time.
disadvantages: requires more memory
advantages: improves performance ~4-5%
---
libavcodec/proresenc_kostya.c | 74 ---
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index e045a972f1..d2f81e73f4 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -219,7 +219,6 @@ struct TrellisNode {
#define MAX_STORED_Q 16
typedef struct ProresThreadData {
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16 * 16];
int16_t custom_q[64];
int16_t custom_chroma_q[64];
@@ -228,7 +227,6 @@ typedef struct ProresThreadData {
typedef struct ProresContext {
AVClass *class;
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16*16];
int16_t quants[MAX_STORED_Q][64];
int16_t quants_chroma[MAX_STORED_Q][64];
@@ -237,6 +235,7 @@ typedef struct ProresContext {
const uint8_t *quant_mat;
const uint8_t *quant_chroma_mat;
const uint8_t *scantable;
+int16_t *blocks[MAX_PLANES];
void (*fdct)(FDCTDSPContext *fdsp, const uint16_t *src,
ptrdiff_t linesize, int16_t *block);
@@ -562,6 +561,8 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
int plane_factor, is_chroma;
uint16_t *qmat;
uint16_t *qmat_chroma;
+int16_t *blocks;
+DECLARE_ALIGNED(16, int16_t, dct_blocks)[16 * 16 * MAX_MBS_PER_SLICE];
if (ctx->pictures_per_frame == 1)
line_add = 0;
@@ -604,28 +605,38 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
src = (const uint16_t*)(pic->data[i] + yp * linesize +
line_add * pic->linesize[i]) + xp;
+if (!ctx->force_quant) {
+blocks = ctx->blocks[i] + (y * ctx->slices_width *
ctx->mbs_per_slice + x) * 16 * 16;
+} else {
+blocks = dct_blocks;
+}
+
if (i < 3) {
-get_slice_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], ctx->emu_buf,
- mbs_per_slice, num_cblocks, is_chroma);
+if (ctx->force_quant) {
+get_slice_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, ctx->emu_buf,
+ mbs_per_slice, num_cblocks, is_chroma);
+}
if (!is_chroma) {/* luma quant */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat);
} else { /* chroma plane */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat_chroma);
}
} else {
-get_alpha_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], mbs_per_slice, ctx->alpha_bits);
+if (ctx->force_quant) {
+get_alpha_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, mbs_per_slice, ctx->alpha_bits);
+}
sizes[i] = encode_alpha_plane(ctx, pb, mbs_per_slice,
- ctx->blocks[0], quant);
+ blocks, quant);
}
total_size += sizes[i];
if (put_bits_left(pb) < 0) {
@@ -730,15 +741,15 @@ static int estimate_slice_plane(ProresContext *ctx, int
*error, int plane,
const uint16_t *src, ptrdiff_t linesize,
int mbs_per_slice,
int blocks_per_mb, int plane_size_factor,
-const int16_t *qmat, ProresThreadData *td)
+const int16_t *qmat, int16_t *blocks)
{
int blocks_per_slice;
int bits;
blocks_per_slice = mbs_per_slice * blocks_per_mb;
-bits = estimate_dcs(error
Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
thanks, just sent new patch On Mon, Dec 31, 2018 at 5:56 PM Derek Buitenhuis wrote: > On 31/12/2018 09:12, Alex Mogurenko wrote: > > I seems to be lame as failed to find how to run fate to check prores_ks > :( > > General way to run all of FATE: > > $ configure --samples=/home/path/for/samples/ --enable-gpl [...] > $ make fate-rsync > $ make fate > > There are sub-targets, too, as listed in Michaels mail, like fate-vsynth1. > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
ping On Mon, Dec 31, 2018 at 11:02 PM Alex Mogurenko wrote: > thanks, > just sent new patch > > On Mon, Dec 31, 2018 at 5:56 PM Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > >> On 31/12/2018 09:12, Alex Mogurenko wrote: >> > I seems to be lame as failed to find how to run fate to check prores_ks >> :( >> >> General way to run all of FATE: >> >> $ configure --samples=/home/path/for/samples/ --enable-gpl [...] >> $ make fate-rsync >> $ make fate >> >> There are sub-targets, too, as listed in Michaels mail, like fate-vsynth1. >> >> - Derek >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacsbr: Turnoff in the event of over read.
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
---
libavcodec/aacsbr_template.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index cf8621eee0..750131c64c 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -1137,6 +1137,7 @@ int AAC_RENAME(ff_decode_sbr_extension)(AACContext *ac,
SpectralBandReplication
if (bytes_read > cnt) {
av_log(ac->avctx, AV_LOG_ERROR,
"Expected to read %d SBR bytes actually read %d.\n", cnt,
bytes_read);
+sbr_turnoff(sbr);
}
return cnt;
}
--
2.11.0.390.gc69c2f50cf-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for CUDA Scale Filter
On Mon, Apr 17, 2017 at 2:51 PM, Timo Rothenpieler wrote: >>> I'm generally in favor of adding CUDA based filtering, there's a lot of >>> nice stuff that could be done that way. >>> >>> But there is one big issue with this approach: >>> >>> Having to run a .bat file prior to building isn't really nice, and not >>> something I and some other people on IRC would like to see in ffmpeg. >>> >>> Instead, it would be nice if configure/make would learn how to handle >>> .cu files, converting them straight to an object-file. >>> My idea for this would be to teach the Makefiles about .cu files, and >>> using a shell script as their compiler. >>> That script can then call nvcc and include the ptx2c functionality, and >>> additionally also calls the designated C compiler, so for the build >>> system it converts .cu to .o. >>> >>> Also, due to these kind of filters having to include cuda.h, they need >>> to be put behind --enable-nonfree in configure. >>> >>> That's what I have in mind so far. I didn't have time for a full review >>> of the code yet, so can't say much about the filter itself. >> >> >> I'm against. Building the "script" seems pretty terribly complicated, >> and adding generated code is usually not what we do in this project. >> This is probably done better with a d3d11 video scale filter, although >> I'm not sure about the tradeoffs yet. > > > That's exactly what I said though? Making configure/make generate the code > at build time, so the generated code is not in the repo, only the actual .cu > file. > > One problem with that is, that nvcc require cl.exe on Windows, it doesn't > work with gcc. So that would limit it to MSVC builds on Windows, which is > fine with me. > FWIW there are non-nvcc cuda compilers that run on Windows, like clang. http://llvm.org/docs/CompileCudaWithLLVM.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/flvdec: Set need_context_update when setting the initial extradata
On Wed, Aug 30, 2017 at 5:09 PM, Michael Niedermayer wrote: > On Tue, Aug 29, 2017 at 11:40:06AM -0700, Alex Converse wrote: >> Fixes ticket 6398. >> >> Debugged with the help of James Almer and Hendrik Leppkes. >> --- >> libavformat/flvdec.c | 1 + >> 1 file changed, 1 insertion(+) > > should be ok > > thx > Pushed. Any thoughts on patch 2/2? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level
Report the actual level of the encoded output if a level is
targeted or the level is passively tracked with a target of 0.
---
libavcodec/libvpxenc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 51f423a..a2fb82e 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -137,6 +137,7 @@ static const char *const ctlidstr[] = {
#endif
#if VPX_ENCODER_ABI_VERSION >= 12
[VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+[VP9E_GET_LEVEL] = "VP9E_GET_LEVEL",
#endif
#endif
};
@@ -264,9 +265,39 @@ static av_cold int codecctl_int(AVCodecContext *avctx,
return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
}
+#if VPX_ENCODER_ABI_VERSION >= 12
+static av_cold int codecctl_intp(AVCodecContext *avctx,
+ enum vp8e_enc_control_id id, int *val)
+{
+VPxContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, " %*s%d\n", width, buf, *val);
+
+res = vpx_codec_control(&ctx->encoder, id, val);
+if (res != VPX_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+}
+
+return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
+}
+#endif
+
static av_cold int vpx_free(AVCodecContext *avctx)
{
VPxContext *ctx = avctx->priv_data;
+int level_out = 0;
+
+#if VPX_ENCODER_ABI_VERSION >= 12
+if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1) &&
+!codecctl_intp(avctx, VP9E_GET_LEVEL, &level_out))
+ av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 0.1);
+#endif
vpx_codec_destroy(&ctx->encoder);
if (ctx->is_alpha)
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] libvpxenc: Support targeting a VP9 level
Levels are specified at https://www.webmproject.org/vp9/levels/
---
libavcodec/libvpxenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 68f25a4..51f423a 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -107,6 +107,7 @@ typedef struct VPxEncoderContext {
int drop_threshold;
int noise_sensitivity;
int vpx_cs;
+float level;
} VPxContext;
/** String mappings for enum vp8e_enc_control_id */
@@ -134,6 +135,9 @@ static const char *const ctlidstr[] = {
#if VPX_ENCODER_ABI_VERSION >= 11
[VP9E_SET_COLOR_RANGE] = "VP9E_SET_COLOR_RANGE",
#endif
+#if VPX_ENCODER_ABI_VERSION >= 12
+[VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+#endif
#endif
};
@@ -680,6 +684,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
#if VPX_ENCODER_ABI_VERSION >= 11
set_color_range(avctx);
#endif
+#if VPX_ENCODER_ABI_VERSION >= 12
+codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 :
lrint(ctx->level * 10));
+#endif
}
#endif
@@ -1089,6 +1096,9 @@ static const AVOption vp9_options[] = {
{ "variance","Variance based Aq", 0, AV_OPT_TYPE_CONST, {.i64 =
1}, 0, 0, VE, "aq_mode" },
{ "complexity", "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 =
2}, 0, 0, VE, "aq_mode" },
{ "cyclic", "Cyclic Refresh Aq", 0, AV_OPT_TYPE_CONST, {.i64 =
3}, 0, 0, VE, "aq_mode" },
+#if VPX_ENCODER_ABI_VERSION >= 12
+{"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1},
-1, 6.2, VE},
+#endif
LEGACY_OPTIONS
{ NULL }
};
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libvpxenc: Support targeting a VP9 level
On Fri, Nov 18, 2016 at 3:44 PM, James Zern wrote: > > On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse > wrote: > > Levels are specified at https://www.webmproject.org/vp9/levels/ > > --- > > libavcodec/libvpxenc.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > lgtm Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level
Report the actual level of the encoded output if a level is
targeted or the level is passively tracked with a target of 0.
---
libavcodec/libvpxenc.c | 32
1 file changed, 32 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 51f423a..1325199 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -137,6 +137,7 @@ static const char *const ctlidstr[] = {
#endif
#if VPX_ENCODER_ABI_VERSION >= 12
[VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+[VP9E_GET_LEVEL] = "VP9E_GET_LEVEL",
#endif
#endif
};
@@ -264,10 +265,41 @@ static av_cold int codecctl_int(AVCodecContext *avctx,
return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
}
+#if VPX_ENCODER_ABI_VERSION >= 12
+static av_cold int codecctl_intp(AVCodecContext *avctx,
+ enum vp8e_enc_control_id id, int *val)
+{
+VPxContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, " %*s%d\n", width, buf, *val);
+
+res = vpx_codec_control(&ctx->encoder, id, val);
+if (res != VPX_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+}
+
+return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
+}
+#endif
+
static av_cold int vpx_free(AVCodecContext *avctx)
{
VPxContext *ctx = avctx->priv_data;
+#if VPX_ENCODER_ABI_VERSION >= 12
+if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+int level_out = 0;
+if (!codecctl_intp(avctx, VP9E_GET_LEVEL, &level_out))
+av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out *
0.1);
+}
+#endif
+
vpx_codec_destroy(&ctx->encoder);
if (ctx->is_alpha)
vpx_codec_destroy(&ctx->encoder_alpha);
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level
On Tue, Nov 22, 2016 at 3:10 PM, James Zern wrote: > On Tue, Nov 22, 2016 at 12:08 PM, James Zern wrote: >> On Tue, Nov 22, 2016 at 12:04 PM, James Zern wrote: >>> On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse >>> wrote: >>>> Report the actual level of the encoded output if a level is >>>> targeted or the level is passively tracked with a target of 0. >>>> --- >>>> libavcodec/libvpxenc.c | 31 +++ >>>> 1 file changed, 31 insertions(+) >>>> >>> >>> lgtm. >>> I don't know if there's a better way to report this at the stream >>> level (AV_PKT_DATA_STRINGS_METADATA?), there doesn't seem to be >>> anything specific right now. This info can be translated quickly if >>> someone wants to make this more structured or has any opinion now. >>> >> >> I forgot that there was some discussion around adding this to the >> codec extradata in webm. That could be a followup if there's >> documentation on the format for that. > > http://wiki.webmproject.org/vp9-codecprivate Are there any tools that read or write this data. libavformat and libvpx/webmenc.cc don't seem to implement it. I'd rather not be the guinea pig for this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level
On Mon, Nov 28, 2016 at 11:57 AM, James Zern wrote: > On Mon, Nov 28, 2016 at 10:34 AM, Alex Converse > wrote: >> Report the actual level of the encoded output if a level is >> targeted or the level is passively tracked with a target of 0. >> --- >> libavcodec/libvpxenc.c | 32 >> 1 file changed, 32 insertions(+) >> > > lgtm pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.
On Tue, Dec 6, 2016 at 5:08 PM, Alex Converse wrote:
> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>
> Reported-by: rcombs on IRC
> ---
> libavcodec/aacdec_template.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 8cfa34b..64d46e3 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
> void *data,
> break;
> }
>
> -che_prev = che;
> -elem_type_prev = elem_type;
> +if (elem_type < TYPE_DSE) {
> +che_prev = che;
> +elem_type_prev = elem_type;
> +}
>
Arguably the che having knowledge of its element type would be better
design but more invasive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.
Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
Reported-by: rcombs on IRC
---
libavcodec/aacdec_template.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 8cfa34b..64d46e3 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
break;
}
-che_prev = che;
-elem_type_prev = elem_type;
+if (elem_type < TYPE_DSE) {
+che_prev = che;
+elem_type_prev = elem_type;
+}
if (err)
goto fail;
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.
On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
wrote:
> On 7 December 2016 at 01:08, Alex Converse wrote:
>
>> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>>
>> Reported-by: rcombs on IRC
>> ---
>> libavcodec/aacdec_template.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 8cfa34b..64d46e3 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext
>> *avctx, void *data,
>> break;
>> }
>>
>> -che_prev = che;
>> -elem_type_prev = elem_type;
>> +if (elem_type < TYPE_DSE) {
>> +che_prev = che;
>> +elem_type_prev = elem_type;
>> +}
>>
>> if (err)
>> goto fail;
>>
>
> I'm not quite following. So it prevents TYPE_DSE and above from getting
> into che_prev which goes into decode_extension_payload() which then decodes
> extensions. But DSE isn't the last in the enum, what about PCE, FIL and END
> elements?
The actual use of elem_type_prev is to describe the element type of
che_prev, but che only updates for element types SCE, CPE, CCE, and
LFE (0, 1, 2, and 3). (che_prev is currently updated every element,
but if che isn't updated on an element then it's a noop.)
>if (elem_type < TYPE_DSE) {
>if (!(che=get_che(ac, elem_type, elem_id))) {
>av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d is not
> allocated\n",
> elem_type, elem_id);
>err = AVERROR_INVALIDDATA;
>goto fail;
>}
>samples = 1024;
>che->present = 1;
>}
Allowing elem_type_prev to desynchronize from che_prev means that the
SBR decoder is provided a che but incorrectly informed of the type of
element the che represents.
For example, the frames of the stream look like this:
[aac @ 0x25659c0] Elem type:0 id:0 // SCE
[aac @ 0x25659c0] Elem type:6 id:3 // FIL
[aac @ 0x25659c0] extension type: 11 len:3 // FIL payload DRC
[aac @ 0x25659c0] Elem type:6 id:9 // FIL
[aac @ 0x25659c0] extension type: 13 len:9 // FIL payload SBR
[aac @ 0x25659c0] Invalid bitstream - cannot apply SBR to element type 6
[aac @ 0x25659c0] Elem type:1 id:0 // CPE
[aac @ 0x25659c0] Elem type:6 id:f // FIL
[aac @ 0x25659c0] extension type: 13 len:18 // FIL payload SBR
[aac @ 0x25659c0] Elem type:1 id:1 // CPE
[aac @ 0x25659c0] Elem type:6 id:f // FIL
[aac @ 0x25659c0] extension type: 13 len:18 // FIL payload SBR
[aac @ 0x25659c0] Elem type:1 id:2 // CPE
[aac @ 0x25659c0] Elem type:6 id:f // FIL
[aac @ 0x25659c0] extension type: 13 len:18 // FIL payload SBR
[aac @ 0x25659c0] Elem type:3 id:0 // LFE
[aac @ 0x25659c0] Elem type:4 id:0 // DSE
[aac @ 0x25659c0] Elem type:7 // END
[aac @ 0x25659c0] element type mismatch 3 != 0
[aac @ 0x25659c0] element type mismatch 0 != 6
In this case we clearly want to apply the first SBR element to the
first SCE element. But the DRC element between them means that we are
going to attempt to apply it the the first SCE element, but we are
going to tell the SBR decoder that the SCE element is a FIL element
which is nonsense.
Assuming we want to support streams like this (generated by
"Fraunhofer IIS MPEG-4 Audio Encoder 03.02.15_MPEGScbr_hdaac") the
che_prev should stay live across FIL elements.
The 2009 spec says:
> 4.5.2.8.2.2 SBR extension payload for the audio object
> types AAC main, AAC SSR, AAC LC and AAC LTP
>
> One SBR fill element is used per AAC syntactic element
> that is to be enhanced by SBR. SBR elements are
> inserted into the raw_data_block() after the
> corresponding AAC elements. Each AAC SCE, CPE or
> independently switched CCE must be succeeded by a
> corresponding SBR element. LFE elements are decoded
> according to standard AAC procedures but must be delay
> adjusted and re-sampled to match the output sample
> rate. Given below is an example of the structure of
> syntactic elements within a raw data block of a 5.1
> (multichannel) configuration, where SBR is used
> without a CRC check.
>
> > // center
> > // front L/R
> > // back L/R
> // sub
> // (end of raw data block)
If someone really wanted to be pedantic about it, they could argue
that the SBR data has to follow the SCE, CPE, or CCE, but it doesn't
have to immediately follow the element. I think this is an awkward
interpretation of the text, but the text doesn't seem to otherwise
address having a different FIL element between the SCE,
[FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.
It describes the type of the previous che element (SCE, CPE, CCE, or
LFE) and does not reflect non-che elements.
---
libavcodec/aacdec_template.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 64d46e3..83e9fb5 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2923,7 +2923,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
{
AACContext *ac = avctx->priv_data;
ChannelElement *che = NULL, *che_prev = NULL;
-enum RawDataBlockType elem_type, elem_type_prev = TYPE_END;
+enum RawDataBlockType elem_type, che_prev_type = TYPE_END;
int err, elem_id;
int samples = 0, multiplier, audio_found = 0, pce_found = 0;
int is_dmono, sce_count = 0;
@@ -3029,7 +3029,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
goto fail;
}
while (elem_id > 0)
-elem_id -= decode_extension_payload(ac, gb, elem_id, che_prev,
elem_type_prev);
+elem_id -= decode_extension_payload(ac, gb, elem_id, che_prev,
che_prev_type);
err = 0; /* FIXME */
break;
@@ -3039,8 +3039,8 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
}
if (elem_type < TYPE_DSE) {
-che_prev = che;
-elem_type_prev = elem_type;
+che_prev = che;
+che_prev_type = elem_type;
}
if (err)
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.
On Thu, Dec 8, 2016 at 12:56 PM, Rostislav Pehlivanov wrote: > On 8 December 2016 at 19:55, Alex Converse wrote: > >> It describes the type of the previous che element (SCE, CPE, CCE, or >> LFE) and does not reflect non-che elements. >> --- >> libavcodec/aacdec_template.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> [...] > > LGTM, thanks. Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.
On Thu, Dec 8, 2016 at 12:36 PM, Rostislav Pehlivanov
wrote:
>
> On 8 December 2016 at 19:42, Alex Converse wrote:
>>
>> On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
>> wrote:
>> > On 7 December 2016 at 01:08, Alex Converse
>> > wrote:
>> >
>> >> Fixes
>> >> https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>> >>
>> >> Reported-by: rcombs on IRC
>> >> ---
>> >> libavcodec/aacdec_template.c | 6 --
>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/libavcodec/aacdec_template.c
>> >> b/libavcodec/aacdec_template.c
>> >> index 8cfa34b..64d46e3 100644
>> >> --- a/libavcodec/aacdec_template.c
>> >> +++ b/libavcodec/aacdec_template.c
>> >> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext
>> >> *avctx, void *data,
>> >> break;
>> >> }
>> >>
>> >> -che_prev = che;
>> >> -elem_type_prev = elem_type;
>> >> +if (elem_type < TYPE_DSE) {
>> >> +che_prev = che;
>> >> +elem_type_prev = elem_type;
>> >> +}
>> >>
>> >> if (err)
>> >> goto fail;
>> >>
>> >
>> > I'm not quite following. So it prevents TYPE_DSE and above from getting
>> > into che_prev which goes into decode_extension_payload() which then
>> > decodes
>> > extensions. But DSE isn't the last in the enum, what about PCE, FIL and
>> > END
>> > elements?
>>
>> The actual use of elem_type_prev is to describe the element type of
>> che_prev, but che only updates for element types SCE, CPE, CCE, and
>> LFE (0, 1, 2, and 3). (che_prev is currently updated every element,
>> but if che isn't updated on an element then it's a noop.)
>>
>
> Thanks for the great explanation, now it all makes sense.
> Patch LGTM, feel free to push whenever you can.
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes
Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not
implement requested capability" log messages on VP8 encodes.
---
libavcodec/libvpxenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 1325199..de0d0b6 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -293,7 +293,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
VPxContext *ctx = avctx->priv_data;
#if VPX_ENCODER_ABI_VERSION >= 12
-if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->level >= 0 &&
+!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
int level_out = 0;
if (!codecctl_intp(avctx, VP9E_GET_LEVEL, &level_out))
av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out *
0.1);
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes
On Mon, Dec 12, 2016 at 2:41 PM, James Zern wrote: > On Mon, Dec 12, 2016 at 12:12 PM, Alex Converse > wrote: >> Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not >> implement requested capability" log messages on VP8 encodes. >> --- >> libavcodec/libvpxenc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > lgtm Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Normalize VP8 and VP9 tags when writing IVF.
VP9-in-ISOM uses vp08 and vp09 tags, while ivf uses VP80 and VP90.
---
libavformat/ivfenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 5dbcd97..1735606 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -26,6 +26,17 @@ typedef struct IVFEncContext {
uint64_t last_pts, sum_delta_pts;
} IVFEncContext;
+static const int canonical_tag_vp8 = MKTAG('V', 'P', '8', '0');
+static const int canonical_tag_vp9 = MKTAG('V', 'P', '9', '0');
+
+static uint32_t canonicalize_tag(AVCodecParameters *par) {
+ switch (par->codec_id) {
+ case AV_CODEC_ID_VP8: return MKTAG('V', 'P', '8', '0');
+ case AV_CODEC_ID_VP9: return MKTAG('V', 'P', '9', '0');
+ default: return par->codec_tag;
+ }
+}
+
static int ivf_write_header(AVFormatContext *s)
{
AVCodecParameters *par;
@@ -44,7 +55,7 @@ static int ivf_write_header(AVFormatContext *s)
avio_write(pb, "DKIF", 4);
avio_wl16(pb, 0); // version
avio_wl16(pb, 32); // header length
-avio_wl32(pb, par->codec_tag ? par->codec_tag : par->codec_id ==
AV_CODEC_ID_VP9 ? AV_RL32("VP90") : AV_RL32("VP80"));
+avio_wl32(pb, canonicalize_tag(par));
avio_wl16(pb, par->width);
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Parse VP9 when coming out of MP4.
Fixes Netflix VP9 DASH samples. --- libavformat/mov.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index a7595c5..6e80b93 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, AVIOContext *pb, case AV_CODEC_ID_EAC3: case AV_CODEC_ID_MPEG1VIDEO: case AV_CODEC_ID_VC1: +case AV_CODEC_ID_VP9: st->need_parsing = AVSTREAM_PARSE_FULL; break; default: -- 2.8.0.rc3.226.g39d4020 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ivfenc: Add VPX codec tags.
This fixes remuxing VPX from MP4 without manually overwriting the tag.
---
libavformat/ivfenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 5dbcd97..f3ae4dc 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -97,6 +97,12 @@ static int ivf_check_bitstream(struct AVFormatContext *s,
const AVPacket *pkt)
return ret;
}
+static const AVCodecTag codec_ivf_tags[] = {
+{ AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
+{ AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
+{ AV_CODEC_ID_NONE, 0 }
+};
+
AVOutputFormat ff_ivf_muxer = {
.priv_data_size = sizeof(IVFEncContext),
.name = "ivf",
@@ -108,4 +114,5 @@ AVOutputFormat ff_ivf_muxer = {
.write_packet = ivf_write_packet,
.write_trailer = ivf_write_trailer,
.check_bitstream = ivf_check_bitstream,
+.codec_tag= (const AVCodecTag* const []){ codec_ivf_tags, 0 },
};
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg code Attribution
On Wed, Mar 23, 2016 at 10:35 PM, Aaron Boxer wrote:
> On Wed, Mar 23, 2016 at 3:59 PM, Michael Bradshaw
> wrote:
>
> > On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> > > Hello Again,
> > >
> > > I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG
> for
> > > many years, and I would say at least 20% of the code in FFmpeg was
> either
> > > directly copied from OpenJPEG, or is very similar to OpenJPEG code.
> > >
> > > I think the people who did the work on the FFmpeg codec would readily
> > admit
> > > that they copied a certain amount directly from the other project.
> > >
> > > So, I think that the OpenJPEG BSD license should appear on those files
> > with
> > > copied code from OpenJPEG, to comply with the BSD license. I can list
> > some
> > > of the files (there aren't many) if people are interested.
> >
> > Go ahead and list the files and sections of code you're concerned
> > about (or the commits that introduced the code). Chances are that's
> > going to come up in the thread anyway, so might as well do it from the
> > get-go.
> >
>
> Here is the most obvious example:
>
> j2kenc.c (from FFmpeg)
>
> static int getnmsedec_sig(int x, int bpno)
> {
> if (bpno > NMSEDEC_FRACBITS)
> return lut_nmsedec_sig[(x >> (bpno - NMSEDEC_FRACBITS)) & ((1 <<
> NMSEDEC_BITS) - 1)];
> return lut_nmsedec_sig0[x & ((1 << NMSEDEC_BITS) - 1)];
> }
>
> static int getnmsedec_ref(int x, int bpno)
> {
> if (bpno > NMSEDEC_FRACBITS)
> return lut_nmsedec_ref[(x >> (bpno - NMSEDEC_FRACBITS)) & ((1 <<
> NMSEDEC_BITS) - 1)];
> return lut_nmsedec_ref0[x & ((1 << NMSEDEC_BITS) - 1)];
> }
>
>
> //
>
> t1.c (from OpenJPEG)
>
> int16_t opj_t1_getnmsedec_sig(uint32_t x, uint32_t bitpos)
> {
> if (bitpos > 0) {
> return lut_nmsedec_sig[(x >> (bitpos)) & ((1 << T1_NMSEDEC_BITS) -
> 1)];
> }
>
> return lut_nmsedec_sig0[x & ((1 << T1_NMSEDEC_BITS) - 1)];
> }
>
> int16_t opj_t1_getnmsedec_ref(uint32_t x, uint32_t bitpos)
> {
> if (bitpos > 0) {
> return lut_nmsedec_ref[(x >> (bitpos)) & ((1 << T1_NMSEDEC_BITS) -
> 1)];
> }
>
> return lut_nmsedec_ref0[x & ((1 << T1_NMSEDEC_BITS) - 1)];
> }
>
>
>
>
> I will post more later.
>
Not having seen the specification I do have a question: Is it possible this
code piece is in the spec? Many specs contain sample code or a description
leading to very similar implementations.
I think this is important to double check and try to stay not biased.
Best,
Alex
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg code Attribution
On Thu, Mar 24, 2016 at 12:23 PM, Alex Beregszaszi wrote: > > Not having seen the specification I do have a question: Is it possible this > code piece is in the spec? Many specs contain sample code or a description > leading to very similar implementations. > > I think this is important to double check and try to stay not biased. Apologies for the formatting of the previous email. Is there any way to set Gmail to plain text mode for certain mailing lists? Best, Alex ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg code Attribution
On Thu, Mar 24, 2016 at 2:44 PM, Aaron Boxer wrote: > On Thu, Mar 24, 2016 at 12:55 AM, Reimar Döffinger > wrote: > >> On Wed, Mar 23, 2016 at 10:50:06PM -0400, Aaron Boxer wrote: >> > On Wed, Mar 23, 2016 at 9:48 PM, Ricardo Constantino >> > wrote: >> > >> > > On 23 March 2016 at 22:35, Aaron Boxer wrote: >> > > > Back to my original point, what is the reasoning not to just switch >> to >> > > > OpenJPEG? >> > > Both OpenJPEG 1 and 2 are supported to add as external libraries in >> > > FFmpeg. What do you mean by switching to OpenJPEG? >> > > >> > >> > >> > I mean abandoning FFmpeg j2k codec, which seems to be a less-featureful >> > copy of OpenJPEG, >> > and putting resources into fixing OpenJPEG issues and making it better. >> > Since OpenJPEG >> > has a much broader user community, this would help both FFmpeg users and >> > many others. >> >> I wonder if you mean only the encoder or also the decoder... >> In general: competition and alternatives are good. >> Every standard should have multiple viable implementations. >> Of course if much code is shared/copied that weakens the argument >> a lot. >> However when it comes to decoders I do consider it important >> for FFmpeg to have its own implementation even if there are >> such shortcomings. >> If for no other reason that having all implementations in >> a shared code base, with shared concepts that allows to >> compare and find common approaches much more easily seems >> a very important thing to me which nobody else provides. >> Every external codec re-invents their way of writing >> bitstreams, VLC codes, ... making it hard to impossible >> to share code or even concepts. >> Plus there is a good chance that FFmpeg will still be >> maintained by the time quite a few of those external >> libraries have become unmaintained and suffered of bitrot. >> In some ways I think I'd consider sharing test vectors >> a possibly more important way of cooperating with >> other projects than sharing code. >> > > > Yes, monoculture is not good. But, one also doesn't want to expend precious > resources re-inventing > the wheel. It's a balance. > > I feel that JPEG 2000 is a bit of a unique case - it is probably one of the > most complex > standards around, and most of the complexity (for example parsing the file > format and code stream) > is not, to my knowledge, shared by other codecs. So, the advantage you > mentioned of re-using > structures across codecs does not really apply to J2K. > > FFmpeg j2k codec was written almost 10 years ago, seemingly as a partial > copy of OpenJPEG, and it is still inferior to it. So, my guess is that > OpenJPEG will continue to be the better choice, unless you can miraculously > summon an army of developers and, equally importantly, users, for the > FFmpeg codec. > > I agree about sharing testing vectors. The OpenJPEG test suite is quite > extensive. But, I'm not quite sure how to share > it with FFmpeg. It relies on ctest framework from Kitware, which doesn't > really fit with FFmpeg environment. Someone would have to re-write all of > the tests. Aaron, I am really wondering what is your goal here. Do you want the JPEG2K implementation be removed from FFmpeg? My impression based on the first thread was that you would be interested in having your AGPL implementation included. Later you have mentioned that you don't want to have it included. Based on past examples I think an implementation would be removed in the following cases: a) there is a superior new FFmpeg-specific implementation available (and not an external library) b) it is broken beyond repair Do any of the following cases stand today? Best, Alex ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section
On Sun, Mar 20, 2016 at 6:29 AM, Christophe Gisquet < christophe.gisq...@gmail.com> wrote: > > > I understand the sentiment, and there's probably little lost in > keeping it, but... is it not a hack? ie: > - When do you notice the added security is no longer there/it breaks > in even worse ways? > - Who is and would be available and able to prevent it from breaking? > Because it already has, and almost nobody dealt with it. > > The original author already did well in reporting the issue to > binutils, so I'm certainly not complaining about his efforts. > > -- > Christophe > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Sorry didn't see this until now. I think that making it dependent on enable/disable-debug is reasonable for an immediate fix. I'll see about taking another stab at binutils and seeing if this can't get fixed upstream. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: Fix debugging on mingw-w64 with gdb
The relocation hack broke debugging on mingw-w64 when using gdb. This makes the reloc hack dependent on --disable-debug so it's still enabled for release builds. This is simply an immediate fix for the issue of broken debugging, we should probably still look at the possibility of reverting it outright if it proves to be more trouble than it's worth. For now keeping it enabled for release builds is a reasonable trade off. Signed-off-by: Alex Smith --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index e550547..e8c4a7b 100755 --- a/configure +++ b/configure @@ -4634,9 +4634,9 @@ case $target_os in # however ld then forgets what the entry point should be (oops) so we # have to manually (re)set it. if enabled x86_32; then -add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup +disabled debug && add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup elif enabled x86_64; then -add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup +disabled debug && add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup check_ldflags -Wl,--high-entropy-va # binutils 2.25 # Set image base >4GB for extra entropy with HEASLR add_ldexeflags -Wl,--image-base,0x14000 -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Fix debugging on mingw-w64 with gdb
I think the logic is correct but I won't be able to test it with the changes until tomorrow. I wanted to get the patch on the ML as soon as possible since debugging is currently broken. As I mentioned in the original patch thread I'll see about taking another stab at binutils to see if this can't get fixed upstream. In the mean time keeping the reloc hack enabled for release builds seems reasonable. Sorry for the delay in addressing this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ogg audio muxing bug and patch
Attached patch fixes an int<-->uint bug affecting muxing of ogg audio. This line is the problem: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggparsevorbis.c#L476 You can see in: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggdec.h#L68 that `os->pduration` is an `unsigned int`, but over at https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggparsevorbis.c#L409 the `duration` local is just an `int`... So when `duration` is negative, it's getting converted to a large positive 32-bit unsigned int. ab pduration.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init
Quiets some log spam on pure upsampling mode.
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/aacsbr.h | 2 +-
libavcodec/aacsbr_template.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 2a06f82efe..6654416e69 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
if (!ac->che[type][id]) {
if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr, type);
}
if (type != TYPE_CCE) {
if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type ==
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
/** Initialize SBR. */
void AAC_RENAME(ff_aac_sbr_init)(void);
/** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr, int id_aac);
/** Close one SBR context. */
void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
/** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
memset(&sbr->spectrum_params, -1, sizeof(SpectrumParameters));
}
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr, int id_aac)
{
if(sbr->mdct.mdct_bits)
return;
sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
sbr_turnoff(sbr);
sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] aac_latm: Allow unaligned AudioSpecificConfig
Fixes ticket 4730
---
libavcodec/aacdec.c | 26 --
libavcodec/aacdec_template.c | 82
libavcodec/mpeg4audio.c | 76 ++--
libavcodec/mpeg4audio.h | 12 ++-
4 files changed, 120 insertions(+), 76 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
AACContext *ac= &latmctx->aac_ctx;
AVCodecContext *avctx = ac->avctx;
MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
int config_start_bit = get_bits_count(gb);
int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
if (asclen) {
sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
} else
asclen = get_bits_left(gb);
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
- "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
if (asclen <= 0)
return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, &m4ac,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
-if (bits_consumed < 0)
+init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
+skip_bits_long(&gbc, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, &m4ac,
+&gbc, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
if (!latmctx->initialized ||
ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+ avctx->extradata[i] = get_bits(&gbc, 8);
+}
memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
}
skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..2a06f82efe 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
}
}
+static inline void relative_align_get_bits(GetBitContext *gb,
+ int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
/**
* Decode program configuration element; reference: table 4.2.
*
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
*/
static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
uint8_t (*layout_map)[3],
- GetBitContext *gb)
+ GetBitContext *gb, int byte_align_ref)
{
int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
tags += num_cc;
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
/* comment field, first byte is length */
comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
*/
static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
GetBitContext *gb,
+ int get_bit_alignment,
MPEG4AudioConfig *m4ac,
int channel_config)
{
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac,
AVCodecContext *avctx,
if (channel_config == 0) {
skip_bits(gb, 4); // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
if (tags < 0)
return tags;
} else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac,
AVCodecContext *avctx,
* @param ac pointer to AACContext, may be null
* @param avctx pointer to AVCCodecContext, used for logging
* @param m4acpointer to MPEG4AudioCo
[FFmpeg-devel] [PATCH 4/4] aac_latm: Align inband PCE to the start of the payload
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.
It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.
Fixes ticket 4544
---
libavcodec/aacdec_template.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 6654416e69..1f14a1cbae 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2949,6 +2949,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
int err, elem_id;
int samples = 0, multiplier, audio_found = 0, pce_found = 0;
int is_dmono, sce_count = 0;
+int payload_alignment;
ac->frame = data;
@@ -2971,6 +2972,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
// This may lead to an undefined profile being signaled
ac->avctx->profile = ac->oc[1].m4ac.object_type - 1;
+payload_alignment = get_bits_count(gb);
ac->tags_mapped = 0;
// parse
while ((elem_type = get_bits(gb, 3)) != TYPE_END) {
@@ -3025,7 +3027,8 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
uint8_t layout_map[MAX_ELEM_ID*4][3];
int tags;
push_output_configuration(ac);
-tags = decode_pce(avctx, &ac->oc[1].m4ac, layout_map, gb, 0);
+tags = decode_pce(avctx, &ac->oc[1].m4ac, layout_map, gb,
+ payload_alignment);
if (tags < 0) {
err = tags;
break;
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] aac_latm: Copy whole AudioSpecificConfig when it is sized.
This preserves sync extensions.
---
libavcodec/aacdec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 709ac7cdf8..08d92fe145 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -289,17 +289,19 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
int sync_extension= 0;
int bits_consumed, esize, i;
-if (asclen) {
+if (asclen > 0) {
sync_extension = 1;
asclen = FFMIN(asclen, get_bits_left(gb));
-} else
-asclen = get_bits_left(gb);
-
-if (asclen <= 0)
+init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
+skip_bits_long(&gbc, config_start_bit);
+} else if (asclen == 0) {
+gbc = *gb;
+} else {
return AVERROR_INVALIDDATA;
+}
-init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
-skip_bits_long(&gbc, config_start_bit);
+if (get_bits_left(gb) <= 0)
+return AVERROR_INVALIDDATA;
bits_consumed = decode_audio_specific_config_gb(NULL, avctx, &m4ac,
&gbc, config_start_bit,
@@ -309,6 +311,9 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
return AVERROR_INVALIDDATA;
bits_consumed -= config_start_bit;
+if (asclen == 0)
+ asclen = bits_consumed;
+
if (!latmctx->initialized ||
ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
ac->oc[1].m4ac.chan_config != m4ac.chan_config) {
@@ -320,7 +325,7 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
latmctx->initialized = 0;
-esize = (bits_consumed+7) / 8;
+esize = (asclen + 7) / 8;
if (avctx->extradata_size < esize) {
av_free(avctx->extradata);
@@ -336,9 +341,9 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
}
-skip_bits_long(gb, bits_consumed);
+skip_bits_long(gb, asclen);
-return bits_consumed;
+return 0;
}
static int read_stream_mux_config(struct LATMContext *latmctx,
@@ -379,8 +384,6 @@ static int read_stream_mux_config(struct LATMContext
*latmctx,
int ascLen = latm_get_value(gb);
if ((ret = latm_decode_audio_specific_config(latmctx, gb, ascLen))
< 0)
return ret;
-ascLen -= ret;
-skip_bits_long(gb, ascLen);
}
latmctx->frame_length_type = get_bits(gb, 3);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/4] aac_latm: Allow unaligned AudioSpecificConfig
Fixes ticket 4730
---
libavcodec/aacdec.c | 26 --
libavcodec/aacdec_template.c | 82
libavcodec/mpeg4audio.c | 76 ++--
libavcodec/mpeg4audio.h | 12 ++-
4 files changed, 120 insertions(+), 76 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
AACContext *ac= &latmctx->aac_ctx;
AVCodecContext *avctx = ac->avctx;
MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
int config_start_bit = get_bits_count(gb);
int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
if (asclen) {
sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
} else
asclen = get_bits_left(gb);
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
- "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
if (asclen <= 0)
return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, &m4ac,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
-if (bits_consumed < 0)
+init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
+skip_bits_long(&gbc, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, &m4ac,
+&gbc, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
if (!latmctx->initialized ||
ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+ avctx->extradata[i] = get_bits(&gbc, 8);
+}
memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
}
skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..e230c87733 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
}
}
+static inline void relative_align_get_bits(GetBitContext *gb,
+ int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
/**
* Decode program configuration element; reference: table 4.2.
*
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
*/
static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
uint8_t (*layout_map)[3],
- GetBitContext *gb)
+ GetBitContext *gb, int byte_align_ref)
{
int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
tags += num_cc;
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
/* comment field, first byte is length */
comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
*/
static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
GetBitContext *gb,
+ int get_bit_alignment,
MPEG4AudioConfig *m4ac,
int channel_config)
{
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac,
AVCodecContext *avctx,
if (channel_config == 0) {
skip_bits(gb, 4); // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
if (tags < 0)
return tags;
} else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac,
AVCodecContext *avctx,
* @param ac pointer to AACContext, may be null
* @param avctx pointer to AVCCodecContext, used for logging
* @param m4acpointer to MPEG4AudioCo
[FFmpeg-devel] [PATCH v2 3/4] aacsbr: Associate SBR data with AAC elements on init
Quiets some log spam on pure upsampling mode.
Fixes ticket 5163.
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/aacsbr.h | 2 +-
libavcodec/aacsbr_template.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index e230c87733..d980ae0e22 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
if (!ac->che[type][id]) {
if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr, type);
}
if (type != TYPE_CCE) {
if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type ==
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
/** Initialize SBR. */
void AAC_RENAME(ff_aac_sbr_init)(void);
/** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr, int id_aac);
/** Close one SBR context. */
void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
/** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
memset(&sbr->spectrum_params, -1, sizeof(SpectrumParameters));
}
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr, int id_aac)
{
if(sbr->mdct.mdct_bits)
return;
sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
sbr_turnoff(sbr);
sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init
On Thu, Feb 9, 2017 at 4:11 PM, Carl Eugen Hoyos wrote: > > 2017-02-09 18:40 GMT+01:00 Alex Converse : > > Quiets some log spam on pure upsampling mode. > > Please mention ticket #5163. > Done > For the whole patchset, I suggest you push as soon as everybody > agrees on the function prefixes. > Prefix changed. Patches 2 and 4 don't have any comments. Do they need further review by anyone? > Could you review my patch for ticket #1614? > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164080.html > It seems to fix the second sample attached on trac, aac_broken.mp4. > It appears that your patch is decoding two channels "on top of each other" creating the artifacts noted in the original review. There isn't an easy change to make to that patch to fix this. The best way to handle it is in positional channel orders to try to decode everything we see then sniff out the channel order after the fact, using the indexed channel configuration as more of a suggestion. That may open the door to some truly crazy stuff, so it's probably best to do some fuzzing and large scale testing on that sort of change before landing it. > Did you see ticket #5722? > It looks like it's probably a demuxer issue. I haven't looked at mov.c in a long time. [...] Regards, Alex ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacdec: When ignoring a PCE restore the previous config
This is related to, but doesn't solve ticker 6152.
---
libavcodec/aacdec_template.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 4e0a9529e1..4367e74cf7 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3036,6 +3036,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
if (pce_found) {
av_log(avctx, AV_LOG_ERROR,
"Not evaluating a further program_config_element as
this construct is dubious at best.\n");
+pop_output_configuration(ac);
} else {
err = output_configure(ac, layout_map, tags, OC_TRIAL_PCE, 1);
if (!err)
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: When ignoring a PCE restore the previous config
On Thu, Feb 16, 2017 at 3:21 PM, Carl Eugen Hoyos wrote:
> 2017-02-16 22:13 GMT+01:00 Alex Converse :
>> This is related to, but doesn't solve ticker 6152.
>> ---
>> libavcodec/aacdec_template.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 4e0a9529e1..4367e74cf7 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -3036,6 +3036,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
>> void *data,
>> if (pce_found) {
>> av_log(avctx, AV_LOG_ERROR,
>> "Not evaluating a further program_config_element as
>> this construct is dubious at best.\n");
>> +pop_output_configuration(ac);
>> } else {
>> err = output_configure(ac, layout_map, tags, OC_TRIAL_PCE,
>> 1);
>> if (!err)
>
> I thought ticket #6152 was related to the else tree...
>
> Anyway: Since this is your code, please wait a day or two
> and push.
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [DISCUSSION] Motion Estimation API/Library
I like the idea -- it will be then possible to link to hardware acceleration. I don't think R-D optimization (including taking VLC / CABAC into account) belongs to the library -- this, as well as figuring out partitions, should be up to the actual encoder. On Thu, Aug 3, 2017 at 4:09 PM, Ronald S. Bultje wrote: > Hi, > > On Thu, Aug 3, 2017 at 5:32 PM, Davinder Singh > wrote: > > > On Tue, Aug 1, 2017 at 7:40 AM Davinder Singh > wrote: > > > > > [...] > > > > > > > Keeping where the code lives, aside, > > > > main thing is API, so we need to talk about it. > > > You're assuming that we know in advance what the API will have to do. I > don't think that's the case. > > For example, what block sizes does it operate on? me_cc doesn't work for > 64x64 blocks in HEVC, VP9 (and AV1?). > > Or what if we don't use VLC coding, but some arithmetic variation? Like all > H.264, VP8-9, HEVC (and AV1?). Where perhaps the arithmetic coding can > depend not just on intra/inter, but also on transform size, chroma/luma, > etc. > > What if qscale is not uniform and allows per-coefficient matrix variations? > How many sub-types of such variations will exist? > > My point is: designing it in advance for everything like this is insane. > Just copy what is there, and prepare for the API to change _all the time_ > while we're molding it to fit in other problem shapes. > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling
On Sat, Aug 12, 2017 at 9:47 AM, Dave Rice wrote: > > Hello all, > This issue originated in this thread > https://github.com/amiaopensource/vrecord/issues/170. On Field Order, in the > QuickTime specification at > https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html > (and similarly in the Matroska specification which adopted similar language) > it states the following meanings for field order values: > > > 9 – B is displayed earliest, T is stored first in the file. 14 – T is > > displayed earliest, B is stored first in the file. > > This definition is contradicted by other Apple documentation such as > https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION. > > An Apple engineer confirmed that the QuickTime specification’s definitions > for those Field Order values is wrong and does not match Apple’s (of > FFmpeg’s) practice, see > https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668. > > However I think that some of the commenting in ffmpeg is based upon the > inaccurate definitions from Apple. For instance, in that thread David Singer > confirms: > > > Ah, not quite. 1 and 6 are indeed 'planar' (all of one field before all of > > the other). They don't concern us. Both 9 and 14 are stored in spatial > > order (i.e. you could do terrible de-interlacing by simply displaying the > > buffer as a frame), and the 9 or 14 value tells you which field is to be > > displayed first. > > > > 9 – T is earlier than B. 14 – B is earlier than T > > mov.c associates AV_FIELD_TB with 9 and AV_FIELD_BT with 14 (similar > associations in matroska.h), but avcodec.h states: > > > AV_FIELD_TB, //< Top coded first, bottom displayed first > > AV_FIELD_BT, //< Bottom coded first, bottom displayed first > > IMHO in both cases of AV_FIELD_TB and AV_FIELD_BT the coding should be > referred as interleaved rather than ‘bottom coded first’ or ‘top coded > first’. In the case of AV_FIELD_TT and AV_FIELD_BB the fields are stored as > planar images where storage order is notable, but with TB and BT the fields > are interleaved. > > Also utils.c associates these field order values with the following labels: > > > AV_FIELD_TB -> "top coded first (swapped)"; > > AV_FIELD_BT -> "bottom coded first (swapped)"; > > From my reading, I infer that "top coded first (swapped)” means "top coded > first, bottom displayed first”; however in practice from files generated by > QuickTime and FFmpeg files with a value of TB have the top field displayed > first, so I think the labels are swapped. In the patch below I suggest using > “top first (interleaved)” for TB and “bottom first (interleaved)” for BT. > > Comments? > Icefloe019 agrees with your changes: http://mirror.informatimago.com/next/developer.apple.com/quicktime/icefloe/dispatch019.html#fiel They seems reasonable to me. when I made this change originally my primary concern was getting the field info out of extradata. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add Audio Video Sync Test filter
Hi Paul, Can you please point me to some information how this filter works? Best, Alex. On Wed, Aug 16, 2017 at 12:08 PM, Paul B Mahol wrote: > Hi, > > patch attached. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/aacdec_template: Fix running cleanup in decode_ics_info()
On Sun, Aug 20, 2017 at 5:15 PM, Michael Niedermayer
wrote:
>
> Fixes: out of array read
> Fixes: 2873/clusterfuzz-testcase-minimized-5924145713905664
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/aacdec_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index a539f74e6f..e7fa27e8db 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -1332,7 +1332,7 @@ static int decode_ics_info(AACContext *ac,
> IndividualChannelStream *ics,
> ics->tns_max_bands = ff_tns_max_bands_512[sampling_index];
> }
> if (!ics->num_swb || !ics->swb_offset)
> -return AVERROR_BUG;
> +goto fail;
> } else {
> ics->swb_offset=ff_swb_offset_1024[sampling_index];
> ics->num_swb = ff_aac_num_swb_1024[sampling_index];
okay
> @@ -1356,7 +1356,7 @@ static int decode_ics_info(AACContext *ac,
> IndividualChannelStream *ics,
> if (aot == AOT_ER_AAC_LD) {
> av_log(ac->avctx, AV_LOG_ERROR,
> "LTP in ER AAC LD not yet implemented.\n");
> -return AVERROR_PATCHWELCOME;
> +goto fail;
> }
> if ((ics->ltp.present = get_bits(gb, 1)))
> decode_ltp(&ics->ltp, gb, ics->max_sfb);
I'm not sure if it matters to anyone, but this is a missing decoder
feature and returning AVERROR_INVALIDDATA is semantically wrong.
> --
> 2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] fate: add test vector aac-al04sf_48
--- tests/fate/aac.mak | 4 1 file changed, 4 insertions(+) diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak index 5ef8ddc2b9..e8cbcef54d 100644 --- a/tests/fate/aac.mak +++ b/tests/fate/aac.mak @@ -2,6 +2,10 @@ FATE_AAC += fate-aac-al04_44 fate-aac-al04_44: CMD = pcm -i $(TARGET_SAMPLES)/aac/al04_44.mp4 fate-aac-al04_44: REF = $(SAMPLES)/aac/al04_44.s16 +FATE_AAC += fate-aac-al04sf_48 +fate-aac-al04sf_48: CMD = pcm -i $(TARGET_SAMPLES)/aac/al04sf_48.mp4 +fate-aac-al04sf_48: REF = $(SAMPLES)/aac/al04sf_48.s16 + FATE_AAC += fate-aac-al05_44 fate-aac-al05_44: CMD = pcm -i $(TARGET_SAMPLES)/aac/al05_44.mp4 fate-aac-al05_44: REF = $(SAMPLES)/aac/al05_44.s16 -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/aac: Add floating point 960/120 MDCT window
From: Paul B Mahol
Co-Authored-By: Alex Converse
---
libavcodec/aac.h | 3 +
libavcodec/aacdec_template.c | 124 +++---
libavcodec/aactab.c | 120
libavcodec/aactab.h | 6 ++
libavcodec/sinewin.h | 4 +-
libavcodec/sinewin_tablegen.h | 5 +-
6 files changed, 253 insertions(+), 9 deletions(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 97a2df6b86..4910c661d6 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -327,7 +327,9 @@ struct AACContext {
#if USE_FIXED
AVFixedDSPContext *fdsp;
#else
+MDCT15Context *mdct120;
MDCT15Context *mdct480;
+MDCT15Context *mdct960;
AVFloatDSPContext *fdsp;
#endif /* USE_FIXED */
int random_state;
@@ -353,6 +355,7 @@ struct AACContext {
OutputConfiguration oc[2];
int warned_num_aac_frames;
+int warned_960_sbr;
/* aacdec functions pointers */
void (*imdct_and_windowing)(AACContext *ac, SingleChannelElement *sce);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a539f74e6f..e76e824fbb 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -811,11 +811,21 @@ static int decode_ga_specific_config(AACContext *ac,
AVCodecContext *avctx,
uint8_t layout_map[MAX_ELEM_ID*4][3];
int tags = 0;
+#if USE_FIXED
if (get_bits1(gb)) { // frameLengthFlag
-avpriv_request_sample(avctx, "960/120 MDCT window");
+avpriv_report_missing_feature(avctx, "Fixed point 960/120 MDCT
window");
return AVERROR_PATCHWELCOME;
}
m4ac->frame_length_short = 0;
+#else
+m4ac->frame_length_short = get_bits1(gb);
+if (m4ac->frame_length_short && m4ac->sbr == 1) {
+ avpriv_report_missing_feature(avctx, "SBR with 960 frame length");
+ if (ac) ac->warned_960_sbr = 1;
+ m4ac->sbr = 0;
+ m4ac->ps = 0;
+}
+#endif
if (get_bits1(gb)) // dependsOnCoreCoder
skip_bits(gb, 14); // coreCoderDelay
@@ -1126,6 +1136,12 @@ static av_cold void aac_static_table_init(void)
// window initialization
AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_long_1024), 4.0,
1024);
AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_short_128), 6.0, 128);
+#if !USE_FIXED
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_long_960), 4.0, 960);
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_short_120), 6.0, 120);
+AAC_RENAME(ff_sine_window_init)(AAC_RENAME(ff_sine_960), 960);
+AAC_RENAME(ff_sine_window_init)(AAC_RENAME(ff_sine_120), 120);
+#endif
AAC_RENAME(ff_init_ff_sine_windows)(10);
AAC_RENAME(ff_init_ff_sine_windows)( 9);
AAC_RENAME(ff_init_ff_sine_windows)( 7);
@@ -1211,9 +1227,15 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
AAC_RENAME_32(ff_mdct_init)(&ac->mdct_small, 8, 1, 1.0 / RANGE15(128.0));
AAC_RENAME_32(ff_mdct_init)(&ac->mdct_ltp, 11, 0, RANGE15(-2.0));
#if !USE_FIXED
+ret = ff_mdct15_init(&ac->mdct120, 1, 3, 1.0f/(16*1024*120*2));
+if (ret < 0)
+return ret;
ret = ff_mdct15_init(&ac->mdct480, 1, 5, 1.0f/(16*1024*960));
if (ret < 0)
return ret;
+ret = ff_mdct15_init(&ac->mdct960, 1, 6, 1.0f/(16*1024*960*2));
+if (ret < 0)
+return ret;
#endif
return 0;
@@ -1314,8 +1336,13 @@ static int decode_ics_info(AACContext *ac,
IndividualChannelStream *ics,
}
}
ics->num_windows = 8;
-ics->swb_offset=ff_swb_offset_128[sampling_index];
-ics->num_swb = ff_aac_num_swb_128[sampling_index];
+if (m4ac->frame_length_short) {
+ics->swb_offset= ff_swb_offset_120[sampling_index];
+ics->num_swb = ff_aac_num_swb_120[sampling_index];
+} else {
+ics->swb_offset= ff_swb_offset_128[sampling_index];
+ics->num_swb = ff_aac_num_swb_128[sampling_index];
+}
ics->tns_max_bands = ff_tns_max_bands_128[sampling_index];
ics->predictor_present = 0;
} else {
@@ -1334,8 +1361,13 @@ static int decode_ics_info(AACContext *ac,
IndividualChannelStream *ics,
if (!ics->num_swb || !ics->swb_offset)
return AVERROR_BUG;
} else {
-ics->swb_offset=ff_swb_offset_1024[sampling_index];
-ics->num_swb = ff_aac_num_swb_1024[sampling_index];
+if (m4ac->frame_length_short) {
+ics->num_swb= ff_aac_num_swb_960[sampling_index];
+ics->swb_offset = ff_swb_offset_960[sampling_index];
+} else {
+ics->num_swb= ff_aac_num_swb_1024[sampling_index];
+ics->swb_
Re: [FFmpeg-devel] [PATCH 2/2] fate: add test vector aac-al04sf_48
On Tue, Aug 22, 2017 at 3:23 PM, Michael Niedermayer wrote: > On Mon, Aug 21, 2017 at 04:22:15PM -0700, Alex Converse wrote: >> --- >> tests/fate/aac.mak | 4 >> 1 file changed, 4 insertions(+) > > where can i find the files to test & upload to fate samples ? > The files are part of the official conformance suite and can be found at: ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al04sf_48.mp4 and ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/referencesWav/al04sf_48.wav ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat: Handle AV_CODEC_CAP_CHANNEL_CONF when first frame fails to decode
Fixes probing the stream from ticket 6398.
Noticed by James Almer.
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 23865c88c4..68ba8aa85b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2997,7 +2997,7 @@ static int try_decode_frame(AVFormatContext *s, AVStream
*st, AVPacket *avpkt,
while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
ret >= 0 &&
(!has_codec_parameters(st, NULL) ||
!has_decode_delay_been_guessed(st) ||
-(!st->codec_info_nb_frames &&
+(!st->nb_decoded_frames &&
(avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF {
got_picture = 0;
if (avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
--
2.13.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/flvdec: Set need_context_update when setting the initial extradata
Fixes ticket 6398. Debugged with the help of James Almer and Hendrik Leppkes. --- libavformat/flvdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c index 94c9e28334..2e70352c53 100644 --- a/libavformat/flvdec.c +++ b/libavformat/flvdec.c @@ -754,6 +754,7 @@ static int flv_get_extradata(AVFormatContext *s, AVStream *st, int size) av_freep(&st->codecpar->extradata); if (ff_get_extradata(s, st->codecpar, s->pb, size) < 0) return AVERROR(ENOMEM); +st->internal->need_context_update = 1; return 0; } -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
