Re: [FFmpeg-devel] [PATCH v5 1/9] fftools/qsv: add device initialization from string

[Zhong Li]

 于2020年5月19日周二 上午3:26写道：
>
> From: Artem Galin 
>
> Signed-off-by: Artem Galin 
> ---
>  fftools/ffmpeg_opt.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 60bb437ea7..83f1b53e9d 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -558,7 +558,11 @@ static int opt_init_hw_device(void *optctx, const char 
> *opt, const char *arg)
>  printf("\n");
>  exit_program(0);
>  } else {
> -return hw_device_init_from_string(arg, NULL);
> +int err;
> +if (!arg)
> +return AVERROR(ENOMEM);

There is no memory allocation, so return EINVAL is better IMHO.

> +err = hw_device_init_from_string(arg, NULL);
> +return err;
>  }
>  }

The rest look good, but prefer to remove "qsv" in the patch subject
since this is not a "qsv" limited change .
___
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 v6 2/9] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair

[Zhong Li]

 于2020年5月19日周二 上午4:31写道：
>
> From: Artem Galin 
>
> Adding DX11 relevant device type checks and adjusting callbacks with
> proper MediaSDK pair type support.
>
> Extending structure for proper MediaSDK pair type support.
>
> Signed-off-by: Artem Galin 
> ---
>  libavcodec/qsv.c  | 53 ++-
>  libavcodec/qsv_internal.h |  2 +-
>  2 files changed, 37 insertions(+), 18 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 17720070f1..ef57b92a9f 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -36,6 +36,8 @@
>  #include "avcodec.h"
>  #include "qsv_internal.h"
>
> +#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
> +
>  #if QSV_VERSION_ATLEAST(1, 12)
>  #include "mfx/mfxvp8.h"
>  #endif
> @@ -239,7 +241,9 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx, 
> QSVFrame *frame)
>  int i;
>  for (i = 0; i < ctx->nb_mids; i++) {
>  QSVMid *mid = &ctx->mids[i];
> -if (mid->handle == frame->surface.Data.MemId)
> +mfxHDLPair *pair = (mfxHDLPair*)frame->surface.Data.MemId;
> +if ((mid->handle_pair.first == pair->first) &&
> +(mid->handle_pair.second == pair->second))
>  return i;
>  }
>  return AVERROR_BUG;
> @@ -380,7 +384,11 @@ static int ff_qsv_set_display_handle(AVCodecContext 
> *avctx, QSVSession *qs)
>  int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
>   const char *load_plugins, int gpu_copy)
>  {
> +#if CONFIG_D3D11VA
> +mfxIMPL  impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
> +#else
>  mfxIMPL  impl = MFX_IMPL_AUTO_ANY;
> +#endif
>  mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
>  mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
>
> @@ -469,7 +477,7 @@ static AVBufferRef *qsv_create_mids(AVBufferRef 
> *hw_frames_ref)
>
>  for (i = 0; i < nb_surfaces; i++) {
>  QSVMid *mid = &mids[i];
> -mid->handle= frames_hwctx->surfaces[i].Data.MemId;
> +mid->handle_pair   = 
> *((mfxHDLPair*)frames_hwctx->surfaces[i].Data.MemId);
>  mid->hw_frames_ref = hw_frames_ref1;
>  }
>
> @@ -646,7 +654,7 @@ static mfxStatus qsv_frame_lock(mfxHDL pthis, mfxMemId 
> mid, mfxFrameData *ptr)
>  goto fail;
>
>  qsv_mid->surf.Info = hw_frames_hwctx->surfaces[0].Info;
> -qsv_mid->surf.Data.MemId = qsv_mid->handle;
> +qsv_mid->surf.Data.MemId = &qsv_mid->handle_pair;
>
>  /* map the data to the system memory */
>  ret = av_hwframe_map(qsv_mid->locked_frame, qsv_mid->hw_frame,
> @@ -679,7 +687,13 @@ static mfxStatus qsv_frame_unlock(mfxHDL pthis, mfxMemId 
> mid, mfxFrameData *ptr)
>  static mfxStatus qsv_frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl)
>  {
>  QSVMid *qsv_mid = (QSVMid*)mid;
> -*hdl = qsv_mid->handle;
> +mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
> +mfxHDLPair *pair_src = (mfxHDLPair*)&qsv_mid->handle_pair;
> +
> +pair_dst->first = pair_src->first;
> +
> +if (pair_src->second != (mfxMemId)MFX_INFINITE)
> +pair_dst->second = pair_src->second;
>  return MFX_ERR_NONE;
>  }
>
> @@ -687,24 +701,19 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, 
> mfxSession *psession,
> AVBufferRef *device_ref, const char 
> *load_plugins,
> int gpu_copy)
>  {
> -static const mfxHandleType handle_types[] = {
> -MFX_HANDLE_VA_DISPLAY,
> -MFX_HANDLE_D3D9_DEVICE_MANAGER,
> -MFX_HANDLE_D3D11_DEVICE,
> -};
>  AVHWDeviceContext*device_ctx = (AVHWDeviceContext*)device_ref->data;
>  AVQSVDeviceContext *device_hwctx = device_ctx->hwctx;
>  mfxSessionparent_session = device_hwctx->session;
>  mfxInitParaminit_par = { MFX_IMPL_AUTO_ANY };
>  mfxHDLhandle = NULL;
> +int  hw_handle_supported = 0;
>
>  mfxSessionsession;
>  mfxVersionver;
>  mfxIMPL   impl;
>  mfxHandleType handle_type;
>  mfxStatus err;
> -
> -int i, ret;
> +int ret;
>
>  err = MFXQueryIMPL(parent_session, &impl);
>  if (err == MFX_ERR_NONE)
> @@ -713,13 +722,23 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, 
> mfxSession *psession,
>  return ff_qsv_print_error(avctx, err,
>"Error querying the session attributes");
>
> -for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
> -err = MFXVideoCORE_GetHandle(parent_session, handle_types[i], 
> &handle);
> -if (err == MFX_ERR_NONE) {
> -handle_type = handle_types[i];
> -break;
> +if (MFX_IMPL_VIA_VAAPI == MFX_IMPL_VIA_MASK(impl)) {
> +handle_type = MFX_HANDLE_VA_DISPLAY;
> +hw_handle_supported = 1;
> +} else if (MFX_IMPL_VIA_D3D11 == MFX_IMPL_VIA_MASK(impl)) {
> +handle_type = MFX_HANDLE_D3D11_DEVICE;
> +hw_handle_

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Emanuele Oriani]

Hi Marton,

Thanks very much for the feedback; below answers to your points - let me 
know further feedback if any.


> And sorry, I cannot say how useful this would be, maybe now is the time
> for people to speak up if somebody is particularly against adding this
> for any reason.

I haven't been able to capture video-games/3d apps running in full 
screen with x11grab, and when running in windowed mode the capture was 
sub optimal in terms of quality (lost frames/choppy/etc etc).
Unless we have better solutions with ffmpeg/libav* (which I'm not aware 
of :) this xcompgrab would target such audience (smooth capture alas 
more CPU usage).
But again, if there's already a better capture, then this has been an 
academic exercise :)


> - Is there a way to keep the captured textures as an
> OpenGL/VAAPI/NVenc/Vulkan object, so the frames can work as some kind of
> hwaccel frames? Can this improve performance?

I think there would be. I would need to find more in terms of 
documentation for both hwaccel frames structures/management.

Please feel free to point me to guides/code/samples etc etc.

Wouldn't a hwaccel frame imply no choice for encoder (as in now we get a 
true uncompressed RGBA buffer which can be encoded as we see fit - if we 
were to get hwacell wouldn't we be forced to use the encoded data as is)?


> - What can be the reason between the quality/smoothness difference of
> x11grab and the Compositor capturer?

My suspicion is that OpenGL has access to the buffered data on the 
videocard itself, hence able to get smooth frames.


Related to both these questions, I've asked the same on Stackoverflow:

https://stackoverflow.com/questions/61613441/is-there-a-better-more-efficient-way-to-capture-composite-x-windows-in-linux

Unfortunately no one has been able to give me an answer (I did set a 
bounty for it) so I posted my own understanding.


> As for the code, I only took a quick look, here are some comments
>
> - probably GCC atomics should be replaced by  atomic
> functions.

Done.

> - Unless there is a reason, I think av_malloc/av_free is preferred for
> memory alloc functions.

Done.

> - Maybe some openGL glue can be shared with libavdevice/opengl_enc.c?
> Take a look, I am not sure, because that was implemented with SDL and
> cross platform capabilities in mind, but since your capture device is
> only for linux (or not?), then maybe it makes more sense to keep it
> separete?

This is indeed a very specific implementation for Linux, I would agree 
that perhaps not sure this makes sense to use shared OpenGL functions?


> - Can the Xlib functions replaced with xcb? I kind of think that would
> be preferable if it is a sensible thing to do.

I understand where you're coming from and it makes sense to give it a 
shot - my only fear is that we may need to use specific Xlib functions 
anyway.

But let me give it a try and see where we go.

On 18/05/2020 20:11, Marton Balint wrote:



On Mon, 18 May 2020, Emanuele Oriani wrote:


Hi Marton/ffmpeg devs/all,

Haven't seen any response to the proposed XComposite windows capture.

As per below the reasoning for adding this code to libav*/ffmpeg is 
that seems to be better in quality than x11grab, although it uses more 
CPU in its current implementation (uses OpenGL and PBO - optional - to 
fetch XComposite windows).


Please let me know if it's still of interest and/or you have further 
technical feedback.

I've posted some performance tests in the thread below.

Here links of two captures (one with x11grab, the other with 
xcompgrab) and the sources:


https://send.firefox.com/download/df859689f4cc6429/#EN6w9upyIMHqO7n_1hMTaQ 


https://github.com/Emanem/replayer/blob/master/src/xcompgrab.c

Thanks in advance for your time and feedback,


Thanks. I am not familiar with the details of opengl/compositing 
capturing, but here are a few questions coming into my mind. Not only 
for you, but for other developers as well:


- Is there a way to keep the captured textures as an 
OpenGL/VAAPI/NVenc/Vulkan object, so the frames can work as some kind of 
hwaccel frames? Can this improve performance?


- What can be the reason between the quality/smoothness difference of 
x11grab and the Compositor capturer?


As for the code, I only took a quick look, here are some comments

- probably GCC atomics should be replaced by  atomic 
functions.


- Unless there is a reason, I think av_malloc/av_free is preferred for 
memory alloc functions.


- Maybe some openGL glue can be shared with libavdevice/opengl_enc.c? 
Take a look, I am not sure, because that was implemented with SDL and 
cross platform capabilities in mind, but since your capture device is 
only for linux (or not?), then maybe it makes more sense to keep it 
separete?


- Can the Xlib functions replaced with xcb? I kind of think that would 
be preferable if it is a sensible thing to do.


And sorry, I cannot say how useful this would be, maybe now is the time 
for people to speak up if somebody is particularly

Re: [FFmpeg-devel] [PATCH v5 3/9] libavutil/hwcontext_d3d11va: adding the vendor option to d3d11va device creation

[Zhong Li]

 于2020年5月19日周二 上午2:56写道：
>
> From: Artem Galin 
>
> Example: --init_hw_device d3d11va:,vendor=0x8086
>
> qsv_device option is still works and has higher priority over vendor
> option.

Would be nice if you can document it in ffmpeg.texi.

> Signed-off-by: Artem Galin  ---
>  libavutil/hwcontext_d3d11va.c | 39 +--
>  1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> index c8ae58f908..b644a0a4fd 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -517,9 +517,12 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
> const char *device,
>  AVD3D11VADeviceContext *device_hwctx = ctx->hwctx;
>
>  HRESULT hr;
> +AVDictionaryEntry *e;
>  IDXGIAdapter   *pAdapter = NULL;
>  ID3D10Multithread  *pMultithread;
>  UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
> +int adapter = -1;
> +long int vendor_id = -1;

if you want 64bits, long long int or int64_t  can make sure that.

>  int is_debug   = !!av_dict_get(opts, "debug", NULL, 0);
>  int ret;
>
> @@ -539,13 +542,45 @@ static int d3d11va_device_create(AVHWDeviceContext 
> *ctx, const char *device,
>  return AVERROR_UNKNOWN;
>  }
>
> +e = av_dict_get(opts, "vendor", NULL, 0);
> +if (e) {
> +vendor_id = strtol(e->value, NULL, 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 v5] libavformat/flacdec: Workaround for truncated metadata picture size

[Mattias Wadman]

Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.

This workaround is only for flac files and not ogg files with flac
METADATA_BLOCK_PICTURE comments and it can be disabled with strict level
above normal. Currently there is a 500MB limit on truncate size to protect
from large memory allocations.

The truncation bug in lavf flacenc was fixed in 
e447a4d112bcfee10126c54eb4481fa8712957c8
but based on existing broken files other unknown flac muxers seems to truncate 
also.
Before the fix a broken flac file for reproduction could be generated with:
ffmpeg -f lavfi -i sine -f lavfi -i color=red:size=2400x2400 -map 0:0 -map 1:0 
-c:v:0 bmp -disposition:1 attached_pic -t 1 test.flac

Fixes ticket 6333
---
 libavformat/flac_picture.c   | 47 ++--
 libavformat/flac_picture.h   |  2 +-
 libavformat/flacdec.c|  2 +-
 libavformat/oggparsevorbis.c |  2 +-
 4 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c
index 81ddf80465..53e24b28b7 100644
--- a/libavformat/flac_picture.c
+++ b/libavformat/flac_picture.c
@@ -27,7 +27,9 @@
 #include "id3v2.h"
 #include "internal.h"
 
-int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size)
+#define MAX_TRUNC_PICTURE_SIZE (500 * 1024 * 1024)
+
+int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size, int 
truncate_workaround)
 {
 const CodecMime *mime = ff_id3v2_mime_tags;
 enum AVCodecID id = AV_CODEC_ID_NONE;
@@ -36,7 +38,8 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, 
int buf_size)
 GetByteContext g;
 AVStream *st;
 int width, height, ret = 0;
-unsigned int len, type;
+unsigned int type;
+uint32_t len, left, trunclen = 0;
 
 if (buf_size < 34) {
 av_log(s, AV_LOG_ERROR, "Attached picture metadata block too short\n");
@@ -114,16 +117,44 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t 
*buf, int buf_size)
 
 /* picture data */
 len = bytestream2_get_be32u(&g);
