2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
>>
>> Should changes ported from libav (what we call merges) be reviewed
>> before being pushed?
>
> I've asked about this on IRC (#ffmpeg-devel). The overall consensus there,
> at least at the time I ask
On Mon, 24 Apr 2017 10:46:38 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
> >>
> >> Should changes ported from libav (what we call merges) be reviewed
> >> before being pushed?
> >
> > I've asked about this on
Hi,
On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
> On Mon, 24 Apr 2017 10:46:38 +0200
> Carl Eugen Hoyos wrote:
> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
> > >>
> > >> Should changes ported from libav (what we call merges) be reviewed
>
From: Shivraj Patil
Signed-off-by: Shivraj Patil
---
configure |4
1 file changed, 4 insertions(+)
diff --git a/configure b/configure
index 1e3463c..c63a48a 100755
--- a/configure
+++ b/configure
@@ -5357,6 +5357,10 @@ elif enabled mips; then
enabled mipsdsp && check_inline_asm_f
2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
>
>> On Mon, 24 Apr 2017 10:46:38 +0200
>> Carl Eugen Hoyos wrote:
>> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
>> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
>> > >>
>> > >> Should cha
- This patch contains the changes to interface the Turing codec
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the
comments in the review as follows:
- Added a pkg-config file to list all dependencies required by libturing.
This should address the issue pointed out by
On Mon, 24 Apr 2017 15:23:20 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
> >
> >> On Mon, 24 Apr 2017 10:46:38 +0200
> >> Carl Eugen Hoyos wrote:
> >> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
2017-04-24 15:38 GMT+02:00 wm4 :
> On Mon, 24 Apr 2017 15:23:20 +0200
> Carl Eugen Hoyos wrote:
>
>> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
>> > Hi,
>> >
>> > On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
>> >
>> >> On Mon, 24 Apr 2017 10:46:38 +0200
>> >> Carl Eugen Hoyos wrote:
>> >> > 20
On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> Hi all
>
> Should changes ported from libav (what we call merges) be reviewed
> before being pushed?
The lot of merges are simple things like "Fix this bug that was already
fixed in ffmpeg months ago", "K&R", etc. Lately we are even no-oping a
g
On 4/24/2017 12:50 AM, Aaron Levinson wrote:
> For example, I submitted a patch to fix a bug with QuickSync interlaced
> video to ffmpeg-devel on 4/13/2017. The change mostly reverted some of
> the QSV code in ffmpeg back to an earlier state. Interlaced video QSV
> encoding used to work in ffmpeg
On Sun, 23 Apr 2017 20:50:38 -0700
Aaron Levinson wrote:
> properly review some of the ported changes on ffmpeg-devel. For
> example, I submitted a patch to fix a bug with QuickSync interlaced
> video to ffmpeg-devel on 4/13/2017. The change mostly reverted some of
> the QSV code in ffmpeg b
Patch attached.
0001-minterpolate-added-codec_me_mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 4/24/17, Davinder Singh wrote:
> Patch attached.
>
So this encodes video frames to generate motion vectors?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
It's not standard but mentionned on:
http://en.wikipedia.org/wiki/Gopher_%28protocol%29#Gopher_item_types
It's used at least on:
gopher://sdf.org/1/sdf/historical
(commercial.mp3)
---
libavformat/gopher.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/gopher.c b/libavformat/gophe
On Mon, 24 Apr 2017 16:00:41 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 15:38 GMT+02:00 wm4 :
> > On Mon, 24 Apr 2017 15:23:20 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> >> > Hi,
> >> >
> >> > On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
> >> >
On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> > Hi all
> >
> > Should changes ported from libav (what we call merges) be reviewed
> > before being pushed?
>
> The lot of merges are simple things like "Fix this bug that was alrea
This is needed to get compatibility with the behavior before the
recent decode.c restructuring merge, and fixes fate failures with
this:
make fate-h264-attachment-631 THREADS=32
For every 4 threads, a frame is dropped at the point at which
draining is initialized. The problem starts at THREADS=
On Mon, 24 Apr 2017 20:27:45 +0200
Michael Niedermayer wrote:
> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> > On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > Should changes ported from libav (what we call merges) be reviewed
> > > before being push
On Mon, 24 Apr 2017, Michael Niedermayer wrote:
On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
We have recently been able to go through six hundred or so commits in a
month or two this way after being stuck for the longest time by a few of
those big API changes. If we start requ
On 4/24/2017 4:08 PM, wm4 wrote:
> On Mon, 24 Apr 2017 20:27:45 +0200
> Michael Niedermayer wrote:
>
>> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
>>> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
Hi all
Should changes ported from libav (what we call merges)
> On Apr 22, 2017, at 4:29 PM, Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_datascope.c | 218 +++--
> 3 files changed, 213 insertions(+), 7 deletions(-
On Mon, 24 Apr 2017 16:19:00 -0300
James Almer wrote:
> On 4/24/2017 4:08 PM, wm4 wrote:
> > On Mon, 24 Apr 2017 20:27:45 +0200
> > Michael Niedermayer wrote:
> >
> >> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> >>> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
>
On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
Marton Balint wrote:
> On Mon, 24 Apr 2017, Michael Niedermayer wrote:
> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
>
> >> We have recently been able to go through six hundred or so commits in a
> >> month or two this way after bein
[sorry for re-sending; but still looking for review. Thanks!]
Hi,
This patch aims to reduce the number of input/output surfaces NVENC allocates
per session. Previous default sets allocated surfaces to 32 (unless there is
user specified param or lookahead involved). Having large number of sur
On Sat, Apr 22, 2017 at 02:23:08AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> Makefile | 4
> configure | 12
> tools/Makefile| 10 ++
> tools/target_dec_fuzzer.c | 12
> 4 fil
On 4/24/17, Dave Rice wrote:
>
> I tested this filter and find it very useful, but could it be adjusted to
> handle full range video. Currently when I test with a sample such as:
>
> ./ffplay -f lavfi -i
> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
>
> The outputs list
> On Apr 24, 2017, at 4:47 PM, Paul B Mahol wrote:
>
> On 4/24/17, Dave Rice wrote:
>>
>> I tested this filter and find it very useful, but could it be adjusted to
>> handle full range video. Currently when I test with a sample such as:
>>
>> ./ffplay -f lavfi -i
>> color=c=white:s=640x480,fo
On 4/24/17, Dave Rice wrote:
>
>> On Apr 24, 2017, at 4:47 PM, Paul B Mahol wrote:
>>
>> On 4/24/17, Dave Rice wrote:
>>>
>>> I tested this filter and find it very useful, but could it be adjusted to
>>> handle full range video. Currently when I test with a sample such as:
>>>
>>> ./ffplay -f la
-- KongQun Yang (KQ)
On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes
wrote:
> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes
> wrote:
> > This brings our generation of the vpcC box up to date to version 1.0
> > of the VP Codec ISO Media File Format Binding.
> >
> > Specifically, color/transf
On 4/24/2017 6:48 PM, KongQun Yang wrote:
> -- KongQun Yang (KQ)
>
> On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes
> wrote:
>
>> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes
>> wrote:
>>> This brings our generation of the vpcC box up to date to version 1.0
>>> of the VP Codec ISO Media F
On 4/23/2017 8:27 PM, Aaron Levinson wrote:
> On 4/22/2017 10:26 AM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/options.c | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/libavcodec/options.c b/libavcodec/options.c
>> index b98da
Signed-off-by: James Almer
---
No changes since last version.
libavcodec/options.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 7bdb0be5af..b98da9378a 100644
--- a/libavcodec/options.c
+++ b
Free coded_frame, coded_side_data and unref hw_device_ctx to prevent
potential leaks.
Signed-off-by: James Almer
---
libavcodec/options.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index b98da9378a..82e12179a6 100644
--- a/lib
On Fri, Apr 21, 2017 at 8:40 AM, Derek Buitenhuis
wrote:
> The WebM DASH spec states:
> The Initialization Segment shall not contain Clusters or Cues.
> The Segment Index corresponds to the Cues.
>
> Previously, it included the cues if they were at the front.
Looks good. Thanks.
>
> Sign
i apologize in advance for replying to this email and not carls, but
be assured i am replying to both carl and wm4 here.
On Mon, 24 Apr 2017 19:13:32 +0200, wm4 wrote:
> On Mon, 24 Apr 2017 16:00:41 +0200
> Carl Eugen Hoyos wrote:
> > 2017-04-24 15:38 GMT+02:00 wm4 :
> > > On Mon, 24 Apr 2017 15
On Thu, Apr 20, 2017 at 7:02 AM, Derek Buitenhuis
wrote:
> The original author apparently never read the documentation for snprintf,
> or even tested that the output was correct.
I was the original author and i am sorry about the mistake.
> Passing overlapping memory
> to snprintf causes undefin
as a few developers have wondered...
how is our project to judge, report and punish coc violations?
since we had a vote to approve of the COC, we will probably need
another vote to approve of the COC rules.
do you want group consensus?
how big of a group? whos in the group?
who wants to do a bun
On 4/24/2017 5:05 PM, Compn wrote:
as a few developers have wondered...
how is our project to judge, report and punish coc violations?
since we had a vote to approve of the COC, we will probably need
another vote to approve of the COC rules.
do you want group consensus?
how big of a group? who
On 2017-04-08 09:05 PM, Micah Galizia wrote:
Is there something I can do to get this reviewed?
Thanks in advance.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 25 April 2017 at 01:26, Aaron Levinson wrote:
> On 4/24/2017 5:05 PM, Compn wrote:
>
>> as a few developers have wondered...
>>
>> how is our project to judge, report and punish coc violations?
>>
>> since we had a vote to approve of the COC, we will probably need
>> another vote to approve of
On Mon, Apr 24, 2017 at 06:19:13PM +0200, François Revol wrote:
> It's not standard but mentionned on:
> http://en.wikipedia.org/wiki/Gopher_%28protocol%29#Gopher_item_types
>
> It's used at least on:
> gopher://sdf.org/1/sdf/historical
> (commercial.mp3)
> ---
> libavformat/gopher.c | 1 +
> 1 f
On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
> This is needed to get compatibility with the behavior before the
> recent decode.c restructuring merge, and fixes fate failures with
> this:
>
> make fate-h264-attachment-631 THREADS=32
>
> For every 4 threads, a frame is dropped at the point at whic
42 matches
Mail list logo
