On Tue, May 31, 2016 at 9:33 PM, Hendrik Leppkes wrote:
>
> On Tue, May 31, 2016 at 2:58 PM, Xinzheng Zhang wrote:
> > ---
> > libavformat/tcp.c | 215
> > ++
> > 1 file changed, 215 insertions(+)
>
Any other thoughts on we should move forward with the _ARIB_STD name
or to use something like HYBRID_LOG_GAMMA?
On Thu, Apr 21, 2016 at 5:04 PM, Neil Birkbeck wrote:
> Thanks Hendrik.
>
> For now, I've updated the patch with a better comment and commit
> message, and
There’s a lot of research done on Motion Estimation. Depending upon the
intended application of the resultant motion vectors, the method used for
motion estimation can be very different.
Classification of Motion Estimation Methods:
Direct Methods: In direct methods we calculate optical flow
On Tue, May 31, 2016 at 09:02:01PM +0530, Umair Khan wrote:
> Hi all,
>
> I replaced floats in my code with SoftFloat and the results weren't as
> expected.
> I also had some doubts the way it is written.
>
> 1. The biggest one is why is the mantissa part of FLOAT_1 defined as
> 0x2000 here
> On May 31, 2016, at 3:23 PM, Michael Niedermayer
> wrote:
>
> adding demuxer and other logs should be easy
> This forces single threaded decoding for simplicity
> It also requires pthreads, this could be avoided either with
> some lockless tricks or simply by assuming
Fixes ticket #5554.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f8cf922..9bf676c 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@
adding demuxer and other logs should be easy
This forces single threaded decoding for simplicity
It also requires pthreads, this could be avoided either with
some lockless tricks or simply by assuming av_log would never be called from
another thread.
doc/ffprobe.xsd update missing (TODO & help
Hi,
2016-05-30 15:09 GMT+02:00 Paul B Mahol :
Hi,
2016-05-30 15:09 GMT+02:00 Paul B Mahol :
>> ffmpeg seems to have libavutil/qsort.h, but I don't even know how much
>> effort is needed to use it here.
>
> Changed, doesn't help but maybe will for other archs.
On Tue, May 31, 2016 at 03:51:20PM +0200, Matthieu Bouron wrote:
> On Tue, May 31, 2016 at 03:35:49PM +0200, Hendrik Leppkes wrote:
> > On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
> > wrote:
> > > From: Matthieu Bouron
> > >
> > >
Hi all,
I replaced floats in my code with SoftFloat and the results weren't as expected.
I also had some doubts the way it is written.
1. The biggest one is why is the mantissa part of FLOAT_1 defined as
0x2000 here -
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/softfloat.h#L41.
If
improve quality on axis drawing with yuv422p and yuv420p format
Signed-off-by: Muhammad Faiz
---
libavfilter/avf_showcqt.c | 73 ++-
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/libavfilter/avf_showcqt.c
On 5/13/2016 6:48 AM, foo86 wrote:
> This is now required by dcadec_decode_frame(). All remaining users of
> avpriv_dca_convert_bitstream() have been updated to expect EXSS marker.
> ---
> libavcodec/dca.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/dca.c
On 5/31/2016 8:46 AM, foo86 wrote:
> Padding before the first sync word can be very large for DTS-in-WAV
> streams. There is no reason to include this padding in parsed packet.
> ---
> libavcodec/dca_parser.c | 41 -
> 1 file changed, 28 insertions(+), 13
On 5/13/2016 6:48 AM, foo86 wrote:
> Remove half-working attempt at supporting unchecked bitstream reader by
> always copying input data into intermediate buffer with large amount of
> padding at the end.
>
> Convert LBR decoder to checked bitstream reader. Convert
> dcadec_decode_frame() to
On Tue, May 31, 2016 at 03:35:49PM +0200, Hendrik Leppkes wrote:
> On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
> wrote:
> > From: Matthieu Bouron
> >
> > Codec width/height restrictions seem hardcoded at the OMX level and
> > seem
On Tue, May 31, 2016 at 3:00 PM, Matthieu Bouron
wrote:
> From: Matthieu Bouron
>
> Codec width/height restrictions seem hardcoded at the OMX level and
> seem arbitrary. Bypassing those restrictions allows a device to decode
> streams at
On Tue, May 31, 2016 at 2:58 PM, Xinzheng Zhang wrote:
> ---
> libavformat/tcp.c | 215
> ++
> 1 file changed, 215 insertions(+)
>
This whole patch looks extremely complicated and long for something
hidden behind a tiny
From: Matthieu Bouron
Codec width/height restrictions seem hardcoded at the OMX level and
seem arbitrary. Bypassing those restrictions allows a device to decode
streams at higher resolutions.
For example it allows a Nexus 5 to decode h264 streams with a resolution
From: Matthieu Bouron
---
libavcodec/mediacodec_wrapper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 053c164..c847a11 100644
--- a/libavcodec/mediacodec_wrapper.c
+++
---
libavformat/tcp.c | 215 ++
1 file changed, 215 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index c105479..9d4fe3d 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -31,11 +31,15 @@
#if HAVE_POLL_H
#include
Sorry, This a wrong patch from a private branch. I will post the correct
one later.
On Tue, May 31, 2016 at 7:05 PM, Xinzheng Zhang
wrote:
> From: xinzhengzhang
>
> ---
> libavformat/tcp.c | 194
>
---
libavcodec/dca_parser.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
index d76b548..1521a5b 100644
--- a/libavcodec/dca_parser.c
+++ b/libavcodec/dca_parser.c
@@ -109,25 +109,25 @@
Padding before the first sync word can be very large for DTS-in-WAV
streams. There is no reason to include this padding in parsed packet.
---
libavcodec/dca_parser.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git
On Fri, May 13, 2016 at 12:48:31PM +0300, foo86 wrote:
> This is now required by dcadec_decode_frame(). All remaining users of
> avpriv_dca_convert_bitstream() have been updated to expect EXSS marker.
> ---
> libavcodec/dca.c | 1 +
> 1 file changed, 1 insertion(+)
Ping.
On Fri, May 13, 2016 at 12:48:30PM +0300, foo86 wrote:
> Remove half-working attempt at supporting unchecked bitstream reader by
> always copying input data into intermediate buffer with large amount of
> padding at the end.
>
> Convert LBR decoder to checked bitstream reader. Convert
>
From: xinzhengzhang
---
libavformat/tcp.c | 194 ++
1 file changed, 194 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 4ac061a..dc3e0bd 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@
On Sun, May 29, 2016 at 10:15:44AM +0200, Matthieu Bouron wrote:
> On Fri, May 27, 2016 at 10:13:20AM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > ---
> > libavcodec/mediacodecdec_h264.c | 61
> > +
> > 1
27 matches
Mail list logo