-if (len <= 0 || len > bytestream2_get_bytes_left(&g)) {
-av_log(s, AV_LOG_ERROR, "Attached picture metadata block too short\n");
-if (s->error_recognition & AV_EF_EXPLODE)
-ret = AVERROR_INVALIDDATA;
-goto fail;
+
+left = bytestream2_get_bytes_left(&g);
+if (len <= 0 || len > left) {
+if (len > MAX_TRUNC_PICTURE_SIZE || len >= INT_MAX - 
AV_INPUT_BUFFER_PADDING_SIZE) {
+av_log(s, AV_LOG_ERROR, "Attached picture metadata block too big 
%u\n", len);
+if (s->error_recognition & AV_EF_EXPLODE)
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+// Workaround bug for flac muxers that writs truncated metadata 
picture block size if
+// the picture size do not fit in 24 bits. lavf flacenc used to have 
the issue and based
+// on existing broken files other unknown flac muxers seems to 
truncate also.
+if (truncate_workaround &&
+s->strict_std_compliance <= FF_COMPLIANCE_NORMAL &&
+len > left && (len & 0xff) == left) {
+av_log(s, AV_LOG_INFO, "Correcting truncated metadata picture size 
from %u to %u\n", left, len);
+trunclen = len - left;
+} else {
+av_log(s, AV_LOG_ERROR, "Attached picture metadata block too 
short\n");
+if (s->error_recognition & AV_EF_EXPLODE)
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 }
 if (!(data = av_buffer_alloc(len + AV_INPUT_BUFFER_PADDING_SIZE))) {
 RETURN_ERROR(AVERROR(ENOMEM));
 }
-bytestream2_get_bufferu(&g, data->data, len);
+
+if (trunclen == 0) {
+bytestream2_get_bufferu(&g, data->data, len);
+} else {
+// If truncation was detected copy all data from block and read 
missing bytes
+// not included in the block size
+bytestream2_get_bufferu(&g, data->data, left);
+if (avio_read(s->pb, data->data + len - trunclen, trunclen) < trunclen)
+RETURN_ERROR(AVERROR_INVALIDDATA);
+}
 memset(data->data + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 
 if (AV_RB64(data->data) == PNGSIG)
diff --git a/libavformat/flac_picture.h b/libavformat/flac_picture.h
index 4374b6f4f6..61fd0c8806 100644
--- a/libavformat/flac_picture.h
+++ b/libavformat/flac_picture.h
@@ -26,6 +26,6 @@
 
 #define RETURN_ERROR(code) do { ret = (code); goto fail; } while (0)
 
-int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size);
+int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size, int 
truncate_workaround);
 
 #endif /* AVFORMAT_FLAC_PICTURE_H */
diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
index cb516fb1f3..79c05f14bf 100644
--- a/libavformat/

Re: [FFmpeg-devel] [PATCH] drawtext: Allow textfile path to be expanded per frame

[Manolis Stamatogiannakis]

Hi David,

Not a full review, but a minor point that popped in mind.

It is common to pad serially numbered files with 0. E.g. if you have <1000
files, the 9th file will be named file009.txt.
Is this case handled by the expansion? Or is it assumed that the text file
numbers are not zero-padded?

If it the latter is the case, it would be good to make that explicit in the
documentation.
Of course, accounting for padding would be better, but this may not be
straightforward without adding more code.

Regards,
Manolis

On Tue, 19 May 2020 at 06:10, David Andreoletti 
wrote:

> Hi ffmpeg maintainers / community,
> New contributor here. The patch [0] for the drawtext filter was submitted
> some
> time ago now but has been reviewed yet. It seems there is no official
> maintainer
> for this filter (as per the MAINTAINERS file)
> What should be done to have it reviewed ?
>
> [0]
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
>
> Regards,
> David Andreoletti
>
>
>
___
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] [WIP] XComposite window capture demuxer (Linux)

[Emanuele Oriani]

Hi Lynne,

Thanks for the feedback.
Some more discussion points below.

> There already is a zero-overhead capture on linux - kmsgrab. It works 
on AMD and Intel.


Does it work on Nvidia too? Does it have smooth capture?
Does it work for 3d applications?

>> Wouldn't a hwaccel frame imply no choice for encoder (as in now we 
get a true uncompressed RGBA buffer which can be encoded as we see fit - 
if we were to get hwacell wouldn't we be forced to use the encoded data 
as is)?

>>
>
> No.

My point was around if you use say NVenc to compress frames, you 
wouldn't want to decompress-recompress to avoid artefacts?


> I wouldn't be surprised if the xlib code has some PTS issues and 
schedules downloading a frame late.


I'm far from being an expert, but I would be surprised if that had 
issues considering it's the main Linux screen capture we have?
The xcb calls to grab a frame are quite simple/straightforward (both shm 
and non shm versions).


> Maybe its worth fixing that instead of adding a yet another x11 capture?

This is a xcomposite capture, I would say it's different than a x11 raw 
capture.


> I'm against any OpenGL code being ran anywhere in our libraries since 
it will disturb OpenGL's global
> state, breaking any OpenGL users of our libraries (there are quite a 
lot). Yes, there are also people who

> want to screencapture and use OpenGL. I'm one.
> This is also why we don't have OpenGL filtering in libavfilter.
> So that's a big NAK for me.

Fair enough - Understood why it would be a NAK from you.
Would there be a way to mark this as experimental?

Out of curiosity if I was proposing/using the native NVidia proprietary 
library for screen capture (linked at runtime dynamically), would that 
be more acceptable in terms of conflicts (I wouldn't like it because it 
wouldn't support AMD/Intel based hardware)?


> As-is now, I don't see much value in this patch.

I wrote this because I wanted to capture 3d apps at 60 FPS with high 
quality without having to drop frames.
If there is a better way with ffmpeg/libav*, please feel free to suggest 
- otherwise currently folks would be forced to use OBS and not use 
ffmpeg/libav* based solutions.


The video games segment under Linux is expanding, would ffmpeg/libav* 
have the right infra/codecs to cater for it?
Can we capture true 60 FPS of a 3d app today? Do we have native 
Vulkan/OpenGL capturers?


If yes then I would agree with you (no point in having this patch), 
otherwise there is value in it.


On 19/05/2020 09:33, Lynne wrote:

May 19, 2020, 09:23 by e...@fastwebnet.it:


Hi Marton,

Thanks very much for the feedback; below answers to your points - let me know 
further feedback if any.


And sorry, I cannot say how useful this would be, maybe now is the time
for people to speak up if somebody is particularly against adding this
for any reason.



I haven't been able to capture video-games/3d apps running in full screen with 
x11grab, and when running in windowed mode the capture was sub optimal in terms 
of quality (lost frames/choppy/etc etc).
Unless we have better solutions with ffmpeg/libav* (which I'm not aware of :) 
this xcompgrab would target such audience (smooth capture alas more CPU usage).
But again, if there's already a better capture, then this has been an academic 
exercise :)



There already is a zero-overhead capture on linux - kmsgrab. It works on AMD 
and Intel.




- Is there a way to keep the captured textures as an
OpenGL/VAAPI/NVenc/Vulkan object, so the frames can work as some kind of
hwaccel frames? Can this improve performance?



I think there would be. I would need to find more in terms of documentation for 
both hwaccel frames structures/management.
Please feel free to point me to guides/code/samples etc etc.



Uploading to hardware frames is something uses can do themselves already. 
Unless there is a native
interop, I don't see how doing the upload in the avdevice helps.




Wouldn't a hwaccel frame imply no choice for encoder (as in now we get a true 
uncompressed RGBA buffer which can be encoded as we see fit - if we were to get 
hwacell wouldn't we be forced to use the encoded data as is)?



No.




- What can be the reason between the quality/smoothness difference of
x11grab and the Compositor capturer?



My suspicion is that OpenGL has access to the buffered data on the videocard 
itself, hence able to get smooth frames.

Related to both these questions, I've asked the same on Stackoverflow:

https://stackoverflow.com/questions/61613441/is-there-a-better-more-efficient-way-to-capture-composite-x-windows-in-linux

Unfortunately no one has been able to give me an answer (I did set a bounty for 
it) so I posted my own understanding.



I wouldn't be surprised if the xlib code has some PTS issues and schedules 
downloading a frame late.
Maybe its worth fixing that instead of adding a yet another x11 capture?




- Maybe some openGL glue can be shared with libavdevice/opengl_enc.c?
Take a look, I am not sure, 

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Lynne (12020-05-19):
> There already is a zero-overhead capture on linux - kmsgrab. It works
> on AMD and Intel.

The doc says:

Requires either DRM master or CAP_SYS_ADMIN to run.

Does it work for a normal user on a desktop distribution freshly
installed, without configuration?

(I should test, but all my boxes are very far from the default
configuration.)

> I'm against any OpenGL code being ran anywhere in our libraries since
> it will disturb OpenGL's global state, breaking any OpenGL users of
> our libraries (there are quite a lot). Yes, there are also people who
> want to screencapture and use OpenGL. I'm one. This is also why we
> don't have OpenGL filtering in libavfilter. So that's a big NAK for
> me.

As long as the devices and filters using OpenGL are clearly marked as
such, and that the consequences of using the are documented, I see no
reason to refuse them. Let us trust users. This is me NAKing your NAK.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

[lance . lmwang]

On Sun, May 17, 2020 at 02:41:18PM +0200, Marton Balint wrote:
> 
> 
> On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:
> 
> > On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
> > > 
> > > 
> > > On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> > > 
> > > > On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:
> > > > > > > > > On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> > > > > > > I suggest you capture the input, so this issue can be
> > > properly reproduced
> > > > > and share it. It may even make sense to create a fate test from it.
> > > > > Have tried, the issue can't be reproduced by capture offset
> > > file. I guess it's
> > > > caused by live stream seek isn't same as off line file.
> > > 
> > > If that is the case then you can override the seekability of files by 
> > > using
> > > -seekable 0 option. Alternatively you might find some other means to 
> > > replay
> > > the recorded ts, anyhow this should be reproduced, because I have a 
> > > feeling
> > > we don't have the whole picture of what is going on.
> > 
> > I have spend more time to investigate it, I have try to capture a pcap file 
> > to
> > reproduce the issue, with tcprelay, it can be reproduced every time, however
> > if export to ts, I failed to reproduce it.
> 
> Great. Can you share the pcap file? You can may send it to me privately if
> you don't want it to be made public.

I have send it the sample to you privately, if you haven't got it, please let me
know.

> 
> [...]
> 
> > Thanks for the advices, I spend more time to investigate and  try to fix it 
> > in the
> > resync logic, with more debug info, I notice the old reanalyze() has one 
> > drawback,
> > the pos isn't one of 188/192/204, so it'll cause the stat will reset all 
> > stats
> > ahead of one of stats[i] which cause normal 188 failed to detected anymore. 
> > I
> > think it's better to return if pos isn't one of 188/192/204, it'll fix my 
> > issue
> > by testing, please help to review whether it's reasonable or not.
> 
> I am not sure yet.

You can tried with my pcap sample, please update the pcap mac info and use
tcpreplay to get the udp stream.

> 
> > the log which explain why it failed to detect back to 188:
> > 
> > [mpegts @ 0x3ef0180] reanalyze: stat: 1, stat[0]: 1, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 2, stat[0]: 2, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 3, stat[0]: 3, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 4, stat[0]: 4, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 5, stat[0]: 4, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 564
> > [mpegts @ 0x3ef0180] reanalyze: stat: 6, stat[0]: 5, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 7, stat[0]: 6, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 8, stat[0]: 6, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 376
> > [mpegts @ 0x3ef0180] reanalyze: stat: 9, stat[0]: 7, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 188
> > [mpegts @ 0x3ef0180] reanalyze: stat: 10, stat[0]: 7, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 474
> > [mpegts @ 0x3ef0180] reanalyze: stat: 0, stat[0]: 0, stat[1]: 0, stat[2]: 
> > 0, raw_packet_size: 192, pos: 752
> 
> pos as a multiple of 188 and not 188 is very suspicious, and it might be
> because pos47_full is only updated if the packet has a payload. Can you try
> the attached patch and see if it makes a difference?

Sorry, I'm miss it before.  I have tried with the patch, you can reproduce with
my sample with offline file, below is the log:

[mpegts @ 0x49a9940] reanalyze: stat: 4, stat[0]: 0, stat[1]: 1, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 5, stat[0]: 0, stat[1]: 2, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 6, stat[0]: 0, stat[1]: 3, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 7, stat[0]: 0, stat[1]: 3, stat[2]: 0, 
pos: 240
[mpegts @ 0x49a9940] reanalyze: stat: 8, stat[0]: 0, stat[1]: 3, stat[2]: 0, 
pos: 195
[mpegts @ 0x49a9940] reanalyze: stat: 9, stat[0]: 0, stat[1]: 3, stat[2]: 0, 
pos: 195
[mpegts @ 0x49a9940] reanalyze: stat: 10, stat[0]: 0, stat[1]: 3, stat[2]: 0, 
pos: 298
[mpegts @ 0x49a9940] Packet corrupt (stream = 0, dts = 446069).
[mpegts @ 0x49a9940] reanalyze: stat: 11, stat[0]: 0, stat[1]: 4, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 1, stat[0]: 0, stat[1]: 1, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 2, stat[0]: 0, stat[1]: 2, stat[2]: 0, 
pos: 192
[mpegts @ 0x49a9940] reanalyze: stat: 3, stat[0]: 0, stat[1]: 2, stat[2]: 0, 
pos: 240
[mpegts @ 0x49a9940] reanalyze: stat: 4, stat[0]: 0, stat[1]: 2, stat[2]: 0, 
pos: 312


> 
> Thanks,
> Mart

Re: [FFmpeg-devel] [PATCH v5 0/4] adpcm_ima_ssi encoder + kvag muxer

[Zane van Iperen]

On Sat, 16 May 2020 11:53:27 +
"Zane van Iperen"  wrote:

> 
> Add support for encoding adpcm_ima_ssi and muxing to kvag.
> 
Ping.

Zane

___
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 2/5] checkasm/sw_scale: Fix stack-buffer-overflow

[Andreas Rheinhardt]

A buffer whose size is not a multiple of four has been initialized using
consecutive writes of 32bits. This results in a stack-buffer-overflow
reported by ASAN in the checkasm-sw_scale FATE-test.

Signed-off-by: Andreas Rheinhardt 
---
Instead of using FFALIGN one could also just remove the "- 1" if that's
preferred.

 tests/checkasm/sw_scale.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index 2680e47897..9efa2b4def 100644
--- a/tests/checkasm/sw_scale.c
+++ b/tests/checkasm/sw_scale.c
@@ -53,7 +53,7 @@ static void check_hscale(void)
 struct SwsContext *ctx;
 
 // padded
-LOCAL_ALIGNED_32(uint8_t, src, [SRC_PIXELS + MAX_FILTER_WIDTH - 1]);
+LOCAL_ALIGNED_32(uint8_t, src, [FFALIGN(SRC_PIXELS + MAX_FILTER_WIDTH - 1, 
4)]);
 LOCAL_ALIGNED_32(uint32_t, dst0, [SRC_PIXELS]);
 LOCAL_ALIGNED_32(uint32_t, dst1, [SRC_PIXELS]);
 
-- 
2.20.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 4/5] avformat/id3v2: Remove unnecessary indirection

[Andreas Rheinhardt]

ff_id3v2_parse_apic/chapters/priv/priv_dict all had a parameter
extra_meta of type ID3v2ExtraMeta ** as if the functions wanted to make
*extra_meta point to something else. But they don't, so just use an
ID3v2ExtraMeta *.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aacdec.c   |  2 +-
 libavformat/aiffdec.c  |  4 ++--
 libavformat/asfdec_f.c |  4 ++--
 libavformat/asfdec_o.c |  4 ++--
 libavformat/dsfdec.c   |  4 ++--
 libavformat/hls.c  |  8 
 libavformat/id3v2.c| 14 +++---
 libavformat/id3v2.h|  8 
 libavformat/iff.c  |  4 ++--
 libavformat/omadec.c   |  2 +-
 libavformat/utils.c|  6 +++---
 libavformat/wavdec.c   |  6 +++---
 12 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index ba3f5ccc6d..a0aa112a8a 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -146,7 +146,7 @@ static int handle_id3(AVFormatContext *s, AVPacket *pkt)
 
 ffio_init_context(&ioctx, pkt->data, pkt->size, 0, NULL, NULL, NULL, NULL);
 ff_id3v2_read_dict(&ioctx, &metadata, ID3v2_DEFAULT_MAGIC, 
&id3v2_extra_meta);
-if ((ret = ff_id3v2_parse_priv_dict(&metadata, &id3v2_extra_meta)) < 0)
+if ((ret = ff_id3v2_parse_priv_dict(&metadata, id3v2_extra_meta)) < 0)
 goto error;
 
 if (metadata) {
diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index cb2f1b60fb..c650e9074d 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -261,8 +261,8 @@ static int aiff_read_header(AVFormatContext *s)
 position = avio_tell(pb);
 ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, size);
 if (id3v2_extra_meta)
-if ((ret = ff_id3v2_parse_apic(s, &id3v2_extra_meta)) < 0 ||
-(ret = ff_id3v2_parse_chapters(s, &id3v2_extra_meta)) < 0) 
{
+if ((ret = ff_id3v2_parse_apic(s, id3v2_extra_meta)) < 0 ||
+(ret = ff_id3v2_parse_chapters(s, id3v2_extra_meta)) < 0) {
 ff_id3v2_free_extra_meta(&id3v2_extra_meta);
 return ret;
 }
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index f0cb353587..e9ddca7151 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -308,8 +308,8 @@ static void get_id3_tag(AVFormatContext *s, int len)
 
 ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
 if (id3v2_extra_meta) {
-ff_id3v2_parse_apic(s, &id3v2_extra_meta);
-ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
+ff_id3v2_parse_apic(s, id3v2_extra_meta);
+ff_id3v2_parse_chapters(s, id3v2_extra_meta);
 }
 ff_id3v2_free_extra_meta(&id3v2_extra_meta);
 }
diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index 7891b23445..1b10e47907 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -461,8 +461,8 @@ static void get_id3_tag(AVFormatContext *s, int len)
 
 ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, len);
 if (id3v2_extra_meta) {
-ff_id3v2_parse_apic(s, &id3v2_extra_meta);
-ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
+ff_id3v2_parse_apic(s, id3v2_extra_meta);
+ff_id3v2_parse_chapters(s, id3v2_extra_meta);
 }
 ff_id3v2_free_extra_meta(&id3v2_extra_meta);
 }
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index 52cddab2c8..c9740cf28f 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -56,8 +56,8 @@ static void read_id3(AVFormatContext *s, uint64_t id3pos)
 
 ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
 if (id3v2_extra_meta) {
-ff_id3v2_parse_apic(s, &id3v2_extra_meta);
-ff_id3v2_parse_chapters(s, &id3v2_extra_meta);
+ff_id3v2_parse_apic(s, id3v2_extra_meta);
+ff_id3v2_parse_chapters(s, id3v2_extra_meta);
 }
 ff_id3v2_free_extra_meta(&id3v2_extra_meta);
 }
