On 11/1/2016 5:01 PM, Sasi Inguva wrote:
> When we add up (last pts + 0.023 ) it amounts to that . We fix the last
> packet duration according to edit list segment duration in our edit list
> patch. Here last pts = 1324.652 .
I figured this was the case. IIRC, the OGG code works like this to
This is in the same the same vein as c981b1145a857c8f962c93b8eecb1c613b20ffe9.
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 5 -
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index
On 10/24/2016 6:43 AM, Sasi Inguva wrote:
> Just sent a patch, correcting a bug in the edit list code. PTAL.
Hi again, it's me. Back with more files this patch set broke :).
This time it's very easy to reproduce:
$ ffmpeg -i sample.mp4 -f null -
This works before your patchset, and also if
On 10/26/2016 7:31 PM, Sasi Inguva wrote:
> According to spec ISO_IEC_15444_12 "For any media stream for which no segment
> index is present, referred to as non‐indexed stream, the media stream
> associated with the first Segment Index box in the segment serves as a
> reference stream in a sense
On 11/3/2016 4:56 PM, Sasi Inguva wrote:
>> I am just converting the *reference* stream duration from that streams'
> timescale to the timescale of the stream I am setting to.
>
>
Indeed, I misread this (midnight emails FTL; I read time_scale 3 times instead
of 2).
Anyway, the rest seems OK to
On 11/3/2016 10:36 PM, Sasi Inguva wrote:
> +if (index == -1) {
> +av_log(mov->fc, AV_LOG_ERROR,
> + "st: %d edit list %"PRId64" Cannot find an index
> entry before timestamp: %"PRId64"\n",
> + st->index, edit_list_index, sear
On 11/4/2016 9:53 PM, Sasi Inguva wrote:
> So, if I am not wrong, the only case when that would happen is, if edit
> list media time was < 0 . And that would be a corrupt MOV file, unless edit
> list media time = -1.
> I tried to create such a file with AtomInspector but it doesn't let me.
FWIW, t
On 11/6/2016 12:40 PM, Michael Niedermayer wrote:
> IMO we should support it if its possible without large hacks
I don't really have an opinion myself, so to speak. I was just noting it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Signed-off-by: Derek Buitenhuis
---
As request by Michael.
---
doc/encoders.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 5a60e7e..ba60e0a 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1751,6 +1751,10 @@ Exhaustive
On 11/4/2016 10:31 PM, Sasi Inguva wrote:
> -avctx->internal->skip_samples -= frame->nb_samples;
> +avctx->internal->skip_samples = FFMAX(0,
> avctx->internal->skip_samples - frame->nb_samples);
LGTM.
- Derek
___
ffmpeg-devel ma
On 11/9/2016 6:51 PM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva
> ---
> libavformat/mov.c | 41
> tests/fate/mov.mak | 6 +-
> tests/ref/fate/mp4-init-nonkeyframe | 120
>
> 3 files changed, 155 inserti
On 11/11/2016 2:30 PM, Michael Niedermayer wrote:
> if noone adds suport fo the 3rd constant then the patch should
> likely be applied, unless i miss something
This patch LGTM.
When I added this option in c981b1145a857c8f962c93b8eecb1c613b20ffe9, the type
was
INT, and the default was -1, and it
On 11/11/2016 3:26 PM, Derek Buitenhuis wrote:
> This patch LGTM.
>
> When I added this option in c981b1145a857c8f962c93b8eecb1c613b20ffe9, the
> type was
> INT, and the default was -1, and it was correct. It was later broken in
> fb99ef0bd39a1859d0e65c6c16caa8e17dd3cfbe. I
On 11/11/2016 4:01 PM, Timo Rothenpieler wrote:
> -1 and 0 both mean false now, and I left in the option to pass -1 to
> stay compatible with possible 3rd parties who pass it.
Well that's certainly non-obvious...
> So changing to default to 0 doesn't really matter, and I decided to keep
> the pat
On 11/12/2016 6:02 AM, Sasi Inguva wrote:
> +/* Adjust skip_samples correctly when ignore_editlist is set, to support
> gapless playback */
> +if (mov->ignore_editlist && sc->num_non_empty_elst <= 1 &&
> +st->codecpar->codec_id == AV_CODEC_ID_AAC &&
> sc->first_elist_start_time >
This could happen when there was a frame number gap and frame threading was
used.
This fixes #5458.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
This fixes a ton of samples that had frame num gaps and were decoding using
large
numbers of
On 12/7/2016 6:43 PM, Carl Eugen Hoyos wrote:
> 2016-12-07 19:06 GMT+01:00 Derek Buitenhuis :
>> This could happen when there was a frame number
>> gap and frame threading was used.
>>
>> This fixes #5458.
>
> Does this patch have a speed impact on valid streams?
On 12/7/2016 8:10 PM, Michael Niedermayer wrote:
> this deadlocks on some samples
> ill try to find one that i can share
I have a vague idea maybe why, but I'd need a sample, yes.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmp
2nd patch in the series is the same as before.
Derek Buitenhuis (2):
h264_slice: Add forgotten progress update for the 2nd field in a slice
h264_slice: Wait for refs to be available before we use them in error
concealment
libavcodec/h264_slice.c | 5 +
1 file changed, 5 insertions
This could happen when there was a frame number gap and frame threading was
used.
This fixes #5458.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264_slice.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264_slice.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 1f2c06521e..a8a8731138 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1538,6 +1538,8 @@ static int
On 12/8/2016 3:46 PM, Carl Eugen Hoyos wrote:
> Does this have a speed impact for valid h264 streams?
Nope.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This could happen when there was a frame number gap and frame threading was
used.
This fixes #5458.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
Extra help from Ronald enlightened me to the fact that there
is actually this field.
Patch 1/2
On 12/9/2016 2:29 PM, Michael Niedermayer wrote:
> this looks reasonable
Pushed.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Derek Buitenhuis
---
Sample is here:
https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-missing-frame | 35 +++
2 files changed, 37 insertions(+)
create mode
Signed-off-by: Derek Buitenhuis
---
Happened to notice this when adding a FATE test.
---
libavcodec/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index d8ab947abe..0ab029696d 100644
--- a/libavcodec/tests/.gitignore
hem at the expense
of breaking legitimate files.
Signed-off-by: Derek Buitenhuis
---
Let's get this out of the way first: I'm not 'returning to FFmpeg'.
I do not intend to be involved in the community again, nor its
overall direction and discussions, short of a miracle occurrin
On 8/24/2016 6:50 PM, Carl Eugen Hoyos wrote:
>> 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, nor
>
> I suspect the commit message links to this sample:
On 8/24/2016 7:00 PM, Carl Eugen Hoyos wrote:
> Does this patch also fix the issue?
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197817.html
It doesn't. The patch I sent fixes a problem with a current workaround
in the mov demuxer. Edit lists are just one way it could have triggered
it.
On 8/24/2016 10:54 PM, Michael Niedermayer wrote:
> IIRC the removed code tried to detect a reorder delay that is not
> possible in a valid file due to the profile constraints. Aka dts and
> pts are too far appart for the largest amount of buffers allowed in
> any codec.
Basing this on timestamps
On 8/25/2016 3:40 PM, Michael Niedermayer wrote:
> but its probably best to remove in a seperate patch so if it breaks
> something bisect would immedeatly point to which of the 2 changes
> caused it
Sounds good.
If you think this patch is OK, please push it with this part
of the commit message re
On 8/25/2016 4:52 PM, Michael Niedermayer wrote:
>> the patch removes all uses of wrong_dts, the field should be
>> > removed too
> oops i forgot cc-ing you, iam not used to reply-all on the ML
OK. I thought it was used in the FLV demuxer too, but it seems
it has it's own copy inside the FLV conte
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
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 54c63ad..bc11fb8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
On 8/25/2016 5:34 PM, James Almer wrote:
> On 8/25/2016 12:45 PM, Carl Eugen Hoyos wrote:
>> 2016-08-24 16:55 GMT+02:00 Derek Buitenhuis :
>>> This breaks files with legitimate single-entry edit lists,
>>
>>> and the hack, introduced in f03a081df09f9c4798a17d7e
On 8/25/2016 5:18 PM, Michael Niedermayer wrote:
> ok if i push with the changes requested in:
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198303.html
> ? (seems another reply with forgotten CC)
You can change 'hack' to 'incorrect workaround' if you wish.
However, removing the p
On 8/25/2016 5:49 PM, Derek Buitenhuis wrote:
> However, removing the part about the sample being missing in
> the commit message would be wrong, because it is, in fact, not
> linked in the commit message.
I must step out now, so please push whenever some consensus is
reached. No
This fixes downconverting framerates to multiples.
For example, prior to this patch, converting 900 frames at 60 fps
to 30 fps would output 451 frames instead of the correct 450.
Signed-off-by: Derek Buitenhuis
---
DISCLAIMER: I don't know libavfilter very well, and I am not
sure this i
On 10/4/2016 9:58 PM, Michael Niedermayer wrote:
> breaks fate
> and the change to fate looks wrong, the last frame is lost
> make fate-filter-fps
> TESTfilter-fps
> --- ./tests/ref/fate/filter-fps 2016-10-04 14:46:19.642736770 +0200
> +++ tests/data/fate/filter-fps 2016-10-04 22:54:01.8593532
On 10/4/2016 10:21 PM, Michael Niedermayer wrote:
>> This "break" may actually be more correct output, but I am not familiar
>> enough
>> with lavfi or vf_fps to say. Removing the last frame in case where it should
>> have
>> been removed was the entire point of this patch.
>
> the change to fat
ork.
* The only working library that I can find is a package for an obscure distro,
in German only, with a bunch of patches applied.
* The ASM in libutvideo doesn't even work on x86_64.
* More, I'm sure others can fill in.
Signed-off-by: Derek Buitenhuis
---
Changelog
On 2/10/2016 3:26 PM, Rostislav Pehlivanov wrote:
> The type of the option has been changed but the limit was apparently
> forgotten.
> Some video codes can handle bitrates of over ~2.2 Gbps (like VC-2).
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavcodec/options_table.h | 2 +-
> 1 file
On 2/10/2016 4:33 PM, Paul B Mahol wrote:
> I'm fine by this, but it would be nice to have SIMD and 10 bit support
> in decoder.
I agree with the latter.
I'd argue, however, we don't actually support 10-bit via the
wrapper anyway, since you can't even build the library. ;)
- Derek
__
On 2/12/2016 2:24 PM, Carl Eugen Hoyos wrote:
> It works here with a repo I found on my hard disc
This means nothing to users, unless you want to mail
your harddisk to each user.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmp
On 2/12/2016 5:03 PM, Paul B Mahol wrote:
> make install (as root)and then build FFmpeg with
>> libutvideo support.
Last time I tried this, it failed to configure, due to duplicated symbol 'main'.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
Signed-off-by: Derek Buitenhuis
---
I don't know how this could ever have worked, but I also am having a hard time
testing the sliced path in swscale... has it even ever been run?
I have CC'd the original author of this code in the hopes that he
can confirm or deny that this is a co
On 2/17/2016 2:53 AM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/eatqi.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
LGTM.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
> ffmpeg | branch: master | Michael Niedermayer |
> Sun Feb 14 15:22:47 2016 +0100| [0eb4092c1bf4d74c3b9a65fb0dbe4f90d3a316d0] |
> committer: Michael Niedermayer
[...]
> +if (align < 4) {
> +av_log(NULL, AV_LOG_ERROR, "Formats with a palette require a
> minimum alignment o
On 2/20/2016 9:24 PM, Michael Niedermayer wrote:
>> This is a silent API break. You changed behavior of a function in such a way
>> that functioning code no longer works.
>
> yes, i posted a patch that would have maintained API more but people
> did not like it
Yes, I must have missed it. Perhaps
From: Justin Ruggles
Improves probing, especially over http when there is a Content-Type header
Signed-off-by: Derek Buitenhuis
---
libavformat/img2dec.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat
Justin Ruggles (2):
img2dec: Support Progressive JPEG in jpeg_probe
img2dec: Add mime_type to image formats
libavformat/img2dec.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
--
2.7.0
___
ffmpeg-devel
From: Justin Ruggles
There can be multiple SOS markers, so do not return 0 in that case.
Signed-off-by: Derek Buitenhuis
---
libavformat/img2dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index c353563..a755b6f 100644
On 2/24/2016 3:10 PM, Michael Niedermayer wrote:
> This should fix leaving uninitialized pointers in priv which can confuse
> user applications.
> See: https://github.com/golang/go/issues/14426
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avpacket.c |1 +
> 1 file changed, 1 ins
On 2/25/2016 7:27 AM, wm4 wrote:
> They also make code ugly as fuck, and are more cargo-cult than anything
> else. They might possibly be ok in some very critical parts of the
> code, but otherwise not at all.
+1 to this.
I will absolutely *not* ACK any patch sets that start littering likely/unli
On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote:
> -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64
> +// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64,
> +// see Ticket2713 for affected gcc/glibc versions
I've never seen this comment bef
On 2/24/2016 3:19 PM, Carl Eugen Hoyos wrote:
> (Do you have an example where the probing fails?)
>
> The idea of these additional demuxers is that they probe
> the content instead of relying on the file suffix.
> File suffix provides a score of _EXTENSION (50), so if probing
> is possible and
On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
Replies are mine.
>> In terms of how the score for a MIME type match compares with
>> those of the individual content matching probe functions, I'd
>> say it makes sense. The stronger probing functions have a
>> score which reflects their reliabili
On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> If this cannot be fixed differently, we should either increase
> the score for the existing 32bit probe functions or reduce the
> score for mime types before this gets applied. Several probe
> functions (outside of img2dec.c) return MAX for 32 bits
On 2/26/2016 2:44 PM, Carl Eugen Hoyos wrote:
> Derek Buitenhuis gmail.com> writes:
>
>> On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> You misunderstand:
> Most "imageauto" demuxers return a score of 51. In all cases
> when 51 is returned, the detectio
Fixes large amounts of seeking past EOF, which could be extremely
slow over a network.
Signed-off-by: Derek Buitenhuis
---
Example of the problem:
ffmpeg -f mp3 -i http://chromashift.org/skyfire.ico
This problem was exacerbated even more by the fact that libavformat
tends to identify
On 2/26/2016 5:14 PM, Derek Buitenhuis wrote:
> +ret = avio_read(pb, &header_buf[0], 4);
> +if (ret <= 0)
> +return CHECK_SEEK_FAILED;
This check should be <, not <=.
Changed locally.
- Derek
___
ffmpeg-devel mai
On 2/26/2016 5:30 PM, wm4 wrote:
> The ffio_ensure_seekback() checks are probably unnecessary.
I can remove them if you prefer. Should I?
> Seems a bit verbose, but ok.
I added the av_log stuff because otherwise you just get "Invalid Argument"
from the ffmpeg cli, with no other explanation.
- D
On 2/26/2016 3:05 PM, Carl Eugen Hoyos wrote:
> Or in other words: Except for jpeg, there is no
> probe function that returns 0 although the decoder
> can decode the image.
I'll take your word for it on this part.
> So please provide your failing jpeg cases to
> improve the probing.
> I will p
On 2/26/2016 5:42 PM, Reimar Döffinger wrote:
> +av_assert0(frame->format == avctx->pix_fmt);
Is this valid? Mid-stream colorspace changes are fairly common.
- erek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:
[...]
> ---
> libavcodec/aacenc_utils.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Cool. Looks like an obvious/easy win, assuming it's identical.
- Derek
___
ffmpeg-devel mailing list
ffmp
Signed-off-by: Derek Buitenhuis
---
This matches API with Libav, in a forthcoming merge, using our
exisiting infastructure code.
CC'd Michael, since he wrote the whitelisting code.
This has been tested with FATE.
---
Changelog | 1 +
doc/APIch
On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote:
> + printf("AVColorTransferCharacteristic=%d calling func(%f)
> expected=%f\n",
> + i, test_data[j], result);
Comparing floats exactly probably isn't a great idea, since
floating point implementations differ betwe
On 3/3/2016 7:50 PM, Michael Niedermayer wrote:
> The io_open/close callbacks afterwards seem direct access IIUC
> so its not possible to remove or add any fields prior
>
> though maybe they have been added so recently that its ok to move
> them above all "no direct access" fields
> or maybe iam m
On 3/4/2016 3:02 PM, James Almer wrote:
> ry to non break ABI just yet, leave it as last resort. We did it not even
> half a year ago, and we'd have to push every single scheduled deprecation.
> If this can be resolved moving only the new entries then that's preferable.
OK I did it this way.
- De
On 3/7/2016 4:29 AM, Matthew Gregan wrote:
> Hi,
>
> The attached patch adds basic mux/demux support for the Opus audio codec in
> MP4.
>
> Mozilla have expressed interest in shipping support for this in:
> https://groups.google.com/d/msg/mozilla.dev.platform/mdDZ-nBr_jM/MaLi2BDOAgAJ
Hi,
Why h
On 3/10/2016 8:11 PM, wm4 wrote:
> Since XML libraries are apparently always broken, bloated, insecure, and
> hard to use, that has always been a point of contention. Although it
> would be the right approach.
You're not going to find an XML library that is not annoying/hard to use
because XML is
On 3/15/2016 8:58 AM, Pradeep Ramachandran wrote:
> Has anyone else experienced such a stark difference in speed? Are the
> limits of linux pipes the reason for this difference, or is there something
> else going on here?
First: This is probably the wrong list.
Second: Did you expect piping a ver
On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote:
> Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits),
> and has a much smaller cache (128 bits). Thus, the timings should also
> be more stable.
>
> This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and
> like
On 3/15/2016 2:56 PM, Ronald S. Bultje wrote:
> Might be related to aacenc? But yes, we need to know overall speed gain of
> some useful end user feature before/after this.
[13:42] <@atomnuker> well, AAC just requires the random numbers to be only
somewhat random
[13:43] <@atomnuker> you could pr
On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
> I see this:
> libavformat/tls_schannel.c:#include
> libavformat/tls_securetransport.c:#include
>
> Are those different headers?
Consider that one is for OS X native TLS, and one is for
Windows native TLS.
- Derek
_
On 3/14/2016 11:22 AM, Hendrik Leppkes wrote:
> This reverts commit 9f9ed79d4cb40e5d9093899f8a79086ff23da844.
>
> The hlsopts member was never set anywhere and always NULL, furthermore
> the HLS demuxer needs to retrieve the proper options from the underlying
> http protocol (cookies, user-agent,
On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
> If one wants good Gaussian samples, then yes, I need a 64 bit rng.
> Please also note that I can use av_lfg_get, it does not result in
> slowdown, since speed benefits here come from the ziggurat algo.
> Concretely, it is 82 cycles vs 81 cycles; to
From: Hendrik Leppkes
---
libavformat/internal.h | 7 +++
libavformat/utils.c| 23 +++
2 files changed, 30 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 7defce8..cd390dd 100644
--- a/libavformat/internal.h
+++ b/libavformat/interna
Signed-off-by: Derek Buitenhuis
---
libavformat/psxstr.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index b57981a..38186f7 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -104,13 +104,7 @@ static int
WAV is not a NOHEADER format, and thus should not be changing
stream codec IDs and probing in read_packet.
Signed-off-by: Derek Buitenhuis
---
Output is unchanged. FATE has been run, and I have also
run Michael's new fate-wav-ac3 test, and it passes.
---
libavformat/wavdec.c
On 4/2/2016 12:02 PM, Michael Niedermayer wrote:
>>> heres one regression:
>>> ./ffmpeg -i Broadway-5.1-48khz-448kbit.ac3 -t 10 out.wav
>>> ./ffmpeg-codecpar-2016-0331-23 -i Broadway-5.1-48khz-448kbit.ac3 -t 10
>>> out-codecpar.wav
Fixed yesterday.
>> another regression:
>> ./ffmpeg -i ~/tickets
On 3/31/2016 9:49 PM, Derek Buitenhuis wrote:
> From: Hendrik Leppkes
>
> ---
> libavformat/internal.h | 7 +++
> libavformat/utils.c| 23 +++
> 2 files changed, 30 insertions(+)
Ping.
- Derek
___
ff
WAV is not a NOHEADER format, and thus should not be changing
stream codec IDs and probing in read_packet.
Signed-off-by: Derek Buitenhuis
---
libavformat/wavdec.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/libavformat/wavdec.c b
Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.
Heavily based off of a patch from 2012.
Original-by: Nicolas George
Signed-off-by: Derek Buitenhuis
---
libavcodec/libxvid.c | 37
On 4/3/2016 10:22 AM, Michael Niedermayer wrote:
> please add somethng like this to the commit message
> LGTM
Applied with updated commit message.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
On 4/3/2016 5:58 PM, Martin Vignali wrote:
> Hello,
>
> In attach a patch to add support for UINT32 pixel type.
[...]
> +#ifndef UINT32_MAX
> +#define UINT32_MAX (0x)
> +#endif
Don't do this, we already require this header be present and working.
- Derek
__
On 4/3/2016 9:49 PM, Clément Bœsch wrote:
> dv needed something like this too, but the code was pretty much hacky in
> the first place and it was changed not to use them, which avoided such
> commit. Where is this needed exactly?
Look at the new rv20 test from 1 April.
- Derek
___
Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.
Heavily based off of a patch from 2012.
Original-by: Nicolas George
Signed-off-by: Derek Buitenhuis
---
libavcodec/libxvid.c | 39
On 4/3/2016 9:54 PM, Derek Buitenhuis wrote:
> Modifying global header extradata in encode_frame is an API violation
> and only happens to work currently because mov writes its header
> at the end of the file.
>
> Heavily based off of a patch from 2012.
>
> Original-by: Nic
Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.
Heavily based off of a patch from 2012.
Original-by: Nicolas George
Signed-off-by: Derek Buitenhuis
---
libavcodec/libxvid.c | 40
On 4/5/2016 10:26 AM, Michael Niedermayer wrote:
> should be ok fro ffmpegs side, i dont know the xvid API
As far as I can tell from its documentation, this is the official / correct
way. The API is kinda bad in that sense.
Thanks,
- Derek
___
ffmpeg-de
On 4/8/2016 2:30 PM, Michael Niedermayer wrote:
> There are a few known bugs in it like code depending on
> sizeof(AVStream) and general a little too much direct access into APIs
> these things will cause ffserver to frequently break if APIs change
> even slightly.
To calrify, the problem is acces
On 4/8/2016 1:38 AM, Rodger Combs wrote:
> @@ -617,6 +617,7 @@ static int dash_write_header(AVFormatContext *s)
> ctx->opaque = s->opaque;
> ctx->io_close = s->io_close;
> ctx->io_open= s->io_open;
> +av_dict_set(&opts, "fflags",
On 4/10/2016 5:42 PM, Michael Niedermayer wrote:
> this is not possible currently libfaac is twice as fast than the
> native encoder.
Twice as fast and produces crap output.
Personally I think 31x realtime (which is the example you've given) is pretty
quick.
I somewhat double people are using t
On 4/10/2016 8:09 PM, Rostislav Pehlivanov wrote:
> There are far less users of libfaac than libstagefright, so I think just a
> changelog entry would be enough.
I very much doubt this. Very few people could even *compile* the libstagefright
code.
- Derek
On 4/11/2016 12:32 AM, Michael Niedermayer wrote:
> The bits_per_raw_sample represents the number of bits of precission per
> sample.
>
> The field is added at the logical place, not at the end as the code was just
> recently added
>
> This fixes the regression about loosing the audio sample pre
On 3/22/2016 11:22 AM, Benjamin St wrote:
> This patch applies filtering/decoding for hdcds(see ticket #4441) . The
> filter is heavily based on
> https://github.com/kode54/foo_hdcd/. (Is this ok? Copyright?)
>
> Discuss, Review
Hi,
Sorry to be late to the party (I just saw this pushed.)
Why is
On 4/21/2016 9:13 AM, Hendrik Leppkes wrote:
> One developer from Libav is working on defining side-data for this
> spherical data. If you want to push this forward I suggest you join
> those efforts.
> ie. this patch for mov: https://patches.libav.org/patch/60300/ (part
> of a longer series)
Yes,
This function bo longer takes an AVCodecContext.
Fixes ticket #5430.
Signed-off-by: Derek Buitenhuis
---
Since I'm sending this patch anyway, I had a few questions:
1. Where the heck is libnut's official repo. Google only turns up
random GitHub forks, and a link to MultiMediaw
On 4/21/2016 1:52 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
This should be my gmail. Fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
601 - 700 of 1502 matches
Mail list logo
