Re: [FFmpeg-devel] HAP QuickTime codec support
On Sat, 15 Nov 2014 12:34:57 +0100 Reimar Döffinger reimar.doeffin...@gmx.de 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 bzk0...@aol.com ___ 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 jessejiang0...@outlook.com 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 jessejiang0...@outlook.com 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 rjvber...@gmail.com 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 bzk0...@aol.com ___ 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 lukasz.m.lu...@gmail.com
---
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 lukasz.m.lu...@gmail.com --- 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 michae...@gmx.at 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 lukasz.m.lu...@gmail.com --- 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
Re: [FFmpeg-devel] use openh264 in ffmpeg
On Mon, Nov 17, 2014 at 1:18 AM, 王山而 she...@live.cn 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] [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 michae...@gmx.at --- 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] 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 jessejiang0...@outlook.com 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 lukasz.m.lu...@gmail.com
---
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 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 lukasz.m.lu...@gmail.com --- 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 jamr...@gmail.com
---
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