diff --git a/libavformat/hls.c b/libavformat/hls.c
index d9e09013e6..89386ea1b7 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1070,12 +1070,12 @@ static void handle_id3(AVIOContext *pb, struct playlist 
*pls)
 
 /* get picture attachment and set text metadata */
 if (pls->ctx->nb_streams)
-ff_id3v2_parse_apic(pls->ctx, &extra_meta);
+ff_id3v2_parse_apic(pls->ctx, extra_meta);
 else
 /* demuxer not yet opened, defer picture attachment */
 pls->id3_deferred_extra = extra_meta;
 
-ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
+ff_id3v2_parse_priv_dict(&metadata, extra_meta);
 av_dict_copy(&pls->ctx->metadata, metadata, 0);
 pls->id3_initial = metadata;
 
@@ -1965,9 +1965,9 @@ static int hls_read_header(AVFormatContext *s)
 goto fail;
 
 if (pls->id3_deferred_extra && pls->ctx->nb_streams == 1) {
-ff_id3v2_parse_apic(pls->ctx, &pls->id3_deferred_extra);
+ff_id3v2_parse_apic(pls->ctx, pls->id

[FFmpeg-devel] [PATCH 5/5] avformat/hls: Remove redundant resetting of pointer

[Andreas Rheinhardt]

ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can
already reset the pointer.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/hls.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 89386ea1b7..3e35d157ad 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1969,7 +1969,6 @@ static int hls_read_header(AVFormatContext *s)
 avformat_queue_attached_pictures(pls->ctx);
 ff_id3v2_parse_priv(pls->ctx, pls->id3_deferred_extra);
 ff_id3v2_free_extra_meta(&pls->id3_deferred_extra);
-pls->id3_deferred_extra = NULL;
 }
 
 if (pls->is_id3_timestamped == -1)
-- 
2.20.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 1/5] avformat/aiffenc: Don't forget chapters

[Andreas Rheinhardt]

If the write_id3v2 option is set, the aiff muxer would write id3v2 tags
if there is global metadata or if there are attached pics to write.
Chapters are ignored in this check that precedes writing id3v2 tags.
Yet 47ac344970f1d6ef149c4b8a883b68cdb15112c2 added support for writing
chapters as id3v2 tags, so one should check for the existence of chapters,
too; otherwise the chapters would only be written in case there is
global metadata or an attached pic.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aiffenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/aiffenc.c b/libavformat/aiffenc.c
index 0145596bec..88c45df334 100644
--- a/libavformat/aiffenc.c
+++ b/libavformat/aiffenc.c
@@ -49,7 +49,7 @@ static int put_id3v2_tags(AVFormatContext *s, 
AIFFOutputContext *aiff)
 AVIOContext *pb = s->pb;
 AVPacketList *pict_list = aiff->pict_list;
 
-if (!s->metadata && !aiff->pict_list)
+if (!s->metadata && !s->nb_chapters && !aiff->pict_list)
 return 0;
 
 avio_wl32(pb, MKTAG('I', 'D', '3', ' '));
-- 
2.20.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 3/5] avformat/id3v2: Avoid allocations for ID3v2ExtraMeta

[Andreas Rheinhardt]

Up until now, the ID3v2ExtraMeta structure (which is used when parsing
ID3v2 tags containing attached pictures, chapters etc.) contained a
pointer to separately allocated data that depended on the type of the
tag. Yet the difference of the sizes of the largest and the smallest of
these structures is fairly small, so that it is better to simply include
a union of all the possible types of tag-dependent structures in
ID3v2ExtraMeta. This commit implements this.

Signed-off-by: Andreas Rheinhardt 
---
If only one were allowed to use anonymous unions!

 libavformat/hls.c|  4 ++--
 libavformat/id3v2.c  | 50 
 libavformat/id3v2.h  | 17 +--
 libavformat/omadec.c | 13 ++--
 4 files changed, 37 insertions(+), 47 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index fc45719d1c..d9e09013e6 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1004,7 +1004,7 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
 ff_id3v2_read_dict(pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
 for (meta = *extra_meta; meta; meta = meta->next) {
 if (!strcmp(meta->tag, "PRIV")) {
-ID3v2ExtraMetaPRIV *priv = meta->data;
+ID3v2ExtraMetaPRIV *priv = &meta->data.priv;
 if (priv->datasize == 8 && !strcmp(priv->owner, 
id3_priv_owner_ts)) {
 /* 33-bit MPEG timestamp */
 int64_t ts = AV_RB64(priv->data);
@@ -1015,7 +1015,7 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
 av_log(s, AV_LOG_ERROR, "Invalid HLS ID3 audio timestamp 
%"PRId64"\n", ts);
 }
 } else if (!strcmp(meta->tag, "APIC") && apic)
-*apic = meta->data;
+*apic = &meta->data.apic;
 }
 }
 
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index abe073dcc1..2ba5c3857d 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -225,7 +225,6 @@ static void free_geobtag(void *obj)
 av_freep(&geob->file_name);
 av_freep(&geob->description);
 av_freep(&geob->data);
-av_free(geob);
 }
 
 /**
@@ -459,20 +458,15 @@ static void read_geobtag(AVFormatContext *s, AVIOContext 
*pb, int taglen,
 if (taglen < 1)
 return;
 
-geob_data = av_mallocz(sizeof(ID3v2ExtraMetaGEOB));
-if (!geob_data) {
-av_log(s, AV_LOG_ERROR, "Failed to alloc %"SIZE_SPECIFIER" bytes\n",
-   sizeof(ID3v2ExtraMetaGEOB));
-return;
-}
-
 new_extra = av_mallocz(sizeof(ID3v2ExtraMeta));
 if (!new_extra) {
 av_log(s, AV_LOG_ERROR, "Failed to alloc %"SIZE_SPECIFIER" bytes\n",
sizeof(ID3v2ExtraMeta));
-goto fail;
+return;
 }
 
+geob_data = &new_extra->data.geob;
+
 /* read encoding type byte */
 encoding = avio_r8(pb);
 taglen--;
@@ -511,7 +505,6 @@ static void read_geobtag(AVFormatContext *s, AVIOContext 
*pb, int taglen,
 
 /* add data to the list */
 new_extra->tag  = "GEOB";
-new_extra->data = geob_data;
 new_extra->next = *extra_meta;
 *extra_meta = new_extra;
 
@@ -577,7 +570,6 @@ static void free_apic(void *obj)
 ID3v2ExtraMetaAPIC *apic = obj;
 av_buffer_unref(&apic->buf);
 av_freep(&apic->description);
-av_freep(&apic);
 }
 
 static void rstrip_spaces(char *buf)
@@ -603,10 +595,11 @@ static void read_apic(AVFormatContext *s, AVIOContext 
*pb, int taglen,
 goto fail;
 
 new_extra = av_mallocz(sizeof(*new_extra));
-apic  = av_mallocz(sizeof(*apic));
-if (!new_extra || !apic)
+if (!new_extra)
 goto fail;
 
+apic = &new_extra->data.apic;
+
 enc = avio_r8(pb);
 taglen--;
 
@@ -658,7 +651,6 @@ static void read_apic(AVFormatContext *s, AVIOContext *pb, 
int taglen,
 memset(apic->buf->data + taglen, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 
 new_extra->tag  = "APIC";
-new_extra->data = apic;
 new_extra->next = *extra_meta;
 *extra_meta = new_extra;
 
@@ -680,7 +672,6 @@ static void free_chapter(void *obj)
 ID3v2ExtraMetaCHAP *chap = obj;
 av_freep(&chap->element_id);
 av_dict_free(&chap->meta);
-av_freep(&chap);
 }
 
 static void read_chapter(AVFormatContext *s, AVIOContext *pb, int len, const 
char *ttag, ID3v2ExtraMeta **extra_meta, int isv34)
@@ -691,10 +682,10 @@ static void read_chapter(AVFormatContext *s, AVIOContext 
*pb, int len, const cha
 ID3v2ExtraMetaCHAP *chap  = NULL;
 
 new_extra = av_mallocz(sizeof(*new_extra));
-chap  = av_mallocz(sizeof(*chap));
+if (!new_extra)
+return;
 
-if (!new_extra || !chap)
-goto fail;
+chap = &new_extra->data.chap;
 
 if (decode_str(s, pb, 0, &chap->element_id, &len) < 0)
 goto fail;
@@ -727,15 +718,13 @@ static void read_chapter(AVFormatContext *s, AVIOContext 
*pb, int len, const cha
 ff_metadata_conv(&chap->meta, NULL, ff_id3v2_4_metadata_conv);
 
 new_extra->tag  = "CHAP";
-new_extra->data = c

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Timo Rothenpieler]

Out of curiosity if I was proposing/using the native NVidia proprietary 
library for screen capture (linked at runtime dynamically), would that 
be more acceptable in terms of conflicts (I wouldn't like it because it 
wouldn't support AMD/Intel based hardware)?


Are the headers for those libraries under a free license, and the 
libraries part of the nvidia drivers?
If you mean the NVIDIA Capture SDK, there is no way to get that into 
FFmpeg, license wise.

___
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] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Lynne (12020-05-19):
> You're not allowed to remove NAKs of other developers.

Says who? “NAK”s have no value anyway.

> Feel free to disagree of course.

Feel free to provide the technical information useful to make the
discussion go forward:

# Does it work for a normal user on a desktop distribution freshly
# installed, without configuration?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] fate: add adpcm_ima_cunning tests

[Zane van Iperen]

On Sat, 09 May 2020 14:00:04 +
"Zane van Iperen"  wrote:

> 
> single:   Single-track
> track{0,1}:   Dual-track
> trunc-t1: Truncated track 1
> trunc-t2-track{0,1}:  Fully-truncated track 2
> trunc-t2a-track{0,1}: Partially-truncated track 2
> trunc-h2: Truncated track 2 header
> 
> Signed-off-by: Zane van Iperen 
> ---
>  tests/fate/adpcm.mak  | 27

Ping, samples are now uploaded.

Zane

___
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] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Nicolas George (12020-05-19):
> The doc says:
> 
>   Requires either DRM master or CAP_SYS_ADMIN to run.
> 
> Does it work for a normal user on a desktop distribution freshly
> installed, without configuration?
> 
> (I should test, but all my boxes are very far from the default
> configuration.)

I stopped being lazy and did test:

[kmsgrab @ 0x55b72655e840] No handle set on framebuffer: maybe you need
some additional capabilities?

So it does NOT work out-of-the-box and without root privileges.

Which makes the current proposal quite valuable indeed.

This consideration completely trumps considerations about OpenGL state,
because they only matter for the few application that would use OpenGL
and this particular device in the library. In particular, it does not
affect the command-line tool at all.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Lynne]

May 19, 2020, 09:23 by e...@fastwebnet.it:

> Hi Marton,
>
> Thanks very much for the feedback; below answers to your points - let me know 
> further feedback if any.
>
>> And sorry, I cannot say how useful this would be, maybe now is the time
>> for people to speak up if somebody is particularly against adding this
>> for any reason.
>>
>
> I haven't been able to capture video-games/3d apps running in full screen 
> with x11grab, and when running in windowed mode the capture was sub optimal 
> in terms of quality (lost frames/choppy/etc etc).
> Unless we have better solutions with ffmpeg/libav* (which I'm not aware of :) 
> this xcompgrab would target such audience (smooth capture alas more CPU 
> usage).
> But again, if there's already a better capture, then this has been an 
> academic exercise :)
>

There already is a zero-overhead capture on linux - kmsgrab. It works on AMD 
and Intel.



>> - Is there a way to keep the captured textures as an
>> OpenGL/VAAPI/NVenc/Vulkan object, so the frames can work as some kind of
>> hwaccel frames? Can this improve performance?
>>
>
> I think there would be. I would need to find more in terms of documentation 
> for both hwaccel frames structures/management.
> Please feel free to point me to guides/code/samples etc etc.
>

Uploading to hardware frames is something uses can do themselves already. 
Unless there is a native
interop, I don't see how doing the upload in the avdevice helps.



> Wouldn't a hwaccel frame imply no choice for encoder (as in now we get a true 
> uncompressed RGBA buffer which can be encoded as we see fit - if we were to 
> get hwacell wouldn't we be forced to use the encoded data as is)?
>

No.



>> - What can be the reason between the quality/smoothness difference of
>> x11grab and the Compositor capturer?
>>
>
> My suspicion is that OpenGL has access to the buffered data on the videocard 
> itself, hence able to get smooth frames.
>
> Related to both these questions, I've asked the same on Stackoverflow:
>
> https://stackoverflow.com/questions/61613441/is-there-a-better-more-efficient-way-to-capture-composite-x-windows-in-linux
>
> Unfortunately no one has been able to give me an answer (I did set a bounty 
> for it) so I posted my own understanding.
>

I wouldn't be surprised if the xlib code has some PTS issues and schedules 
downloading a frame late.
Maybe its worth fixing that instead of adding a yet another x11 capture?



>> - Maybe some openGL glue can be shared with libavdevice/opengl_enc.c?
>> Take a look, I am not sure, because that was implemented with SDL and
>> cross platform capabilities in mind, but since your capture device is
>> only for linux (or not?), then maybe it makes more sense to keep it
>> separete?
>>
>
> This is indeed a very specific implementation for Linux, I would agree that 
> perhaps not sure this makes sense to use shared OpenGL functions?
>

I'm against any OpenGL code being ran anywhere in our libraries since it will 
disturb OpenGL's global
state, breaking any OpenGL users of our libraries (there are quite a lot). Yes, 
there are also people who
want to screencapture and use OpenGL. I'm one.
This is also why we don't have OpenGL filtering in libavfilter.
So that's a big NAK for me.

As-is now, I don't see much value in this patch.

___
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] drawtext: Allow textfile path to be expanded per frame

[David Andreoletti]

Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num} has 0 paddable. When I tested locally (on master), it is
not 0 padded.

Running through different scenario, I recommend the expanded file path to not
contain 0 padded frame number:- if automatic padding is specified, then video
with no total frame known (live stream) would be problematic- if manually
padding is specified, it would complicate drawtext's textfile options parsing:
support for 0 padded %{frame_num} and possibly other custom formatting when
other supported %{} variables are expanded.
For a first improvement to an existing functionality, I would prefer to keep it
simple and focused :-)

[0]https://ffmpeg.org/ffmpeg-filters.html#Text-expansion






On Tue, May 19, 2020 9:34 AM, Manolis Stamatogiannakis msta...@gmail.com  wrote:
Hi David,




Not a full review, but a minor point that popped in mind.




It is common to pad serially numbered files with 0. E.g. if you have <1000

files, the 9th file will be named file009.txt.

Is this case handled by the expansion? Or is it assumed that the text file

