On 26/08/16 22:00, Sean McGovern wrote:
> On Aug 26, 2016 3:29 PM, "Luca Barbato" wrote:
>>
>> On 26/08/16 15:30, Derek Buitenhuis wrote:
>>> I ran into issues with these at work, and fixed them in FFmpeg.
>>>
>>> I've rebased them on Libav and am sending them as a professional
> courtesy.
>>
>> T
On Aug 26, 2016 3:29 PM, "Luca Barbato" wrote:
>
> On 26/08/16 15:30, Derek Buitenhuis wrote:
> > I ran into issues with these at work, and fixed them in FFmpeg.
> >
> > I've rebased them on Libav and am sending them as a professional
courtesy.
>
> Thank you a lot, fate seems happy and the set loo
On 26/08/16 15:30, Derek Buitenhuis wrote:
> I ran into issues with these at work, and fixed them in FFmpeg.
>
> I've rebased them on Libav and am sending them as a professional courtesy.
Thank you a lot, fate seems happy and the set looks fine.
I'll merge it in 1 day if nobody has problems with
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis
---
libavformat/isom.h | 1 -
libavformat/mov.c | 8 +---
2 files changed,
I ran into issues with these at work, and fixed them in FFmpeg.
I've rebased them on Libav and am sending them as a professional courtesy.
Keep in mind I'm still unscubscribed from both lists, so relevant comments
may need to be CC'd to me if you feel something needs changing.
Cheers.
Derek Bui
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 89c2c23..ca49716 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -
On 26/08/16 14:59, Diego Biurrun wrote:
> ---
> libavcodec/wmavoice.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 26/08/16 16:12, Diego Biurrun wrote:
> From: Burt P
>
> Signed-off-by: Burt P
> Signed-off-by: Diego Biurrun
> ---
>
> minor cosmetic changes, version bump
>
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman
On 8/26/2016 11:09 AM, Diego Biurrun wrote:
> On Fri, Aug 26, 2016 at 07:36:29AM -0500, Burt P wrote:
>> --- /dev/null
>> +++ b/libavfilter/af_hdcd.c
>> @@ -0,0 +1,199 @@
>> +
>> +#include
>
> Is there a hdcd_complicated.h header as well?
There used to be one that exposed every internal bit and
From: Burt P
Signed-off-by: Burt P
Signed-off-by: Diego Biurrun
---
minor cosmetic changes, version bump
Changelog| 1 +
configure| 4 +
doc/filters.texi | 47 +++
doc/general.texi | 9 +++
libavfilter/Makefile | 1 +
libav
On Fri, Aug 26, 2016 at 07:36:29AM -0500, Burt P wrote:
> --- /dev/null
> +++ b/libavfilter/af_hdcd.c
> @@ -0,0 +1,199 @@
> +
> +#include
Is there a hdcd_complicated.h header as well?
> +typedef struct HDCDContext {
> +const AVClass *class;
> +
> +hdcd_simple *shdcd;
same question, sort
---
libavcodec/wmavoice.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/wmavoice.c b/libavcodec/wmavoice.c
index 62b603c..19c06f4 100644
--- a/libavcodec/wmavoice.c
+++ b/libavcodec/wmavoice.c
@@ -1672,9 +1672,7 @@ static int check_bits_for_superframe(GetBitCont
On Fri, Aug 26, 2016 at 2:45 AM, Diego Biurrun wrote:
> It's called the rule of least surprise. A function name prefix should
> be related to the name of the library or the format. Adding seemingly
> random characters is just a source for confusion.
>
> What simple API is this? Do you offer a c
A new filter that provides HDCD decoding, using libhdcd.
https://github.com/bp0/libhdcd
Requires ./configure --enable-libhdcd
Signed-off-by: Burt P
---
Changelog| 1 +
configure| 4 +
doc/filters.texi | 47 +++
doc/general.texi | 9
ptrdiff_t is the correct type for array pitches and similar.
---
libavcodec/sanm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 6436f84..3d23195 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -21
ptrdiff_t is the correct type for array pitches and similar.
---
libavcodec/copy_block.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/copy_block.h b/libavcodec/copy_block.h
index 10718cc..0b69622 100644
--- a/libavcodec/copy_block.h
+++ b/libavcodec/co
ptrdiff_t is the correct type for array pitches and similar.
---
libavcodec/svq1dec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/svq1dec.c b/libavcodec/svq1dec.c
index d6f4b43..cc43f14 100644
--- a/libavcodec/svq1dec.c
+++ b/libavcodec/svq1dec.c
@@
ptrdiff_t is the correct type for array pitches and similar.
---
libavcodec/indeo3.c | 14 ++---
libavcodec/ivi.c | 8
libavcodec/ivi.h | 6 +++---
libavcodec/ivi_dsp.c | 52 +++
libavcodec/ivi_dsp.h | 57 +
On Thu, Aug 25, 2016 at 04:53:38PM -0500, Burt P. wrote:
> On Thu, Aug 25, 2016 at 8:56 AM, Diego Biurrun wrote:
> > On Wed, Aug 24, 2016 at 07:34:22AM -0500, Burt P wrote:
>
> For indentation and other cosmetic changes, could you submit a patch
> after this? I don't feel I will be able to get it
On Fri, Aug 26, 2016 at 11:42:03AM +0200, Luca Barbato wrote:
> On 24/08/16 13:02, Diego Biurrun wrote:
> > VP5 has no arch-specific optimizations (nor will it get some in the
> > future), so it makes no sense to try to share dsp init code with VP6.
> > ---
> > libavcodec/arm/vp6dsp_init_arm.c |
On 24/08/16 13:02, Diego Biurrun wrote:
VP5 has no arch-specific optimizations (nor will it get some in the
future), so it makes no sense to try to share dsp init code with VP6.
---
libavcodec/arm/vp6dsp_init_arm.c | 4 +--
libavcodec/vp5.c | 1 +
libavcodec/vp56.c
On Fri, Aug 26, 2016 at 09:58:47AM +0200, Anton Khirnov wrote:
> Quoting Diego Biurrun (2016-08-26 09:48:26)
> > On Thu, Aug 25, 2016 at 06:36:45PM -0500, Burt P. wrote:
> > > On Thu, Aug 25, 2016 at 5:46 PM, Jean-Baptiste Kempf
> > > wrote:
> > > > On 25 Aug, Burt P. wrote :
> > > >> HDCD coding
Quoting Diego Biurrun (2016-08-26 09:48:26)
> On Thu, Aug 25, 2016 at 06:36:45PM -0500, Burt P. wrote:
> > On Thu, Aug 25, 2016 at 5:46 PM, Jean-Baptiste Kempf
> > wrote:
> > > On 25 Aug, Burt P. wrote :
> > >> HDCD coding is hidden in some CD audio, but not all, and using it is
> > >> completely
On 26/08/16 09:48, Diego Biurrun wrote:
I'm with j-b on this one. If the filter is optional, it will be left
out in 99% of cases. It sounds like you are optimizing for a rare edge
case and sacrificing ease of use and better quality in 99% of cases for
it...
I see those general problems:
- Yo
On Thu, Aug 25, 2016 at 06:36:45PM -0500, Burt P. wrote:
> On Thu, Aug 25, 2016 at 5:46 PM, Jean-Baptiste Kempf
> wrote:
> > On 25 Aug, Burt P. wrote :
> >> HDCD coding is hidden in some CD audio, but not all, and using it is
> >> completely optional.
> >
> > But you can detect that, cannot you?
On Thu, Aug 25, 2016 at 11:49:05PM -0500, Burt P. wrote:
> On Thu, Aug 25, 2016 at 7:42 PM, James Almer wrote:
> > On 8/25/2016 6:53 PM, Burt P. wrote:
> >> On Thu, Aug 25, 2016 at 8:56 AM, Diego Biurrun wrote:
> >>> The _t namespace is reserved for POSIX, the library should not invade it.
> >>
>
On 26/08/16 06:49, Burt P. wrote:
I can remove _t from types easily, but does the shdcd_* -> hdcds_*
really need to happen?
Not needed if you do not want to, probably it is nicer the way it is
suggested.
lu
___
libav-devel mailing list
libav-devel
On Thu, Aug 25, 2016 at 04:53:38PM -0500, Burt P. wrote:
> On Thu, Aug 25, 2016 at 8:56 AM, Diego Biurrun wrote:
> > On Wed, Aug 24, 2016 at 07:34:22AM -0500, Burt P wrote:
> >> --- /dev/null
> >> +++ b/libavfilter/af_hdcd.c
> >> @@ -0,0 +1,199 @@
> >> +typedef struct HDCDContext {
> >> +const
28 matches
Mail list logo
