Tags

Tags give the ability to mark specific points in history as being important

  • pr-ffstaging-28/softworkz/submit_long_filenames-v8

    e13c6b0a · avformat/file: remove _WIN32 condition · 
    Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

v6

 * wchar_filename.h: added links to .NET source code
 * wchar_filename.h: free allocations on error
 * os_support.hs: use clean and safe way to redirect stat() calls

v7

 * os_support.h: remapped fstat with win32_stat structure
 * os_support.h: use int64_t for some members
 * avformat/file: remove _WIN32 condition

v8

 * os_support.h: documented win32_stat structure
 * os_support.h: renamed function parameters

softworkz (3):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows
  avformat/file: remove _WIN32 condition

 libavformat/file.c         |   4 -
 libavformat/os_support.h   | 116 ++++++++++++++++++------
 libavutil/file_open.c      |   2 +-
 libavutil/wchar_filename.h | 180 +++++++++++++++++++++++++++++++++++++
 4 files changed, 272 insertions(+), 30 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.28.v8.ffstaging.FFmpeg.1653557330.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.ffstaging.FFmpeg.1652435595.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v2.ffstaging.FFmpeg.1652653071.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v3.ffstaging.FFmpeg.1652736203.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v4.ffstaging.FFmpeg.1653305371.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v5.ffstaging.FFmpeg.1653381808.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v6.ffstaging.FFmpeg.1653400709.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v7.ffstaging.FFmpeg.1653430851.ffmpegagent@gmail.com

  • pr-ffstaging-31/softworkz/submit_qsv_sei-v1

    dcf08cd7 · avcodec/qsvdec: Implement SEI parsing for QSV decoders · 
    Implement SEI parsing for QSV decoders

Missing SEI information has always been a major drawback when using the QSV
decoders. I used to think that there's no chance to get at the data without
explicit implementation from the MSDK side (or doing something weird like
parsing in parallel). It turned out that there's a hardly known api method
that provides access to all SEI (h264/hevc) or user data (mpeg2video).

This allows to get things like closed captions, frame packing, display
orientation, HDR data (mastering display, content light level, etc.) without
having to rely on those data being provided by the MSDK as extended buffers.

The commit "Implement SEI parsing for QSV decoders" includes some hard-coded
workarounds for MSDK bugs which I reported:
https://github.com/Intel-Media-SDK/MediaSDK/issues/2597#issuecomment-1072795311

But that doesn't help. Those bugs exist and I'm sharing my workarounds,
which are empirically determined by testing a range of files. If someone is
interested, I can provide private access to a repository where we have been
testing this. Alternatively, I could also leave those workarounds out, and
just skip those SEI types.

In a previous version of this patchset, there was a concern that payload
data might need to be re-ordered. Meanwhile I have researched this carefully
and the conclusion is that this is not required.

My detailed analysis can be found here:
https://gist.github.com/softworkz/36c49586a8610813a32270ee3947a932

softworkz (6):
  avutil/frame: Add av_frame_copy_side_data() and
    av_frame_remove_all_side_data()
  avcodec/vpp_qsv: Copy side data from input to output frame
  avcodec/mpeg12dec: make mpeg_decode_user_data() accessible
  avcodec/hevcdec: make set_side_data() accessible
  avcodec/h264dec: make h264_export_frame_props() accessible
  avcodec/qsvdec: Implement SEI parsing for QSV decoders

 doc/APIchanges               |   4 +
 libavcodec/h264_slice.c      |  98 +++++++--------
 libavcodec/h264dec.h         |   2 +
 libavcodec/hevcdec.c         | 117 +++++++++---------
 libavcodec/hevcdec.h         |   2 +
 libavcodec/mpeg12.h          |  28 +++++
 libavcodec/mpeg12dec.c       |  40 +-----
 libavcodec/qsvdec.c          | 233 +++++++++++++++++++++++++++++++++++
 libavfilter/qsvvpp.c         |   6 +
 libavfilter/vf_overlay_qsv.c |  19 ++-
 libavutil/frame.c            |  67 ++++++----
 libavutil/frame.h            |  32 +++++
 libavutil/version.h          |   2 +-
 13 files changed, 477 insertions(+), 173 deletions(-)

base-commit: b033913d1c5998a29dfd13e9906dd707ff6eff12

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.31.ffstaging.FFmpeg.1653552529.ffmpegagent@gmail.com

  • pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v5

    8c4fe7ff · libx264: Set min build version to 158 · 
    libx264: Set min build version to 158

