Re: [FFmpeg-devel] HAP QuickTime codec support
On Sat, 15 Nov 2014 12:34:57 +0100 Reimar Döffinger wrote: > > Are you sure this compression format makes any sense whatsoever? > > You get a 1:6 compression (exactly, compared to RGB888), but > > also horrible compression artefacts. > > Simply going to half the resolution in x and y with YUV420 gives > > you 1:8 compression and I would bet it would even look better. > > At least I have a hard time seeing how it could look much worse. > > Looking at texture compression formats, I don't think any make much > sense for video that is originally in 4:2:0 format. > The first that might be interesting (but is limited to a few mobile > devices) is ASTC. > Besides better quality at same bitrate, it allow for (relatively) > fine-grained per-frame compression ratio selection (and thus a > kind of rate-control), enough encoding options for perceptual encoding > and temporal compression (by using 3D textures). > But even with those improvements the usefulness for video even > compared to uncompressed seems questionable, especially since even > with uncompressed textures you could implement delta encoding > on the GPU. Well the intended use for me is solely to be able to process more videos in parallel from a single hard drive using the mentioned video compositing application, quality is (for now) secondary, but I will do some comparisons myself as soon as I can get my hands on a MacOS or Windows machine again. The problem with 4:2:0 (which we are currently using for most content) is that it is still too heavy on the CPU load to make streaming of many videos in parallel completely smooth, which is our primary requirement. Simply using uncompressed actually did not occur to me beforehand. Next time we get together I will see how far we can get with this until the drive's bandwidth is the bottleneck, which I fear might become an issue quickly. Thanks for having a look at this! Best regards, -- Patric Schmitz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Move ffmpeg to WinRT
Hi All, I want to move ffmpeg to WinRT platform, like Windows Store and Windows Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style assembly codes to ARM-style codes. Also the codes are open-sourced, here https://github.com/qyljcy/FFmpeg Now this project can be compiled, but I didn't know if the assembly codes work well. I want to know, if there is any test project to test the function like ff_ps_add_squares_neon, ect. As the WinRT platform is different from win32 or linux, so I need to test them one by one. I hope someone can help me, or work together. Thanks very much Best regards,Jesse ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Move ffmpeg to WinRT
As of Windows 10, WinRT is deprecated, so it's kind of a waste of time dude :/ On Mon, Nov 17, 2014 at 5:02 AM, Jesse Jiang wrote: > Hi All, > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > assembly codes to ARM-style codes. Also the codes are open-sourced, here > https://github.com/qyljcy/FFmpeg > Now this project can be compiled, but I didn't know if the assembly codes > work well. > I want to know, if there is any test project to test the function like > ff_ps_add_squares_neon, ect. As the WinRT platform is different from win32 > or linux, so I need to test them one by one. > I hope someone can help me, or work together. > Thanks very much > Best regards,Jesse > ___ > 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] Move ffmpeg to WinRT
On 17 November 2014 21:02, Jesse Jiang wrote: > Hi All, > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > assembly codes to ARM-style codes. Also the codes are open-sourced, here > https://github.com/qyljcy/FFmpeg > Now this project can be compiled, but I didn't know if the assembly codes > work well. > I want to know, if there is any test project to test the function like > ff_ps_add_squares_neon, ect. As the WinRT platform is different from win32 > or linux, so I need to test them one by one. > I hope someone can help me, or work together. > Thanks very much > Best regards,Jesse > Have you had a look through the tests provided by FFmpegs FATE ( https://www.ffmpeg.org/fate.html)? Also I noticed you converted the GNU arm assembly and created new code files. What is the syntax difference between the 2? i.e. what had to be changed. As it might be possible to just add some pre-processor macros to allow the existing code to compile under the windows arm compiler. That way 2 different source files dont need to be maintained for the exact same code. As of Windows 10, WinRT is deprecated, so it's kind of a waste of time dude Without getting into how (not so)well the Windows RT tablets sold, but Windows 10 apparently has a ARM build coming later next year and on winphones ARM will be supported for a while. So windows on arm (previously Windows RT) is not entirely dead. That said the windows run-time (WinRT) is still used for apps in the metro store and is a focus of windows 10 as they are unifying the app store across devices (pc,phone,xbox). So from a dev point of view people really need to differentiate between Windows RT and WinRT in discussions ;). So from what I can tell Jesse is trying to support both arm under the windows compiler and then then Windows store. Either of which could be useful for ffmpeg on windows phone and for distributing apps in the windows store (although win store support is a whole can of worms!). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Move ffmpeg to WinRT
On 17 Nov, Matt Oliver wrote : > As of Windows 10, WinRT is deprecated, so it's kind of a waste of time dude Please read again. It's quite the opposite. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Move ffmpeg to WinRT
On 17 Nov, Jesse Jiang wrote : > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > assembly codes to ARM-style codes. Also the codes are open-sourced, here > https://github.com/qyljcy/FFmpeg > Now this project can be compiled, but I didn't know if the assembly codes > work well. This work is useless... FFmpeg can already be compiled on WinRT, with gas-preproc... -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Mon, 17 Nov 2014 11:24:56 +0100 René J.V. Bertin wrote: > On Friday November 14 2014 18:47:53 bzk0...@aol.com wrote: > > >We need Hap encoded videos to use them with a video compositing / VJing > >software on MacOS, Modul8 (http://www.modul8.ch/). When using lots of > > Really, MacOS? > (MacOS =/= Mac OS X!) It is Mac OS X. -- Patric Schmitz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_i386: Optimize decode_significance_8x8_x86 for 64 bit.
On Mon, Nov 17, 2014 at 08:19:32AM +0100, Reimar Döffinger wrote: > On 17.11.2014, at 02:37, Michael Niedermayer wrote: > > On Sat, Nov 15, 2014 at 06:16:03PM +0100, Reimar Döffinger wrote: > >> 11674 -> 10877 decicycles on my Phenom II. > >> Overall speedup was unfortunately within measurement error. > > > > here its 10153 ->10135 > > I suspect it also depends a bit on the compiler and how it changes the > surrounding code. > Note that I also tested with PIC actually. > > > but ive a slightly odd feeling about the chnages to the asm code, > > iam not sure if all assemblers will be happy about the changed > > code > > Do you mean particularly the movzbl change? yes and the k stuff > I am also unsure about that, I think there was a reason for that %k6 mess... > But this as well as movzx seemed to work for me... it works here too i just have the feeling it might fail on some odd assembler or platform. Thats not meant to keep you from pushing this just that it might require to be reverted or fixed if such problems actually occor [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 07/11] lavu/dict: add av_dict_serialize
On Mon, Nov 17, 2014 at 02:46:54AM +0100, Lukasz Marek wrote:
> TODO: bump minor, update doc/APIchanges
>
> Signed-off-by: Lukasz Marek
> ---
> libavutil/dict.c | 27 +++
> libavutil/dict.h | 16
> 2 files changed, 43 insertions(+)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 475e906..a41d61e 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -24,6 +24,7 @@
> #include "dict.h"
> #include "internal.h"
> #include "mem.h"
> +#include "bprint.h"
>
> struct AVDictionary {
> int count;
> @@ -207,3 +208,29 @@ void av_dict_copy(AVDictionary **dst, FF_CONST_AVUTIL53
> AVDictionary *src, int f
> while ((t = av_dict_get(src, "", t, AV_DICT_IGNORE_SUFFIX)))
> av_dict_set(dst, t->key, t->value, flags);
> }
> +
> +int av_dict_serialize(const AVDictionary *m, char **buffer,
> + const char pairs_sep, const char key_val_sep)
> +{
> +AVDictionaryEntry *t = NULL;
> +AVBPrint bprint;
> +int cnt = 0;
> +
> +if (!m || !buffer)
> +return AVERROR(EINVAL);
It should be also possible to serialize an empty dictionary
the serialization string should also contain a serialization format
identifer/version otherwise future maintaince could become hard
this identifer should specify the used separator chars
> +
> +if (!av_dict_count(m)) {
> +*buffer = av_strdup("");
> +return *buffer ? 0 : AVERROR(ENOMEM);
> +}
> +
> +av_bprint_init(&bprint, 64, AV_BPRINT_SIZE_UNLIMITED);
> +
> +while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
> +if (cnt++)
> +av_bprint_append_data(&bprint, &pairs_sep, 1);
> +av_bprintf(&bprint, "%s%c%s", t->key, key_val_sep, t->value);
> +}
this would fail for a string containing the seperator chars
and a string containing all 255 chars could not be serialized at
all.
Also it would lack a check for the occurance of the seperator chars
in the source
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 11/11] ffmpeg_opt: make use of recommended encoder configuration
On Mon, Nov 17, 2014 at 03:04:31AM +0100, Lukasz Marek wrote: > On 17.11.2014 02:46, Lukasz Marek wrote: > >So far ffmpeg used recommended configuration only for codec priv options. > >ffmpeg will use now codec defaults and then apply recommended configuration > >for all options. Recommended configuration possibly contains minimal > >set of options to filful user configuration. > > > >Signed-off-by: Lukasz Marek > >--- > > ffmpeg_opt.c | 41 - > > 1 file changed, 12 insertions(+), 29 deletions(-) > > whole patchset on my github, master branch ./configure && make -j12 alltools LD tools/ffserver_config_test gcc: error: ffserver_config.o: No such file or directory gcc: error: cmdutils.o: No such file or directory make: *** [tools/ffserver_config_test] Error 1 make -j12 && make -j12 alltools LD tools/ffserver_config_test libavformat/libavformat.a(swfdec.o): In function `swf_read_packet': /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:335: undefined reference to `uncompress' libavformat/libavformat.a(swfdec.o): In function `swf_read_header': /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:124: undefined reference to `inflateInit_' libavformat/libavformat.a(swfdec.o): In function `zlib_refill': /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:92: undefined reference to `inflate' libavformat/libavformat.a(swfdec.o): In function `swf_read_close': /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:502: undefined reference to `inflateEnd' ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 11/11] ffmpeg_opt: make use of recommended encoder configuration
On 17 November 2014 15:15, Michael Niedermayer wrote: > On Mon, Nov 17, 2014 at 03:04:31AM +0100, Lukasz Marek wrote: > > On 17.11.2014 02:46, Lukasz Marek wrote: > > >So far ffmpeg used recommended configuration only for codec priv > options. > > >ffmpeg will use now codec defaults and then apply recommended > configuration > > >for all options. Recommended configuration possibly contains minimal > > >set of options to filful user configuration. > > > > > >Signed-off-by: Lukasz Marek > > >--- > > > ffmpeg_opt.c | 41 - > > > 1 file changed, 12 insertions(+), 29 deletions(-) > > > > whole patchset on my github, master branch > > ./configure && make -j12 alltools > LD tools/ffserver_config_test > gcc: error: ffserver_config.o: No such file or directory > gcc: error: cmdutils.o: No such file or directory > make: *** [tools/ffserver_config_test] Error 1 > > > make -j12 && make -j12 alltools > LD tools/ffserver_config_test > libavformat/libavformat.a(swfdec.o): In function `swf_read_packet': > /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:335: undefined > reference to `uncompress' > libavformat/libavformat.a(swfdec.o): In function `swf_read_header': > /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:124: undefined > reference to `inflateInit_' > libavformat/libavformat.a(swfdec.o): In function `zlib_refill': > /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:92: undefined > reference to `inflate' > libavformat/libavformat.a(swfdec.o): In function `swf_read_close': > /home/michael/ffmpeg-git/ffmpeg/libavformat/swfdec.c:502: undefined > reference to `inflateEnd' > this is because of following patch, it is work in progress so I can be removed from this patches. [PATCH 06/11] [WIP][RFC]tools: add ffserver_config_test Pushed just as reference changes so far not break anything, But I would appreciate some help with it to fix Makefile, I'm not good with Makefiles. If no one helps then I will postpone this one commit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] use openh264 in ffmpeg
hi I want to use openh264 in ffmpeg, how should I do this? please give me some help. thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] use openh264 in ffmpeg
On Mon, Nov 17, 2014 at 1:18 AM, 王山而 wrote: > hi > I want to use openh264 in ffmpeg, how should I do this? > please give me some help. > thank you. Why? FFmpeg has a native H.264 decoder and I am fairly sure x264 still performs better than OpenH264. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Mon, Nov 17, 2014 at 09:52:31AM +0100, bzk0...@aol.com wrote: > The problem with 4:2:0 (which we are currently using > for most content) is that it is still too heavy on the > CPU load to make streaming of many videos in parallel > completely smooth, which is our primary requirement. > > Simply using uncompressed actually did not occur to me > beforehand. Next time we get together I will see how > far we can get with this until the drive's bandwidth > is the bottleneck, which I fear might become an issue > quickly. Thanks for having a look at this! I am not sure you understood my question/suggestion correctly. Uncompressed YUV 4:2:0 has half the bandwidth of uncompressed RGB, and any half-modern GPU can play it "directly" (MPlayer's -vo gl for example for one implementation). Reduce the resolution a bit and the bandwith is the same as with this codec (well, depending on compression mode). Also some of those old codecs are probably also an option if bandwidth to the GPU is not the problem. NUV (both with and without "RT" JPEG) and cinepack are examples for such codecs (though the latter is horribly slow to encode with FFmpeg at least). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] use openh264 in ffmpeg
On Mon, 17 Nov 2014 13:34:24 -0800 Timothy Gu wrote: > On Mon, Nov 17, 2014 at 1:18 AM, 王山而 wrote: > > hi > > I want to use openh264 in ffmpeg, how should I do this? > > please give me some help. > > thank you. > > Why? FFmpeg has a native H.264 decoder and I am fairly sure x264 still > performs better than OpenH264. users use ffmpeg as a wrapper api for the various standard encoders and decoders. libmpeg, xvid, libvorbis, etc. the wrapper code doesnt change much and people find it helpful. ffmpeg used to have a lot of wrappers for other libs. also useful for testing our dec/encoders. instead of having to use mplayer to test between xvid and ffmpeg4... -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/oss_audio: avoid strerror() and errbuf
On Sat, Oct 18, 2014 at 11:29:36PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavdevice/oss_audio.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 07/11] lavu/dict: add av_dict_serialize
On 17.11.2014 14:01, Michael Niedermayer wrote:
On Mon, Nov 17, 2014 at 02:46:54AM +0100, Lukasz Marek wrote:
TODO: bump minor, update doc/APIchanges
Signed-off-by: Lukasz Marek
---
libavutil/dict.c | 27 +++
libavutil/dict.h | 16
2 files changed, 43 insertions(+)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 475e906..a41d61e 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -24,6 +24,7 @@
#include "dict.h"
#include "internal.h"
#include "mem.h"
+#include "bprint.h"
struct AVDictionary {
int count;
@@ -207,3 +208,29 @@ void av_dict_copy(AVDictionary **dst, FF_CONST_AVUTIL53
AVDictionary *src, int f
while ((t = av_dict_get(src, "", t, AV_DICT_IGNORE_SUFFIX)))
av_dict_set(dst, t->key, t->value, flags);
}
+
+int av_dict_serialize(const AVDictionary *m, char **buffer,
+ const char pairs_sep, const char key_val_sep)
+{
+AVDictionaryEntry *t = NULL;
+AVBPrint bprint;
+int cnt = 0;
+
+if (!m || !buffer)
+return AVERROR(EINVAL);
It should be also possible to serialize an empty dictionary
the serialization string should also contain a serialization format
identifer/version otherwise future maintaince could become hard
this identifer should specify the used separator chars
Escaping OK, added. But what is the point of this? It will just require
additional function to remove these and pass it to av_dict_parse_string.
Of course user will not have to remember separators.
>From 13a3a26622fddf714a46580fccbe9e63563e2445 Mon Sep 17 00:00:00 2001
From: Lukasz Marek
Date: Sun, 16 Nov 2014 01:45:07 +0100
Subject: [PATCH] lavu/dict: add av_dict_serialize
TODO: bump minor, update doc/APIchanges
Signed-off-by: Lukasz Marek
---
libavutil/Makefile | 1 +
libavutil/dict.c | 67 ++
libavutil/dict.h | 16 +
3 files changed, 84 insertions(+)
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 6f90301..c1aa8aa 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -157,6 +157,7 @@ TESTPROGS = adler32 \
cpu \
crc \
des \
+dict\
error \
eval\
file\
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 475e906..7e3bb25 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -24,6 +24,7 @@
#include "dict.h"
#include "internal.h"
#include "mem.h"
+#include "bprint.h"
struct AVDictionary {
int count;
@@ -207,3 +208,69 @@ void av_dict_copy(AVDictionary **dst, FF_CONST_AVUTIL53 AVDictionary *src, int f
while ((t = av_dict_get(src, "", t, AV_DICT_IGNORE_SUFFIX)))
av_dict_set(dst, t->key, t->value, flags);
}
+
+int av_dict_serialize(const AVDictionary *m, char **buffer,
+ const char pairs_sep, const char key_val_sep)
+{
+AVDictionaryEntry *t = NULL;
+AVBPrint bprint;
+int cnt = 0;
+char special_chars[] = {pairs_sep, key_val_sep, '\0'};
+
+if (!buffer || pairs_sep == '\0' || key_val_sep == '\0' || pairs_sep == key_val_sep)
+return AVERROR(EINVAL);
+
+if (!av_dict_count(m)) {
+*buffer = av_strdup("");
+return *buffer ? 0 : AVERROR(ENOMEM);
+}
+
+av_bprint_init(&bprint, 64, AV_BPRINT_SIZE_UNLIMITED);
+
+while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
+if (cnt++)
+av_bprint_append_data(&bprint, &pairs_sep, 1);
+av_bprint_escape(&bprint, t->key, special_chars, AV_ESCAPE_MODE_BACKSLASH, 0);
+av_bprint_append_data(&bprint, &key_val_sep, 1);
+av_bprint_escape(&bprint, t->value, special_chars, AV_ESCAPE_MODE_BACKSLASH, 0);
+}
+
+return av_bprint_finalize(&bprint, buffer);
+}
+
+#ifdef TEST
+static void print_dict(const AVDictionary *m)
+{
+AVDictionaryEntry *t = NULL;
+while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX)))
+printf("%s %s ", t->key, t->value);
+printf("\n");
+}
+
+int main(void)
+{
+AVDictionary *dict = NULL;
+char *buffer = NULL;
+
+av_dict_serialize(dict, &buffer, ',', '=');
+printf("%s\n", buffer);
+av_freep(&buffer);
+
+av_dict_set(&dict, "aaa", "aaa", 0);
+av_dict_set(&dict, "b,b", "bbb", 0);
+av_dict_set(&dict, "c=c", "ccc", 0);
+av_dict_set(&dict, "ddd", "d,d", 0);
+av_dict_set(&dict, "eee", "e=e", 0);
+av_dict_set(&dict, "f,f", "f=f", 0);
+av_dict_set(&dict, "g=g", "g,g", 0);
+print_dict(dict);
+av_dict_serialize(dict, &
Re: [FFmpeg-devel] Move ffmpeg to WinRT
This project should be used as static library. I have done two things in this project. One is converting unsupported APIs to Winrt API, other is converting arm assembly codes to support armasm which VS compiler. Don't worry about Windows 10. Windows 10 is based on the WinRT API, maybe there are some differences, but most of them are the same. > From: bumblebritche...@gmail.com > Date: Mon, 17 Nov 2014 05:37:11 -0500 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] Move ffmpeg to WinRT > > As of Windows 10, WinRT is deprecated, so it's kind of a waste of time dude > :/ > > On Mon, Nov 17, 2014 at 5:02 AM, Jesse Jiang > wrote: > > > Hi All, > > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > > assembly codes to ARM-style codes. Also the codes are open-sourced, here > > https://github.com/qyljcy/FFmpeg > > Now this project can be compiled, but I didn't know if the assembly codes > > work well. > > I want to know, if there is any test project to test the function like > > ff_ps_add_squares_neon, ect. As the WinRT platform is different from win32 > > or linux, so I need to test them one by one. > > I hope someone can help me, or work together. > > Thanks very much > > Best regards,Jesse > > ___ > > 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 mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 07/11] lavu/dict: add av_dict_serialize
On Tue, Nov 18, 2014 at 01:28:42AM +0100, Lukasz Marek wrote:
> On 17.11.2014 14:01, Michael Niedermayer wrote:
> >On Mon, Nov 17, 2014 at 02:46:54AM +0100, Lukasz Marek wrote:
> >>TODO: bump minor, update doc/APIchanges
> >>
> >>Signed-off-by: Lukasz Marek
> >>---
> >> libavutil/dict.c | 27 +++
> >> libavutil/dict.h | 16
> >> 2 files changed, 43 insertions(+)
> >>
> >>diff --git a/libavutil/dict.c b/libavutil/dict.c
> >>index 475e906..a41d61e 100644
> >>--- a/libavutil/dict.c
> >>+++ b/libavutil/dict.c
> >>@@ -24,6 +24,7 @@
> >> #include "dict.h"
> >> #include "internal.h"
> >> #include "mem.h"
> >>+#include "bprint.h"
> >>
> >> struct AVDictionary {
> >> int count;
> >
> >>@@ -207,3 +208,29 @@ void av_dict_copy(AVDictionary **dst,
> >>FF_CONST_AVUTIL53 AVDictionary *src, int f
> >> while ((t = av_dict_get(src, "", t, AV_DICT_IGNORE_SUFFIX)))
> >> av_dict_set(dst, t->key, t->value, flags);
> >> }
> >>+
> >>+int av_dict_serialize(const AVDictionary *m, char **buffer,
> >>+ const char pairs_sep, const char key_val_sep)
> >>+{
> >>+AVDictionaryEntry *t = NULL;
> >>+AVBPrint bprint;
> >>+int cnt = 0;
> >>+
> >>+if (!m || !buffer)
> >>+return AVERROR(EINVAL);
> >
> >It should be also possible to serialize an empty dictionary
> >
> >the serialization string should also contain a serialization format
> >identifer/version otherwise future maintaince could become hard
> >this identifer should specify the used separator chars
>
> Escaping OK, added. But what is the point of this? It will just
> require additional function to remove these and pass it to
> av_dict_parse_string.
> Of course user will not have to remember separators.
what will the function be used for ?
will it be used to store dictionaries in files?, communicate them
across the network? communicate between libs ?
most likely the format will change over the years in some way,
maybe dictionaries will get additional fields for type or maybe
length for non-null terminated data, or ...
how will that work without any way to identify the version or format?
also a serialization stream thats self containd seems much nicer to
handle as theres no need to keep track of the exact version (if we
end up having more than 1) the used seperators, ...
also consider 2 libs or apps to interface with each other using this
serialization format, if one requires a change to the format how can
the other know without a version in it, it would need to know it by
external means. it can surely be done but it doesnt feel like
something desirable
[...]
> @@ -207,3 +208,69 @@ void av_dict_copy(AVDictionary **dst, FF_CONST_AVUTIL53
> AVDictionary *src, int f
> while ((t = av_dict_get(src, "", t, AV_DICT_IGNORE_SUFFIX)))
> av_dict_set(dst, t->key, t->value, flags);
> }
> +
> +int av_dict_serialize(const AVDictionary *m, char **buffer,
> + const char pairs_sep, const char key_val_sep)
> +{
> +AVDictionaryEntry *t = NULL;
> +AVBPrint bprint;
> +int cnt = 0;
> +char special_chars[] = {pairs_sep, key_val_sep, '\0'};
> +
> +if (!buffer || pairs_sep == '\0' || key_val_sep == '\0' || pairs_sep ==
> key_val_sep)
> +return AVERROR(EINVAL);
does it work if the escaping chars " ' \ are used as seperators ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Move ffmpeg to WinRT
Hi Matt, I know FFmpegs FATE, but it may be not what I want. As my fork does not support network, and cannot be output *.exe I just want to know, if the function works well. For example, I need know the input of ff_mdct_fixed_calc_neon and test if my output is correct. In this way, I can know which file is incorrect. If I test the whole video files. I cann't know which function is incorrect. The syntax has lots of differences, and the armasm does not support advantage syntax. I meet lots of problems when I try to convert vc1dsp_neon.s, and I didn't finish this file. > Date: Mon, 17 Nov 2014 22:11:37 +1100 > From: protogo...@gmail.com > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] Move ffmpeg to WinRT > > On 17 November 2014 21:02, Jesse Jiang wrote: > > > Hi All, > > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > > assembly codes to ARM-style codes. Also the codes are open-sourced, here > > https://github.com/qyljcy/FFmpeg > > Now this project can be compiled, but I didn't know if the assembly codes > > work well. > > I want to know, if there is any test project to test the function like > > ff_ps_add_squares_neon, ect. As the WinRT platform is different from win32 > > or linux, so I need to test them one by one. > > I hope someone can help me, or work together. > > Thanks very much > > Best regards,Jesse > > > > Have you had a look through the tests provided by FFmpegs FATE ( > https://www.ffmpeg.org/fate.html)? > Also I noticed you converted the GNU arm assembly and created new code > files. What is the syntax difference between the 2? i.e. what had to be > changed. As it might be possible to just add some pre-processor macros to > allow the existing code to compile under the windows arm compiler. That way > 2 different source files dont need to be maintained for the exact same code. > > As of Windows 10, WinRT is deprecated, so it's kind of a waste of time dude > > > Without getting into how (not so)well the Windows RT tablets sold, but > Windows 10 apparently has a ARM build coming later next year and on > winphones ARM will be supported for a while. So windows on arm (previously > Windows RT) is not entirely dead. That said the windows run-time (WinRT) is > still used for apps in the metro store and is a focus of windows 10 as they > are unifying the app store across devices (pc,phone,xbox). So from a dev > point of view people really need to differentiate between Windows RT and > WinRT in discussions ;). > So from what I can tell Jesse is trying to support both arm under the > windows compiler and then then Windows store. Either of which could be > useful for ffmpeg on windows phone and for distributing apps in the windows > store (although win store support is a whole can of worms!). > ___ > 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] Move ffmpeg to WinRT
Hi JB, Haven't seen you for a long time. I have sent you email before to talk about the GCC compile for ARM-COFF. At that time, I know it is hard for GCC to do this, so I try to convert the assembly codes. If there is gas-preproc, it should be a better choice. Where can I find this script, is it open-source? Best regards,Jesse > Date: Mon, 17 Nov 2014 12:32:55 +0100 > From: j...@videolan.org > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] Move ffmpeg to WinRT > > On 17 Nov, Jesse Jiang wrote : > > I want to move ffmpeg to WinRT platform, like Windows Store and Windows > > Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style > > assembly codes to ARM-style codes. Also the codes are open-sourced, here > > https://github.com/qyljcy/FFmpeg > > Now this project can be compiled, but I didn't know if the assembly codes > > work well. > > This work is useless... > > FFmpeg can already be compiled on WinRT, with gas-preproc... > > -- > Jean-Baptiste Kempf > http://www.jbkempf.com/ - +33 672 704 734 > Sent from my Electronic Device > ___ > 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] Move ffmpeg to WinRT
On Tue, Nov 18, 2014 at 03:07:34AM +, Jesse Jiang wrote: > Hi JB, > Haven't seen you for a long time. I have sent you email before to talk about > the GCC compile for ARM-COFF. > At that time, I know it is hard for GCC to do this, so I try to convert the > assembly codes. If there is gas-preproc, it should be a better choice. > Where can I find this script, is it open-source? yes it is our variant of it is here: https://github.com/FFmpeg/gas-preprocessor [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/11] ffserver_config: cosmetic: simplify functions calls.
Looks Good. Feel free to push. Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/11] ffserver_config: cosmetic: move line_num into FFServerConfig
OK to push too. -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/11] ffserver_config: map ffserver options to AVOptions
Hi On 11/16/2014 11:03 PM, Lukasz Marek wrote: > On 17.11.2014 02:46, Lukasz Marek wrote: >> Signed-off-by: Lukasz Marek >> --- >> ffserver_config.c | 237 >> -- >> ffserver_config.h | 2 - >> 2 files changed, 69 insertions(+), 170 deletions(-) > > @Reynaldo, you may check the test I submitted, and the comments, you may > then have just high level review, not bother if mapping between options > is ok Will do. Thanks for the hint. I should be able to take a look at this and the rest of the changes tomorrow. Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Move ffmpeg to WinRT
Thanks Micheal Date: Tue, 18 Nov 2014 04:56:56 +0100 From: michae...@gmx.at To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] Move ffmpeg to WinRT On Tue, Nov 18, 2014 at 03:07:34AM +, Jesse Jiang wrote: > Hi JB, > Haven't seen you for a long time. I have sent you email before to talk about > the GCC compile for ARM-COFF. > At that time, I know it is hard for GCC to do this, so I try to convert the > assembly codes. If there is gas-preproc, it should be a better choice. > Where can I find this script, is it open-source? yes it is our variant of it is here: https://github.com/FFmpeg/gas-preprocessor [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes ___ 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] lavf/ffmenc: fix memleak in ffm_write_header
Regression since 745730c9c208c40f800d5d71ffa39aceab6ce044.
The dynamic buffer was not being used or freed.
Signed-off-by: James Almer
---
libavformat/ffmenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/ffmenc.c b/libavformat/ffmenc.c
index b717813..c64c26b 100644
--- a/libavformat/ffmenc.c
+++ b/libavformat/ffmenc.c
@@ -217,8 +217,6 @@ static int ffm_write_header(AVFormatContext *s)
avio_write(pb, codec->extradata, codec->extradata_size);
}
write_header_chunk(s->pb, pb, MKBETAG('C', 'O', 'M', 'M'));
-if(avio_open_dyn_buf(&pb) < 0)
-return AVERROR(ENOMEM);
/* specific info */
switch(codec->codec_type) {
case AVMEDIA_TYPE_VIDEO:
--
2.1.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