numbers are not zero-padded?




If it the latter is the case, it would be good to make that explicit in the

documentation.

Of course, accounting for padding would be better, but this may not be

straightforward without adding more code.




Regards,

Manolis




On Tue, 19 May 2020 at 06:10, David Andreoletti 

wrote:




> Hi ffmpeg maintainers / community,

> New contributor here. The patch [0] for the drawtext filter was submitted

> some

> time ago now but has been reviewed yet. It seems there is no official

> maintainer

> for this filter (as per the MAINTAINERS file)

> What should be done to have it reviewed ?

>

> [0]

>

>
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/

>

> Regards,

> David Andreoletti

>

>

>

___

ffmpeg-devel mailing list

ffmpeg-devel@ffmpeg.org

https://ffmpeg.org/mailman/listinfo/ffmpeg-devel




To unsubscribe, visit link above, or email

ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg 4.2.3

[Reto Kromer]

Michael Niedermayer wrote:

>Its quite a while since 4.2.2 so i intend to make 4.2.3 soon
>if you want something backported, backport it now

Good news, thank you!

Out of curiosity, are you also preparing the 4.3 major release?

Best regards, Reto

___
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 2/2] fate: add tests for h264 and vp9 video enc parameters export

[Michael Niedermayer]

On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
> ---
>  libavformat/Makefile  |   1 +
>  tests/Makefile|   1 +
>  tests/fate-run.sh |   7 +
>  tests/fate/h264.mak   |   6 +-
>  tests/fate/vpx.mak|   5 +
>  tests/ref/fate/h264-encparams | 404 +++
>  tests/ref/fate/vp9-encparams  | 937 ++
>  tools/venc_data_dump.c| 195 +++
>  8 files changed, 1555 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/h264-encparams
>  create mode 100644 tests/ref/fate/vp9-encparams
>  create mode 100644 tools/venc_data_dump.c

These tests fail on mingw32

--- src/tests/ref/fate/vp9-encparams2020-05-19 16:09:39.771297305 +0200
+++ tests/data/fate/vp9-encparams   2020-05-19 16:10:18.091233040 +0200
@@ -1,937 +0,0 @@
-frame 0
-AVVideoEncParams 0
-qp 65
-nb_blocks 731
-block 0 0:0 64x64 33
-block 1 64:0 16x16 -12
-block 2 80:0 16x16 -12
-block 3 64:16 16x8 0
-block 4 64:24 16x8 0
-block 5 80:16 8x16 0
-block 6 88:16 8x16 0
-block 7 96:0 32x16 -23
-block 8 96:16 32x16 0
...
src/tests/fate-run.sh: 494: eval: tools/venc_data_dump.exe: Exec format error
src/tests/Makefile:255: recipe for target 'fate-vp9-encparams' failed

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] fate: add tests for h264 and vp9 video enc parameters export

[James Almer]

On 5/19/2020 11:12 AM, Michael Niedermayer wrote:
> On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
>> ---
>>  libavformat/Makefile  |   1 +
>>  tests/Makefile|   1 +
>>  tests/fate-run.sh |   7 +
>>  tests/fate/h264.mak   |   6 +-
>>  tests/fate/vpx.mak|   5 +
>>  tests/ref/fate/h264-encparams | 404 +++
>>  tests/ref/fate/vp9-encparams  | 937 ++
>>  tools/venc_data_dump.c| 195 +++
>>  8 files changed, 1555 insertions(+), 1 deletion(-)
>>  create mode 100644 tests/ref/fate/h264-encparams
>>  create mode 100644 tests/ref/fate/vp9-encparams
>>  create mode 100644 tools/venc_data_dump.c
> 
> These tests fail on mingw32
> 
> --- src/tests/ref/fate/vp9-encparams  2020-05-19 16:09:39.771297305 +0200
> +++ tests/data/fate/vp9-encparams 2020-05-19 16:10:18.091233040 +0200
> @@ -1,937 +0,0 @@
> -frame 0
> -AVVideoEncParams 0
> -qp 65
> -nb_blocks 731
> -block 0 0:0 64x64 33
> -block 1 64:0 16x16 -12
> -block 2 80:0 16x16 -12
> -block 3 64:16 16x8 0
> -block 4 64:24 16x8 0
> -block 5 80:16 8x16 0
> -block 6 88:16 8x16 0
> -block 7 96:0 32x16 -23
> -block 8 96:16 32x16 0
> ...
> src/tests/fate-run.sh: 494: eval: tools/venc_data_dump.exe: Exec format error
> src/tests/Makefile:255: recipe for target 'fate-vp9-encparams' failed

This is under wine, right? venc_data() may need to call the executable
using run(), which appends $target_exec to the command line.
___
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] [RFC]separation of multiple outputs' encoding

[Tomas Härdin]

fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
> Marton Balint  于2020年5月15日周五 上午2:33写道：
> > 
> > 
> > On Thu, 14 May 2020, Tao Zhang wrote:
> > 
> > > Hi,
> > > FFmpeg supports multiple outputs created out of the same input in the
> > > same process like
> > > ffmpeg -i input -filter_complex '[0:v]yadif,split=3[out1][out2][out3]' \
> > >-map '[out1]' -s 1280x720 -acodec … -vcodec … output1 \
> > >-map '[out2]' -s 640x480  -acodec … -vcodec … output2 \
> > >-map '[out3]' -s 320x240  -acodec … -vcodec … output3
> > > In ffmpeg.c, multiple outputs are processed sequentially like
> > > for (i = 0; i < nb_output_streams; i++)
> > >encoding one frame;
> > > 
> > > As below wiki noted, the slowest encoder will slow down the whole
> > > process. Some encoders (like libx264) perform their encoding "threaded
> > > and in the background", but x264_encoder_encode still cost some time.
> > > And it is noticeable when multiple x264_encoder_encodes run in the same 
> > > thread.
> > > https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
> > > 
> > > For API users, they can use separate thread for multiple encoding in
> > > their own code. But is there any way to rescue command line users?
> > 
> > I am not sure I understand what you want. Processing will still be limited
> > to the slowest encoder, because input processing will still be driven by
> > the slowest encoder, even if the encoders run in separate threads.
> > 
> > Buffering encoder input frames is not an option, because input frames are
> > uncompressed, therefore huge. So if you want the faster x264 encoder to
> > finish faster, you have to drive it from a different input, ultimately you
> > should run 3 separate encode processes and accept that decoding and yadif
> > processing happens in all 3 cases separately causing some overhead.
> Currently FFmpeg works like below:
> main thread:
> encoding frame 1 for output 1; encoding frame 1 for output 2; encoding
> frame 1 for output 3; encoding frame 2 for output 1; encoding frame 2
> for output 2; encoding frame 2 for output 3;...
> 
> What I want to do is
> thread 1:
> encoding frame 1 for output 1; encoding frame 2 for output 1;...
> thread 2:
> encoding frame 1 for output 2; encoding frame 2 for output 2;...
> thread 3:
> encoding frame 1 for output 3; encoding frame 2 for output 3;...

Why not just run multiple copies of the ffmpeg program? Decoding should
almost always be very minor work compared to encoding.

/Tomas

___
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] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Lynne (12020-05-19):
> New versions of libdrm can allow it to work without root. It needs 
> modifications.

When these versions have landed in Debian Stable, we will see. In the
meantime, it is useful now.

> You underestimate how many library users use OpenGL.
> My NAK still stands, whether you think its worth anything or not.

The ffmpeg command-line tool does not use OpenGL, unless specifically
directed to. For that reason alone, OpenGL devices and filter have their
place in the project as is.

If you insist on opposing, we will have to ask other people to decide.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Lynne (12020-05-19):
> You underestimate how many library users use OpenGL.

Oh, I just noticed two seconds after sending: There is a big reasoning
mistake here.

I do not underestimate how many library users use OpenGL.

You overestimate how many library users use OpenGL and allow users to
use arbitrary filters and devices without showing their name.

Because a library user using OpenGL is not a problem unless it also uses
the corresponding filter or devices. If it uses the library to decode
files or network streams and OpenGL to display them, it works perfectly,
even if there are problematic filters too.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3 1/2] fftools: add global option to dump filter graph to stderr

[lance . lmwang]

From: Limin Wang 

It's useful for debugging filter graph purposes, now only lavfi can do that.

Reviewed-by: Carl Eugen Hoyos 
Signed-off-by: Limin Wang 
---
 doc/ffmpeg.texi | 4 
 fftools/ffmpeg.h| 1 +
 fftools/ffmpeg_filter.c | 7 +++
 fftools/ffmpeg_opt.c| 3 +++
 4 files changed, 15 insertions(+)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index ed437bb..b50fd7f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -735,6 +735,10 @@ Technical note -- attachments are implemented as codec 
extradata, so this
 option can actually be used to extract extradata from any stream, not just
 attachments.
 
+@item -dump_filtergraph (@emph{global})
+Dump filter graph to stderr. It is off by default, the option is mostly useful
+for debugging filter graph purposes
+
 @item -noautorotate
 Disable automatically rotating video based on file metadata.
 
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 38205a1..a6025d0 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -606,6 +606,7 @@ extern AVIOContext *progress_avio;
 extern float max_error_rate;
 extern char *videotoolbox_pixfmt;
 
+extern int dump_filtergraph;
 extern int filter_nbthreads;
 extern int filter_complex_nbthreads;
 extern int vstats_version;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 8b5b157..46dfb25 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1106,6 +1106,13 @@ int configure_filtergraph(FilterGraph *fg)
 if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
 goto fail;
 
+if (dump_filtergraph) {
+char *dump = avfilter_graph_dump(fg->graph, NULL);
+fputs(dump, stderr);
+fflush(stderr);
+av_free(dump);
+}
+
 /* limit the lists of allowed formats to the ones selected, to
  * make sure they stay the same if the filtergraph is reconfigured later */
 for (i = 0; i < fg->nb_outputs; i++) {
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 60bb437..9179fd3 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -161,6 +161,7 @@ int copy_ts   = 0;
 int start_at_zero = 0;
 int copy_tb   = -1;
 int debug_ts  = 0;
+int dump_filtergraph  = 0;
 int exit_on_error = 0;
 int abort_on_flags= 0;
 int print_stats   = -1;
@@ -3548,6 +3549,8 @@ const OptionDef options[] = {
 { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
  OPT_EXPERT | OPT_INPUT, { .off = 
OFFSET(dump_attachment) },
 "extract an attachment into a file", "filename" },
+{ "dump_filtergraph", OPT_BOOL,  { 
&dump_filtergraph },
+"dump filter graph to stderr" },
 { "stream_loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
 OPT_OFFSET,  { .off = 
OFFSET(loop) }, "set number of times input stream shall be looped", "loop 
count" },
 { "debug_ts",   OPT_BOOL | OPT_EXPERT,   { 
&debug_ts },
-- 
1.8.3.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 v3 2/2] avdevice/lavf: change the dumpgraph option to bool type

[lance . lmwang]

From: Limin Wang 

dumpgraph option currently uses string types, but actually only requires bool 
type

Signed-off-by: Limin Wang 
---
 doc/indevs.texi | 2 +-
 libavdevice/lavfi.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf..0ce61f2 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -974,7 +974,7 @@ filters. Syntax of the filtergraph is the same as the one 
specified by
 the option @var{graph}.
 
 @item dumpgraph
-Dump graph to stderr.
+Dump graph to stderr. Boolean value, by default disabled.
 
 @end table
 
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index c949ff7..57c3070 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -47,7 +47,7 @@ typedef struct {
 AVClass *class;  ///< class for private options
 char  *graph_str;
 char  *graph_filename;
-char  *dump_graph;
+int dump_graph;
 AVFilterGraph *graph;
 AVFilterContext **sinks;
 int *sink_stream_map;
@@ -301,7 +301,7 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
 goto end;
 
 if (lavfi->dump_graph) {
-char *dump = avfilter_graph_dump(lavfi->graph, lavfi->dump_graph);
+char *dump = avfilter_graph_dump(lavfi->graph, NULL);
 if (dump != NULL) {
 fputs(dump, stderr);
 fflush(stderr);
@@ -493,7 +493,7 @@ static int lavfi_read_packet(AVFormatContext *avctx, 
AVPacket *pkt)
 static const AVOption options[] = {
 { "graph", "set libavfilter graph", OFFSET(graph_str),  
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
 { "graph_file","set libavfilter graph filename", OFFSET(graph_filename), 
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC},
-{ "dumpgraph", "dump graph to stderr",  OFFSET(dump_graph), 
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
+{ "dumpgraph", "dump graph to stderr",  OFFSET(dump_graph), 
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DEC },
 { NULL },
 };
 
-- 
1.8.3.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 v3 2/2] avdevice/lavf: change the dumpgraph option to bool type

[Nicolas George]

lance.lmw...@gmail.com (12020-05-19):
> From: Limin Wang 
> 
> dumpgraph option currently uses string types, but actually only requires bool 
> type

Originally, the second parameter to avfilter_graph_dump() was supposed
to be dump options. None was ever added, and I later came to realize
that using a string for that was more of the same bad idea.

I have no objection to making this bit obsolete, but please do it
knowingly.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/2] avdevice/lavf: change the dumpgraph option to bool type

[Nicolas George]

Nicolas George (12020-05-19):
> Originally, the second parameter to avfilter_graph_dump() was supposed
> to be dump options. None was ever added, and I later came to realize
> that using a string for that was more of the same bad idea.
> 
> I have no objection to making this bit obsolete, but please do it
> knowingly.

Again, forgot something before sending:

The idea was to be able to output other kinds of graph representation.
The current one is a very clumsy attempt at ASCII-art. But we could have
added:

avfilter_graph_dump(graph, "fmt=dot");

to get output in Graphviz DOT format, basically importing
tools/graph2dot.c into libavfilter/graphdump.c. Finally doing that may
be a better idea than obsoleting the option.

And of course, other formats are possible too.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Lynne]

May 19, 2020, 11:40 by geo...@nsup.org:

> This is me NAKing your NAK.
>

You're not allowed to remove NAKs of other developers.
Feel free to disagree of course.

___
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 v3 2/2] avdevice/lavf: change the dumpgraph option to bool type

[lance . lmwang]

On Tue, May 19, 2020 at 05:02:42PM +0200, Nicolas George wrote:
> Nicolas George (12020-05-19):
> > Originally, the second parameter to avfilter_graph_dump() was supposed
> > to be dump options. None was ever added, and I later came to realize
> > that using a string for that was more of the same bad idea.
> > 
> > I have no objection to making this bit obsolete, but please do it
> > knowingly.
> 
> Again, forgot something before sending:
> 
> The idea was to be able to output other kinds of graph representation.
> The current one is a very clumsy attempt at ASCII-art. But we could have
> added:
> 
>   avfilter_graph_dump(graph, "fmt=dot");
> 
> to get output in Graphviz DOT format, basically importing
> tools/graph2dot.c into libavfilter/graphdump.c. Finally doing that may
> be a better idea than obsoleting the option.

Thanks for sharing the background, now the document isn't very clear how to
use the option, after checking, nobody use it, so I think it's better to 
claim it as bool. I can take a look how to convert graph to dot format if nobody
will support it.

> 
> And of course, other formats are possible too.
> 
> 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".


-- 
Thanks,
Limin Wang
___
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] [RFC]separation of multiple outputs' encoding

[Zhong Li]

Tomas Härdin  于2020年5月19日周二 下午10:25写道：
>
> fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
> > Marton Balint  于2020年5月15日周五 上午2:33写道：
> > >
> > >
> > > On Thu, 14 May 2020, Tao Zhang wrote:
> > >
> > > > Hi,
> > > > FFmpeg supports multiple outputs created out of the same input in the
> > > > same process like
> > > > ffmpeg -i input -filter_complex '[0:v]yadif,split=3[out1][out2][out3]' \
> > > >-map '[out1]' -s 1280x720 -acodec … -vcodec … output1 \
> > > >-map '[out2]' -s 640x480  -acodec … -vcodec … output2 \
> > > >-map '[out3]' -s 320x240  -acodec … -vcodec … output3
> > > > In ffmpeg.c, multiple outputs are processed sequentially like
> > > > for (i = 0; i < nb_output_streams; i++)
> > > >encoding one frame;
> > > >
> > > > As below wiki noted, the slowest encoder will slow down the whole
> > > > process. Some encoders (like libx264) perform their encoding "threaded
> > > > and in the background", but x264_encoder_encode still cost some time.
> > > > And it is noticeable when multiple x264_encoder_encodes run in the same 
> > > > thread.
> > > > https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
> > > >
> > > > For API users, they can use separate thread for multiple encoding in
> > > > their own code. But is there any way to rescue command line users?
> > >
> > > I am not sure I understand what you want. Processing will still be limited
> > > to the slowest encoder, because input processing will still be driven by
> > > the slowest encoder, even if the encoders run in separate threads.
> > >
> > > Buffering encoder input frames is not an option, because input frames are
> > > uncompressed, therefore huge. So if you want the faster x264 encoder to
> > > finish faster, you have to drive it from a different input, ultimately you
> > > should run 3 separate encode processes and accept that decoding and yadif
> > > processing happens in all 3 cases separately causing some overhead.
> > Currently FFmpeg works like below:
> > main thread:
> > encoding frame 1 for output 1; encoding frame 1 for output 2; encoding
> > frame 1 for output 3; encoding frame 2 for output 1; encoding frame 2
> > for output 2; encoding frame 2 for output 3;...
> >
> > What I want to do is
> > thread 1:
> > encoding frame 1 for output 1; encoding frame 2 for output 1;...
> > thread 2:
> > encoding frame 1 for output 2; encoding frame 2 for output 2;...
> > thread 3:
> > encoding frame 1 for output 3; encoding frame 2 for output 3;...
>
> Why not just run multiple copies of the ffmpeg program? Decoding should
> almost always be very minor work compared to encoding.
Not vey minor IMHO.  For same resolution, H264 decoding is about 10%
computing cost of encoding.
And if adding the filter computing cost (just as yadif filter listed
above), the redundant computing cost is huge.
___
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 v3 2/2] avdevice/lavf: change the dumpgraph option to bool type

[Nicolas George]

lance.lmw...@gmail.com (12020-05-19):
> Thanks for sharing the background, now the document isn't very clear how to
> use the option, after checking, nobody use it, so I think it's better to 
> claim it as bool. I can take a look how to convert graph to dot format if 
> nobody
> will support it.

Since nothing uses it yet, you are free to do what you want with it. But
if you just treat the options string as bool, you cannot use it to
select the output format.

If you intend to also implement the DOT output, then it is better to
really treat it like an options string, probably using
parse_key_value_pair() (why do we have two versions of this is beyond
me) or similar.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Lynne]

May 19, 2020, 11:25 by e...@fastwebnet.it:

> Hi Lynne,
>
> Thanks for the feedback.
> Some more discussion points below.
>
>> There already is a zero-overhead capture on linux - kmsgrab. It works on AMD 
>> and Intel.
>>
>
> Does it work on Nvidia too? Does it have smooth capture?
> Does it work for 3d applications?
>

Of course it does. Did you not bother to read the manual or wiki page? Why 
wouldn't it work for 3D?
It does not work on Nvidia, and you can only blame them.



>>> Wouldn't a hwaccel frame imply no choice for encoder (as in now we get a 
>>> true uncompressed RGBA buffer which can be encoded as we see fit - if we 
>>> were to get hwacell wouldn't we be forced to use the encoded data as is)?
>>>
>>
>> No.
>>
>
> My point was around if you use say NVenc to compress frames, you wouldn't 
> want to decompress-recompress to avoid artefacts?
>

I have zero idea what you're talking about. Hardware frames are just like 
software frames, but
they live in VRAM.



>> I wouldn't be surprised if the xlib code has some PTS issues and schedules 
>> downloading a frame late.
>>
>
> I'm far from being an expert, but I would be surprised if that had issues 
> considering it's the main Linux screen capture we have?
> The xcb calls to grab a frame are quite simple/straightforward (both shm and 
> non shm versions).
>

The avdevice polls to get new frames. If it polls too late, it will miss a 
frame. I think that's where a possible issue is.



>> Maybe its worth fixing that instead of adding a yet another x11 capture?
>>
>
> This is a xcomposite capture, I would say it's different than a x11 raw 
> capture.
>

It captures the same windowing system.
We do not want to end up with 2 capture systems that do the same thing. How 
would users know
which one to use?



>> I'm against any OpenGL code being ran anywhere in our libraries since it 
>> will disturb OpenGL's global
>> state, breaking any OpenGL users of our libraries (there are quite a lot). 
>> Yes, there are also people who
>> want to screencapture and use OpenGL. I'm one.
>> This is also why we don't have OpenGL filtering in libavfilter.
>> So that's a big NAK for me.
>>
>
> Fair enough - Understood why it would be a NAK from you.
> Would there be a way to mark this as experimental?
>

We don't have any way to mark devices as experimental or opengl.
All we have are subjective opinions that this is better than the current 
capture system,
which isn't very convincing its worth merging problematic code and adding new 
API to signal it.



> Out of curiosity if I was proposing/using the native NVidia proprietary 
> library for screen capture (linked at runtime dynamically), would that be 
> more acceptable in terms of conflicts (I wouldn't like it because it wouldn't 
> support AMD/Intel based hardware)?
>

I'd be more okay with having the native Nvidia library for when kmsgrab doesn't 
work.



> I wrote this because I wanted to capture 3d apps at 60 FPS with high quality 
> without having to drop frames.
> If there is a better way with ffmpeg/libav*, please feel free to suggest - 
> otherwise currently folks would be forced to use OBS and not use 
> ffmpeg/libav* based solutions.
>

kmsgrab is by far the fastest capture possible. Use it if performance isn't 
good enough.



> The video games segment under Linux is expanding, would ffmpeg/libav* have 
> the right infra/codecs to cater for it?
> Can we capture true 60 FPS of a 3d app today? Do we have native Vulkan/OpenGL 
> capturers?
>

There is no native Vulkan/OpenGL capture. No such thing exists. You can't just 
spy on other programs.
All captures on all platforms are managed by the windowing system.

___
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] [WIP] XComposite window capture demuxer (Linux)

