Re: [FFmpeg-devel] [PATCH] avformat/fifo: utilize a clone packet for muxing
On Thu, Jan 14, 2021 at 2:13 AM Jan Ekström wrote: > > On Tue, Jan 12, 2021 at 9:59 AM Jan Ekström wrote: > > > > On Mon, Jan 11, 2021 at 10:53 PM Andreas Rheinhardt > > wrote: > > > > > > Jan Ekström: > > > > On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström wrote: > > > >> > > > >> From: Jan Ekström > > > >> > > > >> This way the timestamp adjustments do not have to be manually > > > >> undone in case of failure and need to recover/retry. > > > >> > > > >> Fixes an issue where the timestamp adjustment would be re-done over > > > >> and over again when recovery by muxing the same AVPacket again is > > > >> attempted. Would become visible if the fifo muxer's time base and > > > >> the output muxer's time base do not match (by the value either > > > >> becoming smaller and smaller, or larger and larger). > > > >> > > > >> Signed-off-by: Jan Ekström > > > > > > > > Ping. > > > > > > > > Unless someone finds some disgruntling points in this patch, I will > > > > soon move towards applying this. > > > > > > > > My initial plan was to make a simplified v2 where the output AVPacket > > > > was on stack limited to the fifo_thread_write_packet context, but > > > > apparently gradual removal of stack usage of AVPackets is being > > > > planned, so I decided to not to. > > > > > > > > Best regards, > > > > Jan > > > > > > Can't you just record (in FifoMessage) whether the timestamps have > > > already been converted to the desired timebase? > > > > Back when I found this issue in this function that aligns the time > > bases and writes the packet on the underlying avformat context, I did > > not think of that, but I did think of reversing the time base scaling > > in case of failure. That I then opted not to do due to possibly being > > inaccurate unless I saved all of those values from the AVPacket that > > av_packet_rescale_ts touches. Thus, I settled on just utilizing a > > reference/copy for the actual muxing, so that it could be easily > > discarded and the original AVPacket's values were not lost. > > > > > (Or why not just copy > > > the timebase chosen by the internal muxer to the user-visible stream so > > > that we don't even have to convert it? This is how muxers always operate.) > > > > This one sounds more like the correct way in the end, if possible. My > > attempt for now was to just fix an issue within the current logic > > (time base handling in case of failure was forgotten). I am trying to > > remind myself at which point the AVStreams should no longer be > > poked/modified as far as time base is concerned... init or header? > > init seems to call init_pts in libavformat/mux.c, so my initial > > guesstimate is that where fifo.c is currently doing its things > > (fifo_mux_init), you could just add the time base sync. Most API > > clients tend to call only avformat_write_header so in that sense with > > various API clients you probably wouldn't even notice the difference > > :) . > > So I just double-checked the docs in avformat.h, and the point of > update given to the API user is the header writing, which in the fifo > muxer is being done asynchronously in its own thread. We would have to > basically make fifo_write_header wait until the first time > avformat_write_header gets successfully called in > fifo_thread_write_header. > > While possible - and could make the time base juggling unnecessary - > not sure if it would be my first attempt. :) I'd probably first want > to get the time base logic fixed since that would be limited to > fifo_thread_write_packet. > > If there were question marks on why I utilized a separate reference > AVPacket, it was mostly to keep the time related values original in > the fed AVPacket, thus backing up all of the time values that > av_packet_rescale_ts might touch (if new time fields were to be added > to AVPacket, and modified by av_packet_rescale_ts, then the code would > have to be updated if I had just backed up the values manually and > then passed them back). In addition to possibly causing a new buffer > to be allocated in case of a non-refcounted buffer (although the fifo > muxer does do an av_packet_ref for all input packets, so everything > fed in through the worker thread should be reference counted), It does > cause the side data etc to be copied as well, which is of course > unfortunate. In the testing that was done this did not seem to cause > major issues, though. > > If someone feels heavily about this, I can of course write > ff_packet_copy_ts(AVPacket *dst, const AVPacket *src), which could > then be utilized against the dummy AVPacket. > Ping on this case. 1. Currently since fifo muxer seems to already generate a refcounted AVPacket when taking in an AVPacket, doing another av_packet_ref is indeed overkill, but does not seem to be a too big of an overhead (esp. since done asynchronously), and makes sure all of the relevant timestamp fields are backed up (since they were actually not touched at all in the original reference). Additionally, there
Re: [FFmpeg-devel] [PATCH v4 0/4] Initial implementation of TTML encoding/muxing
On Fri, Jan 22, 2021 at 1:21 PM Jan Ekström wrote:
>
> I've intentionally kept this initial version simple (no styling etc) to focus
> on the basics. As this goes through review, additional features can be added
> (I had initial PoC for styling implemented some time around previous VDD), and
> there is another patch set in my queue which would then add support for muxing
> TTML into MP4.
>
> Changes from the third version:
> - Updated the result of the ffprobe XML output test, as I missed it when
> updating the exact escape mode utilized.
>
> Jan
>
>
> Jan Ekström (3):
> avutil/{avstring,bprint}: add XML attribute value escape modes
> ffprobe: switch to av_bprint_escape for XML escaping
> {avcodec,avformat}: add TTML encoder and muxer
>
> Stefano Sabatini (1):
> avutil/{avstring,bprint}: add XML escaping from ffprobe to avutil
>
Ping for reviews since as far as I can tell I have taken into account
all of the previous remarks from Andreas and Nicolas.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/utils: reset event_flags if extradata is not extracted correctly
On Mon, Jan 25, 2021 at 12:49 AM Anton Khirnov wrote: > > Quoting Linjie Fu (2021-01-24 16:05:56) > > Regression since 87f0c8280. > > > > If the extradata of a stream could not be extracted correctly, > > codec_info_nb_frames would remain zero, while st->event_flag would still > > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS. > > > > The two expressions could be different in this case, hence reset > > event_flags and calculate the correct score. > > > > Fix #9029. > > The ticket mentions ffplay, but ffplay does not access event_flags. > You are right, this helps ffmpeg cmdline to copy and dump: $ ffmpeg -i sample_cut.flv -c copy -y dump.mp4 Before 87f0c8280 and after this patch: audio streams could be dumped and playable, while video streams still not. 87f0c8280..master: Error reporting and quits. [mp4 @ 0x7fb276809a00] dimensions not set Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument Error initializing output stream 0:1 -- I'd change the commit message to "#9029 related" for this, since the ffplay issue remains the same. - linjie ___ 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]lavfi/vflip: Support Bayer vertical flip
Am Sa., 5. Sept. 2020 um 21:15 Uhr schrieb Carl Eugen Hoyos : > Attached patch fixes ticket #8819. Paul, I believe you had an objection but I forgot what it was... Please comment, Carl Eugen ___ 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] avcodec: deprecate AVCodecContext.debug_mv
On 1/24/2021 8:30 PM, Andreas Rheinhardt wrote:
James Almer:
On 1/24/2021 8:14 PM, Andreas Rheinhardt wrote:
James Almer:
It's been unused for almost three years now.
Signed-off-by: James Almer
---
doc/APIchanges | 4
libavcodec/avcodec.h | 7 ---
libavcodec/pthread_frame.c | 4
libavcodec/version.h | 10 +-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bbf56a5385..51f97b2759 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-01-xx - xx - lavc 58.118.100 - avcodec.h
+ deprecate AVCodecContext.debug_mv, FF_DEBUG_VIS_MV_P_FOR,
FF_DEBUG_VIS_MV_B_FOR,
+ FF_DEBUG_VIS_MV_B_BACK
+
2021-01-11 - xx - lavc 58.116.100 - avcodec.h
Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index dc8738c819..eafc2e84e3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2141,15 +2141,16 @@ typedef struct AVCodecContext {
*/
int seek_preroll;
+#if FF_API_DEBUG_MV
/**
- * debug motion vectors
- * - encoding: Set by user.
- * - decoding: Set by user.
+ * @deprecated unused
*/
+ attribute_deprecated
int debug_mv;
#define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward
predicted MVs of P frames
#define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward
predicted MVs of B frames
#define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward
predicted MVs of B frames
+#endif
/**
* custom intra quantization matrix
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index a570e25e0d..3abb691ac7 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -342,7 +342,11 @@ static int
update_context_from_user(AVCodecContext *dst, AVCodecContext *src)
dst->opaque = src->opaque;
dst->debug = src->debug;
+#if FF_API_DEBUG_MV
+FF_DISABLE_DEPRECATION_WARNINGS
dst->debug_mv = src->debug_mv;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
If debug_mv is unused, then why don't you just remove the assignment?
It's a "set by user" field, so even if whatever value it may contain is
never used by libavcodec, removing this would be a change in behavior.
Admittedly harmless, but a change nonetheless, so I'm inclined to just
leave it there.
What user-visible behaviour would change?
Oh, these don't have the user context as dst (I recall now that Hendrik
implemented a separate callback for that purpose on his LAVFilters
fork). Changed locally to remove it, then.
dst->slice_flags = src->slice_flags;
dst->flags2 = src->flags2;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9f80caa9e0..f3974c2cb3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 117
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 118
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT
AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
@@ -54,9 +54,6 @@
#ifndef FF_API_LOWRES
#define FF_API_LOWRES (LIBAVCODEC_VERSION_MAJOR < 59)
#endif
-#ifndef FF_API_DEBUG_MV
-#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 58)
-#endif
Why is this hunk not in the preceding patch?
I figured I'd leave the actual macro in place instead of removing it and
then re-adding it in a following commit, but i can change it if you
prefer that way.
Keeping it would make sense if you just replaced 58 by 60; but not if
you are moving this to the end anyway.
I don't see how one way makes sense but the other doesn't. It's all
cosmetic. But sure, changed locally to remove it in the first patch.
#ifndef FF_API_AVCTX_TIMEBASE
#define FF_API_AVCTX_TIMEBASE (LIBAVCODEC_VERSION_MAJOR < 59)
#endif
@@ -150,5 +147,8 @@
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
+#ifndef FF_API_DEBUG_MV
+#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
+#endif
#endif /* AVCODEC_VERSION_H */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: deprecate AVCodecContext.debug_mv
James Almer:
> On 1/24/2021 8:14 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> It's been unused for almost three years now.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> doc/APIchanges | 4
>>> libavcodec/avcodec.h | 7 ---
>>> libavcodec/pthread_frame.c | 4
>>> libavcodec/version.h | 10 +-
>>> 4 files changed, 17 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index bbf56a5385..51f97b2759 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>>> API changes, most recent first:
>>> +2021-01-xx - xx - lavc 58.118.100 - avcodec.h
>>> + deprecate AVCodecContext.debug_mv, FF_DEBUG_VIS_MV_P_FOR,
>>> FF_DEBUG_VIS_MV_B_FOR,
>>> + FF_DEBUG_VIS_MV_B_BACK
>>> +
>>> 2021-01-11 - xx - lavc 58.116.100 - avcodec.h
>>> Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>> index dc8738c819..eafc2e84e3 100644
>>> --- a/libavcodec/avcodec.h
>>> +++ b/libavcodec/avcodec.h
>>> @@ -2141,15 +2141,16 @@ typedef struct AVCodecContext {
>>> */
>>> int seek_preroll;
>>> +#if FF_API_DEBUG_MV
>>> /**
>>> - * debug motion vectors
>>> - * - encoding: Set by user.
>>> - * - decoding: Set by user.
>>> + * @deprecated unused
>>> */
>>> + attribute_deprecated
>>> int debug_mv;
>>> #define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward
>>> predicted MVs of P frames
>>> #define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward
>>> predicted MVs of B frames
>>> #define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward
>>> predicted MVs of B frames
>>> +#endif
>>> /**
>>> * custom intra quantization matrix
>>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
>>> index a570e25e0d..3abb691ac7 100644
>>> --- a/libavcodec/pthread_frame.c
>>> +++ b/libavcodec/pthread_frame.c
>>> @@ -342,7 +342,11 @@ static int
>>> update_context_from_user(AVCodecContext *dst, AVCodecContext *src)
>>> dst->opaque = src->opaque;
>>> dst->debug = src->debug;
>>> +#if FF_API_DEBUG_MV
>>> +FF_DISABLE_DEPRECATION_WARNINGS
>>> dst->debug_mv = src->debug_mv;
>>> +FF_ENABLE_DEPRECATION_WARNINGS
>>> +#endif
>>
>> If debug_mv is unused, then why don't you just remove the assignment?
>
> It's a "set by user" field, so even if whatever value it may contain is
> never used by libavcodec, removing this would be a change in behavior.
> Admittedly harmless, but a change nonetheless, so I'm inclined to just
> leave it there.
>
What user-visible behaviour would change?
>>
>>> dst->slice_flags = src->slice_flags;
>>> dst->flags2 = src->flags2;
>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>> index 9f80caa9e0..f3974c2cb3 100644
>>> --- a/libavcodec/version.h
>>> +++ b/libavcodec/version.h
>>> @@ -28,8 +28,8 @@
>>> #include "libavutil/version.h"
>>> #define LIBAVCODEC_VERSION_MAJOR 58
>>> -#define LIBAVCODEC_VERSION_MINOR 117
>>> -#define LIBAVCODEC_VERSION_MICRO 101
>>> +#define LIBAVCODEC_VERSION_MINOR 118
>>> +#define LIBAVCODEC_VERSION_MICRO 100
>>> #define LIBAVCODEC_VERSION_INT
>>> AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
>>>
>>> LIBAVCODEC_VERSION_MINOR, \
>>> @@ -54,9 +54,6 @@
>>> #ifndef FF_API_LOWRES
>>> #define FF_API_LOWRES (LIBAVCODEC_VERSION_MAJOR < 59)
>>> #endif
>>> -#ifndef FF_API_DEBUG_MV
>>> -#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 58)
>>> -#endif
>>
>> Why is this hunk not in the preceding patch?
>
> I figured I'd leave the actual macro in place instead of removing it and
> then re-adding it in a following commit, but i can change it if you
> prefer that way.
>
Keeping it would make sense if you just replaced 58 by 60; but not if
you are moving this to the end anyway.
>>
>>> #ifndef FF_API_AVCTX_TIMEBASE
>>> #define FF_API_AVCTX_TIMEBASE (LIBAVCODEC_VERSION_MAJOR < 59)
>>> #endif
>>> @@ -150,5 +147,8 @@
>>> #ifndef FF_API_THREAD_SAFE_CALLBACKS
>>> #define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
>>> #endif
>>> +#ifndef FF_API_DEBUG_MV
>>> +#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
>>> +#endif
>>> #endif /* AVCODEC_VERSION_H */
>>>
___
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] avcodec: deprecate AVCodecContext.debug_mv
On 1/24/2021 8:14 PM, Andreas Rheinhardt wrote:
James Almer:
It's been unused for almost three years now.
Signed-off-by: James Almer
---
doc/APIchanges | 4
libavcodec/avcodec.h | 7 ---
libavcodec/pthread_frame.c | 4
libavcodec/version.h | 10 +-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bbf56a5385..51f97b2759 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-01-xx - xx - lavc 58.118.100 - avcodec.h
+ deprecate AVCodecContext.debug_mv, FF_DEBUG_VIS_MV_P_FOR,
FF_DEBUG_VIS_MV_B_FOR,
+ FF_DEBUG_VIS_MV_B_BACK
+
2021-01-11 - xx - lavc 58.116.100 - avcodec.h
Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index dc8738c819..eafc2e84e3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2141,15 +2141,16 @@ typedef struct AVCodecContext {
*/
int seek_preroll;
+#if FF_API_DEBUG_MV
/**
- * debug motion vectors
- * - encoding: Set by user.
- * - decoding: Set by user.
+ * @deprecated unused
*/
+attribute_deprecated
int debug_mv;
#define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward predicted MVs
of P frames
#define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward predicted MVs
of B frames
#define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward predicted MVs
of B frames
+#endif
/**
* custom intra quantization matrix
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index a570e25e0d..3abb691ac7 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -342,7 +342,11 @@ static int update_context_from_user(AVCodecContext *dst,
AVCodecContext *src)
dst->opaque = src->opaque;
dst->debug= src->debug;
+#if FF_API_DEBUG_MV
+FF_DISABLE_DEPRECATION_WARNINGS
dst->debug_mv = src->debug_mv;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
If debug_mv is unused, then why don't you just remove the assignment?
It's a "set by user" field, so even if whatever value it may contain is
never used by libavcodec, removing this would be a change in behavior.
Admittedly harmless, but a change nonetheless, so I'm inclined to just
leave it there.
dst->slice_flags = src->slice_flags;
dst->flags2 = src->flags2;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9f80caa9e0..f3974c2cb3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 117
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 118
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
@@ -54,9 +54,6 @@
#ifndef FF_API_LOWRES
#define FF_API_LOWRES(LIBAVCODEC_VERSION_MAJOR < 59)
#endif
-#ifndef FF_API_DEBUG_MV
-#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 58)
-#endif
Why is this hunk not in the preceding patch?
I figured I'd leave the actual macro in place instead of removing it and
then re-adding it in a following commit, but i can change it if you
prefer that way.
#ifndef FF_API_AVCTX_TIMEBASE
#define FF_API_AVCTX_TIMEBASE(LIBAVCODEC_VERSION_MAJOR < 59)
#endif
@@ -150,5 +147,8 @@
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
+#ifndef FF_API_DEBUG_MV
+#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
+#endif
#endif /* AVCODEC_VERSION_H */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: deprecate AVCodecContext.debug_mv
James Almer:
> It's been unused for almost three years now.
>
> Signed-off-by: James Almer
> ---
> doc/APIchanges | 4
> libavcodec/avcodec.h | 7 ---
> libavcodec/pthread_frame.c | 4
> libavcodec/version.h | 10 +-
> 4 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index bbf56a5385..51f97b2759 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2021-01-xx - xx - lavc 58.118.100 - avcodec.h
> + deprecate AVCodecContext.debug_mv, FF_DEBUG_VIS_MV_P_FOR,
> FF_DEBUG_VIS_MV_B_FOR,
> + FF_DEBUG_VIS_MV_B_BACK
> +
> 2021-01-11 - xx - lavc 58.116.100 - avcodec.h
>Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index dc8738c819..eafc2e84e3 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2141,15 +2141,16 @@ typedef struct AVCodecContext {
> */
> int seek_preroll;
>
> +#if FF_API_DEBUG_MV
> /**
> - * debug motion vectors
> - * - encoding: Set by user.
> - * - decoding: Set by user.
> + * @deprecated unused
> */
> +attribute_deprecated
> int debug_mv;
> #define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward predicted MVs
> of P frames
> #define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward predicted MVs
> of B frames
> #define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward predicted MVs
> of B frames
> +#endif
>
> /**
> * custom intra quantization matrix
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index a570e25e0d..3abb691ac7 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -342,7 +342,11 @@ static int update_context_from_user(AVCodecContext *dst,
> AVCodecContext *src)
>
> dst->opaque = src->opaque;
> dst->debug= src->debug;
> +#if FF_API_DEBUG_MV
> +FF_DISABLE_DEPRECATION_WARNINGS
> dst->debug_mv = src->debug_mv;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
If debug_mv is unused, then why don't you just remove the assignment?
>
> dst->slice_flags = src->slice_flags;
> dst->flags2 = src->flags2;
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 9f80caa9e0..f3974c2cb3 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -28,8 +28,8 @@
> #include "libavutil/version.h"
>
> #define LIBAVCODEC_VERSION_MAJOR 58
> -#define LIBAVCODEC_VERSION_MINOR 117
> -#define LIBAVCODEC_VERSION_MICRO 101
> +#define LIBAVCODEC_VERSION_MINOR 118
> +#define LIBAVCODEC_VERSION_MICRO 100
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> @@ -54,9 +54,6 @@
> #ifndef FF_API_LOWRES
> #define FF_API_LOWRES(LIBAVCODEC_VERSION_MAJOR < 59)
> #endif
> -#ifndef FF_API_DEBUG_MV
> -#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 58)
> -#endif
Why is this hunk not in the preceding patch?
> #ifndef FF_API_AVCTX_TIMEBASE
> #define FF_API_AVCTX_TIMEBASE(LIBAVCODEC_VERSION_MAJOR < 59)
> #endif
> @@ -150,5 +147,8 @@
> #ifndef FF_API_THREAD_SAFE_CALLBACKS
> #define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
> #endif
> +#ifndef FF_API_DEBUG_MV
> +#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
> +#endif
>
> #endif /* AVCODEC_VERSION_H */
>
___
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/2] avcodec: deprecate AVCodecContext.debug_mv
It's been unused for almost three years now.
Signed-off-by: James Almer
---
doc/APIchanges | 4
libavcodec/avcodec.h | 7 ---
libavcodec/pthread_frame.c | 4
libavcodec/version.h | 10 +-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bbf56a5385..51f97b2759 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-01-xx - xx - lavc 58.118.100 - avcodec.h
+ deprecate AVCodecContext.debug_mv, FF_DEBUG_VIS_MV_P_FOR,
FF_DEBUG_VIS_MV_B_FOR,
+ FF_DEBUG_VIS_MV_B_BACK
+
2021-01-11 - xx - lavc 58.116.100 - avcodec.h
Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index dc8738c819..eafc2e84e3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2141,15 +2141,16 @@ typedef struct AVCodecContext {
*/
int seek_preroll;
+#if FF_API_DEBUG_MV
/**
- * debug motion vectors
- * - encoding: Set by user.
- * - decoding: Set by user.
+ * @deprecated unused
*/
+attribute_deprecated
int debug_mv;
#define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward predicted MVs of
P frames
#define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward predicted MVs of
B frames
#define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward predicted MVs
of B frames
+#endif
/**
* custom intra quantization matrix
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index a570e25e0d..3abb691ac7 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -342,7 +342,11 @@ static int update_context_from_user(AVCodecContext *dst,
AVCodecContext *src)
dst->opaque = src->opaque;
dst->debug= src->debug;
+#if FF_API_DEBUG_MV
+FF_DISABLE_DEPRECATION_WARNINGS
dst->debug_mv = src->debug_mv;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
dst->slice_flags = src->slice_flags;
dst->flags2 = src->flags2;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9f80caa9e0..f3974c2cb3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,8 +28,8 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 117
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 118
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
@@ -54,9 +54,6 @@
#ifndef FF_API_LOWRES
#define FF_API_LOWRES(LIBAVCODEC_VERSION_MAJOR < 59)
#endif
-#ifndef FF_API_DEBUG_MV
-#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 58)
-#endif
#ifndef FF_API_AVCTX_TIMEBASE
#define FF_API_AVCTX_TIMEBASE(LIBAVCODEC_VERSION_MAJOR < 59)
#endif
@@ -150,5 +147,8 @@
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
+#ifndef FF_API_DEBUG_MV
+#define FF_API_DEBUG_MV (LIBAVCODEC_VERSION_MAJOR < 60)
+#endif
#endif /* AVCODEC_VERSION_H */
--
2.30.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 1/2] avcodec: remove long dead debug_mv code
FF_API_DEBUG_MV has been zero since ffmpeg 4.0
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 6 +-
libavcodec/avcodec.h | 24 ---
libavcodec/mpegpicture.c | 3 -
libavcodec/mpegutils.c | 128 -
libavcodec/options_table.h | 7 --
libavcodec/pthread_frame.c | 4 --
6 files changed, 1 insertion(+), 171 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4419c68d11..d7c833be63 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4032,11 +4032,7 @@ static int check_keyboard_interaction(int64_t cur_time)
if(key == 'D') {
debug = input_streams[0]->dec_ctx->debug << 1;
if(!debug) debug = 1;
-while(debug & (FF_DEBUG_DCT_COEFF
-#if FF_API_DEBUG_MV
-
|FF_DEBUG_VIS_QP|FF_DEBUG_VIS_MB_TYPE
-#endif
-
)) //unsupported, would just crash
+while (debug & FF_DEBUG_DCT_COEFF) //unsupported, would just crash
debug += debug;
}else{
char buf[32];
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fdb4276260..dc8738c819 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1619,39 +1619,17 @@ typedef struct AVCodecContext {
#define FF_DEBUG_BITSTREAM 4
#define FF_DEBUG_MB_TYPE 8
#define FF_DEBUG_QP 16
-#if FF_API_DEBUG_MV
-/**
- * @deprecated this option does nothing
- */
-#define FF_DEBUG_MV 32
-#endif
#define FF_DEBUG_DCT_COEFF 0x0040
#define FF_DEBUG_SKIP0x0080
#define FF_DEBUG_STARTCODE 0x0100
#define FF_DEBUG_ER 0x0400
#define FF_DEBUG_MMCO0x0800
#define FF_DEBUG_BUGS0x1000
-#if FF_API_DEBUG_MV
-#define FF_DEBUG_VIS_QP 0x2000
-#define FF_DEBUG_VIS_MB_TYPE 0x4000
-#endif
#define FF_DEBUG_BUFFERS 0x8000
#define FF_DEBUG_THREADS 0x0001
#define FF_DEBUG_GREEN_MD0x0080
#define FF_DEBUG_NOMC0x0100
-#if FF_API_DEBUG_MV
-/**
- * debug
- * - encoding: Set by user.
- * - decoding: Set by user.
- */
-int debug_mv;
-#define FF_DEBUG_VIS_MV_P_FOR 0x0001 // visualize forward predicted MVs
of P-frames
-#define FF_DEBUG_VIS_MV_B_FOR 0x0002 // visualize forward predicted MVs
of B-frames
-#define FF_DEBUG_VIS_MV_B_BACK 0x0004 // visualize backward predicted MVs
of B-frames
-#endif
-
/**
* Error recognition; may misdetect some more or less valid parts as
errors.
* - encoding: unused
@@ -2163,7 +2141,6 @@ typedef struct AVCodecContext {
*/
int seek_preroll;
-#if !FF_API_DEBUG_MV
/**
* debug motion vectors
* - encoding: Set by user.
@@ -2173,7 +2150,6 @@ typedef struct AVCodecContext {
#define FF_DEBUG_VIS_MV_P_FOR 0x0001 //visualize forward predicted MVs of
P frames
#define FF_DEBUG_VIS_MV_B_FOR 0x0002 //visualize forward predicted MVs of
B frames
#define FF_DEBUG_VIS_MV_B_BACK 0x0004 //visualize backward predicted MVs
of B frames
-#endif
/**
* custom intra quantization matrix
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index e495e315e6..e3f648895d 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -203,9 +203,6 @@ static int alloc_picture_tables(AVCodecContext *avctx,
Picture *pic, int encodin
}
if (out_format == FMT_H263 || encoding ||
-#if FF_API_DEBUG_MV
-avctx->debug_mv ||
-#endif
(avctx->export_side_data & AV_CODEC_EXPORT_DATA_MVS)) {
int mv_size= 2 * (b8_array_size + 4) * sizeof(int16_t);
int ref_index_size = 4 * mb_array_size;
diff --git a/libavcodec/mpegutils.c b/libavcodec/mpegutils.c
index c0ee3aae85..e5105ecc58 100644
--- a/libavcodec/mpegutils.c
+++ b/libavcodec/mpegutils.c
@@ -262,132 +262,4 @@ void ff_print_debug_info2(AVCodecContext *avctx, AVFrame
*pict, uint8_t *mbskip_
av_log(avctx, AV_LOG_DEBUG, "\n");
}
}
-
-#if FF_API_DEBUG_MV
-if ((avctx->debug & (FF_DEBUG_VIS_QP | FF_DEBUG_VIS_MB_TYPE)) ||
-(avctx->debug_mv)) {
-int mb_y;
-int i, ret;
-int h_chroma_shift, v_chroma_shift, block_height;
-const int mv_sample_log2 = avctx->codec_id == AV_CODEC_ID_H264 ||
avctx->codec_id == AV_CODEC_ID_SVQ3 ? 2 : 1;
-const int mv_stride = (mb_width << mv_sample_log2) +
- (avctx->codec->id == AV_CODEC_ID_H264 ? 0 :
1);
-
-if (low_delay)
-*low_delay = 0; // needed to see the vectors without trashing the
buffers
-
-ret = av_pix_fmt_get_chroma_sub_sample (avctx->pix_fmt,
_chroma_shift, _chroma_shift);
-if (ret)
-return ret;
-
-av_frame_make_writable(pict);
-
-pict->opaque = NULL;
-block_height = 16 >> v_chroma_shift;
-
-for (mb_y = 0; mb_y <
Re: [FFmpeg-devel] [PATCH] avdevice/avdevice: Deprecate AVDevice Capabilities API
Andreas Rheinhardt (12021-01-24): > I know that Anton is currently working on merging them, but I thought > that this would only involve compiling lavd into libavformat.so; not > that the API would be changed or the libavdevice/ source folder merged > into libavformat. Considering Anton's open dislike of libavdevice, I find that news quite worrisome. I hope he will consult with the people who care about it and have ideas for its evolution before investing time in this work; otherwise it may mean a lot of wasted effort, and I must say it would also be quite disrespectful. 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 1/3] avformat/asfdec_o: Check for EOF in asf_read_marker()
On Wed, Jan 20, 2021 at 12:32:21AM +0100, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 26460/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-5710884393189376 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/asfdec_o.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. 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/hlsend: rework the ffprobe dependency of hls-fmp4_ac3
On 1/24/2021 7:08 PM, Andreas Rheinhardt wrote: James Almer: Add it to the existing +FATE_SAMPLES_FFPROBE list of ffprobe dependant tests instead. Signed-off-by: James Almer --- tests/fate/hlsenc.mak | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak index 02f041a7c2..30b81344f1 100644 --- a/tests/fate/hlsenc.mak +++ b/tests/fate/hlsenc.mak @@ -105,9 +105,10 @@ tests/data/hls_fmp4_ac3.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data -hls_time 2 -hls_segment_filename "$(TARGET_PATH)/tests/data/hls_fmp4_ac3_%d.m4s" \ $(TARGET_PATH)/tests/data/hls_fmp4_ac3.m3u8 2>/dev/null -FATE_HLSENC-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3 -fate-hls-fmp4_ac3: ffprobe$(PROGSSUF)$(EXESUF) tests/data/hls_fmp4_ac3.m3u8 +FATE_HLSENC_PROBE-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3 +fate-hls-fmp4_ac3: tests/data/hls_fmp4_ac3.m3u8 fate-hls-fmp4_ac3: CMD = probeaudiostream $(TARGET_PATH)/tests/data/now_ac3.mp4 FATE_SAMPLES_FFMPEG += $(FATE_HLSENC-yes) -fate-hlsenc: $(FATE_HLSENC-yes) +FATE_SAMPLES_FFPROBE += $(FATE_HLSENC_PROBE-yes) +fate-hlsenc: $(FATE_HLSENC-yes) $(FATE_HLSENC_PROBE-yes) Why not FATE_SAMPLES_FFMPEG_FFPROBE? After all, it needs FFmpeg for the input file. - Andreas You're right. Changed locally then. Will push later. ___ 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/hlsend: rework the ffprobe dependency of hls-fmp4_ac3
James Almer: > Add it to the existing +FATE_SAMPLES_FFPROBE list of ffprobe dependant tests > instead. > > Signed-off-by: James Almer > --- > tests/fate/hlsenc.mak | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak > index 02f041a7c2..30b81344f1 100644 > --- a/tests/fate/hlsenc.mak > +++ b/tests/fate/hlsenc.mak > @@ -105,9 +105,10 @@ tests/data/hls_fmp4_ac3.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) > | tests/data > -hls_time 2 -hls_segment_filename > "$(TARGET_PATH)/tests/data/hls_fmp4_ac3_%d.m4s" \ > $(TARGET_PATH)/tests/data/hls_fmp4_ac3.m3u8 2>/dev/null > > -FATE_HLSENC-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3 > -fate-hls-fmp4_ac3: ffprobe$(PROGSSUF)$(EXESUF) tests/data/hls_fmp4_ac3.m3u8 > +FATE_HLSENC_PROBE-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += > fate-hls-fmp4_ac3 > +fate-hls-fmp4_ac3: tests/data/hls_fmp4_ac3.m3u8 > fate-hls-fmp4_ac3: CMD = probeaudiostream > $(TARGET_PATH)/tests/data/now_ac3.mp4 > > FATE_SAMPLES_FFMPEG += $(FATE_HLSENC-yes) > -fate-hlsenc: $(FATE_HLSENC-yes) > +FATE_SAMPLES_FFPROBE += $(FATE_HLSENC_PROBE-yes) > +fate-hlsenc: $(FATE_HLSENC-yes) $(FATE_HLSENC_PROBE-yes) > Why not FATE_SAMPLES_FFMPEG_FFPROBE? After all, it needs FFmpeg for the input file. - Andreas ___ 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] avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps
On Sat, Nov 21, 2020 at 06:49:55PM +, Mark Thompson wrote: > On 21/11/2020 17:37, Michael Niedermayer wrote: > > On Sun, Nov 15, 2020 at 09:37:45PM +, Mark Thompson wrote: > > > On 14/11/2020 10:18, Michael Niedermayer wrote: > > > > Fixes: index 26 out of bounds for type 'uint8_t [16]' > > > > Fixes: > > > > 24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > >libavcodec/cbs_h265_syntax_template.c | 2 ++ > > > >1 file changed, 2 insertions(+) > > > > > > > > diff --git a/libavcodec/cbs_h265_syntax_template.c > > > > b/libavcodec/cbs_h265_syntax_template.c > > > > index 48fae82d04..8eb6e159f4 100644 > > > > --- a/libavcodec/cbs_h265_syntax_template.c > > > > +++ b/libavcodec/cbs_h265_syntax_template.c > > > > @@ -1405,6 +1405,8 @@ static int > > > > FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw, > > > >infer(num_long_term_sps, 0); > > > >idx_size = 0; > > > >} > > > > +if (HEVC_MAX_REFS < current->num_long_term_sps) > > > > +return AVERROR_INVALIDDATA; > > > > > > Please don't put isolated tests in the middle of the template. If it > > > constrains a value then add it to the constraints on that value. > > > > > > >ue(num_long_term_pics, 0, HEVC_MAX_REFS - > > > > current->num_long_term_sps); > > > >for (i = 0; i < current->num_long_term_sps + > > > > > > > > > > It would be good if the commit message could include an explanation > > > derived from the standard, too. > > > > > > As far as I can tell the constraint doesn't appear explicitly, but the > > > SPS is allowed to define more possible long term frames than are actually > > > allowed to be present at any given moment so we need the tighter bound. > > > > Is the change below what you had in mind ? > > > > commit 72c6c46bb2b31b2822331aff461acccd0a4f9159 (HEAD -> master) > > Author: Michael Niedermayer > > Date: Fri Nov 13 23:15:52 2020 +0100 > > > > avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps > > As far as we can tell the constraint doesn't appear explicitly, but > > the SPS is allowed to > > define more possible long term frames than are actually allowed to be > > present at any given moment so we need the tighter bound. > > I meant write a commit message which explains where in the standard the > constraint is coming from. I wrote that because I didn't see any extra > constraint written in the standard for num_long_term_sps but > num_long_term_ref_pics_sps is indeed bigger, so presumably it must be implied > by something else. what do you suggest if noone finds that "something else" ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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 1/2] avfilter/vf_nnedi: Fix segfault when prescreening is disabled
LGTM
On Sun, Jan 24, 2021 at 10:33 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Since c737f6edcef74a64f4d0ebcefa970bd31266d512 prescreening is
> nevertheless run because of a wrong check: "if (s->prescreen > 0)".
> s->prescreen is an array of two function pointers that is contained in
> the context and comparing it with 0 (i.e. NULL) is actually undefined
> behaviour, because NULL and s->prescreen do not point to the same
> object (NULL after all never points to any object). Nevertheless both
> Clang as well as GCC compile this to code that treat s->prescreen > 0 as
> true, leading to segfaults, because the code then tries to access the
> -1th member of an array.
>
> This commit fixes the check as well as another such check a few lines
> below.
>
> (Found via compiler warnings enabled by -pedantic:
> "ordered comparison between pointer and zero is an extension".)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_nnedi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_nnedi.c b/libavfilter/vf_nnedi.c
> index 1462ce1042..4229150668 100644
> --- a/libavfilter/vf_nnedi.c
> +++ b/libavfilter/vf_nnedi.c
> @@ -637,7 +637,7 @@ static int filter_slice(AVFilterContext *ctx, void
> *arg, int jobnr, int nb_jobs)
> width, 1, in_scale);
>
> for (int y = 0; y < slice_end - slice_start; y += 2) {
> -if (s->prescreen > 0)
> +if (s->pscrn > 0)
> s->prescreen[s->pscrn > 1](ctx, srcbuf + (y / 2) *
> srcbuf_stride + 32,
> srcbuf_stride, prescreen_buf, width,
> >prescreener[s->pscrn - 1]);
> @@ -649,7 +649,7 @@ static int filter_slice(AVFilterContext *ctx, void
> *arg, int jobnr, int nb_jobs)
>prescreen_buf, width,
>>coeffs[s->etype][s->nnsparam][s->nsize],
> s->qual == 2);
>
> -if (s->prescreen > 0)
> +if (s->pscrn > 0)
> interpolation(srcbuf + (y / 2) * srcbuf_stride + 32,
>srcbuf_stride,
>dstbuf + (y / 2) * dstbuf_stride,
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] fate/hlsend: rework the ffprobe dependency of hls-fmp4_ac3
Add it to the existing +FATE_SAMPLES_FFPROBE list of ffprobe dependant tests instead. Signed-off-by: James Almer --- tests/fate/hlsenc.mak | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak index 02f041a7c2..30b81344f1 100644 --- a/tests/fate/hlsenc.mak +++ b/tests/fate/hlsenc.mak @@ -105,9 +105,10 @@ tests/data/hls_fmp4_ac3.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data -hls_time 2 -hls_segment_filename "$(TARGET_PATH)/tests/data/hls_fmp4_ac3_%d.m4s" \ $(TARGET_PATH)/tests/data/hls_fmp4_ac3.m3u8 2>/dev/null -FATE_HLSENC-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3 -fate-hls-fmp4_ac3: ffprobe$(PROGSSUF)$(EXESUF) tests/data/hls_fmp4_ac3.m3u8 +FATE_HLSENC_PROBE-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3 +fate-hls-fmp4_ac3: tests/data/hls_fmp4_ac3.m3u8 fate-hls-fmp4_ac3: CMD = probeaudiostream $(TARGET_PATH)/tests/data/now_ac3.mp4 FATE_SAMPLES_FFMPEG += $(FATE_HLSENC-yes) -fate-hlsenc: $(FATE_HLSENC-yes) +FATE_SAMPLES_FFPROBE += $(FATE_HLSENC_PROBE-yes) +fate-hlsenc: $(FATE_HLSENC-yes) $(FATE_HLSENC_PROBE-yes) -- 2.30.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 2/2] avfilter/vf_unsharp: Remove unnecessary ;
A macro that expands to a function definition might look like a
declaration, but it isn't and therefore an extra ';' at the end is
unnecessary and actually invalid (both GCC and Clang warn about this
when using -pedantic).
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_unsharp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
index e9b6c9008d..198dbbaa51 100644
--- a/libavfilter/vf_unsharp.c
+++ b/libavfilter/vf_unsharp.c
@@ -139,8 +139,8 @@ static int name##_##nbits(AVFilterContext *ctx, void *arg,
int jobnr, int nb_job
}
\
return 0;
\
}
-DEF_UNSHARP_SLICE_FUNC(unsharp_slice, 16);
-DEF_UNSHARP_SLICE_FUNC(unsharp_slice, 8);
+DEF_UNSHARP_SLICE_FUNC(unsharp_slice, 16)
+DEF_UNSHARP_SLICE_FUNC(unsharp_slice, 8)
static int apply_unsharp_c(AVFilterContext *ctx, AVFrame *in, AVFrame *out)
{
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_nnedi: Fix segfault when prescreening is disabled
Since c737f6edcef74a64f4d0ebcefa970bd31266d512 prescreening is
nevertheless run because of a wrong check: "if (s->prescreen > 0)".
s->prescreen is an array of two function pointers that is contained in
the context and comparing it with 0 (i.e. NULL) is actually undefined
behaviour, because NULL and s->prescreen do not point to the same
object (NULL after all never points to any object). Nevertheless both
Clang as well as GCC compile this to code that treat s->prescreen > 0 as
true, leading to segfaults, because the code then tries to access the
-1th member of an array.
This commit fixes the check as well as another such check a few lines
below.
(Found via compiler warnings enabled by -pedantic:
"ordered comparison between pointer and zero is an extension".)
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_nnedi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_nnedi.c b/libavfilter/vf_nnedi.c
index 1462ce1042..4229150668 100644
--- a/libavfilter/vf_nnedi.c
+++ b/libavfilter/vf_nnedi.c
@@ -637,7 +637,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
width, 1, in_scale);
for (int y = 0; y < slice_end - slice_start; y += 2) {
-if (s->prescreen > 0)
+if (s->pscrn > 0)
s->prescreen[s->pscrn > 1](ctx, srcbuf + (y / 2) *
srcbuf_stride + 32,
srcbuf_stride, prescreen_buf, width,
>prescreener[s->pscrn - 1]);
@@ -649,7 +649,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
prescreen_buf, width,
>coeffs[s->etype][s->nnsparam][s->nsize], s->qual ==
2);
-if (s->prescreen > 0)
+if (s->pscrn > 0)
interpolation(srcbuf + (y / 2) * srcbuf_stride + 32,
srcbuf_stride,
dstbuf + (y / 2) * dstbuf_stride,
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Ticket #8750 Add inline function for the vec_xl intrinsic in non-VSX environments
Am Sa., 10. Okt. 2020 um 02:44 Uhr schrieb Andriy Gelman
:
>
> From: Chip Kerchner
>
> ---
> libswscale/ppc/yuv2rgb_altivec.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libswscale/ppc/yuv2rgb_altivec.c
> b/libswscale/ppc/yuv2rgb_altivec.c
> index 536545293d..930ef6b98f 100644
> --- a/libswscale/ppc/yuv2rgb_altivec.c
> +++ b/libswscale/ppc/yuv2rgb_altivec.c
> @@ -283,6 +283,16 @@ static inline void cvtyuvtoRGB(SwsContext *c, vector
> signed short Y,
> *
> --
> */
>
> +#if !HAVE_VSX
> +static inline vector unsigned char vec_xl(signed long long offset, const
> ubyte *addr)
> +{
> +const vector unsigned char *v_addr = (const vector unsigned char *)
> (addr + offset);
> +vector unsigned char align_perm = vec_lvsl(offset, addr);
> +
> +return (vector unsigned char) vec_perm(v_addr[0], v_addr[1], align_perm);
> +}
> +#endif /* !HAVE_VSX */
Is there a speed impact if this function is used?
Carl Eugen
___
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] avdevice/avdevice: Deprecate AVDevice Capabilities API
James Almer: > On 1/24/2021 5:16 PM, Andreas Rheinhardt wrote: >> It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004, >> yet since then none of the necessary create/free_device_capabilities >> functions has been implemented, making this API completely useless. >> >> Because of this one can already simplify >> avdevice_capabilities_free/create and can already remove the function >> pointers at the next major bump. > > Not against it if nobody will bother to implement this on existing > devices, but since the long term idea is to merge lavd into lavf, I > assume the entirety of the library's API will be eventually deprecated > and replaced. I know that Anton is currently working on merging them, but I thought that this would only involve compiling lavd into libavformat.so; not that the API would be changed or the libavdevice/ source folder merged into libavformat. > Worth if anything to remove those AVOutputFormat/AVInputFormat function > pointers, though. > >> >> Signed-off-by: Andreas Rheinhardt >> --- >> doc/APIchanges | 4 >> libavdevice/avdevice.c | 41 ++--- >> libavdevice/avdevice.h | 5 + >> libavdevice/version.h | 7 +-- >> libavformat/avformat.h | 4 >> 5 files changed, 24 insertions(+), 37 deletions(-) >> >> diff --git a/doc/APIchanges b/doc/APIchanges >> index bbf56a5385..8eeb6ba70f 100644 >> --- a/doc/APIchanges >> +++ b/doc/APIchanges >> @@ -15,6 +15,10 @@ libavutil: 2017-10-21 >> API changes, most recent first: >> +2021-01-24 - xx - lavd 58.12.100 - avdevice.h >> + Deprecated avdevice_capabilities_create() and >> + Add avdevice_capabilities_free(). They > > They? "Add" is even bigger bullshit. Sorry. (I swear I read this more than a dozen times.) - Andreas ___ 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
On 1/24/2021 5:16 PM, Andreas Rheinhardt wrote: It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004, yet since then none of the necessary create/free_device_capabilities functions has been implemented, making this API completely useless. Because of this one can already simplify avdevice_capabilities_free/create and can already remove the function pointers at the next major bump. Not against it if nobody will bother to implement this on existing devices, but since the long term idea is to merge lavd into lavf, I assume the entirety of the library's API will be eventually deprecated and replaced. Worth if anything to remove those AVOutputFormat/AVInputFormat function pointers, though. Signed-off-by: Andreas Rheinhardt --- doc/APIchanges | 4 libavdevice/avdevice.c | 41 ++--- libavdevice/avdevice.h | 5 + libavdevice/version.h | 7 +-- libavformat/avformat.h | 4 5 files changed, 24 insertions(+), 37 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index bbf56a5385..8eeb6ba70f 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,10 @@ libavutil: 2017-10-21 API changes, most recent first: +2021-01-24 - xx - lavd 58.12.100 - avdevice.h + Deprecated avdevice_capabilities_create() and + Add avdevice_capabilities_free(). They They? ___ 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove the function
pointers at the next major bump.
Signed-off-by: Andreas Rheinhardt
---
doc/APIchanges | 4
libavdevice/avdevice.c | 41 ++---
libavdevice/avdevice.h | 5 +
libavdevice/version.h | 7 +--
libavformat/avformat.h | 4
5 files changed, 24 insertions(+), 37 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bbf56a5385..8eeb6ba70f 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-01-24 - xx - lavd 58.12.100 - avdevice.h
+ Deprecated avdevice_capabilities_create() and
+ Add avdevice_capabilities_free(). They
+
2021-01-11 - xx - lavc 58.116.100 - avcodec.h
Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index ec84d3b990..fbcf4a4ab2 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -27,6 +27,7 @@
#include "libavutil/ffversion.h"
const char av_device_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
+#if FF_API_DEVICE_CAPABILITIES
#define E AV_OPT_FLAG_ENCODING_PARAM
#define D AV_OPT_FLAG_DECODING_PARAM
#define A AV_OPT_FLAG_AUDIO_PARAM
@@ -60,6 +61,7 @@ const AVOption av_device_capabilities[] = {
#undef A
#undef V
#undef OFFSET
+#endif
unsigned avdevice_version(void)
{
@@ -94,49 +96,18 @@ int avdevice_dev_to_app_control_message(struct
AVFormatContext *s, enum AVDevToA
return s->control_message_cb(s, type, data, data_size);
}
+#if FF_API_DEVICE_CAPABILITIES
int avdevice_capabilities_create(AVDeviceCapabilitiesQuery **caps,
AVFormatContext *s,
AVDictionary **device_options)
{
-int ret;
-av_assert0(s && caps);
-av_assert0(s->iformat || s->oformat);
-if ((s->oformat && !s->oformat->create_device_capabilities) ||
-(s->iformat && !s->iformat->create_device_capabilities))
-return AVERROR(ENOSYS);
-*caps = av_mallocz(sizeof(**caps));
-if (!(*caps))
-return AVERROR(ENOMEM);
-(*caps)->device_context = s;
-if (((ret = av_opt_set_dict(s->priv_data, device_options)) < 0))
-goto fail;
-if (s->iformat) {
-if ((ret = s->iformat->create_device_capabilities(s, *caps)) < 0)
-goto fail;
-} else {
-if ((ret = s->oformat->create_device_capabilities(s, *caps)) < 0)
-goto fail;
-}
-av_opt_set_defaults(*caps);
-return 0;
- fail:
-av_freep(caps);
-return ret;
+return AVERROR(ENOSYS);
}
void avdevice_capabilities_free(AVDeviceCapabilitiesQuery **caps,
AVFormatContext *s)
{
-if (!s || !caps || !(*caps))
-return;
-av_assert0(s->iformat || s->oformat);
-if (s->iformat) {
-if (s->iformat->free_device_capabilities)
-s->iformat->free_device_capabilities(s, *caps);
-} else {
-if (s->oformat->free_device_capabilities)
-s->oformat->free_device_capabilities(s, *caps);
-}
-av_freep(caps);
+return;
}
+#endif
int avdevice_list_devices(AVFormatContext *s, AVDeviceInfoList **device_list)
{
diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
index ee9462480e..85a4dcc6df 100644
--- a/libavdevice/avdevice.h
+++ b/libavdevice/avdevice.h
@@ -321,6 +321,7 @@ int avdevice_dev_to_app_control_message(struct
AVFormatContext *s,
enum AVDevToAppMessageType type,
void *data, size_t data_size);
+#if FF_API_DEVICE_CAPABILITIES
/**
* Following API allows user to probe device capabilities (supported codecs,
* pixel formats, sample formats, resolutions, channel counts, etc).
@@ -416,6 +417,7 @@ typedef struct AVDeviceCapabilitiesQuery {
/**
* AVOption table used by devices to implement device capabilities API. Should
not be used by a user.
*/
+attribute_deprecated
extern const AVOption av_device_capabilities[];
/**
@@ -435,6 +437,7 @@ extern const AVOption av_device_capabilities[];
*
* @return >= 0 on success, negative otherwise.
*/
+attribute_deprecated
int avdevice_capabilities_create(AVDeviceCapabilitiesQuery **caps,
AVFormatContext *s,
AVDictionary **device_options);
@@ -444,7 +447,9 @@ int avdevice_capabilities_create(AVDeviceCapabilitiesQuery
**caps, AVFormatConte
* @param caps Device capabilities data to be freed.
* @param sContext of the device.
*/
+attribute_deprecated
void avdevice_capabilities_free(AVDeviceCapabilitiesQuery **caps,
AVFormatContext *s);
+#endif
/**
* Structure describes basic parameters of the device.
diff --git
Re: [FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions
Jan 24, 2021, 17:05 by an...@khirnov.net: > Quoting Lynne (2021-01-23 20:10:46) > >> This is an RFC about the upcoming additions to the AVPacket structure >> (whose size is still part of the ABI, so we need to plan for any changes). >> >> The current RFC patch adds 3 fields: >> - "void *opaque;" for the user to use as they wish, same as >> AVFrame.opaque >> - "void *opaque_ref;" for more permanent and propagating user data, same >> as AVFrame.opaque_ref >> > > Generally in favor, but: > - do we really need both? > - ownership semantics should be specified more clearly, so there is no > ambiguity over who is allowed to set it. Something like: > whoever owns (i.e. is responsible for unreffing) the packet ref also > owns opaque_ref > I think the void * is useful for API users. They can set it to a local context (such as their own muxing context), while the opaque_ref can be used for more global info (internal metadata, reception timestamp for the source so latency can be measured and such). As for ownership sematics, the description copied verbatim from libavutil/frame.h. To keep sync, I think that description should be expanded first. >> - "AVRational time_base;" which will be set to indicate the time base of >> the packet's timestamps >> > > In favor - should reduce confusion and existing users can still rescale > timestamps manually before passing them to lavf. But then it should also be > added to AVFrame. > Thought so too, will send a patch for AVFrame.time_base. > And compatibility will be tricky - e.g. encoders setting this field will > break muxing in lavf (since current users all rescale manually). > We discussed this in IRC, the conclusion was to add an optional flag to every major context (bsfc, avc, lavf, lavfi*) which will set the time_base value of produced avframes and avpacket, and if it's present, then we can automagically rescale the timestamps in cosumers/producers. The flag will be deprecated once the bump happens. If the user wishes to rescale themselves, they will still be able to do that once the flag is removed. >> >> Some devs (JEEB) wanted reception timestamps and original, overflowed >> timestamps for MPEG-TS. >> I'd be willing to add a reception timestamp as long as we add an additional >> time_base field >> and make it independent of the packet's pts field, since those timestamps >> are usually on >> highly precise system clock time bases, and reducing their precision would >> be undesirable. >> > > This sounds like side data to me. > >> >> I'm not sure about overflowed original timestamps or how they would help. >> Perhaps we should introduce an AVBufferRef *internal_ref like with AVFrame to >> store such single library-only data? >> > > I don't like treating the libraries specially, so -1 for me. > internal_ref should not exist either. > Yeah, tbh it's a single-library only field in avframes and is mainly used for hardware API weirdness reasons. Also another suggestion: should we add a few dozen bytes of padding at the end of the avpacket structure so if anything were to happen we wouldn't be block on waiting for a bump to add a field? ___ 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] Ticket #8750 Add inline function for the vec_xl intrinsic in non-VSX environments
On Sat, 07. Nov 16:31, Andriy Gelman wrote:
> On Sat, 31. Oct 10:17, Andriy Gelman wrote:
> > On Fri, 16. Oct 00:02, Andriy Gelman wrote:
> > > On Fri, 09. Oct 20:17, Andriy Gelman wrote:
> > > > From: Chip Kerchner
> > > >
> > > > ---
> > > > libswscale/ppc/yuv2rgb_altivec.c | 10 ++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/libswscale/ppc/yuv2rgb_altivec.c
> > > > b/libswscale/ppc/yuv2rgb_altivec.c
> > > > index 536545293d..930ef6b98f 100644
> > > > --- a/libswscale/ppc/yuv2rgb_altivec.c
> > > > +++ b/libswscale/ppc/yuv2rgb_altivec.c
> > > > @@ -283,6 +283,16 @@ static inline void cvtyuvtoRGB(SwsContext *c,
> > > > vector signed short Y,
> > > > *
> > > > --
> > > > */
> > > >
> > > > +#if !HAVE_VSX
> > > > +static inline vector unsigned char vec_xl(signed long long offset,
> > > > const ubyte *addr)
> > > > +{
> > > > +const vector unsigned char *v_addr = (const vector unsigned char
> > > > *) (addr + offset);
> > > > +vector unsigned char align_perm = vec_lvsl(offset, addr);
> > > > +
> > > > +return (vector unsigned char) vec_perm(v_addr[0], v_addr[1],
> > > > align_perm);
> > > > +}
> > > > +#endif /* !HAVE_VSX */
> > > > +
> > > > #define DEFCSP420_CVT(name, out_pixels)
> > > >\
> > > > static int altivec_ ## name(SwsContext *c, const unsigned char **in,
> > > >\
> > > > int *instrides, int srcSliceY, int
> > > > srcSliceH, \
> > >
> > > Ping.
> > > This patch fixes PPC64 build on patchwork.
> > >
> >
> > ping
> >
>
> ping
>
I asked Reimar to have a look at the patch. He didn't have a link to original
post, so I'm forwarding his feedback:
- a few comments sure would be good
- the function likely should be always_inline
- the offset is always 0 in the code, so that could be optimized
- I am not sure if the addresses even can be unaligned (the whole magic code is
about fixing up unaligned loads since altivec simply ignores the low bits of
the address, but it looks like the x86 asm also assumes unaligned)
- the extra load needed to fix the alignment can read outside the bounds of the
buffer I think? Especially for chroma and if the load is aligned. Though chroma
seems to have an issue already today...
--
Andriy
___
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] lavf/utils: reset event_flags if extradata is not extracted correctly
Quoting Linjie Fu (2021-01-24 16:05:56) > Regression since 87f0c8280. > > If the extradata of a stream could not be extracted correctly, > codec_info_nb_frames would remain zero, while st->event_flag would still > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS. > > The two expressions could be different in this case, hence reset > event_flags and calculate the correct score. > > Fix #9029. The ticket mentions ffplay, but ffplay does not access event_flags. -- Anton Khirnov ___ 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]lsws/ppc/yuv2rgb: Fix transparency converting from yuv->rgb32
Am Sa., 23. Jan. 2021 um 23:21 Uhr schrieb Reimar Döffinger : > > > > > On 23 Jan 2021, at 19:35, Carl Eugen Hoyos wrote: > > > > > > New patch attached, thank you! > > > > Looks good to me. Patch applied. Thank you, Carl Eugen ___ 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] avpacket: RFC for ABI bump additions
Quoting Lynne (2021-01-23 20:10:46) > This is an RFC about the upcoming additions to the AVPacket structure > (whose size is still part of the ABI, so we need to plan for any changes). > > The current RFC patch adds 3 fields: > - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque > - "void *opaque_ref;" for more permanent and propagating user data, same > as AVFrame.opaque_ref Generally in favor, but: - do we really need both? - ownership semantics should be specified more clearly, so there is no ambiguity over who is allowed to set it. Something like: whoever owns (i.e. is responsible for unreffing) the packet ref also owns opaque_ref > - "AVRational time_base;" which will be set to indicate the time base of > the packet's timestamps In favor - should reduce confusion and existing users can still rescale timestamps manually before passing them to lavf. But then it should also be added to AVFrame. And compatibility will be tricky - e.g. encoders setting this field will break muxing in lavf (since current users all rescale manually). > > Some devs (JEEB) wanted reception timestamps and original, overflowed > timestamps for MPEG-TS. > I'd be willing to add a reception timestamp as long as we add an additional > time_base field > and make it independent of the packet's pts field, since those timestamps are > usually on > highly precise system clock time bases, and reducing their precision would be > undesirable. This sounds like side data to me. > > I'm not sure about overflowed original timestamps or how they would help. > Perhaps we should introduce an AVBufferRef *internal_ref like with AVFrame to > store such single library-only data? I don't like treating the libraries specially, so -1 for me. internal_ref should not exist either. -- Anton Khirnov ___ 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] fftools/ffmpeg_opt: restore to use codec_info_nb_frames to calculate score
On Sun, Jan 24, 2021 at 9:38 PM James Almer wrote: > > On 1/24/2021 10:00 AM, Linjie Fu wrote: > > From: Linjie Fu > > > > Regression since 87f0c8280. > > > > If the extradata of a stream could not be extracted correctly, > > codec_info_nb_frames would remain zero, while st->event_flag would still > > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS since it's a new packet > > indeed. > > > > The two expressions could be different in this case, hence restore to > > calculate the correct score. > > > > Fix #9029. > > codec_info_nb_frames is not public, which is why its usage was removed, > so this patch is not ok. Okay, thx. > A proper fix would perhaps be to reset event_flags after this, as its > API says it should. Can you try that and see if it works? > Yes it works, and I've tried this before I sent this patch out. However, what makes me hesitant is the definition of AVSTREAM_EVENT_FLAG_NEW_PACKETS , which says this flag indicates "new packets for this stream were read from the file". IIRC the behaviour in this case matches the definition well, hence I didn't reset event_flags to zero at first. Will send it out for discussion as well, thx. - linjie ___ 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] lavf/utils: reset event_flags if extradata is not extracted correctly
Regression since 87f0c8280.
If the extradata of a stream could not be extracted correctly,
codec_info_nb_frames would remain zero, while st->event_flag would still
be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS.
The two expressions could be different in this case, hence reset
event_flags and calculate the correct score.
Fix #9029.
Signed-off-by: Linjie Fu
---
libavformat/utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f100294a1..de397a209e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3895,8 +3895,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
if (!st->internal->avctx->extradata) {
ret = extract_extradata(st, pkt);
-if (ret < 0)
+if (ret < 0) {
+st->event_flags = 0;
goto unref_then_goto_end;
+}
}
/* If still no information, we try to open the codec and to
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils: always preserve container dimensions for all streams
If a decoder is used for probing it may change the dimensions reported by the
demuxer, either by the lowres factor or because of assorted frames reporting
different dimensions, and in a codec copy scenario, the last dimensions
arbitrarily set by it could end up being propagated to the muxer.
Signed-off-by: James Almer
---
libavformat/utils.c | 10 ++
tests/ref/fate/cbs-vp9-vp90-2-05-resize | 2 +-
tests/ref/fate/redcode-demux| 2 +-
tests/ref/fate/wtv-demux| 4 ++--
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f100294a1..bfc8436fc9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4105,6 +4105,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
st = ic->streams[i];
if (st->internal->avctx_inited) {
+AVRational orig_sar = st->codecpar->sample_aspect_ratio;
int orig_w = st->codecpar->width;
int orig_h = st->codecpar->height;
ret = avcodec_parameters_from_context(st->codecpar,
st->internal->avctx);
@@ -4113,13 +4114,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
ret = add_coded_side_data(st, st->internal->avctx);
if (ret < 0)
goto find_stream_info_err;
-#if FF_API_LOWRES
-// The decoder might reduce the video size by the lowres factor.
-if (st->internal->avctx->lowres && orig_w) {
+
+// The decoder might change the video size.
+if (orig_w && orig_h) {
+if (st->codecpar->width != orig_w && st->codecpar->height !=
orig_h)
+st->codecpar->sample_aspect_ratio = orig_sar;
st->codecpar->width = orig_w;
st->codecpar->height = orig_h;
}
-#endif
}
#if FF_API_LAVF_AVCTX
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
index 8f036bba81..37a37ff1ea 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
+++ b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
@@ -1 +1 @@
-6838422ebb45df353a2bad62b9aff8e9
+1c39300b93fe110e1db30974e5d3479d
diff --git a/tests/ref/fate/redcode-demux b/tests/ref/fate/redcode-demux
index 45119ec71e..c6e0b6de5c 100644
--- a/tests/ref/fate/redcode-demux
+++ b/tests/ref/fate/redcode-demux
@@ -1,7 +1,7 @@
#tb 0: 1/24
#media_type 0: video
#codec_id 0: jpeg2000
-#dimensions 0: 2048x1152
+#dimensions 0: 4096x2304
#sar 0: 0/1
#tb 1: 1/24
#media_type 1: audio
diff --git a/tests/ref/fate/wtv-demux b/tests/ref/fate/wtv-demux
index abe85a4ab6..388ba796d3 100644
--- a/tests/ref/fate/wtv-demux
+++ b/tests/ref/fate/wtv-demux
@@ -3,8 +3,8 @@
#tb 0: 1/1000
#media_type 0: video
#codec_id 0: mpeg2video
-#dimensions 0: 720x576
-#sar 0: 64/45
+#dimensions 0: 704x480
+#sar 0: 0/1
#tb 1: 1/1000
#media_type 1: audio
#codec_id 1: mp2
--
2.30.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".
Re: [FFmpeg-devel] [PATCH] ffmpeg_opts: remove lowres check
Quoting James Almer (2021-01-23 19:38:57)
>
> If i apply the following, the output of three remuxing (codec copy)
> tests change
>
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8ac6bc04b8..0cdf3156a6 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4110,13 +4110,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > ret = add_coded_side_data(st, st->internal->avctx);
> > if (ret < 0)
> > goto find_stream_info_err;
> > -#if FF_API_LOWRES
> > -// The decoder might reduce the video size by the lowres
> > factor.
> > -if (st->internal->avctx->lowres && orig_w) {
> > +
> > +// The decoder might change the video size.
> > +if (orig_w && orig_h) {
> > st->codecpar->width = orig_w;
> > st->codecpar->height = orig_h;
> > }
> > -#endif
> > }
>
> What i assume happens is that without this change st->codecpar is being
> populated with dimensions set by whatever decoder was used during
> probing, and then propagated to the muxer codecpar, whereas with this
> change the dimensions from the source container are kept unchanged.
>
> Case in point
>
> > diff --git a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > index 8f036bba81..37a37ff1ea 100644
> > --- a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > +++ b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > @@ -1 +1 @@
> > -6838422ebb45df353a2bad62b9aff8e9
> > +1c39300b93fe110e1db30974e5d3479d
> > diff --git a/tests/ref/fate/redcode-demux b/tests/ref/fate/redcode-demux
> > index 45119ec71e..c6e0b6de5c 100644
> > --- a/tests/ref/fate/redcode-demux
> > +++ b/tests/ref/fate/redcode-demux
> > @@ -1,7 +1,7 @@
> > #tb 0: 1/24
> > #media_type 0: video
> > #codec_id 0: jpeg2000
> > -#dimensions 0: 2048x1152
> > +#dimensions 0: 4096x2304
> > #sar 0: 0/1
> > #tb 1: 1/24
> > #media_type 1: audio
> > diff --git a/tests/ref/fate/wtv-demux b/tests/ref/fate/wtv-demux
> > index abe85a4ab6..39d395699c 100644
> > --- a/tests/ref/fate/wtv-demux
> > +++ b/tests/ref/fate/wtv-demux
> > @@ -3,7 +3,7 @@
> > #tb 0: 1/1000
> > #media_type 0: video
> > #codec_id 0: mpeg2video
> > -#dimensions 0: 720x576
> > +#dimensions 0: 704x480
> > #sar 0: 64/45
> > #tb 1: 1/1000
> > #media_type 1: audio
> > --
>
> I personally think that for a codec copy scenario (Where you could have
> no decoders at all), this behavior is more consistent. Some samples have
> different resolution per frame, like that vp9 one, and a decoder could
> return the one from the last frame probed.
I tend to agree, though in the specific case of wtv-demux the container
dimensions seem broken. But then again I don't think it's the job of
find_stream_info() to engage in such heuristics.
--
Anton Khirnov
___
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] fftools/ffmpeg_opt: restore to use codec_info_nb_frames to calculate score
On 1/24/2021 10:00 AM, Linjie Fu wrote:
From: Linjie Fu
Regression since 87f0c8280.
If the extradata of a stream could not be extracted correctly,
codec_info_nb_frames would remain zero, while st->event_flag would still
be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS since it's a new packet
indeed.
The two expressions could be different in this case, hence restore to
calculate the correct score.
Fix #9029.
codec_info_nb_frames is not public, which is why its usage was removed,
so this patch is not ok.
A proper fix would perhaps be to reset event_flags after this, as its
API says it should. Can you try that and see if it works?
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_opt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index bf2eb26246..ba813ea7bc 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2228,8 +2228,7 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int score;
ist = input_streams[i];
-score = ist->st->codecpar->width * ist->st->codecpar->height
- + 1 * !!(ist->st->event_flags &
AVSTREAM_EVENT_FLAG_NEW_PACKETS)
+score = ist->st->codecpar->width * ist->st->codecpar->height +
1*!!ist->st->codec_info_nb_frames
+ 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
___
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 6/6] avformat/flvdec: Check for EOF in loop in flv_data_packet()
Quoting Michael Niedermayer (2021-01-23 23:10:56)
> Fixes: Timeout
> Fixes:
> 29656/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5840098987999232
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/flvdec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 4bc5e15dd2..02797e1fba 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -909,6 +909,11 @@ static int flv_data_packet(AVFormatContext *s, AVPacket
> *pkt,
>
> while (array || (ret = amf_get_string(pb, buf, sizeof(buf))) > 0) {
> AMFDataType type = avio_r8(pb);
> +if (avio_feof(pb)) {
> +ret = AVERROR_INVALIDDATA;
> +goto skip;
> +}
> +
> if (type == AMF_DATA_TYPE_STRING && (array || !strcmp(buf, "text")))
> {
> length = avio_rb16(pb);
> ret= av_get_packet(pb, pkt, length);
> --
> 2.17.1
IMO it would be cleaner to make amf_get_string() check the return value
of avio_read() and return an error on short reads.
--
Anton Khirnov
___
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 4/6] avformat/flvdec: Check for nesting depth in amf_parse_object()
Quoting Michael Niedermayer (2021-01-23 23:10:54) > Fixes: out of array access > Fixes: > 29202/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5112845840809984 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/flvdec.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c > index 07ef342278..e15be0a221 100644 > --- a/libavformat/flvdec.c > +++ b/libavformat/flvdec.c > @@ -41,6 +41,8 @@ > > #define RESYNC_BUFFER_SIZE (1<<20) > > +#define MAX_DEPTH 10 Why 10 specifically. And which buffer overflows? -- Anton Khirnov ___ 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/6] avcodec/apedec: Use FFABSU() in do_apply_filter()
Quoting Michael Niedermayer (2021-01-23 23:10:52) > Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to > an unsigned type to negate this value to itself > Fixes: > 29053/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4814432697974784 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/apedec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks ok -- Anton Khirnov ___ 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/6] avutil/common: Add FFABSU() for a signed -> unsigned ABS
Quoting Michael Niedermayer (2021-01-23 23:10:51) > Signed-off-by: Michael Niedermayer > --- > libavutil/common.h | 8 This is a public header, so a minor bump+APIchanges entry are needed. (ideally we'd also rename those to use the AV prefix, but that is for later) -- Anton Khirnov ___ 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] fftools/ffmpeg_opt: restore to use codec_info_nb_frames to calculate score
From: Linjie Fu
Regression since 87f0c8280.
If the extradata of a stream could not be extracted correctly,
codec_info_nb_frames would remain zero, while st->event_flag would still
be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS since it's a new packet
indeed.
The two expressions could be different in this case, hence restore to
calculate the correct score.
Fix #9029.
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_opt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index bf2eb26246..ba813ea7bc 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2228,8 +2228,7 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int score;
ist = input_streams[i];
-score = ist->st->codecpar->width * ist->st->codecpar->height
- + 1 * !!(ist->st->event_flags &
AVSTREAM_EVENT_FLAG_NEW_PACKETS)
+score = ist->st->codecpar->width * ist->st->codecpar->height +
1*!!ist->st->codec_info_nb_frames
+ 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/swfdec: Check outlen before allocation
Quoting Michael Niedermayer (2021-01-23 23:34:19)
> On Sat, Jan 23, 2021 at 03:29:38PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-01-22 15:09:47)
> > > Fixes: Timeout (too long -> 241ms)
> > > Fixes:
> > > 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/swfdec.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> > > index 1463f0ad4d..aa4be88f91 100644
> > > --- a/libavformat/swfdec.c
> > > +++ b/libavformat/swfdec.c
> > > @@ -367,6 +367,9 @@ static int swf_read_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > ff_dlog(s, "bitmap: ch=%d fmt=%d %dx%d (linesize=%d)
> > > len=%d->%ld pal=%d\n",
> > > ch_id, bmp_fmt, width, height, linesize, len,
> > > out_len, colormapsize);
> > >
> > > +if (len * 17373LL < out_len)
> >
> > Where does the magic number come from?
>
> A very quick simulation of the best case compression for "compress"
> below is not nice written code as i did not expect I or anyone else
> would ever see it again
>
> I would have preferred some nicer expression or course, but thats
> what it seems to be asymptotically. For smaller amounts of data a
> tighter bound is possible but i saw no nice way to consider that
> and it seems also overkill to try to do it more fine grained for
> just this
>
> main(){
> int64_t bits = 0;
> int bank = 256;
> int bitbank = 8;
> for(unsigned i = 0; i<1024*1024*1024*4U-10;) {
> int word_size = bank-255;
> i += word_size;
> bits += bitbank;
>
> if (!(bank & (bank-1)))
> bitbank ++;
> bank++;
> if (bitbank > 16) {
> printf("BEST %f \n", 8.0 * i / bits );
> bank = 256;
> bitbank = 8;
> }
> }
> }
>
> above assumes i remembered correctly how the algorithm works but the
> value was close to what actual compession of zeros gave
People who read this code in the future will be interested in all this.
So the content of your reply should be added to the commit message
and/or the code itself.
--
Anton Khirnov
___
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] avfilter/avfilter: Remove AVFilterLink.flags
Andreas Rheinhardt (12021-01-24): > It is a private field that is unused since > 44f660e7e75b856eafa5f7e7cc6e633de5d01b5d. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/avfilter.h | 5 - > 1 file changed, 5 deletions(-) LGTM, thanks. 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".
[FFmpeg-devel] [PATCH 2/2] avfilter/avfilter: Remove AVFilterLink.flags
It is a private field that is unused since
44f660e7e75b856eafa5f7e7cc6e633de5d01b5d.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/avfilter.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 100183f56c..d43b866599 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -587,11 +587,6 @@ struct AVFilterLink {
*/
int channels;
-/**
- * Link processing flags.
- */
-unsigned flags;
-
/**
* Number of past frames sent through the link.
*/
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/url: Reorder elements of URLProtocol to make it smaller
Signed-off-by: Andreas Rheinhardt
---
libavformat/url.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/url.h b/libavformat/url.h
index e33edf0cb9..1ef5ca35d5 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -87,8 +87,8 @@ typedef struct URLProtocol {
int *numhandles);
int (*url_get_short_seek)(URLContext *h);
int (*url_shutdown)(URLContext *h, int flags);
-int priv_data_size;
const AVClass *priv_data_class;
+int priv_data_size;
int flags;
int (*url_check)(URLContext *h, int mask);
int (*url_open_dir)(URLContext *h);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] seeking consultancy around FFmpeg
> What we are looking for is pretty straight forward. I like to capture > the HDMI video/audio output of a Chromecast dongle and distribute it > into a LAN network via UDP multicast. Something like this: > > Chromecast -> HDMI -> HDMI-USB Capture -> RPi4/8G (with FFmpeg) -> > UDP/Multicast -> LAN -> TV set > > > UDP Multicast output should use the H.264 hardware encoder comes with > the RPi. This may be helpful for your project: https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/ ___ 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] seeking consultancy around FFmpeg
Hello everyone, I hope this is the right email list for asking if someone is interested in doing some consultancy work for us. What we are looking for is pretty straight forward. I like to capture the HDMI video/audio output of a Chromecast dongle and distribute it into a LAN network via UDP multicast. Something like this: Chromecast -> HDMI -> HDMI-USB Capture -> RPi4/8G (with FFmpeg) -> UDP/Multicast -> LAN -> TV set UDP Multicast output should use the H.264 hardware encoder comes with the RPi. Someone out there happy to assist us? Thanks a lot Gisbert ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add epx pixel art scaler
Will apply soon. ___ 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".
