Re: [FFmpeg-devel] [PATCH 1/3] avcodec/exr: Check uncompressed_size against max_pixels
On Sun, Jul 11, 2021 at 03:26:32PM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 35286/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6557139802914816 > Fixes: > 31253/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-4901782326214656 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/exr.c | 3 +++ > 1 file changed, 3 insertions(+) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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/7] tools/target_dec_fuzzer: Fuzz skip_frame
On Fri, Feb 07, 2020 at 02:48:25PM +0100, Michael Niedermayer wrote: > Should allow coverage of related code > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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 4/7] tools/target_dec_fuzzer: Set extradata for the parser
On Fri, Feb 07, 2020 at 02:48:28PM +0100, Michael Niedermayer wrote: > This should improve coverage > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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 5/7] tools/target_dec_fuzzer: Fuzz AV_CODEC_FLAG2_EXPORT_MVS
On Fri, Feb 07, 2020 at 02:48:29PM +0100, Michael Niedermayer wrote: > This should increase coverage > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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 6/7] tools/target_dec_fuzzer: Fuzz FF_DEBUG_*
On Fri, Feb 07, 2020 at 02:48:30PM +0100, Michael Niedermayer wrote: > This should increase coverage > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 9 + > 1 file changed, 9 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator 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] lavfi/vf_v360: add missing 0.5 subpixel shift
Hi, I'm unable to apply this patch, please send it via attachment to new mail in this same thread. ___ 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] tools/target_dec_fuzzer: Set bits_per_raw_sample for ARGO
This may improve coverage of argo
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 3d06630e46..3963eb1d2a 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -282,6 +282,9 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
av_dict_set_int(&opts, "target_level",
(int)(bytestream2_get_byte(&gbc) % 32) - 31, 0);
av_dict_set_int(&opts, "dmix_mode",
(int)(bytestream2_get_byte(&gbc) % 4) - 1, 0);
break;
+case AV_CODEC_ID_ARGO:
+ctx->bits_per_raw_sample= bytestream2_get_byte(&gbc); // This
is a violation of the API but used by the argo demuxer - decoder interface
+break;
}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: fix -t inaccurate recording time
On 2021-07-10 15:42, Gyan Doshi wrote:
On 2021-07-09 11:03, Shiwang.Xie wrote:
Pings.
Will test.
Fix confirmed. Will push tomorrow if no one objects.
Regards,
Gyan
On Sat, 5 Jun 2021, Shiwang.Xie wrote:
Ping.
Thanks,
Shiwang.Xie
On Sat, 29 May 2021, Shiwang.Xie wrote:
Hi, any updates for this?
Thanks,
Shiwang.Xie
On Wed, 19 May 2021, Shiwang.Xie wrote:
Hi, is there objection?
Thanks,
Shiwang.Xie
On Sat, 15 May 2021, Shiwang.Xie wrote:
if input start time is not 0 -t is inaccurate doing stream copy,
will record extra duration according to input start time.
it should base on following cases:
input video start time from 60s, duration is 300s,
1. stream copy:
ffmpeg -ss 40 -t 60 -i in.mp4 -c copy -y out.mp4
open_input_file() will seek to 100 and set ts_offset to -100,
process_input() will offset pkt->pts with ts_offset to make it 0,
so when do_streamcopy() with -t, exits when ist->pts >=
recording_time.
2. stream copy with -copyts:
ffmpeg -ss 40 -t 60 -copyts -i in.mp4 -c copy -y out.mp4
open_input_file() will seek to 100 and set ts_offset to 0,
process_input() will keep raw pkt->pts as ts_offset is 0,
so when do_streamcopy() with -t, exits when
ist->pts >= (recording_time+f->start_time+f->ctx->start_time).
3. stream copy with -copyts -start_at_zero:
ffmpeg -ss 40 -t 60 -copyts -start_at_zero -i in.mp4 -c
copy -y out.mp4
open_input_file() will seek to 120 and set ts_offset to -60 as
start_to_zero option,
process_input() will offset pkt->pts with input file start time,
so when do_streamcopy() with -t, exits when ist->pts >=
(recording_time+f->start_time).
0 60 40 60 360
|___|_|___|___|
start -ss -t
This fixes ticket #9141.
Signed-off-by: Shiwang.Xie
---
fftools/ffmpeg.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b3658d8f65..309d9dfa6e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2082,9 +2082,11 @@ static void do_streamcopy(InputStream
*ist, OutputStream *ost, const AVPacket *p
}
if (f->recording_time != INT64_MAX) {
- start_time = f->ctx->start_time;
- if (f->start_time != AV_NOPTS_VALUE && copy_ts)
- start_time += f->start_time;
+ start_time = 0;
+ if (copy_ts) {
+ start_time += f->start_time != AV_NOPTS_VALUE ?
f->start_time : 0;
+ start_time += start_at_zero ? 0 : f->ctx->start_time;
+ }
if (ist->pts >= f->recording_time + start_time) {
close_output_stream(ost);
return;
--
2.18.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [WIP] Event loop
Hi. Some time ago, I started working on the project to update libavformat's protocols to run with a proper event loop, instead of the several half-assed event loops we have here and there in the code. I started by writing the documentation for the low-level API, making sure it is an API that (1) is sufficient for the high-level API and (2) I can deliver on Unix using poll() and pthreads and could deliver with GLib, libev and probably libuv. Please have a look at it. In particular, if you know system/event programming for other operating systems, please have a look to tell me if there are flaws in that regard. Here are a few comments: The structure of my projects are: - AVWorker, single-threaded low-level API, with the possibility of having several implementations to accommodate different operating systems or integrate into existing frameworks. - AVScheduler, multi-threaded high-level API, with the possibility of having several implementations to integrate into existing frameworks. - Redesign AVIO so that it works as tasks in an AVScheduler. - Redesign libavfilter so that activating filters is tasks in an AVScheduler. Note that I have made implementation choices different from what we are used to. In particular, when it comes to making the API future-proof. Adding low-level tasks needs to be extremely lightweight, to the exclusion of dynamic allocation: our old and t[ier]+d foo_alloc() / foo_free() / add fields at the end does not cut it. If you want to criticize these choices, please make sure you understand how they work, what constraints I am working with and what benefit they bring, and preferably have an alternate proposal. Here is the current state of worker.h. Now I will be working on scheduler.h. Regards, -- Nicolas George /* * This file is part of FFmpeg. * * FFmpeg is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * FFmpeg is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with FFmpeg; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ #ifndef AVUTIL_WORKER_H #define AVUTIL_WORKER_H /** * @defgroup lavu_worker AVWorker * * AVWorker: single-threaded event loop. * * AVWorker is an API to implement single-threaded event loops. * It is the building block used to implement multi-threaded event loops, * see the AVScheduler API. * * You want to consider this API if: * * 1. You need a simple event loop and lightweight initialization is more *important than the extra performance bought by parallelism. * * 2. You want to implement an AVWorker capable of taking advantage of the *specifics of your OS or framework to use with AVScheduler. * * Otherwise, you should probably be using AVScheduler. * * In normal circumstances, an AVWorker has a set of tasks attached to it. * It will wait for one of these tasks to be ready and execute it. * This can be repeated in a loop until the end of operation is reached. * * Different types of tasks exist, depending on the condition for their * execution. * There are tasks to wait for a specific time. * There are tasks to wait for network activity or other IPC. * There are tasks to be executed as soon as computing time is available. * * Even though AVWorker is single-threaded, it can be thread-safe. This is * specified through a flag. * If an AVWorker is not thread-safe, applications must ensure to only ever * use it from a single thread; tasks can still do threads internally of * course. * If the AVWorker is thread-safe, it still must be run on a single thread, * but other threads can add and remove tasks. Other threads can also * interrupt a task prematurely, if it is implemented for that particular * task. * * Tasks have a priority. If several tasks are ready to run, the one with * the highest priority will be chosen. This API does not define the range * of priorities. * * Tasks have a duration, which is defined as a rough upper bound to the * time it will actually take to complete. Per convention, use 1000 for * tasks that only do a little processing and 1 for tasks that may do a * few system calls or dynamic allocation. Applications can limit the time * an AVWorker will be running: tasks that would finish too late are not * considered. The value (unsigned)-1 = UINT_MAX means no limit. * * Tasks have a interrupt_latency parameter, which describes the time it * takes to interrupt it from another thread, in a way similar to its * duration. Applications
[FFmpeg-devel] [PATCH] addroi filter: Now it can be dynamically moved with zmq command
0001-addroi-filter-Now-it-can-be-dynamically-moved-with-z.patch Description: 0001-addroi-filter-Now-it-can-be-dynamically-moved-with-z.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg: add option readrate
> On Jul 17, 2021, at 12:07 PM, Gyan Doshi wrote: > > On 2021-07-17 04:50, ffmpegandmahanstreamer@e.email wrote: >> Put the fact that -re is equivalent to -readrate 1 in the deprecated message >> so people know what to switch to. > > It's already in the docs for -re as well as the ffmpeg -h description. How about keep `-re` as an shortcut for `-readrate` and don't deprecate it? It's simple to type and satisfied most of the usecases of `-readrate`. > > Regards, > Gyan > ___ > 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". > > On 2021-07-17 04:50, ffmpegandmahanstreamer@e.email wrote: >> Put the fact that -re is equivalent to -readrate 1 in the deprecated message >> so people know what to switch to. > > It's already in the docs for -re as well as the ffmpeg -h description. > > Regards, > Gyan > ___ > 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] RV: [PATCH] addroi filter: Now it can be dynamically moved with zmq command
Hi all, I am updating this patch for the addroi filter to now include the ability to dynamically move the region of interest via message passing. Through the ZeroMQ library or similar, new regions of interest in a video that is in the process of being encoded can now be sent through the command line. This works very well for live streams using FFmpeg. An example of use will be as follows: ./ffmpeg -i -c:v libx264 -crf -vf "addroi=iw-200:ih-200:iw/2:ih/2:-1,zmq" -f dash /var/www/html/dash/file.mpd In case you need to change it, just execute this command changing the attributes you want to set: echo Parsed_addroi_0 reinit x=200:y=200:w=100:h=100 | ./zmqsend 0001-addroi-filter-Now-it-can-be-dynamically-moved-with-z.patch Description: 0001-addroi-filter-Now-it-can-be-dynamically-moved-with-z.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg: add option readrate
On 2021-07-17 18:16, Zhao Zhili wrote: > >> On Jul 17, 2021, at 12:07 PM, Gyan Doshi wrote: >> >> On 2021-07-17 04:50, ffmpegandmahanstreamer@e.email wrote: >>> Put the fact that -re is equivalent to -readrate 1 in the >>> deprecated message so people know what to switch to. >> >> It's already in the docs for -re as well as the ffmpeg -h >> description. > > How about keep `-re` as an shortcut for `-readrate` and don't > deprecate it? It's simple to type and satisfied most of the usecases > of `-readrate`. That works too. Regards, Gyan ___ 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: add option readrate
On 2021-07-17 19:04, Gyan Doshi wrote: On 2021-07-17 18:16, Zhao Zhili wrote: > >> On Jul 17, 2021, at 12:07 PM, Gyan Doshi wrote: >> >> On 2021-07-17 04:50, ffmpegandmahanstreamer@e.email wrote: >>> Put the fact that -re is equivalent to -readrate 1 in the >>> deprecated message so people know what to switch to. >> >> It's already in the docs for -re as well as the ffmpeg -h >> description. > > How about keep `-re` as an shortcut for `-readrate` and don't > deprecate it? It's simple to type and satisfied most of the usecases > of `-readrate`. That works too. Undeprecated -re and pushed as c320b78e95bab2a71a636dc4da905522c4646b35 Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 00/34] avdevice (mostly dshow) enhancements
On Wed, Jul 7, 2021 at 8:46 AM Diederick C. Niehorster wrote: > > On Tue, Jul 6, 2021 at 11:20 AM Diederick Niehorster > wrote: > > > > This patch series implements a series of features, mostly enhancing the > > dshow avdevice, but also adding new functionality to avformat. > > This whole patchset enabled users of the FFmpeg API to fully > > query and control a dshow device, making FFmpeg a nice backend for any > > program that needs access to, e.g., a webcam. > > Offlist, i received an LGTM from Roger Pack, the dshow maintainer. Ping for the series. I realize that there are some unfinished discussions. In my understanding, the proposal to lock avdevice and avformat together at the minor version level (see thread kicked off by this message: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html), which has not seen detractors, resolves the issues that came up earlier about how to go forward with avdevice, correct? That would clear the way for re-introducing the (useful!) avdevice capabilities api, which i guess is the most contentious part of this patch set. Curious to hear of course if there is anything else blocking it! Let me know if there is anything i can facilitate, or alternatively, if this requires discussion in some meeting the project will have, do you have an idea when that meeting would be? Thanks and all the best, Dee ___ 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] avcodec: add a parser flag to enable keyframe tagging heuristics
On Fri, Jul 16, 2021 at 03:43:39PM -0300, James Almer wrote:
> On 7/16/2021 1:55 PM, Michael Niedermayer wrote:
> > On Thu, Jul 15, 2021 at 05:55:51PM -0300, James Almer wrote:
> > > On 7/15/2021 5:23 PM, Michael Niedermayer wrote:
> > > > On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote:
> > > > > It will be used to allow parsers to be more liberal when tagging
> > > > > packets as
> > > > > keyframes.
> > > > >
> > > > > Signed-off-by: James Almer
> > > > > ---
> > > > >libavcodec/avcodec.h | 1 +
> > > > >1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > > > index 8b97895aeb..8e3d888266 100644
> > > > > --- a/libavcodec/avcodec.h
> > > > > +++ b/libavcodec/avcodec.h
> > > > > @@ -2809,6 +2809,7 @@ typedef struct AVCodecParserContext {
> > > > >#define PARSER_FLAG_ONCE 0x0002
> > > > >/// Set if the parser has a valid file offset
> > > > >#define PARSER_FLAG_FETCHED_OFFSET0x0004
> > > > > +#define PARSER_FLAG_USE_KEYFRAME_HEURISTICS 0x0008
> > > > >#define PARSER_FLAG_USE_CODEC_TS 0x1000
> > > >
> > > > This doesnt "feel" like the best solution to me
> > > >
> > > > dont you think it would be better to export all information ?
> > >
> > > The AVParser API is going to be removed at some point for something better
> > > that works on packets rather than raw buffers, so ideally we should not
> > > expand it too much, and leave more complex implementations for later.
> >
> > Iam not sure i follow your logic here
> >
> > do you suggest to block setting lets call it "advanced keyframe" related
> > work
> > across the codebase ? (that includes muxers and so on ?
> > Iam not saying thats a good or bad idea. Just trying to understand
>
> I'm saying to not spend time extending the AVCodecParserContext API to
> export even more information when it's going to be replaced. A single flag
> to stop one parser from tagging more than it needs to is enough to work
> around the problem at hand.
>
> >
> > Because to me it seems if the awnser is no to the question above
> > then this is not just about "Adding a flag is the simplest way to fix this"
> > but its adding codec specific code in muxers probably to extract the exta
> > information, and iam not sure that at this point its not easier to have
> > the parser export this information
>
> Inserting the h264 parser internally in mpegtsenc is needed because it's the
> generic demuxer code that may or may not use one to assemble packets or fill
> missing information. The muxer side has no interaction with it, it only
> receives packets from some source.
> So you add a new field to AVCodecParserContext to signal these "advanced
> keyframes". How does that information reach the muxer? You're now having to
> define or expand more stuff for this purpose.
>
> Inserting it in the muxer also has the added benefit of not depending on the
> demuxing side from having inserted one to begin with. For example, open an
> mp4 file for which the demuxer was able to create an AVIndexEntry array and
> therefore will not tell the generic code that it needs a parser. If you
> remux that file to mpegts, only Sync Samples (Of which there may be none)
> will have been tagged as keyframes by the demuxer (Which is expected) and
> not all these other packets with recovery points like mpegts apparently
> wants.
> If the muxer internally inserts the parser, all of them can be marked, and a
> flag is enough for that.
>
> >
> > And when the parser API is then replaced by "something better" the interface
> > changes less. If this heuristic flag is added then i assume it needs to be
> > removed and reimplemented with the API change.
>
> This flag would be removed alongside the rest of AVCodecParserContext API,
> but the replacement would not need something like it since we would then
> look into ensuring it exports more detailed information for a given packet
> in a proper way,
> and not just setting a generic and poorly defined
> context-wide key_frame field.
>
> This is just a stopgap solution, not something that needs to be translated
> into a new API. I mean, just look how all these flags are not even
> namespaced, or how the main function doesn't even return error codes. A
> replacement hardly requires to be a 1:1 translation.
>
> >
> > I very likely am missing something
> > But i certainly do not suggest or ask for more work to be done. Rather the
> > opposit, i was wondering if its not less work overall to export the
> > information properly ...
>
> The replacement for AVCodecParserContext would, if i recall correctly when
> it was suggested, be having the work done by bitstream filters. Some muxers
> and demuxers are already using bsfs in some cases, so it would be built on
> top of that, and maybe automatically inserted by both muxers and demuxers,
> not just the latter.
>
> So considering that muxer specific code is needed right
Re: [FFmpeg-devel] [PATCH] cmdutils: simplify opt_cpucount()
On Fri, Jul 16, 2021 at 09:26:16PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > fftools/cmdutils.c | 27 +++ > 1 file changed, 7 insertions(+), 20 deletions(-) Posted an alternative patch which goes the opposit direction and make use of the features of the eval stuff thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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] fftools/cmdutils: Allow expressions for opt_cpucount()
This allows for example
"-cpucount cpu/2" to use half the available CPUs
Signed-off-by: Michael Niedermayer
---
fftools/cmdutils.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6e875104fd..a902354669 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -859,11 +859,12 @@ int opt_cpucount(void *optctx, const char *opt, const
char *arg)
int ret;
int count;
-static const AVOption opts[] = {
-{"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1, INT_MAX, NULL},
+AVOption opts[] = {
+{"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1, INT_MAX, 0,
"val"},
+{"cpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1}, 0, 0, 0, "val"},
{NULL},
};
-static const AVClass class = {
+const AVClass class = {
.class_name = "cpucount",
.item_name = av_default_item_name,
.option = opts,
@@ -871,6 +872,8 @@ int opt_cpucount(void *optctx, const char *opt, const char
*arg)
};
const AVClass *pclass = &class;
+opts[1].default_val.i64 = av_cpu_count();
+
ret = av_opt_eval_int(&pclass, opts, arg, &count);
if (!ret) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/cmdutils: Allow expressions for opt_cpucount()
On 7/17/2021 1:21 PM, Michael Niedermayer wrote:
This allows for example
"-cpucount cpu/2" to use half the available CPUs
Signed-off-by: Michael Niedermayer
---
fftools/cmdutils.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6e875104fd..a902354669 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -859,11 +859,12 @@ int opt_cpucount(void *optctx, const char *opt, const
char *arg)
int ret;
int count;
-static const AVOption opts[] = {
-{"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1, INT_MAX, NULL},
+AVOption opts[] = {
+{"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1, INT_MAX, 0,
"val"},
+{"cpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1}, 0, 0, 0, "val"},
{NULL},
};
-static const AVClass class = {
+const AVClass class = {
.class_name = "cpucount",
.item_name = av_default_item_name,
.option = opts,
@@ -871,6 +872,8 @@ int opt_cpucount(void *optctx, const char *opt, const char
*arg)
};
const AVClass *pclass = &class;
+opts[1].default_val.i64 = av_cpu_count();
You could set this directly as the default value instead of -1 above.
Should be ok either way.
+
ret = av_opt_eval_int(&pclass, opts, arg, &count);
if (!ret) {
___
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] mxfdec.c: fixed frame wrapping detection for MXFGCP1FrameWrappedPicture essence container
On Mon, 12 Jul 2021, Tomas Härdin wrote:
sön 2021-07-11 klockan 09:47 -0700 skrev p...@sandflow.com:
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
For JPEG 2000 essence, the MXF input format module currently uses the value
of byte 14 of the essence container UL to determines whether the J2K essence is
clip- (byte 14 is 0x02)
or frame-wrapped (byte 14 is 0x01). This approach does work when the
essence container UL is equal to MXFGCP1FrameWrappedPicture, in which case the
essence is always frame-wrapped.
"This approach does "*not*" work when..."
libavformat/mxf.h| 3 ++-
libavformat/mxfdec.c | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index b1b1fedac7..ca510f5a2f 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -75,7 +75,8 @@ typedef enum {
NormalWrap = 0,
D10D11Wrap,
RawAWrap,
-RawVWrap
+RawVWrap,
+AlwaysFrameWrap
} MXFWrappingIndicatorType;
typedef struct MXFLocalTagPair {
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..7024d2ea7d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1413,6 +1413,7 @@ static void *mxf_resolve_strong_ref(MXFContext *mxf, UID
*strong_ref, enum MXFMe
static const MXFCodecUL mxf_picture_essence_container_uls[] = {
// video essence container uls
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x06,0x00
}, 15, AV_CODEC_ID_JPEG2000, NULL, 16, AlwaysFrameWrap }, /* MXF-GC P1
Frame-Wrapped JPEG 2000 */
Setting wrapping_indicator_pos to 16 seems problematic, it might cause
overreads in mxf_get_wrapping_kind, and a bit misleading...
I'd rather not add a new entry with the same codec id for the same
prefix, but add a JPEG2000Wrap MXFWrappingIndicatorType instead, and
similarly how D10D11Wrap is handled, add a new case and a simple if in
mxf_get_wrapping_kind:
case JPEG2000Wrap:
if (val == 0x06)
val = 0x01;
break;
Thanks,
Marton
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
}, 14, AV_CODEC_ID_JPEG2000, NULL, 14 },
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x10,0x60,0x01
}, 14, AV_CODEC_ID_H264, NULL, 15 }, /* H.264 */
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
}, 14, AV_CODEC_ID_DNXHD, NULL, 14 }, /* VC-3 */
@@ -1497,6 +1498,9 @@ static MXFWrappingScheme mxf_get_wrapping_kind(UID
*essence_container_ul)
if (val == 0x02)
val = 0x01;
break;
+case AlwaysFrameWrap:
+val = 0x01;
+break;
Looks OK. Still passes FATE.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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/cmdutils: Allow expressions for opt_cpucount()
On 7/17/2021 2:22 PM, James Almer wrote:
On 7/17/2021 1:21 PM, Michael Niedermayer wrote:
This allows for example
"-cpucount cpu/2" to use half the available CPUs
Signed-off-by: Michael Niedermayer
---
fftools/cmdutils.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6e875104fd..a902354669 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -859,11 +859,12 @@ int opt_cpucount(void *optctx, const char *opt,
const char *arg)
int ret;
int count;
- static const AVOption opts[] = {
- {"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1,
INT_MAX, NULL},
+ AVOption opts[] = {
+ {"count", NULL, 0, AV_OPT_TYPE_INT, { .i64 = -1}, -1,
INT_MAX, 0, "val"},
+ {"cpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1}, 0, 0, 0,
"val"},
{NULL},
};
- static const AVClass class = {
+ const AVClass class = {
.class_name = "cpucount",
.item_name = av_default_item_name,
.option = opts,
@@ -871,6 +872,8 @@ int opt_cpucount(void *optctx, const char *opt,
const char *arg)
};
const AVClass *pclass = &class;
+ opts[1].default_val.i64 = av_cpu_count();
You could set this directly as the default value instead of -1 above.
Should be ok either way.
Actually, the "cpu" constant should be documented.
+
ret = av_opt_eval_int(&pclass, opts, arg, &count);
if (!ret) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: remove AVStreamInternal.orig_codec_id
James Almer:
> It's a write only field.
>
> Signed-off-by: James Almer
> ---
> libavformat/internal.h | 2 --
> libavformat/utils.c| 6 --
> 2 files changed, 8 deletions(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 240de9e289..4b7ab082e7 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -204,8 +204,6 @@ struct AVStreamInternal {
> */
> int avctx_inited;
>
> -enum AVCodecID orig_codec_id;
> -
> /* the context for extracting extradata in find_stream_info()
> * inited=1/bsf=NULL signals that extracting is not possible (codec not
> * supported) */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 998fddf270..efdb6f062f 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -604,9 +604,6 @@ int avformat_open_input(AVFormatContext **ps, const char
> *filename,
>
> update_stream_avctx(s);
>
> -for (i = 0; i < s->nb_streams; i++)
> -s->streams[i]->internal->orig_codec_id =
> s->streams[i]->codecpar->codec_id;
> -
> if (options) {
> av_dict_free(options);
> *options = tmp;
> @@ -3614,9 +3611,6 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> }
> }
>
> -if (st->codecpar->codec_id != st->internal->orig_codec_id)
> -st->internal->orig_codec_id = st->codecpar->codec_id;
> -
> ret = avcodec_parameters_to_context(avctx, st->codecpar);
> if (ret < 0)
> goto find_stream_info_err;
>
LGTM.
- 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] mxfdec.c: fixed frame wrapping detection for MXFGCP1FrameWrappedPicture essence container
You mean something like this?
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index ca510f5a2f..b9fe7fe7ef 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -76,7 +76,7 @@ typedef enum {
D10D11Wrap,
RawAWrap,
RawVWrap,
-AlwaysFrameWrap
+J2KWrap
} MXFWrappingIndicatorType;
typedef struct MXFLocalTagPair {
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 7024d2ea7d..7c33150675 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1413,8 +1413,7 @@ static void *mxf_resolve_strong_ref(MXFContext
*mxf, UID *strong_ref, enum MXFMe
static const MXFCodecUL mxf_picture_essence_container_uls[] = {
// video essence container uls
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x06,0x00
}, 15, AV_CODEC_ID_JPEG2000, NULL, 16, AlwaysFrameWrap }, /* MXF-GC
P1 Frame-Wrapped JPEG 2000 */
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
}, 14, AV_CODEC_ID_JPEG2000, NULL, 14 },
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
}, 14, AV_CODEC_ID_JPEG2000, NULL, 14, J2KWrap },
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x10,0x60,0x01
}, 14, AV_CODEC_ID_H264, NULL, 15 }, /* H.264 */
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
}, 14, AV_CODEC_ID_DNXHD, NULL, 14 }, /* VC-3 */
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x12,0x01,0x00
}, 14,AV_CODEC_ID_VC1, NULL, 14 }, /* VC-1 */
@@ -1498,8 +1497,9 @@ static MXFWrappingScheme
mxf_get_wrapping_kind(UID *essence_container_ul)
if (val == 0x02)
val = 0x01;
break;
-case AlwaysFrameWrap:
-val = 0x01;
+case J2KWrap:
+if (val != 0x02)
+val = 0x01;
break;
}
if (val == 0x01)
On Sat, Jul 17, 2021 at 11:19 AM Marton Balint wrote:
>
>
>
> On Mon, 12 Jul 2021, Tomas Härdin wrote:
>
> > sön 2021-07-11 klockan 09:47 -0700 skrev p...@sandflow.com:
> >> From: Pierre-Anthony Lemieux
> >>
> >> Signed-off-by: Pierre-Anthony Lemieux
> >> ---
> >>
> >> Notes:
> >> For JPEG 2000 essence, the MXF input format module currently uses the
> >> value of byte 14 of the essence container UL to determines whether the J2K
> >> essence is clip- (byte 14 is 0x02)
> >> or frame-wrapped (byte 14 is 0x01). This approach does work when the
> >> essence container UL is equal to MXFGCP1FrameWrappedPicture, in which case
> >> the essence is always frame-wrapped.
>
> "This approach does "*not*" work when..."
>
> >>
> >> libavformat/mxf.h| 3 ++-
> >> libavformat/mxfdec.c | 4
> >> 2 files changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> >> index b1b1fedac7..ca510f5a2f 100644
> >> --- a/libavformat/mxf.h
> >> +++ b/libavformat/mxf.h
> >> @@ -75,7 +75,8 @@ typedef enum {
> >> NormalWrap = 0,
> >> D10D11Wrap,
> >> RawAWrap,
> >> -RawVWrap
> >> +RawVWrap,
> >> +AlwaysFrameWrap
> >> } MXFWrappingIndicatorType;
> >>
> >> typedef struct MXFLocalTagPair {
> >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >> index 3bf480a3a6..7024d2ea7d 100644
> >> --- a/libavformat/mxfdec.c
> >> +++ b/libavformat/mxfdec.c
> >> @@ -1413,6 +1413,7 @@ static void *mxf_resolve_strong_ref(MXFContext *mxf,
> >> UID *strong_ref, enum MXFMe
> >>
> >> static const MXFCodecUL mxf_picture_essence_container_uls[] = {
> >> // video essence container uls
> >> +{ {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x06,0x00
> >> }, 15, AV_CODEC_ID_JPEG2000, NULL, 16, AlwaysFrameWrap }, /* MXF-GC P1
> >> Frame-Wrapped JPEG 2000 */
>
> Setting wrapping_indicator_pos to 16 seems problematic, it might cause
> overreads in mxf_get_wrapping_kind, and a bit misleading...
>
> I'd rather not add a new entry with the same codec id for the same
> prefix, but add a JPEG2000Wrap MXFWrappingIndicatorType instead, and
> similarly how D10D11Wrap is handled, add a new case and a simple if in
> mxf_get_wrapping_kind:
>
> case JPEG2000Wrap:
> if (val == 0x06)
> val = 0x01;
> break;
>
> Thanks,
> Marton
>
>
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
> >> }, 14, AV_CODEC_ID_JPEG2000, NULL, 14 },
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x10,0x60,0x01
> >> }, 14, AV_CODEC_ID_H264, NULL, 15 }, /* H.264 */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> >> }, 14, AV_CODEC_ID_DNXHD, NULL, 14 }, /* VC-3 */
> >> @@ -1497,6 +1498,9 @@ static MXFWrappingScheme mxf_get_wrapping_kind(UID
> >> *essence_container_ul)
> >> if (val == 0x02)
> >> val = 0x01;
> >> break;
> >> +
[FFmpeg-devel] [PATCH] fftools/ffmpeg: Fix declaration-after-statement warning
Signed-off-by: Andreas Rheinhardt
---
What is actually the reason that we stick to this C90 rule?
Is it because of compability with ancient compilers? (Given that we
already require several C99 features, I doubt that there are compilers
which would fail if we stopped adhering to the
declaration-before-statement rule.) Or is it because it is presumed that
it improves clarity and readability?
fftools/ffmpeg.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e0f2fe138f..6f6e002604 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4234,10 +4234,11 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
float scale = f->rate_emu ? 1.0 : f->readrate;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
+int64_t stream_ts_offset, pts, now;
if (!ist->nb_packets) continue;
-int64_t stream_ts_offset = FFMAX(ist->first_dts != AV_NOPTS_VALUE
? ist->first_dts : 0, file_start);
-int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
-int64_t now = (av_gettime_relative() - ist->start)*scale +
stream_ts_offset;
+stream_ts_offset = FFMAX(ist->first_dts != AV_NOPTS_VALUE ?
ist->first_dts : 0, file_start);
+pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
+now = (av_gettime_relative() - ist->start) * scale +
stream_ts_offset;
if (pts > now)
return AVERROR(EAGAIN);
}
--
2.27.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] avformat/utils: remove AVStreamInternal.orig_codec_id
James Almer:
> It's a write only field.
>
> Signed-off-by: James Almer
> ---
> libavformat/internal.h | 2 --
> libavformat/utils.c| 6 --
> 2 files changed, 8 deletions(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 240de9e289..4b7ab082e7 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -204,8 +204,6 @@ struct AVStreamInternal {
> */
> int avctx_inited;
>
> -enum AVCodecID orig_codec_id;
> -
> /* the context for extracting extradata in find_stream_info()
> * inited=1/bsf=NULL signals that extracting is not possible (codec not
> * supported) */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 998fddf270..efdb6f062f 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -604,9 +604,6 @@ int avformat_open_input(AVFormatContext **ps, const char
> *filename,
>
> update_stream_avctx(s);
>
> -for (i = 0; i < s->nb_streams; i++)
This loop is the only user of i, so it needs to be removed as well. LGTM
apart from that.
(Found via patchwork; thanks Andriy again. Btw, this shows why we should
use for loops with variable declaration (i.e. "for (int i = 0;").)
> -s->streams[i]->internal->orig_codec_id =
> s->streams[i]->codecpar->codec_id;
> -
> if (options) {
> av_dict_free(options);
> *options = tmp;
> @@ -3614,9 +3611,6 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> }
> }
>
> -if (st->codecpar->codec_id != st->internal->orig_codec_id)
> -st->internal->orig_codec_id = st->codecpar->codec_id;
> -
> ret = avcodec_parameters_to_context(avctx, st->codecpar);
> if (ret < 0)
> goto find_stream_info_err;
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: remove AVStreamInternal.orig_codec_id
On 7/17/2021 7:17 PM, Andreas Rheinhardt wrote:
James Almer:
It's a write only field.
Signed-off-by: James Almer
---
libavformat/internal.h | 2 --
libavformat/utils.c| 6 --
2 files changed, 8 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 240de9e289..4b7ab082e7 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -204,8 +204,6 @@ struct AVStreamInternal {
*/
int avctx_inited;
-enum AVCodecID orig_codec_id;
-
/* the context for extracting extradata in find_stream_info()
* inited=1/bsf=NULL signals that extracting is not possible (codec not
* supported) */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 998fddf270..efdb6f062f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -604,9 +604,6 @@ int avformat_open_input(AVFormatContext **ps, const char
*filename,
update_stream_avctx(s);
-for (i = 0; i < s->nb_streams; i++)
This loop is the only user of i, so it needs to be removed as well. LGTM
apart from that.
(Found via patchwork; thanks Andriy again. Btw, this shows why we should
use for loops with variable declaration (i.e. "for (int i = 0;").)
Yeah, i noticed the warning after sending the patch and already had it
amended locally.
Pushed, thanks.
-s->streams[i]->internal->orig_codec_id =
s->streams[i]->codecpar->codec_id;
-
if (options) {
av_dict_free(options);
*options = tmp;
@@ -3614,9 +3611,6 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
}
}
-if (st->codecpar->codec_id != st->internal->orig_codec_id)
-st->internal->orig_codec_id = st->codecpar->codec_id;
-
ret = avcodec_parameters_to_context(avctx, st->codecpar);
if (ret < 0)
goto find_stream_info_err;
___
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 3/3] avcodec/h264_parser: use the keyframe heuristics flag
James Almer:
> Tag only packets containing with IDR pictures as keyframes by default, same as
> the decoder.
> Fixes MP4 and Matroska muxers marking incorrect samples as Sync Samples in
> scenarios where this AVParser is used.
>
1. Could you please explain where you got the info that Matroska
keyframes need to be ISOBMFF Sync Samples from? Because it's actually
undefined what it exactly is; in case of AV1 (the only codec with a
detailed codec mapping) said mapping allows delayed random access points
to be marked as keyframes (without providing anything to actually signal
that these are delayed random access points), so a key frame is simply a
random access point. And that is how it is de-facto handled with all
other codecs as well. IMO it is ISOBMFF which is the outlier here.
> Signed-off-by: James Almer
> ---
> libavcodec/h264_parser.c | 16 ++--
> tests/fate-run.sh | 4 ++--
> tests/fate/ffmpeg.mak | 2 +-
> tests/fate/lavf-container.mak | 12 ++--
> tests/fate/matroska.mak| 2 +-
> tests/ref/fate/copy-trac2211-avi | 2 +-
> tests/ref/fate/matroska-h264-remux | 4 ++--
> tests/ref/fate/segment-mp4-to-ts | 10 +-
> tests/ref/lavf-fate/h264.mp4 | 4 ++--
> 9 files changed, 30 insertions(+), 26 deletions(-)
>
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index d3c56cc188..532dc462b0 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -344,9 +344,11 @@ static inline int parse_nal_units(AVCodecParserContext
> *s,
> get_ue_golomb_long(&nal.gb); // skip first_mb_in_slice
> slice_type = get_ue_golomb_31(&nal.gb);
> s->pict_type = ff_h264_golomb_to_pict_type[slice_type % 5];
> -if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
> -/* key frame, since recovery_frame_cnt is set */
> -s->key_frame = 1;
> +if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
> +if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
> +/* key frame, since recovery_frame_cnt is set */
> +s->key_frame = 1;
> +}
2. This change means that files that don't use IDR pictures, but only
recovery point SEIs won't have packets marked as keyframes at all any
more; this affects every open-gop video. This is way worse than an
incorrect sync sample list created by the mp4 muxer.
(When using x264 with open-gop, it even means that every stream so
encoded will only have one keyframe (the IDR frame at the beginning),
because for some reason x264 never uses IDR frames in open-gop mode even
at scenecuts (where the gop is closed and where using an IDR frame
instead of a recovery point SEI would actually save a few bytes).)
> }
> pps_id = get_ue_golomb(&nal.gb);
> if (pps_id >= MAX_PPS_COUNT) {
> @@ -370,9 +372,11 @@ static inline int parse_nal_units(AVCodecParserContext
> *s,
> p->ps.sps = p->ps.pps->sps;
> sps = p->ps.sps;
>
> -// heuristic to detect non marked keyframes
> -if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0]
> <= 1 && s->pict_type == AV_PICTURE_TYPE_I)
> -s->key_frame = 1;
> +if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
> +// heuristic to detect non marked keyframes
> +if (p->ps.sps->ref_frame_count <= 1 &&
> p->ps.pps->ref_count[0] <= 1 && s->pict_type == AV_PICTURE_TYPE_I)
> +s->key_frame = 1;
> +}
>
> p->poc.frame_num = get_bits(&nal.gb, sps->log2_max_frame_num);
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index ba437dfbb8..8680e35524 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -339,8 +339,8 @@ lavf_container_fate()
> outdir="tests/data/lavf-fate"
> file=${outdir}/lavf.$t
> input="${target_samples}/$1"
> -do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input"
> "$ENC_OPTS -metadata title=lavftest" -vcodec copy -acodec copy
> -do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
> $target_path/$file $3
> +do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input"
> "$ENC_OPTS -metadata title=lavftest" -vcodec copy -acodec copy $3
> +do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
> $target_path/$file $4
> }
>
> lavf_image(){
> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
> index 4dfb77d250..57d16fba6f 100644
> --- a/tests/fate/ffmpeg.mak
> +++ b/tests/fate/ffmpeg.mak
> @@ -110,7 +110,7 @@ fate-copy-trac4914-avi: CMD = transcode mpegts
> $(TARGET_SAMPLES)/mpeg2/xdcam8mp2
> FATE_STREAMCOPY-$(call ALLYES, H264_DEMUXER AVI_MUXER) +=
> fate-copy-trac2211-avi
> fate-copy-trac2211-avi: $(SAMPLES)/h264/bbc2.sample.h264
> fate-copy-trac2211-avi: CMD = transcode "h264 -r 14"
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/h264_parser: use the keyframe heuristics flag
On 7/17/2021 9:30 PM, Andreas Rheinhardt wrote:
James Almer:
Tag only packets containing with IDR pictures as keyframes by default, same as
the decoder.
Fixes MP4 and Matroska muxers marking incorrect samples as Sync Samples in
scenarios where this AVParser is used.
1. Could you please explain where you got the info that Matroska
keyframes need to be ISOBMFF Sync Samples from? Because it's actually
undefined what it exactly is; in case of AV1 (the only codec with a
detailed codec mapping) said mapping allows delayed random access points
to be marked as keyframes (without providing anything to actually signal
that these are delayed random access points), so a key frame is simply a
random access point. And that is how it is de-facto handled with all
other codecs as well. IMO it is ISOBMFF which is the outlier here.
It was an assumption considering the Matroska h264 encapsulation is
taken verbatim from ISOBMFF. But you're right, MKVToolnix does mark
those as key.
Signed-off-by: James Almer
---
libavcodec/h264_parser.c | 16 ++--
tests/fate-run.sh | 4 ++--
tests/fate/ffmpeg.mak | 2 +-
tests/fate/lavf-container.mak | 12 ++--
tests/fate/matroska.mak| 2 +-
tests/ref/fate/copy-trac2211-avi | 2 +-
tests/ref/fate/matroska-h264-remux | 4 ++--
tests/ref/fate/segment-mp4-to-ts | 10 +-
tests/ref/lavf-fate/h264.mp4 | 4 ++--
9 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..532dc462b0 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -344,9 +344,11 @@ static inline int parse_nal_units(AVCodecParserContext *s,
get_ue_golomb_long(&nal.gb); // skip first_mb_in_slice
slice_type = get_ue_golomb_31(&nal.gb);
s->pict_type = ff_h264_golomb_to_pict_type[slice_type % 5];
-if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
-/* key frame, since recovery_frame_cnt is set */
-s->key_frame = 1;
+if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
+if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
+/* key frame, since recovery_frame_cnt is set */
+s->key_frame = 1;
+}
2. This change means that files that don't use IDR pictures, but only
recovery point SEIs won't have packets marked as keyframes at all any
more; this affects every open-gop video. This is way worse than an
incorrect sync sample list created by the mp4 muxer.
I worked around this for the mpegts muxer as Kieran requested, but if
Matroska is the same then the situation changes.
I can add a user settable demuxer option for the autoinserted parser
instead of hardcoding the behavior, and leave the current behavior as
the default.
(When using x264 with open-gop, it even means that every stream so
encoded will only have one keyframe (the IDR frame at the beginning),
because for some reason x264 never uses IDR frames in open-gop mode even
at scenecuts (where the gop is closed and where using an IDR frame
instead of a recovery point SEI would actually save a few bytes).)
}
pps_id = get_ue_golomb(&nal.gb);
if (pps_id >= MAX_PPS_COUNT) {
@@ -370,9 +372,11 @@ static inline int parse_nal_units(AVCodecParserContext *s,
p->ps.sps = p->ps.pps->sps;
sps = p->ps.sps;
-// heuristic to detect non marked keyframes
-if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0] <= 1
&& s->pict_type == AV_PICTURE_TYPE_I)
-s->key_frame = 1;
+if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
+// heuristic to detect non marked keyframes
+if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0] <= 1
&& s->pict_type == AV_PICTURE_TYPE_I)
+s->key_frame = 1;
+}
p->poc.frame_num = get_bits(&nal.gb, sps->log2_max_frame_num);
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index ba437dfbb8..8680e35524 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -339,8 +339,8 @@ lavf_container_fate()
outdir="tests/data/lavf-fate"
file=${outdir}/lavf.$t
input="${target_samples}/$1"
-do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input" "$ENC_OPTS
-metadata title=lavftest" -vcodec copy -acodec copy
-do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
$target_path/$file $3
+do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input" "$ENC_OPTS
-metadata title=lavftest" -vcodec copy -acodec copy $3
+do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
$target_path/$file $4
}
lavf_image(){
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 4dfb77d250..57d16fba6f 100644
-
[FFmpeg-devel] [PATCH 1/8] avcodec/argo: use pixel format provided by the demuxer
But fall back to bits_per_raw_sample, in case we're with older
libavformat.
Signed-off-by: Zane van Iperen
---
libavcodec/argo.c| 21 ++---
libavcodec/version.h | 2 +-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/libavcodec/argo.c b/libavcodec/argo.c
index 87c646f56c..9df5b8a8d3 100644
--- a/libavcodec/argo.c
+++ b/libavcodec/argo.c
@@ -676,13 +676,20 @@ static av_cold int decode_init(AVCodecContext *avctx)
{
ArgoContext *s = avctx->priv_data;
-switch (avctx->bits_per_raw_sample) {
-case 8: s->bpp = 1;
- avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
-case 24: s->bpp = 4;
- avctx->pix_fmt = AV_PIX_FMT_BGR0; break;
-default: avpriv_request_sample(s, "depth == %u",
avctx->bits_per_raw_sample);
- return AVERROR_PATCHWELCOME;
+if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
+/* For compat with older libavformat. */
+switch (avctx->bits_per_raw_sample) {
+case 8: s->bpp = 1;
+avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
+case 24: s->bpp = 4;
+avctx->pix_fmt = AV_PIX_FMT_BGR0; break;
+default: avpriv_request_sample(s, "depth == %u",
avctx->bits_per_raw_sample);
+return AVERROR_PATCHWELCOME;
+}
+}
+
+if (avctx->pix_fmt != AV_PIX_FMT_PAL8 && avctx->pix_fmt !=
AV_PIX_FMT_BGR0) {
+return AVERROR_INVALIDDATA;
}
s->frame = av_frame_alloc();
diff --git a/libavcodec/version.h b/libavcodec/version.h
index c660f70669..91325ce4e7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 59
#define LIBAVCODEC_VERSION_MINOR 3
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.31.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 2/8] avformat/argo_brp: set pixel format directly
Signed-off-by: Zane van Iperen
---
libavformat/argo_brp.c | 11 ++-
libavformat/version.h | 2 +-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/argo_brp.c b/libavformat/argo_brp.c
index 059418cd1d..6cc0c4a3f8 100644
--- a/libavformat/argo_brp.c
+++ b/libavformat/argo_brp.c
@@ -230,7 +230,16 @@ static int argo_brp_read_header(AVFormatContext *s)
st->codecpar->width = bvid->width;
st->codecpar->height = bvid->height;
st->nb_frames = bvid->num_frames;
-st->codecpar->bits_per_raw_sample = bvid->depth;
+
+if (bvid->depth == 8) {
+st->codecpar->format = AV_PIX_FMT_PAL8;
+} else if (bvid->depth == 24) {
+st->codecpar->format = AV_PIX_FMT_BGR0;
+} else {
+st->codecpar->format = AV_PIX_FMT_NONE;
+avpriv_request_sample(s, "depth == %u", bvid->depth);
+}
+
} else if (hdr->codec_id == BRP_CODEC_ID_BASF) {
/*
* It would make the demuxer significantly more complicated
diff --git a/libavformat/version.h b/libavformat/version.h
index 6519bba101..03eb20ad82 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 59
#define LIBAVFORMAT_VERSION_MINOR 4
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/8] avformat/argo_cvg: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen --- libavformat/argo_cvg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/argo_cvg.c b/libavformat/argo_cvg.c index 73db777199..37288a1496 100644 --- a/libavformat/argo_cvg.c +++ b/libavformat/argo_cvg.c @@ -183,7 +183,6 @@ static int argo_cvg_read_header(AVFormatContext *s) par->channel_layout = AV_CH_LAYOUT_MONO; par->bits_per_coded_sample = 4; -par->bits_per_raw_sample= 16; par->block_align= ARGO_CVG_BLOCK_ALIGN; par->bit_rate = par->sample_rate * par->bits_per_coded_sample; -- 2.31.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8] avformat/argo_asf: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index c3ac49fdc2..ef647ae20c 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -109,12 +109,7 @@ int ff_argo_asf_fill_stream(AVFormatContext *s, AVStream
*st, const ArgoASFFileH
st->codecpar->bits_per_coded_sample = 4;
-if (ckhdr->flags & ASF_CF_BITS_PER_SAMPLE)
-st->codecpar->bits_per_raw_sample = 16;
-else
-st->codecpar->bits_per_raw_sample = 8;
-
-if (st->codecpar->bits_per_raw_sample != 16) {
+if (!(ckhdr->flags & ASF_CF_BITS_PER_SAMPLE)) {
/* The header allows for these, but I've never seen any files with
them. */
avpriv_request_sample(s, "Non 16-bit samples");
return AVERROR_PATCHWELCOME;
--
2.31.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 5/8] avformat/alp: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen --- libavformat/alp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/alp.c b/libavformat/alp.c index bc19f02083..4876015f4b 100644 --- a/libavformat/alp.c +++ b/libavformat/alp.c @@ -127,7 +127,6 @@ static int alp_read_header(AVFormatContext *s) return AVERROR_INVALIDDATA; par->bits_per_coded_sample = 4; -par->bits_per_raw_sample= 16; par->block_align= 1; par->bit_rate = par->channels * par->sample_rate * -- 2.31.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 6/8] avformat/apm: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen --- libavformat/apm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/apm.c b/libavformat/apm.c index 6ae53b8712..6a047c5095 100644 --- a/libavformat/apm.c +++ b/libavformat/apm.c @@ -146,7 +146,6 @@ static int apm_read_header(AVFormatContext *s) par->codec_type= AVMEDIA_TYPE_AUDIO; par->codec_id = AV_CODEC_ID_ADPCM_IMA_APM; par->format= AV_SAMPLE_FMT_S16; -par->bits_per_raw_sample = 16; par->bit_rate = par->channels * par->sample_rate * par->bits_per_coded_sample; -- 2.31.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 7/8] avformat/kvag: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen --- libavformat/kvag.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/kvag.c b/libavformat/kvag.c index 94dc1ddc04..b5ebe418e6 100644 --- a/libavformat/kvag.c +++ b/libavformat/kvag.c @@ -80,7 +80,6 @@ static int kvag_read_header(AVFormatContext *s) par->sample_rate= hdr.sample_rate; par->bits_per_coded_sample = 4; -par->bits_per_raw_sample= 16; par->block_align= 1; par->bit_rate = par->channels * (uint64_t)par->sample_rate * -- 2.31.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 8/8] avformat/pp_bnk: don't set bits_per_raw_sample
Signed-off-by: Zane van Iperen --- libavformat/pp_bnk.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c index dfe5343cde..821d14a4aa 100644 --- a/libavformat/pp_bnk.c +++ b/libavformat/pp_bnk.c @@ -214,7 +214,6 @@ static int pp_bnk_read_header(AVFormatContext *s) par->sample_rate= hdr.sample_rate; par->bits_per_coded_sample = 4; -par->bits_per_raw_sample= 16; par->block_align= 1; par->bit_rate = par->sample_rate * (int64_t)par->bits_per_coded_sample * par->channels; -- 2.31.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add a parser flag to enable keyframe tagging heuristics
James Almer: > On 7/15/2021 5:23 PM, Michael Niedermayer wrote: >> >> the concept of a keyframe is a point at which decoding can begin >> that really are at least 3 points >> >> the point at which packets begin to be input into the decoder >> >> the point at which the decoder is able to return some decoded >> data which closely resembles the encoder input >> >> and the point at which the decoder output matches 1:1 the output >> of a decoder starting from frame 0 > > All parsers save for h264 are currently only tagging packets containing > a coded bitstream that, when decoded, it fully resets the decoding state > and depends on no previously parsed data or state, which is what (most) > muxers expect. This approach here is making the h264 do the same by > default (in line with the decoder), to ensure some muxers don't wrongly > mark certain packets as sync samples, while letting others remain > liberal about it. > That is not true: The HEVC parser marks packets that may have leading RASL pictures as keyframe; such frames are not sync samples according to my version of ISO/IEC 14496-15. (Furthermore, for parsers that don't set key_frame the recommended fallback is by checking pict_type for AV_PICTURE_TYPE_I (parse_packet() in libavformat/utils.c does this); if one follows this, then MPEG-2 I-frames will be marked as keyframes, even when they are not sync samples in ISOBMFF if there is an open GOP.) It seems to be mostly followed that random access points are keyframes even if they are not IDR frames/even if there is an open GOP. In fact, the AV1 parser (which does not set it for delayed random access points (AV1's equivalent of open GOP)) seems to be an exception. And your claim (also contained in the commit message) that this brings the parser in line with the decoder is wrong, too: output_frame() in h264dec.c sets key_frame depending on sei_recovery_frame_cnt. - 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/8] avcodec/argo: use pixel format provided by the demuxer
Zane van Iperen:
> But fall back to bits_per_raw_sample, in case we're with older
> libavformat.
>
We are still in an open ABI phase, so you do not need to care about
older libavformat.
> Signed-off-by: Zane van Iperen
> ---
> libavcodec/argo.c| 21 ++---
> libavcodec/version.h | 2 +-
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/argo.c b/libavcodec/argo.c
> index 87c646f56c..9df5b8a8d3 100644
> --- a/libavcodec/argo.c
> +++ b/libavcodec/argo.c
> @@ -676,13 +676,20 @@ static av_cold int decode_init(AVCodecContext *avctx)
> {
> ArgoContext *s = avctx->priv_data;
>
> -switch (avctx->bits_per_raw_sample) {
> -case 8: s->bpp = 1;
> - avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
> -case 24: s->bpp = 4;
> - avctx->pix_fmt = AV_PIX_FMT_BGR0; break;
> -default: avpriv_request_sample(s, "depth == %u",
> avctx->bits_per_raw_sample);
> - return AVERROR_PATCHWELCOME;
> +if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
> +/* For compat with older libavformat. */
> +switch (avctx->bits_per_raw_sample) {
> +case 8: s->bpp = 1;
> +avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
> +case 24: s->bpp = 4;
> +avctx->pix_fmt = AV_PIX_FMT_BGR0; break;
> +default: avpriv_request_sample(s, "depth == %u",
> avctx->bits_per_raw_sample);
> +return AVERROR_PATCHWELCOME;
> +}
> +}
> +
> +if (avctx->pix_fmt != AV_PIX_FMT_PAL8 && avctx->pix_fmt !=
> AV_PIX_FMT_BGR0) {
> +return AVERROR_INVALIDDATA;
> }
>
> s->frame = av_frame_alloc();
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index c660f70669..91325ce4e7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #define LIBAVCODEC_VERSION_MAJOR 59
> #define LIBAVCODEC_VERSION_MINOR 3
> -#define LIBAVCODEC_VERSION_MICRO 101
> +#define LIBAVCODEC_VERSION_MICRO 102
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
>
___
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 3/3] avcodec/h264_parser: use the keyframe heuristics flag
James Almer:
> On 7/17/2021 9:30 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Tag only packets containing with IDR pictures as keyframes by
>>> default, same as
>>> the decoder.
>>> Fixes MP4 and Matroska muxers marking incorrect samples as Sync
>>> Samples in
>>> scenarios where this AVParser is used.
>>>
>>
>> 1. Could you please explain where you got the info that Matroska
>> keyframes need to be ISOBMFF Sync Samples from? Because it's actually
>> undefined what it exactly is; in case of AV1 (the only codec with a
>> detailed codec mapping) said mapping allows delayed random access points
>> to be marked as keyframes (without providing anything to actually signal
>> that these are delayed random access points), so a key frame is simply a
>> random access point. And that is how it is de-facto handled with all
>> other codecs as well. IMO it is ISOBMFF which is the outlier here.
>
> It was an assumption considering the Matroska h264 encapsulation is
> taken verbatim from ISOBMFF. But you're right, MKVToolnix does mark
> those as key.
>
It's not taken verbatim -- Matroska doesn't have an analog to the sync
samples table; actually, it is not even guaranteed that cues always
reference keyframes (MKVToolNix even allows to reference all blocks!),
although (lacking an alternative) demuxers operate under this assumption.
>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/h264_parser.c | 16 ++--
>>> tests/fate-run.sh | 4 ++--
>>> tests/fate/ffmpeg.mak | 2 +-
>>> tests/fate/lavf-container.mak | 12 ++--
>>> tests/fate/matroska.mak | 2 +-
>>> tests/ref/fate/copy-trac2211-avi | 2 +-
>>> tests/ref/fate/matroska-h264-remux | 4 ++--
>>> tests/ref/fate/segment-mp4-to-ts | 10 +-
>>> tests/ref/lavf-fate/h264.mp4 | 4 ++--
>>> 9 files changed, 30 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
>>> index d3c56cc188..532dc462b0 100644
>>> --- a/libavcodec/h264_parser.c
>>> +++ b/libavcodec/h264_parser.c
>>> @@ -344,9 +344,11 @@ static inline int
>>> parse_nal_units(AVCodecParserContext *s,
>>> get_ue_golomb_long(&nal.gb); // skip first_mb_in_slice
>>> slice_type = get_ue_golomb_31(&nal.gb);
>>> s->pict_type = ff_h264_golomb_to_pict_type[slice_type %
>>> 5];
>>> - if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
>>> - /* key frame, since recovery_frame_cnt is set */
>>> - s->key_frame = 1;
>>> + if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
>>> + if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
>>> + /* key frame, since recovery_frame_cnt is set */
>>> + s->key_frame = 1;
>>> + }
>>
>> 2. This change means that files that don't use IDR pictures, but only
>> recovery point SEIs won't have packets marked as keyframes at all any
>> more; this affects every open-gop video. This is way worse than an
>> incorrect sync sample list created by the mp4 muxer.
>
> I worked around this for the mpegts muxer as Kieran requested, but if
> Matroska is the same then the situation changes.
>
> I can add a user settable demuxer option for the autoinserted parser
> instead of hardcoding the behavior, and leave the current behavior as
> the default.
>
So the mp4 muxer would create invalid files by default and in case this
flag is set, it instead creates crippled files (where open gop random
access points are not marked as such)? Does not sound good to me.
An actual fix is to make the muxer aware of the difference between IDR
and ordinary keyframes (there is already a MOV_PARTIAL_SYNC_SAMPLE for
the latter; and there is already some parsing in case of MPEG-2).
(As much as I like to reuse the parsers for this, I don't really know
what exactly the parser should additionally return. Should this be
solved, we might need to add another field to AVPacket (given that the
new parsing API is supposed to be packet-based, said information should
be stored there; alternatively, one could also use more of AV_PKT_FLAG_*).
We do not even have to wait for the new parser API to get this
information out of the parser: We can just add new fields to
AVCodecParserContext; but we need to agree on whether this information
should be part of AVPacket and if so, how.)
- 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/3] avcodec: add a parser flag to enable keyframe tagging heuristics
On 7/17/2021 10:23 PM, Andreas Rheinhardt wrote: James Almer: On 7/15/2021 5:23 PM, Michael Niedermayer wrote: the concept of a keyframe is a point at which decoding can begin that really are at least 3 points the point at which packets begin to be input into the decoder the point at which the decoder is able to return some decoded data which closely resembles the encoder input and the point at which the decoder output matches 1:1 the output of a decoder starting from frame 0 All parsers save for h264 are currently only tagging packets containing a coded bitstream that, when decoded, it fully resets the decoding state and depends on no previously parsed data or state, which is what (most) muxers expect. This approach here is making the h264 do the same by default (in line with the decoder), to ensure some muxers don't wrongly mark certain packets as sync samples, while letting others remain liberal about it. That is not true: The HEVC parser marks packets that may have leading RASL pictures as keyframe; such frames are not sync samples according to my version of ISO/IEC 14496-15. (Furthermore, for parsers that don't set key_frame the recommended fallback is by checking pict_type for AV_PICTURE_TYPE_I (parse_packet() in libavformat/utils.c does this); if one follows this, then MPEG-2 I-frames will be marked as keyframes, even when they are not sync samples in ISOBMFF if there is an open GOP.) It seems to be mostly followed that random access points are keyframes even if they are not IDR frames/even if there is an open GOP. In fact, the AV1 parser (which does not set it for delayed random access points (AV1's equivalent of open GOP)) seems to be an exception. And your claim (also contained in the commit message) that this brings the parser in line with the decoder is wrong, too: output_frame() in h264dec.c sets key_frame depending on sei_recovery_frame_cnt. True, missed that. But for example in the case of intra_refresh.h264 it would not trigger, whereas the parser does tag it. - 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". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/subtitles: Deduplicate subtitles' read_(packet|seek|close)
Andreas Rheinhardt: > Signed-off-by: Andreas Rheinhardt > --- > libavformat/assdec.c| 27 +++ > libavformat/jacosubdec.c| 29 - > libavformat/lrcdec.c| 27 +++ > libavformat/mccdec.c| 27 +++ > libavformat/mpl2dec.c | 27 +++ > libavformat/mpsubdec.c | 27 +++ > libavformat/pjsdec.c| 27 +++ > libavformat/realtextdec.c | 27 +++ > libavformat/samidec.c | 27 +++ > libavformat/sccdec.c| 27 +++ > libavformat/srtdec.c| 27 +++ > libavformat/stldec.c| 26 +++--- > libavformat/subtitles.c | 21 + > libavformat/subtitles.h | 7 +++ > libavformat/subviewer1dec.c | 27 +++ > libavformat/subviewerdec.c | 27 +++ > libavformat/vplayerdec.c| 27 +++ > 17 files changed, 74 insertions(+), 360 deletions(-) > Will apply. - 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 3/3] avcodec/h264_parser: use the keyframe heuristics flag
On 7/17/2021 11:19 PM, Andreas Rheinhardt wrote:
James Almer:
On 7/17/2021 9:30 PM, Andreas Rheinhardt wrote:
James Almer:
Tag only packets containing with IDR pictures as keyframes by
default, same as
the decoder.
Fixes MP4 and Matroska muxers marking incorrect samples as Sync
Samples in
scenarios where this AVParser is used.
1. Could you please explain where you got the info that Matroska
keyframes need to be ISOBMFF Sync Samples from? Because it's actually
undefined what it exactly is; in case of AV1 (the only codec with a
detailed codec mapping) said mapping allows delayed random access points
to be marked as keyframes (without providing anything to actually signal
that these are delayed random access points), so a key frame is simply a
random access point. And that is how it is de-facto handled with all
other codecs as well. IMO it is ISOBMFF which is the outlier here.
It was an assumption considering the Matroska h264 encapsulation is
taken verbatim from ISOBMFF. But you're right, MKVToolnix does mark
those as key.
It's not taken verbatim -- Matroska doesn't have an analog to the sync
samples table; actually, it is not even guaranteed that cues always
reference keyframes (MKVToolNix even allows to reference all blocks!),
although (lacking an alternative) demuxers operate under this assumption.
Signed-off-by: James Almer
---
libavcodec/h264_parser.c | 16 ++--
tests/fate-run.sh | 4 ++--
tests/fate/ffmpeg.mak | 2 +-
tests/fate/lavf-container.mak | 12 ++--
tests/fate/matroska.mak | 2 +-
tests/ref/fate/copy-trac2211-avi | 2 +-
tests/ref/fate/matroska-h264-remux | 4 ++--
tests/ref/fate/segment-mp4-to-ts | 10 +-
tests/ref/lavf-fate/h264.mp4 | 4 ++--
9 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..532dc462b0 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -344,9 +344,11 @@ static inline int
parse_nal_units(AVCodecParserContext *s,
get_ue_golomb_long(&nal.gb); // skip first_mb_in_slice
slice_type = get_ue_golomb_31(&nal.gb);
s->pict_type = ff_h264_golomb_to_pict_type[slice_type %
5];
- if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
- /* key frame, since recovery_frame_cnt is set */
- s->key_frame = 1;
+ if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
+ if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
+ /* key frame, since recovery_frame_cnt is set */
+ s->key_frame = 1;
+ }
2. This change means that files that don't use IDR pictures, but only
recovery point SEIs won't have packets marked as keyframes at all any
more; this affects every open-gop video. This is way worse than an
incorrect sync sample list created by the mp4 muxer.
I worked around this for the mpegts muxer as Kieran requested, but if
Matroska is the same then the situation changes.
I can add a user settable demuxer option for the autoinserted parser
instead of hardcoding the behavior, and leave the current behavior as
the default.
So the mp4 muxer would create invalid files by default and in case this
flag is set, it instead creates crippled files (where open gop random
access points are not marked as such)? Does not sound good to me.
An actual fix is to make the muxer aware of the difference between IDR
and ordinary keyframes (there is already a MOV_PARTIAL_SYNC_SAMPLE for
the latter; and there is already some parsing in case of MPEG-2).
The current code uses this flag to write stps atoms, and at least for
h264 that's not apparently what should be done (We need roll sample
groups instead).
(As much as I like to reuse the parsers for this, I don't really know
what exactly the parser should additionally return. Should this be
solved, we might need to add another field to AVPacket (given that the
new parsing API is supposed to be packet-based, said information should
be stored there; alternatively, one could also use more of AV_PKT_FLAG_*).
A packet flag would work to signal that the packet contains an ordinary
key frame, but not to propagate values like recovery_frame_cnt (to write
roll distance). That would probably require a side data struct.
We do not even have to wait for the new parser API to get this
information out of the parser: We can just add new fields to
AVCodecParserContext; but we need to agree on whether this information
should be part of AVPacket and if so, how.)
It would need to be part of AVPacket if we do it as something
AVCodecParsers and demuxers can output and propagate. Even a bsfs
inserted by the muxer would require whatever we get out of it to be
attached to the packet. But we could maybe avoid this with a new bsfs
based parser API where for example reduced s
Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add a parser flag to enable keyframe tagging heuristics
James Almer: > On 7/17/2021 10:23 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 7/15/2021 5:23 PM, Michael Niedermayer wrote: the concept of a keyframe is a point at which decoding can begin that really are at least 3 points the point at which packets begin to be input into the decoder the point at which the decoder is able to return some decoded data which closely resembles the encoder input and the point at which the decoder output matches 1:1 the output of a decoder starting from frame 0 >>> >>> All parsers save for h264 are currently only tagging packets containing >>> a coded bitstream that, when decoded, it fully resets the decoding state >>> and depends on no previously parsed data or state, which is what (most) >>> muxers expect. This approach here is making the h264 do the same by >>> default (in line with the decoder), to ensure some muxers don't wrongly >>> mark certain packets as sync samples, while letting others remain >>> liberal about it. >>> >> That is not true: The HEVC parser marks packets that may have leading >> RASL pictures as keyframe; such frames are not sync samples according to >> my version of ISO/IEC 14496-15. (Furthermore, for parsers that don't set >> key_frame the recommended fallback is by checking pict_type for >> AV_PICTURE_TYPE_I (parse_packet() in libavformat/utils.c does this); if >> one follows this, then MPEG-2 I-frames will be marked as keyframes, even >> when they are not sync samples in ISOBMFF if there is an open GOP.) >> >> It seems to be mostly followed that random access points are keyframes >> even if they are not IDR frames/even if there is an open GOP. In fact, >> the AV1 parser (which does not set it for delayed random access points >> (AV1's equivalent of open GOP)) seems to be an exception. >> >> And your claim (also contained in the commit message) that this brings >> the parser in line with the decoder is wrong, too: output_frame() in >> h264dec.c sets key_frame depending on sei_recovery_frame_cnt. > > True, missed that. But for example in the case of intra_refresh.h264 it > would not trigger, whereas the parser does tag it. > Yeah, we don't handle intra refresh well at all; and I am pretty sure that quite a lot of people would not consider the packets containing the recovery point SEI message a keyframe if recovery_frame_cnt is > 0. As has been said in the earlier thread, there is no single correct definition for keyframe. - 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 v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
>
> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >
> > From: Linjie Fu
> >
> > Skip the logic of frame rate emulation until the input reaches the
> > specified start time.
> >
> > Test CMD:
> >$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >
> > Before the patch:
> > first time to got frame, it takes 257305 us
> > After this patch:
> > first time to got frame, it takes 48879 us
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: fixed the mixed declaration and code warning
> > Calculate the time to get the first frame:
> > https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> > fftools/ffmpeg.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index e97d879cb3..c8849e4250 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
> > **pkt)
> > {
> > if (f->rate_emu) {
> > int i;
> > +int64_t pts;
> > +int64_t now;
> > for (i = 0; i < f->nb_streams; i++) {
> > InputStream *ist = input_streams[f->ist_index + i];
> > -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> > -int64_t now = av_gettime_relative() - ist->start;
> > +if (!ist->got_output)
> > +continue;
> > +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> > +now = av_gettime_relative() - ist->start;
> > if (pts > now)
> > return AVERROR(EAGAIN);
> > }
> > --
> > 2.31.1
> ping, thx.
>
Another ping, thx.
___
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 QSV variants of the stack filters
Hi Haihao,
On Wed, Jun 9, 2021 at 3:36 PM Haihao Xiang wrote:
>
> Include hstack_qsv, vstack_qsv and xstack_qsv, some code is copy and
> pasted from other filters
>
> Example:
> $> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -filter_complex
> "[0:v][0:v]hstack_qsv" -f null -
> ---
> configure | 6 +
> libavfilter/Makefile | 3 +
> libavfilter/allfilters.c | 3 +
> libavfilter/vf_stack_qsv.c | 499 +
> 4 files changed, 511 insertions(+)
> create mode 100644 libavfilter/vf_stack_qsv.c
>
> diff --git a/configure b/configure
> index 6bfd98b384..89adb3a374 100755
> --- a/configure
> +++ b/configure
> @@ -3705,6 +3705,12 @@ vpp_qsv_filter_select="qsvvpp"
> xfade_opencl_filter_deps="opencl"
> yadif_cuda_filter_deps="ffnvcodec"
> yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
> +hstack_qsv_filter_deps="libmfx"
> +hstack_qsv_filter_select="qsvvpp"
> +vstack_qsv_filter_deps="libmfx"
> +vstack_qsv_filter_select="qsvvpp"
> +xstack_qsv_filter_deps="libmfx"
> +xstack_qsv_filter_select="qsvvpp"
>
> # examples
> avio_list_dir_deps="avformat avutil"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index bc81033e3f..16cf2c8712 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -493,6 +493,9 @@ OBJS-$(CONFIG_YAEPBLUR_FILTER) +=
> vf_yaepblur.o
> OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
> OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
> OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
> +OBJS-$(CONFIG_HSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
> +OBJS-$(CONFIG_VSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
> +OBJS-$(CONFIG_XSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
>
> OBJS-$(CONFIG_ALLRGB_FILTER) += vsrc_testsrc.o
> OBJS-$(CONFIG_ALLYUV_FILTER) += vsrc_testsrc.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c6afef835f..278ccb99a9 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -471,6 +471,9 @@ extern const AVFilter ff_vf_yaepblur;
> extern const AVFilter ff_vf_zmq;
> extern const AVFilter ff_vf_zoompan;
> extern const AVFilter ff_vf_zscale;
> +extern const AVFilter ff_vf_hstack_qsv;
> +extern const AVFilter ff_vf_vstack_qsv;
> +extern const AVFilter ff_vf_xstack_qsv;
>
> extern const AVFilter ff_vsrc_allrgb;
> extern const AVFilter ff_vsrc_allyuv;
> diff --git a/libavfilter/vf_stack_qsv.c b/libavfilter/vf_stack_qsv.c
> new file mode 100644
> index 00..87f611eece
> --- /dev/null
> +++ b/libavfilter/vf_stack_qsv.c
> @@ -0,0 +1,499 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * Hardware accelerated hstack, vstack and xstack filters based on Intel
> Quick Sync Video VPP
> + */
> +
> +#include "libavutil/opt.h"
> +#include "libavutil/common.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/eval.h"
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/parseutils.h"
> +
> +#include "internal.h"
> +#include "avfilter.h"
"avfilter.h" has been included in lots of *.h like "internal.h" and
"qsvvpp.h", hence seems to be redundant here.
> +#include "filters.h"
> +#include "formats.h"
> +#include "video.h"
> +
> +#include "framesync.h"
> +#include "qsvvpp.h"
> +
> +#define OFFSET(x) offsetof(QSVStackContext, x)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> +
> +enum {
> +QSV_STACK_H = 0,
> +QSV_STACK_V = 1,
> +QSV_STACK_X = 2
> +};
> +
> +typedef struct QSVStackContext {
> +const AVClass *class;
> +QSVVPPContext *qsv;
> +QSVVPPParam qsv_param;
> +mfxExtVPPComposite comp_conf;
> +int mode;
> +FFFrameSync fs;
> +
> +/* Options */
> +int nb_inputs;
> +int shortest;
> +double scale;
> +char *layout;
> +uint8_t fillcolor[4];
> +char *fillcolor_str;
> +int fillcolor_enable;
> +} QSVStackContext;
> +
> +static void rgb2yuv(float r, float g, float b, int *y, int *u, int *v, int
> depth
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On 2021-07-18 09:32, Linjie Fu wrote:
On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
From: Linjie Fu
Skip the logic of frame rate emulation until the input reaches the
specified start time.
Test CMD:
$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
Before the patch:
first time to got frame, it takes 257305 us
After this patch:
first time to got frame, it takes 48879 us
Signed-off-by: Linjie Fu
---
[v2]: fixed the mixed declaration and code warning
Calculate the time to get the first frame:
https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
fftools/ffmpeg.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e97d879cb3..c8849e4250 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
{
if (f->rate_emu) {
int i;
+int64_t pts;
+int64_t now;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
-int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
-int64_t now = av_gettime_relative() - ist->start;
+if (!ist->got_output)
+continue;
+pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
+now = av_gettime_relative() - ist->start;
if (pts > now)
return AVERROR(EAGAIN);
}
--
2.31.1
ping, thx.
Another ping, thx.
I pushed changes to this code yesterday. I don't think it's required
anymore, but do test.
Regards,
Gyan
___
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: fix -t inaccurate recording time
On 2021-07-17 15:10, Gyan Doshi wrote: On 2021-07-10 15:42, Gyan Doshi wrote: On 2021-07-09 11:03, Shiwang.Xie wrote: Pings. Will test. Fix confirmed. Will push tomorrow if no one objects. Pushed as 694545b6d5fff5a8242b5fab8c1746e74a06f9ba Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
Hi Gyan,
On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi wrote:
>
>
>
> On 2021-07-18 09:32, Linjie Fu wrote:
> > On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
> >> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >>> From: Linjie Fu
> >>>
> >>> Skip the logic of frame rate emulation until the input reaches the
> >>> specified start time.
> >>>
> >>> Test CMD:
> >>> $ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >>>
> >>> Before the patch:
> >>> first time to got frame, it takes 257305 us
> >>> After this patch:
> >>> first time to got frame, it takes 48879 us
> >>>
> >>> Signed-off-by: Linjie Fu
> >>> ---
> >>> [v2]: fixed the mixed declaration and code warning
> >>> Calculate the time to get the first frame:
> >>> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>> fftools/ffmpeg.c | 8 ++--
> >>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>> index e97d879cb3..c8849e4250 100644
> >>> --- a/fftools/ffmpeg.c
> >>> +++ b/fftools/ffmpeg.c
> >>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f,
> >>> AVPacket **pkt)
> >>> {
> >>> if (f->rate_emu) {
> >>> int i;
> >>> +int64_t pts;
> >>> +int64_t now;
> >>> for (i = 0; i < f->nb_streams; i++) {
> >>> InputStream *ist = input_streams[f->ist_index + i];
> >>> -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>> -int64_t now = av_gettime_relative() - ist->start;
> >>> +if (!ist->got_output)
> >>> +continue;
> >>> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>> +now = av_gettime_relative() - ist->start;
> >>> if (pts > now)
> >>> return AVERROR(EAGAIN);
> >>> }
> >>> --
> >>> 2.31.1
> >> ping, thx.
> >>
> > Another ping, thx.
>
> I pushed changes to this code yesterday. I don't think it's required
> anymore, but do test.
>
Thanks for the review, tested after applying the readrate patch, I'm
afraid that it's not identical as hope,
since ist->nb_packets would increase no matter input stream got output or not:
(lldb) p ist->nb_packets
(uint64_t) $4 = 1
(lldb) p ist->got_output
(int) $5 = 0
Hence we still need to add the check for ist->got_output, or replace
the ist->nb_packets.
Also there is a new warning caught by the check in patchwork, probably
"mixed declaration and code warning".
Will send patches to rebase and fix.
- 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 v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On 2021-07-18 10:42, Linjie Fu wrote:
Hi Gyan,
On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi wrote:
On 2021-07-18 09:32, Linjie Fu wrote:
On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
From: Linjie Fu
Skip the logic of frame rate emulation until the input reaches the
specified start time.
Test CMD:
$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
Before the patch:
first time to got frame, it takes 257305 us
After this patch:
first time to got frame, it takes 48879 us
Signed-off-by: Linjie Fu
---
[v2]: fixed the mixed declaration and code warning
Calculate the time to get the first frame:
https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
fftools/ffmpeg.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e97d879cb3..c8849e4250 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
{
if (f->rate_emu) {
int i;
+int64_t pts;
+int64_t now;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
-int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
-int64_t now = av_gettime_relative() - ist->start;
+if (!ist->got_output)
+continue;
+pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
+now = av_gettime_relative() - ist->start;
if (pts > now)
return AVERROR(EAGAIN);
}
--
2.31.1
ping, thx.
Another ping, thx.
I pushed changes to this code yesterday. I don't think it's required
anymore, but do test.
Thanks for the review, tested after applying the readrate patch, I'm
afraid that it's not identical as hope,
since ist->nb_packets would increase no matter input stream got output or not:
(lldb) p ist->nb_packets
(uint64_t) $4 = 1
(lldb) p ist->got_output
(int) $5 = 0
Hence we still need to add the check for ist->got_output, or replace
the ist->nb_packets.
No, test the speed, not the parity of got_output. got_output is only
incremented when the stream is decoded. Won't work with streamcopy.
nb_packets is the correct check since it's incremented after the initial
packet is demuxed.
Also there is a new warning caught by the check in patchwork, probably
"mixed declaration and code warning".
Will send patches to rebase and fix.
There is already patch for the mixed warning.
Regards,
Gyan
___
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".
