Re: [FFmpeg-devel] [PATCH] fate: Test pullup and fieldmatch with 5 instead of 1 frame
On Mon, May 11, 2015 at 07:34:11AM +0200, Clément Bœsch wrote: On Mon, May 11, 2015 at 12:44:14AM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- tests/fate-run.sh|3 ++- tests/fate/filter-video.mak |4 ++-- tests/ref/fate/filter-pixfmts-fieldmatch | 10 +- tests/ref/fate/filter-pixfmts-pullup | 24 4 files changed, 21 insertions(+), 20 deletions(-) Hum, 5 frames test with telecine... I'd really go for more. ok, how many frames should we use ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
On Mon, May 11, 2015 at 12:38:46PM +0800, 周晓勇 wrote: From 9837274dcee5e1900160901cf28d883246a7ecfb Mon Sep 17 00:00:00 2001 From: Zhou Xiaoyong zhouxiaoy...@loongson.cn Date: Mon, 11 May 2015 03:28:52 -0400 Subject: [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. 2.Option -mhard-float has been added. Signed-off-by: Zhou Xiaoyong zhouxiaoy...@loongson.cn --- configure |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 1b41367..7716e66 100755 --- a/configure +++ b/configure @@ -3937,7 +3937,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags=-march=$cpu ;; generic) disable mips32r5 @@ -4691,7 +4690,7 @@ elif enabled mips; then if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags -mips64r2 add_asflags -mips64r2 -elif enabled mips64 enabled mipsfpu; then +elif enabled mips64 enabled mipsfpu disabled loongson3; then this breaks build on mips: CC libavcodec/ac3dec_fixed.o In file included from ffmpeg/libavcodec/ac3dec_fixed.c:169: ffmpeg/libavcodec/ac3dec.c: In function ‘ac3_decode_init’: ffmpeg/libavcodec/ac3dec.c:213: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) ffmpeg/libavcodec/ac3dec.c:215: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) /tmp/ccgKabta.s: Assembler messages: /tmp/ccgKabta.s:5229: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dmult $25,$24' /tmp/ccgKabta.s:5231: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dsrl $25,$25,32' [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/subtitles: Use size_t for len
On Mon, May 11, 2015 at 07:30:53AM +0200, Clément Bœsch wrote:
On Sun, May 10, 2015 at 03:38:40PM +0200, Michael Niedermayer wrote:
string length could theoretically be larger than int
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/subtitles.c |4 ++--
libavformat/subtitles.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 67624fc..5bdbc8d 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -109,7 +109,7 @@ int ff_text_peek_r8(FFTextReader *r)
}
AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
-const uint8_t *event, int len, int
merge)
+const uint8_t *event, size_t len, int
merge)
{
AVPacket *subs, *sub;
@@ -303,7 +303,7 @@ int ff_smil_extract_next_text_chunk(FFTextReader *tr,
AVBPrint *buf, char *c)
const char *ff_smil_get_attr_ptr(const char *s, const char *attr)
{
int in_quotes = 0;
-const int len = strlen(attr);
+const size_t len = strlen(attr);
while (*s) {
while (*s) {
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index eb719ea..885285c 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -116,7 +116,7 @@ typedef struct {
* previous one instead of adding a new entry, 0 otherwise
*/
AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
-const uint8_t *event, int len, int
merge);
+const uint8_t *event, size_t len, int
merge);
/**
* Set missing durations and sort subtitles by PTS, and then byte position.
LGTM
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffserver jpg patch
On Sun, 10 May 2015 22:31:27 -0600 ill illumil...@gmail.com wrote: It applies for me. Konsole output $ patch -p1 patching.patch patching file ffserver.c patching file ffserver_config.c patching file ffserver_config.h Hunk #1 succeeded at 79 with fuzz 1. patching file libavformat/allformats.c patching file libavformat/rawenc.c I also ran git format-patch -1 on it: Konsole output $ git format-patch -1 patching.patch ill@compy:~/ffmpeggitmod$ and that worked without issue. You are supposed to send this patch instead of your broken manual patch. Or is michaelni supposed to fix your broken patch by hand? I'm sure you don't actually want to torture him. I still haven't gotten a reply about the author. Can I just set the author as anybody or does it have to be someone specific? The author field is for attribution and copyright. It should have the correct name, whatever that is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
On Mon, 11 May 2015 13:17:16 +0200 Nicolas George geo...@nsup.org wrote: Le duodi 22 floréal, an CCXXIII, James Almer a écrit : If this is meant to solve the whole debate from the Tell users about -use_absolute_path thread, then i think it's a bit overkill. Set AVOption to value is generic enough that works in any situation, be it for API user or ffmpeg.c, and could be used in every av_log message. I concur. Also, note that the object that requires the option is given as context to the log callback, therefore it is possible to know, programatically, if the option is needed for a muxer, demuxer, decoder, protocol, etc. This doesn't work because the log callback is process-global. There may be multiple independent ffmpeg users in the same process. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
On Mon, May 11, 2015 at 12:41:51PM +0800, 周晓勇 wrote: From 3d5a9d0d38c96d6b6ec51b082102f3a231b5b881 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Mon, 11 May 2015 09:27:00 +0800 Subject: [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1 Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- libavcodec/mips/Makefile |4 + libavcodec/mips/mpegvideo_init.c | 44 +++ libavcodec/mips/mpegvideo_loongson.c | 563 ++ why are the optimized functions and the code that sets them in the context in 2 seperate files ? this seems unneccesarily complicated [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
On Mon, May 11, 2015 at 02:16:15PM +0200, Michael Niedermayer wrote: On Mon, May 11, 2015 at 02:26:24AM -0300, James Almer wrote: On 10/05/15 10:18 PM, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/opt.c | 32 libavutil/opt.h | 21 + 2 files changed, 53 insertions(+) If this is meant to solve the whole debate from the Tell users about -use_absolute_path thread, then i think it's a bit overkill. yes i felt similarly, but Set AVOption to value is generic enough that works in any situation, be it for API user or ffmpeg.c, and could be used in every av_log message. it works, but it does not work well consider the normal/generic case of a user application using libavcodec and maybe libavformat amongth probably other libs the user sees a message saying something along the lines of: to do this set option foo to bar The user most likly does not know that this message comes from libavcodec or libavformat, another lib or the application itself and likely the user doesnt even know the difference anyway but the way to set the option can and does sometimes depend on for what the option is in mplayer, its one of -lavdopts o=XXX=YYY -lavcopts o=XXX=YYY -lavfopts o=XXX=YYY -lavdopts XXX=YYY -lavcopts XXX=YYY -lavfopts XXX=YYY in ffmpeg/ffplay/ffprobe its -XXX YYY then theres --demuxer-lavf-o=XXX=YYY and many more also the message may originate from a libavcodec used by another lib instead of the user application I think the average user would benefit from having the option dispayed with a exactly useable as is syntax I support this as well. No opinion on the API itself. -- Clément B. pgpMR5kDw8AoD.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
Le duodi 22 floréal, an CCXXIII, James Almer a écrit : If this is meant to solve the whole debate from the Tell users about -use_absolute_path thread, then i think it's a bit overkill. Set AVOption to value is generic enough that works in any situation, be it for API user or ffmpeg.c, and could be used in every av_log message. I concur. Also, note that the object that requires the option is given as context to the log callback, therefore it is possible to know, programatically, if the option is needed for a muxer, demuxer, decoder, protocol, etc. 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 1/4] avutil: add av_format_option_for_user() callback system
Le duodi 22 floréal, an CCXXIII, wm4 a écrit : This doesn't work because the log callback is process-global. There may be multiple independent ffmpeg users in the same process. Please do not pollute the discussion with a completely unrelated issue. 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 1/4] avutil: add av_format_option_for_user() callback system
On Mon, May 11, 2015 at 02:26:24AM -0300, James Almer wrote: On 10/05/15 10:18 PM, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/opt.c | 32 libavutil/opt.h | 21 + 2 files changed, 53 insertions(+) If this is meant to solve the whole debate from the Tell users about -use_absolute_path thread, then i think it's a bit overkill. yes i felt similarly, but Set AVOption to value is generic enough that works in any situation, be it for API user or ffmpeg.c, and could be used in every av_log message. it works, but it does not work well consider the normal/generic case of a user application using libavcodec and maybe libavformat amongth probably other libs the user sees a message saying something along the lines of: to do this set option foo to bar The user most likly does not know that this message comes from libavcodec or libavformat, another lib or the application itself and likely the user doesnt even know the difference anyway but the way to set the option can and does sometimes depend on for what the option is in mplayer, its one of -lavdopts o=XXX=YYY -lavcopts o=XXX=YYY -lavfopts o=XXX=YYY -lavdopts XXX=YYY -lavcopts XXX=YYY -lavfopts XXX=YYY in ffmpeg/ffplay/ffprobe its -XXX YYY then theres --demuxer-lavf-o=XXX=YYY and many more also the message may originate from a libavcodec used by another lib instead of the user application I think the average user would benefit from having the option dispayed with a exactly useable as is syntax [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- 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 1/4] avutil: add av_format_option_for_user() callback system
Le duodi 22 floréal, an CCXXIII, Clement Boesch a écrit : also the message may originate from a libavcodec used by another lib instead of the user application I think the average user would benefit from having the option dispayed with a exactly useable as is syntax I support this as well. No opinion on the API itself. Theoretically, that is true. In practice, there are dozens of things that would benefit the user in this area. The most obvious one is of course: having the error message in their native tongue instead of English. There is a hard design problem in the error reporting mechanism. The issue that lead to this discussion is the tip of the iceberg. Not even that, is is just a tiny ice peak near the surface amongst dozens of similar and more pressing issues. We are only discussing it because someone had too much free time this week-end and decided to bikeshed Carl Eugen's wording. Attacking the issues one at a time and addressing them the quick-and-dirty way will only make it that much harder to overhaul the system cleanly. So the real question is: is the benefit worth the cost? The benefit here is: in a few fringe cases, avoid users who do not know it already to look in their application help system how to set a lavf option. Well, IMHO, no, the benefit is not worth the cost. Not by far. Of course, if someone comes up with an idea that really enhances the error reporting system that would, as a side effect, fix this negligible issue, I would wholeheartedly support it. But I am sorry to say that despite all my efforts, I have still not come up with a satisfactory solution for error reporting. Regards, -- Nicola 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 1/4] avutil: add av_format_option_for_user() callback system
On Mon, 11 May 2015 15:43:18 +0200 Nicolas George geo...@nsup.org wrote: The issue that lead to this discussion is the tip of the iceberg. Not even that, is is just a tiny ice peak near the surface amongst dozens of similar and more pressing issues. We are only discussing it because someone had too much free time this week-end and decided to bikeshed Carl Eugen's wording. Please, your pathetic trolling is just bothersome. (Was this good enough?) I think this whole issue makes a pretty strong case for not adding more ffmpeg.c application specifics to the library. What I feel here is that some folks don't care about anything that isn't ffmpeg.c though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
On Mon, May 11, 2015 at 03:43:18PM +0200, Nicolas George wrote: Le duodi 22 floréal, an CCXXIII, Clement Boesch a écrit : also the message may originate from a libavcodec used by another lib instead of the user application I think the average user would benefit from having the option dispayed with a exactly useable as is syntax I support this as well. No opinion on the API itself. Theoretically, that is true. In practice, there are dozens of things that would benefit the user in this area. The most obvious one is of course: having the error message in their native tongue instead of English. There is a hard design problem in the error reporting mechanism. The issue that lead to this discussion is the tip of the iceberg. Not even that, is is just a tiny ice peak near the surface amongst dozens of similar and more pressing issues. We are only discussing it because someone had too much free time this week-end and decided to bikeshed Carl Eugen's wording. Attacking the issues one at a time and addressing them the quick-and-dirty way will only make it that much harder to overhaul the system cleanly. does someone intend to actually work on a overhaul and is such overhaul actually wanted and usefull, what would it involve? is it likely that such overhaul would also fix the issue of user application specific option translation? if noone will ever do an overhaul then its a fairly bad idea to wait for it So the real question is: is the benefit worth the cost? The benefit here is: in a few fringe cases, avoid users who do not know it already to look in their application help system how to set a lavf option. this assumes it is documented, that they know where or for what to search and that they find it. as a quick test one could ask a random user to find the page in each projects documentation from the error message this thread is about. That is the documentation of mplayer, mpv, vlc and gstreamer just to pick some random apps and look at the clock how much time that did cost to find also their subjective oppinon would be interresting to hear if they consider it worth it to instead print directly usable syntax Well, IMHO, no, the benefit is not worth the cost. Not by far. Of course, if someone comes up with an idea that really enhances the error reporting system that would, as a side effect, fix this negligible issue, I would wholeheartedly support it. But I am sorry to say that despite all my efforts, I have still not come up with a satisfactory solution for error reporting. Regards, -- Nicola George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
On Mon, 11 May 2015 17:06:50 +0200 Michael Niedermayer michae...@gmx.at wrote: On Mon, May 11, 2015 at 03:43:18PM +0200, Nicolas George wrote: Le duodi 22 floréal, an CCXXIII, Clement Boesch a écrit : also the message may originate from a libavcodec used by another lib instead of the user application I think the average user would benefit from having the option dispayed with a exactly useable as is syntax I support this as well. No opinion on the API itself. Theoretically, that is true. In practice, there are dozens of things that would benefit the user in this area. The most obvious one is of course: having the error message in their native tongue instead of English. There is a hard design problem in the error reporting mechanism. The issue that lead to this discussion is the tip of the iceberg. Not even that, is is just a tiny ice peak near the surface amongst dozens of similar and more pressing issues. We are only discussing it because someone had too much free time this week-end and decided to bikeshed Carl Eugen's wording. Attacking the issues one at a time and addressing them the quick-and-dirty way will only make it that much harder to overhaul the system cleanly. does someone intend to actually work on a overhaul and is such overhaul actually wanted and usefull, what would it involve? is it likely that such overhaul would also fix the issue of user application specific option translation? if noone will ever do an overhaul then its a fairly bad idea to wait for it In Libav there are plans to make the av_log callback non-global. Then your current patch might be helpful. I don't think it's feasible to solve this problem perfectly, as a certain someone else is suggesting. This would cause lots of complexity for little gain. The correct solution in this specific case is IMHO requiring the API user to provide a callback for opening further files, instead of somehow hardcoding lots of policy in libavformat (and then adding options and log messages to allow the user to interact with it). If you want a quick and dirty solution, I'd at least word it like set the libavformat use_absolute_path option to 1. So the real question is: is the benefit worth the cost? The benefit here is: in a few fringe cases, avoid users who do not know it already to look in their application help system how to set a lavf option. this assumes it is documented, that they know where or for what to search and that they find it. as a quick test one could ask a random user to find the page in each projects documentation from the error message this thread is about. That is the documentation of mplayer, mpv, vlc and gstreamer just to pick some random apps and look at the clock how much time that did cost to find also their subjective oppinon would be interresting to hear if they consider it worth it to instead print directly usable syntax Well, IMHO, no, the benefit is not worth the cost. Not by far. Of course, if someone comes up with an idea that really enhances the error reporting system that would, as a side effect, fix this negligible issue, I would wholeheartedly support it. But I am sorry to say that despite all my efforts, I have still not come up with a satisfactory solution for error reporting. Regards, -- Nicola George ___ 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] avcodec/libx265: use x265 Multi-library Interface to query the API
On 5/11/2015 5:57 AM, Gopu Govindaswamy wrote: Thanks for review, Do i need to send a new patch or this patch itself can move into ffmpeg repo? I fixed and pushed it. I was out of the country for a few days, hence the delay. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] id3v2: catch avio_read errors in check_tag
Since len is an unsigned int, the comparison is currently treated as unsigned and thus ignores all errors from avio_read. Thus cast len to int, which is unproblematic, because at that point len is between 0 and 4. This fixes 'Conditional jump or move depends on uninitialised value' valgrind warnings in is_tag. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavformat/id3v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c index 49a4c38..2289bfc 100644 --- a/libavformat/id3v2.c +++ b/libavformat/id3v2.c @@ -205,7 +205,7 @@ static int check_tag(AVIOContext *s, int offset, unsigned int len) if (len 4 || avio_seek(s, offset, SEEK_SET) 0 || -avio_read(s, tag, len) len) +avio_read(s, tag, len) (int)len) return -1; else if (!AV_RB32(tag) || is_tag(tag, len)) return 1; -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] id3v2: catch avio_read errors in check_tag
On Mon, May 11, 2015 at 08:07:49PM +0200, Andreas Cadhalpun wrote: Since len is an unsigned int, the comparison is currently treated as unsigned and thus ignores all errors from avio_read. Thus cast len to int, which is unproblematic, because at that point len is between 0 and 4. This fixes 'Conditional jump or move depends on uninitialised value' valgrind warnings in is_tag. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
Currently video_dst_bufsize is used, which is set to the return value
of av_image_alloc, but this is the combined size of all planes.
Only the first plane is written in fwrite.
The size of the first plane is the product of video_dst_linesize[0] and
height.
This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
doc/examples/demuxing_decoding.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index feeeb96..81c8a92 100644
--- a/doc/examples/demuxing_decoding.c
+++ b/doc/examples/demuxing_decoding.c
@@ -47,7 +47,6 @@ static FILE *audio_dst_file = NULL;
static uint8_t *video_dst_data[4] = {NULL};
static int video_dst_linesize[4];
-static int video_dst_bufsize;
static int video_stream_idx = -1, audio_stream_idx = -1;
static AVFrame *frame = NULL;
@@ -109,7 +108,7 @@ static int decode_packet(int *got_frame, int cached)
pix_fmt, width, height);
/* write to rawvideo file */
-fwrite(video_dst_data[0], 1, video_dst_bufsize, video_dst_file);
+fwrite(video_dst_data[0], 1, video_dst_linesize[0] * height,
video_dst_file);
}
} else if (pkt.stream_index == audio_stream_idx) {
/* decode audio frame */
@@ -290,7 +289,6 @@ int main (int argc, char **argv)
fprintf(stderr, Could not allocate raw video buffer\n);
goto end;
}
-video_dst_bufsize = ret;
}
if (open_codec_context(audio_stream_idx, fmt_ctx, AVMEDIA_TYPE_AUDIO) =
0) {
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add callback for opening further files
On Mon, May 11, 2015 at 06:12:25PM +0200, wm4 wrote:
On Mon, 11 May 2015 17:55:57 +0200
Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/avformat.h |6 ++
libavformat/utils.c|1 +
2 files changed, 7 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 339ff52..2e840a7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1237,6 +1237,8 @@ typedef struct AVChapter {
typedef int (*av_format_control_message)(struct AVFormatContext *s, int
type,
void *data, size_t data_size);
+typedef int (*AVOpenCallback)(AVIOContext **s, const char *url, int flags,
+ const AVIOInterruptCB *int_cb, AVDictionary
**options);
/**
* The duration of a video can be estimated through various ways, and this
enum can be used
@@ -1780,6 +1782,8 @@ typedef struct AVFormatContext {
* Demuxing: Set by user.
*/
enum AVCodecID data_codec_id;
+
+int (*open_cb)(AVIOContext **s, const char *url, int flags, const
AVIOInterruptCB *int_cb, AVDictionary **options);
} AVFormatContext;
int av_format_get_probe_score(const AVFormatContext *s);
@@ -1797,6 +1801,8 @@ void *av_format_get_opaque(const AVFormatContext
*s);
void av_format_set_opaque(AVFormatContext *s, void *opaque);
av_format_control_message av_format_get_control_message_cb(const
AVFormatContext *s);
void av_format_set_control_message_cb(AVFormatContext *s,
av_format_control_message callback);
+AVOpenCallback av_format_get_open_cb(const AVFormatContext *s);
+void av_format_set_open_cb(AVFormatContext *s, AVOpenCallback
callback);
/**
* This function will cause global side data to be injected in the next
packet
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d1f1d09..db2b4f6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -112,6 +112,7 @@ MAKE_ACCESSORS(AVFormatContext, format, AVCodec *,
data_codec)
MAKE_ACCESSORS(AVFormatContext, format, int, metadata_header_padding)
MAKE_ACCESSORS(AVFormatContext, format, void *, opaque)
MAKE_ACCESSORS(AVFormatContext, format, av_format_control_message,
control_message_cb)
+MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
int64_t av_stream_get_end_pts(const AVStream *st)
{
Looks almost good. I think the callback should have the AVFormatContext
as a parameter.
changed
Is there a context field in AVFormatContext for free
use by the API user? If not, an opaque context parameter for the
callback set by av_format_set_open_cb() is also good.
theres AVFormatContext.opaque, which i belive can be used
bumped version, added APIChanges entry
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: Use open_cb() if set
On Mon, May 11, 2015 at 05:55:58PM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavformat/mov.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
On Mon, May 11, 2015 at 03:18:16AM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/opt.c | 32 libavutil/opt.h | 21 + 2 files changed, 53 insertions(+) The open_cb() patch reduces the need for this in relation for opening URLs but theres still a large number of other references to options throughout the code in log messages which are unrelated to opening files. Thus the issue that this patchset would resolves is still there theres code pointing to at least -strict -1, thread_type, coder, qscale, crf, profile, sub_charenc, threads, mb_info, password, ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/img2dec: add option to disable pattern matching
Signed-off-by: Marton Balint c...@passwd.hu
---
doc/demuxers.texi | 4
libavformat/img2.h| 3 ++-
libavformat/img2dec.c | 9 ++---
libavformat/version.h | 2 +-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 3f7c45e..b7ddebb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -258,6 +258,10 @@ Select the pattern type used to interpret the provided
filename.
@var{pattern_type} accepts one of the following values.
@table @option
+@item none
+Disable pattern matching, therefore the video will only contain the specified
+image. You should use this option if you do not want to create sequences from
+multiple images and your filenames may contain special pattern characters.
@item sequence
Select a sequence pattern type, used to specify a sequence of files
indexed by sequential numbers.
diff --git a/libavformat/img2.h b/libavformat/img2.h
index e4bcb26..f6b9dd9 100644
--- a/libavformat/img2.h
+++ b/libavformat/img2.h
@@ -33,7 +33,8 @@
enum PatternType {
PT_GLOB_SEQUENCE,
PT_GLOB,
-PT_SEQUENCE
+PT_SEQUENCE,
+PT_NONE
};
typedef struct VideoDemuxData {
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index ba29110..0830f00 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -177,7 +177,7 @@ static int img_read_probe(AVProbeData *p)
int ff_img_read_header(AVFormatContext *s1)
{
VideoDemuxData *s = s1-priv_data;
-int first_index, last_index;
+int first_index = 1, last_index = 1;
AVStream *st;
enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE;
@@ -282,7 +282,7 @@ int ff_img_read_header(AVFormatContext *s1)
is not supported by this libavformat build\n);
return AVERROR(ENOSYS);
#endif
-} else if (s-pattern_type != PT_GLOB_SEQUENCE) {
+} else if (s-pattern_type != PT_GLOB_SEQUENCE s-pattern_type !=
PT_NONE) {
av_log(s1, AV_LOG_ERROR,
Unknown value '%d' for pattern_type option\n,
s-pattern_type);
return AVERROR(EINVAL);
@@ -377,7 +377,9 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
}
if (s-img_number s-img_last)
return AVERROR_EOF;
-if (s-use_glob) {
+if (s-pattern_type == PT_NONE) {
+av_strlcpy(filename_bytes, s-path, sizeof(filename_bytes));
+} else if (s-use_glob) {
#if HAVE_GLOB
filename = s-globstate.gl_pathv[s-img_number];
#endif
@@ -538,6 +540,7 @@ const AVOption ff_img_options[] = {
{ glob_sequence,select glob/sequence pattern type, 0,
AV_OPT_TYPE_CONST, {.i64=PT_GLOB_SEQUENCE}, INT_MIN, INT_MAX, DEC,
pattern_type },
{ glob, select glob pattern type,0,
AV_OPT_TYPE_CONST, {.i64=PT_GLOB }, INT_MIN, INT_MAX, DEC,
pattern_type },
{ sequence, select sequence pattern type,0,
AV_OPT_TYPE_CONST, {.i64=PT_SEQUENCE }, INT_MIN, INT_MAX, DEC,
pattern_type },
+{ none, disable pattern matching,0,
AV_OPT_TYPE_CONST, {.i64=PT_NONE }, INT_MIN, INT_MAX, DEC,
pattern_type },
{ pixel_format, set video pixel format,
OFFSET(pixel_format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
{ start_number, set first number in the sequence,
OFFSET(start_number), AV_OPT_TYPE_INT,{.i64 = 0 }, INT_MIN, INT_MAX, DEC
},
diff --git a/libavformat/version.h b/libavformat/version.h
index 071fe5d..e16d316 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
#define LIBAVFORMAT_VERSION_MAJOR 56
#define LIBAVFORMAT_VERSION_MINOR 33
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
-原始邮件- 发件人: Michael Niedermayer michae...@gmx.at 发送时间: 2015年5月11日 星期一 收件人: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org 抄送: 主题: Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1 On Mon, May 11, 2015 at 12:41:51PM +0800, 周晓勇 wrote: From 3d5a9d0d38c96d6b6ec51b082102f3a231b5b881 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Mon, 11 May 2015 09:27:00 +0800 Subject: [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1 Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- libavcodec/mips/Makefile |4 + libavcodec/mips/mpegvideo_init.c | 44 +++ libavcodec/mips/mpegvideo_loongson.c | 563 ++ why are the optimized functions and the code that sets them in the context in 2 seperate files ? this seems unneccesarily complicated i case mipstec optimize the same functions of mpegvideodec using msa they could use filename mpegviedo_mips.c and write init functions into mpegvideo_init.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
On Tue, May 12, 2015 at 10:32:19AM +0800, 周晓勇 wrote: -原始邮件- 发件人: Michael Niedermayer michae...@gmx.at 发送时间: 2015年5月11日 星期一 收件人: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org 抄送: 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags On Mon, May 11, 2015 at 12:38:46PM +0800, 周晓勇 wrote: From 9837274dcee5e1900160901cf28d883246a7ecfb Mon Sep 17 00:00:00 2001 From: Zhou Xiaoyong zhouxiaoy...@loongson.cn Date: Mon, 11 May 2015 03:28:52 -0400 Subject: [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. 2.Option -mhard-float has been added. Signed-off-by: Zhou Xiaoyong zhouxiaoy...@loongson.cn --- configure |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 1b41367..7716e66 100755 --- a/configure +++ b/configure @@ -3937,7 +3937,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags=-march=$cpu ;; generic) disable mips32r5 @@ -4691,7 +4690,7 @@ elif enabled mips; then if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags -mips64r2 add_asflags -mips64r2 -elif enabled mips64 enabled mipsfpu; then +elif enabled mips64 enabled mipsfpu disabled loongson3; then this breaks build on mips: CC libavcodec/ac3dec_fixed.o In file included from ffmpeg/libavcodec/ac3dec_fixed.c:169: ffmpeg/libavcodec/ac3dec.c: In function ‘ac3_decode_init’: ffmpeg/libavcodec/ac3dec.c:213: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) ffmpeg/libavcodec/ac3dec.c:215: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) /tmp/ccgKabta.s: Assembler messages: /tmp/ccgKabta.s:5229: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dmult $25,$24' /tmp/ccgKabta.s:5231: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dsrl $25,$25,32' [...] weird, i have no problem with this patch. all pass except some fate. ./configure --enable-gpl --cc='ccache gcc' --enable-pthreads --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a above was cross build for non loongson MIPS with mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5 it works before the patch but not afterwards after the patch HAVE_LOONGSON3=yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffserver jpg patch
I attached the file made by Konsole output git commit -p and then the
format patch command.
I wrote that caligula person as the author because he was the one who
posted the modified code stuff that I used.
On Mon, May 11, 2015 at 05:02:34PM -0600, ill wrote:
That is what I sent. It is the same file. I have run the git
format-patch -1 on this as well, not that the command seems to do
anything to the patch file itself.
you would have to attach the file generated by git format-patch
also you of course first need to locally commit your changes
and set the commit message and author
see man git commit
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 5b681fdaf7971f841b84cfe06412c67ba417fb00 Mon Sep 17 00:00:00 2001
From: Caligula useraccount calig...@sarijopen.student.utwente.nl
Date: Mon, 11 May 2015 17:42:42 -0600
Subject: [PATCH] ffserver jpg patch
---
ffserver.c | 4
ffserver_config.c| 6 --
ffserver_config.h| 1 +
libavformat/allformats.c | 1 +
libavformat/rawenc.c | 12
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 4803b96..2b99241 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -967,6 +967,10 @@ static int handle_connection(HTTPContext *c)
/* close connection if trailer sent */
if (c-state == HTTPSTATE_SEND_DATA_TRAILER)
return -1;
+/* Check if it is a single jpeg frame 123 */
+if (c-stream-single_frame c-data_count c-cur_frame_bytes c-cur_frame_bytes 0) {
+close_connection(c);
+}
break;
case HTTPSTATE_RECEIVE_DATA:
/* no need to read if no events */
diff --git a/ffserver_config.c b/ffserver_config.c
index 017af48..06bd8ac 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -862,8 +862,10 @@ static int ffserver_parse_config_stream(FFServerConfig *config, const char *cmd,
} else {
stream-stream_type = STREAM_TYPE_LIVE;
/* JPEG cannot be used here, so use single frame MJPEG */
-if (!strcmp(arg, jpeg))
-strcpy(arg, mjpeg);
+if (!strcmp(arg, jpeg)) {
+strcpy(arg, singlejpeg);
+stream-single_frame=1;
+}
stream-fmt = ffserver_guess_format(arg, NULL, NULL);
if (!stream-fmt)
ERROR(Unknown Format: '%s'\n, arg);
diff --git a/ffserver_config.h b/ffserver_config.h
index bdeb3c9..1b12194 100644
--- a/ffserver_config.h
+++ b/ffserver_config.h
@@ -79,6 +79,7 @@ typedef struct FFServerStream {
int multicast_port; /* first port used for multicast */
int multicast_ttl;
int loop; /* if true, send the stream in loops (only meaningful if file) */
+char single_frame;/* only single frame */
/* feed specific */
int feed_opened; /* true if someone is writing to the feed */
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e6a9d01..2c78e39 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -273,6 +273,7 @@ void av_register_all(void)
REGISTER_MUXER (SEGMENT, stream_segment);
REGISTER_DEMUXER (SHORTEN, shorten);
REGISTER_DEMUXER (SIFF, siff);
+REGISTER_MUXER (SINGLEJPEG, singlejpeg);
REGISTER_DEMUXER (SLN, sln);
REGISTER_DEMUXER (SMACKER, smacker);
REGISTER_MUXDEMUX(SMJPEG, smjpeg);
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 9b77cdc..9f1fab7 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -250,6 +250,18 @@ AVOutputFormat ff_mjpeg_muxer = {
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
+
+AVOutputFormat ff_singlejpeg_muxer = {
+.name = singlejpeg,
+.long_name = NULL_IF_CONFIG_SMALL(JPEG single image),
+.mime_type = image/jpeg,
+.extensions= jpg,jpeg,
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_MJPEG,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+.write_header = force_one_stream,
+};
#endif
#if CONFIG_MLP_MUXER
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffserver jpg patch
On Mon, May 11, 2015 at 05:02:34PM -0600, ill wrote: That is what I sent. It is the same file. I have run the git format-patch -1 on this as well, not that the command seems to do anything to the patch file itself. you would have to attach the file generated by git format-patch also you of course first need to locally commit your changes and set the commit message and author see man git commit [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On Mon, May 11, 2015 at 11:34:32PM +0200, Andreas Cadhalpun wrote: Currently video_dst_bufsize is used, which is set to the return value of av_image_alloc, but this is the combined size of all planes. Only the first plane is written in fwrite. The size of the first plane is the product of video_dst_linesize[0] and height. This fixes 'Syscall param write(buf) points to uninitialised byte(s)' valgrind warnings. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- doc/examples/demuxing_decoding.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) this breaks demuxing_decoding with pixel formats that use more than 1 plane for example: doc/examples/demuxing_decoding lena255.jpg out.raw /dev/null Could not find audio stream in input file 'lena255.jpg' Input #0, image2, from 'lena255.jpg': Duration: 00:00:00.04, start: 0.00, bitrate: 3124 kb/s Stream #0:0: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 255x255, 25 tbr, 25 tbn, 25 tbc Demuxing video from file 'lena255.jpg' into 'out.raw' video_frame n:0 coded_n:0 pts:NOPTS Demuxing succeeded. Play the output video file with the command: ffplay -f rawvideo -pix_fmt yuvj444p -video_size 255x255 out.raw but the printed command line for ffplay does not work as the stored image is not containing teh chroma planes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On Mon, May 11, 2015 at 03:55:40PM -0700, Nick Lewycky wrote: On 8 May 2015 at 14:28, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 12:43:20PM -0700, Nick Lewycky wrote: On 8 May 2015 at 12:06, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compilerAnd if you decide that you don’t want to edit the hunk after all, simply delete everything in the file, save close it. Git will then abort the editing process and leave the hunk unchanged, returning you to
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 8 May 2015 at 14:28, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 12:43:20PM -0700, Nick Lewycky wrote: On 8 May 2015 at 12:06, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compilerAnd if you decide that you don’t want to edit the hunk after all, simply delete everything in the file, save close it. Git will then abort the editing process and leave the hunk unchanged, returning you to the standard selection. I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you
Re: [FFmpeg-devel] ffserver jpg patch
That is what I sent. It is the same file. I have run the git
format-patch -1 on this as well, not that the command seems to do
anything to the patch file itself.
On Sun, 10 May 2015 22:31:27 -0600
ill illumil...@gmail.com wrote:
It applies for me.
Konsole output
$ patch -p1 patching.patch
patching file ffserver.c
patching file ffserver_config.c
patching file ffserver_config.h
Hunk #1 succeeded at 79 with fuzz 1.
patching file libavformat/allformats.c
patching file libavformat/rawenc.c
I also ran git format-patch -1 on it:
Konsole output
$ git format-patch -1 patching.patch
ill@compy:~/ffmpeggitmod$
and that worked without issue.
You are supposed to send this patch instead of your broken manual
patch. Or is michaelni supposed to fix your broken patch by hand? I'm
sure you don't actually want to torture him.
I still haven't gotten a reply about the author. Can I just set the
author as anybody or does it have to be someone specific?
The author field is for attribution and copyright. It should have the
correct name, whatever that is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
diff -Nrup ffmpeg-git--orig/ffserver.c ffmpeg-git/ffserver.c
--- ffmpeg-git--orig/ffserver.c2015-03-16 20:25:48.0 +0100
+++ ffmpeg-git/ffserver.c2015-04-05 02:33:53.0 +0200
@@ -967,6 +967,10 @@ static int handle_connection(HTTPContext
/* close connection if trailer sent */
if (c-state == HTTPSTATE_SEND_DATA_TRAILER)
return -1;
+/* Check if it is a single jpeg frame 123 */
+if (c-stream-single_frame c-data_count c-cur_frame_bytes c-cur_frame_bytes 0) {
+close_connection(c);
+}
break;
case HTTPSTATE_RECEIVE_DATA:
/* no need to read if no events */
diff -Nrup ffmpeg-git--orig/ffserver_config.c
ffmpeg-git/ffserver_config.c
--- ffmpeg-git--orig/ffserver_config.c2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.c2015-04-05 02:33:53.0 +0200
@@ -862,8 +862,10 @@ static int ffserver_parse_config_stream(
} else {
stream-stream_type = STREAM_TYPE_LIVE;
/* JPEG cannot be used here, so use single frame MJPEG */
-if (!strcmp(arg, jpeg))
-strcpy(arg, mjpeg);
+if (!strcmp(arg, jpeg)) {
+strcpy(arg, singlejpeg);
+stream-single_frame=1;
+}
stream-fmt = ffserver_guess_format(arg, NULL, NULL);
if (!stream-fmt)
ERROR(Unknown Format: '%s'\n, arg);
diff -Nrup ffmpeg-git--orig/ffserver_config.h
ffmpeg-git/ffserver_config.h
--- ffmpeg-git--orig/ffserver_config.h2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.h2015-04-05 02:33:53.0 +0200
@@ -79,6 +79,7 @@ typedef struct FFServerStream {
int multicast_port; /* first port used for multicast */
int multicast_ttl;
int loop; /* if true, send the stream in loops (only meaningful if file) */
+char single_frame;/* only single frame */
/* feed specific */
int feed_opened; /* true if someone is writing to the
feed */
diff -Nrup ffmpeg-git--orig/libavformat/allformats.c
ffmpeg-git/libavformat/allformats.c
--- ffmpeg-git--orig/libavformat/allformats.c2015-03-16
20:25:52.0 +0100
+++ ffmpeg-git/libavformat/allformats.c2015-04-05
02:33:53.0 +0200
@@ -273,6 +273,7 @@ void av_register_all(void)
REGISTER_MUXER (SEGMENT, stream_segment);
REGISTER_DEMUXER (SHORTEN, shorten);
REGISTER_DEMUXER (SIFF, siff);
+REGISTER_MUXER (SINGLEJPEG, singlejpeg);
REGISTER_DEMUXER (SLN, sln);
REGISTER_DEMUXER (SMACKER, smacker);
REGISTER_MUXDEMUX(SMJPEG, smjpeg);
diff -Nrup ffmpeg-git--orig/libavformat/rawenc.c
ffmpeg-git/libavformat/rawenc.c
--- ffmpeg-git--orig/libavformat/rawenc.c2015-03-16
20:25:54.0 +0100
+++ ffmpeg-git/libavformat/rawenc.c2015-04-05$
02:33:53.0 +0200
@@ -250,6 +250,18 @@ AVOutputFormat ff_mjpeg_muxer = {
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
+
+AVOutputFormat ff_singlejpeg_muxer = {
+.name = singlejpeg,
+.long_name = NULL_IF_CONFIG_SMALL(JPEG single image),
+.mime_type = image/jpeg,
+.extensions= jpg,jpeg,
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_MJPEG,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+.write_header = force_one_stream,
+};
#endif
#if CONFIG_MLP_MUXER
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
-原始邮件- 发件人: Michael Niedermayer michae...@gmx.at 发送时间: 2015年5月11日 星期一 收件人: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org 抄送: 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags On Mon, May 11, 2015 at 12:38:46PM +0800, 周晓勇 wrote: From 9837274dcee5e1900160901cf28d883246a7ecfb Mon Sep 17 00:00:00 2001 From: Zhou Xiaoyong zhouxiaoy...@loongson.cn Date: Mon, 11 May 2015 03:28:52 -0400 Subject: [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. 2.Option -mhard-float has been added. Signed-off-by: Zhou Xiaoyong zhouxiaoy...@loongson.cn --- configure |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 1b41367..7716e66 100755 --- a/configure +++ b/configure @@ -3937,7 +3937,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags=-march=$cpu ;; generic) disable mips32r5 @@ -4691,7 +4690,7 @@ elif enabled mips; then if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags -mips64r2 add_asflags -mips64r2 -elif enabled mips64 enabled mipsfpu; then +elif enabled mips64 enabled mipsfpu disabled loongson3; then this breaks build on mips: CC libavcodec/ac3dec_fixed.o In file included from ffmpeg/libavcodec/ac3dec_fixed.c:169: ffmpeg/libavcodec/ac3dec.c: In function ‘ac3_decode_init’: ffmpeg/libavcodec/ac3dec.c:213: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) ffmpeg/libavcodec/ac3dec.c:215: warning: ‘request_channels’ is deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) /tmp/ccgKabta.s: Assembler messages: /tmp/ccgKabta.s:5229: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dmult $25,$24' /tmp/ccgKabta.s:5231: Error: opcode not supported on this processor: mips32r2 (mips32r2) `dsrl $25,$25,32' [...] weird, i have no problem with this patch. all pass except some fate. ./configure --enable-gpl --cc='ccache gcc' --enable-pthreads --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a 1.when testing on FC19-O32 system, config.mak list as: CC_IDENT=gcc 4.8.3 (GCC) 20140624 (Red Hat 4.8.3-1) ARCH=mips CPPFLAGS= -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST CFLAGS= -march=loongson3a -std=c99 -fomit-frame-pointer -fPIC -mhard-float -pthread -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized CXXFLAGS= -D__STDC_CONSTANT_MACROS ASFLAGS= -march=loongson3a -fPIC -mhard-float -g ARCH_MIPS=yes !ARCH_MIPS64=yes HAVE_MIPSFPU=yes !HAVE_MIPS32R2=yes !HAVE_MIPS32R5=yes !HAVE_MIPS64R6=yes !HAVE_MIPSDSPR1=yes !HAVE_MIPSDSPR2=yes !HAVE_MSA=yes HAVE_LOONGSON3=yes !HAVE_ALIGNED_STACK=yes HAVE_FAST_64BIT=yes HAVE_FAST_CLZ=yes HAVE_FAST_CMOV=yes HAVE_LOCAL_ALIGNED_8=yes HAVE_LOCAL_ALIGNED_16=yes !HAVE_LOCAL_ALIGNED_32=yes HAVE_SIMD_ALIGN_16=yes 2.when testing on CentOS-N64 system, config.mak list as: CC_IDENT=gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-3.1) ARCH=mips CPPFLAGS= -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST CFLAGS= -march=loongson3a -std=c99 -fomit-frame-pointer -fPIC -mhard-float -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat CXXFLAGS= -D__STDC_CONSTANT_MACROS ASFLAGS= -march=loongson3a -fPIC -mhard-float -g ARCH_MIPS=yes ARCH_MIPS64=yes HAVE_MIPSFPU=yes !HAVE_MIPS32R2=yes !HAVE_MIPS32R5=yes !HAVE_MIPS64R6=yes !HAVE_MIPSDSPR1=yes !HAVE_MIPSDSPR2=yes !HAVE_MSA=yes HAVE_LOONGSON3=yes !HAVE_ALIGNED_STACK=yes HAVE_FAST_64BIT=yes HAVE_FAST_CLZ=yes HAVE_FAST_CMOV=yes
[FFmpeg-devel] [PATCH 1/2] avformat: add callback for opening further files
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/avformat.h |6 ++
libavformat/utils.c|1 +
2 files changed, 7 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 339ff52..2e840a7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1237,6 +1237,8 @@ typedef struct AVChapter {
typedef int (*av_format_control_message)(struct AVFormatContext *s, int type,
void *data, size_t data_size);
+typedef int (*AVOpenCallback)(AVIOContext **s, const char *url, int flags,
+ const AVIOInterruptCB *int_cb, AVDictionary
**options);
/**
* The duration of a video can be estimated through various ways, and this
enum can be used
@@ -1780,6 +1782,8 @@ typedef struct AVFormatContext {
* Demuxing: Set by user.
*/
enum AVCodecID data_codec_id;
+
+int (*open_cb)(AVIOContext **s, const char *url, int flags, const
AVIOInterruptCB *int_cb, AVDictionary **options);
} AVFormatContext;
int av_format_get_probe_score(const AVFormatContext *s);
@@ -1797,6 +1801,8 @@ void *av_format_get_opaque(const AVFormatContext *s);
void av_format_set_opaque(AVFormatContext *s, void *opaque);
av_format_control_message av_format_get_control_message_cb(const
AVFormatContext *s);
void av_format_set_control_message_cb(AVFormatContext *s,
av_format_control_message callback);
+AVOpenCallback av_format_get_open_cb(const AVFormatContext *s);
+void av_format_set_open_cb(AVFormatContext *s, AVOpenCallback callback);
/**
* This function will cause global side data to be injected in the next packet
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d1f1d09..db2b4f6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -112,6 +112,7 @@ MAKE_ACCESSORS(AVFormatContext, format, AVCodec *,
data_codec)
MAKE_ACCESSORS(AVFormatContext, format, int, metadata_header_padding)
MAKE_ACCESSORS(AVFormatContext, format, void *, opaque)
MAKE_ACCESSORS(AVFormatContext, format, av_format_control_message,
control_message_cb)
+MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
int64_t av_stream_get_end_pts(const AVStream *st)
{
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/mov: Use open_cb() if set
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/mov.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 0f63d22..02de755 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2602,6 +2602,11 @@ static void mov_build_index(MOVContext *mov, AVStream
*st)
static int mov_open_dref(MOVContext *c, AVIOContext **pb, const char *src,
MOVDref *ref,
AVIOInterruptCB *int_cb)
{
+AVOpenCallback open_func = c-fc-open_cb;
+
+if (!open_func)
+open_func = avio_open2;
+
/* try relative path, we do not try the absolute because it can leak
information about our
system to an attacker */
if (ref-nlvl_to 0 ref-nlvl_from 0 ref-path[0] != '/') {
@@ -2634,19 +2639,22 @@ static int mov_open_dref(MOVContext *c, AVIOContext
**pb, const char *src, MOVDr
av_strlcat(filename, ../, sizeof(filename));
av_strlcat(filename, ref-path + l + 1, sizeof(filename));
-if (!c-use_absolute_path)
+if (!c-use_absolute_path !c-fc-open_cb)
if(strstr(ref-path + l + 1, ..) || ref-nlvl_from 1)
return AVERROR(ENOENT);
if (strlen(filename) + 1 == sizeof(filename))
return AVERROR(ENOENT);
-if (!avio_open2(pb, filename, AVIO_FLAG_READ, int_cb, NULL))
+if (!open_func(pb, filename, AVIO_FLAG_READ, int_cb, NULL))
return 0;
}
} else if (c-use_absolute_path) {
av_log(c-fc, AV_LOG_WARNING, Using absolute path on user request,
this is a possible security issue\n);
-if (!avio_open2(pb, ref-path, AVIO_FLAG_READ, int_cb, NULL))
+if (!open_func(pb, ref-path, AVIO_FLAG_READ, int_cb, NULL))
+return 0;
+} else if (c-fc-open_cb) {
+if (!open_func(pb, ref-path, AVIO_FLAG_READ, int_cb, NULL))
return 0;
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add callback for opening further files
On Mon, 11 May 2015 17:55:57 +0200
Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/avformat.h |6 ++
libavformat/utils.c|1 +
2 files changed, 7 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 339ff52..2e840a7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1237,6 +1237,8 @@ typedef struct AVChapter {
typedef int (*av_format_control_message)(struct AVFormatContext *s, int type,
void *data, size_t data_size);
+typedef int (*AVOpenCallback)(AVIOContext **s, const char *url, int flags,
+ const AVIOInterruptCB *int_cb, AVDictionary
**options);
/**
* The duration of a video can be estimated through various ways, and this
enum can be used
@@ -1780,6 +1782,8 @@ typedef struct AVFormatContext {
* Demuxing: Set by user.
*/
enum AVCodecID data_codec_id;
+
+int (*open_cb)(AVIOContext **s, const char *url, int flags, const
AVIOInterruptCB *int_cb, AVDictionary **options);
} AVFormatContext;
int av_format_get_probe_score(const AVFormatContext *s);
@@ -1797,6 +1801,8 @@ void *av_format_get_opaque(const AVFormatContext
*s);
void av_format_set_opaque(AVFormatContext *s, void *opaque);
av_format_control_message av_format_get_control_message_cb(const
AVFormatContext *s);
void av_format_set_control_message_cb(AVFormatContext *s,
av_format_control_message callback);
+AVOpenCallback av_format_get_open_cb(const AVFormatContext *s);
+void av_format_set_open_cb(AVFormatContext *s, AVOpenCallback callback);
/**
* This function will cause global side data to be injected in the next
packet
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d1f1d09..db2b4f6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -112,6 +112,7 @@ MAKE_ACCESSORS(AVFormatContext, format, AVCodec *,
data_codec)
MAKE_ACCESSORS(AVFormatContext, format, int, metadata_header_padding)
MAKE_ACCESSORS(AVFormatContext, format, void *, opaque)
MAKE_ACCESSORS(AVFormatContext, format, av_format_control_message,
control_message_cb)
+MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
int64_t av_stream_get_end_pts(const AVStream *st)
{
Looks almost good. I think the callback should have the AVFormatContext
as a parameter. Is there a context field in AVFormatContext for free
use by the API user? If not, an opaque context parameter for the
callback set by av_format_set_open_cb() is also good.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