[Marton Balint]

On Tue, 19 May 2020, Lynne wrote:


May 19, 2020, 09:23 by e...@fastwebnet.it:


Hi Marton,

Thanks very much for the feedback; below answers to your points - let me know 
further feedback if any.


And sorry, I cannot say how useful this would be, maybe now is the time
for people to speak up if somebody is particularly against adding this
for any reason.



I haven't been able to capture video-games/3d apps running in full screen with 
x11grab, and when running in windowed mode the capture was sub optimal in terms 
of quality (lost frames/choppy/etc etc).
Unless we have better solutions with ffmpeg/libav* (which I'm not aware of :) 
this xcompgrab would target such audience (smooth capture alas more CPU usage).
But again, if there's already a better capture, then this has been an academic 
exercise :)



There already is a zero-overhead capture on linux - kmsgrab. It works on AMD 
and Intel.


As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it 
on Intel half a year ago on Ubuntu 18.04, and it simply does not work 
correctly. There were crashes, there were random failures with cryptic 
error messages, usually at the beginning of the capture, somtimes in the 
middle of it. And the captured frame was missing some of the drawn opengl 
primitives, it looked like kmsgrab grabbed the frame from the back buffer 
and not the front.


So kmsgab on Intel is a no-no for me.

Regards,
Marton
___
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] [WIP] XComposite window capture demuxer (Linux)

[Lynne]

May 19, 2020, 13:09 by geo...@nsup.org:

> Nicolas George (12020-05-19):
>
>> The doc says:
>>
>>  Requires either DRM master or CAP_SYS_ADMIN to run.
>>
>> Does it work for a normal user on a desktop distribution freshly
>> installed, without configuration?
>>
>> (I should test, but all my boxes are very far from the default
>> configuration.)
>>
>
> I stopped being lazy and did test:
>
> [kmsgrab @ 0x55b72655e840] No handle set on framebuffer: maybe you need
> some additional capabilities?
>

New versions of libdrm can allow it to work without root. It needs 
modifications.



> So it does NOT work out-of-the-box and without root privileges.
>
> Which makes the current proposal quite valuable indeed.
>
> This consideration completely trumps considerations about OpenGL state,
> because they only matter for the few application that would use OpenGL
> and this particular device in the library. In particular, it does not
> affect the command-line tool at all.
>

You underestimate how many library users use OpenGL.
My NAK still stands, whether you think its worth anything or not.

___
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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

[Marton Balint]

On Tue, 19 May 2020, lance.lmw...@gmail.com wrote:


On Sun, May 17, 2020 at 02:41:18PM +0200, Marton Balint wrote:



On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:

> On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
> > 
> > 
> > On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> > 
> > > On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:

> > > > > > > > On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> > > > > > I suggest you capture the input, so this issue can be
> > properly reproduced
> > > > and share it. It may even make sense to create a fate test from it.
> > > > Have tried, the issue can't be reproduced by capture offset
> > file. I guess it's
> > > caused by live stream seek isn't same as off line file.
> > 
> > If that is the case then you can override the seekability of files by using

> > -seekable 0 option. Alternatively you might find some other means to replay
> > the recorded ts, anyhow this should be reproduced, because I have a feeling
> > we don't have the whole picture of what is going on.
> 
> I have spend more time to investigate it, I have try to capture a pcap file to

> reproduce the issue, with tcprelay, it can be reproduced every time, however
> if export to ts, I failed to reproduce it.

Great. Can you share the pcap file? You can may send it to me privately if
you don't want it to be made public.


I have send it the sample to you privately, if you haven't got it, please let me
know.


Thanks, got it, and reproduced it, I will reply to your patch.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/mpegts: Fix misdetection of the raw packet size

[Marton Balint]

On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:


From: Limin Wang 

Signed-off-by: Limin Wang 
---
libavformat/mpegts.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0833d62..4bca339 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2852,6 +2852,8 @@ static void reanalyze(MpegTSContext *ts) {
ts->size_stat[1] ++;
} else if (pos == TS_FEC_PACKET_SIZE) {
ts->size_stat[2] ++;
+} else {
+return;
}


Okay, so what this patch does is that it skips unrecognized sync byte 
distances entirely. I guess that is OK, but it still not fixes 
not recognizing skipped 0x47 bytes. I will send an alternative patch with 
some more explanation.


Thanks,
Marton
___
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] [RFC]separation of multiple outputs' encoding

[Bodecs Bela]

2020.05.19. 17:27 keltezéssel, Zhong Li írta:

Tomas Härdin  于2020年5月19日周二 下午10:25写道：

fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:

Marton Balint  于2020年5月15日周五 上午2:33写道：


On Thu, 14 May 2020, Tao Zhang wrote:


Hi,
FFmpeg supports multiple outputs created out of the same input in the
same process like
ffmpeg -i input -filter_complex '[0:v]yadif,split=3[out1][out2][out3]' \
-map '[out1]' -s 1280x720 -acodec … -vcodec … output1 \
-map '[out2]' -s 640x480  -acodec … -vcodec … output2 \
-map '[out3]' -s 320x240  -acodec … -vcodec … output3
In ffmpeg.c, multiple outputs are processed sequentially like
for (i = 0; i < nb_output_streams; i++)
encoding one frame;

As below wiki noted, the slowest encoder will slow down the whole
process. Some encoders (like libx264) perform their encoding "threaded
and in the background", but x264_encoder_encode still cost some time.
And it is noticeable when multiple x264_encoder_encodes run in the same thread.
https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs

For API users, they can use separate thread for multiple encoding in
their own code. But is there any way to rescue command line users?

I am not sure I understand what you want. Processing will still be limited
to the slowest encoder, because input processing will still be driven by
the slowest encoder, even if the encoders run in separate threads.

Buffering encoder input frames is not an option, because input frames are
uncompressed, therefore huge. So if you want the faster x264 encoder to
finish faster, you have to drive it from a different input, ultimately you
should run 3 separate encode processes and accept that decoding and yadif
processing happens in all 3 cases separately causing some overhead.

Currently FFmpeg works like below:
main thread:
encoding frame 1 for output 1; encoding frame 1 for output 2; encoding
frame 1 for output 3; encoding frame 2 for output 1; encoding frame 2
for output 2; encoding frame 2 for output 3;...

What I want to do is
thread 1:
encoding frame 1 for output 1; encoding frame 2 for output 1;...
thread 2:
encoding frame 1 for output 2; encoding frame 2 for output 2;...
thread 3:
encoding frame 1 for output 3; encoding frame 2 for output 3;...

Why not just run multiple copies of the ffmpeg program? Decoding should
almost always be very minor work compared to encoding.

Not vey minor IMHO.  For same resolution, H264 decoding is about 10%
computing cost of encoding.
And if adding the filter computing cost (just as yadif filter listed
above), the redundant computing cost is huge.


I agree. I was several times in similar situations.

bb


___
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] avcodec/libx265: add support for reordered_opaque

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/libx265.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 573ecc8cb0..821175c1b6 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -504,6 +504,16 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 ret = libx265_encode_set_roi(ctx, pic, &x265pic);
 if (ret < 0)
 return ret;
+
+if (pic->reordered_opaque) {
+x265pic.userData = av_malloc(sizeof(pic->reordered_opaque));
+if (!x265pic.userData) {
+av_freep(&x265pic.quantOffsets);
+return AVERROR(ENOMEM);
+}
+
+memcpy(x265pic.userData, &pic->reordered_opaque, 
sizeof(pic->reordered_opaque));
+}
 }
 
 ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
@@ -570,6 +580,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 ff_side_data_set_encoder_stats(pkt, x265pic_out.frameData.qp * 
FF_QP2LAMBDA, NULL, 0, pict_type);
 
+if (x265pic_out.userData) {
+memcpy(&avctx->reordered_opaque, x265pic_out.userData, 
sizeof(avctx->reordered_opaque));
+av_freep(&x265pic_out.userData);
+} else
+avctx->reordered_opaque = 0;
+
 *got_packet = 1;
 return 0;
 }
@@ -683,6 +699,7 @@ AVCodec ff_libx265_encoder = {
 .priv_data_size   = sizeof(libx265Context),
 .priv_class   = &class,
 .defaults = x265_defaults,
-.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS |
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .wrapper_name = "libx265",
 };
-- 
2.26.2

___
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/mpegts: fix resync logic stuck in 192 bytes

[Marton Balint]

pos47_full is not updated for every packet, and for unseekable inputs the
resync logic might simply skip some 0x47 sync bytes. In order to detect these
let's check for modulo instead of exact value.

Also skip unrecognized sync byte distances instead of considering them as a
failure of detection. It only delays the detection of the new packet size.

Also note that AVIO only buffers a single packet (for UDP/mpegts, that usually
means 1316 bytes), so among every ten consecutive 188-byte MPEGTS packets there
will always be a seek failure, and that caused the old code to not find the 188
byte pattern across 10 consecutive packets.