From: Matt Oliver <protogonoi@gmail.com>

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.30.v5.ffstaging.FFmpeg.1653550090616.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.ffstaging.FFmpeg.1653088310211.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v2.ffstaging.FFmpeg.1653471067991.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v3.ffstaging.FFmpeg.1653471298766.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v4.ffstaging.FFmpeg.1653476739751.ffmpegagent@gmail.com

  • pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v4

    0d1bee35 · libx264: Set min build version to 158 · 
    libx264: Set min build version to 158

From: Matt Oliver <protogonoi@gmail.com>

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.30.v4.ffstaging.FFmpeg.1653476739751.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.ffstaging.FFmpeg.1653088310211.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v2.ffstaging.FFmpeg.1653471067991.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v3.ffstaging.FFmpeg.1653471298766.ffmpegagent@gmail.com

  • pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v3

    374130a0 · libx264: Set min build version to 158 · 
    libx264: Set min build version to 158

From: Matt Oliver <protogonoi@gmail.com>

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.30.v3.ffstaging.FFmpeg.1653471298766.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.ffstaging.FFmpeg.1653088310211.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.v2.ffstaging.FFmpeg.1653471067991.ffmpegagent@gmail.com

  • pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v2

    1696684d · libx264: Set min build version to 158 · 
    libx264: Set min build version to 158

From: softworkz <softworkz@hotmail.com>

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.30.v2.ffstaging.FFmpeg.1653471067991.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.30.ffstaging.FFmpeg.1653088310211.ffmpegagent@gmail.com

  • pr-ffstaging-28/softworkz/submit_long_filenames-v7

    0522fc23 · avformat/file: remove _WIN32 condition · 
    Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

v6

 * wchar_filename.h: added links to .NET source code
 * wchar_filename.h: free allocations on error
 * os_support.hs: use clean and safe way to redirect stat() calls

v7

 * os_support.h: remapped fstat with win32_stat structure
 * os_support.h: use int64_t for some members
 * avformat/file: remove _WIN32 condition

softworkz (3):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows
  avformat/file: remove _WIN32 condition

 libavformat/file.c         |   4 -
 libavformat/os_support.h   | 106 ++++++++++++++++------
 libavutil/file_open.c      |   2 +-
 libavutil/wchar_filename.h | 180 +++++++++++++++++++++++++++++++++++++
 4 files changed, 262 insertions(+), 30 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.28.v7.ffstaging.FFmpeg.1653430851.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.ffstaging.FFmpeg.1652435595.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v2.ffstaging.FFmpeg.1652653071.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v3.ffstaging.FFmpeg.1652736203.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v4.ffstaging.FFmpeg.1653305371.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v5.ffstaging.FFmpeg.1653381808.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v6.ffstaging.FFmpeg.1653400709.ffmpegagent@gmail.com

  • pr-ffstaging-28/softworkz/submit_long_filenames-v6

    6f8d400d · avformat/os_support: Support long file names on Windows · 
    Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

v6

 * wchar_filename.h: added links to .NET source code
 * wchar_filename.h: free allocations on error
 * os_support.hs: use clean and safe way to redirect stat() calls

softworkz (2):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows

 libavformat/os_support.h   |  87 +++++++++++++-----
 libavutil/file_open.c      |   2 +-
 libavutil/wchar_filename.h | 180 +++++++++++++++++++++++++++++++++++++
 3 files changed, 244 insertions(+), 25 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.28.v6.ffstaging.FFmpeg.1653400709.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.ffstaging.FFmpeg.1652435595.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v2.ffstaging.FFmpeg.1652653071.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v3.ffstaging.FFmpeg.1652736203.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v4.ffstaging.FFmpeg.1653305371.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v5.ffstaging.FFmpeg.1653381808.ffmpegagent@gmail.com

  • pr-ffstaging-28/softworkz/submit_long_filenames-v5

    5313aeec · avformat/os_support: Support long file names on Windows · 
    Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

softworkz (2):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows

 libavformat/os_support.h   |  16 ++--
 libavutil/file_open.c      |   2 +-
 libavutil/wchar_filename.h | 166 +++++++++++++++++++++++++++++++++++++
 3 files changed, 178 insertions(+), 6 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.28.v5.ffstaging.FFmpeg.1653381808.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.ffstaging.FFmpeg.1652435595.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v2.ffstaging.FFmpeg.1652653071.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v3.ffstaging.FFmpeg.1652736203.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v4.ffstaging.FFmpeg.1653305371.ffmpegagent@gmail.com

  • pr-ffstaging-28/softworkz/submit_long_filenames-v4

    252ed894 · avformat/os_support: Support long file names on Windows · 
    Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

