The recently added apngdec code does not compile under msvc.
See:
http://fate.ffmpeg.org/report.cgi?time=20141122053145&slot=x86_32-msvc12-windows-native
Attached is a patch to fix it.
0001-lavf-fix-apngdec-under-msvc.patch
Description: Binary data
__
Hi,
On November 21, 2014 11:09:34 PM GMT+01:00, James Almer
wrote:
>Also use length and not stream position
>
>Signed-off-by: James Almer
>---
> libavformat/apngdec.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
>diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
>inde
Hi,
On November 21, 2014 11:09:33 PM GMT+01:00, James Almer
wrote:
>Signed-off-by: James Almer
>---
> libavformat/apngdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
>index 54fbd29..2af87ad 100644
>--- a/libavformat/apngdec.c
>+++ b/lib
On Fri, Nov 21, 2014 at 05:43:09PM -0800, Mark Reid wrote:
> Changes since v1:
> * renamed mxf_read_source_package -> mxf_read_package
>
> ---
> libavformat/mxfdec.c | 78
> +++-
> 1 file changed, 41 insertions(+), 37 deletions(-)
applied
thx
[.
Changes since v1:
* renamed mxf_read_source_package -> mxf_read_package
---
libavformat/mxfdec.c | 78 +++-
1 file changed, 41 insertions(+), 37 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fa0a2f4..cc740b5 100644
---
Copying context using dedicated function is safer that raw memcpy
which creates shallow copy.
Signed-off-by: Lukasz Marek
---
ffserver.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index e3e76ba..7e36ab1 100644
--- a/ffserver.c
+++ b/ffser
On Sat, Nov 22, 2014 at 09:23:43AM +0900, TOYAMA Shin-ichi wrote:
> ---
> doc/decoders.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much a
On Fri, Nov 21, 2014 at 1:25 AM, Tomas Härdin
wrote:
> On Tue, 2014-11-18 at 16:52 -0800, Mark Reid wrote:
> > ---
> > libavformat/mxfdec.c | 74
> +++-
> > 1 file changed, 39 insertions(+), 35 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c
On 21/11/14 8:05 AM, Benoit Fouet wrote:
> ---
> Changes:
> - do not reset decode_next_dat when decoding IDAT of fdAT
> - add configure part
> ---
Changelog entry?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinf
---
doc/decoders.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 2c920e7..01fca9f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -192,7 +192,7 @@ ee450d, 101010, eaeaea, 0ce60b, ec14ed, ebff0b, 0d617a,
7b7b7b, d1d1d1,
On 17.11.2014 02:46, Lukasz Marek wrote:
ffmenc will store recommended encoder configuration if present.
This will allow the user to base on local defaults and
apply only explicitly set options.
If recommended encoder configuration is not present, then
non-default context's options are stored.
On 18.11.2014 22:50, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
[..]
@@ -3355,6 +3354,9 @@ static int add_av_stream(FFServerStream *feed, AVStream
*st)
fst = add_av_stream1(feed, av, 0);
if (!fst)
return -1;
+if (av_stream_get_r
On 21.11.2014 23:17, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/20/2014 10:14 PM, Lukasz Marek wrote:
On 18.11.2014 21:35, Reynaldo H. Verdejo Pinochet wrote:
[...]
Also, please make an effort
to break lines at 80 chars as long as it doesn't make the
code harder to read. This seems particula
On 18.11.2014 21:44, Reynaldo H. Verdejo Pinochet wrote:
Hi Lukasz
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
[..]
@@ -174,13 +174,20 @@ void ffserver_parse_acl_row(FFServerStream *stream,
FFServerStream* feed,
}
/* add a codec and set the default parameters */
-static void add_codec(FFS
On 21.11.2014 16:31, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/20/2014 10:09 PM, Lukasz Marek wrote:
On 18.11.2014 23:25, Reynaldo H. Verdejo Pinochet wrote:
[..]
I do think undefined behavior should be avoided if possible
without too much hassle, so if we go with the former I would
appreci
On 18.11.2014 22:50, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
[..]
@@ -3355,6 +3354,9 @@ static int add_av_stream(FFServerStream *feed, AVStream
*st)
fst = add_av_stream1(feed, av, 0);
if (!fst)
return -1;
+if (av_stream_get_r
On 11/21/2014 07:17 PM, Reynaldo H. Verdejo Pinochet wrote:
> [..]
> suggestion many avid by.
s/avid by/follow/g
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi
On 11/20/2014 10:14 PM, Lukasz Marek wrote:
> On 18.11.2014 21:35, Reynaldo H. Verdejo Pinochet wrote:
> [...]
> Also, please make an effort
>> to break lines at 80 chars as long as it doesn't make the
>> code harder to read. This seems particularly possible on the
>> function declarations.
>
Also use length and not stream position
Signed-off-by: James Almer
---
libavformat/apngdec.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 2af87ad..ce62190 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec
Signed-off-by: James Almer
---
libavformat/apngdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 54fbd29..2af87ad 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -373,6 +373,7 @@ static int apng_read_packet(AVFormatCont
Le primidi 1er frimaire, an CCXXIII, Vadim Kalinsky a écrit :
> bprint.h can't be included in C++ code
> C++ does not support anonymous struct.
Thanks for the patch.
Basically, bprint.h is not meant to be included in c++ code.
> From a45cc83a807e7eabf158ddff52751171e80874f8 Mon Sep 17 00:00:00 2
Hi all
Its over 2 month since FFmpeg 2.4, so the next release is not far
away ...
If you want something in it or want something fixed dont wait too
long, though i dont plan to release it in the next week ...
Also if you want it to have a specific name, say so now, otherwise
ill pick something fr
C++ does not support anonymous struct.
0001-C-compatible-AVBPrint-definition.patch
Description: Binary data
Vadim Kalinsky
kalinsky.ru
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ffmpeg-devel mailing list
ffm
On Fri, Nov 21, 2014 at 12:05:47PM +0100, Benoit Fouet wrote:
> ---
> Changes:
> - do not reset decode_next_dat when decoding IDAT of fdAT
> - add configure part
> ---
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h
On Thu, Nov 20, 2014 at 03:07:18PM +0100, Benoit Fouet wrote:
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/apngdec.c| 409
> +++
> 3 files changed, 411 insertions(+)
> create mode 100644 libavformat/ap
On Fri, Nov 21, 2014 at 08:09:50AM -0500, compn wrote:
> On Fri, 21 Nov 2014 12:05:47 +0100
> Benoit Fouet wrote:
>
> > configure | 1 +
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/avcodec.h| 1 +
> > libavcodec/codec_desc.c |
Hi
On 11/20/2014 10:09 PM, Lukasz Marek wrote:
> On 18.11.2014 23:25, Reynaldo H. Verdejo Pinochet wrote:
>> [..]
>> I do think undefined behavior should be avoided if possible
>> without too much hassle, so if we go with the former I would
>> appreciate doc entries specifying the options preceden
On Fri, 21 Nov 2014 11:52:01 +0100
Alexis Ballier wrote:
> > No, this would imply that the pointer to the opaque data is in
> > AVFrame.data[3], and all other pointers are ignored. So you have
> > only 1 pointer. AVFrame.linesize has no meaning either in this case.
>
> this won't work with NV12(T
On Fri, 21 Nov 2014 12:05:47 +0100
Benoit Fouet wrote:
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 8 +++
> libavcodec/pngdec.c | 139
missing addition of apng to doc
---
Changes:
- do not reset decode_next_dat when decoding IDAT of fdAT
- add configure part
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 8 +++
libavcodec/pngdec.c | 139 +++
On Fri, 21 Nov 2014 11:23:49 +0100
wm4 wrote:
> > I didn't know such "opaque" things existed; it probably makes more
> > sense with it indeed.
> >
> > How should I do it ? add .flags = AV_PIX_FMT_FLAG_HWACCEL and be
> > done ? I would like to keep 'av_pix_fmt_count_planes()' working for
> > it at
On Fri, 21 Nov 2014 10:50:42 +0100
Jean-Baptiste Kempf wrote:
> > Now, if I want to use the fimc device to apply some effects I can't
> > because the decoder is magically using it behind my back.
>
> How is that relevant? Just block it.
Block what ? automatic conversion ? what fmt should i adver
On Fri, 21 Nov 2014 11:15:08 +0100
Alexis Ballier wrote:
> On Fri, 21 Nov 2014 10:51:52 +0100
> wm4 wrote:
>
> > On Fri, 21 Nov 2014 10:43:15 +0100
> > Alexis Ballier wrote:
> >
> > > On Fri, 21 Nov 2014 10:15:29 +0100
> > > Jean-Baptiste Kempf wrote:
> > >
> > > > On 21 Nov, Alexis Ballier
On Fri, 21 Nov 2014 10:51:52 +0100
wm4 wrote:
> On Fri, 21 Nov 2014 10:43:15 +0100
> Alexis Ballier wrote:
>
> > On Fri, 21 Nov 2014 10:15:29 +0100
> > Jean-Baptiste Kempf wrote:
> >
> > > On 21 Nov, Alexis Ballier wrote :
> > > > > So you have a format outputted that is of no use, except if
On Fri, 21 Nov 2014 10:43:15 +0100
Alexis Ballier wrote:
> On Fri, 21 Nov 2014 10:15:29 +0100
> Jean-Baptiste Kempf wrote:
>
> > On 21 Nov, Alexis Ballier wrote :
> > > > So you have a format outputted that is of no use, except if you
> > > > use the filter.
> > >
> > > On MFCv5 yes; I don't a
On 21 Nov, Alexis Ballier wrote :
> On Fri, 21 Nov 2014 10:38:37 +0100
> Jean-Baptiste Kempf wrote:
>
> > On 21 Nov, Alexis Ballier wrote :
> > > I think it's safe to assume that if you have a SOC with a HW dec
> > > that outputs only this insane and uncommon format, the SOC also has
> > > a HW f
On 21 Nov, Alexis Ballier wrote :
> On Fri, 21 Nov 2014 10:15:29 +0100
> Jean-Baptiste Kempf wrote:
>
> > On 21 Nov, Alexis Ballier wrote :
> > > > So you have a format outputted that is of no use, except if you
> > > > use the filter.
> > >
> > > On MFCv5 yes; I don't assume because I'm working
On Fri, 21 Nov 2014 10:38:37 +0100
Jean-Baptiste Kempf wrote:
> On 21 Nov, Alexis Ballier wrote :
> > I think it's safe to assume that if you have a SOC with a HW dec
> > that outputs only this insane and uncommon format, the SOC also has
> > a HW filter that can convert it.
>
> Then use this fi
On Fri, 21 Nov 2014 10:15:29 +0100
Jean-Baptiste Kempf wrote:
> On 21 Nov, Alexis Ballier wrote :
> > > So you have a format outputted that is of no use, except if you
> > > use the filter.
> >
> > On MFCv5 yes; I don't assume because I'm working on this that it is
> > the only one :)
>
> So, b
Hi,
- Mail original -
[...]
> I think it's safe to assume that if you have a SOC with a HW dec that
> outputs only this insane and uncommon format, the SOC also has a HW
> filter that can convert it.
This is a good argument IMHO.
On a side note, I don't think it would be that complicate
On 21 Nov, Alexis Ballier wrote :
> I think it's safe to assume that if you have a SOC with a HW dec that
> outputs only this insane and uncommon format, the SOC also has a HW
> filter that can convert it.
Then use this filter to output a standard format.
> > Sorry, but that's far from clear.
>
On Tue, 2014-11-18 at 16:52 -0800, Mark Reid wrote:
> ---
> libavformat/mxfdec.c | 74
> +++-
> 1 file changed, 39 insertions(+), 35 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index fa0a2f4..8c13c24 100644
> --- a/l
On Fri, 21 Nov 2014 10:02:36 +0100
Jean-Baptiste Kempf wrote:
> On 21 Nov, Alexis Ballier wrote :
> > > > How do you put this in an AVFrame then ?
> > >
> > > Preferably not at all. Is there a need to? Only the end result
> > > (nv12 I suppose) needs to be in an AVFrame.
> >
> > It can be done
On Sun, 2014-11-16 at 02:03 +0100, Carl Eugen Hoyos wrote:
> On Saturday 15 November 2014 11:57:00 pm Michael Niedermayer wrote:
> > On Sat, Nov 15, 2014 at 02:50:38AM +0100, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch fixes ticket #4107 for me.
> > > An alternative would be to for
On 21 Nov, Alexis Ballier wrote :
> > So you have a format outputted that is of no use, except if you use
> > the filter.
>
> On MFCv5 yes; I don't assume because I'm working on this that it is the
> only one :)
So, basically, noone can display it, reencode or do anything with it,
without the fil
On Fri, 21 Nov 2014 09:58:40 +0100
Jean-Baptiste Kempf wrote:
> On 21 Nov, Alexis Ballier wrote :
> > On Thu, 20 Nov 2014 18:40:18 +0100
> > Jean-Baptiste Kempf wrote:
> >
> > > On 20 Nov, Alexis Ballier wrote :
> > > > This is the only format supported by MFC5 HW decoders (e.g.
> > > > Samsung
On 21 Nov, Alexis Ballier wrote :
> > > How do you put this in an AVFrame then ?
> >
> > Preferably not at all. Is there a need to? Only the end result (nv12 I
> > suppose) needs to be in an AVFrame.
>
> It can be done but is ugly IMHO:
>
> - I was under the impression that lavc decoder conventi
On 21 Nov, Alexis Ballier wrote :
> On Thu, 20 Nov 2014 18:40:18 +0100
> Jean-Baptiste Kempf wrote:
>
> > On 20 Nov, Alexis Ballier wrote :
> > > This is the only format supported by MFC5 HW decoders (e.g. Samsung
> > > exynos 4412).
> >
> > Why not convert it to a normal format?
> >
>
> That
Hi,
- Mail original -
> On Thu, Nov 20, 2014 at 03:07:17PM +0100, Benoit Fouet wrote:
> > ---
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/avcodec.h| 1 +
> > libavcodec/codec_desc.c | 8 +++
> > libavcodec/pngdec.c | 142
> > ++
Hi,
- Mail original -
[...]
> ...in which I screw up and post the same patch. Here you go...
>
> From f06aa763f3e3593d12cc16d8017e796c9e5db3b3 Mon Sep 17 00:00:00
> 2001
> From: Rodger Combs
> Date: Thu, 20 Nov 2014 01:47:05 -0600
> Subject: [PATCH] dashenc: Add a segment_start_number
---
ffplay.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index f79161d..1914a66 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3169,8 +3169,9 @@ static int read_thread(void *arg)
stream_component_close(is, is->video_stream);
if (is->subtitle
On Fri, 21 Nov 2014 09:01:43 +0100
wm4 wrote:
> On Fri, 21 Nov 2014 08:45:47 +0100
> Alexis Ballier wrote:
>
> > On Thu, 20 Nov 2014 18:42:19 +0100
> > wm4 wrote:
> > > I think this should be rejected. It's far too special to be
> > > useful in general, and it's not even pixel- or line-address
On 20.11.2014, at 09:48, Jesse Jiang wrote:
> Hi Reimar,
> Because of Windows RT cannot use CryptographicBuffer or _beginthreadex API,
> so I try to use rand() instead of it, or we need to write own function
> instead of it. If we use WinRT api to instead of these apis, it will cause
> more bug
On Fri, 21 Nov 2014 08:45:47 +0100
Alexis Ballier wrote:
> On Thu, 20 Nov 2014 18:42:19 +0100
> wm4 wrote:
> > I think this should be rejected. It's far too special to be useful in
> > general, and it's not even pixel- or line-addressable (Z-shaped tiles,
> > seriously?). It's pretty much a raw
On 21.11.2014, at 07:44, Jesse Jiang wrote:
> Now, I find a function get_generic_seed()
> So, I use this function will work fine?
It is already used as fallback so I don't see why you'd have to change the code
at all.
> uint32_t av_get_random_seed(void){uint32_t seed;
> #if HAVE_CRYPTGENRAN
55 matches
Mail list logo