Signed-off-by: Marton Balint 
---
 libavformat/mpegts.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index a065c61c40..f2b2c05d86 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2846,12 +2846,14 @@ static void reanalyze(MpegTSContext *ts) {
 if (pos < 0)
 return;
 pos -= ts->pos47_full;
-if (pos == TS_PACKET_SIZE) {
+if (pos % TS_PACKET_SIZE == 0) {
 ts->size_stat[0] ++;
-} else if (pos == TS_DVHS_PACKET_SIZE) {
+} if (pos % TS_DVHS_PACKET_SIZE == 0) {
 ts->size_stat[1] ++;
-} else if (pos == TS_FEC_PACKET_SIZE) {
+} if (pos % TS_FEC_PACKET_SIZE == 0) {
 ts->size_stat[2] ++;
+} else {
+return;
 }
 
 ts->size_stat_count ++;
-- 
2.26.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] [WIP] XComposite window capture demuxer (Linux)

[Nicolas George]

Marton Balint (12020-05-19):
> As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on
> Intel half a year ago on Ubuntu 18.04, and it simply does not work
> correctly. There were crashes, there were random failures with cryptic error
> messages, usually at the beginning of the capture, somtimes in the middle of
> it. And the captured frame was missing some of the drawn opengl primitives,
> it looked like kmsgrab grabbed the frame from the back buffer and not the
> front.
> 
> So kmsgab on Intel is a no-no for me.

Thanks for the confirmation.

Could you weigh in on the issue of filters/devices changing the OpenGL
global state, please?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec: Add MediaFoundation encoder wrapper

[Martin Storsjö]

On Mon, 18 May 2020, Aman Gupta wrote:


On Fri, May 15, 2020 at 12:04 AM Martin Storsjö  wrote:


On Tue, 12 May 2020, Martin Storsjö wrote:

> From: wm4 
>
> This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
>
> This is based on top of an original patch by wm4
> . The original patch supported both encoding
> and decoding, but this patch only includes encoding.
>
> The patch contains further changes by Paweł Wegner
>  (primarily for splitting out the encoding
> parts of the original patch) and further cleanup, build compatibility
> fixes and tweaks for use with Qualcomm encoders by Martin Storsjö.
> ---
> v2: Added AV_CODEC_CAP_HYBRID, removed a leftover unused AVBSFContext,
> added changelog and encoders.text entries, renamed the configure option
> and config item to "mediafoundation" instead of "mf", changed the
> makefile to keep individual additions of object files for each
> individual encoder (so that it isn't compiled if all encoders are
> disabled, even if CONFIG_MEDIAFOUNDATION is enabled).

Any further comments on this, or is it ok to be merged now?



+1 from me. We have been using the original patchset for quite a few years
now, and it will make things much easier if it is included upstream.

For encoding video, we found the mf apis work much more reliably across
different hardware (and versions of Windows) compared to using qsv directly.


Thanks - pushed this now!

// Martin
___
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 2/2] hwcontext_vulkan: expose the enabled device features

[Mark Thompson]

On 13/05/2020 16:53, Lynne wrote:
> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan 
> API users interoperable is complete.
> Users of both libraries can initialize one another's contexts without having
> to create a new one.
> > From 28264793295b0d7861527f40fa7c7041a3b34907 Mon Sep 17 00:00:00 2001
> From: Lynne 
> Date: Wed, 13 May 2020 16:39:00 +0100
> Subject: [PATCH 2/2] hwcontext_vulkan: expose the enabled device features
> 
> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan

The "puzze".

> API users interoperable is complete.
> Users of both libraries can initialize one another's contexts without having
> to create a new one.
> ---
>  libavutil/hwcontext_vulkan.c | 11 +++
>  libavutil/hwcontext_vulkan.h |  7 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index 82ceb7013a..d05dd2cf5d 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -807,6 +807,7 @@ static int 
> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>  AVDictionaryEntry *opt_d;
>  VulkanDevicePriv *p = ctx->internal->priv;
>  AVVulkanDeviceContext *hwctx = ctx->hwctx;
> +VkPhysicalDeviceFeatures dev_features = { 0 };
>  VkDeviceQueueCreateInfo queue_create_info[3] = {
>  { .sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO, },
>  { .sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO, },
> @@ -815,6 +816,7 @@ static int 
> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>  
>  VkDeviceCreateInfo dev_info = {
>  .sType= VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
> +.pEnabledFeatures = &hwctx->device_features,
>  .pQueueCreateInfos= queue_create_info,
>  .queueCreateInfoCount = 0,
>  };
> @@ -839,6 +841,15 @@ static int 
> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>  av_log(ctx, AV_LOG_VERBOSE, "minMemoryMapAlignment:  
> %li\n",
> p->props.limits.minMemoryMapAlignment);
>  
> +vkGetPhysicalDeviceFeatures(hwctx->phys_dev, &dev_features);
> +#define COPY_FEATURE(DST, NAME) (DST).NAME = dev_features.NAME;
> +COPY_FEATURE(hwctx->device_features, shaderImageGatherExtended)
> +COPY_FEATURE(hwctx->device_features, shaderStorageImageExtendedFormats)
> +COPY_FEATURE(hwctx->device_features, fragmentStoresAndAtomics)
> +COPY_FEATURE(hwctx->device_features, vertexPipelineStoresAndAtomics)
> +COPY_FEATURE(hwctx->device_features, shaderInt64)
> +#undef COPY_FEATURE

Forgive me if I'm being stupid here, but why can't the user run exactly the 
same code to find the features themselves?  They do have hwctx->phys_dev.

> +
>  /* Search queue family */
>  if ((err = search_queue_families(ctx, &dev_info)))
>  goto end;
> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
> index 9fbe8b9dcb..b73097d514 100644
> --- a/libavutil/hwcontext_vulkan.h
> +++ b/libavutil/hwcontext_vulkan.h
> @@ -94,6 +94,13 @@ typedef struct AVVulkanDeviceContext {
>   */
>  const char * const *enabled_dev_extensions;
>  int nb_enabled_dev_extensions;
> +/**
> + * This structure lists all device features that are present and enabled
> + * during device creation. By default, if present, 
> shaderImageGatherExtended,
> + * shaderStorageImageExtendedFormats, fragmentStoresAndAtomics, 
> shaderInt64,
> + * and vertexPipelineStoresAndAtomics are enabled.

And what should an API user set it to?  Do they need to enable that same set of 
features?

> + */
> +VkPhysicalDeviceFeatures device_features;
>  } AVVulkanDeviceContext;
>  
>  /**
> -- 
> 2.26.2

- Mark
___
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/2] hwcontext_vulkan: expose the amount of queues for each queue family

[Mark Thompson]

On 13/05/2020 16:53, Lynne wrote:
> This, along with the next patch, are the last missing pieces to being 
> interoperable with libplacebo.
> There is no danger of users running into this API break because there are 
> none,
> and API was completely backwards-incompatibly changed just 2 days ago.
> This is needed so we won't have to break the API anymore in the future.

?  The previous change wasn't an ABI break after the fields were rearranged 
properly.

> From 63a95c6848e44f365256dbe10c0e1fa595a0f679 Mon Sep 17 00:00:00 2001
> From: Lynne 
> Date: Wed, 13 May 2020 16:20:15 +0100
> Subject: [PATCH 1/2] hwcontext_vulkan: expose the amount of queues for each
>  queue family
> 
> This, along with the next patch, are the last missing pieces to being
> interoperable with libplacebo.
> ---
>  libavutil/hwcontext_vulkan.c |  3 +++
>  libavutil/hwcontext_vulkan.h | 14 --
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index 8f3f3fdd2a..82ceb7013a 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -679,16 +679,19 @@ static int search_queue_families(AVHWDeviceContext 
> *ctx, VkDeviceCreateInfo *cd)
>  hwctx->queue_family_index  = graph_index;
>  hwctx->queue_family_comp_index = graph_index;
>  hwctx->queue_family_tx_index   = graph_index;
> +hwctx->nb_graphics_queues  = qs[graph_index].queueCount;
>  
>  if (comp_index != -1) {
>  ADD_QUEUE(comp_index, 0, 1, tx_index < 0)
>  hwctx->queue_family_tx_index   = comp_index;
>  hwctx->queue_family_comp_index = comp_index;
> +hwctx->nb_comp_queues  = qs[comp_index].queueCount;
>  }
>  
>  if (tx_index != -1) {
>  ADD_QUEUE(tx_index, 0, 0, 1)
>  hwctx->queue_family_tx_index = tx_index;
> +hwctx->nb_tx_queues  = qs[tx_index].queueCount;
>  }
>  
>  #undef ADD_QUEUE
> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
> index c3fc14af70..9fbe8b9dcb 100644
> --- a/libavutil/hwcontext_vulkan.h
> +++ b/libavutil/hwcontext_vulkan.h
> @@ -55,16 +55,26 @@ typedef struct AVVulkanDeviceContext {
>   * @note av_hwdevice_create() will set all 3 queue indices if unset
>   * If there is no dedicated queue for compute or transfer operations,
>   * they will be set to the graphics queue index which can handle both.
> + * nb_graphics_queues indicates how many queues were enabled for the
> + * graphics queue (must be at least 1)
>   */
>  int queue_family_index;
> +int nb_graphics_queues;
>  /**
> - * Queue family index for transfer ops only
> + * Queue family index to use for transfer operations, and the amount of 
> queues
> + * enabled. In case there is no dedicated transfer queue, nb_tx_queues
> + * must be 0 and queue_family_tx_index must be the same as either the 
> graphics
> + * queue or the compute queue, if available.
>   */
>  int queue_family_tx_index;
> +int nb_tx_queues;
>  /**
> - * Queue family index for compute ops
> + * Queue family index for compute ops, and the amount of queues enabled.
> + * In case there are no dedicated compute queues, nb_comp_queues must be
> + * 0 and its queue family index must be set to the graphics queue.
>   */
>  int queue_family_comp_index;
> +int nb_comp_queues;
>  /**
>   * Enabled instance extensions. By default, VK_KHR_surface is enabled if 
> found.
>   * If supplying your own device context, set this to an array of 
> strings, with
> -- 
> 2.26.2

Put the new fields at the end.  It looks like that combined with zero implying 
the number of queues available in that queue family would be sufficient to 
maintain compatibility?

Under what circumstances would a user create an AVVulkanDeviceContext which 
does not set these to their maximum value?  Will you want to expose some option 
so that a device created by lavu can do the same thing?

- Mark
___
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/libx265: add support for reordered_opaque

[Derek Buitenhuis]

On 19/05/2020 19:55, James Almer wrote:
> +if (pic->reordered_opaque) {

If this is meant to be PTS, won't this break on PTS==0?

- Derek
___
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/libx265: add support for reordered_opaque

[James Almer]

On 5/19/2020 5:18 PM, Derek Buitenhuis wrote:
> On 19/05/2020 19:55, James Almer wrote:
>> +if (pic->reordered_opaque) {
> 
> If this is meant to be PTS, won't this break on PTS==0?
> 
> - Derek

When pic->reordered_opaque is 0 (default value) x265pic.userData will
remain NULL. This in turn means x265pic_out.userData will also be NULL
and avctx->reordered_opaque will be set to 0, so it's functionally the
expected behavior.
This is done to avoid a malloc() per frame in 99% of use cases where
reordered_opaque is not going to be used.
___
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] movenc: Try to extract extradata from the first H264/HEVC packet, if none is set

[Martin Storsjö]

Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).

This only works for cases where the moov hasn't already been written
(e.g. when not writing fragmented mp4 with empty_moov, unless using
the delay_moov option).
---
 libavformat/avc.c| 41 ++
 libavformat/avc.h|  3 +++
 libavformat/hevc.c   | 52 
 libavformat/hevc.h   | 16 ++
 libavformat/movenc.c | 11 ++
 5 files changed, 114 insertions(+), 9 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index cd15ac3cdb..268d77c1a2 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -219,6 +219,47 @@ fail:
 return ret;
 }
 
+int ff_avc_extract_parameter_sets(const uint8_t *buf_in, int size_in,
+  uint8_t **buf_out, int *size_out)
+{
+const uint8_t *p = buf_in;
+const uint8_t *end = p + size_in;
+const uint8_t *nal_start, *nal_end;
+AVIOContext *pb;
+int ret = avio_open_dyn_buf(&pb);
+if (ret < 0)
+return ret;
+
+nal_start = ff_avc_find_startcode(p, end);
+for (;;) {
+uint8_t nal_type;
+
+while (nal_start < end && !*(nal_start++));
+if (nal_start == end)
+break;
+
+nal_type = nal_start[0] & 0x1f;
+nal_end = ff_avc_find_startcode(nal_start, end);
+
+switch (nal_type) {
+case 7:  /* SPS */
+case 8:  /* PPS */
+case 13: /* SPS_EXT */
+avio_wb32(pb, 1);
+avio_write(pb, nal_start, nal_end - nal_start);
+break;
+default:
+break;
+}
+
+nal_start = nal_end;
+}
+
+*size_out = avio_close_dyn_buf(pb, buf_out);
+
+return 0;
+}
+
 int ff_avc_write_annexb_extradata(const uint8_t *in, uint8_t **buf, int *size)
 {
 uint16_t sps_size, pps_size;
diff --git a/libavformat/avc.h b/libavformat/avc.h
index 5286d19d89..fee78b90c3 100644
--- a/libavformat/avc.h
+++ b/libavformat/avc.h
@@ -36,6 +36,9 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t *start,
 uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
   uint32_t *dst_len, int header_len);
 
+int ff_avc_extract_parameter_sets(const uint8_t *buf_in, int size_in,
+  uint8_t **buf_out, int *size_out);
+
 typedef struct {
 uint8_t id;
 uint8_t profile_idc;
diff --git a/libavformat/hevc.c b/libavformat/hevc.c
index f621cb2f19..9215638e64 100644
--- a/libavformat/hevc.c
+++ b/libavformat/hevc.c
@@ -1065,20 +1065,22 @@ int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in, 
uint8_t **buf_out,
 return 0;
 }
 
-int ff_isom_write_hvcc(AVIOContext *pb, const uint8_t *data,
-   int size, int ps_array_completeness)
+static int write_parameter_sets(AVIOContext *pb, const uint8_t *data,
+int size, int ps_array_completeness,
+int write_hvcc)
 {
 int ret = 0;
 uint8_t *buf, *end, *start = NULL;
 HEVCDecoderConfigurationRecord hvcc;
 
-hvcc_init(&hvcc);
+if (write_hvcc)
+hvcc_init(&hvcc);
 
 if (size < 6) {
 /* We can't write a valid hvcC from the provided data */
 ret = AVERROR_INVALIDDATA;
 goto end;
-} else if (*data == 1) {
+} else if (*data == 1 && write_hvcc) {
 /* Data is already hvcC-formatted */
 avio_write(pb, data, size);
 goto end;
@@ -1107,9 +1109,14 @@ int ff_isom_write_hvcc(AVIOContext *pb, const uint8_t 
*data,
 case HEVC_NAL_PPS:
 case HEVC_NAL_SEI_PREFIX:
 case HEVC_NAL_SEI_SUFFIX:
-ret = hvcc_add_nal_unit(buf, len, ps_array_completeness, &hvcc);
-if (ret < 0)
-goto end;
+if (write_hvcc) {
+ret = hvcc_add_nal_unit(buf, len, ps_array_completeness, 
&hvcc);
+if (ret < 0)
+goto end;
+} else {
+avio_wb32(pb, 1);
+avio_write(pb, buf, len);
+}
 break;
 default:
 break;
@@ -1118,10 +1125,37 @@ int ff_isom_write_hvcc(AVIOContext *pb, const uint8_t 
*data,
 buf += len;
 }
 
-ret = hvcc_write(pb, &hvcc);
+if (write_hvcc)
+ret = hvcc_write(pb, &hvcc);
 
 end:
-hvcc_close(&hvcc);
+if (write_hvcc)
+hvcc_close(&hvcc);
 av_free(start);
 return ret;
 }
+
+int ff_isom_write_hvcc(AVIOContext *pb, const uint8_t *data,
+   int size, int ps_array_completeness)
+{
+return write_parameter_sets(pb, data, size, ps_array_completeness, 1);
+}
+
+int ff_hevc_extract_parameter_sets(const uint8_t *buf_in, int size_in,
+

Re: [FFmpeg-devel] [WIP] XComposite window capture demuxer (Linux)

[Marton Balint]

On Tue, 19 May 2020, Lynne wrote:


May 19, 2020, 11:25 by e...@fastwebnet.it:




I wouldn't be surprised if the xlib code has some PTS issues and schedules 
downloading a frame late.



I'm far from being an expert, but I would be surprised if that had issues 
considering it's the main Linux screen capture we have?
The xcb calls to grab a frame are quite simple/straightforward (both shm and 
non shm versions).



The avdevice polls to get new frames. If it polls too late, it will miss a 
frame. I think that's where a possible issue is.


This is a good point. As far as I see I can greatly improve the smoothness 
of captured frames of xcbgrab by changing the av_usleep(delay) line in 
xcbgrab.c to av_usleep(delay/2).


Regards,
Marton
___
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] movenc: Try to extract extradata from the first H264/HEVC packet, if none is set

[James Almer]

On 5/19/2020 5:57 PM, Martin Storsjö wrote:
> Some encoders don't provide split out extradata directly on init (or
> at all). In particular, the MediaFoundation encoder wrapper doesn't
> always (depending on the actual encoder device) - this is the case for
> Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).
> 
> This only works for cases where the moov hasn't already been written
> (e.g. when not writing fragmented mp4 with empty_moov, unless using
> the delay_moov option).
> ---
>  libavformat/avc.c| 41 ++
>  libavformat/avc.h|  3 +++
>  libavformat/hevc.c   | 52 
>  libavformat/hevc.h   | 16 ++
>  libavformat/movenc.c | 11 ++
>  5 files changed, 114 insertions(+), 9 deletions(-)