softworkz (2):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows

 libavformat/os_support.h   |  26 ++++--
 libavutil/file_open.c      |   2 +-
 libavutil/wchar_filename.h | 166 +++++++++++++++++++++++++++++++++++++
 3 files changed, 188 insertions(+), 6 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.28.v4.ffstaging.FFmpeg.1653305371.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.ffstaging.FFmpeg.1652435595.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v2.ffstaging.FFmpeg.1652653071.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.28.v3.ffstaging.FFmpeg.1652736203.ffmpegagent@gmail.com

  • pr-ffstaging-26/softworkz/submit_replace_fopen-v7

    a5266db9 · avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen() · 
    use av_fopen_utf8() instead of plain fopen()

Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages
v5: Add patch to remap ff_open in libavfilter for MSVC on Windows
v6: Add avfilter/file_open.c to "Files without standard license headers"
list
v7: Rebase and use the new avpriv_fopen_utf8() instead

softworkz (2):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()

 libavcodec/dvdsubdec.c            | 2 +-
 libavfilter/af_firequalizer.c     | 2 +-
 libavfilter/vf_deshake.c          | 2 +-
 libavfilter/vf_psnr.c             | 2 +-
 libavfilter/vf_signature.c        | 4 ++--
 libavfilter/vf_ssim.c             | 2 +-
 libavfilter/vf_vidstabdetect.c    | 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c       | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.26.v7.ffstaging.FFmpeg.1653305170.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.ffstaging.FFmpeg.1651945149.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v2.ffstaging.FFmpeg.1652122322889.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v3.ffstaging.FFmpeg.1652747942.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v4.ffstaging.FFmpeg.1652790597.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v5.ffstaging.FFmpeg.1652996437.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v6.ffstaging.FFmpeg.1653002114.ffmpegagent@gmail.com

  • pr-ffstaging-25/softworkz/derive_devices-v2

    d0957afd · avfilter/hwmap,hwupload: use new av_hwdevice_ctx_get_or_create_derived method · 
    Add derive-device function which searches for existing devices in both directions

This is an updated version of: [PATCH v4 1/1] avutils/hwcontext: When
deriving a hwdevice, search for existing device in both directions

There has been an objection that the earlier patchset would change API
behavior, and that this change should be limited to ffmpeg cli.

To achieve this, the API behavior is left unchanged now and a new function
av_hwdevice_ctx_get_or_create_derived() is added and used by the hwupload
and hwmap filters.

v2: Implemented concept for "weak references" to avoid circular reference
lockup.

softworkz (4):
  avutil/buffer: add av_ref_from_buffer() function
  avutils/hwcontext: add derive-device function which searches for
    existing devices in both directions
  lavu: bump minor version and add doc/APIchanges entry for
    av_hwdevice_ctx_get_or_create_derived()
  avfilter/hwmap,hwupload: use new av_hwdevice_ctx_get_or_create_derived
    method

 doc/APIchanges                 |   6 ++
 libavfilter/vf_hwmap.c         |   4 +-
 libavfilter/vf_hwupload.c      |   2 +-
 libavutil/buffer.c             |  16 ++++
 libavutil/buffer.h             |   8 ++
 libavutil/hwcontext.c          | 167 +++++++++++++++++++++++++++++++--
 libavutil/hwcontext.h          |  20 ++++
 libavutil/hwcontext_internal.h |  11 +++
 libavutil/hwcontext_qsv.c      |  11 ++-
 libavutil/version.h            |   4 +-
 10 files changed, 234 insertions(+), 15 deletions(-)

base-commit: 9ab20b1614194280b862d98dfcdb7b1bcff03329

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.25.v2.ffstaging.FFmpeg.1653142062.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.25.ffstaging.FFmpeg.1651349262.ffmpegagent@gmail.com

  • pr-ffstaging-12/softworkz/master-upstream_asf_4-v5

    a05986d7 · libavformat/asfdec: fix variable types and add checks for unsupported values · 
    libavformat/asf: fix handling of byte array length values

The spec allows attachment sizes of up to UINT32_MAX while we can handle
only sizes up to INT32_MAX (in downstream code)

The debug.assert in get_tag didn't really address this, and truncating the
value_len in calling methods cannot be used because the length value is
required in order to continue parsing. This adds a check with log message in
ff_asf_handle_byte_array to handle those (rare) cases.

