On Mon, Aug 31, 2015 at 8:31 AM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> > Does someone want to keep it?
>
> Was the question about the release branch or about
> master?
>
>> Yes, I want to keep it. It works much better for
>> me than the old one.
>
> All LAV users use t
Hendrik Leppkes gmail.com> writes:
> Seeking is broken with many more files with the old
> demuxer, in fact thats the most common complaint I got
> about asf with the old demuxer, seeking doesn't work.
Could you point me to an example?
> The new one improves seeking quite substantially on
>
Hendrik Leppkes gmail.com> writes:
> Please report or fix crashes
Weren't most reports ignored so far?
I ask because from a quick look, one of a dozen
samples in trac was fixed.
Or do I miss something?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg
Hi!
The encoder produces conforming and - if requested - lossless files,
it should not be marked experimental imo.
Why is memory consumption a specific issue for this encoder?
Please comment, Carl Eugen
diff --git a/Changelog b/Changelog
index d8c8a41..aeb94b8 100644
--- a/Changelog
+++ b/Chang
On Mon, Aug 31, 2015 at 10:02 AM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> Seeking is broken with many more files with the old
>> demuxer, in fact thats the most common complaint I got
>> about asf with the old demuxer, seeking doesn't work.
>
> Could you point me to an e
Hendrik Leppkes gmail.com> writes:
> Here is sample that seeks quite badly with the old
> demuxer, in playback it takes several seconds for the
> seek to catch up properly,
(Seconds or milliseconds? I can reproduce the issue
with time but not visually...)
> because it seeks to an absolutely
Hi!
I didn't test myself but iiuc, the aac encoder produces better
quality than all other libavcodec audio encoders and better
quality than the libvo-aac encoder that is not marked as
experimental, so the flag should be removed.
Please comment, Carl Eugen
__
On Mon, Aug 31, 2015 at 10:41 AM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> Here is sample that seeks quite badly with the old
>> demuxer, in playback it takes several seconds for the
>> seek to catch up properly,
>
> (Seconds or milliseconds? I can reproduce the issue
> w
Hendrik Leppkes gmail.com> writes:
> Seconds. The way seeking works in my app is that when
> user wants to seek to positon X, then the reference
> clock is set to X, and if the demuxer seeks to a
> wrong position, then it either has to read and decode
> a lot of frames until X is reached (whi
PES header size is 6 bytes (00 00 01 bf XX XX), not 0.
BluRay text subtitles use private stream 2.
---
libavformat/mpegts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index eac6d9e..625d473 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpe
Am Mo, 31.08.2015, 08:31 schrieb Carl Eugen Hoyos:
> Peter B. das-werkstatt.com> writes:
>
>> Replaced the reference files accordingly
>
> This cannot be done, we want to run fate (also)
> with old sources.
Hm. Now I'm confused...
I expected old sources to use old tests?
In my case, there are
On Mon, 31 Aug 2015 09:04:46 + (UTC)
Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
> > Seconds. The way seeking works in my app is that when
> > user wants to seek to positon X, then the reference
> > clock is set to X, and if the demuxer seeks to a
> > wrong position, t
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavformat/mpegts.c| 1 +
3 files changed, 9 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 12a6b54..b4cf79d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -516,6 +516,7 @@
On Mon, Aug 31, 2015 at 11:13 AM, Peter B. wrote:
>
>
> Am Mo, 31.08.2015, 08:31 schrieb Carl Eugen Hoyos:
>> Peter B. das-werkstatt.com> writes:
>>
>>> Replaced the reference files accordingly
>>
>> This cannot be done, we want to run fate (also)
>> with old sources.
>
> Hm. Now I'm confused...
Petri Hintukainen gmail.com> writes:
> +AV_CODEC_ID_HDMV_TEXT_SUBTITLE,
No, I believe we still "maintain" the fork, you
have to force a specific tag, something like
"TSTX" or whatever you like.
Will you also port the decoder?
Thank you, Carl Eugen
___
wm4 googlemail.com> writes:
> It's been said multiple times: the old code is
> terrible, while the new demuxer's code is actually
> maintainable.
Ok (I don't agree, but let's assume that for a moment):
But who is maintaining it?
Who is going through the user reports on trac and
fixing the iss
Am Mo, 31.08.2015, 11:22 schrieb Hendrik Leppkes:
> On Mon, Aug 31, 2015 at 11:13 AM, Peter B. wrote:
>>
>> In my case, there are files in "tests/ref/vsynth" that contain the
>> expected reference results from tests.
>>
>> If I only provide the changed the FATE makefiles, like "vcodec.mak", who
>>
Hendrik Leppkes gmail.com> writes:
> What should not be changed is the samples inside the
> FATE suite - if a change is needed, there should be
> a new sample with a new name - which is probably what
> Carl refers to.
Yes.
> But since these seem to be vsynth tests, no external
> samples fro
Hi!
Attached removes two unnecessary context variables on version bump, please
review.
Carl Eugen
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e83a374..4068ab6 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1396,6 +1396,7 @@ typedef struct AVFormatCont
On Mon, Aug 31, 2015 at 10:44 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> I didn't test myself but iiuc, the aac encoder produces better
> quality than all other libavcodec audio encoders and better
> quality than the libvo-aac encoder that is not marked as
> experimental, so the flag should be removed
Andy Furniss wrote:
I've just done a quick test converting 25i to 30i and the il way is
worse than yadif.
Of course it's just one test with a compressed SD sample which I
then deint and scale with mpv to see on an HD monitor.
I repeated with a better quality 40mbit HD 1080i30 x264 version of
Hendrik Leppkes gmail.com> writes:
> On Fri, Aug 28, 2015 at 11:05 AM, Carl Eugen Hoyos wrote:
> > Attached patch removes the framerate from the output shown
> > by the dnxhd encoder if bad properties were chosen:
> > The framerate is ignored and the table seems very difficult
> > to maintain and
Hi Michael,
On Sun, Aug 30, 2015 at 10:02 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Sun, Aug 30, 2015 at 08:53:37PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Aug 29, 2015 at 10:23 PM, Michael Niedermayer
> > wrote:
> >
> > > From: Michael Niedermayer
> > >
> > >
On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>
> I've just done a quick test converting 25i to 30i and the il way is
>> worse than yadif.
>>
>> Of course it's just one test with a compressed SD sample which I
>> then deint and scale with mpv to see on an HD monitor.
On Mon, 31 Aug 2015 07:11:38 -0400
"Ronald S. Bultje" wrote:
> Hi Michael,
>
> On Sun, Aug 30, 2015 at 10:02 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
> > On Sun, Aug 30, 2015 at 08:53:37PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Sat, Aug 29, 2015 at 10:23 PM,
Robert Krüger wrote:
On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss
wrote:
Andy Furniss wrote:
I've just done a quick test converting 25i to 30i and the il way
is
worse than yadif.
Of course it's just one test with a compressed SD sample which I
then deint and scale with mpv to see on an HD
On 30.08.2015 21:32, Michael Niedermayer wrote:
On Sun, Aug 30, 2015 at 07:06:44PM +0200, Peter B. wrote:
Hello,
I've been working on FATE tests for FFV1 in the past already [1]. My
tests didn't work on all platforms and therefore never made it upstream.
I think it's better if I try to provide
The only real major feature the encoder doesn't quite have working fine yet
is TNS, for which I have a patch which I will push later today.
Everything else works fine. There are some infinite loops happening with
non-default extreme settings (very high bitrates with low frequency cutoffs
with the f
On Mon, Aug 31, 2015 at 1:35 PM, Andy Furniss wrote:
> Robert Krüger wrote:
>
>> On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss
>> wrote:
>>
>> Andy Furniss wrote:
>>>
>>> I've just done a quick test converting 25i to 30i and the il way
>>> is
>>>
worse than yadif.
Of course it's
Ronald S. Bultje gmail.com> writes:
[...]
If this were all true, why don't you fork FFmpeg
and show us how it's done better?
Seriously: No matter which fair I visit, the users
always tell the same story. They liked avconv
because it promised so many things that could be
improved in FFmpeg a
Hi Carl,
On Mon, Aug 31, 2015 at 5:41 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached removes two unnecessary context variables on version bump, please
> review.
lgtm.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
Hi Ronald,
On 31.08.2015 00:14, Ronald S. Bultje wrote:
> On Sun, Aug 30, 2015 at 5:56 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 22.08.2015 19:58, Andreas Cadhalpun wrote:
>>> Without this fate-filter-join fails with
>>> FF_API_GET_CHANNEL_LAYOUT_COMPAT disabled.
On 8/31/15, Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> [...]
>
> If this were all true, why don't you fork FFmpeg
> and show us how it's done better?
>
> Seriously: No matter which fair I visit, the users
> always tell the same story. They liked avconv
> because it promised
Robert Krüger wrote:
OK, thanks for the sample. It is a very good sample for
interlacing/deinterlacing or also frame interpolation tests (e.g.
for testing mc_fps). Is is rights-free?
I made that some time ago from masters (so you can probably do better!)
The rights on the masters are "free" A
Hi Ronald,
On 31.08.2015 00:19, Ronald S. Bultje wrote:
> On Sat, Aug 22, 2015 at 1:57 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> This fixes building with FF_API_QSCALE_TYPE disabled.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/version.h | 3 ---
>>
On 31.08.2015 00:40, Paul B Mahol wrote:
> On 8/30/15, Andreas Cadhalpun wrote:
>> Hi,
>>
>> On 29.08.2015 04:28, Michael Niedermayer wrote:
>>> Its about 2 and a half month since 2.7
>>> if there are no objections then ill branch of release/2.8 from
>>> some revission prior to the next API bump a
Hi,
On Mon, Aug 31, 2015 at 7:49 AM, Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> [...]
>
> If this were all true, why don't you fork FFmpeg
> and show us how it's done better?
>
https://en.wikipedia.org/wiki/Reductio_ad_absurdum
Seriously: No matter which fair I visit, t
Hi Hendrik,
On 31.08.2015 01:29, Hendrik Leppkes wrote:
> On Mon, Aug 31, 2015 at 12:15 AM, Andreas Cadhalpun
> wrote:
>> Before the release we should decide what to do with the asf_o demuxer.
>> Since it still crashes often, it's probably best to just remove it.
>>
>> Does someone want to keep i
Hi Carl Eugen,
On 31.08.2015 08:31, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>>> Does someone want to keep it?
>
> Was the question about the release branch or about
> master?
Primarily about the release branch.
I wouldn't want to be responsible for security support
of t
Hi,
On Mon, Aug 31, 2015 at 8:09 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi Ronald,
>
> On 31.08.2015 00:19, Ronald S. Bultje wrote:
> > On Sat, Aug 22, 2015 at 1:57 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> This fixes building with F
Ronald S. Bultje gmail.com> writes:
> > If this were all true, why don't you fork FFmpeg
> > and show us how it's done better?
>
> https://en.wikipedia.org/wiki/Reductio_ad_absurdum
Sorry, I thought you would understand the joke (and
that this was no argument) without any tags.
(Particularly
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 4
libavfilter/vf_elbg.c | 59 ++-
2 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index b78cf90..dbc1106 100644
--- a/doc/filters.texi
Andreas Cadhalpun googlemail.com> writes:
> > Was the question about the release branch or about
> > master?
>
> Primarily about the release branch.
Then I suggest you remove the demuxer from the
release branch, I think LAV does not use releases.
Or does it?
Carl Eugen
_
On Mon, 31 Aug 2015 14:19:02 +0200
Andreas Cadhalpun wrote:
> Hi Hendrik,
>
> On 31.08.2015 01:29, Hendrik Leppkes wrote:
> > On Mon, Aug 31, 2015 at 12:15 AM, Andreas Cadhalpun
> > wrote:
> >> Before the release we should decide what to do with the asf_o
> >> demuxer. Since it still crashes of
Hi,
On Mon, Aug 31, 2015 at 8:40 AM, Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
> > > I really don't understand why we don't spend
> > > the time fixing real (user-reported) issues
> > > instead of discussing how "clean" an api can
> > > be...
> >
> > Because the two are not
Ronald S. Bultje gmail.com> writes:
> The academic argument for clean code is that it
> speeds up development.
But isn't the deeper issue that this wasn't true
for FFmpeg five years ago and still isn't?
(Or in other words: That this was always an
"academic" argument...)
Maybe because you did
On Mon, 31 Aug 2015 11:49:19 + (UTC)
Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> [...]
>
> If this were all true, why don't you fork FFmpeg
> and show us how it's done better?
Don't even go there.
> Seriously: No matter which fair I visit, the users
> always tell
compn mi.rr.com> writes:
> if only we could also also import asf demuxer
> from vlc...
Do you have an asf sample that works with vlc
but fails with FFmpeg?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/l
From: Clément Bœsch
---
I'm not sure I'm doing the correct thing here, but maybe that's just because my
samples aren't relevant.
TODO: doc
---
libavfilter/vf_codecview.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/libavfilter/v
On Mon, 31 Aug 2015 13:02:57 + (UTC)
Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> > The academic argument for clean code is that it
> > speeds up development.
>
> But isn't the deeper issue that this wasn't true
> for FFmpeg five years ago and still isn't?
> (Or in o
On 8/31/15, wm4 wrote:
> On Mon, 31 Aug 2015 11:49:19 + (UTC)
> Carl Eugen Hoyos wrote:
>
>> Ronald S. Bultje gmail.com> writes:
>>
>> [...]
>>
>> If this were all true, why don't you fork FFmpeg
>> and show us how it's done better?
>
> Don't even go there.
>
>> Seriously: No matter which fa
On Mon, Aug 31, 2015 at 2:08 PM, Andy Furniss wrote:
> Robert Krüger wrote:
>
> OK, thanks for the sample. It is a very good sample for
>> interlacing/deinterlacing or also frame interpolation tests (e.g.
>> for testing mc_fps). Is is rights-free?
>>
>
> I made that some time ago from masters (so
On Mon, Aug 31, 2015 at 03:17:22AM +0200, Peter B. wrote:
> Hi.
>
> I've now cleaned up a few things in the current FFV1 tests:
> - Changed "ffv1.X" to "ffv1-vX", removing necessity for vcodec argument.
> - Added linebreaks to FFV1 FATE tests for better readability.
> - Renamed pix_fmts wording in
On Mon, Aug 31, 2015 at 03:29:03PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> I'm not sure I'm doing the correct thing here, but maybe that's just because
> my
> samples aren't relevant.
>
> TODO: doc
> ---
> libavfilter/vf_codecview.c | 43
On Mon, Aug 31, 2015 at 04:30:47PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 31, 2015 at 03:29:03PM +0200, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > ---
> > I'm not sure I'm doing the correct thing here, but maybe that's just
> > because my
> > samples aren't relevant.
> >
> >
On Mon, Aug 31, 2015 at 03:29:03PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> I'm not sure I'm doing the correct thing here, but maybe that's just because
> my
> samples aren't relevant.
i tried
./ffplay tests/data/fate/vsynth1-mpeg4-qprd.avi -debug 8192
./ffplay tests/data/fat
On Mon, Aug 31, 2015 at 12:17:23PM +0300, Petri Hintukainen wrote:
> ---
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +++
> libavformat/mpegts.c| 1 +
> 3 files changed, 9 insertions(+)
do you have a small testcase for this ?
or how can this be tested ?
[...]
--
Micha
Michael Niedermayer gmx.at> writes:
> do you have a small testcase for this ?
See ticket #4481 and vlc ticket 13888 that is now 15179.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/vf_spp.c | 98 ++--
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/libavfilter/vf_spp.c b/libavfilter/vf_spp.c
index b75f5f3..990fea3 100644
--- a/libavfilter/vf_spp.c
+++ b/libavfil
wm4 googlemail.com> writes:
> Or maybe you just don't know better.
Certainly true for both of us...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi!
Attached patch fixes ticket #4812 for Robert, I suspect it
will not fix all use-cases but maybe it is a good start?
Carl Eugen
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index a1a19bb..545e2b7 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -374,6 +374,1
On Mon, Aug 31, 2015 at 6:59 AM, Robert Krüger wrote:
> On Mon, Aug 31, 2015 at 10:44 AM, Carl Eugen Hoyos wrote:
>
>> Hi!
>>
>> I didn't test myself but iiuc, the aac encoder produces better
>> quality than all other libavcodec audio encoders and better
>> quality than the libvo-aac encoder that
Le quartidi 14 fructidor, an CCXXIII, Ronald S. Bultje a écrit :
> We're about to add FF_QSCALE_TYPE_MPEG1 to libavutil, and it's part of our
> intra-library ABI so we can't change it unless we bump majors, even though
> it's in internal.h.
I mostly agree to the general stance of this discussion a
On Mon, Aug 31, 2015 at 05:28:12PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4812 for Robert, I suspect it
> will not fix all use-cases but maybe it is a good start?
>
> Carl Eugen
> vf_scale.c |4
> 1 file changed, 4 insertions(+)
> 7a4374034719c004e2e0616
Please find attached the patch for ExtraData computation for aac in -acodec
copy. With audio codec copy, there is no extradata computation and RTMP fails
with no audio in playback.
Here is the command-line used for testing and verfication:
/opt/ripcode/bin/ffmpeg -copyts -i /root/ModernFamilyV
File avc.c ff_isom_write_avcc()
The implementation is:
--
avio_w8(pb, 1); /* version */
avio_w8(pb, sps[1]); /* profile */
avio_w8(pb, sps[2]); /* profile compat */
avio_w8(pb, sps[3]); /* level */
avio_w8(pb, 0xff); /* 6 bits
Hi guys!
My internship is finished (5 days ago) (if you still don't know: I was your
Outreachy intern;)). It was a great time with this project, thank you!
Thank you for all jokes on irc, all answers, all silly questions which
showed me that it's normal (to ask silly questions).
If you want to r
Signed-off-by: Marton Balint
---
doc/fftools-common-opts.texi | 6 --
libavformat/utils.c | 12 +---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 3b85813..40ace30 100644
--- a/doc/fftools-co
When use %s parameter for the segment filename, it will get error message
with Invalid
segment filename template, so add the use_localtime option fix it, the
default value is
14 for the segment filename.
the test example:
./ffmpeg -re -i ~/Movies/objectC/facebook.mp4 -v verbose -c copy -f
On 08/31/2015 01:44 PM, Tobias Rapp wrote:
> On 30.08.2015 21:32, Michael Niedermayer wrote:
>>> - Target "fate-vsynth%-*" tests default to sws_flags
>>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
>>
>> it makes more cases lossless IIRC
>> the default upscaling + defa
Hi,
On 31.08.2015 14:32, Ronald S. Bultje wrote:
> On Mon, Aug 31, 2015 at 8:09 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> These defines are used in libavcodec and libavfilter.
>> Since libavfilter only uses them for ff_norm_qscale, we could also move
>> that
>> to libav
On 31.08.2015 14:47, Carl Eugen Hoyos wrote:
> Andreas Cadhalpun googlemail.com> writes:
>
>>> Was the question about the release branch or about
>>> master?
>>
>> Primarily about the release branch.
>
> Then I suggest you remove the demuxer from the
> release branch,
That could be done, if n
On 31.08.2015 14:55, compn wrote:
> On Mon, 31 Aug 2015 14:19:02 +0200
> Andreas Cadhalpun wrote:
>> On 31.08.2015 01:29, Hendrik Leppkes wrote:
>>> On Mon, Aug 31, 2015 at 12:15 AM, Andreas Cadhalpun
>>> wrote:
Before the release we should decide what to do with the asf_o
demuxer. Sinc
Instead of returning EINVAL, which can cause a stream to fail to load, this
allows the tag to be passed through to the flv demuxer, where it's summarily
ignored.
---
libavformat/rtmppkt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index c474fb
On Mon, Aug 31, 2015 at 11:57 PM, Andreas Cadhalpun
wrote:
> On 31.08.2015 14:55, compn wrote:
>> On Mon, 31 Aug 2015 14:19:02 +0200
>> Andreas Cadhalpun wrote:
>>> On 31.08.2015 01:29, Hendrik Leppkes wrote:
On Mon, Aug 31, 2015 at 12:15 AM, Andreas Cadhalpun
wrote:
> Before the r
Arthur Grant gmail.com> writes:
> The part "if (profile_idc == 100) ..." is missing.
You forgot to attach your patch (made with git format-patch).
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
76 matches
Mail list logo