Wouldn't copying the first packet into trk->vos_data, like it's done
with dnxhd, truehd and ac3 in ff_mov_write_packet(), work for these
codecs as well?

See
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=32e81092687439c8b91e918bb614654a5c6670d8;hb=HEAD#l5585
___
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] movenc: Try to extract extradata from the first H264/HEVC packet, if none is set

[Martin Storsjö]

On Tue, 19 May 2020, James Almer wrote:


On 5/19/2020 5:57 PM, Martin Storsjö wrote:

Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).

This only works for cases where the moov hasn't already been written
(e.g. when not writing fragmented mp4 with empty_moov, unless using
the delay_moov option).
---
 libavformat/avc.c| 41 ++
 libavformat/avc.h|  3 +++
 libavformat/hevc.c   | 52 
 libavformat/hevc.h   | 16 ++
 libavformat/movenc.c | 11 ++
 5 files changed, 114 insertions(+), 9 deletions(-)


Wouldn't copying the first packet into trk->vos_data, like it's done
with dnxhd, truehd and ac3 in ff_mov_write_packet(), work for these
codecs as well?


Hmm, yes, that's right - that would actually also work. That's 
significantly simpler...


// Martin
___
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/libx265: add support for reordered_opaque

[Derek Buitenhuis]

On 19/05/2020 22:03, James Almer wrote:
> When pic->reordered_opaque is 0 (default value) x265pic.userData will
> remain NULL. This in turn means x265pic_out.userData will also be NULL
> and avctx->reordered_opaque will be set to 0, so it's functionally the
> expected behavior.
> This is done to avoid a malloc() per frame in 99% of use cases where
> reordered_opaque is not going to be used.

OK, seems fine then.

- Derek
___
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/libx265: add support for reordered_opaque

[Hendrik Leppkes]

On Tue, May 19, 2020 at 10:45 PM Derek Buitenhuis
 wrote:
>
> On 19/05/2020 19:55, James Almer wrote:
> > +if (pic->reordered_opaque) {
>
> If this is meant to be PTS, won't this break on PTS==0?
>

Well, it won't break anything, since if  its not set on the frame,
it'll be set to zero when the frame returns

However, the default value of reordered_opaque is AV_NOPTS_VALUE, so
if you want to skip writing one value, it should probably be that one,
instead of zero.

- Hendrik
___
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 2/2] fate: add tests for h264 and vp9 video enc parameters export

[Michael Niedermayer]

On Tue, May 19, 2020 at 11:19:03AM -0300, James Almer wrote:
> On 5/19/2020 11:12 AM, Michael Niedermayer wrote:
> > On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
> >> ---
> >>  libavformat/Makefile  |   1 +
> >>  tests/Makefile|   1 +
> >>  tests/fate-run.sh |   7 +
> >>  tests/fate/h264.mak   |   6 +-
> >>  tests/fate/vpx.mak|   5 +
> >>  tests/ref/fate/h264-encparams | 404 +++
> >>  tests/ref/fate/vp9-encparams  | 937 ++
> >>  tools/venc_data_dump.c| 195 +++
> >>  8 files changed, 1555 insertions(+), 1 deletion(-)
> >>  create mode 100644 tests/ref/fate/h264-encparams
> >>  create mode 100644 tests/ref/fate/vp9-encparams
> >>  create mode 100644 tools/venc_data_dump.c
> > 
> > These tests fail on mingw32
> > 
> > --- src/tests/ref/fate/vp9-encparams2020-05-19 16:09:39.771297305 
> > +0200
> > +++ tests/data/fate/vp9-encparams   2020-05-19 16:10:18.091233040 +0200
> > @@ -1,937 +0,0 @@
> > -frame 0
> > -AVVideoEncParams 0
> > -qp 65
> > -nb_blocks 731
> > -block 0 0:0 64x64 33
> > -block 1 64:0 16x16 -12
> > -block 2 80:0 16x16 -12
> > -block 3 64:16 16x8 0
> > -block 4 64:24 16x8 0
> > -block 5 80:16 8x16 0
> > -block 6 88:16 8x16 0
> > -block 7 96:0 32x16 -23
> > -block 8 96:16 32x16 0
> > ...
> > src/tests/fate-run.sh: 494: eval: tools/venc_data_dump.exe: Exec format 
> > error
> > src/tests/Makefile:255: recipe for target 'fate-vp9-encparams' failed
> 

> This is under wine, right? 

yes


> venc_data() may need to call the executable
> using run(), which appends $target_exec to the command line.
> ___
> 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".

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: add support for reordered_opaque

[James Almer]

On 5/19/2020 5:53 PM, Hendrik Leppkes wrote:
> On Tue, May 19, 2020 at 10:45 PM Derek Buitenhuis
>  wrote:
>>
>> On 19/05/2020 19:55, James Almer wrote:
>>> +if (pic->reordered_opaque) {
>>
>> If this is meant to be PTS, won't this break on PTS==0?
>>
> 
> Well, it won't break anything, since if  its not set on the frame,
> it'll be set to zero when the frame returns
> 
> However, the default value of reordered_opaque is AV_NOPTS_VALUE, so
> if you want to skip writing one value, it should probably be that one,
> instead of zero.

No, the AVCodecContext field and the AVFrame field have different
default values. By writing 0 in AVCodecContext in this scenario I'm
effectively passing the AVFrame value through, which is the expected
behavior for AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE encoders as per the doxy.
___
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/libx265: add support for reordered_opaque

[James Almer]

On 5/19/2020 6:40 PM, Derek Buitenhuis wrote:
> On 19/05/2020 22:03, James Almer wrote:
>> When pic->reordered_opaque is 0 (default value) x265pic.userData will
>> remain NULL. This in turn means x265pic_out.userData will also be NULL
>> and avctx->reordered_opaque will be set to 0, so it's functionally the
>> expected behavior.
>> This is done to avoid a malloc() per frame in 99% of use cases where
>> reordered_opaque is not going to be used.
> 
> OK, seems fine then.
> 
> - Derek

Pushed, thanks.
___
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/mpegts: fix resync logic stuck in 192 bytes

[lance . lmwang]

On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> pos47_full is not updated for every packet, and for unseekable inputs the
> resync logic might simply skip some 0x47 sync bytes. In order to detect these
> let's check for modulo instead of exact value.

Before modifying and returning directly, I considered whether pos is a multiple 
of raw_packet_size, by the debug information, it's not true. Also it's possible
for the pos of two sync byte > 188/192/204 * n. If that's true, it's not correct
to look it as stats hit by the modulo logic.

> 
> Also skip unrecognized sync byte distances instead of considering them as a
> failure of detection. It only delays the detection of the new packet size.
> 
> Also note that AVIO only buffers a single packet (for UDP/mpegts, that usually
> means 1316 bytes), so among every ten consecutive 188-byte MPEGTS packets 
> there
> will always be a seek failure, and that caused the old code to not find the 
> 188
> byte pattern across 10 consecutive packets.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mpegts.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index a065c61c40..f2b2c05d86 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2846,12 +2846,14 @@ static void reanalyze(MpegTSContext *ts) {
>  if (pos < 0)
>  return;
>  pos -= ts->pos47_full;
> -if (pos == TS_PACKET_SIZE) {
> +if (pos % TS_PACKET_SIZE == 0) {
>  ts->size_stat[0] ++;
> -} else if (pos == TS_DVHS_PACKET_SIZE) {
> +} if (pos % TS_DVHS_PACKET_SIZE == 0) {
>  ts->size_stat[1] ++;
> -} else if (pos == TS_FEC_PACKET_SIZE) {
> +} if (pos % TS_FEC_PACKET_SIZE == 0) {
>  ts->size_stat[2] ++;
> +} else {
> +return;
>  }
>  
>  ts->size_stat_count ++;
> -- 
> 2.26.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".

-- 
Thanks,
Limin Wang
___
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] [WIP] XComposite window capture demuxer (Linux)

[Lynne]

May 19, 2020, 19:02 by c...@passwd.hu:

>
>
> On Tue, 19 May 2020, Lynne wrote:
>
>> May 19, 2020, 09:23 by e...@fastwebnet.it:
>>
>>> Hi Marton,
>>>
>>> Thanks very much for the feedback; below answers to your points - let me 
>>> know further feedback if any.
>>>
 And sorry, I cannot say how useful this would be, maybe now is the time
 for people to speak up if somebody is particularly against adding this
 for any reason.

>>>
>>> I haven't been able to capture video-games/3d apps running in full screen 
>>> with x11grab, and when running in windowed mode the capture was sub optimal 
>>> in terms of quality (lost frames/choppy/etc etc).
>>> Unless we have better solutions with ffmpeg/libav* (which I'm not aware of 
>>> :) this xcompgrab would target such audience (smooth capture alas more CPU 
>>> usage).
>>> But again, if there's already a better capture, then this has been an 
>>> academic exercise :)
>>>
>>
>> There already is a zero-overhead capture on linux - kmsgrab. It works on AMD 
>> and Intel.
>>
>
> As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on 
> Intel half a year ago on Ubuntu 18.04, and it simply does not work correctly. 
> There were crashes, there were random failures with cryptic error messages, 
> usually at the beginning of the capture, somtimes in the middle of it. And 
> the captured frame was missing some of the drawn opengl primitives, it looked 
> like kmsgrab grabbed the frame from the back buffer and not the front.
>
> So kmsgab on Intel is a no-no for me.
>

That's a driver issue, no fault of kmsgrab, and I can't even confirm seeing 
those bugs happen to anyone
using kmsgrab, either on intel or amd, so maybe your system state was somewhat 
broken?
Either way, there's still the issue of OpenGL state, OpenGL API usage 
signalling and finally, something
OP omitted: this capture system would only work on compositing X11 WMs. Not all 
WMs are compositing,
and Nvidia discouraged enabling compositors due to bugs years ago.
Our current capture system works with all X11 WMs.

___
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 2/2] hwcontext_vulkan: expose the enabled device features

[Lynne]

May 19, 2020, 20:57 by s...@jkqxz.net:

> On 13/05/2020 16:53, Lynne wrote:
>
>> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan 
>> API users interoperable is complete.
>> Users of both libraries can initialize one another's contexts without having
>> to create a new one.
>> > From 28264793295b0d7861527f40fa7c7041a3b34907 Mon Sep 17 00:00:00 2001
>> From: Lynne 
>> Date: Wed, 13 May 2020 16:39:00 +0100
>> Subject: [PATCH 2/2] hwcontext_vulkan: expose the enabled device features
>>
>> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan
>>
>
> The "puzze".
>

Fixed.