v2: Rebased & PING
v3: Adjustments suggested by Michael
v4: 1 of 11 merged, 10 to go..
v5: adjusted commit message of 4/10 as requested

softworkz (10):
  libavformat/asf: fix handling of byte array length values
  libavformat/asfdec: fix get_value return type and add checks for
  libavformat/asfdec: fix type of value_len
  libavformat/asfdec: fixing get_tag
  libavformat/asfdec: implement parsing of GUID values
  libavformat/asfdec: avoid clang warnings
  libavformat/asfdec: remove variable redefinition in inner scope
  libavformat/asfdec: ensure variables are initialized
  libavformat/asfdec: fix parameter type in asf_read_stream_propertie()
  libavformat/asfdec: fix variable types and add checks for unsupported
    values

 libavformat/asf.c      |   8 +-
 libavformat/asf.h      |   2 +-
 libavformat/asfdec_f.c | 338 +++++++++++++++++++++++++++--------------
 3 files changed, 229 insertions(+), 119 deletions(-)

base-commit: 9ab20b1614194280b862d98dfcdb7b1bcff03329

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.12.v5.ffstaging.FFmpeg.1653110500.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.12.ffstaging.FFmpeg.1640186030.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.12.v2.ffstaging.FFmpeg.1651916204.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.12.v3.ffstaging.FFmpeg.1651978882.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.12.v4.ffstaging.FFmpeg.1652561722.ffmpegagent@gmail.com

  • pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v1

    bbe97f5e · libx264: Set min build version to 158 · 
    libx264: Set min build version to 158

From: Matt Oliver <protogonoi@gmail.com>

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

Alternatively we can detect the x264 build version in configure
and keep the fallback of manually setting the flag on older x264
builds that arent using pkgconfig (to keep the old behaviour) but
that requires some complex configure changes.

Submitted-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.30.ffstaging.FFmpeg.1653088310211.ffmpegagent@gmail.com

  • pr-ffstaging-29/softworkz/submit_x264_api_imports-v2

    bc86a3e9 · avcodec/libx264: allow to disable definition of X264_API_IMPORTS macro · 
    avcodec/libx264: allow to disable definition of X264_API_IMPORTS macro

From: softworkz <softworkz@hotmail.com>

When MSVC is used, the definition of X264_API_IMPORTS is
required for shared linking to libx264.dll, but it must
not be defined in case of statically linking to libx264.

Defining DISABLE_X264_API_IMPORTS allows to disable the
definition of X264_API_IMPORTS for those cases.

This has become necessary due to:

https://code.videolan.org/videolan/x264/-/blob/
bfc87b7a330f75f5c9a21e56081e4b20344f139e/x264.h#L63-67

A better fix would eventually be this one:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/287426.html

But there has been disagreement and the issue stalled.

This patch is intended to be a stop-gap solution until
the mention fix will have been worked out.

Signed-off-by: softworkz <softworkz@hotmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.29.v2.ffstaging.FFmpeg.1653060204841.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.29.ffstaging.FFmpeg.1653000752870.ffmpegagent@gmail.com

  • pr-ffstaging-26/softworkz/submit_replace_fopen-v6

    4035d5dd · avfilter: Make avpriv_open a library-internal function on msvcrt · 
    use av_fopen_utf8() instead of plain fopen()

Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages
v5: Add patch to remap ff_open in libavfilter for MSVC on Windows
v6: Add avfilter/file_open.c to "Files without standard license headers"
list

softworkz (3):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()
  avfilter: Make avpriv_open a library-internal function on msvcrt

 libavcodec/dvdsubdec.c            | 2 +-
 libavfilter/Makefile              | 1 +
 libavfilter/af_firequalizer.c     | 2 +-
 libavfilter/file_open.c           | 1 +
 libavfilter/vf_deshake.c          | 2 +-
 libavfilter/vf_psnr.c             | 2 +-
 libavfilter/vf_signature.c        | 4 ++--
 libavfilter/vf_ssim.c             | 2 +-
 libavfilter/vf_vidstabdetect.c    | 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c       | 2 +-
 tests/ref/fate/source             | 1 +
 12 files changed, 13 insertions(+), 10 deletions(-)
 create mode 100644 libavfilter/file_open.c

