On Monday 29 September 2014 01:22:38 am Carl Eugen Hoyos wrote:
Attached patch is the first part of the fix for ticket #1304.
New, tested patch attached.
Please comment, Carl Eugen
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 2eb2ae1..723e802 100644
---
On Monday 29 September 2014 01:30:44 am Carl Eugen Hoyos wrote:
Attached patch fixes ticket #1304: biSizeImage may be 0 for images with
codec tag 0, if the size is set too small, WMP refuses to play the file.
Patch with changes to fate attached.
Please comment, Carl Eugen
diff --git
Hi,
- Mail original -
On Monday 29 September 2014 01:22:38 am Carl Eugen Hoyos wrote:
Attached patch is the first part of the fix for ticket #1304.
New, tested patch attached.
Please comment, Carl Eugen
LGTM,
--
Ben
___
Hi,
- Mail original -
On Monday 29 September 2014 01:30:44 am Carl Eugen Hoyos wrote:
Attached patch fixes ticket #1304: biSizeImage may be 0 for images
with
codec tag 0, if the size is set too small, WMP refuses to play the
file.
Patch with changes to fate attached.
LGTM
Hi,
- Mail original -
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/utils.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index b27f918..9eb2b5b 100644
--- a/libavcodec/utils.c
+++
Hi,
- Mail original -
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/put_bits.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 8081fb9..f16d04a 100644
--- a/libavcodec/put_bits.h
At last I got back to this issue.
First I thought of adding such new error codes:
#define AVERROR_BAD_REQUESTFFERRTAG(0xF8,'4','0','0') ///
Remote server returns 400 Bad Request reply
#define AVERROR_AUTH_FAILEDFFERRTAG(0xF8,'4','0','1') ///
Unauthorized by remote server
#define
On Mon, Sep 29, 2014 at 09:33:16AM +0200, Carl Eugen Hoyos wrote:
On Monday 29 September 2014 01:22:38 am Carl Eugen Hoyos wrote:
Attached patch is the first part of the fix for ticket #1304.
New, tested patch attached.
Please comment, Carl Eugen
riffenc.c |5 -
1 file
On Mon, Sep 29, 2014 at 09:59:21AM +0200, Benoit Fouet wrote:
Hi,
- Mail original -
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/utils.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
On Mon, Sep 29, 2014 at 10:04:04AM +0200, Benoit Fouet wrote:
Hi,
- Mail original -
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/put_bits.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavcodec/put_bits.h
On 28.09.2014 10:49, Reimar Döffinger wrote:
Note the documentation for that option:
The /LARGEADDRESSAWARE option tells the linker that the application can
handle addresses larger than 2 gigabytes.
This flag is _only_ used to signal that an application can deal
with addresses that use more
Hi,
- Mail original -
Hi,
Le 26/09/2014 18:38, Michael Niedermayer a écrit :
On Fri, Sep 26, 2014 at 09:27:01AM +0200, Benoit Fouet wrote:
Hi,
- Mail original -
Michael Niedermayer michaelni at gmx.at writes:
On Fri, Aug 01, 2014 at 01:54:14AM +0200, Michael
Le quartidi 4 vendémiaire, an CCXXIII, Reynaldo H. Verdejo Pinochet a écrit :
As you might already know, Samsung has decided to back up our
initiative with the required 6K USD (Thanks!) and as result,
we have got at least one mentee covered for this round of the
Outreach Program for Women
Le septidi 7 vendémiaire, an CCXXIII, Clément Bœsch a écrit :
---
Can only be applied after timed SRT is dropped.
---
libavcodec/srtdec.c | 78
-
1 file changed, 35 insertions(+), 43 deletions(-)
The changes look right to me.
Regards,
L'octidi 28 fructidor, an CCXXII, Clément Bœsch a écrit :
---
libavcodec/srtdec.c | 33 +++
libavcodec/srtenc.c | 49
++-
libavformat/matroska.c| 1 -
libavformat/matroskaenc.c | 45
Hi,
I want to propose to have an FFmpeg IRC meeting the next Saturday, 4th
October, UTC 16. Alternatively, I propose the Saturday of the next
week, Saturday October 11, same time.
Candidate topics of the day:
- VDD 2014 report and discussion, in particular with regards to
relationships with
On Mon, Sep 29, 2014 at 05:39:23PM +0200, Stefano Sabatini wrote:
Hi,
I want to propose to have an FFmpeg IRC meeting the next Saturday, 4th
October, UTC 16. Alternatively, I propose the Saturday of the next
week, Saturday October 11, same time.
Candidate topics of the day:
- VDD 2014
On Mon, Sep 29, 2014 at 02:01:25AM +0200, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes decoding 32bit pcm audio in mov as written by the
Convergent Design's Odyssey 7Q recorder.
Please comment, Carl Eugen
mov.c |4
1 file changed, 4 insertions(+)
L'octidi 8 vendémiaire, an CCXXIII, Andrey Utkin a écrit :
At last I got back to this issue.
First I thought of adding such new error codes:
snip
What do you think about it? Which would you prefer?
I am sorry to have to say your proposal has the taste of add whatever I
need for my specific use
On Mon, 29 Sep 2014 19:06:09 +0200
Nicolas George geo...@nsup.org wrote:
I quite like the GError system devised in GLib for the Gtk+ toolkit. It
solves A, B and C in a rather elegant way IMHO.
*panic*
(GLib is full of utter shit design, I doubt GError is sane.)
L'octidi 8 vendémiaire, an CCXXIII, wm4 a écrit :
(GLib is full of utter shit design, I doubt GError is sane.)
By your wording, I guess you did not actually look. I did.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
On Mon, 29 Sep 2014 19:17:04 +0200
Nicolas George geo...@nsup.org wrote:
L'octidi 8 vendémiaire, an CCXXIII, wm4 a écrit :
(GLib is full of utter shit design, I doubt GError is sane.)
By your wording, I guess you did not actually look. I did.
Well, I've read the rest of your description,
On Mon, Sep 29, 2014 at 05:42:09PM +0200, Nicolas George wrote:
L'octidi 28 fructidor, an CCXXII, Clément Bœsch a écrit :
---
libavcodec/srtdec.c | 33 +++
libavcodec/srtenc.c | 49
++-
avio_flush() did nothing useful for read streams. Fix it to behave as
expected, and discard the currently read buffer properly.
---
Since avio_flush() was just broken for read streams, I don't think this
needs to be treated as an API-change.
---
libavformat/avio.h| 8 ++--
Useful for Bluray and DVD, since the libraries used to read them just
change the byte stream under your feet on seeking.
Maybe there should be a AVInputFormat callback for this. But the
mpeg-ps (DVD) and the mpeg-ts (Bluray) demuxers don't change much
state during seeking - they just try to find
On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote:
Useful for Bluray and DVD, since the libraries used to read them just
change the byte stream under your feet on seeking.
Maybe there should be a AVInputFormat callback for this. But the
mpeg-ps (DVD) and the mpeg-ts (Bluray) demuxers don't
On Mon, 29 Sep 2014 20:25:47 +0200
Michael Niedermayer michae...@gmx.at wrote:
On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote:
Useful for Bluray and DVD, since the libraries used to read them just
change the byte stream under your feet on seeking.
Maybe there should be a
On Mon, Sep 29, 2014 at 08:34:44PM +0200, wm4 wrote:
On Mon, 29 Sep 2014 20:25:47 +0200
Michael Niedermayer michae...@gmx.at wrote:
On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote:
Useful for Bluray and DVD, since the libraries used to read them just
change the byte stream under
On Mon, Sep 29, 2014 at 05:56:01AM +0200, Michael Niedermayer wrote:
This should reduce the memory requirement
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/mpegvideo_enc.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
On Mon, Sep 29, 2014 at 03:31:36PM +0200, Benoit Fouet wrote:
Hi,
- Mail original -
Hi,
Le 26/09/2014 18:38, Michael Niedermayer a écrit :
On Fri, Sep 26, 2014 at 09:27:01AM +0200, Benoit Fouet wrote:
Hi,
- Mail original -
Michael Niedermayer michaelni at
On Mon, Sep 29, 2014 at 07:41:27PM +0200, wm4 wrote:
avio_flush() did nothing useful for read streams. Fix it to behave as
expected, and discard the currently read buffer properly.
---
Since avio_flush() was just broken for read streams, I don't think this
needs to be treated as an
A badly behaving user provided mutex manager (such as that in OpenCV) may not
reset the mutex to NULL on destruction. This can cause a problem for a later
mutex manager (which may assert that the mutex is NULL before creating).
---
libavcodec/utils.c | 15 +--
1 file changed, 9
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/allcodecs.c | 51 +---
libavcodec/avcodec.h |5 +
2 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/allformats.c | 44 +++-
libavformat/avformat.h |5 +
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index
On Mon, Sep 29, 2014 at 02:41:38PM -0700, Manfred Georg wrote:
A badly behaving user provided mutex manager (such as that in OpenCV) may not
reset the mutex to NULL on destruction. This can cause a problem for a later
mutex manager (which may assert that the mutex is NULL before creating).
35 matches
Mail list logo
