Re: [FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness
On 28-07-2018 03:33 AM, Tomas Härdin wrote: woot! I didn't know the mov demuxer dumped such things. It is quite slow however, since it will scan through every leaf atom in the file. For example, running time ffmpeg -i input.mov -v 56 2>&1 | wc on a 1.5 GiB MP4 on an SSD takes: Use the subfile protocol to forgo parsing the whole file, e.g. ffmpeg -i subfile,,start,0,end,1,,:in.mp4 -v 56 2>&1 | grep -e "type:'moov'" -e "type:'mdat'" | head -1 | grep moov This assumes that at least one of the two targeted boxes moov/mdat start within the first 1 bytes. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] cmdutils: print a more descriptive error message in show_help_bsf() when no bsf is specified
Signed-off-by: James Almer
---
fftools/cmdutils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index b8de319fe4..9cfbc45c2b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1956,7 +1956,10 @@ static void show_help_bsf(const char *name)
{
const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
-if (!bsf) {
+if (!name) {
+av_log(NULL, AV_LOG_ERROR, "No bitstream filter name specified.\n");
+return;
+} else if (!bsf) {
av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n", name);
return;
}
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
Fixes crashes like "ffmpeg -h bsf" caused by passing NULL to strcmp()
Signed-off-by: James Almer
---
libavcodec/bitstream_filters.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index c21373621c..3433921554 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -78,6 +78,9 @@ const AVBitStreamFilter *av_bsf_get_by_name(const char *name)
const AVBitStreamFilter *f = NULL;
void *i = 0;
+if (!name)
+return NULL;
+
while ((f = av_bsf_iterate())) {
if (!strcmp(f->name, name))
return f;
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: add AVS2 section
Signed-off-by: hwren --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 234b655..40186d1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -143,6 +143,7 @@ Codecs: asv* Michael Niedermayer atrac3plus* Maxim Poliakovski audiotoolbox* Rodger Combs + avs2* Huiwen Ren bgmc.c, bgmc.hThilo Borgmann binkaudio.c Peter Ross cavs* Stefan Gehrer @@ -189,6 +190,7 @@ Codecs: libcelt_dec.c Nicolas George libcodec2.c Tomas Härdin libdirac* David Conrad + libdavs2.cHuiwen Ren libgsm.c Michel Bardiaux libkvazaar.c Arttu Ylä-Outinen libopenjpeg.c Jaikrishnan Menon -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext
On 7/27/2018 10:58 PM, Michael Niedermayer wrote: > On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote: >> Certain AVCodecParameters, like the contents of the extradata, may be changed >> by the init() function of any of the bitstream filters in the chain. >> >> Signed-off-by: James Almer >> --- >> Now it's not going to be called after the codec has been opened. >> >> libavcodec/decode.c | 4 >> 1 file changed, 4 insertions(+) > > This breaks: > ffmpeg -i > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > -bitexact -pix_fmt rgba -f framecrc - Is any other decoder failing the same way? Because the apng decoder threading code may be faulty otherwise. Plenty of avctx fields are changed after ff_thread_init() is called within avcodec_open2(). There should not be a race at this point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext
On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote: > Certain AVCodecParameters, like the contents of the extradata, may be changed > by the init() function of any of the bitstream filters in the chain. > > Signed-off-by: James Almer > --- > Now it's not going to be called after the codec has been opened. > > libavcodec/decode.c | 4 > 1 file changed, 4 insertions(+) This breaks: ffmpeg -i https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png -bitexact -pix_fmt rgba -f framecrc - libavutil 56. 18.102 / 56. 18.102 libavcodec 58. 22.100 / 58. 22.100 libavformat58. 17.101 / 58. 17.101 libavdevice58. 4.101 / 58. 4.101 libavfilter 7. 26.100 / 7. 26.100 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100 libpostproc55. 2.100 / 55. 2.100 ==7203== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==7203==at 0xF5667D9: sendmmsg (sendmmsg.c:32) ==7203==by 0x1FF88AB0: __libc_res_nsend (res_send.c:1279) ==7203==by 0x1FF85E2B: __libc_res_nquery (res_query.c:227) ==7203==by 0x1FF86862: __libc_res_nsearch (res_query.c:591) ==7203==by 0x25B07C72: _nss_dns_gethostbyname4_r (dns-host.c:315) ==7203==by 0xF537665: gaih_inet (getaddrinfo.c:858) ==7203==by 0xF53A96C: getaddrinfo (getaddrinfo.c:2414) ==7203==by 0x783CAC: tcp_open (in ffmpeg/ffmpeg_g) ==7203==by 0x6710D5: ffurl_connect (in ffmpeg/ffmpeg_g) ==7203==by 0x6717CC: ffurl_open_whitelist (in ffmpeg/ffmpeg_g) ==7203==by 0x7D8C23: ff_tls_open_underlying (in ffmpeg/ffmpeg_g) ==7203==by 0x786BBA: tls_open (in ffmpeg/ffmpeg_g) ==7203==by 0x670FBE: ffurl_connect (in ffmpeg/ffmpeg_g) ==7203==by 0x6717CC: ffurl_open_whitelist (in ffmpeg/ffmpeg_g) ==7203==by 0x6B85AC: http_open_cnx_internal (in ffmpeg/ffmpeg_g) ==7203==by 0x6B87FA: http_open_cnx (in ffmpeg/ffmpeg_g) ==7203==by 0x6B9A18: http_open (in ffmpeg/ffmpeg_g) ==7203==by 0x670FBE: ffurl_connect (in ffmpeg/ffmpeg_g) ==7203==by 0x6717CC: ffurl_open_whitelist (in ffmpeg/ffmpeg_g) ==7203==by 0x67AF2F: ffio_open_whitelist (in ffmpeg/ffmpeg_g) ==7203== Address 0x7feff7ff0 is on thread 1's stack ==7203== Uninitialised value was created by a stack allocation ==7203==at 0x1FF87E6D: __libc_res_nsend (res_send.c:364) ==7203== Input #0, apng, from 'https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png': Duration: N/A, bitrate: N/A Stream #0:0: Video: apng, rgba(pc), 100x100, 13.33 fps, 13.33 tbr, 100k tbn, 100k tbc Stream mapping: Stream #0:0 -> #0:0 (apng (native) -> rawvideo (native)) Press [q] to stop, [?] for help ==7203== Thread 2: ==7203== Invalid read of size 4 ==7203==at 0xA43816: decode_frame_common.isra.9 (in ffmpeg/ffmpeg_g) ==7203==by 0xA46C37: decode_frame_apng (in ffmpeg/ffmpeg_g) ==7203==by 0xA544B0: frame_worker_thread (in ffmpeg/ffmpeg_g) ==7203==by 0xB8A2183: start_thread (pthread_create.c:312) ==7203==by 0xF56503C: clone (clone.S:111) ==7203== Address 0x256136c0 is 0 bytes inside a block of size 109 free'd ==7203==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==7203==by 0xB3362F: avcodec_parameters_to_context (in ffmpeg/ffmpeg_g) ==7203==by 0x829EC8: ff_decode_bsfs_init (in ffmpeg/ffmpeg_g) ==7203==by 0xB3044A: avcodec_open2 (in ffmpeg/ffmpeg_g) ==7203==by 0x4CA18C: transcode_init (in ffmpeg/ffmpeg_g) ==7203==by 0x4CC6F8: transcode (in ffmpeg/ffmpeg_g) ==7203==by 0x4AACDC: main (in ffmpeg/ffmpeg_g) ==7203== ==7203== Invalid read of size 4 ==7203==at 0xA4384A: decode_frame_common.isra.9 (in ffmpeg/ffmpeg_g) ==7203==by 0xA46C37: decode_frame_apng (in ffmpeg/ffmpeg_g) ==7203==by 0xA544B0: frame_worker_thread (in ffmpeg/ffmpeg_g) ==7203==by 0xB8A2183: start_thread (pthread_create.c:312) ==7203==by 0xF56503C: clone (clone.S:111) ==7203== Address 0x256136c4 is 4 bytes inside a block of size 109 free'd ==7203==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==7203==by 0xB3362F: avcodec_parameters_to_context (in ffmpeg/ffmpeg_g) ==7203==by 0x829EC8: ff_decode_bsfs_init (in ffmpeg/ffmpeg_g) ==7203==by 0xB3044A: avcodec_open2 (in ffmpeg/ffmpeg_g) ==7203==by 0x4CA18C: transcode_init (in ffmpeg/ffmpeg_g) ==7203==by 0x4CC6F8: transcode (in ffmpeg/ffmpeg_g) ==7203==by 0x4AACDC: main (in ffmpeg/ffmpeg_g) ==7203== ==7203== Invalid read of size 4 ==7203==at 0xA44E8E: decode_frame_common.isra.9 (in ffmpeg/ffmpeg_g) ==7203==by 0xA46C37: decode_frame_apng (in ffmpeg/ffmpeg_g) ==7203==by 0xA544B0: frame_worker_thread (in ffmpeg/ffmpeg_g) ==7203==by 0xB8A2183: start_thread (pthread_create.c:312) ==7203==by 0xF56503C: clone (clone.S:111) ==7203== Address 0x256136c8 is 8 bytes inside a block of size 109 free'd ==7203==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==7203==by 0xB3362F: avcodec_parameters_to_context (in
Re: [FFmpeg-devel] [GSOC] [PATCH] On the fly generation of default DNN models and code style fixes
On Fri, Jul 27, 2018 at 08:06:15PM +0300, Sergey Lavrushkin wrote:
> Hello,
>
> The first patch provides on the fly generation of default DNN models,
> that eliminates data duplication for model weights. Also, files with
> internal weights
> were replaced with automatically generated one for models I trained.
> Scripts for training and generating these files can be found here:
> https://github.com/HighVoltageRocknRoll/sr
> Later, I will add a description to this repo on how to use it and benchmark
> results for trained models.
>
> The second patch fixes some code style issues for pointers in DNN module
> and sr filter. Are there any other code style fixes I should make for this
> code?
It seems the code with these patches produces some warnings:
In file included from libavfilter/dnn_backend_native.c:27:0:
libavfilter/dnn_srcnn.h:2113:21: warning: ‘srcnn_consts’ defined but not used
[-Wunused-variable]
static const float *srcnn_consts[] = {
^
libavfilter/dnn_srcnn.h:2122:24: warning: ‘srcnn_consts_dims’ defined but not
used [-Wunused-variable]
static const long int *srcnn_consts_dims[] = {
^
libavfilter/dnn_srcnn.h:2142:20: warning: ‘srcnn_activations’ defined but not
used [-Wunused-variable]
static const char *srcnn_activations[] = {
^
In file included from libavfilter/dnn_backend_native.c:28:0:
libavfilter/dnn_espcn.h:5401:21: warning: ‘espcn_consts’ defined but not used
[-Wunused-variable]
static const float *espcn_consts[] = {
^
libavfilter/dnn_espcn.h:5410:24: warning: ‘espcn_consts_dims’ defined but not
used [-Wunused-variable]
static const long int *espcn_consts_dims[] = {
^
libavfilter/dnn_espcn.h:5432:20: warning: ‘espcn_activations’ defined but not
used [-Wunused-variable]
static const char *espcn_activations[] = {
^
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add YUV-based floating-point pixel formats.
On Sat, Sep 02, 2017 at 09:22:17AM +, Andrew Sun wrote: > This commit adds support for 32-bpc YUV-based floating-point pixel formats. > --- > doc/APIchanges | 2 ++ > libavutil/pixdesc.c | 75 > + > libavutil/pixfmt.h | 11 > libavutil/version.h | 2 +- > 4 files changed, 89 insertions(+), 1 deletion(-) can you add support in libswscale too ? That way vf_scale and libavfilter will be able to automatically convert to and from it thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why does ffmpeg h264 decoder stop decoding when certain type of packets are coming in the input stream?
On Fri, Jul 27, 2018 at 05:27:44PM +0530, Naveed Basha wrote: > Hi All, > > I used av_read_frame to get the AVPacket from encoded h264 file. But when > this packet (00 00 01 05 94 5a 33 e7 4d 6b d7 ad 13 86 ff 47 83 93 31 f1 e3 > 0a) is in the input stream (h264 video) ffmpeg decoder stops decoding > frames for any subsequent AVPackets. But if I skip this packet to provide > to the decoder the next AVPackets decode just fine. > > Could you please help me to find what is wrong with this packet? Or what is > wrong with the ffmpeg decoder? > Thanks, > Naveed do you have some testcase for reproducing this ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add lumakey_opencl filter
On Fri, Jul 27, 2018 at 11:42:57AM -0300, James Almer wrote: > On 7/27/2018 7:22 AM, Danil Iashchenko wrote: > > Add lumakey_opencl filter. Behaves like existing lumakey filter. > > > > --- > > > > On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote: > >>> On 7/25/2018 9:13 AM, Danil Iashchenko wrote: > Add lumakey_opencl filter. Behaves like existing lumakey filter. > >>> > >>> Isn't it possible to keep each of these new OpenCL filters as an > >>> optional codepath within the C version, using an AVOption like "opencl" > >>> or "hwaccel" to toggle one or another? Or maybe autodetected depending > >>> on the filter chain and/or input pix_fmt? > >>> > >>> I'm asking because it's getting too crowded. We also have some vaapi and > >>> qsv duplicate filters, and once we start committing filters using the > >>> upcoming Vulkan hwcontext the same way, we may also end up introducing > >>> yet another hardware specific variant for each of these. > >>> > > > >>> In libavcodec the hwaccels are seamlessly integrated into supported > >>> decoders. This has been favored over separate full stream hardware > >>> decoders where possible for the above reasons. It would be ideal to > >>> achieve the same with libavfilter. > > > >> i am in favor of this design as well. The user should not need to have > >> to know about and manage manually GPU optimizations. > > > >> thx > > > > Hi! I am GSoC student and I still have some tasks before the program ends. > > Also my mentor said: > > IMO don't think about it now, there isn't that much time left. > > I looked at doing last year (when converting to the current > > structure) and concluded that it's not really sane to do. > > The _opencl versions of filters operate completely differently, so > > while some code for setup can be shared putting them in the same filter > > doesn't really make sense. > > > > Thanks, Danil. > > Fair enough, i wasn't aware this was for GSoC, and this kind of change > (assuming it's doable) would definitely take a while, so it can wait. +1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/librtmp: fix returning EOF from Read/Write
applied smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add YUV-based floating-point pixel formats.
This commit adds support for 32-bpc YUV-based floating-point pixel formats.
---
doc/APIchanges | 2 ++
libavutil/pixdesc.c | 75 +
libavutil/pixfmt.h | 11
libavutil/version.h | 2 +-
4 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4effbf9364..980b6e01bf 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,8 @@ libavutil: 2015-08-28
API changes, most recent first:
+2017-09-01 - xxx - lavu 57.82.100 - pixfmt.h
+ Add YUV-based floating-point pixel formats.
2017-09-01 - xxx - lavf 57.81.100 - avio.h
Add avio_read_partial().
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index d45eae5772..d954866470 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2237,6 +2237,81 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA |
AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_FLOAT,
},
+[AV_PIX_FMT_YUV420PF32BE] = {
+.name = "yuv420pf32be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
+ AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV420PF32LE] = {
+.name = "yuv420pf32le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV422PF32BE] = {
+.name = "yuv422pf32be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
+ AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV422PF32LE] = {
+.name = "yuv422pf32le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV444PF32BE] = {
+.name = "yuv444pf32be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
+ AV_PIX_FMT_FLAG_FLOAT,
+},
+[AV_PIX_FMT_YUV444PF32LE] = {
+.name = "yuv444pf32le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },/* R */
+{ 1, 4, 0, 0, 32, 3, 31, 1 },/* G */
+{ 2, 4, 0, 0, 32, 3, 31, 1 },/* B */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_FLOAT,
+},
};
#if FF_API_PLUS1_MINUS1
FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 6dd094376f..3863e1c9a9 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -334,6 +334,13 @@ enum AVPixelFormat {
AV_PIX_FMT_GBRAPF32BE, ///< IEEE-754 single precision planar GBRA 4:4:4:4,
128bpp, big-endian
AV_PIX_FMT_GBRAPF32LE, ///< IEEE-754 single precision planar GBRA 4:4:4:4,
128bpp, little-endian
+AV_PIX_FMT_YUV420PF32BE, ///< IEEE-754 single precision planar YUV 4:2:0
(1 Cr & Cb sample per 2x2 Y samples), 48bpp, big-endian
+AV_PIX_FMT_YUV420PF32LE, ///< IEEE-754 single precision planar YUV 4:2:0
(1 Cr & Cb sample per 2x2 Y samples), 48bpp, little-endian
+AV_PIX_FMT_YUV422PF32BE, ///< IEEE-754 single precision planar YUV 4:2:2
(1 Cr & Cb sample per 2x1 Y samples), 64bpp, big-endian
+AV_PIX_FMT_YUV422PF32LE, ///< IEEE-754 single precision planar YUV 4:2:2
(1 Cr & Cb sample per 2x1 Y samples), 64bpp, little-endian
+AV_PIX_FMT_YUV444PF32BE, ///< IEEE-754 single precision planar YUV 4:4:4
(1 Cr & Cb sample per 1x1 Y samples), 96bpp, big-endian
+AV_PIX_FMT_YUV444PF32LE, ///< IEEE-754 single precision planar YUV 4:4:4
Re: [FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness
fre 2018-07-27 klockan 19:54 +0530 skrev Gyan Doshi: > > On 27-07-2018 07:36 PM, Tomas Härdin wrote: > > > This is something the PeerTube guys need, and this seemed a > > straightforward enough approach. Feedback appreciated > > Not a patch review, just a note that one can do this with > ffmpeg/ffprobe > and basic *nix tools. > > To check for moof, > > ffmpeg -i in.mp4 -v 56 2>&1 | grep -e type:'moof' > > To see if moov precedes mdat > > ffmpeg -i in.mp4 -v 56 2>&1 | grep -e "type:'moov'" -e > "type:'mdat'" | head -1 | grep moov woot! I didn't know the mov demuxer dumped such things. It is quite slow however, since it will scan through every leaf atom in the file. For example, running time ffmpeg -i input.mov -v 56 2>&1 | wc on a 1.5 GiB MP4 on an SSD takes: real0m4,740s user0m6,708s sys 0m2,356s While using the patched qt-faststart: real0m0,002s user0m0,000s sys 0m0,000s /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/dump_extradata_bsf: don't allocate a new AVPacket per filtered packet
On Wed, Jul 25, 2018 at 10:11:47PM -0300, James Almer wrote: > ~4x speedup in dump_extradata() > > Signed-off-by: James Almer > --- > libavcodec/dump_extradata_bsf.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) should be ok and nice speedup thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/audiogen: raise channel count limit to 12
On Thu, Jul 26, 2018 at 09:13:41AM +0200, Tobias Rapp wrote: > Signed-off-by: Tobias Rapp > --- > tests/audiogen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/audiogen.c b/tests/audiogen.c > index 8d596b5..c43bb70 100644 > --- a/tests/audiogen.c > +++ b/tests/audiogen.c > @@ -26,7 +26,7 @@ > #include > #include > > -#define MAX_CHANNELS 8 > +#define MAX_CHANNELS 12 LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libopusenc: allow encoding channel mapping 2
---
libavcodec/libopusenc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 4ae81b0bb2..6b450ec317 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -27,6 +27,7 @@
#include "bytestream.h"
#include "internal.h"
#include "libopus.h"
+#include "mathops.h"
#include "vorbis.h"
#include "audio_frame_queue.h"
@@ -200,6 +201,21 @@ static int libopus_check_vorbis_layout(AVCodecContext
*avctx, int mapping_family
return 0;
}
+static int libopus_check_ambisonics_channels(AVCodecContext *avctx) {
+int channels = avctx->channels;
+int ambisonic_order = ff_sqrt(channels) - 1;
+if (channels != ((ambisonic_order + 1) * (ambisonic_order + 1)) &&
+channels != ((ambisonic_order + 1) * (ambisonic_order + 1) + 2)) {
+av_log(avctx, AV_LOG_ERROR,
+ "Ambisonics coding is only specified for channel counts"
+ " which can be written as (n + 1)^2 or (n + 1)^2 + 2"
+ " for nonnegative integer n\n");
+return AVERROR_INVALIDDATA;
+}
+
+return 0;
+}
+
static int libopus_validate_layout_and_get_channel_map(
AVCodecContext *avctx,
int mapping_family,
@@ -231,6 +247,12 @@ static int libopus_validate_layout_and_get_channel_map(
channel_map = ff_vorbis_channel_layout_offsets[avctx->channels -
1];
}
break;
+case 2:
+ret = libopus_check_max_channels(avctx, 227);
+if (ret == 0) {
+ret = libopus_check_ambisonics_channels(avctx);
+}
+break;
case 255:
ret = libopus_check_max_channels(avctx, 254);
break;
--
2.18.0.345.g5c9ce644c3-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/encode: fix frame_number double-counted
On Thu, Jul 26, 2018 at 03:51:07PM +0800, Zhong Li wrote: > Encoder frame_number may be double-counted if some frames are cached and then > flushed. > Take qsv encoder (some frames are cached firsty for asynchronism) as example, > ./ffmpeg -loglevel verbose -hwaccel qsv -c:v h264_qsv -i in.mp4 -vframes 100 > -c:v h264_qsv out.mp4 > frame_number passed to encoder is double-counted and larger than the accurate > value. > Libx264 encoding with B frames can also reproduce it. > > Signed-off-by: Zhong Li > --- > libavcodec/encode.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hi, On Fri, Jul 27, 2018 at 10:59 AM, Pedro Arthur wrote: > 2018-07-27 11:31 GMT-03:00 Ronald S. Bultje : > > Hi, > > > > On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur > wrote: > > > >> Hi, > >> > >> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje : > >> > > >> > NN is different. The exposed software *uses* but does not *generate* > the > >> > coefficients. In fact, the meaning of most coefficients is completely > >> > opaque. They are just multiplier and addition constants with no > obvious > >> > relationship to reality, other than that they were generated by some > >> > magical process that tells us that statistically (??), this bears > >> > resemblence to some trained form of reality. You want to adjust > behaviour > >> > for a defined different outcome? You'll have to retrain. That's all > fine, > >> > don't get me wrong, but we need to know how to retrain since it's not > >> > obvious to us. Just tell us what process and what data were used to > get > >> the > >> > outcome so that we can get a different outcome if we so choose (that > *is* > >> > freedom to modify)? > >> > > >> > Please document (and make available) all such information for the > >> > re-training. > >> We already did it [1] the repo provides all scripts to download the > >> data and run the training and also generates the header with weights > >> readily to use in ffmpeg. > >> When Jean-Baptist raised this issue we worked to provide all the > >> necessary scripts to perform training, reading the replies above, it > >> seems no one is aware of it (not even J-B). > >> Isn't [1] enough? whats is missing then? why no one asked for whatever > >> may be missing in the original email when we provided the link to the > >> repo? > >> > >> > >> [1] - https://github.com/HighVoltageRocknRoll/sr > > > > > > It's probably because the documentation is not in FFmpeg, so how could we > > be aware of it? > > > > $ git grep -i rocknroll . > > $ pwd > > /Users/ronaldbultje/Projects/ffmpeg > > $ git log --oneline -1 > > 536bcc3 avcodec: add missing files missed in previous commits > > > > It sounds to me like we agree that documentation for re-training should > be > > provided, and the miscommunication was more about where this should be > > and/or how to make it discoverable. I would encourage you to make it as > > discoverable as possible by including the documentation inside the FFmpeg > > source tree, possibly inside the filter's source code file. > > > > (I understand that it may not be practical for the actual retraining data > > and scripts to be hosted on videolan/FFmpeg infrastructure.) > A small description with a link for the repo in the header with the > weights is enough? If it answers the questions (after the obvious "hey, that looks cool, let me dig deeper") "what on earth is this" and/or "how can I do that myself?", then maybe, yes? It might also be useful to briefly refer to (or repeat) the same in public documentation, e.g. in filters.texi, so that users who start reading about nn filters and want to pass their own coefficients can read easily how to generate them. Freedoms aren't just intended for developers, they're also meant for users. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 27 July 2018 at 18:12, Rostislav Pehlivanov wrote: > > And the coding style is just the tip, there are dozens of things I > disagree with, such as the custom float to 8 bit conversions, when filters > already exist which take in floats (zscale). > I should probably expand on what I mean by the custom float conversion: make the filter accept a float pixel format, such as AV_PIX_FMT_GBRPF32. We have one, we use it in vf_tonemap and vf_zscale. Users will need to specify a filter to convert to float first, which will match what they have to do for vf_zscale and vf_tonemap. If you need to process YUV then add a float YUV format, but please, don't do custom conversions in filters. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 27 July 2018 at 17:48, Pedro Arthur wrote: > 2018-07-27 12:07 GMT-03:00 Rostislav Pehlivanov : > > On 27 July 2018 at 15:11, James Almer wrote: > > > >> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote: > >> > Reference - IRC and j-b's earlier email. > >> > Coding style issues: > >> > DNNModel* ff_dnn_load_model_native(const char* model_filename) > >> > > >> > We never ever do stupid things like put the asterix first. The author > of > >> > the patch should have known better and the patch should have been > >> checked. > >> > Even a glance could have told you its wrong. > >> > >> Tone it down. It's a style issue. New contributors don't always know > >> things like that and we always tell them to fix it. It's the reviewer > >> who should have pointed it out, and if they missed it then it's > >> harmless. It's not like he used a public suffix like av_, where it can > >> be a problem. > >> > > > > It shows the code wasn't reviewed properly. These style issues are > > propagated throughout all the DNN framework, which was many thousands of > > lines of code and shows that not even a glimpse was spent on the actual > > code. We don't commit such huge patches without at least some form of > > review, even if months have passed and no one has bothered to yet. > The style issue is my fault, I did not ensure the student were aware > of the coding style. > That does not mean that other aspects of the code were not properly > reviewed, I spent a good amount of time reviewing and testing the > code. > The code style issue is easily fixable, the student will already > provide a fix, but if it is too much urgent I could fix it myself in a > few minutes. > Doesn't matter how easy it is to fix, its too late, the code landed, you pushed it and you didn't even bother to look at it. This is unacceptable, especially for such a big patchset, and unfair to the rest of developers. Ping the patchset, and keep pinging it until someone reviews it. Don't make it your authority to do so especially as its new code for which no maintainers exist. And the coding style is just the tip, there are dozens of things I disagree with, such as the custom float to 8 bit conversions, when filters already exist which take in floats (zscale). I don't see how reverting the code and asking for "proper" review, > which no one (in almost 3 months) besides me did, will do any good. > After reverting will you be compromised (or anyone else) to review it? > or the code will get forgotten waiting for review until no one cares > about it? > Yes, I'll review it myself. It is not fair to propose a patch, and push it within 24h, reverting > the student work of almost 3 months where no one has complained before > of issues to be fixed. > What isn't fair is that this literal unreviewed code dump is sitting in our repository at all, without review from any developer, but only with the reassurance that it compiles and that it mostly does the things it should. I don't want to keep pointing out issues upon issues with code in our repository, a nice clean start is what's needed, which means like I said a temporary revert. I'd rather have that than a tens of patches needed to actually fix the whole thing, when a few well formatted emails would suffice. The code style issue will be addressed. > We already provide a repo with training scripts, and it will be > referenced in the code. > > Objectively, what else needs to be fixed? let me know and give the > student at least a few days so he can provide a fix. Remove the internal tables. All of them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 7/27/2018 12:07 PM, Rostislav Pehlivanov wrote: > On 27 July 2018 at 15:11, James Almer wrote: > >> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote: >>> Reference - IRC and j-b's earlier email. >>> Coding style issues: >>> DNNModel* ff_dnn_load_model_native(const char* model_filename) >>> >>> We never ever do stupid things like put the asterix first. The author of >>> the patch should have known better and the patch should have been >> checked. >>> Even a glance could have told you its wrong. >> >> Tone it down. It's a style issue. New contributors don't always know >> things like that and we always tell them to fix it. It's the reviewer >> who should have pointed it out, and if they missed it then it's >> harmless. It's not like he used a public suffix like av_, where it can >> be a problem. >> > > It shows the code wasn't reviewed properly. These style issues are > propagated throughout all the DNN framework, which was many thousands of > lines of code and shows that not even a glimpse was spent on the actual > code. We don't commit such huge patches without at least some form of > review, even if months have passed and no one has bothered to yet. > > > >> >>> I described them in the sentence above. >>> But I'm not willing to wait for a potential fix, and especially not for a >>> whole bunch of them rewriting everything. The whole code needs to be >> thrown >>> out and thoroughly reviewed properly, by at least yourself and one other >>> person, preferably before gsoc ends. >>> You should start coordinating with your student on how to fix everything >>> mentioned and then resend the patchsets once fixed. I'll apply the revert >>> patch tomorrow. >> >> No, you wont. Not until this has been discussed. > > > Yes I will, unless someone objects I still intend to. No one has yet. I just objected, and Ronald is trying to find a way to solve this without getting to the point of reverting. You'll not apply this patch until there's a consensus, and much less after a day just because you don't like it. This is a collaborative project, and revert wars are not welcome. > > > I don't know what got >> to you but you're acting like someone pushed code that would get a cop >> on your doorstep. Calm down for once in your life, you're seemingly >> angry in every other email you write, and you're not helping making this >> project a friendly place at all for new and old contributors alike. >> > > I didn't intend to sound such but nevertheless the facts I mentioned > remain, and I can't really think of a way to present them better. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
2018-07-27 12:07 GMT-03:00 Rostislav Pehlivanov : > On 27 July 2018 at 15:11, James Almer wrote: > >> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote: >> > Reference - IRC and j-b's earlier email. >> > Coding style issues: >> > DNNModel* ff_dnn_load_model_native(const char* model_filename) >> > >> > We never ever do stupid things like put the asterix first. The author of >> > the patch should have known better and the patch should have been >> checked. >> > Even a glance could have told you its wrong. >> >> Tone it down. It's a style issue. New contributors don't always know >> things like that and we always tell them to fix it. It's the reviewer >> who should have pointed it out, and if they missed it then it's >> harmless. It's not like he used a public suffix like av_, where it can >> be a problem. >> > > It shows the code wasn't reviewed properly. These style issues are > propagated throughout all the DNN framework, which was many thousands of > lines of code and shows that not even a glimpse was spent on the actual > code. We don't commit such huge patches without at least some form of > review, even if months have passed and no one has bothered to yet. The style issue is my fault, I did not ensure the student were aware of the coding style. That does not mean that other aspects of the code were not properly reviewed, I spent a good amount of time reviewing and testing the code. The code style issue is easily fixable, the student will already provide a fix, but if it is too much urgent I could fix it myself in a few minutes. I don't see how reverting the code and asking for "proper" review, which no one (in almost 3 months) besides me did, will do any good. After reverting will you be compromised (or anyone else) to review it? or the code will get forgotten waiting for review until no one cares about it? It is not fair to propose a patch, and push it within 24h, reverting the student work of almost 3 months where no one has complained before of issues to be fixed. The code style issue will be addressed. We already provide a repo with training scripts, and it will be referenced in the code. Objectively, what else needs to be fixed? let me know and give the student at least a few days so he can provide a fix. > > > >> >> > I described them in the sentence above. >> > But I'm not willing to wait for a potential fix, and especially not for a >> > whole bunch of them rewriting everything. The whole code needs to be >> thrown >> > out and thoroughly reviewed properly, by at least yourself and one other >> > person, preferably before gsoc ends. >> > You should start coordinating with your student on how to fix everything >> > mentioned and then resend the patchsets once fixed. I'll apply the revert >> > patch tomorrow. >> >> No, you wont. Not until this has been discussed. > > > Yes I will, unless someone objects I still intend to. No one has yet. > > > I don't know what got >> to you but you're acting like someone pushed code that would get a cop >> on your doorstep. Calm down for once in your life, you're seemingly >> angry in every other email you write, and you're not helping making this >> project a friendly place at all for new and old contributors alike. >> > > I didn't intend to sound such but nevertheless the facts I mentioned > remain, and I can't really think of a way to present them better. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: remove unnecessary reference file for fate-encryption-info
On 7/26/2018 12:38 AM, James Almer wrote: > Signed-off-by: James Almer > --- > tests/fate/libavutil.mak | 1 + > tests/ref/fate/encryption-info | 0 > 2 files changed, 1 insertion(+) > delete mode 100644 tests/ref/fate/encryption-info > > diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak > index a1d9313c3d..b12d15727b 100644 > --- a/tests/fate/libavutil.mak > +++ b/tests/fate/libavutil.mak > @@ -73,6 +73,7 @@ fate-dict: CMD = run libavutil/tests/dict > FATE_LIBAVUTIL += fate-encryption-info > fate-encryption-info: libavutil/tests/encryption_info$(EXESUF) > fate-encryption-info: CMD = run libavutil/tests/encryption_info > +fate-encryption-info: CMP = null > > FATE_LIBAVUTIL += fate-eval > fate-eval: libavutil/tests/eval$(EXESUF) > diff --git a/tests/ref/fate/encryption-info b/tests/ref/fate/encryption-info > deleted file mode 100644 > index e69de29bb2..00 Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 27 July 2018 at 15:11, James Almer wrote: > On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote: > > Reference - IRC and j-b's earlier email. > > Coding style issues: > > DNNModel* ff_dnn_load_model_native(const char* model_filename) > > > > We never ever do stupid things like put the asterix first. The author of > > the patch should have known better and the patch should have been > checked. > > Even a glance could have told you its wrong. > > Tone it down. It's a style issue. New contributors don't always know > things like that and we always tell them to fix it. It's the reviewer > who should have pointed it out, and if they missed it then it's > harmless. It's not like he used a public suffix like av_, where it can > be a problem. > It shows the code wasn't reviewed properly. These style issues are propagated throughout all the DNN framework, which was many thousands of lines of code and shows that not even a glimpse was spent on the actual code. We don't commit such huge patches without at least some form of review, even if months have passed and no one has bothered to yet. > > > I described them in the sentence above. > > But I'm not willing to wait for a potential fix, and especially not for a > > whole bunch of them rewriting everything. The whole code needs to be > thrown > > out and thoroughly reviewed properly, by at least yourself and one other > > person, preferably before gsoc ends. > > You should start coordinating with your student on how to fix everything > > mentioned and then resend the patchsets once fixed. I'll apply the revert > > patch tomorrow. > > No, you wont. Not until this has been discussed. Yes I will, unless someone objects I still intend to. No one has yet. I don't know what got > to you but you're acting like someone pushed code that would get a cop > on your doorstep. Calm down for once in your life, you're seemingly > angry in every other email you write, and you're not helping making this > project a friendly place at all for new and old contributors alike. > I didn't intend to sound such but nevertheless the facts I mentioned remain, and I can't really think of a way to present them better. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On Fri, 27 Jul 2018, at 16:59, Pedro Arthur wrote: > 2018-07-27 11:31 GMT-03:00 Ronald S. Bultje : > > Hi, > > > > On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote: > > > >> Hi, > >> > >> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje : > >> > > >> > NN is different. The exposed software *uses* but does not *generate* the > >> > coefficients. In fact, the meaning of most coefficients is completely > >> > opaque. They are just multiplier and addition constants with no obvious > >> > relationship to reality, other than that they were generated by some > >> > magical process that tells us that statistically (??), this bears > >> > resemblence to some trained form of reality. You want to adjust behaviour > >> > for a defined different outcome? You'll have to retrain. That's all fine, > >> > don't get me wrong, but we need to know how to retrain since it's not > >> > obvious to us. Just tell us what process and what data were used to get > >> the > >> > outcome so that we can get a different outcome if we so choose (that *is* > >> > freedom to modify)? > >> > > >> > Please document (and make available) all such information for the > >> > re-training. > >> We already did it [1] the repo provides all scripts to download the > >> data and run the training and also generates the header with weights > >> readily to use in ffmpeg. > >> When Jean-Baptist raised this issue we worked to provide all the > >> necessary scripts to perform training, reading the replies above, it > >> seems no one is aware of it (not even J-B). > >> Isn't [1] enough? whats is missing then? why no one asked for whatever > >> may be missing in the original email when we provided the link to the > >> repo? > >> > >> > >> [1] - https://github.com/HighVoltageRocknRoll/sr > > > > > > It's probably because the documentation is not in FFmpeg, so how could we > > be aware of it? > > > > $ git grep -i rocknroll . > > $ pwd > > /Users/ronaldbultje/Projects/ffmpeg > > $ git log --oneline -1 > > 536bcc3 avcodec: add missing files missed in previous commits > > > > It sounds to me like we agree that documentation for re-training should be > > provided, and the miscommunication was more about where this should be > > and/or how to make it discoverable. I would encourage you to make it as > > discoverable as possible by including the documentation inside the FFmpeg > > source tree, possibly inside the filter's source code file. > > > > (I understand that it may not be practical for the actual retraining data > > and scripts to be hosted on videolan/FFmpeg infrastructure.) > A small description with a link for the repo in the header with the > weights is enough? And the README is empty. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
2018-07-27 11:31 GMT-03:00 Ronald S. Bultje : > Hi, > > On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote: > >> Hi, >> >> 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje : >> > >> > NN is different. The exposed software *uses* but does not *generate* the >> > coefficients. In fact, the meaning of most coefficients is completely >> > opaque. They are just multiplier and addition constants with no obvious >> > relationship to reality, other than that they were generated by some >> > magical process that tells us that statistically (??), this bears >> > resemblence to some trained form of reality. You want to adjust behaviour >> > for a defined different outcome? You'll have to retrain. That's all fine, >> > don't get me wrong, but we need to know how to retrain since it's not >> > obvious to us. Just tell us what process and what data were used to get >> the >> > outcome so that we can get a different outcome if we so choose (that *is* >> > freedom to modify)? >> > >> > Please document (and make available) all such information for the >> > re-training. >> We already did it [1] the repo provides all scripts to download the >> data and run the training and also generates the header with weights >> readily to use in ffmpeg. >> When Jean-Baptist raised this issue we worked to provide all the >> necessary scripts to perform training, reading the replies above, it >> seems no one is aware of it (not even J-B). >> Isn't [1] enough? whats is missing then? why no one asked for whatever >> may be missing in the original email when we provided the link to the >> repo? >> >> >> [1] - https://github.com/HighVoltageRocknRoll/sr > > > It's probably because the documentation is not in FFmpeg, so how could we > be aware of it? > > $ git grep -i rocknroll . > $ pwd > /Users/ronaldbultje/Projects/ffmpeg > $ git log --oneline -1 > 536bcc3 avcodec: add missing files missed in previous commits > > It sounds to me like we agree that documentation for re-training should be > provided, and the miscommunication was more about where this should be > and/or how to make it discoverable. I would encourage you to make it as > discoverable as possible by including the documentation inside the FFmpeg > source tree, possibly inside the filter's source code file. > > (I understand that it may not be practical for the actual retraining data > and scripts to be hosted on videolan/FFmpeg infrastructure.) A small description with a link for the repo in the header with the weights is enough? > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/8] avcodec/vp9_superframe_bsf: implement a AVBSFContext.flush() callback
Signed-off-by: James Almer
---
libavcodec/vp9_superframe_bsf.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index 52569ab097..ea6750750b 100644
--- a/libavcodec/vp9_superframe_bsf.c
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -189,6 +189,17 @@ static int vp9_superframe_init(AVBSFContext *ctx)
return 0;
}
+static void vp9_superframe_flush(AVBSFContext *ctx)
+{
+VP9BSFContext *s = ctx->priv_data;
+int n;
+
+// unref cached data
+for (n = 0; n < s->n_cache; n++)
+av_packet_unref(s->cache[n]);
+s->n_cache = 0;
+}
+
static void vp9_superframe_close(AVBSFContext *ctx)
{
VP9BSFContext *s = ctx->priv_data;
@@ -208,6 +219,7 @@ const AVBitStreamFilter ff_vp9_superframe_bsf = {
.priv_data_size = sizeof(VP9BSFContext),
.filter = vp9_superframe_filter,
.init = vp9_superframe_init,
+.flush = vp9_superframe_flush,
.close = vp9_superframe_close,
.codec_ids = codec_ids,
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/8] avcodec/h264_redundant_pps_bsf: implement a AVBSFContext.flush() callback
Signed-off-by: James Almer
---
I'm not 100% sure this is correct. I also don't know if the CBS contexts need
to be fully reinitialized or not in this scenario. Because if so, then every
bsf using cbs will require a flush() callback as well.
libavcodec/h264_redundant_pps_bsf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/h264_redundant_pps_bsf.c
b/libavcodec/h264_redundant_pps_bsf.c
index 26baca84e3..cc5a3060f5 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -35,6 +35,7 @@ typedef struct H264RedundantPPSContext {
int global_pic_init_qp;
int current_pic_init_qp;
+int extradata_pic_init_qp;
} H264RedundantPPSContext;
@@ -145,6 +146,7 @@ static int h264_redundant_pps_init(AVBSFContext *bsf)
h264_redundant_pps_fixup_pps(ctx, au->units[i].content);
}
+ctx->extradata_pic_init_qp = ctx->current_pic_init_qp;
err = ff_cbs_write_extradata(ctx->output, bsf->par_out, au);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to write extradata.\n");
@@ -157,6 +159,12 @@ static int h264_redundant_pps_init(AVBSFContext *bsf)
return 0;
}
+static void h264_redundant_pps_flush(AVBSFContext *bsf)
+{
+H264RedundantPPSContext *ctx = bsf->priv_data;
+ctx->current_pic_init_qp = ctx->extradata_pic_init_qp;
+}
+
static void h264_redundant_pps_close(AVBSFContext *bsf)
{
H264RedundantPPSContext *ctx = bsf->priv_data;
@@ -172,6 +180,7 @@ const AVBitStreamFilter ff_h264_redundant_pps_bsf = {
.name = "h264_redundant_pps",
.priv_data_size = sizeof(H264RedundantPPSContext),
.init = _redundant_pps_init,
+.flush = _redundant_pps_flush,
.close = _redundant_pps_close,
.filter = _redundant_pps_filter,
.codec_ids = h264_redundant_pps_codec_ids,
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/8] avcodec/mpeg4_unpack_bframes_bsf: implement a AVBSFContext.flush() callback
Signed-off-by: James Almer
---
libavcodec/mpeg4_unpack_bframes_bsf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index c2b779a9d5..e9c535f390 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -166,6 +166,12 @@ static int mpeg4_unpack_bframes_init(AVBSFContext *ctx)
return 0;
}
+static void mpeg4_unpack_bframes_flush(AVBSFContext *bsfc)
+{
+UnpackBFramesBSFContext *ctx = bsfc->priv_data;
+av_packet_unref(ctx->b_frame);
+}
+
static void mpeg4_unpack_bframes_close(AVBSFContext *bsfc)
{
UnpackBFramesBSFContext *ctx = bsfc->priv_data;
@@ -181,6 +187,7 @@ const AVBitStreamFilter ff_mpeg4_unpack_bframes_bsf = {
.priv_data_size = sizeof(UnpackBFramesBSFContext),
.init = mpeg4_unpack_bframes_init,
.filter = mpeg4_unpack_bframes_filter,
+.flush = mpeg4_unpack_bframes_flush,
.close = mpeg4_unpack_bframes_close,
.codec_ids = codec_ids,
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 8/8] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext
Certain AVCodecParameters, like the contents of the extradata, may be changed by the init() function of any of the bitstream filters in the chain. Signed-off-by: James Almer --- Now it's not going to be called after the codec has been opened. libavcodec/decode.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/decode.c b/libavcodec/decode.c index 2e82f6b506..4607e9f318 100644 --- a/libavcodec/decode.c +++ b/libavcodec/decode.c @@ -281,6 +281,10 @@ int ff_decode_bsfs_init(AVCodecContext *avctx) bsfs_str++; } +ret = avcodec_parameters_to_context(avctx, s->bsfs[s->nb_bsfs - 1]->par_out); +if (ret < 0) +return ret; + return 0; fail: ff_decode_bsfs_uninit(avctx); -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/8] avcodec/decode: flush the internal bsfs instead of constantly reinitalizing them
Initialize the bsfs once when opening the codec and uninitialize them once when
closing it, instead of at every codec flush/seek.
Signed-off-by: James Almer
---
I think i didn't miss any bsf with internal state that needs a flush()
callback, but an extra pair of eyes (or more) to make sure would come in handy.
In any case, the only bsfs where this matters are those used during decoding,
which essentially means those autoinserted by decoders given that the ffmpeg
cli doesn't allow -bsf as an input option. But you can't know what an API user
may do, so better get them all right.
libavcodec/decode.c | 20 ++--
libavcodec/decode.h | 2 ++
libavcodec/utils.c | 5 +
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index db364ca700..2e82f6b506 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -182,7 +182,7 @@ static int unrefcount_frame(AVCodecInternal *avci, AVFrame
*frame)
return 0;
}
-static int bsfs_init(AVCodecContext *avctx)
+int ff_decode_bsfs_init(AVCodecContext *avctx)
{
AVCodecInternal *avci = avctx->internal;
DecodeFilterContext *s = >filter;
@@ -688,10 +688,6 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext
*avctx, const AVPacke
if (avpkt && !avpkt->size && avpkt->data)
return AVERROR(EINVAL);
-ret = bsfs_init(avctx);
-if (ret < 0)
-return ret;
-
av_packet_unref(avci->buffer_pkt);
if (avpkt && (avpkt->data || avpkt->side_data_elems)) {
ret = av_packet_ref(avci->buffer_pkt, avpkt);
@@ -751,10 +747,6 @@ int attribute_align_arg
avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr
if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec))
return AVERROR(EINVAL);
-ret = bsfs_init(avctx);
-if (ret < 0)
-return ret;
-
if (avci->buffer_frame->buf[0]) {
av_frame_move_ref(frame, avci->buffer_frame);
} else {
@@ -1978,6 +1970,14 @@ int ff_reget_buffer(AVCodecContext *avctx, AVFrame
*frame)
return ret;
}
+static void bsfs_flush(AVCodecContext *avctx)
+{
+DecodeFilterContext *s = >internal->filter;
+
+for (int i = 0; i < s->nb_bsfs; i++)
+av_bsf_flush(s->bsfs[i]);
+}
+
void avcodec_flush_buffers(AVCodecContext *avctx)
{
avctx->internal->draining = 0;
@@ -1998,7 +1998,7 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
avctx->pts_correction_last_pts =
avctx->pts_correction_last_dts = INT64_MIN;
-ff_decode_bsfs_uninit(avctx);
+bsfs_flush(avctx);
if (!avctx->refcounted_frames)
av_frame_unref(avctx->internal->to_free);
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 15271c529a..c3e0e82f4c 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -64,6 +64,8 @@ typedef struct FrameDecodeData {
*/
int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt);
+int ff_decode_bsfs_init(AVCodecContext *avctx);
+
void ff_decode_bsfs_uninit(AVCodecContext *avctx);
/**
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4f9a2b76ef..d95a4fe71c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -994,6 +994,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
avctx->time_base = av_inv_q(av_mul_q(avctx->framerate,
(AVRational){avctx->ticks_per_frame, 1}));
#endif
+
+ret = ff_decode_bsfs_init(avctx);
+if (ret < 0)
+goto free_and_end;
}
if (codec->priv_data_size > 0 && avctx->priv_data && codec->priv_class) {
av_assert0(*(const AVClass **)avctx->priv_data == codec->priv_class);
@@ -1032,6 +1036,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_packet_free(>internal->last_pkt_props);
av_packet_free(>internal->ds.in_pkt);
+ff_decode_bsfs_uninit(avctx);
av_freep(>internal->pool);
}
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/8] avcodec/h264_mp4toannexb_bsf: implement a AVBSFContext.flush() callback
Signed-off-by: James Almer
---
libavcodec/h264_mp4toannexb_bsf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 292d106433..a263df9948 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -279,6 +279,15 @@ fail:
return ret;
}
+static void h264_mp4toannexb_flush(AVBSFContext *ctx)
+{
+H264BSFContext *s = ctx->priv_data;
+
+s->idr_sps_seen = 0;
+s->idr_pps_seen = 0;
+s->new_idr = s->extradata_parsed;
+}
+
static const enum AVCodecID codec_ids[] = {
AV_CODEC_ID_H264, AV_CODEC_ID_NONE,
};
@@ -288,5 +297,6 @@ const AVBitStreamFilter ff_h264_mp4toannexb_bsf = {
.priv_data_size = sizeof(H264BSFContext),
.init = h264_mp4toannexb_init,
.filter = h264_mp4toannexb_filter,
+.flush = h264_mp4toannexb_flush,
.codec_ids = codec_ids,
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/8] avcodec/vp9_superframe_split_bsf: implement a AVBSFContext.flush() callback
Signed-off-by: James Almer
---
libavcodec/vp9_superframe_split_bsf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/vp9_superframe_split_bsf.c
b/libavcodec/vp9_superframe_split_bsf.c
index 9c4aa33dc1..77bfcb4cdf 100644
--- a/libavcodec/vp9_superframe_split_bsf.c
+++ b/libavcodec/vp9_superframe_split_bsf.c
@@ -132,6 +132,14 @@ fail:
return ret;
}
+static void vp9_superframe_split_flush(AVBSFContext *ctx)
+{
+VP9SFSplitContext *s = ctx->priv_data;
+
+av_packet_unref(>buffer_pkt);
+memset(s, 0, sizeof(*s));
+}
+
static void vp9_superframe_split_uninit(AVBSFContext *ctx)
{
VP9SFSplitContext *s = ctx->priv_data;
@@ -143,5 +151,6 @@ const AVBitStreamFilter ff_vp9_superframe_split_bsf = {
.priv_data_size = sizeof(VP9SFSplitContext),
.close = vp9_superframe_split_uninit,
.filter = vp9_superframe_split_filter,
+.flush = vp9_superframe_split_flush,
.codec_ids = (const enum AVCodecID []){ AV_CODEC_ID_VP9,
AV_CODEC_ID_NONE },
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/8] avcodec/bsf: add a flushing mechanism to AVBSFContext
Meant to reset the internal bsf state without the need to reinitialize it.
Signed-off-by: James Almer
---
Missing APIChanges entry and version bump.
libavcodec/avcodec.h | 6 ++
libavcodec/bsf.c | 10 ++
2 files changed, 16 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1266879206..56be65bd56 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5769,6 +5769,7 @@ typedef struct AVBitStreamFilter {
int (*init)(AVBSFContext *ctx);
int (*filter)(AVBSFContext *ctx, AVPacket *pkt);
void (*close)(AVBSFContext *ctx);
+void (*flush)(AVBSFContext *ctx);
} AVBitStreamFilter;
#if FF_API_OLD_BSF
@@ -5895,6 +5896,11 @@ int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);
*/
int av_bsf_receive_packet(AVBSFContext *ctx, AVPacket *pkt);
+/**
+ * Reset the internal bitstream filter state / flush internal buffers.
+ */
+void av_bsf_flush(AVBSFContext *ctx);
+
/**
* Free a bitstream filter context and everything associated with it; write
NULL
* into the supplied pointer.
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index bd611ea16b..03841da682 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -172,6 +172,16 @@ int av_bsf_init(AVBSFContext *ctx)
return 0;
}
+void av_bsf_flush(AVBSFContext *ctx)
+{
+ctx->internal->eof = 0;
+
+av_packet_unref(ctx->internal->buffer_pkt);
+
+if (ctx->filter->flush)
+ctx->filter->flush(ctx);
+}
+
int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt)
{
int ret;
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add lumakey_opencl filter
On 7/27/2018 7:22 AM, Danil Iashchenko wrote: > Add lumakey_opencl filter. Behaves like existing lumakey filter. > > --- > > On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote: >>> On 7/25/2018 9:13 AM, Danil Iashchenko wrote: Add lumakey_opencl filter. Behaves like existing lumakey filter. >>> >>> Isn't it possible to keep each of these new OpenCL filters as an >>> optional codepath within the C version, using an AVOption like "opencl" >>> or "hwaccel" to toggle one or another? Or maybe autodetected depending >>> on the filter chain and/or input pix_fmt? >>> >>> I'm asking because it's getting too crowded. We also have some vaapi and >>> qsv duplicate filters, and once we start committing filters using the >>> upcoming Vulkan hwcontext the same way, we may also end up introducing >>> yet another hardware specific variant for each of these. >>> > >>> In libavcodec the hwaccels are seamlessly integrated into supported >>> decoders. This has been favored over separate full stream hardware >>> decoders where possible for the above reasons. It would be ideal to >>> achieve the same with libavfilter. > >> i am in favor of this design as well. The user should not need to have >> to know about and manage manually GPU optimizations. > >> thx > > Hi! I am GSoC student and I still have some tasks before the program ends. > Also my mentor said: > IMO don't think about it now, there isn't that much time left. > I looked at doing last year (when converting to the current > structure) and concluded that it's not really sane to do. > The _opencl versions of filters operate completely differently, so > while some code for setup can be shared putting them in the same filter > doesn't really make sense. > > Thanks, Danil. Fair enough, i wasn't aware this was for GSoC, and this kind of change (assuming it's doable) would definitely take a while, so it can wait. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hi, On Fri, Jul 27, 2018 at 10:16 AM, Pedro Arthur wrote: > Hi, > > 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje : > > > > NN is different. The exposed software *uses* but does not *generate* the > > coefficients. In fact, the meaning of most coefficients is completely > > opaque. They are just multiplier and addition constants with no obvious > > relationship to reality, other than that they were generated by some > > magical process that tells us that statistically (??), this bears > > resemblence to some trained form of reality. You want to adjust behaviour > > for a defined different outcome? You'll have to retrain. That's all fine, > > don't get me wrong, but we need to know how to retrain since it's not > > obvious to us. Just tell us what process and what data were used to get > the > > outcome so that we can get a different outcome if we so choose (that *is* > > freedom to modify)? > > > > Please document (and make available) all such information for the > > re-training. > We already did it [1] the repo provides all scripts to download the > data and run the training and also generates the header with weights > readily to use in ffmpeg. > When Jean-Baptist raised this issue we worked to provide all the > necessary scripts to perform training, reading the replies above, it > seems no one is aware of it (not even J-B). > Isn't [1] enough? whats is missing then? why no one asked for whatever > may be missing in the original email when we provided the link to the > repo? > > > [1] - https://github.com/HighVoltageRocknRoll/sr It's probably because the documentation is not in FFmpeg, so how could we be aware of it? $ git grep -i rocknroll . $ pwd /Users/ronaldbultje/Projects/ffmpeg $ git log --oneline -1 536bcc3 avcodec: add missing files missed in previous commits It sounds to me like we agree that documentation for re-training should be provided, and the miscommunication was more about where this should be and/or how to make it discoverable. I would encourage you to make it as discoverable as possible by including the documentation inside the FFmpeg source tree, possibly inside the filter's source code file. (I understand that it may not be practical for the actual retraining data and scripts to be hosted on videolan/FFmpeg infrastructure.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
> On Jul 27, 2018, at 22:20, James Almer wrote: > > On 7/27/2018 10:43 AM, James Almer wrote: >> On 7/27/2018 9:10 AM, Liu Steven wrote: >>> >>> 在 2018年7月20日，上午10:58，Steven Liu 写道： hwren 于2018年7月19日周四 上午10:38写道： > > Ping, any comments for following patches? will push after one week if there have no objections. >>> pushed. >> >> You forgot to include avs2_parser.o and libdavs2.o in two of your >> commits. Please do it soon as compilation is currently broken. > > Just added them myself. Please make sure to first test compilation and > run fate every time you push patches. OK, i got it Thanks James Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness
On 27-07-2018 07:36 PM, Tomas Härdin wrote: This is something the PeerTube guys need, and this seemed a straightforward enough approach. Feedback appreciated Not a patch review, just a note that one can do this with ffmpeg/ffprobe and basic *nix tools. To check for moof, ffmpeg -i in.mp4 -v 56 2>&1 | grep -e type:'moof' To see if moov precedes mdat ffmpeg -i in.mp4 -v 56 2>&1 | grep -e "type:'moov'" -e "type:'mdat'" | head -1 | grep moov Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions
On Fri, Jul 27, 2018 at 4:03 PM, James Darnley wrote: > On 2018-07-27 15:05, Henrik Gramner wrote: >> Can't you just use 7 GPR:s on x86-32 as well? > > I'm sure I've done that in the past and at least 1 platform has always > complained due to PIE or stack alignment or whatever, I think. I went > looking for an old email but couldn't find it. > > If you want me to try it I can. If you're allocating stack space with a positive number there has to be a register available to store the old stack pointer in case the guaranteed stack alignment is smaller than the required stack alignment. This can be avoided by using a negative value for the stack space in case of high register pressure which will allocate space for the old stack pointer and store it on the stack after allocation/alignment. In functions that doesn't use the stack this is a non-issue. So it should be fine to use 7 registers here. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions
On 27 July 2018 at 12:47, James Darnley wrote: > On 2018-07-26 17:29, Rostislav Pehlivanov wrote: > > On 26 July 2018 at 12:28, James Darnley wrote: > > +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w > >> +DECLARE_REG_TMP 4,5 > >> + > >> +mova m2, [pd_1] > >> +mov r3d, wd > >> +and wd, ~(mmsize/4 - 1) > >> +shl wd, 2 > >> +add b0q, wq > >> +add b1q, wq > >> +neg wq > >> + > >> +ALIGN 16 > >> +.loop_simd: > >> +mova m0, [b0q + wq] > >> +mova m1, [b1q + wq] > >> +paddd m3, m1, m2 > >> +psrad m3, 1 > >> +psubd m0, m3 > >> +paddd m1, m0 > >> +mova [b0q + wq], m0 > >> +mova [b1q + wq], m1 > >> +add wq, mmsize > >> +jl .loop_simd > >> + > >> +and r3d, mmsize/4 - 1 > >> +jz .end > >> +.loop_scalar: > >> +mov t0d, [b0q] > >> +mov t1d, [b1q] > >> +mov r2d, t1d > >> +add r2d, 1 > >> +sar r2d, 1 > >> +sub t0d, r2d > >> +add t1d, t0d > >> +mov [b0q], t0d > >> +mov [b1q], t1d > >> + > >> +add b0q, 4 > >> +add b1q, 4 > >> +sub r3d, 1 > >> +jg .loop_scalar > >> + > >> +.end: > >> +RET > >> + > >> +%endmacro > >> + > >> +%macro HAAR_HORIZONTAL 0 > >> > > + > >> > > > > Could you remove this newline from every patch? All asm I've written and > > seen keep them without a newline. It made me think there's something in > the > > asm which checked the value of the macro, not that the entire function is > > macro'd. > > What? I don't understand what you mean. Do you think I have too many > blank lines between things? > Just remove the newline between the macro definition and the cglobal. > +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w, > >> x, b2 > >> +DECLARE_REG_TMP 2,5 > >> +%if ARCH_X86_64 > >> +%define tail r6d > >> +%else > >> +%define tail dword wm > >> +%endif > >> + > >> +mova m2, [pd_1] > >> +xor xd, xd > >> +shr wd, 1 > >> +mov tail, wd > >> +lea b2q, [bq + 4*wq] > >> + > >> +ALIGN 16 > >> +.loop_lo: > >> +mova m0, [bq + 4*xq] > >> +movu m1, [b2q + 4*xq] > >> +paddd m1, m2 > >> +psrad m1, 1 > >> +psubd m0, m1 > >> +mova [temp_q + 4*xq], m0 > >> +add xd, mmsize/4 > >> +cmp xd, wd > >> +jl .loop_lo > >> + > >> +xor xd, xd > >> +and wd, ~(mmsize/4 - 1) > >> + > >> +ALIGN 16 > >> +.loop_hi: > >> +mova m0, [temp_q + 4*xq] > >> +movu m1, [b2q+ 4*xq] > >> +paddd m1, m0 > >> +paddd m0, m2 > >> +paddd m1, m2 > >> +psrad m0, 1 > >> +psrad m1, 1 > >> +SBUTTERFLY dq, 0,1,3 > >> +%if cpuflag(avx2) > >> +SBUTTERFLY dqqq, 0,1,3 > >> +%endif > >> +mova [bq + 8*xq], m0 > >> +mova [bq + 8*xq + mmsize], m1 > >> +add xd, mmsize/4 > >> +cmp xd, wd > >> +jl .loop_hi > >> + > >> +and tail, mmsize/4 - 1 > >> +jz .end > >> +.loop_scalar: > >> +mov t0d, [temp_q + 4*xq] > >> +mov t1d, [b2q+ 4*xq] > >> +add t1d, t0d > >> +add t0d, 1 > >> +add t1d, 1 > >> +sar t0d, 1 > >> +sar t1d, 1 > >> +mov [bq + 8*xq], t0d > >> +mov [bq + 8*xq + 4], t1d > >> +add xq, 1 > >> +sub tail, 1 > >> +jg .loop_scalar > >> + > >> +.end: > >> +REP_RET > >> + > >> +%endmacro > >> + > >> +INIT_XMM sse2 > >> +HAAR_HORIZONTAL > >> +HAAR_VERTICAL > >> + > >> +INIT_XMM avx > >> +HAAR_HORIZONTAL > >> +HAAR_VERTICAL > >> > > > > You're not using any avx functions in that version, not unless a macro'd > > instruction inserts one for you. I think you should remove the avx > version > > then. > > Also since you always have a HAAR_HORIZONTAL and HAAR_VERTICAL macros per > > version you can just make a single macro to do both versions at the same > > time. > > Now that I think about it there will be only one 3-operand instruction > in the SBUTTERFLY and the vertical function also only has 1. I will > remove it. > > I can merge the two macros but I will look back at what I've done > previously. I think it is usually 1 macro per function. > > > + > >> +INIT_YMM avx2 > >> +HAAR_HORIZONTAL > >> +HAAR_VERTICAL > >> diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c > >> b/libavcodec/x86/dirac_dwt_init_10bit.c > >> new file mode 100644 > >> index 00..289862d728 > >> --- /dev/null > >> +++ b/libavcodec/x86/dirac_dwt_init_10bit.c > >> @@ -0,0 +1,76 @@ > >> +/* > >> + * x86 optimized discrete wavelet transform > >> + * Copyright (c) 2018 James Darnley > >> + * > >> + * 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 > >> + *
Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
On 7/27/2018 10:43 AM, James Almer wrote: > On 7/27/2018 9:10 AM, Liu Steven wrote: >> >> >>> 在 2018年7月20日，上午10:58，Steven Liu 写道： >>> >>> hwren 于2018年7月19日周四 上午10:38写道： Ping, any comments for following patches? >>> will push after one week if there have no objections. >> pushed. > > You forgot to include avs2_parser.o and libdavs2.o in two of your > commits. Please do it soon as compilation is currently broken. Just added them myself. Please make sure to first test compilation and run fate every time you push patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hi, 2018-07-27 8:12 GMT-03:00 Ronald S. Bultje : > > NN is different. The exposed software *uses* but does not *generate* the > coefficients. In fact, the meaning of most coefficients is completely > opaque. They are just multiplier and addition constants with no obvious > relationship to reality, other than that they were generated by some > magical process that tells us that statistically (??), this bears > resemblence to some trained form of reality. You want to adjust behaviour > for a defined different outcome? You'll have to retrain. That's all fine, > don't get me wrong, but we need to know how to retrain since it's not > obvious to us. Just tell us what process and what data were used to get the > outcome so that we can get a different outcome if we so choose (that *is* > freedom to modify)? > > Please document (and make available) all such information for the > re-training. We already did it [1] the repo provides all scripts to download the data and run the training and also generates the header with weights readily to use in ffmpeg. When Jean-Baptist raised this issue we worked to provide all the necessary scripts to perform training, reading the replies above, it seems no one is aware of it (not even J-B). Isn't [1] enough? whats is missing then? why no one asked for whatever may be missing in the original email when we provided the link to the repo? [1] - https://github.com/HighVoltageRocknRoll/sr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote: > Reference - IRC and j-b's earlier email. > Coding style issues: > DNNModel* ff_dnn_load_model_native(const char* model_filename) > > We never ever do stupid things like put the asterix first. The author of > the patch should have known better and the patch should have been checked. > Even a glance could have told you its wrong. Tone it down. It's a style issue. New contributors don't always know things like that and we always tell them to fix it. It's the reviewer who should have pointed it out, and if they missed it then it's harmless. It's not like he used a public suffix like av_, where it can be a problem. > I described them in the sentence above. > But I'm not willing to wait for a potential fix, and especially not for a > whole bunch of them rewriting everything. The whole code needs to be thrown > out and thoroughly reviewed properly, by at least yourself and one other > person, preferably before gsoc ends. > You should start coordinating with your student on how to fix everything > mentioned and then resend the patchsets once fixed. I'll apply the revert > patch tomorrow. No, you wont. Not until this has been discussed. I don't know what got to you but you're acting like someone pushed code that would get a cop on your doorstep. Calm down for once in your life, you're seemingly angry in every other email you write, and you're not helping making this project a friendly place at all for new and old contributors alike. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fate: add tests for audio channel up-/downmixing with pan filter
Tobias Rapp (2018-07-26): > Add tests for upmixing and downmixing with audio channel counts that > have a corresponding default layout and also tests where there is no > default layout. > > Update the existing "stereo4" test so it actually outputs stereo like > the other stereo tests. Rename the previous "stereo4" test into > "upmix1". > > Signed-off-by: Tobias Rapp Looks reasonable. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness
Hi
This is something the PeerTube guys need, and this seemed a
straightforward enough approach. Feedback appreciated
/TomasFrom 8d5627c02cc2da8708b5342b58d2a6eaebf189c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 27 Jul 2018 13:54:52 +0200
Subject: [PATCH] qt-faststart: Add mode for probing faststart-ness
Activated by giving the program only a single filename.
There are three cases, with corresponding exit codes:
0: File has moov before mdat, is streamable (not fragmented)
2: File has moov after mdat, not streamable
3: File is fragmented (has moof atoms, is streamable in some players)
Fragmented files get a separate exit code since they may not be
supported in all players.
---
Changelog| 1 +
tests/fate/mov.mak | 40 +++
tools/qt-faststart.c | 78
3 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/Changelog b/Changelog
index 807a05dec9..973b1f9fdd 100644
--- a/Changelog
+++ b/Changelog
@@ -16,6 +16,7 @@ version :
- ATRAC9 decoder
- lensfun wrapper filter
- colorconstancy filter
+- added ability to probe faststart-ness with tools/qt-faststart
version 4.0:
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 6f0e28d21e..404e6c662e 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -29,6 +29,37 @@ FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
fate-mov-guess-delay-3 \
FATE_MOV_FASTSTART = fate-mov-faststart-4gb-overflow \
+ fate-mov-faststart-probe-streamable \
+ fate-mov-faststart-probe-fragmented \
+ fate-mov-faststart-probe-not-streamable \
+
+FATE_MOV_FASTSTART_SAMPLES_STREAMABLE = \
+440hz-10ms.m4a \
+displaymatrix.mov \
+fcp_export8-236.mov \
+white_zombie_scrunch-part.mov \
+
+FATE_MOV_FASTSTART_SAMPLES_FRAGMENTED = \
+buck480p30_na.mp4 \
+frag_overlap.mp4 \
+
+FATE_MOV_FASTSTART_SAMPLES_NOT_STREAMABLE = \
+aac-2048-priming.mov \
+elst_ends_betn_b_and_i.mp4 \
+fake-gp-media-with-real-gpmf.mp4 \
+invalid_elst_entry_count.mov \
+mov-1elist-1ctts.mov \
+mov-1elist-ends-last-bframe.mov \
+mov-1elist-noctts.mov \
+mov-2elist-elist1-ends-bframe.mov \
+mov-3elist-1ctts.mov \
+mov-3elist-encrypted.mov \
+mov-3elist.mov \
+mov-elist-starts-ctts-2ndsample.mov \
+mov_ibi_elst_starts_b.mov \
+moviedispmat.mp4 \
+mp4-init-nonkeyframe.mp4 \
+spherical.mov \
FATE_SAMPLES_AVCONV += $(FATE_MOV)
FATE_SAMPLES_FFPROBE += $(FATE_MOV_FFPROBE)
@@ -116,3 +147,12 @@ fate-mov-guess-delay-3: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries stre
fate-mov-faststart-4gb-overflow: CMD = run tools/qt-faststart$(EXESUF) $(TARGET_SAMPLES)/mov/faststart-4gb-overflow.mov faststart-4gb-overflow-output.mov > /dev/null ; md5sum faststart-4gb-overflow-output.mov | cut -d " " -f1 ; rm faststart-4gb-overflow-output.mov
fate-mov-faststart-4gb-overflow: CMP = oneline
fate-mov-faststart-4gb-overflow: REF = bc875921f151871e787c4b4023269b29
+
+fate-mov-faststart-probe-streamable: CMD = for f in $(FATE_MOV_FASTSTART_SAMPLES_STREAMABLE); do run tools/qt-faststart$(EXESUF) $(TARGET_SAMPLES)/mov/$$f || exit 1; done
+fate-mov-faststart-probe-streamable: CMP = null
+
+fate-mov-faststart-probe-fragmented: CMD = for f in $(FATE_MOV_FASTSTART_SAMPLES_FRAGMENTED); do run tools/qt-faststart$(EXESUF) $(TARGET_SAMPLES)/mov/$$f; [ $$? -eq 3 ] || exit 1; done
+fate-mov-faststart-probe-fragmented: CMP = null
+
+fate-mov-faststart-probe-not-streamable: CMD = for f in $(FATE_MOV_FASTSTART_SAMPLES_NOT_STREAMABLE); do run tools/qt-faststart$(EXESUF) $(TARGET_SAMPLES)/mov/$$f; [ $$? -eq 2 ] || exit 1; done
+fate-mov-faststart-probe-not-streamable: CMP = null
diff --git a/tools/qt-faststart.c b/tools/qt-faststart.c
index 5e88c38e6b..54f44a78f3 100644
--- a/tools/qt-faststart.c
+++ b/tools/qt-faststart.c
@@ -6,6 +6,8 @@
*
* This utility rearranges a Quicktime file such that the moov atom
* is in front of the data, thus facilitating network streaming.
+ * Alternatively, it can also be used to probe a file for whether it is
+ * streamable or not, and if it's fragmented.
*
* To compile this program, start from the base directory from which you
* are building FFmpeg and type:
@@ -15,6 +17,8 @@
* guaranteed, particularly on 64-bit platforms.
* Invoke the program with:
* qt-faststart
+ * To probe a file for faststart-ness, invoke it with:
+ * qt-faststart
*
* Notes: Quicktime files can come in many configurations of top-level
* atoms. This utility stipulates that the very last atom in the file needs
@@ -88,6 +92,9 @@
#define PICT_ATOM QT_ATOM('P', 'I', 'C', 'T')
#define FTYP_ATOM QT_ATOM('f', 't', 'y', 'p')
#define UUID_ATOM QT_ATOM('u', 'u', 'i', 'd')
+#define SIDX_ATOM QT_ATOM('s', 'i', 'd', 'x')
+#define STYP_ATOM QT_ATOM('s', 't', 'y', 'p')
+#define MOOF_ATOM QT_ATOM('m', 'o', 'o', 'f')
Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions
On 2018-07-27 15:05, Henrik Gramner wrote: > On Fri, Jul 27, 2018 at 1:47 PM, James Darnley wrote: >> On 2018-07-26 17:29, Rostislav Pehlivanov wrote: +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w, x, b2 +DECLARE_REG_TMP 2,5 +%if ARCH_X86_64 +%define tail r6d +%else +%define tail dword wm +%endif + >>> >>> You can remove this whole bit, the init function only gets called if >>> ARCH_X86_64 is true. >> >> Where did you get that from? I don't require 64-bit for this. > > Can't you just use 7 GPR:s on x86-32 as well? I'm sure I've done that in the past and at least 1 platform has always complained due to PIE or stack alignment or whatever, I think. I went looking for an old email but couldn't find it. If you want me to try it I can. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
On 7/27/2018 9:10 AM, Liu Steven wrote: > > >> 在 2018年7月20日，上午10:58，Steven Liu 写道： >> >> hwren 于2018年7月19日周四 上午10:38写道： >>> >>> Ping, any comments for following patches? >> will push after one week if there have no objections. > pushed. You forgot to include avs2_parser.o and libdavs2.o in two of your commits. Please do it soon as compilation is currently broken. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions
On Fri, Jul 27, 2018 at 1:47 PM, James Darnley wrote: > On 2018-07-26 17:29, Rostislav Pehlivanov wrote: >>> +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w, >>> x, b2 >>> +DECLARE_REG_TMP 2,5 >>> +%if ARCH_X86_64 >>> +%define tail r6d >>> +%else >>> +%define tail dword wm >>> +%endif >>> + >>> >> >> You can remove this whole bit, the init function only gets called if >> ARCH_X86_64 is true. > > Where did you get that from? I don't require 64-bit for this. Can't you just use 7 GPR:s on x86-32 as well? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Rostislav Pehlivanov (2018-07-27): > Reference - IRC I think I agree with you on the issue at hand, but this point raises again an issue I would like to emphasize: Not everybody in the project does, or even can, participate in IRC discussions. And while these discussions are archived, they are not adapted for reading afterward, they are not curated by their authors like mails. Therefore, please remember that IRC discussions cannot be considered consensus. You can of course discuss things on IRC, but before calling their result consensus, somebody needs to summarize the arguments to bring them on the mailing-list and let them be discussed here. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
> 在 2018年7月20日，上午10:58，Steven Liu 写道： > > hwren 于2018年7月19日周四 上午10:38写道： >> >> Ping, any comments for following patches? > will push after one week if there have no objections. pushed. BTW, Huiwen, submit FATE please, can you maintain the AVS2 codec module? Thanks >> >> >> >> >> >> >> >> At 2018-07-16 15:24:54, "hwren" wrote: >>> hwren (3): >>> lavc: add avs2 parser >>> lavf: add avs2 fourcc >>> lavc,doc,configure: add avs2 video decoder wrapper >>> >>> Changelog| 1 + >>> configure| 4 ++ >>> doc/decoders.texi| 6 ++ >>> doc/general.texi | 14 >>> libavcodec/Makefile | 2 + >>> libavcodec/allcodecs.c | 1 + >>> libavcodec/avcodec.h | 1 + >>> libavcodec/avs2_parser.c | 95 + >>> libavcodec/codec_desc.c | 7 ++ >>> libavcodec/libdavs2.c| 177 >>> +++ >>> libavcodec/parser.c | 1 + >>> libavcodec/version.h | 4 +- >>> libavformat/riff.c | 1 + >>> 13 files changed, 312 insertions(+), 2 deletions(-) >>> create mode 100644 libavcodec/avs2_parser.c >>> create mode 100644 libavcodec/libdavs2.c >>> >>> -- >>> 2.7.4 >>> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Why does ffmpeg h264 decoder stop decoding when certain type of packets are coming in the input stream?
Hi All, I used av_read_frame to get the AVPacket from encoded h264 file. But when this packet (00 00 01 05 94 5a 33 e7 4d 6b d7 ad 13 86 ff 47 83 93 31 f1 e3 0a) is in the input stream (h264 video) ffmpeg decoder stops decoding frames for any subsequent AVPackets. But if I skip this packet to provide to the decoder the next AVPackets decode just fine. Could you please help me to find what is wrong with this packet? Or what is wrong with the ffmpeg decoder? Thanks, Naveed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions
On 2018-07-26 17:29, Rostislav Pehlivanov wrote: > On 26 July 2018 at 12:28, James Darnley wrote: > +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w >> +DECLARE_REG_TMP 4,5 >> + >> +mova m2, [pd_1] >> +mov r3d, wd >> +and wd, ~(mmsize/4 - 1) >> +shl wd, 2 >> +add b0q, wq >> +add b1q, wq >> +neg wq >> + >> +ALIGN 16 >> +.loop_simd: >> +mova m0, [b0q + wq] >> +mova m1, [b1q + wq] >> +paddd m3, m1, m2 >> +psrad m3, 1 >> +psubd m0, m3 >> +paddd m1, m0 >> +mova [b0q + wq], m0 >> +mova [b1q + wq], m1 >> +add wq, mmsize >> +jl .loop_simd >> + >> +and r3d, mmsize/4 - 1 >> +jz .end >> +.loop_scalar: >> +mov t0d, [b0q] >> +mov t1d, [b1q] >> +mov r2d, t1d >> +add r2d, 1 >> +sar r2d, 1 >> +sub t0d, r2d >> +add t1d, t0d >> +mov [b0q], t0d >> +mov [b1q], t1d >> + >> +add b0q, 4 >> +add b1q, 4 >> +sub r3d, 1 >> +jg .loop_scalar >> + >> +.end: >> +RET >> + >> +%endmacro >> + >> +%macro HAAR_HORIZONTAL 0 >> > + >> > > Could you remove this newline from every patch? All asm I've written and > seen keep them without a newline. It made me think there's something in the > asm which checked the value of the macro, not that the entire function is > macro'd. What? I don't understand what you mean. Do you think I have too many blank lines between things? > +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w, >> x, b2 >> +DECLARE_REG_TMP 2,5 >> +%if ARCH_X86_64 >> +%define tail r6d >> +%else >> +%define tail dword wm >> +%endif >> + >> +mova m2, [pd_1] >> +xor xd, xd >> +shr wd, 1 >> +mov tail, wd >> +lea b2q, [bq + 4*wq] >> + >> +ALIGN 16 >> +.loop_lo: >> +mova m0, [bq + 4*xq] >> +movu m1, [b2q + 4*xq] >> +paddd m1, m2 >> +psrad m1, 1 >> +psubd m0, m1 >> +mova [temp_q + 4*xq], m0 >> +add xd, mmsize/4 >> +cmp xd, wd >> +jl .loop_lo >> + >> +xor xd, xd >> +and wd, ~(mmsize/4 - 1) >> + >> +ALIGN 16 >> +.loop_hi: >> +mova m0, [temp_q + 4*xq] >> +movu m1, [b2q+ 4*xq] >> +paddd m1, m0 >> +paddd m0, m2 >> +paddd m1, m2 >> +psrad m0, 1 >> +psrad m1, 1 >> +SBUTTERFLY dq, 0,1,3 >> +%if cpuflag(avx2) >> +SBUTTERFLY dqqq, 0,1,3 >> +%endif >> +mova [bq + 8*xq], m0 >> +mova [bq + 8*xq + mmsize], m1 >> +add xd, mmsize/4 >> +cmp xd, wd >> +jl .loop_hi >> + >> +and tail, mmsize/4 - 1 >> +jz .end >> +.loop_scalar: >> +mov t0d, [temp_q + 4*xq] >> +mov t1d, [b2q+ 4*xq] >> +add t1d, t0d >> +add t0d, 1 >> +add t1d, 1 >> +sar t0d, 1 >> +sar t1d, 1 >> +mov [bq + 8*xq], t0d >> +mov [bq + 8*xq + 4], t1d >> +add xq, 1 >> +sub tail, 1 >> +jg .loop_scalar >> + >> +.end: >> +REP_RET >> + >> +%endmacro >> + >> +INIT_XMM sse2 >> +HAAR_HORIZONTAL >> +HAAR_VERTICAL >> + >> +INIT_XMM avx >> +HAAR_HORIZONTAL >> +HAAR_VERTICAL >> > > You're not using any avx functions in that version, not unless a macro'd > instruction inserts one for you. I think you should remove the avx version > then. > Also since you always have a HAAR_HORIZONTAL and HAAR_VERTICAL macros per > version you can just make a single macro to do both versions at the same > time. Now that I think about it there will be only one 3-operand instruction in the SBUTTERFLY and the vertical function also only has 1. I will remove it. I can merge the two macros but I will look back at what I've done previously. I think it is usually 1 macro per function. > + >> +INIT_YMM avx2 >> +HAAR_HORIZONTAL >> +HAAR_VERTICAL >> diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c >> b/libavcodec/x86/dirac_dwt_init_10bit.c >> new file mode 100644 >> index 00..289862d728 >> --- /dev/null >> +++ b/libavcodec/x86/dirac_dwt_init_10bit.c >> @@ -0,0 +1,76 @@ >> +/* >> + * x86 optimized discrete wavelet transform >> + * Copyright (c) 2018 James Darnley >> + * >> + * 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
Re: [FFmpeg-devel] [PATCH] avformat/librtmp: fix returning EOF from Read/Write
I did a 24h test with this, and it seems to fix the issue. Will apply and backport to 4.0 in 24h if nobody objects. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hi, On Fri, Jul 27, 2018 at 7:02 AM, Ronald S. Bultje wrote: > Hi, > > On Thu, Jul 26, 2018 at 11:49 PM, Pedro Arthur > wrote: > >> Taking the vp9 as example, sure the coeficients are obtained by the >> 'poly3' but the real data are the polynomial coeficients, does any one >> asks where these polynomial coeficients came from, reproducibility, >> etc? Your comparison does not seems fair to me. > > > The ~1.02 in VP9/AV1 and 6 in HEVC? They are stepsizes (in different > units). It's exactly clear where they come from and it's obvious how to > adjust them. You want more than 52 qps at the same range in HEVC? Increase > the 6. > > How do I adjust the NN coefficients to get a defined adjustment in > behaviour? > Actually, since I know you'll answer like you don't get it, let me explain it in more detail to you: the adjustment in quantizer, derivation of the coefficients if you will, is all defined by the process itself. The external tools used to validate are the actual encoding software itself (the model). You call this training? Sure, but then the software created by the training *is* the training software in itself. But in all reasonableness, it's clear what each value means and how its adjustments affects the process - that is, if you are willing to understand. NN is different. The exposed software *uses* but does not *generate* the coefficients. In fact, the meaning of most coefficients is completely opaque. They are just multiplier and addition constants with no obvious relationship to reality, other than that they were generated by some magical process that tells us that statistically (??), this bears resemblence to some trained form of reality. You want to adjust behaviour for a defined different outcome? You'll have to retrain. That's all fine, don't get me wrong, but we need to know how to retrain since it's not obvious to us. Just tell us what process and what data were used to get the outcome so that we can get a different outcome if we so choose (that *is* freedom to modify)? Please document (and make available) all such information for the re-training. There's a second, orthogonal, concern: many of these filters that we're seeing now are filters to convert X to Y are do process Z on data A. That's great. I love it. I have no problem with it. I see a filter that converts 8bit RGB to 10bit HDR RGB and it's fantastic, it's a little bit like colorspace (which I wrote) but maybe it can actually get closer to intended (rather than artifacted) source, which would be fantastic. I hope it works. But: how do we know that it does? For example, for the colorspace filter, it's clear, because all coefficients come from the reference documentation. For the NN filter version, how do I know it works? Seriously. If I were an anonymous Russian submitting such a filter to the American elections, how can I guarantee that it does what I say it does rather than just randomly garbling the lower bits? How would I know the difference? Again, I need to know how it was trained. Lastly, if all filters do the same but with a different set of coefs, then why not simply have one filter and loadable coefs? Maybe subclassing etc. for better documentation - it would make SIMD a lot easier since we only have to write it once. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
On 27 July 2018 at 03:04, Pedro Arthur wrote: > Hi, > > I'm surprised with this patch, there wasn't any concern raised in the > patch review process. > It slipped through, and we (and you) should have known better. > 2018-07-26 16:26 GMT-03:00 Rostislav Pehlivanov : > > As discussed recently, the vf_sr filter and the DNN framework have an > > issue: unreproducable weights and questionable license, as well as > > overall unfitting coding style to the rest of the project. > I think I'm not aware of these discussions could you provide a > reference? I also don't understand why the coding style is unfitting > (again no concern was raised). > Reference - IRC and j-b's earlier email. Coding style issues: DNNModel* ff_dnn_load_model_native(const char* model_filename) We never ever do stupid things like put the asterix first. The author of the patch should have known better and the patch should have been checked. Even a glance could have told you its wrong. > > > The vf_sr filter in particular has weights embedded which weight the > > libavfilter binary by a bit and cannot currently be reproduced. > > There's an overall consensus that NN filters should accept external > > weights only, as the nnedi filter currently does. > > > > So, temporarily remove both until the coding style issues have been > > fixed with the framework and the filter has been modified to accept > > external weights. > What are these issues so we can fix them? > I described them in the sentence above. But I'm not willing to wait for a potential fix, and especially not for a whole bunch of them rewriting everything. The whole code needs to be thrown out and thoroughly reviewed properly, by at least yourself and one other person, preferably before gsoc ends. You should start coordinating with your student on how to fix everything mentioned and then resend the patchsets once fixed. I'll apply the revert patch tomorrow. > > > Also, there's a discussion by the Debian folks as to whether to treat > > pretrained NNs as non-free[0], hence its not just our project that's > > affected by the questionable license of distributing pretrained NN > > weights. > > > > Due to the weight of the patch (more than 1mb!) I've uploaded it to > > https://0x0.st/sVEH.patch if anyone wants to test it. The change stat > > is printed below. > > > > [0]: https://lwn.net/Articles/760142/ > I took the time to read the whole discussion and in my opinion it is > flawed, except for the storage requirement, which Sergey already > worked on a patch to reduce the stored data. > > > I think before any discussion, it should be clear what is the ffmpeg > policy on adding data, and what is considered data, and it should be > consistent. > > I'll try to address the topics in the above discussion. > > First what is data? is it expected that all data stored should be > easily reproducible? > Easily? No. Always? Absolutely. I guess not, what is the point in storing data that is easily reproducible? > We do it for speed reasons. Large tables take time to generate on startup. The entire humanity is built on previous stored knowledge, namely > data, do we require each time one is going to use some form of > knowledge to reproduce it? that is, proof everything one is using? > The answer is no, the whole point in storing data is that you had once > worked hard to proof it works and onwards just use it and believe it > works. That does not mean it is imposible to proof everything. > > I think the above fits perfectly with NN weights as data. > > The next point is the reproducibility, one should be reasonable, it is > hard to reproduce bit by bit of NN stored data but is totally doable > to achieve similar results following the same training metodology > used. > Very well, provide code and references to sources to reproduce please. > Then there is the question what is open-source, once again one should > be reasonable. > The NN model is public available, everything is documented, the math > machinery is also widely available and documented. > There is also a repository containing everything one needs to train > the NN and achieve similar results, the trainig data is public also. > The training software is open-source, the user could also use any > machine learning framework of their choice to perform the training > since the model is documented, there is nothing locking one to a > specific software or hardware. > I can't see what is not open. > The process to replicate the weights. Provide script(s) and references to sources. Does we impose all requiriments imposed for NN weights on all other > data stored in ffmpeg? > I guess not, once more one should be consistent. > > > If you compare NN weights with quantization tables they are pretty > similar, both can be obtained from a training process over a dataset > so it achieves better results (quality/compression). Are quantization > tables evil? I don't think so. > It seems people is afraid of NN just because we give
[FFmpeg-devel] [PATCH] lavfi: add lumakey_opencl filter
Add lumakey_opencl filter. Behaves like existing lumakey filter. --- On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote: >> On 7/25/2018 9:13 AM, Danil Iashchenko wrote: >> > Add lumakey_opencl filter. Behaves like existing lumakey filter. >> >> Isn't it possible to keep each of these new OpenCL filters as an >> optional codepath within the C version, using an AVOption like "opencl" >> or "hwaccel" to toggle one or another? Or maybe autodetected depending >> on the filter chain and/or input pix_fmt? >> >> I'm asking because it's getting too crowded. We also have some vaapi and >> qsv duplicate filters, and once we start committing filters using the >> upcoming Vulkan hwcontext the same way, we may also end up introducing >> yet another hardware specific variant for each of these. >> >> In libavcodec the hwaccels are seamlessly integrated into supported >> decoders. This has been favored over separate full stream hardware >> decoders where possible for the above reasons. It would be ideal to >> achieve the same with libavfilter. >i am in favor of this design as well. The user should not need to have >to know about and manage manually GPU optimizations. >thx Hi! I am GSoC student and I still have some tasks before the program ends. Also my mentor said: IMO don't think about it now, there isn't that much time left. I looked at doing last year (when converting to the current structure) and concluded that it's not really sane to do. The _opencl versions of filters operate completely differently, so while some code for setup can be shared putting them in the same filter doesn't really make sense. Thanks, Danil. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hi, On Thu, Jul 26, 2018 at 11:49 PM, Pedro Arthur wrote: > Taking the vp9 as example, sure the coeficients are obtained by the > 'poly3' but the real data are the polynomial coeficients, does any one > asks where these polynomial coeficients came from, reproducibility, > etc? Your comparison does not seems fair to me. The ~1.02 in VP9/AV1 and 6 in HEVC? They are stepsizes (in different units). It's exactly clear where they come from and it's obvious how to adjust them. You want more than 52 qps at the same range in HEVC? Increase the 6. How do I adjust the NN coefficients to get a defined adjustment in behaviour? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
2018-07-27 4:04 GMT+02:00, Pedro Arthur : > Does we impose all requiriments imposed for NN weights > on all other data stored in ffmpeg? (As explained before:) No, we clearly do not. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter
Hello, On Fri, 27 Jul 2018, at 05:49, Pedro Arthur wrote: > > Are NN weights a single, one-line (10-character) expression? Please > > elaborate. Why isn't that 10-character function documented anywhere? > I think you missed the point, I wrote "can be obtained from a training > process over a dataset so it achieves better results > (quality/compression)". Yes, but that is the point I made days ago already, and you did not address. You MUST provide a process to produce data that is similar. Else, it is not free software. It might be cool and fun; but that is not free software. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/nlmeans: fixup aarch64 assembly with clang
On Fri, Jul 27, 2018 at 12:03:46AM +0300, Jan Ekström wrote:
> Clang is more strict about some things.
> ---
> libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S
> b/libavfilter/aarch64/vf_nlmeans_neon.S
> index 6308a428db..ac16157bbd 100644
> --- a/libavfilter/aarch64/vf_nlmeans_neon.S
> +++ b/libavfilter/aarch64/vf_nlmeans_neon.S
> @@ -22,7 +22,7 @@
>
> // acc_sum_store(ABCD) = {X+A, X+A+B, X+A+B+C, X+A+B+C+D}
> .macro acc_sum_store x, xb
> -dup v24.4S, v24.4S[3] //
> ...X ->
> +dup v24.4s, v24.s[3]//
> ...X ->
can you keep the capitalized form?
> ext v25.16B, v26.16B, \xb, #12 //
> ext(,ABCD,12)=0ABC
> add v24.4S, v24.4S, \x //
> +ABCD={X+A,X+B,X+C,X+D}
> add v24.4S, v24.4S, v25.4S //
> {X+A,X+B+A,X+C+B,X+D+C} (+0ABC)
> @@ -37,7 +37,7 @@ function ff_compute_safe_ssd_integral_image_neon, export=1
> moviv26.4S, #0 //
> used as zero for the "rotations" in acc_sum_store
> sub x3, x3, w6, UXTW//
> s1 padding (s1_linesize - w)
> sub x5, x5, w6, UXTW//
> s2 padding (s2_linesize - w)
> -sub x9, x0, x1, UXTW #2 //
> dst_top
> +sub x9, x0, w1, UXTW #2 //
> dst_top
> sub x1, x1, w6, UXTW//
> dst padding (dst_linesize_32 - w)
> lsl x1, x1, #2 //
> dst padding expressed in bytes
> 1: mov w10, w6 //
> width copy for each line
LGTM otherwise, thx
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavformat/dashenc: Fix relative URI of HLS master playlist
On 7/26/18 6:52 PM, Antonio Morell wrote: > --- > libavformat/dashenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > index a9b8b1d4f6..ae57fd5493 100644 > --- a/libavformat/dashenc.c > +++ b/libavformat/dashenc.c > @@ -868,7 +868,7 @@ static int write_manifest(AVFormatContext *s, int final) > int max_audio_bitrate = 0; > > if (*c->dirname) > -snprintf(filename_hls, sizeof(filename_hls), "%s/master.m3u8", > c->dirname); > +snprintf(filename_hls, sizeof(filename_hls), "%smaster.m3u8", > c->dirname); > else > snprintf(filename_hls, sizeof(filename_hls), "master.m3u8"); > LGTM. Thanks, Karthick > -- > 2.15.2 (Apple Git-101.1) > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