base-commit: 41a558fea06cc0a23b8d2d0dfb03ef6a25cf5100

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.26.v6.ffstaging.FFmpeg.1653002114.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.ffstaging.FFmpeg.1651945149.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v2.ffstaging.FFmpeg.1652122322889.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v3.ffstaging.FFmpeg.1652747942.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v4.ffstaging.FFmpeg.1652790597.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v5.ffstaging.FFmpeg.1652996437.ffmpegagent@gmail.com

  • pr-ffstaging-29/softworkz/submit_x264_api_imports-v1

    640a17b8 · avcodec/libx264: don't define X264_API_IMPORTS when compiling static · 
    avcodec/libx264: don't define X264_API_IMPORTS when compiling static

From: softworkz <softworkz@hotmail.com>

The definition of X264_API_IMPORTS is required for shared linking
(when MSVC is used) but it must not be defined in case of static
builds as is stated in x264.h:

https://code.videolan.org/videolan/x264/-/blob/
bfc87b7a330f75f5c9a21e56081e4b20344f139e/x264.h#L63-67

This commit adds a check for the definition of _LIB which indicates
static linking.

Signed-off-by: softworkz <softworkz@hotmail.com>

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.29.ffstaging.FFmpeg.1653000752870.ffmpegagent@gmail.com

  • pr-ffstaging-26/softworkz/submit_replace_fopen-v5

    5e50103a · avfilter: Make avpriv_open a library-internal function on msvcrt · 
    use av_fopen_utf8() instead of plain fopen()

Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages
v5: Add patch to remap ff_open in libavfilter for MSVC on Windows

softworkz (3):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()
  avfilter: Make avpriv_open a library-internal function on msvcrt

 libavcodec/dvdsubdec.c            | 2 +-
 libavfilter/Makefile              | 1 +
 libavfilter/af_firequalizer.c     | 2 +-
 libavfilter/file_open.c           | 1 +
 libavfilter/vf_deshake.c          | 2 +-
 libavfilter/vf_psnr.c             | 2 +-
 libavfilter/vf_signature.c        | 4 ++--
 libavfilter/vf_ssim.c             | 2 +-
 libavfilter/vf_vidstabdetect.c    | 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c       | 2 +-
 11 files changed, 12 insertions(+), 10 deletions(-)
 create mode 100644 libavfilter/file_open.c

base-commit: 41a558fea06cc0a23b8d2d0dfb03ef6a25cf5100

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.26.v5.ffstaging.FFmpeg.1652996437.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.ffstaging.FFmpeg.1651945149.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v2.ffstaging.FFmpeg.1652122322889.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v3.ffstaging.FFmpeg.1652747942.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v4.ffstaging.FFmpeg.1652790597.ffmpegagent@gmail.com

  • pr-ffstaging-26/softworkz/submit_replace_fopen-v4

    68192b1a · avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen() · 
    use av_fopen_utf8() instead of plain fopen()

Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages

softworkz (2):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()

 libavcodec/dvdsubdec.c            | 2 +-
 libavfilter/af_firequalizer.c     | 2 +-
 libavfilter/vf_deshake.c          | 2 +-
 libavfilter/vf_psnr.c             | 2 +-
 libavfilter/vf_signature.c        | 4 ++--
 libavfilter/vf_ssim.c             | 2 +-
 libavfilter/vf_vidstabdetect.c    | 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c       | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

base-commit: e3580f60775c897c3b13b178c57ab191ecc4a031

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.26.v4.ffstaging.FFmpeg.1652790597.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.ffstaging.FFmpeg.1651945149.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v2.ffstaging.FFmpeg.1652122322889.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v3.ffstaging.FFmpeg.1652747942.ffmpegagent@gmail.com

  • pr-ffstaging-26/softworkz/submit_replace_fopen-v3

    1be02d9e · avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen() · 
    use av_fopen_utf8() instead of plain fopen()

Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements

softworkz (2):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen()

 libavcodec/dvdsubdec.c            | 2 +-
 libavfilter/af_firequalizer.c     | 2 +-
 libavfilter/vf_deshake.c          | 2 +-
 libavfilter/vf_psnr.c             | 2 +-
 libavfilter/vf_signature.c        | 4 ++--
 libavfilter/vf_ssim.c             | 2 +-
 libavfilter/vf_vidstabdetect.c    | 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c       | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

base-commit: e3580f60775c897c3b13b178c57ab191ecc4a031

Submitted-As: https://master.gitmailbox.com/ffmpegdev/pull.26.v3.ffstaging.FFmpeg.1652747942.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.ffstaging.FFmpeg.1651945149.ffmpegagent@gmail.com
In-Reply-To: https://master.gitmailbox.com/ffmpegdev/pull.26.v2.ffstaging.FFmpeg.1652122322889.ffmpegagent@gmail.com