>> API users interoperable is complete.
>> Users of both libraries can initialize one another's contexts without having
>> to create a new one.
>> ---
>>  libavutil/hwcontext_vulkan.c | 11 +++
>>  libavutil/hwcontext_vulkan.h |  7 +++
>>  2 files changed, 18 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
>> index 82ceb7013a..d05dd2cf5d 100644
>> --- a/libavutil/hwcontext_vulkan.c
>> +++ b/libavutil/hwcontext_vulkan.c
>> @@ -807,6 +807,7 @@ static int 
>> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>>  AVDictionaryEntry *opt_d;
>>  VulkanDevicePriv *p = ctx->internal->priv;
>>  AVVulkanDeviceContext *hwctx = ctx->hwctx;
>> +VkPhysicalDeviceFeatures dev_features = { 0 };
>>  VkDeviceQueueCreateInfo queue_create_info[3] = {
>>  { .sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO, },
>>  { .sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO, },
>> @@ -815,6 +816,7 @@ static int 
>> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>>  
>>  VkDeviceCreateInfo dev_info = {
>>  .sType= VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
>> +.pEnabledFeatures = &hwctx->device_features,
>>  .pQueueCreateInfos= queue_create_info,
>>  .queueCreateInfoCount = 0,
>>  };
>> @@ -839,6 +841,15 @@ static int 
>> vulkan_device_create_internal(AVHWDeviceContext *ctx,
>>  av_log(ctx, AV_LOG_VERBOSE, "minMemoryMapAlignment:  %li\n",
>>  p->props.limits.minMemoryMapAlignment);
>>  
>> +vkGetPhysicalDeviceFeatures(hwctx->phys_dev, &dev_features);
>> +#define COPY_FEATURE(DST, NAME) (DST).NAME = dev_features.NAME;
>> +COPY_FEATURE(hwctx->device_features, shaderImageGatherExtended)
>> +COPY_FEATURE(hwctx->device_features, shaderStorageImageExtendedFormats)
>> +COPY_FEATURE(hwctx->device_features, fragmentStoresAndAtomics)
>> +COPY_FEATURE(hwctx->device_features, vertexPipelineStoresAndAtomics)
>> +COPY_FEATURE(hwctx->device_features, shaderInt64)
>> +#undef COPY_FEATURE
>>
>
> Forgive me if I'm being stupid here, but why can't the user run exactly the 
> same code to find the features themselves?  They do have hwctx->phys_dev.
>

vkGetPhysicalDeviceFeatures gets the list of features the device supports.
You have to manually put the ones you enable in the VkDeviceCreateInfo struct.
Even after you do that, vkGetPhysicalDeviceFeatures still gives you the 
features the device
supports, not what you've enabled. There's no way to get any enabled features 
or extensions
for a device or an instance after its created, but only what's supported.



>> +
>>  /* Search queue family */
>>  if ((err = search_queue_families(ctx, &dev_info)))
>>  goto end;
>> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
>> index 9fbe8b9dcb..b73097d514 100644
>> --- a/libavutil/hwcontext_vulkan.h
>> +++ b/libavutil/hwcontext_vulkan.h
>> @@ -94,6 +94,13 @@ typedef struct AVVulkanDeviceContext {
>>  */
>>  const char * const *enabled_dev_extensions;
>>  int nb_enabled_dev_extensions;
>> +/**
>> + * This structure lists all device features that are present and enabled
>> + * during device creation. By default, if present, 
>> shaderImageGatherExtended,
>> + * shaderStorageImageExtendedFormats, fragmentStoresAndAtomics, 
>> shaderInt64,
>> + * and vertexPipelineStoresAndAtomics are enabled.
>>
>
> And what should an API user set it to?  Do they need to enable that same set 
> of features?
>

The API user can set it to whatever they have enabled in their 
VkDeviceCreateInfo struct.
They don't need to have the same extensions enabled. We don't (and won't) 
depend on any
extensions, but optionally use them if they're enabled.
Not sure how to make this clearer.

___
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] [RFC] encoder profile validation

[myp...@gmail.com]

On Tue, May 19, 2020 at 2:33 AM Marton Balint  wrote:
>
>
>
> On Mon, 18 May 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2020-05-16 15:52:22)
> >> Hi,
> >>
> >> As you may know, a recent patchset enabled AVCodecContext->profile
> >> constants to reside in encoders.
> >>
> >> In order to make a full transition to avctx->profile even in existing
> >> encoders which might use a private profile setting, we have to make sure
> >> only supported avctx->profile values are passed to encoders.
> >>
> >> The fact that avctx->profile is not validated is already an issue, and
> >> assertions/segmentation faults can already happen in existing encoders
> >> (e.g.: aac, mpeg) if unsupported values are passed.
> >>
> >> AVCodec have a .profiles attribute which supposed to contain the list of
> >> supported profiles. However this is problematic because
> >> - AVCodecContext->profile is not validated against this list
> >> - not all encoders define the list
> >> - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL
> >> - some encoders support more or less than its currently defined list
> >
> > All of these sound like bugs that can and should be fixed.
> >
> >> - AVCodec->profiles contains AVProfiles which supposed to have a textual
> >>representation of each profile, which can cause profile name
> >>duplications/inconsistencies against libavcodec/profiles.c if the list
> >>is different to the one in codecs profile list.
> >
> > Why should it be different? Isn't that a bug that should be fixed?
>
> The list can be different because possibly not all the profiles which are
> recognized by the decoder is supported by the encoder. Also the encoder
> can define pseudo profiles which it can support, for example the AAC
> encoders have support for FF_PROFILE_MPEG2_AAC_LOW which is LC profile
> with some features disabled.
>
> >
> >>
> >> So I'd rather not user AVCodec->profiles for this validation. I am
> >> thinking about two possible solutions:
> >
> > It seems preferable to me to fix the above issues and not have multiple
> > fields with subtly different meanings that are just bound to cause
> > confusion and bugs.
>
> I agree that having the list of suppored profiles in two places is wrong,
> so in the long run, I would simply deprecate AVCodec->profiles, and use
> only the AVOptions to list the supported profiles. Also see my previous
> patchset which moves profile names directly to encoders:
>
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1193
>
> So the supported profiles would be contained in one place, AVOptions.
> Even querying the list should be doable, if needed, and
> av_get_profile_name can also be modified to get the profile name from the
> AVOptions.
So this change will break the API if deprecate AVCodec->profiles? I
know some guys used the FFmpeg API for encoding, it's bad new for them
___
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/2] hwcontext_vulkan: expose the amount of queues for each queue family

[Lynne]

May 19, 2020, 20:50 by s...@jkqxz.net:

> On 13/05/2020 16:53, Lynne wrote:
>
>> This, along with the next patch, are the last missing pieces to being 
>> interoperable with libplacebo.
>> There is no danger of users running into this API break because there are 
>> none,
>> and API was completely backwards-incompatibly changed just 2 days ago.
>> This is needed so we won't have to break the API anymore in the future.
>>
>
> ?  The previous change wasn't an ABI break after the fields were rearranged 
> properly.
>

The number of fences per image was what I was referring to.



>> From 63a95c6848e44f365256dbe10c0e1fa595a0f679 Mon Sep 17 00:00:00 2001
>> From: Lynne 
>> Date: Wed, 13 May 2020 16:20:15 +0100
>> Subject: [PATCH 1/2] hwcontext_vulkan: expose the amount of queues for each
>>  queue family
>>
>> This, along with the next patch, are the last missing pieces to being
>> interoperable with libplacebo.
>> ---
>>  libavutil/hwcontext_vulkan.c |  3 +++
>>  libavutil/hwcontext_vulkan.h | 14 --
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
>> index 8f3f3fdd2a..82ceb7013a 100644
>> --- a/libavutil/hwcontext_vulkan.c
>> +++ b/libavutil/hwcontext_vulkan.c
>> @@ -679,16 +679,19 @@ static int search_queue_families(AVHWDeviceContext 
>> *ctx, VkDeviceCreateInfo *cd)
>>  hwctx->queue_family_index  = graph_index;
>>  hwctx->queue_family_comp_index = graph_index;
>>  hwctx->queue_family_tx_index   = graph_index;
>> +hwctx->nb_graphics_queues  = qs[graph_index].queueCount;
>>  
>>  if (comp_index != -1) {
>>  ADD_QUEUE(comp_index, 0, 1, tx_index < 0)
>>  hwctx->queue_family_tx_index   = comp_index;
>>  hwctx->queue_family_comp_index = comp_index;
>> +hwctx->nb_comp_queues  = qs[comp_index].queueCount;
>>  }
>>  
>>  if (tx_index != -1) {
>>  ADD_QUEUE(tx_index, 0, 0, 1)
>>  hwctx->queue_family_tx_index = tx_index;
>> +hwctx->nb_tx_queues  = qs[tx_index].queueCount;
>>  }
>>  
>>  #undef ADD_QUEUE
>> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
>> index c3fc14af70..9fbe8b9dcb 100644
>> --- a/libavutil/hwcontext_vulkan.h
>> +++ b/libavutil/hwcontext_vulkan.h
>> @@ -55,16 +55,26 @@ typedef struct AVVulkanDeviceContext {
>>  * @note av_hwdevice_create() will set all 3 queue indices if unset
>>  * If there is no dedicated queue for compute or transfer operations,
>>  * they will be set to the graphics queue index which can handle both.
>> + * nb_graphics_queues indicates how many queues were enabled for the
>> + * graphics queue (must be at least 1)
>>  */
>>  int queue_family_index;
>> +int nb_graphics_queues;
>>  /**
>> - * Queue family index for transfer ops only
>> + * Queue family index to use for transfer operations, and the amount of 
>> queues
>> + * enabled. In case there is no dedicated transfer queue, nb_tx_queues
>> + * must be 0 and queue_family_tx_index must be the same as either the 
>> graphics
>> + * queue or the compute queue, if available.
>>  */
>>  int queue_family_tx_index;
>> +int nb_tx_queues;
>>  /**
>> - * Queue family index for compute ops
>> + * Queue family index for compute ops, and the amount of queues enabled.
>> + * In case there are no dedicated compute queues, nb_comp_queues must be
>> + * 0 and its queue family index must be set to the graphics queue.
>>  */
>>  int queue_family_comp_index;
>> +int nb_comp_queues;
>>  /**
>>  * Enabled instance extensions. By default, VK_KHR_surface is enabled if 
>> found.
>>  * If supplying your own device context, set this to an array of strings, 
>> with
>> -- 
>> 2.26.2
>>
>
> Put the new fields at the end.  It looks like that combined with zero 
> implying the number of queues available in that queue family would be 
> sufficient to maintain compatibility?
>

nb_graphics_queues is required to be set to at least one.
There is absolutely no one to keep compatibility for, as there's no one using 
this API at all (since it was
not usable as-is).
I'd like to have the header looking nicely for the release, and like the commit 
message said, this is the
last change we need to make, so I'd really rather not change this.
As for why this wasn't done earlier, its because there were only a few API 
users to really integrate with,
and those API users had not really thought about making their own API 
interoperable with everyone
else's, so like us, they exposed the minimal amount of information needed.
It was only very recently that libplacebo gained support for being initialized 
with an external device and
instance, and even then, like us, it lacked certain aspects that allowed 
interoperability, so we had to
work to solve those issues. We had at least thought of this before, so there 
were only a few modifications
we had to make, but considering the size of the Vulkan spec and that there was 
a single person working
on this (and anot

Re: [FFmpeg-devel] [PATCH 5/5] avformat/hls: Remove redundant resetting of pointer

[myp...@gmail.com]

On Tue, May 19, 2020 at 7:10 PM Andreas Rheinhardt
 wrote:
>
> ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can
> already reset the pointer.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/hls.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 89386ea1b7..3e35d157ad 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1969,7 +1969,6 @@ static int hls_read_header(AVFormatContext *s)
>  avformat_queue_attached_pictures(pls->ctx);
>  ff_id3v2_parse_priv(pls->ctx, pls->id3_deferred_extra);
>  ff_id3v2_free_extra_meta(&pls->id3_deferred_extra);
> -pls->id3_deferred_extra = NULL;
>  }
>
>  if (pls->is_id3_timestamped == -1)
> --
> 2.20.1
LGTM
___
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] avcodec/decode: remove ff_decode_bsfs_uninit()

[James Almer]

It's been a wrapper for a simple av_bsf_free() call since c96904f525.

Signed-off-by: James Almer 
---
 libavcodec/decode.c | 7 +--
 libavcodec/decode.h | 2 --
 libavcodec/utils.c  | 4 ++--
 3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 48a61d5419..f3327d74af 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -231,7 +231,7 @@ int ff_decode_bsfs_init(AVCodecContext *avctx)
 
 return 0;
 fail:
-ff_decode_bsfs_uninit(avctx);
+av_bsf_free(&avci->bsf);
 return ret;
 }
 
@@ -2005,8 +2005,3 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 if (!avctx->refcounted_frames)
 av_frame_unref(avci->to_free);
 }
-
-void ff_decode_bsfs_uninit(AVCodecContext *avctx)
-{
-av_bsf_free(&avctx->internal->bsf);
-}
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index c3e0e82f4c..0d69294def 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -66,8 +66,6 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket 
*pkt);
 
 int ff_decode_bsfs_init(AVCodecContext *avctx);
 
-void ff_decode_bsfs_uninit(AVCodecContext *avctx);
-
 /**
  * Make sure avctx.hw_frames_ctx is set. If it's not set, the function will
  * try to allocate it from hw_device_ctx. If that is not possible, an error
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 91b271a717..3255679550 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1045,7 +1045,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 av_packet_free(&avci->last_pkt_props);
 
 av_packet_free(&avci->ds.in_pkt);
-ff_decode_bsfs_uninit(avctx);
+av_bsf_free(&avci->bsf);
 
 av_buffer_unref(&avci->pool);
 }
@@ -1106,7 +1106,7 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 avctx->hwaccel->uninit(avctx);
 av_freep(&avctx->internal->hwaccel_priv_data);
 
-ff_decode_bsfs_uninit(avctx);
+av_bsf_free(&avctx->internal->bsf);
 
 av_freep(&avctx->internal);
 }
-- 
2.26.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] movenc: Use first H264/HEVC frame as extradata, if it is missing

[Martin Storsjö]

Sticking a full frame in the extradata works, as the code for writing
the avcC/hvcC extracts the relevant parameter set NAL units - provided
that they actually exist in the frame.

Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).

This only works for cases where the moov hasn't already been written
(e.g. when not writing fragmented mp4 with empty_moov, unless using
the delay_moov option).

Signed-off-by: Martin Storsjö 
---
 libavformat/movenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 27d7621e27..6a85440a3f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5584,7 +5584,9 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 
 if ((par->codec_id == AV_CODEC_ID_DNXHD ||
  par->codec_id == AV_CODEC_ID_TRUEHD ||
- par->codec_id == AV_CODEC_ID_AC3) && !trk->vos_len) {
+ par->codec_id == AV_CODEC_ID_AC3 ||
+ par->codec_id == AV_CODEC_ID_H264 ||
+ par->codec_id == AV_CODEC_ID_HEVC) && !trk->vos_len) {
 /* copy frame to create needed atoms */
 trk->vos_len  = size;
 trk->vos_data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
-- 
2.17.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] [RFC] encoder profile validation

[Marton Balint]

On Wed, 20 May 2020, myp...@gmail.com wrote:


On Tue, May 19, 2020 at 2:33 AM Marton Balint  wrote:




On Mon, 18 May 2020, Anton Khirnov wrote:

> Quoting Marton Balint (2020-05-16 15:52:22)
>> Hi,
>>
>> As you may know, a recent patchset enabled AVCodecContext->profile
>> constants to reside in encoders.
>>
>> In order to make a full transition to avctx->profile even in existing
>> encoders which might use a private profile setting, we have to make sure
>> only supported avctx->profile values are passed to encoders.
>>
>> The fact that avctx->profile is not validated is already an issue, and
>> assertions/segmentation faults can already happen in existing encoders
>> (e.g.: aac, mpeg) if unsupported values are passed.
>>
>> AVCodec have a .profiles attribute which supposed to contain the list of
>> supported profiles. However this is problematic because
>> - AVCodecContext->profile is not validated against this list
>> - not all encoders define the list
>> - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL
>> - some encoders support more or less than its currently defined list
>
> All of these sound like bugs that can and should be fixed.
>
>> - AVCodec->profiles contains AVProfiles which supposed to have a textual
>>representation of each profile, which can cause profile name
>>duplications/inconsistencies against libavcodec/profiles.c if the list
>>is different to the one in codecs profile list.
>
> Why should it be different? Isn't that a bug that should be fixed?

The list can be different because possibly not all the profiles which are
recognized by the decoder is supported by the encoder. Also the encoder
can define pseudo profiles which it can support, for example the AAC
encoders have support for FF_PROFILE_MPEG2_AAC_LOW which is LC profile
with some features disabled.

>
>>
>> So I'd rather not user AVCodec->profiles for this validation. I am
>> thinking about two possible solutions:
>
> It seems preferable to me to fix the above issues and not have multiple
> fields with subtly different meanings that are just bound to cause
> confusion and bugs.

I agree that having the list of suppored profiles in two places is wrong,
so in the long run, I would simply deprecate AVCodec->profiles, and use
only the AVOptions to list the supported profiles. Also see my previous
patchset which moves profile names directly to encoders:

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1193

So the supported profiles would be contained in one place, AVOptions.
Even querying the list should be doable, if needed, and
av_get_profile_name can also be modified to get the profile name from the
AVOptions.



So this change will break the API if deprecate AVCodec->profiles? I
know some guys used the FFmpeg API for encoding, it's bad new for them


Which change? According to my plan, validating AVCodecContext->profile 
will not not touch AVCodec->profiles. A potential next change can 
deprecate it, but it is a deprecation, not an instant removal.


Regards,
Marton
___
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/mpegts: fix resync logic stuck in 192 bytes

[Marton Balint]

On Wed, 20 May 2020, lance.lmw...@gmail.com wrote:


On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:

pos47_full is not updated for every packet, and for unseekable inputs the
resync logic might simply skip some 0x47 sync bytes. In order to detect these
let's check for modulo instead of exact value.


Before modifying and returning directly, I considered whether pos is a multiple 
of raw_packet_size, by the debug information, it's not true.


Not always, because sometimes there are 0x47 sync bytes in the packet 
payload as well. But we siply ignore that case because of the return later 
originated from your patch. Checking for modulo allows faster detection 
and it also allows detection when UDP packets contain a single MPEGTS 
packet.



Also it's possible
for the pos of two sync byte > 188/192/204 * n. If that's true, it's not correct
to look it as stats hit by the modulo logic.


I don't understand what you mean here.

Regards,
Marton






Also skip unrecognized sync byte distances instead of considering them as a
failure of detection. It only delays the detection of the new packet size.

Also note that AVIO only buffers a single packet (for UDP/mpegts, that usually
means 1316 bytes), so among every ten consecutive 188-byte MPEGTS packets there
will always be a seek failure, and that caused the old code to not find the 188
byte pattern across 10 consecutive packets.

Signed-off-by: Marton Balint 
---
 libavformat/mpegts.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index a065c61c40..f2b2c05d86 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2846,12 +2846,14 @@ static void reanalyze(MpegTSContext *ts) {
 if (pos < 0)
 return;
 pos -= ts->pos47_full;
-if (pos == TS_PACKET_SIZE) {
+if (pos % TS_PACKET_SIZE == 0) {
 ts->size_stat[0] ++;
-} else if (pos == TS_DVHS_PACKET_SIZE) {
+} if (pos % TS_DVHS_PACKET_SIZE == 0) {
 ts->size_stat[1] ++;
-} else if (pos == TS_FEC_PACKET_SIZE) {
+} if (pos % TS_FEC_PACKET_SIZE == 0) {
 ts->size_stat[2] ++;
+} else {
+return;
 }

 ts->size_stat_count ++;
--
2.26.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".


--
Thanks,
Limin Wang
___
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] [WIP] XComposite window capture demuxer (Linux)

[Marton Balint]

On Tue, 19 May 2020, Nicolas George wrote:


Marton Balint (12020-05-19):

As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on
Intel half a year ago on Ubuntu 18.04, and it simply does not work
correctly. There were crashes, there were random failures with cryptic error
messages, usually at the beginning of the capture, somtimes in the middle of
it. And the captured frame was missing some of the drawn opengl primitives,
it looked like kmsgrab grabbed the frame from the back buffer and not the
front.

So kmsgab on Intel is a no-no for me.


Thanks for the confirmation.

Could you weigh in on the issue of filters/devices changing the OpenGL
global state, please?


If that was the only concern against it, then I'd say it is acceptable. 
But there are some other concerns, also it seems to me xcbgrab can be 
improved to reach the same smoothness as this attempt, and that was the 
main distinctive feature of it. With that advantage lost, I'd say fixing 
xcbgrab is the better bet.


Regards,
Marton
___
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".