Fixed patch issue.
> It seems that "mjpeg-trell-qprd-huffman" is missing here.
Removed the test instead since it's supposed to error.
---
Changelog| 1 +
doc/encoders.texi| 21 ++
libavcodec/Makefile
On Tuesday, January 31, 2017, Chris Cunningham
wrote:
>
> On Tue, Jan 31, 2017 at 1:07 AM, wm4 > wrote:
>
>> On Tue, 31 Jan 2017 09:57:24 +0100
>> wm4 > > wrote:
>>
>> > On Mon, 30 Jan 2017 17:05:49 -0800
>> > Chris Cunningham > > wrote:
>> >
>> > > Blocks are marked as key frames whenever the "
Hello,
On Wed, 1 Feb 2017, at 05:14, compn wrote:
> videolan has been having trouble with it for a while. you can see posts
> on the internet complaining about the automatic vlc bug reporter also
> being down because of this.
Not at all. Those are 2 complete different services and streams is
work
On Wed, 1 Feb 2017 00:09:41 -0500
compn wrote:
> not sure if this is the right way to do it, maybe its easier to ask for
> someone on twitter?
>
> it would be nice to have a backup just in case videolan has problems.
> then we dont have to ask users to use datafilehost heh.
>
> i dont want to b
On Tue, 31 Jan 2017 22:12:24 +0100
Timo Rothenpieler wrote:
> > IIRC, past conversations on this have concluded that the 'avconv'
> > rewrite will allow this by
> > avoiding the current problem that the encoder is fully initialised up
> > front before the cuvid
> > parser can run. Presumably, at
On Tue, 31 Jan 2017 12:02:01 -0800
Chris Cunningham wrote:
> Thanks for taking a look.
>
> Definitely missing a "break;" - will fix in subsequent patch.
>
> Agree timestamps should be relative (didn't realize this). Vignesh points
> out that "0" in the test file is due to a bug in ffmpeg (and p
not sure if this is the right way to do it, maybe its easier to ask for
someone on twitter?
it would be nice to have a backup just in case videolan has problems.
then we dont have to ask users to use datafilehost heh.
i dont want to burden ffmpeg admins to maintain some ftp either.
carl, what do
On Tue, 31 Jan 2017 13:09:07 +0100
Thilo Borgmann wrote:
> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it
> is not the place to upload things then these messages should be
> changed accordingly and the preferred way to upload samples need to
> be documented.
currently uplo
I have a mpegts file with a HE-AAC audio track that cannot be decoded by
ffmpeg. I have uploaded a sample at the link below, as requested by the
decoder.
Happy to help with a patch to fix this issue, if someone can point me in
the right direction. FWIW, VLC is able to decode the audio without issu
The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.
Normality Hypothesis Test:
The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean clo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 31 Jan 2017 14:43:24 +0100
Michael Niedermayer wrote:
> On Sun, Jan 29, 2017 at 01:11:51PM -0800, Philip Langdale wrote:
> > Signed-off-by: Philip Langdale
> > ---
> > libswscale/input.c| 32
> >
This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h
Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have b
First (and probably last) Opus encoder not to use anything from libopus, woot.
Need help with striding the MDCT so I can do in place transient MDCTs.
Need help/ideas for a faster PVQ search algorithm.
Sounds good though.
Rostislav Pehlivanov (6):
opus_rc: rename total_bits_used to total_bits an
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/opus_celt.c | 2 +-
libavcodec/opus_rc.c | 19 +--
libavcodec/opus_rc.h | 6 +++---
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index c115ee7ad3..96fedb7a4
A huge amount can be reused by the encoder, as the only thing
which needs to be done would be to add a 10 line celt_icwrsi,
a wrapper around it (celt_alg_quant) and templating the
ff_celt_decode_band to replace entropy decoding functions
with entropy encoding.
There is no performance loss but in f
Mostly used the RFC document, the decoding functions and
the reference encoder's implmenentation as a reference.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/opus_rc.c | 182 ++-
libavcodec/opus_rc.h | 35 --
2 files changed, 212 ins
The stride parameter does not currently do anything.
I can't figure out how to stride since the damn post-rotation
happens from the middle and goes both up and down at the same time.
Signed-off-by: Rostislav Pehlivanov
---
configure| 6 +-
libavcodec/Makefile | 2
This marks the first time anyone has written an Opus encoder without
using any libopus code. The aim of the encoder is to prove how far
the format can go by writing the craziest encoder for it.
The encoder's pretty basic, it supports nearly all the features
that CELT has (except the pitch prefilte
On 2017-02-01 12:34, Marton Balint wrote:
No, your code is not yet committed to the ffmpeg master repository, I
am not sure which github repo you are referring to. So you might still
change your mind. Also I plan to squash your two patches into one.
I managed to stuff up (and misuse) my local r
On 31.01.2017 13:45, Ronald S. Bultje wrote:
> I don't want this patch. I also don't want to discuss it further. Please
> remove the log message. Thank you.
For the sake of ending this, I've removed them.
Please avoid complaining about log messages for my future patches. Thank you.
Best regards,
On Wed, 1 Feb 2017, Lucas Sandery wrote:
On 2017-02-01 08:47, Marton Balint wrote:
On Tue, 31 Jan 2017, Lucas Sandery wrote:
On 2017-01-31 11:28, Marton Balint wrote:
On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of
playback windows
On 31.01.2017 15:13, Michael Niedermayer wrote:
> On Tue, Jan 31, 2017 at 01:59:38AM +0100, Andreas Cadhalpun wrote:
>> The code relies on their validity and otherwise can try to access a NULL
>> object->rle pointer, causing segmentation faults.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> li
On 31.01.2017 09:43, Steinar H. Gunderson wrote:
> On Tue, Jan 31, 2017 at 01:57:31AM +0100, Andreas Cadhalpun wrote:
>>> This sounds like a strangeness in constructing the table, which shouldn't be
>>> papered over in the inner loop of the decoder.
>> Maybe, I don't know what the contents of the t
On 09/12/2016 11:54, PHILIP DE NIER wrote:
> Hi,
> Attached patch fixes issue #6007 for me.
> I think it could improved / extended because the "if (s->seekable ==
> -1 && (!s->is_akamai || s->content_range_len != 2147483647))" is
> probably better placed http_read_header along with the similar
> is
On Tue, Jan 31, 2017 at 08:27:41PM -0300, James Almer wrote:
> On 1/31/2017 7:12 PM, Michael Niedermayer wrote:
> > On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
> >> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> >>> The assumtation this is based on is wrong, the code is not alw
From: Aman Gupta
Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
---
libavfilter/Makefile | 8 +--
libavfilter/scale.c | 143 +++
libavfilter/scale.h |
On 2017-02-01 08:47, Marton Balint wrote:
On Tue, 31 Jan 2017, Lucas Sandery wrote:
On 2017-01-31 11:28, Marton Balint wrote:
On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of
playback windows into other programs. It would improve the lo
On 1/31/2017 7:12 PM, Michael Niedermayer wrote:
> On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
>> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
>>> The assumtation this is based on is wrong, the code is not always run with
>>> bitexact flags
Assumption not assumtation. Missed
On Tue, 31 Jan 2017, Lucas Sandery wrote:
On 2017-01-31 11:28, Marton Balint wrote:
On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of playback
windows into other programs. It would improve the looks in many situations
and avoid ugly ha
On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> > The assumtation this is based on is wrong, the code is not always run with
> > bitexact flags
> >
> > This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
> > cha
On 31/01/17 21:00, Aman Gupta wrote:
> On Tue, Jan 31, 2017 at 12:26 PM, Mark Thompson wrote:
>
>> On 31/01/17 19:14, Aman Gupta wrote:
>>> From: Aman Gupta
>>>
>>> Copied directly from vf_scale.c.
>>>
>>> Implements the same expression logic, however not all the variables were
>> copied over.
>
> IIRC, past conversations on this have concluded that the 'avconv'
> rewrite will allow this by
> avoiding the current problem that the encoder is fully initialised up
> front before the cuvid
> parser can run. Presumably, at some point in the future, we'll get
> through the merge backlog
> and ev
On Tue, Jan 31, 2017 at 12:26 PM, Mark Thompson wrote:
> On 31/01/17 19:14, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > Copied directly from vf_scale.c.
> >
> > Implements the same expression logic, however not all the variables were
> copied over.
> > This patch was sufficient for my particu
On 1/31/2017 5:09 PM, Michael Niedermayer wrote:
> The code is not just used by VP3, the optimizations have primarly an effect
> on VP3
> but are used by other codecs too when available.
>
> This reverts commit ca8a3978e57c7c8f6abab8547f47483e407469b7, reversing
> changes made to 481884080977f158
On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> The assumtation this is based on is wrong, the code is not always run with
> bitexact flags
>
> This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
> changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
> ---
> libavcode
On 31/01/17 19:14, Aman Gupta wrote:
> From: Aman Gupta
>
> Copied directly from vf_scale.c.
>
> Implements the same expression logic, however not all the variables were
> copied over.
> This patch was sufficient for my particular use-case
> `scale_vaapi=-2:min(ih\,720)`,
> but perhaps it make
From: Aman Gupta
Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete
and before the file is added to the m3u8 playlist.
This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding w
On 2017-01-31 07:45, wm4 wrote:
On Tue, 31 Jan 2017 15:38:33 +
Sumit Agarwal wrote:
From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
From: sumit
Date: Tue, 31 Jan 2017 21:00:50 +0530
Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid
---
ffmpeg_cuv
The code is not just used by VP3, the optimizations have primarly an effect on
VP3
but are used by other codecs too when available.
This reverts commit ca8a3978e57c7c8f6abab8547f47483e407469b7, reversing
changes made to 481884080977f15854fe06e1c742a7741e49555c.
---
libavcodec/x86/Makefile
On Tue, Jan 31, 2017 at 1:07 AM, wm4 wrote:
> On Tue, 31 Jan 2017 09:57:24 +0100
> wm4 wrote:
>
> > On Mon, 30 Jan 2017 17:05:49 -0800
> > Chris Cunningham wrote:
> >
> > > Blocks are marked as key frames whenever the "reference" field is
> > > zero. This is incorrect for non-keyframe Blocks th
The assumtation this is based on is wrong, the code is not always run with
bitexact flags
This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
---
libavcodec/x86/hpeldsp.h | 2 +-
libavcodec/x86/hpeldsp_init.c
From: Aman Gupta
Copied directly from vf_scale.c.
Implements the same expression logic, however not all the variables were copied
over.
This patch was sufficient for my particular use-case
`scale_vaapi=-2:min(ih\,720)`,
but perhaps it makes sense to add support for the remaining variables
and
2017-01-31 17:00 GMT+01:00 Petri Hintukainen :
> I think I posted HDMV text subtitle decoder patch year+ ago. But I
> can't find it from list archives (?).
I suspect because you didn't sent it =-(
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178194.html
Thank for for providing it now!
On 1/31/17, Petri Hintukainen wrote:
> Hello,
>
> I think I posted HDMV text subtitle decoder patch year+ ago. But I
> can't find it from list archives (?).
>
> I'll attach the original patch for reference / documentation of the
> format.
> There's also more complete implementation (text styles, p
On Mon, 30 Jan 2017 15:58:12 +0100, Clément Bœsch wrote:
> ---
> doc/lexicon | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 doc/lexicon
>
> diff --git a/doc/lexicon b/doc/lexicon
> new file mode 100644
> index 00..36ff803fb5
> --- /dev/null
> +++ b
DogFilm wrote:
I am still waitinng for an upload facility. Please send me an email so I
can follow this.
You have a gmail address so I guess you have google drive.
Assuming you have the free version then upload size limit is too small
for 1.6 gig.
You could upload in two parts and post the 2
> On Tue, Jan 31, 2017 at 06:28:16PM +0100, Michael Niedermayer wrote:
> > On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> > > patch looks good to me.
> >
> > applied
>
> maybe i asked already but it seems the Author field of your commits is
> inconsistet in git
>
> some say:
> A
On Tue, Jan 31, 2017 at 06:29:03PM +0100, Paul B Mahol wrote:
> On 1/31/17, Michael Niedermayer wrote:
> > On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
> >> On 1/31/17, Michael Niedermayer wrote:
> >> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> >> >> Only lo
In many uses of av_expr_free() the pointer is NULLed afterwards, this should
allow simplifying such code
TODO: add bump& APIChanges
Signed-off-by: Michael Niedermayer
---
libavutil/eval.c | 7 +++
libavutil/eval.h | 6 ++
2 files changed, 13 insertions(+)
diff --git a/libavutil/eval.c
On Tue, Jan 31, 2017 at 06:28:16PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> > patch looks good to me.
>
> applied
maybe i asked already but it seems the Author field of your commits
is inconsistet in git
some say:
Author: erankor
some s
On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> patch looks good to me.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Soc
On 1/31/17, Michael Niedermayer wrote:
> On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
>> On 1/31/17, Michael Niedermayer wrote:
>> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
>> >> Only lossy part is decoded for now.
>> >>
>> >> Signed-off-by: Paul B Mahol
>>
On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
> On 1/31/17, Michael Niedermayer wrote:
> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> >> Only lossy part is decoded for now.
> >>
> >> Signed-off-by: Paul B Mahol
> >> ---
> > [...]
> >> static int oma_read_pack
On Mon, Jan 30, 2017 at 01:49:00AM +0100, Michael Niedermayer wrote:
> It seems ive written this thing though i cannot really remember
>
> Signed-off-by: Michael Niedermayer
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B14
Hello,
I think I posted HDMV text subtitle decoder patch year+ ago. But I
can't find it from list archives (?).
I'll attach the original patch for reference / documentation of the
format.
There's also more complete implementation (text styles, positioning,
...) in libbluray: http://git.videolan.o
On Tue, 31 Jan 2017 15:38:33 +
Sumit Agarwal wrote:
> From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
> From: sumit
> Date: Tue, 31 Jan 2017 21:00:50 +0530
> Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid
>
> ---
> ffmpeg_cuvid.c | 2 +-
> 1 file
On Tue, Jan 31, 2017 at 2:12 AM Vittorio Giovara
wrote:
> On Sat, Jan 28, 2017 at 4:13 AM, James Almer wrote:
> > On 1/27/2017 11:21 PM, Aaron Colwell wrote:
> >> On Fri, Jan 27, 2017 at 5:46 PM James Almer wrote:
> >>
> >> yeah. I'm a little confused why the demuxing code didn't implement this
On Tue, 31 Jan 2017 15:22:17 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile| 2 +
> libavcodec/allcodecs.c | 2 +
> libavcodec/textst_parser.c | 49
> libavcodec/textstdec.c | 108
> +
Sorry, by mistake attached the wrong patch earlier. Please find attached the
correct patch now.
Regards,
Sumit
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Timo
Rothenpieler
Sent: Tuesday, January 31, 2017 8:30 PM
To: ffmpeg-devel@ffmpeg.or
On 1/31/17, Carl Eugen Hoyos wrote:
> 2017-01-31 15:22 GMT+01:00 Paul B Mahol :
>
>> +AVCodec ff_textst_decoder = {
>> +.name = "textst",
>> +.long_name = NULL_IF_CONFIG_SMALL("HDMV TextST subtitle"),
>
> Is this patch related to ticket #4481?
Yes!
_
2017-01-31 15:56 GMT+01:00 Sumit Agarwal :
> -hwframe_ctx->sw_format = ist->st->codecpar->format ==
> AV_PIX_FMT_YUV420P10LE ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
> +hwframe_ctx->sw_format = ist->st->codecpar->format ==
> AV_PIX_FMT_YUV420P10 ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
I
2017-01-31 15:22 GMT+01:00 Paul B Mahol :
> +AVCodec ff_textst_decoder = {
> +.name = "textst",
> +.long_name = NULL_IF_CONFIG_SMALL("HDMV TextST subtitle"),
Is this patch related to ticket #4481?
Thank you, Carl Eugen
___
ffmpeg
On 1/31/17, Michael Niedermayer wrote:
> On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
>> Only lossy part is decoded for now.
>>
>> Signed-off-by: Paul B Mahol
>> ---
> [...]
>> static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
>> {
>> OMAContext *oc = s->priv_
On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> Only lossy part is decoded for now.
>
> Signed-off-by: Paul B Mahol
> ---
[...]
> static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
> {
> OMAContext *oc = s->priv_data;
> -AVStream *st= s->streams[0];
> -
On 30.01.2017 04:54, Jerry Jiang wrote:
[...]
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index a51f16c..a325da9 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -213,11 +213,15 @@ fate-vsynth%-jpeg2000-97: DECINOPTS = -vcodec
jpeg2000
FATE_VCODEC-$(c
> Hi,
>
> Please review the attached patch which adds 420 10-bit transcode support for
> hwaccel cuvid.
>
> Sample Command:
> ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc output.265
>
> Thanks,
> Sumit
Are you sure the attached patch is complete?
All it does is replace AV
Hi,
Please review the attached patch which adds 420 10-bit transcode support for
hwaccel cuvid.
Sample Command:
ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc output.265
Thanks,
Sumit
---
This
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 2 +
libavcodec/allcodecs.c | 2 +
libavcodec/textst_parser.c | 49
libavcodec/textstdec.c | 108 +
libavformat/utils.c| 1 +
5 files changed, 162 i
On 31.01.2017 12:54, Michael Niedermayer wrote:
On Wed, Jan 18, 2017 at 10:27:03AM +0100, Tobias Rapp wrote:
Signed-off-by: Tobias Rapp
---
doc/muxers.texi | 33 +
1 file changed, 33 insertions(+)
LGTM
Pushed, thanks for the review.
Regards,
Tobias
__
On Tue, Jan 31, 2017 at 01:59:38AM +0100, Andreas Cadhalpun wrote:
> The code relies on their validity and otherwise can try to access a NULL
> object->rle pointer, causing segmentation faults.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/pgssubdec.c | 5 -
> 1 file changed, 4 ins
On Tue, Jan 31, 2017 at 07:45:56AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jan 30, 2017 at 8:52 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
> > Marton proposed a way to mitigate this [1], but you haven't commented
> > on it so far.
>
>
> It doesn't mitigate it.
On Sun, Jan 29, 2017 at 01:11:51PM -0800, Philip Langdale wrote:
> Signed-off-by: Philip Langdale
> ---
> libswscale/input.c| 32
> libswscale/swscale_unscaled.c | 4 +++-
> libswscale/utils.c| 2 ++
> 3 files changed, 37 insertions(+), 1
On 30 January 2017 at 03:54, Jerry Jiang wrote:
>Hey everyone,
>
>Sorry for the long wait, here's a new patch addressing the feedback. In
>addition, we discovered that this current implementation of optimal huffman
>encoding is not compatible with QP RD, so we chose to disable QP RD for
>mjpeg or
2017-01-31 14:06 GMT+01:00 Matteo Naccari :
> Re: On removal of malloc, free, etc. I think this v4 takes care of this as
> the commit messages says.
I don't think so.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/m
DogFilm wrote:
OK, please tell me a place where I can upload 1.6 GB video file and i will
do it, thanks!
"It is quite a normal
video downloaded from a public media library"
Link?
Maybe you can reproduce with a cut down by dd version?
free google drive IIRC has 1 gig upload limit, if you real
> That's pretty old by now. Can you send a v4 patch set?
Sorry my bad, I've already sent a v4 on the 14/12. Do you want me to rebase the
patch to the latest commit on the branch master?
Re: On removal of malloc, free, etc. I think this v4 takes care of this as the
commit messages says.
2017-01-31 13:47 GMT+01:00 DogFilm :
> The file is not available anymore, it was in the arte.tv online vod service
> but is not available anymore due to the legal requirement to remove content
> after seven days.
Please provide the command line that you tested and the complete, uncut
console outpu
2017-01-31 13:09 GMT+01:00 Thilo Borgmann :
> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it is not
> the place to
> upload things then these messages should be changed accordingly and the
> preferred
> way to upload samples need to be documented.
We have been promised re
> Or whatever necessary but in the end the message we show should actually
be a valid way for the user to proceed.
for me the experience felt like I would very much like if it ended in a
succesful way. it did not.
The link showing a dead ftp site btw destroyed my breakfast time as I was
trying to
2017-01-31 13:52 GMT+01:00 Carl Eugen Hoyos :
> 2017-01-31 13:42 GMT+01:00 Matteo Naccari :
>> Any news on the integration of the patch identified in the subject line?
>
> So far, you haven't removed the calls to malloc().
> Please use av_freep() (instead of av_free) to free the memory.
And pleas
2017-01-31 13:42 GMT+01:00 Matteo Naccari :
> Hello everyone,
>
> Any news on the integration of the patch identified in the subject line?
So far, you haven't removed the calls to malloc().
Please use av_freep() (instead of av_free) to free the memory.
Carl Eugen
_
On Tue, 31 Jan 2017 12:42:54 +
Matteo Naccari wrote:
> Hello everyone,
>
> Any news on the integration of the patch identified in the subject line?
>
> Best regards,
> Matteo
That's pretty old by now. Can you send a v4 patch set?
___
ffmpeg-devel
The file is not available anymore, it was in the arte.tv online vod service
but is not available anymore due to the legal requirement to remove content
after seven days.
On Tue, Jan 31, 2017 at 1:18 PM, Carl Eugen Hoyos
wrote:
> 2017-01-31 12:43 GMT+01:00 DogFilm :
>
> > I have a video here that
Hi,
On Mon, Jan 30, 2017 at 8:52 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Marton proposed a way to mitigate this [1], but you haven't commented
> on it so far.
It doesn't mitigate it. Source code is still an issue, as is binary size if
CONFIG_SMALL is off, which is the
Hello everyone,
Any news on the integration of the patch identified in the subject line?
Best regards,
Matteo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Am 31.01.17 um 13:17 schrieb wm4:
> On Tue, 31 Jan 2017 13:09:07 +0100
> Thilo Borgmann wrote:
>
>> Am 31.01.17 um 13:00 schrieb Paul B Mahol:
>>> On 1/31/17, DogFilm wrote:
Hi,
I have a video here that will make ffmpeg hang and eat all CPU without
doing any actual work and
2017-01-31 12:43 GMT+01:00 DogFilm :
> I have a video here that will make ffmpeg hang and eat all CPU without
> doing any actual work and produces a lot of errors. It is quite a normal
> video downloaded from a public media library
Where did you download the file from?
Carl Eugen
___
On Tue, 31 Jan 2017 13:09:07 +0100
Thilo Borgmann wrote:
> Am 31.01.17 um 13:00 schrieb Paul B Mahol:
> > On 1/31/17, DogFilm wrote:
> >> Hi,
> >>
> >> I have a video here that will make ffmpeg hang and eat all CPU without
> >> doing any actual work and produces a lot of errors. It is quite a
OK, please tell me a place where I can upload 1.6 GB video file and i will
do it, thanks!
On Tue, Jan 31, 2017 at 1:00 PM, Paul B Mahol wrote:
> On 1/31/17, DogFilm wrote:
> > Hi,
> >
> > I have a video here that will make ffmpeg hang and eat all CPU without
> > doing any actual work and produc
Am 31.01.17 um 13:00 schrieb Paul B Mahol:
> On 1/31/17, DogFilm wrote:
>> Hi,
>>
>> I have a video here that will make ffmpeg hang and eat all CPU without
>> doing any actual work and produces a lot of errors. It is quite a normal
>> video downloaded from a public media library, nothing special.
On Wed, Jan 18, 2017 at 10:27:03AM +0100, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp
> ---
> doc/muxers.texi | 33 +
> 1 file changed, 33 insertions(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whe
On 1/31/17, DogFilm wrote:
> Hi,
>
> I have a video here that will make ffmpeg hang and eat all CPU without
> doing any actual work and produces a lot of errors. It is quite a normal
> video downloaded from a public media library, nothing special.
>
> The error message asks me to upload the file t
Hi,
I have a video here that will make ffmpeg hang and eat all CPU without
doing any actual work and produces a lot of errors. It is quite a normal
video downloaded from a public media library, nothing special.
The error message asks me to upload the file to
ftp://upload.ffmpeg.org/incoming/ and
On Sat, Jan 28, 2017 at 4:13 AM, James Almer wrote:
> On 1/27/2017 11:21 PM, Aaron Colwell wrote:
>> On Fri, Jan 27, 2017 at 5:46 PM James Almer wrote:
>>
>> yeah. I'm a little confused why the demuxing code didn't implement this to
>> begin with.
>
> Vittorio (The one that implemented AVSpherica
2017-01-30 11:28 GMT+01:00 Paul B Mahol :
> On 1/30/17, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I suspect attached patch makes using the alac decoder easier with
>> non-FFmpeg demuxers.
>>
>> Please comment, Carl Eugen
>>
>
> lgtm
Patch applied.
Thank you, Carl Eugen
___
On 1/30/17, Moritz Barsnick wrote:
> Signed-off-by: Moritz Barsnick
> ---
> libavformat/xwma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
On Mon, Jan 30, 2017 at 11:44 PM, Thilo Borgmann wrote:
> Am 30.01.17 um 18:41 schrieb Umair Khan:
>> On Wed, Jan 25, 2017 at 5:45 PM, Thilo Borgmann
>> wrote:
>>> Am 25.01.17 um 06:14 schrieb Umair Khan:
On Wed, Jan 25, 2017 at 7:45 AM, Michael Niedermayer
wrote:
>
> On Mon,
On Tue, 31 Jan 2017 09:57:24 +0100
wm4 wrote:
> On Mon, 30 Jan 2017 17:05:49 -0800
> Chris Cunningham wrote:
>
> > Blocks are marked as key frames whenever the "reference" field is
> > zero. This is incorrect for non-keyframe Blocks that take a refernce
> > on a keyframe at time zero.
> >
> >
On Mon, 30 Jan 2017 17:05:49 -0800
Chris Cunningham wrote:
> Blocks are marked as key frames whenever the "reference" field is
> zero. This is incorrect for non-keyframe Blocks that take a refernce
> on a keyframe at time zero.
>
> Now using -1 to denote "no reference".
>
> Reported to chromium
On Tue, Jan 31, 2017 at 01:57:31AM +0100, Andreas Cadhalpun wrote:
>> This sounds like a strangeness in constructing the table, which shouldn't be
>> papered over in the inner loop of the decoder.
> Maybe, I don't know what the contents of the table should be, but the
> following
> are {-1, 0}: 32
1 - 100 of 101 matches
Mail list logo
