On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
wrote:
> Chrome canary now supports decoding of VP9 streams with alpha
> channel [1]. Add support to ffmpeg for creating such files.
>
> [1] https://codereview.chromium.org/2096813002/
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
On Wed, Jul 13, 2016 at 6:05 AM, James Almer wrote:
> Fix the demuxer dependencies in some of the tests and remove the vp8 decoder
> dependency for the stream copy tests
>
I assume you actually tested those without the decoder? Some codecs
like to act a bit odd when the decoder can't provide extr
On Tue, Jul 12, 2016 at 11:49 AM, Vignesh Venkatasubramanian
wrote:
>>> > Alright, i have a working patch for the decoder locally (i will push
>>> > that to the ML shortly).
>>>
>>> Here it is: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196403.html
>>
>>
>> Thanks, that resolves my concern
Fix the demuxer dependencies in some of the tests and remove the vp8 decoder
dependency for the stream copy tests
Signed-off-by: James Almer
---
tests/fate/vpx.mak | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.m
On Wed, Jul 06, 2016 at 08:25:27PM -0300, James Almer wrote:
> RFC 5334 recommendens this extension to go alongside the video/ogg
> mimetype for video files, with or without audio and subtitles [1].
>
> [1] https://tools.ietf.org/html/rfc5334#section-10.2
>
> Signed-off-by: James Almer
> ---
> T
On Fri, Jul 08, 2016 at 12:08:14PM -0300, James Almer wrote:
> On 7/8/2016 4:22 AM, Michael Niedermayer wrote:
> > On Thu, Jul 07, 2016 at 11:02:30PM -0300, James Almer wrote:
> >> On 7/7/2016 10:55 PM, Michael Niedermayer wrote:
> >>> On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote:
>
On Tue, Jul 12, 2016 at 04:19:53PM -0700, Jon Toohill wrote:
> initial_padding specifies only encoder delay, decoder delay is
> handled by start_skip_samples.
> ---
> doc/APIchanges | 4
> libavcodec/libmp3lame.c | 2 +-
> libavcodec/version.h| 2 +-
> libavformat/mp3enc.c| 4
On Tue, Jul 12, 2016 at 03:41:38PM -0700, Jon Toohill wrote:
> I'm having a hard time finding software that uses this via simple GitHub
> searches.
FFmpeg itself uses it
>
> I think this should be considered a bugfix, since the struct field states
> that it only represents encoder delay, not dec
initial_padding specifies only encoder delay, decoder delay is
handled by start_skip_samples.
---
doc/APIchanges | 4
libavcodec/libmp3lame.c | 2 +-
libavcodec/version.h| 2 +-
libavformat/mp3enc.c| 4 ++--
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/A
---
ffmpeg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 652774f..442f818 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3001,6 +3001,7 @@ static int transcode_init(void)
enc_ctx->audio_service_type = dec_ctx->audio_service_type;
enc_ct
---
libavformat/mp3enc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 3b77d29..da70d13 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -248,11 +248,14 @@ static int mp3_write_xing(AVFormatContext *s)
---
libavformat/mp3dec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 56c7f8c..345fa88 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -239,6 +239,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, AVStream
*st,
Also adds trailing_padding to AVCodecContext to match
AVCodecParameters so that it doesn't get lost when mapping
between them.
---
doc/APIchanges | 4
libavcodec/avcodec.h | 11 +++
libavcodec/utils.c | 40 +++-
libavcodec/version.h | 2 +-
These patches expose the encoder delay/padding parsed from an mp3's Xing header
to users of lavc/lavf, and show gapless info in the stream summary string. They
also change ffmpeg to pass Xing gapless metadata from input to output when
using -acodec copy.
trailing_padding is still not set proper
On 7/12/2016 7:52 PM, Moritz Barsnick wrote:
> On Tue, Jul 12, 2016 at 18:36:20 -0300, James Almer wrote:
>> +uint32_t invcnt = !((granule >> 30) & 3);
>
> If it's just for storing a 0/1 (bool, basically), wouldn't you use the
> more unspecific type "int"? (Not sure whether it matters at all.)
On 7/12/2016 7:50 PM, Moritz Barsnick wrote:
> On Tue, Jul 12, 2016 at 18:36:22 -0300, James Almer wrote:
>> +/** for VP8 granule */
>
> Spurious asterisk. ;-)
Copy paste from a Theora comment a couple lines above this one.
Is it a problem? I can change both to use a single asterisk if
needed
On Tue, Jul 12, 2016 at 18:36:20 -0300, James Almer wrote:
> +uint32_t invcnt = !((granule >> 30) & 3);
If it's just for storing a 0/1 (bool, basically), wouldn't you use the
more unspecific type "int"? (Not sure whether it matters at all.)
Moritz
_
On Tue, Jul 12, 2016 at 18:36:22 -0300, James Almer wrote:
> +/** for VP8 granule */
Spurious asterisk. ;-)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I'm having a hard time finding software that uses this via simple GitHub
searches.
I think this should be considered a bugfix, since the struct field states
that it only represents encoder delay, not decoder delay. I'll send out an
updated patchset that splits this into more patches, including
doc
On Tue, Jul 12, 2016 at 18:31:36 +0430, Omid Ghaffarinia wrote:
Your mailer has broken the patch by inserting line breaks. You should
try attaching the patch as a file, or directly using "git send-email".
> Bug is due to kernel handling multicast ttl 0 differently (as noted in
> kernel code net/i
On Tue, Jul 12, 2016 at 21:36:54 +0800, Steven Liu wrote:
> resend the patch, delete the trailing whitespace and check patch by
> ./tools/patcheck
I reviewed the older patch (sorry!), but the grammar comments still
apply.
Moritz
___
ffmpeg-devel mailing
On Tue, Jul 12, 2016 at 11:55:39 +0800, Steven Liu wrote:
Grammar:
> +@item method
> +Use HTTP method to operation the hls files,
-> "Use the given HTTP method to create the hls files."
Or something like this. I couldn't figure it out from the code: How
about listing the allowed methods?
> +Thi
On Mon, 11 Jul 2016 23:20:13 +0100, Rostislav Pehlivanov wrote:
> Removed the "in a clean way", it was unnencessary anyway as the "new APIs"
> were already implied to be nicer earlier.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> src/index | 9 +
> 1 file changed, 9 insertions(+)
LG
Addresses ticket #5687
Signed-off-by: James Almer
---
AVFMT_TS_NONSTRICT is added to flags because invisible vp8 frames don't
increase the pts
libavformat/oggenc.c| 94 +
tests/fate/avformat.mak | 1 +
tests/lavf-regression.sh| 4 ++
Signed-off-by: James Almer
---
libavformat/oggparsevp8.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/oggparsevp8.c b/libavformat/oggparsevp8.c
index d57419e..3ba5375 100644
--- a/libavformat/oggparsevp8.c
+++ b/libavformat/oggparsevp8.c
@@ -82,7 +82,11 @@
Signed-off-by: James Almer
---
No changes from the previous standalone version, but i'm resending
it since it's needed by the next patch.
libavformat/oggenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 6940a7b..9522
On Tue, Jul 12, 2016 at 12:54:09PM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip
On Tue, 12 Jul 2016, Nicolas George wrote:
Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
The fifo muxer never returns EAGAIN. It silently drops the packets in
non-blocking mode on a full queue. This behaviour is useful for the tee
muxer case, when you don't want one slow/unreliab
On Tue, Jul 12, 2016 at 12:54:06PM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented spea
On 7/12/2016 3:48 PM, Vignesh Venkatasubramanian wrote:
> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
> ability to decode such files with alpha channel.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavcodec/libvpxdec.c | 102 +---
On Tue, Jul 12, 2016 at 09:35:46PM +0800, Steven Liu wrote:
> resend the patch, delete the trailing whitespace and check patch by
> ./tools/patcheck
>
> add the hls_flags round_durations, discont_start, omit_endlist flags
> describe
>
> Signed-off-by: LiuQi
> ---
> doc/muxers.texi | 12 ++
On 7/12/2016 3:48 PM, Vignesh Venkatasubramanian wrote:
> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
> ability to decode such files with alpha channel.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavcodec/libvpxdec.c | 102 +---
On Thu, Jul 7, 2016 at 12:02 PM, Ronald S. Bultje wrote:
> Hi Vignesh,
>
> On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google@ffmpeg.org> wrote:
>
>> On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
>> wrote:
>> > On Fri, Jul 1, 2016 at 3:03 PM, Ronald
VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
ability to decode such files with alpha channel.
Signed-off-by: Vignesh Venkatasubramanian
---
libavcodec/libvpxdec.c | 102 +---
tests/fate/vpx.mak | 3 +
tests/ref/fate/vp8-al
On Mon, Jul 11, 2016 at 5:55 PM, James Zern
wrote:
> On Thu, Jul 7, 2016 at 11:43 AM, Vignesh Venkatasubramanian
> wrote:
>> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
>> ability to decode such files with alpha channel.
>>
>> Signed-off-by: Vignesh Venkatasubramanian
>> -
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 73a0b93..48f87f6 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1094,7 +1094,7 @@ static int filter_frame(AVF
Only call hdcd_update_info() when the control code changes
instead of every frame, so the counters are more meaningful.
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/libavfilter/af_hdcd.c b
Count and report when a code is signaled but fails to match a known pattern.
For example try Līve - Secret Samadhi.
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 73 ---
1 file changed, 58 insertions(+), 15 deletions(-)
diff --git a/libavfilte
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 4104935..8acbdda 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1157,13 +1157,15 @@ static a
This is the previous patch split into smaller patches, as requested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 89012eb..73a0b93 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -883,7 +883,7 @@ static void hdcd_reset(hd
On Tue, Jul 12, 2016 at 01:15:07PM +0100, Rostislav Pehlivanov wrote:
> On 12 July 2016 at 12:53, Michael Niedermayer
> wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/dirac_vlc.h |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec
When using ffmpeg to start a local-only server (i.e. setting ttl=0)
using multicast ip (i.e. 224.1.1.1) you can see packets going to
network.
Bug is due to kernel handling multicast ttl 0 differently (as noted in
kernel code net/ipv4/route.c:2191 see:
https://github.com/torvalds/linux/blob/master/n
resend the patch, delete the trailing whitespace and check patch by
./tools/patcheck
add the hls_flags round_durations, discont_start, omit_endlist flags
describe
Signed-off-by: LiuQi
---
doc/muxers.texi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/doc/mu
On Jul 12, 2016 05:14, "Ronald S. Bultje" wrote:
>
> Hi,
>
> On Mon, Jul 11, 2016 at 9:56 PM, Jing Yu
> wrote:
>
> > .macro movrel rd, sym, gp
> > +#ifdef __APPLE__
> > +ld \rd, \sym@got(r2)
> > +#else
> > ld \rd, \sym@got(2)
> > +#endif
> > .endm
>
>
> Does something like th
resend the patch, delete the trailing whitespace and check patch by
./tools/patcheck
Signed-off-by: LiuQi
---
doc/muxers.texi |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index bf5bc82..f6fc8e5 100644
--- a/doc/muxers.texi
++
On 12 July 2016 at 12:53, Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/dirac_vlc.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dirac_vlc.h b/libavcodec/dirac_vlc.h
> index 523e9ca..42ae41b 100644
> --- a/libavcodec
Ronald S. Bultje gmail.com> writes:
> The hh restriction seems random.
It unfortunately made the (only) difference for the
given sample...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-dev
Clément Bœsch pkh.me> writes:
> > A user provided a rawvideo frame that is detected as vplayer
> > without attached patch.
>
> can you show a hex dump of the first few bytes?
000 3530 3530 3530 3530 3530 3530 3530 3530
*
0f0 3530 3530 3530 3530 3530 3531 3532 3533
100 3534 3535 353
Signed-off-by: Michael Niedermayer
---
libavcodec/dirac_vlc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dirac_vlc.h b/libavcodec/dirac_vlc.h
index 523e9ca..42ae41b 100644
--- a/libavcodec/dirac_vlc.h
+++ b/libavcodec/dirac_vlc.h
@@ -22,7 +22,7 @@
#ifndef A
On Tue, Jul 12, 2016 at 12:37:39PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> A user provided a rawvideo frame that is detected as vplayer without attached
> patch.
>
can you show a hex dump of the first few bytes?
> Please comment, Carl Eugen
> From 493f24f3d0ba74353ed7742c34a3727c344535eb Mon
Hi,
On Tue, Jul 12, 2016 at 6:37 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> A user provided a rawvideo frame that is detected as vplayer without
> attached
> patch.
The hh restriction seems random. But ok.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-deve
Hi,
On Mon, Jul 11, 2016 at 9:56 PM, Jing Yu
wrote:
> .macro movrel rd, sym, gp
> +#ifdef __APPLE__
> +ld \rd, \sym@got(r2)
> +#else
> ld \rd, \sym@got(2)
> +#endif
> .endm
Does something like this work? (Looks a little more readable)
#ifdef __APPLE__
#define ARG_2 r2
#el
Hi!
A user provided a rawvideo frame that is detected as vplayer without attached
patch.
Please comment, Carl Eugen
From 493f24f3d0ba74353ed7742c34a3727c344535eb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 12 Jul 2016 12:23:58 +0200
Subject: [PATCH] lavf/vplayerdec: Stricter prob
> There are two sides to this issue: change the muxer to write the value if it
> is known at the beginning and change the command-line tool to compute the
> value for their output.
> I suspect the muxer change would be reasonably easy.
> The change on the command-line tool, on the other hand, yo
On Mon, Jul 11, 2016 at 10:25:23PM -0300, James Almer wrote:
> Fixes ticket #5704
>
> Signed-off-by: James Almer
> ---
> libavformat/oggenc.c | 8
> 1 file changed, 8 insertions(+)
should be ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No
On Mon, Jul 11, 2016 at 05:33:03PM -0500, Burt P. wrote:
> Only call hdcd_update_info() when the control code changes
> instead of every frame, so the counters are more meaningful.
>
> Also, adds some basic error detection. After scanning through
> about 30 HDCD-encoded CD's I've found errors wh
Le quintidi 25 messidor, an CCXXIV, Soft Works a écrit :
> Such circumstances are not really "special" or even rare.
> Especially in most trivial cases (like mkv to mkv) there is a known
> duration from the source that could be used.
>
> No doubt, that it's not available in all cases. But it could
On Tue, Jul 12, 2016 at 11:55:05AM +0800, Steven Liu wrote:
> add the hls_flags round_durations, discont_start, omit_endlist flags
> describe
>
[...]
> muxers.texi | 12
> 1 file changed, 12 insertions(+)
> 2c76ab4a4f03f11a29c95ef2703d98b4ca31ca83 0001-refine-the-doc-of-hlsenc.pa
On Tue, Jul 12, 2016 at 11:11 AM, Soft Works wrote:
>
>> Unfortunately the duration is not available in all cases, so writing
>> it early would only work in a few special circumstances, so as a
>> generic solution its not going to work.
>
> Such circumstances are not really "special" or even rare.
> Unfortunately the duration is not available in all cases, so writing
> it early would only work in a few special circumstances, so as a
> generic solution its not going to work.
Such circumstances are not really "special" or even rare.
Especially in most trivial cases (like mkv to mkv) there is
On Tue, Jul 12, 2016 at 10:11 AM, Soft Works wrote:
> Now I'm wondering if this could be fixed by early writing the duration in
> mkv_write_header if a duration is available at this time (usually taken from
> the source stream)?
>
Unfortunately the duration is not available in all cases, so wri
Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
> The fifo muxer never returns EAGAIN. It silently drops the packets in
> non-blocking mode on a full queue. This behaviour is useful for the tee
> muxer case, when you don't want one slow/unreliable (network) output to
> block reading the
Le quintidi 25 messidor, an CCXXIV, Nicolas George a écrit :
> Le quartidi 24 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
> > I think it is used in decoding only - the documentation of AVStream mentions
> > only decoding and I also tried to search references to that field if it is
> > not used
Hi,
we are using ffmpeg to transcode or remux mkv to mkv. The result is being
streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still
running).
The problem here is that the client is unable to detect the duration because
the duration is only written to the mkv at the end
65 matches
Mail list logo
