Figured it out. Valgrind was pretty helpful.
Thanks again.
-Niklesh
On Sat, Jul 4, 2015 at 12:40 AM, Niklesh Lalwani
wrote:
> Thanks guys, I'll try it out.
>
> -Niklesh
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote:
> Hi all
>
> It is POSSIBLE that we need to move to different servers/hosting.
> We have been informed that the free hosting and servers we use
> currently may become unavailable in the future.
>
> Thus if someone can provide th
On Sat, Jul 04, 2015 at 12:45:18PM +0200, Michael Niedermayer wrote:
> On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > It is POSSIBLE that we need to move to different servers/hosting.
> > We have been informed that the free hosting and servers we use
> > cu
Hello All,
There is patch which fixes too strong frame height rounding for case
when progressive frame sequence encodes by QSV.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-libavcodec-qsvenc.c.patch
Description: Binary data
__
On Sat, Jul 4, 2015 at 2:38 PM, Ivan Uskov wrote:
> Hello All,
>
> There is patch which fixes too strong frame height rounding for case
> when progressive frame sequence encodes by QSV.
Is there any harm in always using 32 alignment for the height?
Because the flag you are checking there is not c
Hello Hendrik,
The harm of hard-coded alignment 32 that typical 1280x720 progressive
video should be encoded as 1280x736. I.e. absolutely superfluous
stripe of macroblocks should be encoded.
I can see that CODEC_FLAG_INTERLACED_DCT currently checks into
dnxhddata.c
dnxhdenc.c
dvenc.c
libx264.c
lib
On Sat, Jun 27, 2015 at 7:18 PM, Ganesh Ajjanagadde wrote:
> On Sat, Jun 27, 2015 at 9:49 AM, Ganesh Ajjanagadde wrote:
>> On Sat, Jun 27, 2015 at 2:22 AM, Hendrik Leppkes wrote:
>>> On Sat, Jun 27, 2015 at 3:09 AM, Ganesh Ajjanagadde
>>> wrote:
Fixes Ticket4673
Signed-off-by: Ga
On Sat, 4 Jul 2015 10:02:14 -0400
Devin Heitmueller wrote:
> > note, to make this clear there will be no ffmpeg.org or mplayerhq.hu
> > soon if noone helps
> > we need a server we need volunteers to help with the move
>
> Is there anything you can share about what the current bandwidth
> require
I fixed brackets and added dependency on fate-lavf to be sure that lavf.flv
exists.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Works only with video stream.
---
tests/api/Makefile| 1 +
tests/api/api-seek-test.c | 194 ++
tests/fate/api.mak| 4 +
tests/ref/fate/api-seek | 147 +++
4 files changed, 346 insertions(+)
create mo
> note, to make this clear there will be no ffmpeg.org or mplayerhq.hu
> soon if noone helps
> we need a server we need volunteers to help with the move
Is there anything you can share about what the current bandwidth
requirements are? It might make it easier to assess whether it's
feasible to ho
compn wrote:
On Sat, 4 Jul 2015 10:02:14 -0400
Devin Heitmueller wrote:
note, to make this clear there will be no ffmpeg.org or mplayerhq.hu
soon if noone helps
we need a server we need volunteers to help with the move
Is there anything you can share about what the current bandwidth
requirem
On Sat, Jul 04, 2015 at 01:15:51PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 04, 2015 at 12:45:18PM +0200, Michael Niedermayer wrote:
> > On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > It is POSSIBLE that we need to move to different servers/hos
13 matches
Mail list logo
