[FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: Adjust threshold for NUV
Fixes: Timeout
Fixes:
49286/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5856252655173632
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index a423277808..e55d9fc7eb 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -256,6 +256,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_MVC2:maxpixels /= 128; break;
case AV_CODEC_ID_MWSC:maxpixels /= 256; break;
case AV_CODEC_ID_MXPEG: maxpixels /= 128; break;
+case AV_CODEC_ID_NUV: maxpixels /= 128; break;
case AV_CODEC_ID_OPUS:maxsamples /= 16384; break;
case AV_CODEC_ID_PNG: maxpixels /= 128; break;
case AV_CODEC_ID_APNG:maxpixels /= 128; 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 1/3] avformat/avisynth: add missing avs_release_video_frame
On 8/7/22 9:25 PM, Stephen Hutchinson wrote:
The AviSynth C API requires using avs_release_video_frame
whenever avs_get_frame has been used, but the recent addition
of frameprop reading to the demuxer was missing this in
avisynth_create_stream_video.
---
libavformat/avisynth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index a97d12b6b6..98b4d68a57 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -728,6 +728,7 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
st->codecpar->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
}
}
+avs_library.avs_release_video_frame(frame);
} else {
st->codecpar->field_order = AV_FIELD_UNKNOWN;
/* AviSynth works with frame-based video, detecting field order can
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mimic: Fix undefined pointer arithmetic
Michael Niedermayer: > On Fri, Aug 12, 2022 at 02:40:43PM +0200, Andreas Rheinhardt wrote: >> NULL + anything is UB. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/mimic.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > if its NULL, LGTM > It is (at least for the first keyframe). So I will therefore apply this. - 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] avcodec/mimic: Fix undefined pointer arithmetic
On Fri, Aug 12, 2022 at 02:40:43PM +0200, Andreas Rheinhardt wrote: > NULL + anything is UB. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/mimic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) if its NULL, LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire 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] ipfsgateway: Remove default gateway
On 12.08.2022 19:18, Michael Niedermayer wrote: And i dont think removing IPFS support entirely from FFmpeg is a smart choice. I wouldn't at all be upset about having proper IPFS support in FFmpeg, there's no argument there. The issue is that this has very little to do with actual/native IPFS support, but it's just a url rewriter, which on top of that comes with a hardcoded in default gateway. Which is run by a to me unknown company, with unknown interests. ___ 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] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 07:01:49PM +0200, Nicolas George wrote: > Michael Niedermayer (12022-08-12): > > Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog > > > > to grab data from DNS you can implement a full DNS server which recursivly > > resolves the request starting from the root name servers (which it needs to > > have > > hardcoded in some form) But this is something no application does because of > > latency and wide support of easier name resolution on platforms > > > > So what one does is to connect to local of ISP DNS server which caches > > results > > and does resolve from the root servers if needed (either directly or though > > platform APIs) > > Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one > > locally normally > > > > Below is how i understand IPFS, please someone correct me if iam wrong, iam > > listing this here as i think it makes sense for the dicussion to better > > understand > > what IPFS is before arguing about it > > > > IPFS seems closer to DNS in how it works than to how http works > > if you want to grab something from IPFS it cant just do it, it needs to > > connect > > to peers and find out which has the data. > > If you start from zero (and some hardcoded peer list) that will take more > > time > > than if there is a running node with active connections > > So for better performance we want to use a IPFS node which persists before > > and > > after the process with libavformat. This is the same as with a DNS server. > > > > I suspect IPFS provides little security against loging, > > If you run a IPFS node, others can likely find out what your node cached > > because > > thats the whole point, of caching data, so that others can get it. > > If you are concerned the http-ipfs gateway logs you, running your own node > > might > > be worse. IIUC thats like a public caching DNS server > > > > the other threat of the http-ipfs gateway modifying data can possible be > > prevented > > with some effort. > > IPFS urls IIUC contain the hash from a root of a merkle tree of the data so > > one > > can take a subset of the data with some more hashes and verify that the data > > matcheswhat the URL refers to. This also makes data immutable. There is > > mutable data in IPFS called IPNS. > > IPNS uses a hash of a public key allowing the private key owner only to > > modify > > the data. > > again it can in principle be checked that this is all unmodifed by any > > intermediate > > that makes IPFS different fron DNS and HTTP(S) which cannot be checked from > > the > > URL alone > > All this looks a lot like “magnet:” URLs for torrents, and we do not > consider FFmpeg should support torrents. But the practice can make the > difference: if leeching without seeding at all is supported, then it can > make sense. > > The goal that everything works out of the box is limited by the need for > safety for the user, and it is a concern for both a peer-to-peer > protocol and for an external gateway. And it is not limited to technical > security risks, it involves also legal liability: the information that > somebody accessed a resource that is considered illegal in their country > is more likely to leak. Also to consider: if FFmpeg hardcodes a default > gateway, secondary distributors might change that default into a less > trustworthy one. > > The simile with DNS has a significant limitation: DNS has been here > since forever, and we can assume it is properly configured everywhere. > In fact, FFmpeg does not use DNS, it uses the libc's resolver, which > could be configured not to use DNS at all. This protocol is a newfangled > thing, so the expectation that it just works is lower. > > It brings me to another point: how common is this thing? FFmpeg aims to This is easy to awnser, you can look at: google trends since 2015 when IPFS first release was worldwide https://trends.google.com/trends/explore?date=2015-01-01%202022-08-12=ipfs at that timescale its popularity is going up alot over time > support all protocols used in the world, but it is not meant to be a > showcase for somebody's vanity project or some company's new commercial > product. For this issue, I think the criterion the IETF uses to consider > something a standard is a good touchstone: are there several independent > and compatible implementations already out there? gthub search for ipfs has "10,204 repository results" first hit is a "IPFS implementation in Go" 3rd is a "IPFS implementation in JavaScript" looking further i see "Python implementation of IPFS, the InterPlanetary File System. Not even remotely done yet." further down "The Interplanetary File System (IPFS), implemented in Rust" so id say you can have an implementation of some form in every modern language And i dont think removing IPFS support entirely from FFmpeg is a smart choice. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
Michael Niedermayer (12022-08-12): > Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog > > to grab data from DNS you can implement a full DNS server which recursivly > resolves the request starting from the root name servers (which it needs to > have > hardcoded in some form) But this is something no application does because of > latency and wide support of easier name resolution on platforms > > So what one does is to connect to local of ISP DNS server which caches results > and does resolve from the root servers if needed (either directly or though > platform APIs) > Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one > locally normally > > Below is how i understand IPFS, please someone correct me if iam wrong, iam > listing this here as i think it makes sense for the dicussion to better > understand > what IPFS is before arguing about it > > IPFS seems closer to DNS in how it works than to how http works > if you want to grab something from IPFS it cant just do it, it needs to > connect > to peers and find out which has the data. > If you start from zero (and some hardcoded peer list) that will take more time > than if there is a running node with active connections > So for better performance we want to use a IPFS node which persists before and > after the process with libavformat. This is the same as with a DNS server. > > I suspect IPFS provides little security against loging, > If you run a IPFS node, others can likely find out what your node cached > because > thats the whole point, of caching data, so that others can get it. > If you are concerned the http-ipfs gateway logs you, running your own node > might > be worse. IIUC thats like a public caching DNS server > > the other threat of the http-ipfs gateway modifying data can possible be > prevented > with some effort. > IPFS urls IIUC contain the hash from a root of a merkle tree of the data so > one > can take a subset of the data with some more hashes and verify that the data > matcheswhat the URL refers to. This also makes data immutable. There is > mutable data in IPFS called IPNS. > IPNS uses a hash of a public key allowing the private key owner only to modify > the data. > again it can in principle be checked that this is all unmodifed by any > intermediate > that makes IPFS different fron DNS and HTTP(S) which cannot be checked from > the > URL alone All this looks a lot like “magnet:” URLs for torrents, and we do not consider FFmpeg should support torrents. But the practice can make the difference: if leeching without seeding at all is supported, then it can make sense. The goal that everything works out of the box is limited by the need for safety for the user, and it is a concern for both a peer-to-peer protocol and for an external gateway. And it is not limited to technical security risks, it involves also legal liability: the information that somebody accessed a resource that is considered illegal in their country is more likely to leak. Also to consider: if FFmpeg hardcodes a default gateway, secondary distributors might change that default into a less trustworthy one. The simile with DNS has a significant limitation: DNS has been here since forever, and we can assume it is properly configured everywhere. In fact, FFmpeg does not use DNS, it uses the libc's resolver, which could be configured not to use DNS at all. This protocol is a newfangled thing, so the expectation that it just works is lower. It brings me to another point: how common is this thing? FFmpeg aims to support all protocols used in the world, but it is not meant to be a showcase for somebody's vanity project or some company's new commercial product. For this issue, I think the criterion the IETF uses to consider something a standard is a good touchstone: are there several independent and compatible implementations already out there? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Tue, Aug 9, 2022 at 6:05 PM Pierre-Anthony Lemieux wrote:
>
> On Mon, Aug 8, 2022 at 7:50 AM Pierre-Anthony Lemieux
> wrote:
> >
> > On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
> > wrote:
> > >
> > > p...@sandflow.com:
> > > > From: Pierre-Anthony Lemieux
> > > >
> > > > Addresses
> > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> > > >
> > > > ---
> > > > libavformat/avformat.c | 66
> > > > libavformat/fifo.c | 8 ++---
> > > > libavformat/internal.h | 11 +++
> > > > libavformat/mux.h| 9 --
> > > > libavformat/mux_utils.c | 28 -
> > > > libavformat/segment.c| 6 ++--
> > > > libavformat/tee.c| 7 ++---
> > > > libavformat/webm_chunk.c | 6 ++--
> > > > 8 files changed, 86 insertions(+), 55 deletions(-)
> > > >
> > > > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > > > index 30d6ea6a49..19c7219471 100644
> > > > --- a/libavformat/avformat.c
> > > > +++ b/libavformat/avformat.c
> > > > @@ -235,6 +235,72 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > > > AVStream *src)
> > > > return 0;
> > > > }
> > > >
> > > > +/**
> > > > + * Copy all stream parameters from source to destination stream, with
> > > > the
> > > > + * exception of the index field, which is usually set by
> > > > avformat_new_stream().
> > > > + *
> > > > + * @param dst pointer to destination AVStream
> > > > + * @param src pointer to source AVStream
> > > > + * @return >=0 on success, AVERROR code on error
> > > > + */
> > > > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > > > +{
> > > > +int ret;
> > > > +
> > > > +dst->id = src->id;
> > > > +dst->time_base = src->time_base;
> > > > +dst->start_time = src->start_time;
> > > > +dst->duration= src->duration;
> > > > +dst->nb_frames = src->nb_frames;
> > > > +dst->disposition = src->disposition;
> > > > +dst->discard = src->discard;
> > > > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > > > +dst->avg_frame_rate = src->avg_frame_rate;
> > > > +dst->event_flags = src->event_flags;
> > > > +dst->r_frame_rate= src->r_frame_rate;
> > > > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > > > +
> > > > +av_dict_free(>metadata);
> > > > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +ret = ff_stream_side_data_copy(dst, src);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +av_packet_unref(>attached_pic);
> > > > +if (src->attached_pic.data) {
> > > > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +}
> > > > +
> > > > +return 0;
> > > > +}
> > > > +
> > > > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream
> > > > *src)
> > > > +{
> > > > +AVStream *st;
> > > > +int ret;
> > > > +
> > > > +st = avformat_new_stream(dst_ctx, NULL);
> > > > +if (!st)
> > > > +return NULL;
> > > > +
> > > > +ret = stream_params_copy(st, src);
> > > > +if (ret < 0) {
> > > > +ff_remove_stream(dst_ctx, st);
> > > > +return NULL;
> > > > +}
> > > > +
> > > > +return st;
> > > > +}
> > > > +
> > > > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > > > {
> > > > AVProgram *program = NULL;
> > > > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > > > index ead2bdc5cf..55d413b952 100644
> > > > --- a/libavformat/fifo.c
> > > > +++ b/libavformat/fifo.c
> > > > @@ -505,13 +505,11 @@ static int fifo_mux_init(AVFormatContext *avf,
> > > > const AVOutputFormat *oformat,
> > > > avf2->flags = avf->flags;
> > > >
> > > > for (i = 0; i < avf->nb_streams; ++i) {
> > > > -AVStream *st = avformat_new_stream(avf2, NULL);
> > > > +AVStream *st = NULL;
> > > > +
> > > > +st = ff_stream_clone(avf2, avf->streams[i]);
> > >
> > > I don't know why you stopped initializing st directly with its eventual
> > > value (if I see this corrently, the line wouldn't be overlong). I can
> > > fix this upon commit if you allow. Anyway, I will apply this in two days
> > > unless there are any comments from anyone else.
> >
> > I thought if() was not favored.
> >
> > Please modify as you see fit.
> >
> > Thanks.
>
> Couldn't this entire code block be simplified to the following?
>
> for (i = 0; i < avf->nb_streams; ++i)
> if (!ff_stream_clone(avf2, avf->streams[i]))
> return AVERROR(ENOMEM);
>
> Happy to submit a revised patch if it helps.
See v8.
>
>
> >
> > >
> > > > if (!st)
> > > >
Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
On Fri, Aug 12, 2022 at 09:12:30AM +0200, Dawid Kozinski/Robot SDK (PLT) /SRPOL/Staff Engineer/삼성전자 wrote: > If the only issue is about 'No newline at end of file', of course I will add > it and provide new patches. iam not sure what the issue was i just saw the error and didnt immedeatly see anything wrong when i looked into the file so i reported it assuming it would replroduce on your side i will recheck if theres a new version, do you have some git repro i can test so you dont have to repost this for just a line ending thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch 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] fftools/ffmpeg: move stream-dependent starttime correction to transcode_init()
On Thu, Aug 11, 2022 at 09:45:48AM +0200, Anton Khirnov wrote: > Currently this code is located in the discontinuity handling block, > where it does not belong. > --- > Now with previously missed 'is->start_time != AV_NOPTS_VALUE' check > --- > fftools/ffmpeg.c | 40 ++-- > 1 file changed, 22 insertions(+), 18 deletions(-) seems working fine thx [...] -- 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 v2] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx
On 8/9/2022 10:38 AM, "zhilizhao(赵志立)" wrote: > It’s suspicious to return a timestamp with unknown timebase. Would you suggest erroring in the case where there's no frag_stream? That could make sense. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 12:03:17AM +0200, Timo Rothenpieler wrote: > On 11.08.2022 22:18, Michael Niedermayer wrote: > > On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote: [...] > > > > > > This is just your - valued! - opinion, but still just 1. I insist on > > > waiting to hear from Michael to hear a decision on this, mainly because he > > > was quite persistent in asking for this feature to begin with. > > > > Iam quite happy to leave this discussion to others, last time it was > > just that noone seemed to care over a really long time to comment > > now it seems everyone really cares. > > I think its very good that people are thinking about it now, it is a > > rather annoying situation as each option is a tradeoff which sucks in > > some form > > Maybe the ultimate best would be a change at the IPFS protocol level > > so that lean light clients could securely use the protocol easily > > > The patch wasn't on my radar at all. I had assumed it was actually > implementing IPFS in some fashion. > Not via an entire external http gateway. I'm a bit confused that it's its > whole own protocol. Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog to grab data from DNS you can implement a full DNS server which recursivly resolves the request starting from the root name servers (which it needs to have hardcoded in some form) But this is something no application does because of latency and wide support of easier name resolution on platforms So what one does is to connect to local of ISP DNS server which caches results and does resolve from the root servers if needed (either directly or though platform APIs) Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one locally normally Below is how i understand IPFS, please someone correct me if iam wrong, iam listing this here as i think it makes sense for the dicussion to better understand what IPFS is before arguing about it IPFS seems closer to DNS in how it works than to how http works if you want to grab something from IPFS it cant just do it, it needs to connect to peers and find out which has the data. If you start from zero (and some hardcoded peer list) that will take more time than if there is a running node with active connections So for better performance we want to use a IPFS node which persists before and after the process with libavformat. This is the same as with a DNS server. I suspect IPFS provides little security against loging, If you run a IPFS node, others can likely find out what your node cached because thats the whole point, of caching data, so that others can get it. If you are concerned the http-ipfs gateway logs you, running your own node might be worse. IIUC thats like a public caching DNS server the other threat of the http-ipfs gateway modifying data can possible be prevented with some effort. IPFS urls IIUC contain the hash from a root of a merkle tree of the data so one can take a subset of the data with some more hashes and verify that the data matcheswhat the URL refers to. This also makes data immutable. There is mutable data in IPFS called IPNS. IPNS uses a hash of a public key allowing the private key owner only to modify the data. again it can in principle be checked that this is all unmodifed by any intermediate that makes IPFS different fron DNS and HTTP(S) which cannot be checked from the URL alone Also i hope this whole thread can stay technical because this all is a technical problem and a technical mailing list and it should have a technical solution. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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] track id could be zore
On 8/12/2022 8:26 AM, 帝江-VII wrote: > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 6ee6ed0950..3b0c328e6a 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -4916,8 +4916,6 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > flags = avio_rb24(pb); > > track_id = avio_rb32(pb); > - if (!track_id) > -return AVERROR_INVALIDDATA; Bad patch formatting, aside, no, it cannot. Zero is not a valid track ID. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
Derek Buitenhuis (12022-08-11): > I agree... we should never send a users data through *any* service they > haven't explicitly asked for. Ever. Regardless of who runs it and who > is deemed "trustworthy". Absolutely. And Kieran's simile with DNS is very good. It is not just a question of whether the gateway might turn evil, there are also concerns of privacy. > > The patch wasn't on my radar at all. I had assumed it was actually > > implementing IPFS in some fashion. > Yes, I had assumed the same too, and thus wasn't following the sets > at all. > > As it exists right now though, I don't really see why lavf needs what > amounts to a URL builder for a service as a "protocol" - this totally > the wrong layer to do that at... I also assumed it was a native implementation. If it is just a matter of translating “ipfs://whatever” into “https://gateway/wHaTeVeR”, a perl script in tools/ would be a reasonable expedient. Native implementations are a huge part of what made FFmpeg great: you build from source, without a shit-ton of extra libraries that might not be packaged or recent enough on long-term distributions, and you get support for most codecs, formats and protocols in the world. Unfortunately, work on implementing native versions of codecs and protocols seems to have gotten out of fashion. For protocols, I can blame the lack of framework: our pedestrian read/write blocking API is not adapted to modern protocols that require asynchronous operation. I had the project of building a new framework for networking and protocols; in fact I have a large part of how I want to make it work in the back of my mind already. But considering the shortsightedness of the leadership of the project these days about framework that is not an obvious incremental enhancement directly related to existing code, I do not expect to invest more time into it any time soon. The same goes for most API enhancement I had promised over the years. Too bad. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Fri, 12 Aug 2022 at 15:48, Derek Buitenhuis wrote: > On 8/12/2022 3:34 PM, Mark Gaiser wrote: > > Great opinion you 2, 0 constructiveness. > > That doesn't help at all. > > Your tone has been pretty rude in this whole thread. > > > Please try again in a constructive manner that convinces me of your > > undoubtedly great arguments! > > You seem to be defining anything that involves removing it as "not > consructive", which is rather convenient. > > I would also ask you stop sending unwanted private mails to people on this > thread about the subject. > > - Derek > I would like to refer this issue to the technical committee for a final decision. TC is copied into this email. Kieran ___ 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] ipfsgateway: Remove default gateway
On 8/12/2022 3:34 PM, Mark Gaiser wrote: > Great opinion you 2, 0 constructiveness. > That doesn't help at all. Your tone has been pretty rude in this whole thread. > Please try again in a constructive manner that convinces me of your > undoubtedly great arguments! You seem to be defining anything that involves removing it as "not consructive", which is rather convenient. I would also ask you stop sending unwanted private mails to people on this thread about the subject. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
> > Great opinion you 2, 0 constructiveness. > That doesn't help at all. > > Please try again in a constructive manner that convinces me of your > undoubtedly great arguments! > Please let me know what IPFS has to do with Interplanetary Communications. (hint: none). Kieran ___ 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] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 4:30 PM Kieran Kunhya wrote: > On Fri, 12 Aug 2022 at 15:22, Vittorio Giovara > > wrote: > > > On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis < > > derek.buitenh...@gmail.com> wrote: > > > > > As it exists right now though, I don't really see why lavf needs what > > > amounts to a URL builder for a service as a "protocol" - this totally > > > the wrong layer to do that at... > > > > > > > Agreed, this protocol should be dropped IMO. > > > > Agreed. In a similar vein, we don't suddenly decide to pick DNS servers for > the user if they don't have one configured. Great opinion you 2, 0 constructiveness. That doesn't help at all. Please try again in a constructive manner that convinces me of your undoubtedly great arguments! ___ 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] ipfsgateway: Remove default gateway
On Fri, 12 Aug 2022 at 15:22, Vittorio Giovara wrote: > On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > > > As it exists right now though, I don't really see why lavf needs what > > amounts to a URL builder for a service as a "protocol" - this totally > > the wrong layer to do that at... > > > > Agreed, this protocol should be dropped IMO. > Agreed. In a similar vein, we don't suddenly decide to pick DNS servers for the user if they don't have one configured. Kieran ___ 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] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > As it exists right now though, I don't really see why lavf needs what > amounts to a URL builder for a service as a "protocol" - this totally > the wrong layer to do that at... > Agreed, this protocol should be dropped IMO. -- Vittorio ___ 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] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 8/11/2022 11:03 PM, Timo Rothenpieler wrote: > > Any kind of built in hardcoded server is not acceptable imo. > > Even with it pointing to our own infrastructure, we can't really > > guarantee its availability, specially should the protocol gain traction > > and heavy use. > > I agree... we should never send a users data through *any* service they > haven't explicitly asked for. Ever. Regardless of who runs it and who > is deemed "trustworthy". > > > The patch wasn't on my radar at all. I had assumed it was actually > > implementing IPFS in some fashion. > > Yes, I had assumed the same too, and thus wasn't following the sets > at all. > > As it exists right now though, I don't really see why lavf needs what > amounts to a URL builder for a service as a "protocol" - this totally > the wrong layer to do that at... > > - Derek > (not a specific reply to you, Derek, just a reply to the latest message in this discussion.) First I'd like to highlight the idea of security here. As that seems to play a big part in this thread. The points Michael makes with regards to letting a user find a gateway are in my opinion valid. If a user googles for a gateway, you hope they would find/use dweb.link, as it is a safe option. Now I'm not saying other gateways are "less safe", not at all! But the dweb.link gateway is run by protocol labs themselves and is used a lot. It has a team behind it monitoring it who have a quite high responsibility of keeping the gateway functioning properly. Not many gateways have the resources behind it that dweb.link has. Also, with regards to video playback, that is guaranteed to work on dweb.link whereas less resource heavy gateways could potentially throttle such traffic. I won't call out names but i do know of at least 1 very popular one that does this. I don't know how far I can answer organizational details about dweb.link, but I do know that it's of high importance for Protocol Labs to make sure the gateway functions normally. If there are questions about security audits or guarantees about "user data" [1] policies then I can forward those to the persons who know or have the ability to get answers. That all being said. In the case where the user has no local gateway (still a likely fact) it would be far more secure to have a fallback one (dweb.link) then to let the user google one. Just pushing a sensationalized view of "it has to go because of security" might actually have the adverse effect so be very careful and constructive when you say that. Now to play devel's advocate for a moment. Say dweb.link remains as default, how likely is it to be hacked and truly causing harm for ffmpeg users? A lot of steps have to happen before that harm really can be done, here's a list of things i can come up with (but it's likely much longer). - the gateway would have to be hacked and that would not be detected (unlikely) - the malicious party would have to change gateway code and still remain undetected (again unlikely) - ffmpeg users would actually get malicious data (unlikely) - that malicious data would have to be able to cause actual harm (yet again unlikely, ffmpeg is more likely to crash with malicious data [2]) So in realistic terms, how likely is it that dweb.link causes an actual security risk for the user? The more I think about it, the less likely I think that's going to be. On the other hand, removing the default gateway very definitely has a much higher potential for a security risk. I hope we can proceed this discussion in a more mature way with actual constructive arguments. Passionate and emotional calls to remove this "just because" won't help the discussion forward by any means. I also ask to refrain from arguments like "it should've never been merged and therefore removed", that's like a very demotivating response to even consider responding to. So keep it nice and constructive and we'll figure out a way that works for everyone :) [1] there are no users.. At most you have webserver logging winch, with other data, could be used for tracking purposes perhaps. [2] for malicious data to be successfully abused there would also have to be at least 1 severe bug in ffmpeg itself. Probably in the http stack but if that passes in the codec itself. ___ 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 v1 3/3] lavc/vaapi_vp9: add surface internal re-allocation capability
From: Linjie Fu
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/vaapi_vp9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..fc6ff0a0f2 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,5 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
.uninit = ff_vaapi_decode_uninit,
.frame_params = ff_vaapi_common_frame_params,
.priv_data_size = sizeof(VAAPIDecodeContext),
-.caps_internal= HWACCEL_CAP_ASYNC_SAFE,
+.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
HWACCEL_CAP_INTERNAL_ALLOC,
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel
From: Linjie Fu
Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to
re-allocate surface internally through ff_decode_get_hw_frames_ctx.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/decode.c | 36
libavcodec/hwconfig.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index d66d5a4160..00c9141d91 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1176,6 +1176,33 @@ static const AVCodecHWConfigInternal
*get_hw_config(AVCodecContext *avctx, enum
return hw_config;
}
+static int hwaccel_realloc_surface(AVCodecContext *avctx)
+{
+const AVCodecHWConfigInternal *hw_config;
+int ret;
+
+if (avctx->hw_frames_ctx)
+av_buffer_unref(>hw_frames_ctx);
+
+hw_config = get_hw_config(avctx, avctx->pix_fmt);
+if (!hw_config)
+return AV_PIX_FMT_NONE;
+
+if (avctx->hw_device_ctx &&
+hw_config->public.methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) {
+const AVHWDeviceContext *device_ctx =
+(AVHWDeviceContext*)avctx->hw_device_ctx->data;
+ret = ff_decode_get_hw_frames_ctx(avctx, device_ctx->type);
+if (ret < 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to re-allocate hwaccel
surface internally.\n");
+return AV_PIX_FMT_NONE;
+}
+} else
+return AV_PIX_FMT_NONE;
+
+return hw_config->public.pix_fmt;
+}
+
int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
{
const AVPixFmtDescriptor *desc;
@@ -1202,6 +1229,15 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
return AV_PIX_FMT_NONE;
for (;;) {
+if (avctx->internal->hwaccel_priv_data &&
+avctx->hwaccel->caps_internal & HWACCEL_CAP_INTERNAL_ALLOC) {
+err = hwaccel_realloc_surface(avctx);
+if (err < 0)
+av_log(avctx, AV_LOG_WARNING, "Try to re-initialize all.\n");
+else
+return err;
+}
+
// Remove the previous hwaccel, if there was one.
hwaccel_uninit(avctx);
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..7405c66c07 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -24,6 +24,7 @@
#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
+#define HWACCEL_CAP_INTERNAL_ALLOC (1 << 1)
typedef struct AVCodecHWConfigInternal {
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 1/3] lavc/decode: Add get_hw_config function
From: Linjie Fu
Wrap the procedure of getting the hardware config from a pixel format
into a function.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/decode.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 75373989c6..d66d5a4160 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1156,6 +1156,26 @@ static void hwaccel_uninit(AVCodecContext *avctx)
av_buffer_unref(>hw_frames_ctx);
}
+static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext *avctx,
enum AVPixelFormat fmt)
+{
+const AVCodecHWConfigInternal *hw_config;
+int i;
+
+if (ffcodec(avctx->codec)->hw_configs) {
+for (i = 0;; i++) {
+hw_config = ffcodec(avctx->codec)->hw_configs[i];
+if (!hw_config)
+break;
+if (hw_config->public.pix_fmt == fmt)
+break;
+}
+} else {
+hw_config = NULL;
+}
+
+return hw_config;
+}
+
int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
{
const AVPixFmtDescriptor *desc;
@@ -1213,18 +1233,7 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
break;
}
-if (ffcodec(avctx->codec)->hw_configs) {
-for (i = 0;; i++) {
-hw_config = ffcodec(avctx->codec)->hw_configs[i];
-if (!hw_config)
-break;
-if (hw_config->public.pix_fmt == user_choice)
-break;
-}
-} else {
-hw_config = NULL;
-}
-
+hw_config = get_hw_config(avctx, user_choice);
if (!hw_config) {
// No config available, so no extra setup required.
ret = user_choice;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/mimic: Fix undefined pointer arithmetic
NULL + anything is UB.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mimic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mimic.c b/libavcodec/mimic.c
index ce5c2afd19..bcf10b7ae1 100644
--- a/libavcodec/mimic.c
+++ b/libavcodec/mimic.c
@@ -268,8 +268,9 @@ static int decode(MimicContext *ctx, int quality, int
num_coeffs,
const int qscale= av_clip(1 - quality, is_chroma ? 1000 : 2000,
1) << 2;
const int stride= ctx->frames[ctx->cur_index ].f->linesize[plane];
-const uint8_t *src = ctx->frames[ctx->prev_index].f->data[plane];
uint8_t *dst = ctx->frames[ctx->cur_index ].f->data[plane];
+/* src is unused for I frames; set to avoid UB pointer arithmetic. */
+const uint8_t *src = is_iframe ? dst :
ctx->frames[ctx->prev_index].f->data[plane];
for (y = 0; y < ctx->num_vblocks[plane]; y++) {
for (x = 0; x < ctx->num_hblocks[plane]; x++) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
I've just added missing newline at end of file -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Thursday, August 11, 2022 11:06 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec On Thu, Aug 11, 2022 at 02:36:47PM +0200, Dawid Kozinski wrote: > - Added muxer for EVC format (MP4, raw) > - Added demuxer for EVC format (MP4) > - Added evc extension to the list of extensions for ff_mov_demuxer > - Added information to moov atom [...] > diff --git a/libavformat/evc.h b/libavformat/evc.h > new file mode 100644 > index 00..d7b93d521d > --- /dev/null > +++ b/libavformat/evc.h > @@ -0,0 +1,147 @@ > +/* > + * EVC helper functions for muxers > + * Copyright (c) 2022 Dawid Kozinski > + * > + * 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 AVFORMAT_EVC_H > +#define AVFORMAT_EVC_H [...] > +#endif // AVFORMAT_EVC_H > \ No newline at end of file fate-source is not happy about this: --- ./tests/ref/fate/source 2022-07-29 22:42:50.354493777 +0200 +++ tests/data/fate/source 2022-08-11 22:54:59.715488573 +0200 @@ -21,6 +21,7 @@ compat/djgpp/math.h compat/float/float.h compat/float/limits.h +libavformat/evc.h tools/decode_simple.h Use of av_clip() where av_clip_uintp2() could be used: Use of av_clip() where av_clip_intp2() could be used: Test source failed. Look at tests/data/fate/source.err for details. tests/Makefile:304: recipe for target 'fate-source' failed make: *** [fate-source] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
- Added muxer for EVC format (MP4, raw)
- Added demuxer for EVC format (MP4)
- Added evc extension to the list of extensions for ff_mov_demuxer
- Added information to moov atomi
Signed-off-by: Dawid Kozinski
---
doc/muxers.texi | 6 +
libavformat/Makefile | 4 +-
libavformat/allformats.c | 2 +
libavformat/evc.c| 461 +++
libavformat/evc.h| 148 +
libavformat/evcdec.c | 142
libavformat/isom_tags.c | 2 +
libavformat/mov.c| 2 +-
libavformat/movenc.c | 35 ++-
libavformat/rawenc.c | 13 ++
10 files changed, 812 insertions(+), 3 deletions(-)
create mode 100644 libavformat/evc.c
create mode 100644 libavformat/evc.h
create mode 100644 libavformat/evcdec.c
diff --git a/doc/muxers.texi b/doc/muxers.texi
index b2f4326aae..08ab20c09e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2124,6 +2124,12 @@ DTS Coherent Acoustics (DCA) audio.
Dolby Digital Plus, also known as Enhanced AC-3, audio.
+@subsection evc
+
+MPEG-5 Essential Video Coding (EVC) / EVC / MPEG-5 Part 1 EVC video.
+
+Extensions: evc
+
@subsection g722
ITU-T G.722 audio.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index e420384355..f5326aea79 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -249,6 +249,8 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o pcm.o
OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
+OBJS-$(CONFIG_EVC_DEMUXER) += evcdec.o rawdec.o
+OBJS-$(CONFIG_EVC_MUXER) += rawenc.o
OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_encryption.o
OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
OBJS-$(CONFIG_HNM_DEMUXER) += hnm.o
@@ -358,7 +360,7 @@ OBJS-$(CONFIG_MOV_DEMUXER) += mov.o
mov_chan.o mov_esds.o \
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o
\
movenchint.o mov_chan.o rtp.o \
movenccenc.o movenc_ttml.o
rawutils.o \
-dovi_isom.o
+dovi_isom.o evc.o
OBJS-$(CONFIG_MP2_MUXER) += rawenc.o
OBJS-$(CONFIG_MP3_DEMUXER) += mp3dec.o replaygain.o
OBJS-$(CONFIG_MP3_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ae4479fb7a..dfce49d149 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -148,6 +148,8 @@ extern const AVInputFormat ff_ea_cdata_demuxer;
extern const AVInputFormat ff_eac3_demuxer;
extern const AVOutputFormat ff_eac3_muxer;
extern const AVInputFormat ff_epaf_demuxer;
+extern const AVInputFormat ff_evc_demuxer;
+extern const AVOutputFormat ff_evc_muxer;
extern const AVOutputFormat ff_f4v_muxer;
extern const AVInputFormat ff_ffmetadata_demuxer;
extern const AVOutputFormat ff_ffmetadata_muxer;
diff --git a/libavformat/evc.c b/libavformat/evc.c
new file mode 100644
index 00..42d09bce01
--- /dev/null
+++ b/libavformat/evc.c
@@ -0,0 +1,461 @@
+/*
+ * EVC helper functions for muxers
+ * Copyright (c) 2022 Dawid Kozinski
+ *
+ * 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
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/get_bits.h"
+#include "libavcodec/golomb.h"
+#include "avformat.h"
+#include "avio.h"
+#include "evc.h"
+#include "avio_internal.h"
+
+// The length field that indicates the length in bytes of the following NAL
unit is configured to be of 4 bytes
+#define EVC_NAL_UNIT_LENGTH_BYTE(4) /* byte */
+#define EVC_NAL_HEADER_SIZE (2) /* byte */
+
+// rpl structure
+typedef struct RefPicListStruct {
+int poc;
+int tid;
+int ref_pic_num;
+int ref_pic_active_num;
+int ref_pics[EVC_MAX_NUM_REF_PICS];
+char pic_type;
+
+} RefPicListStruct;
+
+// The sturcture reflects SPS RBSP(raw byte sequence payload) layout
+// @see ISO_IEC_23094-1 section 7.3.2.1
+//
+// The following descriptors specify the parsing process of each
[FFmpeg-devel] [PATCH 1/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
- Added new entry to codec IDs list - Added new entry to the codec descriptor list - Bumped libavcodec minor version - Changes in Changelog and MAINTAINERS files - Added xeve encoder wrapper - Added xevd dencoder wrapper - Added documentation for xeve and xevd wrappers - Added parser for EVC format - Changes in project configuration file and libavcodec Makefilei Signed-off-by: Dawid Kozinski --- Changelog | 3 +- MAINTAINERS | 2 + configure | 8 + doc/decoders.texi | 24 ++ doc/encoders.texi | 92 + doc/general_contents.texi | 19 + libavcodec/Makefile | 3 + libavcodec/allcodecs.c| 2 + libavcodec/avcodec.h | 3 + libavcodec/codec_desc.c | 8 + libavcodec/codec_id.h | 1 + libavcodec/evc_parser.c | 758 ++ libavcodec/libxevd.c | 420 + libavcodec/libxeve.c | 601 ++ libavcodec/parsers.c | 1 + libavcodec/profiles.c | 6 + libavcodec/profiles.h | 1 + libavcodec/version.h | 2 +- 18 files changed, 1952 insertions(+), 2 deletions(-) create mode 100644 libavcodec/evc_parser.c create mode 100644 libavcodec/libxevd.c create mode 100644 libavcodec/libxeve.c diff --git a/Changelog b/Changelog index fa83786a20..f41e260247 100644 --- a/Changelog +++ b/Changelog @@ -82,7 +82,8 @@ version 5.0: - VideoToolbox ProRes encoder - anlmf audio filter - IMF demuxer (experimental) - +- eXtra-fast Essential Video Encoder (XEVE) +- eXtra-fast Essential Video Decoder (XEVD) version 4.4: - AudioToolbox output device diff --git a/MAINTAINERS b/MAINTAINERS index ed2ec0b90c..03c052e0bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -206,6 +206,7 @@ Codecs: libvpx* James Zern libxavs.c Stefan Gehrer libxavs2.cHuiwen Ren + libxev*.c, evc_parser.c Dawid Kozinski libzvbi-teletextdec.c Marton Balint lzo.h, lzo.c Reimar Doeffinger mdec.cMichael Niedermayer @@ -426,6 +427,7 @@ Muxers/Demuxers: dv.c Roman Shaposhnik electronicarts.c Peter Ross epafdec.c Paul B Mahol + evcdec.c Dawid Kozinski ffm* Baptiste Coudurier flic.cMike Melanson flvdec.c Michael Niedermayer diff --git a/configure b/configure index 090ccf21a7..f294b09759 100755 --- a/configure +++ b/configure @@ -291,6 +291,8 @@ External library support: --enable-libwebp enable WebP encoding via libwebp [no] --enable-libx264 enable H.264 encoding via x264 [no] --enable-libx265 enable HEVC encoding via x265 [no] + --enable-libxeve enable EVC encoding via libxeve [no] + --enable-libxevd enable EVC decoding via libxevd [no] --enable-libxavs enable AVS encoding via xavs [no] --enable-libxavs2enable AVS2 encoding via xavs2 [no] --enable-libxcb enable X11 grabbing using XCB [autodetect] @@ -1875,6 +1877,8 @@ EXTERNAL_LIBRARY_LIST=" libvorbis libvpx libwebp +libxevd +libxeve libxml2 libzimg libzmq @@ -3397,6 +3401,8 @@ libx264rgb_encoder_select="libx264_encoder" libx265_encoder_deps="libx265" libxavs_encoder_deps="libxavs" libxavs2_encoder_deps="libxavs2" +libxevd_decoder_deps="libxevd" +libxeve_encoder_deps="libxeve" libxvid_encoder_deps="libxvid" libzvbi_teletext_decoder_deps="libzvbi" vapoursynth_demuxer_deps="vapoursynth" @@ -6705,6 +6711,8 @@ enabled libx265 && require_pkg_config libx265 x265 x265.h x265_api_get require_cpp_condition libx265 x265.h "X265_BUILD >= 70" enabled libxavs && require libxavs "stdint.h xavs.h" xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs" enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0" "stdint.h xavs2.h" xavs2_api_get +enabled libxevd && require_pkg_config libxevd "xevd >= 0.4.0" "xevd.h" xevd_decode +enabled libxeve && require_pkg_config libxeve "xeve >= 0.4.0" "xeve.h" xeve_encode enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore enabled libzimg && require_pkg_config libzimg "zimg >= 2.7.0" zimg.h zimg_get_api_version enabled libzmq&& require_pkg_config libzmq "libzmq >= 4.2.1" zmq.h zmq_ctx_new diff --git a/doc/decoders.texi b/doc/decoders.texi index e2fcbf5dc9..0bd9096114 100644 --- a/doc/decoders.texi +++ b/doc/decoders.texi @@ -126,6 +126,30 @@ Set amount of frame threads to use during decoding. The default value is 0 (auto @end table +@section libxevd + +eXtra-fast Essential Video Decoder (XEVD) MPEG-5
Re: [FFmpeg-devel] [PATCH] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
bin.wang-at-intel@ffmpeg.org:
> From: bwang30
>
> This commit enabled assembly code with intel AVX512 VNNI and added unit test
> for sobel filter
>
> sobel_c: 4537
> sobel_avx512icl 2470
>
> Signed-off-by: bwang30
> ---
> libavfilter/convolution.h | 2 +
> libavfilter/vf_convolution.c | 8 ++
> libavfilter/x86/vf_convolution.asm| 162 ++
> libavfilter/x86/vf_convolution_init.c | 18 +++
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 +
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/vf_convolution.c | 116 ++
> 8 files changed, 311 insertions(+)
> create mode 100644 tests/checkasm/vf_convolution.c
>
> diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
> index 88aabe9a20..143b0fb2d9 100644
> --- a/libavfilter/convolution.h
> +++ b/libavfilter/convolution.h
> @@ -61,4 +61,6 @@ typedef struct ConvolutionContext {
> } ConvolutionContext;
>
> void ff_convolution_init_x86(ConvolutionContext *s);
> +void ff_sobel_init_x86(ConvolutionContext *s);
> +int ff_filter_param_init(AVFilterContext *ctx);
> #endif
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index 9a9c099e6d..98aa952258 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -874,6 +874,9 @@ static int param_init(AVFilterContext *ctx)
> if (s->depth > 8)
> for (p = 0; p < s->nb_planes; p++)
> s->filter[p] = filter16_sobel;
> +#if CONFIG_CONVOLUTION_FILTER && ARCH_X86_64
> +ff_sobel_init_x86(s);
> +#endif
> } else if (!strcmp(ctx->filter->name, "kirsch")) {
> if (s->depth > 8)
> for (p = 0; p < s->nb_planes; p++)
> @@ -887,6 +890,11 @@ static int param_init(AVFilterContext *ctx)
> return 0;
> }
>
> +int ff_filter_param_init(AVFilterContext *ctx)
> +{
> +return param_init(ctx);
> +}
> +
> static int config_input(AVFilterLink *inlink)
> {
> AVFilterContext *ctx = inlink->dst;
> diff --git a/libavfilter/x86/vf_convolution.asm
> b/libavfilter/x86/vf_convolution.asm
> index 754d4d1064..59c807b218 100644
> --- a/libavfilter/x86/vf_convolution.asm
> +++ b/libavfilter/x86/vf_convolution.asm
> @@ -22,6 +22,10 @@
>
> SECTION_RODATA
> half: dd 0.5
> +data_p1: dd 1
> +data_n1: dd -1
> +data_p2: dd 2
> +data_n2: dd -2
>
> SECTION .text
>
> @@ -154,3 +158,161 @@ cglobal filter_3x3, 4, 15, 7, dst, width, rdiv, bias,
> matrix, ptr, c0, c1, c2, c
> INIT_XMM sse4
> FILTER_3X3
> %endif
> +
> +
> +%macro SOBEL_MUL_16 3
> +movd xmm2, [%2]
> +VPBROADCASTD m2, xmm2
> +movdqu xmm3, [c%1q + xq]
> +vpmovzxbd m3, xmm3
> +vpdpbusd m%3, m3, m2
> +%endmacro
> +
> +%macro SOBEL_ADD_16 2
> +movdqu xmm3, [c%1q + xq]
> +vpmovzxbd m3, xmm3
> +vpaddd m%2, m3
> +%endmacro
> +
> +
> +%macro SOBEL_MUL 2
> +movzx ptrd, byte [c%1q + xq]
> +imul ptrd, [%2]
> +add rd, ptrd
> +%endmacro
> +
> +%macro SOBEL_ADD 1
> +movzx ptrd, byte [c%1q + xq]
> +add rd, ptrd
> +%endmacro
> +
> +; void filter_sobel_avx512(uint8_t *dst, int width,
> +; float scale, float delta, const int *const matrix,
> +; const uint8_t *c[], int peak, int radius,
> +; int dstride, int stride)
> +%macro FILTER_SOBEL 0
> +%if UNIX64
> +cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4,
> c5, c6, c7, c8, r, x
> +%else
> +cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1,
> c2, c3, c4, c5, c6, c7, c8, r, x
> +%endif
> +%if WIN64
> +SWAP xmm0, xmm2
> +SWAP xmm1, xmm3
> +mov r2q, matrixmp
> +mov r3q, ptrmp
> +DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8,
> r, x
> +%endif
> +movsxdifnidn widthq, widthd
> +VBROADCASTSS m0, xmm0
> +VBROADCASTSS m1, xmm1
> +pxor m6, m6
> +mov c0q, [ptrq + 0*gprsize]
> +mov c1q, [ptrq + 1*gprsize]
> +mov c2q, [ptrq + 2*gprsize]
> +mov c3q, [ptrq + 3*gprsize]
> +mov c4q, [ptrq + 4*gprsize]
> +mov c5q, [ptrq + 5*gprsize]
> +mov c6q, [ptrq + 6*gprsize]
> +mov c7q, [ptrq + 7*gprsize]
> +mov c8q, [ptrq + 8*gprsize]
> +
> +xor xq, xq
> +cmp widthq, mmsize/4
> +jl .loop2
> +
> +mov rq, widthq
> +and rq, mmsize/4-1
> +sub widthq, rq
> +
> +.loop1:
> +pxor m4, m4
> +pxor m5, m5
> +
> +;Gx
> +SOBEL_MUL_16 0, data_n1, 4
> +SOBEL_MUL_16 1, data_n2, 4
> +SOBEL_MUL_16 2, data_n1, 4
> +SOBEL_ADD_16 6, 4
> +SOBEL_MUL_16 7, data_p2, 4
> +SOBEL_ADD_16 8, 4
> +
> +cvtdq2ps m4, m4
> +mulps m4, m4
> +
> +;Gy
> +SOBEL_MUL_16 0, data_n1, 5
> +SOBEL_ADD_16 2, 5
> +SOBEL_MUL_16 3, data_n2, 5
> +SOBEL_MUL_16 5, data_p2, 5
> +SOBEL_MUL_16 6, data_n1, 5
> +SOBEL_ADD_16 8, 5
>
[FFmpeg-devel] [PATCH] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
From: bwang30
This commit enabled assembly code with intel AVX512 VNNI and added unit test
for sobel filter
sobel_c: 4537
sobel_avx512icl 2470
Signed-off-by: bwang30
---
libavfilter/convolution.h | 2 +
libavfilter/vf_convolution.c | 8 ++
libavfilter/x86/vf_convolution.asm| 162 ++
libavfilter/x86/vf_convolution_init.c | 18 +++
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_convolution.c | 116 ++
8 files changed, 311 insertions(+)
create mode 100644 tests/checkasm/vf_convolution.c
diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
index 88aabe9a20..143b0fb2d9 100644
--- a/libavfilter/convolution.h
+++ b/libavfilter/convolution.h
@@ -61,4 +61,6 @@ typedef struct ConvolutionContext {
} ConvolutionContext;
void ff_convolution_init_x86(ConvolutionContext *s);
+void ff_sobel_init_x86(ConvolutionContext *s);
+int ff_filter_param_init(AVFilterContext *ctx);
#endif
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index 9a9c099e6d..98aa952258 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -874,6 +874,9 @@ static int param_init(AVFilterContext *ctx)
if (s->depth > 8)
for (p = 0; p < s->nb_planes; p++)
s->filter[p] = filter16_sobel;
+#if CONFIG_CONVOLUTION_FILTER && ARCH_X86_64
+ff_sobel_init_x86(s);
+#endif
} else if (!strcmp(ctx->filter->name, "kirsch")) {
if (s->depth > 8)
for (p = 0; p < s->nb_planes; p++)
@@ -887,6 +890,11 @@ static int param_init(AVFilterContext *ctx)
return 0;
}
+int ff_filter_param_init(AVFilterContext *ctx)
+{
+return param_init(ctx);
+}
+
static int config_input(AVFilterLink *inlink)
{
AVFilterContext *ctx = inlink->dst;
diff --git a/libavfilter/x86/vf_convolution.asm
b/libavfilter/x86/vf_convolution.asm
index 754d4d1064..59c807b218 100644
--- a/libavfilter/x86/vf_convolution.asm
+++ b/libavfilter/x86/vf_convolution.asm
@@ -22,6 +22,10 @@
SECTION_RODATA
half: dd 0.5
+data_p1: dd 1
+data_n1: dd -1
+data_p2: dd 2
+data_n2: dd -2
SECTION .text
@@ -154,3 +158,161 @@ cglobal filter_3x3, 4, 15, 7, dst, width, rdiv, bias,
matrix, ptr, c0, c1, c2, c
INIT_XMM sse4
FILTER_3X3
%endif
+
+
+%macro SOBEL_MUL_16 3
+movd xmm2, [%2]
+VPBROADCASTD m2, xmm2
+movdqu xmm3, [c%1q + xq]
+vpmovzxbd m3, xmm3
+vpdpbusd m%3, m3, m2
+%endmacro
+
+%macro SOBEL_ADD_16 2
+movdqu xmm3, [c%1q + xq]
+vpmovzxbd m3, xmm3
+vpaddd m%2, m3
+%endmacro
+
+
+%macro SOBEL_MUL 2
+movzx ptrd, byte [c%1q + xq]
+imul ptrd, [%2]
+add rd, ptrd
+%endmacro
+
+%macro SOBEL_ADD 1
+movzx ptrd, byte [c%1q + xq]
+add rd, ptrd
+%endmacro
+
+; void filter_sobel_avx512(uint8_t *dst, int width,
+; float scale, float delta, const int *const matrix,
+; const uint8_t *c[], int peak, int radius,
+; int dstride, int stride)
+%macro FILTER_SOBEL 0
+%if UNIX64
+cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4,
c5, c6, c7, c8, r, x
+%else
+cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1,
c2, c3, c4, c5, c6, c7, c8, r, x
+%endif
+%if WIN64
+SWAP xmm0, xmm2
+SWAP xmm1, xmm3
+mov r2q, matrixmp
+mov r3q, ptrmp
+DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8,
r, x
+%endif
+movsxdifnidn widthq, widthd
+VBROADCASTSS m0, xmm0
+VBROADCASTSS m1, xmm1
+pxor m6, m6
+mov c0q, [ptrq + 0*gprsize]
+mov c1q, [ptrq + 1*gprsize]
+mov c2q, [ptrq + 2*gprsize]
+mov c3q, [ptrq + 3*gprsize]
+mov c4q, [ptrq + 4*gprsize]
+mov c5q, [ptrq + 5*gprsize]
+mov c6q, [ptrq + 6*gprsize]
+mov c7q, [ptrq + 7*gprsize]
+mov c8q, [ptrq + 8*gprsize]
+
+xor xq, xq
+cmp widthq, mmsize/4
+jl .loop2
+
+mov rq, widthq
+and rq, mmsize/4-1
+sub widthq, rq
+
+.loop1:
+pxor m4, m4
+pxor m5, m5
+
+;Gx
+SOBEL_MUL_16 0, data_n1, 4
+SOBEL_MUL_16 1, data_n2, 4
+SOBEL_MUL_16 2, data_n1, 4
+SOBEL_ADD_16 6, 4
+SOBEL_MUL_16 7, data_p2, 4
+SOBEL_ADD_16 8, 4
+
+cvtdq2ps m4, m4
+mulps m4, m4
+
+;Gy
+SOBEL_MUL_16 0, data_n1, 5
+SOBEL_ADD_16 2, 5
+SOBEL_MUL_16 3, data_n2, 5
+SOBEL_MUL_16 5, data_p2, 5
+SOBEL_MUL_16 6, data_n1, 5
+SOBEL_ADD_16 8, 5
+
+cvtdq2psm5, m5
+VFMADD231PS m4, m5, m5
+
+sqrtpsm4, m4
+mulps m4, m0 ; sum *= scale
+addps m4, m1 ; sum += delta
+cvttps2dq m4, m4
+vpmovusdb xmm4, m4
+movdqu[dstq + xq], xmm4
+
+add xq, mmsize/4
+cmp xq, widthq
+jl .loop1
+
+add widthq, rq
+cmp xq, widthq
+jge .end
+
+.loop2:
+xor
Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
If the only issue is about 'No newline at end of file', of course I will add it and provide new patches. -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Thursday, August 11, 2022 11:06 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec On Thu, Aug 11, 2022 at 02:36:47PM +0200, Dawid Kozinski wrote: > - Added muxer for EVC format (MP4, raw) > - Added demuxer for EVC format (MP4) > - Added evc extension to the list of extensions for ff_mov_demuxer > - Added information to moov atom [...] > diff --git a/libavformat/evc.h b/libavformat/evc.h > new file mode 100644 > index 00..d7b93d521d > --- /dev/null > +++ b/libavformat/evc.h > @@ -0,0 +1,147 @@ > +/* > + * EVC helper functions for muxers > + * Copyright (c) 2022 Dawid Kozinski > + * > + * 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 AVFORMAT_EVC_H > +#define AVFORMAT_EVC_H [...] > +#endif // AVFORMAT_EVC_H > \ No newline at end of file fate-source is not happy about this: --- ./tests/ref/fate/source 2022-07-29 22:42:50.354493777 +0200 +++ tests/data/fate/source 2022-08-11 22:54:59.715488573 +0200 @@ -21,6 +21,7 @@ compat/djgpp/math.h compat/float/float.h compat/float/limits.h +libavformat/evc.h tools/decode_simple.h Use of av_clip() where av_clip_uintp2() could be used: Use of av_clip() where av_clip_intp2() could be used: Test source failed. Look at tests/data/fate/source.err for details. tests/Makefile:304: recipe for target 'fate-source' failed make: *** [fate-source] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
Hi Michael, After I'd applied my patches onto master ffmpeg branch then I ran ffmpeg FATE but FATE didn't report any issues. I followed the steps described on https://ffmpeg.org/fate.html make fate-rsync SAMPLES=fate-suite/ make fate SAMPLES=fate-suite/ Then I checked tests/ref/fate/source file but it didn't contain any reports about issues inside. It looks like follows: Files without standard license headers: libavcodec/file_open.c libavcodec/ilbcdata.h libavcodec/ilbcdec.c libavcodec/interplayacm.c libavcodec/log2_tab.c libavcodec/reverse.c libavdevice/file_open.c libavdevice/reverse.c libavfilter/af_arnndn.c libavfilter/file_open.c libavfilter/log2_tab.c libavformat/file_open.c libavformat/golomb_tab.c libavformat/log2_tab.c libswresample/log2_tab.c libswscale/log2_tab.c tools/uncoded_frame.c tools/yuvcmp.c Headers without standard inclusion guards: compat/djgpp/math.h compat/float/float.h compat/float/limits.h tools/decode_simple.h Use of av_clip() where av_clip_uintp2() could be used: Use of av_clip() where av_clip_intp2() could be used: I'm not able to reproduce the issue pointed out by you. Tell me please if I do something the wrong way. Any hints will be appreciated. -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Thursday, August 11, 2022 11:06 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec On Thu, Aug 11, 2022 at 02:36:47PM +0200, Dawid Kozinski wrote: > - Added muxer for EVC format (MP4, raw) > - Added demuxer for EVC format (MP4) > - Added evc extension to the list of extensions for ff_mov_demuxer > - Added information to moov atom [...] > diff --git a/libavformat/evc.h b/libavformat/evc.h > new file mode 100644 > index 00..d7b93d521d > --- /dev/null > +++ b/libavformat/evc.h > @@ -0,0 +1,147 @@ > +/* > + * EVC helper functions for muxers > + * Copyright (c) 2022 Dawid Kozinski > + * > + * 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 AVFORMAT_EVC_H > +#define AVFORMAT_EVC_H [...] > +#endif // AVFORMAT_EVC_H > \ No newline at end of file fate-source is not happy about this: --- ./tests/ref/fate/source 2022-07-29 22:42:50.354493777 +0200 +++ tests/data/fate/source 2022-08-11 22:54:59.715488573 +0200 @@ -21,6 +21,7 @@ compat/djgpp/math.h compat/float/float.h compat/float/limits.h +libavformat/evc.h tools/decode_simple.h Use of av_clip() where av_clip_uintp2() could be used: Use of av_clip() where av_clip_intp2() could be used: Test source failed. Look at tests/data/fate/source.err for details. tests/Makefile:304: recipe for target 'fate-source' failed make: *** [fate-source] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope ___ 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".
