date:20160620

Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)

2016-06-20 Thread Eric Beuque

2016-06-20 0:35 GMT+02:00 Ivan Kalvachev :

> On 6/17/16, Eric Beuque  wrote:
> > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer :
> >
> >> On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
> >> > Hi,
> >> >
> >> > i'm posting here for a feature that is missing in ffmpeg (or may be i
> >> > missed something), which consist of decoding H.264 frame with a
> scaling
> >> > factor of 1/2, 1/4, 1/8...
> >> >
> >> > I found the parameter lowres, which works well with MJPEG stream but
> >> > it's
> >> > not working with the H.264 decoder.
> >> >
> >> > I don't know if it's something possible to implement in the decoder,
> but
> >> if
> >> > yes, my compagny agreed to sponsor the feature (depending on the cost
> of
> >> > course), if a developer qualified is interested to do it.
> >> >
> >> > Is someone know if it is possible, and if it can exist someone
> >> > interested
> >> > to develop this feature?
> >>
> >> is it acceptable if the encoder enforces some restrictions on the used
> >> features ?
> >>
> >> most general h264 likely cannot efficiently be decoded in lower
> >> resolution with acceptable quality
> >> Restricting the used intra modes may make it possible to do it though
> >> i dont know what the quality would be but better than without
> >> restrictions
> >>
> >> [...]
> >>
> >
> >
> > Actually, the main goal is for motion detection algorithm, so we need
> small
> > resolution and best quality is not required. We just need good estimation
> > for the moving pixel.
> >
> > For now, we decode in H.264, and scale it close 320x240, the then we
> > perform motion detection on it. The goal is to speed up the process and
> > reduce the memory usage since decoding a 2048x1536 picture lead around a
> 5
> > MB for the decoded image in memory.
>
> Have you tried to extract the motion vectors of the H.264 stream itself?
>
> If the encoder supports more than I-frames, it should do some Motion
> Estimation.
>

No, but i don't really know how it is working. Our goal is to split the
picture in 1024 block and telling which block has motion detection or not.
Do we have a motion vectors for the I-Frame it self? I assume no, but i
actually need motion detection in any frame.





> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)

2016-06-20 Thread Michael Niedermayer

On Sun, Jun 19, 2016 at 11:42:42PM +0200, Eric Beuque wrote:
> 2016-06-19 16:14 GMT+02:00 Michael Niedermayer :
> 
> > On Sun, Jun 19, 2016 at 09:59:22AM +0200, Eric Beuque wrote:
> > > 2016-06-18 13:46 GMT+02:00 Michael Niedermayer :
> > >
> > > > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote:
> > > > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer
> > :
> > > > >
> > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may
> > be i
> > > > > > > missed something), which consist of decoding H.264 frame with a
> > > > scaling
> > > > > > > factor of 1/2, 1/4, 1/8...
> > > > > > >
> > > > > > > I found the parameter lowres, which works well with MJPEG stream
> > but
> > > > it's
> > > > > > > not working with the H.264 decoder.
> > > > > > >
> > > > > > > I don't know if it's something possible to implement in the
> > decoder,
> > > > but
> > > > > > if
> > > > > > > yes, my compagny agreed to sponsor the feature (depending on the
> > > > cost of
> > > > > > > course), if a developer qualified is interested to do it.
> > > > > > >
> > > > > > > Is someone know if it is possible, and if it can exist someone
> > > > interested
> > > > > > > to develop this feature?
> > > > > >
> > > > > > is it acceptable if the encoder enforces some restrictions on the
> > used
> > > > > > features ?
> > > > > >
> > > > > > most general h264 likely cannot efficiently be decoded in lower
> > > > > > resolution with acceptable quality
> > > > > > Restricting the used intra modes may make it possible to do it
> > though
> > > > > > i dont know what the quality would be but better than without
> > > > > > restrictions
> > > > > >
> > > > > > [...]
> > > > > >
> > > > >
> > > > >
> > > > > Actually, the main goal is for motion detection algorithm, so we need
> > > > small
> > > > > resolution and best quality is not required. We just need good
> > estimation
> > > > > for the moving pixel.
> > > > >
> > > > > For now, we decode in H.264, and scale it close 320x240, the then we
> > > > > perform motion detection on it. The goal is to speed up the process
> > and
> > > > > reduce the memory usage since decoding a 2048x1536 picture lead
> > around a
> > > > 5
> > > > > MB for the decoded image in memory.
> > > > >
> > > > > So i think it could be OK.
> > > >
> > > > i dont think that withut restrictions it would be good enough for
> > > > motion detection
> > > >
> > >
> > > I don't really understand what will be changed in the decoder with or
> > > without restriction...
> >
> > some of the features of h.264 will not decode "right" without the
> > full resolution
> >
> 
> Ok what features do you mean? Maybe it's out of our scope.

some restrictions on intra modes
constrained intra prediction at least
The GOP size should be small too and there may be other things
like disabling the loop filter

cant you just use the IP camera in lower resolution if memory is a
problem ? maybe it can encode 2 streams of different resolution

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec{, _h264}: set FF_CODEC_CAP_SETS_PKT_DTS capability

2016-06-20 Thread Matthieu Bouron

On Sun, Jun 19, 2016 at 06:01:49PM +0200, Matthieu Bouron wrote:
> On Fri, Jun 17, 2016 at 09:47:35AM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > And sets frames pkt_dts to AV_NOPTS_VALUE as we do not want lavc/utils
> > to overwrite the field with incorrect values as the decoder is
> > asynchronous.
> 
> If there is no objection, I will push the patch in one day.

Pushed.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)

2016-06-20 Thread Eric Beuque

2016-06-20 9:57 GMT+02:00 Michael Niedermayer :

> On Sun, Jun 19, 2016 at 11:42:42PM +0200, Eric Beuque wrote:
> > 2016-06-19 16:14 GMT+02:00 Michael Niedermayer :
> >
> > > On Sun, Jun 19, 2016 at 09:59:22AM +0200, Eric Beuque wrote:
> > > > 2016-06-18 13:46 GMT+02:00 Michael Niedermayer
> :
> > > >
> > > > > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote:
> > > > > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer
> > > :
> > > > > >
> > > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > i'm posting here for a feature that is missing in ffmpeg (or
> may
> > > be i
> > > > > > > > missed something), which consist of decoding H.264 frame
> with a
> > > > > scaling
> > > > > > > > factor of 1/2, 1/4, 1/8...
> > > > > > > >
> > > > > > > > I found the parameter lowres, which works well with MJPEG
> stream
> > > but
> > > > > it's
> > > > > > > > not working with the H.264 decoder.
> > > > > > > >
> > > > > > > > I don't know if it's something possible to implement in the
> > > decoder,
> > > > > but
> > > > > > > if
> > > > > > > > yes, my compagny agreed to sponsor the feature (depending on
> the
> > > > > cost of
> > > > > > > > course), if a developer qualified is interested to do it.
> > > > > > > >
> > > > > > > > Is someone know if it is possible, and if it can exist
> someone
> > > > > interested
> > > > > > > > to develop this feature?
> > > > > > >
> > > > > > > is it acceptable if the encoder enforces some restrictions on
> the
> > > used
> > > > > > > features ?
> > > > > > >
> > > > > > > most general h264 likely cannot efficiently be decoded in lower
> > > > > > > resolution with acceptable quality
> > > > > > > Restricting the used intra modes may make it possible to do it
> > > though
> > > > > > > i dont know what the quality would be but better than without
> > > > > > > restrictions
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Actually, the main goal is for motion detection algorithm, so we
> need
> > > > > small
> > > > > > resolution and best quality is not required. We just need good
> > > estimation
> > > > > > for the moving pixel.
> > > > > >
> > > > > > For now, we decode in H.264, and scale it close 320x240, the
> then we
> > > > > > perform motion detection on it. The goal is to speed up the
> process
> > > and
> > > > > > reduce the memory usage since decoding a 2048x1536 picture lead
> > > around a
> > > > > 5
> > > > > > MB for the decoded image in memory.
> > > > > >
> > > > > > So i think it could be OK.
> > > > >
> > > > > i dont think that withut restrictions it would be good enough for
> > > > > motion detection
> > > > >
> > > >
> > > > I don't really understand what will be changed in the decoder with or
> > > > without restriction...
> > >
> > > some of the features of h.264 will not decode "right" without the
> > > full resolution
> > >
> >
> > Ok what features do you mean? Maybe it's out of our scope.
>
> some restrictions on intra modes
> constrained intra prediction at least
> The GOP size should be small too and there may be other things
> like disabling the loop filter
>
> cant you just use the IP camera in lower resolution if memory is a
> problem ? maybe it can encode 2 streams of different resolution
>


Actually, we are already doing this, but sometimes it's not possible,
because some camera are not able to deliver two stream. It's just a
question to know if there is a way to improve the usage in that case. If
you tell me it's not, we will deal with that.



>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Is this a bug of Memory leak about NVENC

2016-06-20 Thread Ron

hi everyone;


OS: ubuntu server 16.04
Driver Version: 361.42, GeForce GTX 970


Ffmpeg: ffmpeg-3.0.2.tar.bz2
configure: --enable-nonfree --enable-nvenc
ffmpeg -y -i input.mp4 -c:a aac -c:v nvenc_hevc -f hevc output.hevc


when I executed the ffmpeg，a part of memory leaked every time;


before running .


free -h
  totalusedfree  shared  buff/cache   available
Mem:   7.8G171M6.9G 21M692M7.5G
Swap:  4.0G  0B4.0G



cat /proc/meminfo
MemTotal:8135708 kB
MemFree: 7251780 kB
MemAvailable:7849060 kB
Buffers:   21532 kB
Cached:   598084 kB
SwapCached:0 kB
Active:   442604 kB
Inactive: 272172 kB
Active(anon):  98492 kB
Inactive(anon):20632 kB
Active(file): 344112 kB
Inactive(file):   251540 kB
Unevictable:3644 kB
Mlocked:3660 kB
SwapTotal:   4152828 kB
SwapFree:4152828 kB
Dirty:76 kB
Writeback: 0 kB
AnonPages: 98856 kB
Mapped:37340 kB
Shmem: 21552 kB
Slab:  89684 kB
SReclaimable:  44096 kB
SUnreclaim:45588 kB
KernelStack:4080 kB
PageTables: 5348 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8220680 kB
Committed_AS:2732220 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 32768 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  106364 kB
DirectMap2M: 3000320 kB
DirectMap1G: 7340032 kB





running.


nvidia-smi
Mon Jun 20 05:06:37 2016
+--+
| NVIDIA-SMI 361.42 Driver Version: 361.42 |
|---+--+--+
| GPU  NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  Compute M. |
|===+==+==|
|   0  GeForce GTX 970 Off  | :01:00.0 Off |  N/A |
|  0%   47CP260W / 151W |942MiB /  4095MiB | 23%  Default |
+---+--+--+


+-+
| Processes:   GPU Memory |
|  GPU   PID  Type  Process name   Usage  |
|=|
|0  2272C   ffmpeg 921MiB |
+-+





after running...
free -h
  totalusedfree  shared  buff/cache   available
Mem:   7.8G531M6.4G 21M850M7.1G
Swap:  4.0G  0B4.0G



cat /proc/meminfo
MemTotal:8135708 kB
MemFree: 6720548 kB
MemAvailable:7475752 kB
Buffers:   21720 kB
Cached:   755068 kB
SwapCached:0 kB
Active:   738340 kB
Inactive: 424388 kB
Active(anon): 389296 kB
Inactive(anon):20640 kB
Active(file): 349044 kB
Inactive(file):   403748 kB
Unevictable:3644 kB
Mlocked:3660 kB
SwapTotal:   4152828 kB
SwapFree:4152828 kB
Dirty:32 kB
Writeback: 0 kB
AnonPages:102400 kB
Mapped:37616 kB
Shmem: 21584 kB
Slab:  94496 kB
SReclaimable:  44880 kB
SUnreclaim:49616 kB
KernelStack:4224 kB
PageTables: 5864 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8220680 kB
Committed_AS:2747656 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 32768 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  264060 kB
DirectMap2M: 4939776 kB
DirectMap1G: 5242880 kB



nvidia-smi
Mon Jun 20 05:08:53 2016

+--+
| NVIDIA-SMI 361.42 Driver Version: 361.42 |
|---+--+--+
| GPU  NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  Compute M. |
|===+===

Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-20 Thread Matthieu Bouron

On Fri, Jun 17, 2016 at 01:26:10AM +0200, Michael Niedermayer wrote:
> On Thu, Jun 16, 2016 at 05:26:14PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > Fixes packet pts of samples which contain ctts entries with count=0.
> > ---
> > 
> > Hello,
> > 
> > The following patch fixes packet pts of samples which contain ctts values 
> > with
> > count=0 (so the ctts entry does not apply to any sample if I understand
> > correctly). Such samples are produced by a LG G4 phone. I don't have any
> > sample I can share at the moment (and thus no fate test following this patch
> > yet).
> > 
> > An alternative to this patch is to remove directly the entry when the ctts 
> > atom
> > is parsed. Would you prefer this alternative ?
> 
> i dont know what is preferred but i agree about either solution
> 
> removing them on load would avoid any issues with ctts_count > 0
> and no real entries, i dont know though if that ever matters

I've attached the alternative patch that removes the CTTS entries with
count <= 0 at parsing time. I think it's better in the end (I first liked
the idea to keep the ctts table as is in memory but after some thoughts I
think it's really useful). Anyway I'll go with whatever patch you prefer.

Matthieu

[...]
>From 3bf2a6a81b8cca09bee4c0b6ef6f6ce78e276f0d Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Thu, 16 Jun 2016 13:16:52 +0200
Subject: [PATCH] lavf/mov: ignore ctts that do not apply to a least one sample

Fixes packet pts of samples which contain ctts values with count <= 0.
---
 libavformat/mov.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 57a0354..8eab34c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2574,7 +2574,7 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
 MOVStreamContext *sc;
-unsigned int i, entries;
+unsigned int i, entries, ctts_count = 0;
 
 if (c->fc->nb_streams < 1)
 return 0;
@@ -2600,8 +2600,16 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 int count=avio_rb32(pb);
 int duration =avio_rb32(pb);
 
-sc->ctts_data[i].count   = count;
-sc->ctts_data[i].duration= duration;
+if (count <= 0) {
+av_log(c->fc, AV_LOG_TRACE,
+"ignoring CTTS entry with count=%d duration=%d\n",
+count, duration);
+continue;
+}
+
+sc->ctts_data[ctts_count].count= count;
+sc->ctts_data[ctts_count].duration = duration;
+ctts_count++;
 
 av_log(c->fc, AV_LOG_TRACE, "count=%d, duration=%d\n",
 count, duration);
@@ -2617,7 +2625,7 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 mov_update_dts_shift(sc, duration);
 }
 
-sc->ctts_count = i;
+sc->ctts_count = ctts_count;
 
 if (pb->eof_reached)
 return AVERROR_EOF;
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-20 Thread Matthieu Bouron

On Mon, Jun 20, 2016 at 11:22 AM, Matthieu Bouron  wrote:

> On Fri, Jun 17, 2016 at 01:26:10AM +0200, Michael Niedermayer wrote:
> > On Thu, Jun 16, 2016 at 05:26:14PM +0200, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > >
> > > Fixes packet pts of samples which contain ctts entries with count=0.
> > > ---
> > >
> > > Hello,
> > >
> > > The following patch fixes packet pts of samples which contain ctts
> values with
> > > count=0 (so the ctts entry does not apply to any sample if I understand
> > > correctly). Such samples are produced by a LG G4 phone. I don't have
> any
> > > sample I can share at the moment (and thus no fate test following this
> patch
> > > yet).
> > >
> > > An alternative to this patch is to remove directly the entry when the
> ctts atom
> > > is parsed. Would you prefer this alternative ?
> >
> > i dont know what is preferred but i agree about either solution
> >
> > removing them on load would avoid any issues with ctts_count > 0
> > and no real entries, i dont know though if that ever matters
>
> I've attached the alternative patch that removes the CTTS entries with
> count <= 0 at parsing time. I think it's better in the end (I first liked
> the idea to keep the ctts table as is in memory but after some thoughts I
> think it's really useful). Anyway I'll go with whatever patch you prefer.
>

 *not* really useful

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] It happens on CTRL+C//re??Is this a bug of Memory leak about NVENC

2016-06-20 Thread Ron

It happens on CTRL+C;


-- 原始邮件 --
发件人: "Ron";;
发送时间: 2016年6月20日(星期一) 下午5:09
收件人: "ffmpeg-devel"; 

主题: Is this a bug of Memory leak about NVENC 



hi everyone;


OS: ubuntu server 16.04
Driver Version: 361.42, GeForce GTX 970


Ffmpeg: ffmpeg-3.0.2.tar.bz2
configure: --enable-nonfree --enable-nvenc
ffmpeg -y -i input.mp4 -c:a aac -c:v nvenc_hevc -f hevc output.hevc


when I executed the ffmpeg，a part of memory leaked every time;


before running .


free -h
  totalusedfree  shared  buff/cache   available
Mem:   7.8G171M6.9G 21M692M7.5G
Swap:  4.0G  0B4.0G



cat /proc/meminfo
MemTotal:8135708 kB
MemFree: 7251780 kB
MemAvailable:7849060 kB
Buffers:   21532 kB
Cached:   598084 kB
SwapCached:0 kB
Active:   442604 kB
Inactive: 272172 kB
Active(anon):  98492 kB
Inactive(anon):20632 kB
Active(file): 344112 kB
Inactive(file):   251540 kB
Unevictable:3644 kB
Mlocked:3660 kB
SwapTotal:   4152828 kB
SwapFree:4152828 kB
Dirty:76 kB
Writeback: 0 kB
AnonPages: 98856 kB
Mapped:37340 kB
Shmem: 21552 kB
Slab:  89684 kB
SReclaimable:  44096 kB
SUnreclaim:45588 kB
KernelStack:4080 kB
PageTables: 5348 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8220680 kB
Committed_AS:2732220 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 32768 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  106364 kB
DirectMap2M: 3000320 kB
DirectMap1G: 7340032 kB





running.


nvidia-smi
Mon Jun 20 05:06:37 2016
+--+
| NVIDIA-SMI 361.42 Driver Version: 361.42 |
|---+--+--+
| GPU  NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  Compute M. |
|===+==+==|
|   0  GeForce GTX 970 Off  | :01:00.0 Off |  N/A |
|  0%   47CP260W / 151W |942MiB /  4095MiB | 23%  Default |
+---+--+--+


+-+
| Processes:   GPU Memory |
|  GPU   PID  Type  Process name   Usage  |
|=|
|0  2272C   ffmpeg 921MiB |
+-+





after running...
free -h
  totalusedfree  shared  buff/cache   available
Mem:   7.8G531M6.4G 21M850M7.1G
Swap:  4.0G  0B4.0G



cat /proc/meminfo
MemTotal:8135708 kB
MemFree: 6720548 kB
MemAvailable:7475752 kB
Buffers:   21720 kB
Cached:   755068 kB
SwapCached:0 kB
Active:   738340 kB
Inactive: 424388 kB
Active(anon): 389296 kB
Inactive(anon):20640 kB
Active(file): 349044 kB
Inactive(file):   403748 kB
Unevictable:3644 kB
Mlocked:3660 kB
SwapTotal:   4152828 kB
SwapFree:4152828 kB
Dirty:32 kB
Writeback: 0 kB
AnonPages:102400 kB
Mapped:37616 kB
Shmem: 21584 kB
Slab:  94496 kB
SReclaimable:  44880 kB
SUnreclaim:49616 kB
KernelStack:4224 kB
PageTables: 5864 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8220680 kB
Committed_AS:2747656 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 32768 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  264060 kB
DirectMap2M: 4939776 kB
DirectMap1G: 5242880 kB



nvidia-smi
Mon Jun 20 05:08:53 2016

+--+
| NVIDIA-SMI 361.42 Driver Version: 361.42 |
|---+--+--+
| GPU  Name

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-06-20 Thread Davinder Singh

On Sat, Jun 18, 2016 at 3:16 AM Michael Niedermayer 
wrote:

> On Fri, Jun 17, 2016 at 08:19:00AM +, Davinder Singh wrote:
> [...]
> > Yes, I did that, after understanding it completely. It now works with the
> > motion vectors generated by mEstimate filter. Now I’m trying to improve
> it
> > based on this paper: Overlapped Block Motion Compensation: An
> > Estimation-Theoretic Approach
>
> > <
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.8359&rep=rep1&type=pdf
> >
>
> this is 22 years old
>
>
> > and
> > this one: Window Motion Compensation
> > .Takes a lot of time
>
> this is 25 years old
>
> not saying old papers are bad, just that this represents the knowledge
> of 20 years ago
>
> also its important to keep in mind that blind block matching of any
> metric will not be enough. To find true motion the whole motion
> vector fields of multiple frames will need to be considered
>
> For example a ball thrown accross the field of view entering and
> exiting the picture needs to move smoothly and at the ends (in time)
> there are frames without the ball then a frame with the ball
> these 2 are not enough to interpolate the frames between as we have
> just one location where the ball is. With the next frames though
> we can find the motion trajectory of the ball and interpolate it end
> to end
>
> I think papers which work on problems like this and also interpolation
> of all the areas that end up overlapping and covering each other
> like the backgroud behind the ball in that example would be better
> starting points for implementing motion estiation because ultimatly
> that is the kind of ME code we would like to have.
> Block matching with various windows, OBMC, ... are all good but
> if in our example the vectors for the ball or background are off that
> will look rather bad with any motion compensation
> So trying to move a bit toward this would make sense but first
> having some motion estimation even really basic and dumb with
> mc working in a testable filter (pair) should probably be done.
> Iam just mentioning this as a bit of a preview of what i hope could
> eventually be implemented, maybe this would be after GSoC but its
> the kind of code needed to have really usable frame interpolation
>
>
>
> > reading them. I think we need to add new Raised Cosine window (weights)
> > along with Linear Window (currently implemented). What do you say?
>
> i dont know, the windows used in snow are already the best of several
> tried (for snow).
> no great gains will be found by changing the OBMC window from snow.
>
>
> >
> > Also making mInterpolate work with variable macroblock size MC. The
> current
> > interpolation works without half pel accuracy, though.
>
> mcfps has fully working 1/4 pel OBMC code, that should be fine to be
> used as is i think unless i miss something
>
> half pel is 20 years old, it is not usefull
> multiple block sizes on the MC side should not really matter ATM
> smaller blocks are a bit slower but first we should get the code
> working, then working with good quality and then working fast.
>
> multiple block sizes may be usefull for the estimation side if it
> improves estimation somehow.
>
> Can i see your current "work in progress" ?
>
>
> [...]
> > I’m moving estimation code to some new file motion_est.c file and the
> > methods are shared by both mEstimate and mInterpolate filters. mEstimate
> > store the MVs in frame’s side data for any other filter. Moreover, any
> > other filter if need post processing on MVs it can directly use the
> shared
> > methods. But, mInterpolate use them internally, no saving in sidedata,
> and
> > saving unnecessary processing.
>
> This design sounds good
>
>
> >
> >
> > Also, Paper [1] doesn’t uses window with OBMC at all. It just find normal
> > average without weight. Perhaps to compare papers I either need to add
> > multiple option for each setting or need to assign the algorithm as
> > researcher’s name in filter options.
>
>
>
Paper [1] and [2] uses functions or do post processing on motion vectors,
so needs fast ME algorithms, which currently I’m working on. [*M]

Let me summarize the papers (from Email 1, this thread):

Paper [1]: Zhai et al. (2005) A Low Complexity Motion Compensated Frame
Interpolation Method

[Quote]
This paper propose a MCFI method intended for real time processing. It
first examines the motion vectors in the bitstream [*1]. 8x8 block size is
used rather than 16x16 as in most cases; Using smaller block size leads to
denser motion field, so neighboring MVs are more highly correlated, so
prediction is better. To reduce complexity, MVs in bitstream are utilized
[*1]. But need to be filtered as not all of them represent true motion.
They are grouped into “good vectors, can be used directly” and “bad
vectors, need to find true motion”. For classification of MVs into groups,
SAD and BAD is used. For an 8x8 block in to-be-interpolated frame F(in) we
get m

Re: [FFmpeg-devel] [PATCH 2/2] swresample/x86: add support for exact_rational

2016-06-20 Thread Muhammad Faiz

On Thu, Jun 16, 2016 at 12:31 AM, Muhammad Faiz  wrote:
> phase_shift and phase_mask is removed
> generally exact_rational=on is faster than exact_rational=off
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libswresample/resample.c  |  2 -
>  libswresample/resample.h  |  3 --
>  libswresample/x86/resample.asm| 87 
> +--
>  libswresample/x86/resample_init.c |  4 --
>  4 files changed, 46 insertions(+), 50 deletions(-)
>
going to apply this if no one object

thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS

2016-06-20 Thread Matthieu Bouron

On Sun, Jun 19, 2016 at 07:44:44PM +0200, Matthieu Bouron wrote:
> On Mon, Jun 13, 2016 at 02:37:29PM +0200, Matthieu Bouron wrote:
> > On Mon, Jun 13, 2016 at 12:23:07PM +0200, Hendrik Leppkes wrote:
> > > On Mon, Jun 13, 2016 at 11:51 AM, Matthieu Bouron
> > >  wrote:
> > > > On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
> > > >> From: Matthieu Bouron 
> > > >>
> > > >> Fixes playback of HLS streams on MediaTek devices which requires 
> > > >> PPS/SPS
> > > >> to be set in their respective csd-{0,1} buffers.
> > > >> ---
> > > >>
> > > >> Hello,
> > > >>
> > > >> The attached patch fixes playback of HLS streams on MediaTek devices 
> > > >> which
> > > >> requires PPS/SPS to be set in their respetive csd-{0,1} buffers 
> > > >> (instead of
> > > >> having sps+pps in the csd-0 which works on other devices).
> > > >>
> > > >> I'm not sure if I can use the ff_h264_decode_extradata this way (or at 
> > > >> least
> > > >> initialize the H264Context with zeroes minus the avctx field).
> > > >
> > > > Rebased patch (after the h264 ps merged) attached.
> > > >
> > > > I still have the same question, is my use of
> > > > H264Context + ff_h264_decode_extradata correct ?
> > > >
> > > 
> > > Using H264 decoder internals seems to be a rather unfortunate
> > > solution, as its prone to breakage, often subtle, as the h264 decoder
> > > gets changed and not all inter-module dependencies are known.
> > > So if possible at all, not using something that uses H264Context for
> > > example would be nice.
> > > 
> > > For the record, ff_h264_decode_extradata is scheduled for refactoring
> > > to make it independent of H264Context so it can be more easily shared
> > > with the h264 decoder and the h264 parser.
> > > Once that is done, it may give you a cleaner interface to use it from
> > > mediacodec as well.
> > 
> > Ok. I can wait for the refactor to be merged but the MediaCodec decoder
> > will remain broken on those devices. I'm not too happy about that if a
> > release is to be made in those following days. Do we have an ETA ?  I'm
> > also not too happy to write the same parsing code as I did before for the
> > AVCC format to split/extract the PPS/SPS.
> > 
> > Or ..., I can push this code (if its use is valid) and update it when the
> > merge lands (I'm helping Clément with the merges, so I will take care
> > about this part).
> 
> Updated patch attached (using the new ff_h264_decode_extradata API).
> 

Correct patch attached (the previous one was incorrect).

[...]
>From a27b3ece788cbbe459226f50fbdaf12ce3fee1bb Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 10 Jun 2016 13:16:09 +0200
Subject: [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to
 extract PPS/SPS

Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
to be set in their respective csd-{0,1} buffers.
---
 libavcodec/mediacodecdec_h264.c | 153 +++-
 1 file changed, 42 insertions(+), 111 deletions(-)

diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 0f90606..219649a 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -32,6 +32,7 @@
 #include "libavutil/atomic.h"
 
 #include "avcodec.h"
+#include "h264.h"
 #include "internal.h"
 #include "mediacodecdec.h"
 #include "mediacodec_wrapper.h"
@@ -50,104 +51,6 @@ typedef struct MediaCodecH264DecContext {
 
 } MediaCodecH264DecContext;
 
-static int h264_extradata_to_annexb_sps_pps(AVCodecContext *avctx,
-uint8_t **extradata_annexb, int *extradata_annexb_size,
-int *sps_offset, int *sps_size,
-int *pps_offset, int *pps_size)
-{
-uint16_t unit_size;
-uint64_t total_size = 0;
-
-uint8_t i, j, unit_nb;
-uint8_t sps_seen = 0;
-uint8_t pps_seen = 0;
-
-const uint8_t *extradata;
-static const uint8_t nalu_header[4] = { 0x00, 0x00, 0x00, 0x01 };
-
-if (avctx->extradata_size < 8) {
-av_log(avctx, AV_LOG_ERROR,
-"Too small extradata size, corrupted stream or invalid MP4/AVCC bitstream\n");
-return AVERROR(EINVAL);
-}
-
-*extradata_annexb = NULL;
-*extradata_annexb_size = 0;
-
-*sps_offset = *sps_size = 0;
-*pps_offset = *pps_size = 0;
-
-extradata = avctx->extradata + 4;
-
-/* skip length size */
-extradata++;
-
-for (j = 0; j < 2; j ++) {
-
-if (j == 0) {
-/* number of sps unit(s) */
-unit_nb = *extradata++ & 0x1f;
-} else {
-/* number of pps unit(s) */
-unit_nb = *extradata++;
-}
-
-for (i = 0; i < unit_nb; i++) {
-int err;
-
-unit_size   = AV_RB16(extradata);
-total_size += unit_size + 4;
-
-if (total_size > INT_MAX) {
-av_log(avctx, AV_LOG_ERROR,
-"Too big extradata size, corrupted stream or invalid MP4/AVCC bitstream\n");
-av_freep(extradata_annexb);
-

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 09:54:15AM +, Davinder Singh wrote:
> On Sat, Jun 18, 2016 at 3:16 AM Michael Niedermayer 
> wrote:
> 
> > On Fri, Jun 17, 2016 at 08:19:00AM +, Davinder Singh wrote:
> > [...]
> > > Yes, I did that, after understanding it completely. It now works with the
> > > motion vectors generated by mEstimate filter. Now I’m trying to improve
> > it
> > > based on this paper: Overlapped Block Motion Compensation: An
> > > Estimation-Theoretic Approach
> >
> > > <
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.8359&rep=rep1&type=pdf
> > >
> >
> > this is 22 years old
> >
> >
> > > and
> > > this one: Window Motion Compensation
> > > .Takes a lot of time
> >
> > this is 25 years old
> >
> > not saying old papers are bad, just that this represents the knowledge
> > of 20 years ago
> >
> > also its important to keep in mind that blind block matching of any
> > metric will not be enough. To find true motion the whole motion
> > vector fields of multiple frames will need to be considered
> >
> > For example a ball thrown accross the field of view entering and
> > exiting the picture needs to move smoothly and at the ends (in time)
> > there are frames without the ball then a frame with the ball
> > these 2 are not enough to interpolate the frames between as we have
> > just one location where the ball is. With the next frames though
> > we can find the motion trajectory of the ball and interpolate it end
> > to end
> >
> > I think papers which work on problems like this and also interpolation
> > of all the areas that end up overlapping and covering each other
> > like the backgroud behind the ball in that example would be better
> > starting points for implementing motion estiation because ultimatly
> > that is the kind of ME code we would like to have.
> > Block matching with various windows, OBMC, ... are all good but
> > if in our example the vectors for the ball or background are off that
> > will look rather bad with any motion compensation
> > So trying to move a bit toward this would make sense but first
> > having some motion estimation even really basic and dumb with
> > mc working in a testable filter (pair) should probably be done.
> > Iam just mentioning this as a bit of a preview of what i hope could
> > eventually be implemented, maybe this would be after GSoC but its
> > the kind of code needed to have really usable frame interpolation
> >
> >
> >
> > > reading them. I think we need to add new Raised Cosine window (weights)
> > > along with Linear Window (currently implemented). What do you say?
> >
> > i dont know, the windows used in snow are already the best of several
> > tried (for snow).
> > no great gains will be found by changing the OBMC window from snow.
> >
> >
> > >
> > > Also making mInterpolate work with variable macroblock size MC. The
> > current
> > > interpolation works without half pel accuracy, though.
> >
> > mcfps has fully working 1/4 pel OBMC code, that should be fine to be
> > used as is i think unless i miss something
> >
> > half pel is 20 years old, it is not usefull
> > multiple block sizes on the MC side should not really matter ATM
> > smaller blocks are a bit slower but first we should get the code
> > working, then working with good quality and then working fast.
> >
> > multiple block sizes may be usefull for the estimation side if it
> > improves estimation somehow.
> >
> > Can i see your current "work in progress" ?
> >
> >
> > [...]
> > > I’m moving estimation code to some new file motion_est.c file and the
> > > methods are shared by both mEstimate and mInterpolate filters. mEstimate
> > > store the MVs in frame’s side data for any other filter. Moreover, any
> > > other filter if need post processing on MVs it can directly use the
> > shared
> > > methods. But, mInterpolate use them internally, no saving in sidedata,
> > and
> > > saving unnecessary processing.
> >
> > This design sounds good
> >
> >
> > >
> > >
> > > Also, Paper [1] doesn’t uses window with OBMC at all. It just find normal
> > > average without weight. Perhaps to compare papers I either need to add
> > > multiple option for each setting or need to assign the algorithm as
> > > researcher’s name in filter options.
> >
> >
> >
> Paper [1] and [2] uses functions or do post processing on motion vectors,
> so needs fast ME algorithms, which currently I’m working on. [*M]
> 
> Let me summarize the papers (from Email 1, this thread):
> 
> Paper [1]: Zhai et al. (2005) A Low Complexity Motion Compensated Frame
> Interpolation Method
> 
> [Quote]
> This paper propose a MCFI method intended for real time processing. It
> first examines the motion vectors in the bitstream [*1]. 8x8 block size is
> used rather than 16x16 as in most cases; Using smaller block size leads to
> denser motion field, so neighboring MVs are more highly correlated, so
> prediction is better. To reduce complexity, MVs in bitstream are ut

Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API

2016-06-20 Thread Michael Niedermayer

On Sun, Jun 12, 2016 at 04:30:50PM -0500, Rodger Combs wrote:
> ---
>  libavformat/internal.h |  5 +++--
>  libavformat/mux.c  | 45 +-
>  libavformat/segment.c  |  6 +++--
>  libavformat/utils.c| 59 
> +-
>  4 files changed, 91 insertions(+), 24 deletions(-)

This fixes the memleak in fate-matroska-remux
is there a reason why this is not pushed ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API

2016-06-20 Thread Jan Sebechlebsky




On 06/20/2016 02:04 PM, Michael Niedermayer wrote:

On Sun, Jun 12, 2016 at 04:30:50PM -0500, Rodger Combs wrote:

---
  libavformat/internal.h |  5 +++--
  libavformat/mux.c  | 45 +-
  libavformat/segment.c  |  6 +++--
  libavformat/utils.c| 59 +-
  4 files changed, 91 insertions(+), 24 deletions(-)

This fixes the memleak in fate-matroska-remux
is there a reason why this is not pushed ?

[...]


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
There is a discussion about creating new API for list of BSFs 
processing, so maybe the author decided to wait for that, but I guess 
there is no reason not to use this patch until the API is ready.


Regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add myself for videotoolbox.c, remove vda* maintainer

2016-06-20 Thread Michael Niedermayer

On Thu, Jun 16, 2016 at 09:12:39AM -0400, Rick Kern wrote:
> Person in MAINTAINERS hasn't responded to a patch on the ML or private
> email, and doesn't maintain the files according to git.
> 
> Signed-off-by: Rick Kern 
> ---
>  MAINTAINERS | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

should be ok

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers

2016-06-20 Thread Clément Bœsch

On Thu, Jun 16, 2016 at 11:26:02AM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> ---
> Still unsure about the FATE changes.
> Also couldn't test pgm vs pgmyuv due to a crash
> ---
>  libavformat/Makefile|  5 +
>  libavformat/allformats.c|  5 +
>  libavformat/img2dec.c   | 55 
> +
>  tests/ref/seek/lavf-pbmpipe | 50 ++---
>  tests/ref/seek/lavf-pgmpipe | 50 ++---
>  tests/ref/seek/lavf-ppmpipe | 50 ++---
>  6 files changed, 146 insertions(+), 69 deletions(-)
> 

ping

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 11:22:08AM +0200, Matthieu Bouron wrote:
> On Fri, Jun 17, 2016 at 01:26:10AM +0200, Michael Niedermayer wrote:
> > On Thu, Jun 16, 2016 at 05:26:14PM +0200, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > > 
> > > Fixes packet pts of samples which contain ctts entries with count=0.
> > > ---
> > > 
> > > Hello,
> > > 
> > > The following patch fixes packet pts of samples which contain ctts values 
> > > with
> > > count=0 (so the ctts entry does not apply to any sample if I understand
> > > correctly). Such samples are produced by a LG G4 phone. I don't have any
> > > sample I can share at the moment (and thus no fate test following this 
> > > patch
> > > yet).
> > > 
> > > An alternative to this patch is to remove directly the entry when the 
> > > ctts atom
> > > is parsed. Would you prefer this alternative ?
> > 
> > i dont know what is preferred but i agree about either solution
> > 
> > removing them on load would avoid any issues with ctts_count > 0
> > and no real entries, i dont know though if that ever matters
> 
> I've attached the alternative patch that removes the CTTS entries with
> count <= 0 at parsing time. I think it's better in the end (I first liked
> the idea to keep the ctts table as is in memory but after some thoughts I
> think it's really useful). Anyway I'll go with whatever patch you prefer.

i prefer this patch very slightly

thanks

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers

2016-06-20 Thread Carl Eugen Hoyos

Clément Bœsch  pkh.me> writes:

> +static int pgmyuv_probe(AVProbeData *p)
> +{
> +int ret = pgmx_probe(p);
> +return ret && av_match_ext(p->filename, "pgmyuv") ? ret : 0;

You could add a comment that this format was invented within 
FFmpeg, I hadn't realized this.
And you could check for positive resolutions if you want to 
improve probing.

Did you run the probe test for the new functions?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swresample/x86: add support for exact_rational

2016-06-20 Thread Michael Niedermayer

On Thu, Jun 16, 2016 at 12:31:04AM +0700, Muhammad Faiz wrote:
> phase_shift and phase_mask is removed
> generally exact_rational=on is faster than exact_rational=off 
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libswresample/resample.c  |  2 -
>  libswresample/resample.h  |  3 --
>  libswresample/x86/resample.asm| 87 
> +--
>  libswresample/x86/resample_init.c |  4 --
>  4 files changed, 46 insertions(+), 50 deletions(-)

tested on mingwg32/64 and linux 32/64

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-20 Thread Matthieu Bouron

On Mon, Jun 20, 2016 at 02:43:16PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 11:22:08AM +0200, Matthieu Bouron wrote:
> > On Fri, Jun 17, 2016 at 01:26:10AM +0200, Michael Niedermayer wrote:
> > > On Thu, Jun 16, 2016 at 05:26:14PM +0200, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron 
> > > > 
> > > > Fixes packet pts of samples which contain ctts entries with count=0.
> > > > ---
> > > > 
> > > > Hello,
> > > > 
> > > > The following patch fixes packet pts of samples which contain ctts 
> > > > values with
> > > > count=0 (so the ctts entry does not apply to any sample if I understand
> > > > correctly). Such samples are produced by a LG G4 phone. I don't have any
> > > > sample I can share at the moment (and thus no fate test following this 
> > > > patch
> > > > yet).
> > > > 
> > > > An alternative to this patch is to remove directly the entry when the 
> > > > ctts atom
> > > > is parsed. Would you prefer this alternative ?
> > > 
> > > i dont know what is preferred but i agree about either solution
> > > 
> > > removing them on load would avoid any issues with ctts_count > 0
> > > and no real entries, i dont know though if that ever matters
> > 
> > I've attached the alternative patch that removes the CTTS entries with
> > count <= 0 at parsing time. I think it's better in the end (I first liked
> > the idea to keep the ctts table as is in memory but after some thoughts I
> > think it's really useful). Anyway I'll go with whatever patch you prefer.
> 
> i prefer this patch very slightly

Pushed. Thanks.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/h264_ps: add ff_h264_ps_uninit and use it

2016-06-20 Thread Matthieu Bouron

From: Matthieu Bouron 

---
 libavcodec/h264.c| 10 +-
 libavcodec/h264.h|  6 ++
 libavcodec/h264_parser.c |  8 +---
 libavcodec/h264_ps.c | 17 +
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index f2dc473..9d2caba 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -377,15 +377,7 @@ static av_cold int h264_decode_end(AVCodecContext *avctx)
 h->nb_slice_ctx = 0;
 
 ff_h264_sei_uninit(&h->sei);
-
-for (i = 0; i < MAX_SPS_COUNT; i++)
-av_buffer_unref(&h->ps.sps_list[i]);
-
-for (i = 0; i < MAX_PPS_COUNT; i++)
-av_buffer_unref(&h->ps.pps_list[i]);
-
-av_buffer_unref(&h->ps.sps_ref);
-av_buffer_unref(&h->ps.pps_ref);
+ff_h264_ps_uninit(&h->ps);
 
 ff_h2645_packet_uninit(&h->pkt);
 
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 61d94cd..8e92f62 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -695,6 +695,12 @@ typedef struct H264Context {
 extern const uint16_t ff_h264_mb_sizes[4];
 
 /**
+ * Uninit H264 param sets structure.
+ */
+
+void ff_h264_ps_uninit(H264ParamSets *ps);
+
+/**
  * Decode SPS
  */
 int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 3ce049e..42ad932 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -649,17 +649,11 @@ static void h264_close(AVCodecParserContext *s)
 {
 H264ParseContext *p = s->priv_data;
 ParseContext *pc = &p->pc;
-int i;
 
 av_freep(&pc->buffer);
 
 ff_h264_sei_uninit(&p->sei);
-
-for (i = 0; i < FF_ARRAY_ELEMS(p->ps.sps_list); i++)
-av_buffer_unref(&p->ps.sps_list[i]);
-
-for (i = 0; i < FF_ARRAY_ELEMS(p->ps.pps_list); i++)
-av_buffer_unref(&p->ps.pps_list[i]);
+ff_h264_ps_uninit(&p->ps);
 }
 
 static av_cold int init(AVCodecParserContext *s)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 521f560..fb05b05 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -298,6 +298,23 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS 
*sps,
 }
 }
 
+void ff_h264_ps_uninit(H264ParamSets *ps)
+{
+int i;
+
+for (i = 0; i < MAX_SPS_COUNT; i++)
+av_buffer_unref(&ps->sps_list[i]);
+
+for (i = 0; i < MAX_PPS_COUNT; i++)
+av_buffer_unref(&ps->pps_list[i]);
+
+av_buffer_unref(&ps->sps_ref);
+av_buffer_unref(&ps->pps_ref);
+
+ps->pps = NULL;
+ps->sps = NULL;
+}
+
 int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
  H264ParamSets *ps, int ignore_truncation)
 {
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers

2016-06-20 Thread Michael Niedermayer

On Thu, Jun 16, 2016 at 11:26:02AM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> ---
> Still unsure about the FATE changes.
> Also couldn't test pgm vs pgmyuv due to a crash
> ---
>  libavformat/Makefile|  5 +
>  libavformat/allformats.c|  5 +
>  libavformat/img2dec.c   | 55 
> +
>  tests/ref/seek/lavf-pbmpipe | 50 ++---
>  tests/ref/seek/lavf-pgmpipe | 50 ++---
>  tests/ref/seek/lavf-ppmpipe | 50 ++---
>  6 files changed, 146 insertions(+), 69 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 481f3b1..12d8f6b 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -226,9 +226,14 @@ OBJS-$(CONFIG_IMAGE_EXR_PIPE_DEMUXER) += img2dec.o 
> img2.o
>  OBJS-$(CONFIG_IMAGE_J2K_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER)  += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_PAM_PIPE_DEMUXER) += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_PBM_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_PGMYUV_PIPE_DEMUXER)  += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_PGM_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER)  += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER)   += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index ddf540c..d490cc4 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -356,9 +356,14 @@ void av_register_all(void)
>  REGISTER_DEMUXER (IMAGE_J2K_PIPE,image_j2k_pipe);
>  REGISTER_DEMUXER (IMAGE_JPEG_PIPE,   image_jpeg_pipe);
>  REGISTER_DEMUXER (IMAGE_JPEGLS_PIPE, image_jpegls_pipe);
> +REGISTER_DEMUXER (IMAGE_PAM_PIPE,image_pam_pipe);
> +REGISTER_DEMUXER (IMAGE_PBM_PIPE,image_pbm_pipe);
>  REGISTER_DEMUXER (IMAGE_PCX_PIPE,image_pcx_pipe);
> +REGISTER_DEMUXER (IMAGE_PGMYUV_PIPE, image_pgmyuv_pipe);
> +REGISTER_DEMUXER (IMAGE_PGM_PIPE,image_pgm_pipe);
>  REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
>  REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
> +REGISTER_DEMUXER (IMAGE_PPM_PIPE,image_ppm_pipe);
>  REGISTER_DEMUXER (IMAGE_QDRAW_PIPE,  image_qdraw_pipe);
>  REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
>  REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 1b0e608..9cbc9dc 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -862,6 +862,56 @@ static int webp_probe(AVProbeData *p)
>  return 0;
>  }
>  
> +static int pnm_magic_check(const AVProbeData *p, int magic)
> +{
> +const uint8_t *b = p->buf;
> +
> +return b[0] == 'P' && b[1] == magic + '0';
> +}
> +
> +static inline int pnm_probe(const AVProbeData *p)
> +{
> +const uint8_t *b = p->buf;
> +
> +while (b[2] == '\r')
> +b++;

shouldnt this check buf_size ?

either way patch LGTM

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/h264_ps: add ff_h264_ps_uninit and use it

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 04:13:02PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libavcodec/h264.c| 10 +-
>  libavcodec/h264.h|  6 ++
>  libavcodec/h264_parser.c |  8 +---
>  libavcodec/h264_ps.c | 17 +
>  4 files changed, 25 insertions(+), 16 deletions(-)

probably ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.

signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Dan Parrot

Could a PPC maintainer verify that this patch integrates cleanly into
the design? I would like to proceed with the remaining changes to close
out ticket #5570 but since the first patch was rejected, I am unsure on
whether I'll have to rewrite the code.

Thanks.
Dan.

On Sun, 2016-06-19 at 21:57 +, Dan Parrot wrote:
> First commit addressing Trac ticket #5570. Functions defined in 
> libswscale/input.c
> have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> ---
>  libswscale/ppc/Makefile   |1 +
>  libswscale/ppc/input_vsx.c| 1070 
> +
>  libswscale/swscale.c  |3 +
>  libswscale/swscale_internal.h |1 +
>  4 files changed, 1075 insertions(+)
>  create mode 100644 libswscale/ppc/input_vsx.c
> 
> diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> index d1b596e..2482893 100644
> --- a/libswscale/ppc/Makefile
> +++ b/libswscale/ppc/Makefile
> @@ -1,3 +1,4 @@
>  OBJS += ppc/swscale_altivec.o   \
> +ppc/input_vsx.o \
>  ppc/yuv2rgb_altivec.o   \
>  ppc/yuv2yuv_altivec.o   \
> diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> new file mode 100644
> index 000..adb0e38
> --- /dev/null
> +++ b/libswscale/ppc/input_vsx.c
> @@ -0,0 +1,1070 @@
> +/*
> + * Copyright (C) 2016 Dan Parrot 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "libavutil/avutil.h"
> +#include "libavutil/bswap.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/avassert.h"
> +#include "config.h"
> +#include "libswscale/rgb2rgb.h"
> +#include "libswscale/swscale.h"
> +#include "libswscale/swscale_internal.h"
> +
> +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> +
> +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> +
> +#if HAVE_VSX
> +
> +// This is a SIMD version for IBM POWER8 of function rgb64ToY_c_template
> +// in file libswscale/input.c
> +static av_always_inline void
> +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
> +enum AVPixelFormat origin, int32_t *rgb2yuv)
> +{
> +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = rgb2yuv[BY_IDX];
> +int i, j;
> +int num_vec, frag;
> +
> +num_vec = width / 8;
> +frag= width % 8;
> +
> +vector int v_ry = vec_splats((int)ry);
> +vector int v_gy = vec_splats((int)gy);
> +vector int v_by = vec_splats((int)by);
> +
> +int s_opr2;
> +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> +
> +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> +vector int v_opr2 = vec_splats((int)s_opr2);
> +
> +vector int v_r, v_g, v_b, v_tmp;
> +vector short v_tmpi, v_dst;
> +
> +for (i = 0; i < num_vec; i++) {
> +for (j = 7; j >= 0  ; j--) {
> +int r_b = input_pixel(&src[(i*8+j)*4+0]);
> +int g   = input_pixel(&src[(i*8+j)*4+1]);
> +int b_r = input_pixel(&src[(i*8+j)*4+2]);
> +
> +v_r[j % 4] = r;
> +v_g[j % 4] = g;
> +v_b[j % 4] = b;
> +
> +if (!(j % 4)) {
> +v_tmp = v_ry * v_r;
> +v_tmp = v_tmp + v_gy * v_g;
> +v_tmp = v_tmp + v_by * v_b;
> +v_tmp = v_tmp + v_opr2;
> +v_tmp = vec_sr(v_tmp, (vector unsigned int)v_opr1);
> +
> +v_tmpi  = (vector short)v_tmp;
> +v_dst[(j / 4) * 4 + 3]  = v_tmpi[6];
> +v_dst[(j / 4) * 4 + 2]  = v_tmpi[4];
> +v_dst[(j / 4) * 4 + 1]  = v_tmpi[2];
> +v_dst[(j / 4) * 4 + 0]  = v_tmpi[0];
> +}

[FFmpeg-devel] [PATCH 2/3] avformat/segment: Ensure write_trailer is called

2016-06-20 Thread sebechlebskyjan

From: Jan Sebechlebsky 

Ensure that write_trailer is always called after successful
write_header operation so underlying muxer is deinitialized.

Signed-off-by: Jan Sebechlebsky 
---
 This is a little tricky - we have to ensure that 
 write_trailer is called if the write_header succeeded, however
 if the io_open fails the AVIOContext is invalid and cause
 underlying muxer to crash (the muxer may assume that AVIOContext 
 is initialized). So temporarily AVIOContext is initialized to null
 context just to allow write_trailer to finalize underlying muxer
 successfully.

 libavformat/segment.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 7e4e840..df37a56 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -763,6 +763,8 @@ static int seg_init(AVFormatContext *s)
 av_log(s, AV_LOG_ERROR,
"Some of the provided format options in '%s' are not 
recognized\n", seg->format_options_str);
 ret = AVERROR(EINVAL);
+av_write_trailer(oc);
+ff_format_io_close(oc, &oc->pb);
 goto fail;
 }
 
@@ -785,8 +787,14 @@ static int seg_init(AVFormatContext *s)
 } else {
 close_null_ctxp(&oc->pb);
 }
-if ((ret = oc->io_open(oc, &oc->pb, oc->filename, AVIO_FLAG_WRITE, 
NULL)) < 0)
+if ((ret = oc->io_open(oc, &oc->pb, oc->filename, AVIO_FLAG_WRITE, 
NULL)) < 0) {
+// Some muxers rely on valid AVIOContext so we need to create one
+// before performing write trailer
+open_null_ctx(&oc->pb);
+av_write_trailer(oc);
+close_null_ctxp(&oc->pb);
 goto fail;
+}
 if (!seg->individual_header_trailer)
 oc->pb->seekable = 0;
 }
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avformat/segment: Use deinit function to deinitialize muxer

2016-06-20 Thread sebechlebskyjan

From: Jan Sebechlebsky 

This commit moves all deinitialization of SegmentContext to
seg_free_context function and registers this function as
.deinit function of segment muxer. This also fixes memory leaks
caused by context not being deinitialized when write_header
call of segment muxer fails.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/segment.c | 49 +++--
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index df37a56..872233b 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -627,9 +627,28 @@ static int select_reference_stream(AVFormatContext *s)
 return 0;
 }
 
-static void seg_free_context(SegmentContext *seg)
+static void seg_free_context(AVFormatContext *s)
 {
-ff_format_io_close(seg->avf, &seg->list_pb);
+SegmentContext *seg = s->priv_data;
+SegmentListEntry *cur, *next;
+
+if (seg->list)
+ff_format_io_close(s, &seg->list_pb);
+
+av_dict_free(&seg->format_options);
+av_opt_free(seg);
+av_freep(&seg->times);
+av_freep(&seg->frames);
+av_freep(&seg->cur_entry.filename);
+
+cur = seg->segment_list_entries;
+while (cur) {
+next = cur->next;
+av_freep(&cur->filename);
+av_free(cur);
+cur = next;
+}
+
 avformat_free_context(seg->avf);
 seg->avf = NULL;
 }
@@ -801,8 +820,6 @@ static int seg_init(AVFormatContext *s)
 
 fail:
 av_dict_free(&options);
-if (ret < 0)
-seg_free_context(seg);
 
 return ret;
 }
@@ -917,9 +934,6 @@ fail:
 seg->segment_frame_count++;
 }
 
-if (ret < 0)
-seg_free_context(seg);
-
 return ret;
 }
 
@@ -944,25 +958,6 @@ static int seg_write_trailer(struct AVFormatContext *s)
 ret = segment_end(s, 1, 1);
 }
 fail:
-if (seg->list)
-ff_format_io_close(s, &seg->list_pb);
-
-av_dict_free(&seg->format_options);
-av_opt_free(seg);
-av_freep(&seg->times);
-av_freep(&seg->frames);
-av_freep(&seg->cur_entry.filename);
-
-cur = seg->segment_list_entries;
-while (cur) {
-next = cur->next;
-av_freep(&cur->filename);
-av_free(cur);
-cur = next;
-}
-
-avformat_free_context(oc);
-seg->avf = NULL;
 return ret;
 }
 
@@ -1045,6 +1040,7 @@ AVOutputFormat ff_segment_muxer = {
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
 .check_bitstream = seg_check_bitstream,
+.deinit = seg_free_context,
 .priv_class = &seg_class,
 };
 
@@ -1064,5 +1060,6 @@ AVOutputFormat ff_stream_segment_muxer = {
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
 .check_bitstream = seg_check_bitstream,
+.deinit = seg_free_context,
 .priv_class = &sseg_class,
 };
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fix memory leaks in segment muxer

2016-06-20 Thread sebechlebskyjan

From: Jan Sebechlebsky 

Hello,
I've observed several memory leaks in segment muxer in case the
failure happens in seg_init (write_header call). 
I'm sending patchset to fix those.

Regards,
Jan

Jan Sebechlebsky (3):
  avformat/segment: Check write_header return value immediately
  avformat/segment: Ensure write_trailer is called
  avformat/segment: Use deinit function to deinitialize muxer

 libavformat/segment.c | 68 ---
 1 file changed, 37 insertions(+), 31 deletions(-)

-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avformat/segment: Check write_header return value immediately

2016-06-20 Thread sebechlebskyjan

From: Jan Sebechlebsky 

Check write_header return value immediately after call,
so in the successive statements we can assume the write_header
was successful.

Signed-off-by: Jan Sebechlebsky 
---
 This is needed for the next patch in patchset.

 libavformat/segment.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index df6f4b5..7e4e840 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -754,6 +754,11 @@ static int seg_init(AVFormatContext *s)
 
 av_dict_copy(&options, seg->format_options, 0);
 ret = avformat_write_header(oc, &options);
+if (ret < 0) {
+ff_format_io_close(oc, &oc->pb);
+goto fail;
+}
+
 if (av_dict_count(options)) {
 av_log(s, AV_LOG_ERROR,
"Some of the provided format options in '%s' are not 
recognized\n", seg->format_options_str);
@@ -761,10 +766,6 @@ static int seg_init(AVFormatContext *s)
 goto fail;
 }
 
-if (ret < 0) {
-ff_format_io_close(oc, &oc->pb);
-goto fail;
-}
 seg->segment_frame_count = 0;
 
 av_assert0(s->nb_streams == oc->nb_streams);
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/h264_ps: add ff_h264_ps_uninit and use it

2016-06-20 Thread Matthieu Bouron

On Mon, Jun 20, 2016 at 05:00:22PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 04:13:02PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > ---
> >  libavcodec/h264.c| 10 +-
> >  libavcodec/h264.h|  6 ++
> >  libavcodec/h264_parser.c |  8 +---
> >  libavcodec/h264_ps.c | 17 +
> >  4 files changed, 25 insertions(+), 16 deletions(-)
> 
> probably ok

Pushed. Thanks.

[...]

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS

2016-06-20 Thread Matthieu Bouron

On Mon, Jun 20, 2016 at 12:03:58PM +0200, Matthieu Bouron wrote:
> On Sun, Jun 19, 2016 at 07:44:44PM +0200, Matthieu Bouron wrote:
> > On Mon, Jun 13, 2016 at 02:37:29PM +0200, Matthieu Bouron wrote:
> > > On Mon, Jun 13, 2016 at 12:23:07PM +0200, Hendrik Leppkes wrote:
> > > > On Mon, Jun 13, 2016 at 11:51 AM, Matthieu Bouron
> > > >  wrote:
> > > > > On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
> > > > >> From: Matthieu Bouron 
> > > > >>
> > > > >> Fixes playback of HLS streams on MediaTek devices which requires 
> > > > >> PPS/SPS
> > > > >> to be set in their respective csd-{0,1} buffers.
> > > > >> ---
> > > > >>
> > > > >> Hello,
> > > > >>
> > > > >> The attached patch fixes playback of HLS streams on MediaTek devices 
> > > > >> which
> > > > >> requires PPS/SPS to be set in their respetive csd-{0,1} buffers 
> > > > >> (instead of
> > > > >> having sps+pps in the csd-0 which works on other devices).
> > > > >>
> > > > >> I'm not sure if I can use the ff_h264_decode_extradata this way (or 
> > > > >> at least
> > > > >> initialize the H264Context with zeroes minus the avctx field).
> > > > >
> > > > > Rebased patch (after the h264 ps merged) attached.
> > > > >
> > > > > I still have the same question, is my use of
> > > > > H264Context + ff_h264_decode_extradata correct ?
> > > > >
> > > > 
> > > > Using H264 decoder internals seems to be a rather unfortunate
> > > > solution, as its prone to breakage, often subtle, as the h264 decoder
> > > > gets changed and not all inter-module dependencies are known.
> > > > So if possible at all, not using something that uses H264Context for
> > > > example would be nice.
> > > > 
> > > > For the record, ff_h264_decode_extradata is scheduled for refactoring
> > > > to make it independent of H264Context so it can be more easily shared
> > > > with the h264 decoder and the h264 parser.
> > > > Once that is done, it may give you a cleaner interface to use it from
> > > > mediacodec as well.
> > > 
> > > Ok. I can wait for the refactor to be merged but the MediaCodec decoder
> > > will remain broken on those devices. I'm not too happy about that if a
> > > release is to be made in those following days. Do we have an ETA ?  I'm
> > > also not too happy to write the same parsing code as I did before for the
> > > AVCC format to split/extract the PPS/SPS.
> > > 
> > > Or ..., I can push this code (if its use is valid) and update it when the
> > > merge lands (I'm helping Clément with the merges, so I will take care
> > > about this part).
> > 
> > Updated patch attached (using the new ff_h264_decode_extradata API).
> > 
> 
> Correct patch attached (the previous one was incorrect).
> 
> [...]

> From a27b3ece788cbbe459226f50fbdaf12ce3fee1bb Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 10 Jun 2016 13:16:09 +0200
> Subject: [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to
>  extract PPS/SPS
> 
> Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
> to be set in their respective csd-{0,1} buffers.
> ---
>  libavcodec/mediacodecdec_h264.c | 153 
> +++-
>  1 file changed, 42 insertions(+), 111 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
> index 0f90606..219649a 100644
> --- a/libavcodec/mediacodecdec_h264.c
> +++ b/libavcodec/mediacodecdec_h264.c
> @@ -32,6 +32,7 @@
>  #include "libavutil/atomic.h"
>  
>  #include "avcodec.h"
> +#include "h264.h"
>  #include "internal.h"
>  #include "mediacodecdec.h"
>  #include "mediacodec_wrapper.h"
> @@ -50,104 +51,6 @@ typedef struct MediaCodecH264DecContext {
>  
>  } MediaCodecH264DecContext;
>  
> -static int h264_extradata_to_annexb_sps_pps(AVCodecContext *avctx,
> -uint8_t **extradata_annexb, int *extradata_annexb_size,
> -int *sps_offset, int *sps_size,
> -int *pps_offset, int *pps_size)
> -{
> -uint16_t unit_size;
> -uint64_t total_size = 0;
> -
> -uint8_t i, j, unit_nb;
> -uint8_t sps_seen = 0;
> -uint8_t pps_seen = 0;
> -
> -const uint8_t *extradata;
> -static const uint8_t nalu_header[4] = { 0x00, 0x00, 0x00, 0x01 };
> -
> -if (avctx->extradata_size < 8) {
> -av_log(avctx, AV_LOG_ERROR,
> -"Too small extradata size, corrupted stream or invalid MP4/AVCC 
> bitstream\n");
> -return AVERROR(EINVAL);
> -}
> -
> -*extradata_annexb = NULL;
> -*extradata_annexb_size = 0;
> -
> -*sps_offset = *sps_size = 0;
> -*pps_offset = *pps_size = 0;
> -
> -extradata = avctx->extradata + 4;
> -
> -/* skip length size */
> -extradata++;
> -
> -for (j = 0; j < 2; j ++) {
> -
> -if (j == 0) {
> -/* number of sps unit(s) */
> -unit_nb = *extradata++ & 0x1f;
> -} else {
> -/* number of pps unit(s) */
> -unit_nb = *extradata++;
> -}
> -
> -for (i = 0; i < unit_nb; i++) {
> -int e

[FFmpeg-devel] [PATCH] fate: add test for alimiter

2016-06-20 Thread Petru Rares Sincraian

Hi there,

Today I make a test for alimiter. Here is it :)


Regards,
Petru Rares.From f964d3524773df919d09df3316878997b8738f2b Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Mon, 20 Jun 2016 19:32:36 +0200
Subject: [PATCH] fate: add test for alimiter

---
 tests/fate/filter-audio.mak|   5 +
 tests/ref/fate/filter-alimiter | 264 +
 2 files changed, 269 insertions(+)
 create mode 100644 tests/ref/fate/filter-alimiter

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 7c903b7..2bdb644 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -63,6 +63,11 @@ fate-filter-agate: tests/data/asynth-44100-2.wav
 fate-filter-agate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-agate: CMD = framecrc -i $(SRC) -af agate=level_in=10:range=0:threshold=1:ratio=1:attack=1:knee=1:makeup=4
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, AFADE, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-alimiter
+fate-filter-alimiter: tests/data/asynth-44100-2.wav
+fate-filter-alimiter: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-alimiter: CMD = framecrc -i $(SRC) -af alimiter=level_in=1:level_out=2:limit=0.2
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-alimiter b/tests/ref/fate/filter-alimiter
new file mode 100644
index 000..06e23f1
--- /dev/null
+++ b/tests/ref/fate/filter-alimiter
@@ -0,0 +1,264 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0xd4194af4
+0,   1024,   1024, 1024, 4096, 0x686af4ab
+0,   2048,   2048, 1024, 4096, 0xe80cee61
+0,   3072,   3072, 1024, 4096, 0xa686fbad
+0,   4096,   4096, 1024, 4096, 0x191e062c
+0,   5120,   5120, 1024, 4096, 0x1a13edb1
+0,   6144,   6144, 1024, 4096, 0xab21f8ef
+0,   7168,   7168, 1024, 4096, 0xaa30e757
+0,   8192,   8192, 1024, 4096, 0x5afdf69f
+0,   9216,   9216, 1024, 4096, 0x765e05ec
+0,  10240,  10240, 1024, 4096, 0x6484f551
+0,  11264,  11264, 1024, 4096, 0x61b9e9f7
+0,  12288,  12288, 1024, 4096, 0xa735feb3
+0,  13312,  13312, 1024, 4096, 0xb47203aa
+0,  14336,  14336, 1024, 4096, 0xb6b5fbf5
+0,  15360,  15360, 1024, 4096, 0xbc66f14f
+0,  16384,  16384, 1024, 4096, 0x2003ff5b
+0,  17408,  17408, 1024, 4096, 0x1160f17d
+0,  18432,  18432, 1024, 4096, 0x308001a4
+0,  19456,  19456, 1024, 4096, 0x9df9f429
+0,  20480,  20480, 1024, 4096, 0x3e6eec0f
+0,  21504,  21504, 1024, 4096, 0xca3301f2
+0,  22528,  22528, 1024, 4096, 0x9eb1f961
+0,  23552,  23552, 1024, 4096, 0xd0a50c8c
+0,  24576,  24576, 1024, 4096, 0x071ee96b
+0,  25600,  25600, 1024, 4096, 0x7a46f05b
+0,  26624,  26624, 1024, 4096, 0x2cb2f475
+0,  27648,  27648, 1024, 4096, 0x5bda0a52
+0,  28672,  28672, 1024, 4096, 0x33c0f727
+0,  29696,  29696, 1024, 4096, 0x53cfee59
+0,  30720,  30720, 1024, 4096, 0x1588f221
+0,  31744,  31744, 1024, 4096, 0x95d400d6
+0,  32768,  32768, 1024, 4096, 0x0078009a
+0,  33792,  33792, 1024, 4096, 0x686af4ab
+0,  34816,  34816, 1024, 4096, 0xe80cee61
+0,  35840,  35840, 1024, 4096, 0xa686fbad
+0,  36864,  36864, 1024, 4096, 0x191e062c
+0,  37888,  37888, 1024, 4096, 0x1a13edb1
+0,  38912,  38912, 1024, 4096, 0xab21f8ef
+0,  39936,  39936, 1024, 4096, 0xaa30e757
+0,  40960,  40960, 1024, 4096, 0x5afdf69f
+0,  41984,  41984, 1024, 4096, 0x765e05ec
+0,  43008,  43008, 1024, 4096, 0x6484f551
+0,  44032,  44032, 1024, 4096, 0x755e0600
+0,  45056,  45056, 1024, 4096, 0x5056ecb9
+0,  46080,  46080, 1024, 4096, 0xdcb609a8
+0,  47104,  47104, 1024, 4096, 0xc87bf4a1
+0,  48128,  48128, 1024, 4096, 0xecdfef95
+0,  49152,  49152, 1024, 4096, 0x905ff13f
+0,  50176,  50176, 1024, 4096, 0x4e69eeb3
+0,  51200,  51200, 1024, 4096, 0x16e1082c
+0,  52224,  52224, 1024, 4096, 0x606c0a22
+0,  53248,  53248, 1024, 4096, 0x9f94f351
+0,  54272,  54272, 1024, 4096, 0x2c47f63f
+0,  55296,  55296, 1024, 4096, 0x9e14ebf9
+0,  56320,  56320, 1024, 4096, 0x7804fbcb
+0,  57344,

Re: [FFmpeg-devel] Fix memory leaks in segment muxer

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 05:24:04PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Hello,
> I've observed several memory leaks in segment muxer in case the
> failure happens in seg_init (write_header call). 
> I'm sending patchset to fix those.
> 
> Regards,
> Jan
> 
> Jan Sebechlebsky (3):
>   avformat/segment: Check write_header return value immediately
>   avformat/segment: Ensure write_trailer is called
>   avformat/segment: Use deinit function to deinitialize muxer
> 
>  libavformat/segment.c | 68 
> ---
>  1 file changed, 37 insertions(+), 31 deletions(-)

seems to cause:
libavformat/segment.c: In function ‘seg_write_trailer’:
libavformat/segment.c:944:29: warning: unused variable ‘next’ 
[-Wunused-variable]
libavformat/segment.c:944:23: warning: unused variable ‘cur’ [-Wunused-variable]

no more comments from me, review left to others

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add test for alimiter

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 05:35:34PM +, Petru Rares Sincraian wrote:
> Hi there,
> 
> Today I make a test for alimiter. Here is it :)
> 
> 
> Regards,
> Petru Rares.

>  fate/filter-audio.mak|5 
>  ref/fate/filter-alimiter |  264 
> +++
>  2 files changed, 269 insertions(+)
> 751aa7ceef39ec8af91725caaee4967c3861cae0  
> 0001-fate-add-test-for-alimiter.patch
> From f964d3524773df919d09df3316878997b8738f2b Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Mon, 20 Jun 2016 19:32:36 +0200
> Subject: [PATCH] fate: add test for alimiter
> 
> ---
>  tests/fate/filter-audio.mak|   5 +
>  tests/ref/fate/filter-alimiter | 264 
> +
>  2 files changed, 269 insertions(+)
>  create mode 100644 tests/ref/fate/filter-alimiter
> 
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 7c903b7..2bdb644 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -63,6 +63,11 @@ fate-filter-agate: tests/data/asynth-44100-2.wav
>  fate-filter-agate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
>  fate-filter-agate: CMD = framecrc -i $(SRC) -af 
> agate=level_in=10:range=0:threshold=1:ratio=1:attack=1:knee=1:makeup=4
>  
> +FATE_AFILTER-$(call FILTERDEMDECENCMUX, AFADE, WAV, PCM_S16LE, PCM_S16LE, 
> WAV) += fate-filter-alimiter
> +fate-filter-alimiter: tests/data/asynth-44100-2.wav
> +fate-filter-alimiter: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
> +fate-filter-alimiter: CMD = framecrc -i $(SRC) -af 
> alimiter=level_in=1:level_out=2:limit=0.2
> +
>  tests/data/hls-list.m3u8: TAG = GEN
>  tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Remove Benjamin Larsson from MAINTAINERS

2016-06-20 Thread Lou Logan

On Thu,  9 Jun 2016 21:21:22 +0200, Benjamin Larsson wrote:

> ---
>  MAINTAINERS | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)

Applied after removing blocking trailing whitespace.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/3] avformat/segment: Use deinit function to deinitialize muxer

2016-06-20 Thread sebechlebskyjan

From: Jan Sebechlebsky 

This commit moves all deinitialization of SegmentContext to
seg_free_context function and registers this function as
.deinit function of segment muxer. This also fixes memory leaks
caused by context not being deinitialized when write_header
call of segment muxer fails.

Signed-off-by: Jan Sebechlebsky 
---
 Thanks for noticing, I've removed unused declarations, this patch
 should be fine.

 libavformat/segment.c | 50 +++---
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index df37a56..c9d0074 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -627,9 +627,28 @@ static int select_reference_stream(AVFormatContext *s)
 return 0;
 }
 
-static void seg_free_context(SegmentContext *seg)
+static void seg_free_context(AVFormatContext *s)
 {
-ff_format_io_close(seg->avf, &seg->list_pb);
+SegmentContext *seg = s->priv_data;
+SegmentListEntry *cur, *next;
+
+if (seg->list)
+ff_format_io_close(s, &seg->list_pb);
+
+av_dict_free(&seg->format_options);
+av_opt_free(seg);
+av_freep(&seg->times);
+av_freep(&seg->frames);
+av_freep(&seg->cur_entry.filename);
+
+cur = seg->segment_list_entries;
+while (cur) {
+next = cur->next;
+av_freep(&cur->filename);
+av_free(cur);
+cur = next;
+}
+
 avformat_free_context(seg->avf);
 seg->avf = NULL;
 }
@@ -801,8 +820,6 @@ static int seg_init(AVFormatContext *s)
 
 fail:
 av_dict_free(&options);
-if (ret < 0)
-seg_free_context(seg);
 
 return ret;
 }
@@ -917,9 +934,6 @@ fail:
 seg->segment_frame_count++;
 }
 
-if (ret < 0)
-seg_free_context(seg);
-
 return ret;
 }
 
@@ -927,7 +941,6 @@ static int seg_write_trailer(struct AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
 AVFormatContext *oc = seg->avf;
-SegmentListEntry *cur, *next;
 int ret = 0;
 
 if (!oc)
@@ -944,25 +957,6 @@ static int seg_write_trailer(struct AVFormatContext *s)
 ret = segment_end(s, 1, 1);
 }
 fail:
-if (seg->list)
-ff_format_io_close(s, &seg->list_pb);
-
-av_dict_free(&seg->format_options);
-av_opt_free(seg);
-av_freep(&seg->times);
-av_freep(&seg->frames);
-av_freep(&seg->cur_entry.filename);
-
-cur = seg->segment_list_entries;
-while (cur) {
-next = cur->next;
-av_freep(&cur->filename);
-av_free(cur);
-cur = next;
-}
-
-avformat_free_context(oc);
-seg->avf = NULL;
 return ret;
 }
 
@@ -1045,6 +1039,7 @@ AVOutputFormat ff_segment_muxer = {
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
 .check_bitstream = seg_check_bitstream,
+.deinit = seg_free_context,
 .priv_class = &seg_class,
 };
 
@@ -1064,5 +1059,6 @@ AVOutputFormat ff_stream_segment_muxer = {
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
 .check_bitstream = seg_check_bitstream,
+.deinit = seg_free_context,
 .priv_class = &sseg_class,
 };
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swresample/x86: add support for exact_rational

2016-06-20 Thread Muhammad Faiz

On Mon, Jun 20, 2016 at 8:16 PM, Michael Niedermayer
 wrote:
> On Thu, Jun 16, 2016 at 12:31:04AM +0700, Muhammad Faiz wrote:
>> phase_shift and phase_mask is removed
>> generally exact_rational=on is faster than exact_rational=off
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libswresample/resample.c  |  2 -
>>  libswresample/resample.h  |  3 --
>>  libswresample/x86/resample.asm| 87 
>> +--
>>  libswresample/x86/resample_init.c |  4 --
>>  4 files changed, 46 insertions(+), 50 deletions(-)
>
> tested on mingwg32/64 and linux 32/64
>
applied

thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Michael Niedermayer

On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> First commit addressing Trac ticket #5570. Functions defined in 
> libswscale/input.c
> have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> ---
>  libswscale/ppc/Makefile   |1 +
>  libswscale/ppc/input_vsx.c| 1070 
> +
>  libswscale/swscale.c  |3 +
>  libswscale/swscale_internal.h |1 +
>  4 files changed, 1075 insertions(+)
>  create mode 100644 libswscale/ppc/input_vsx.c
> 
> diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> index d1b596e..2482893 100644
> --- a/libswscale/ppc/Makefile
> +++ b/libswscale/ppc/Makefile
> @@ -1,3 +1,4 @@
>  OBJS += ppc/swscale_altivec.o   \
> +ppc/input_vsx.o \
>  ppc/yuv2rgb_altivec.o   \
>  ppc/yuv2yuv_altivec.o   \
> diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> new file mode 100644
> index 000..adb0e38
> --- /dev/null
> +++ b/libswscale/ppc/input_vsx.c
> @@ -0,0 +1,1070 @@
> +/*
> + * Copyright (C) 2016 Dan Parrot 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "libavutil/avutil.h"
> +#include "libavutil/bswap.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/avassert.h"
> +#include "config.h"
> +#include "libswscale/rgb2rgb.h"
> +#include "libswscale/swscale.h"
> +#include "libswscale/swscale_internal.h"
> +
> +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> +
> +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> +
> +#if HAVE_VSX
> +
> +// This is a SIMD version for IBM POWER8 of function rgb64ToY_c_template
> +// in file libswscale/input.c
> +static av_always_inline void
> +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
> +enum AVPixelFormat origin, int32_t *rgb2yuv)
> +{
> +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = rgb2yuv[BY_IDX];
> +int i, j;
> +int num_vec, frag;
> +
> +num_vec = width / 8;
> +frag= width % 8;
> +
> +vector int v_ry = vec_splats((int)ry);
> +vector int v_gy = vec_splats((int)gy);
> +vector int v_by = vec_splats((int)by);
> +
> +int s_opr2;
> +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> +
> +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> +vector int v_opr2 = vec_splats((int)s_opr2);
> +
> +vector int v_r, v_g, v_b, v_tmp;
> +vector short v_tmpi, v_dst;
> +
> +for (i = 0; i < num_vec; i++) {
> +for (j = 7; j >= 0  ; j--) {
> +int r_b = input_pixel(&src[(i*8+j)*4+0]);
> +int g   = input_pixel(&src[(i*8+j)*4+1]);
> +int b_r = input_pixel(&src[(i*8+j)*4+2]);
> +
> +v_r[j % 4] = r;
> +v_g[j % 4] = g;
> +v_b[j % 4] = b;
> +
> +if (!(j % 4)) {
   ^

> +v_tmp = v_ry * v_r;
> +v_tmp = v_tmp + v_gy * v_g;
> +v_tmp = v_tmp + v_by * v_b;
> +v_tmp = v_tmp + v_opr2;
> +v_tmp = vec_sr(v_tmp, (vector unsigned int)v_opr1);
> +
> +v_tmpi  = (vector short)v_tmp;
> +v_dst[(j / 4) * 4 + 3]  = v_tmpi[6];
^
what is the speed of a division and modulo on PPC compared to a
bitwise and ?

its also not trivial for the compiler to optimize then out as it
has to proof the varables are never negative


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristot

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Dan Parrot

On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > First commit addressing Trac ticket #5570. Functions defined in 
> > libswscale/input.c
> > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > ---
> >  libswscale/ppc/Makefile   |1 +
> >  libswscale/ppc/input_vsx.c| 1070 
> > +
> >  libswscale/swscale.c  |3 +
> >  libswscale/swscale_internal.h |1 +
> >  4 files changed, 1075 insertions(+)
> >  create mode 100644 libswscale/ppc/input_vsx.c
> > 
> > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > index d1b596e..2482893 100644
> > --- a/libswscale/ppc/Makefile
> > +++ b/libswscale/ppc/Makefile
> > @@ -1,3 +1,4 @@
> >  OBJS += ppc/swscale_altivec.o   \
> > +ppc/input_vsx.o \
> >  ppc/yuv2rgb_altivec.o   \
> >  ppc/yuv2yuv_altivec.o   \
> > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > new file mode 100644
> > index 000..adb0e38
> > --- /dev/null
> > +++ b/libswscale/ppc/input_vsx.c
> > @@ -0,0 +1,1070 @@
> > +/*
> > + * Copyright (C) 2016 Dan Parrot 
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > 02110-1301 USA
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "libavutil/avutil.h"
> > +#include "libavutil/bswap.h"
> > +#include "libavutil/cpu.h"
> > +#include "libavutil/intreadwrite.h"
> > +#include "libavutil/mathematics.h"
> > +#include "libavutil/pixdesc.h"
> > +#include "libavutil/avassert.h"
> > +#include "config.h"
> > +#include "libswscale/rgb2rgb.h"
> > +#include "libswscale/swscale.h"
> > +#include "libswscale/swscale_internal.h"
> > +
> > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> > +
> > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : 
> > r_b)
> > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : 
> > b_r)
> > +
> > +#if HAVE_VSX
> > +
> > +// This is a SIMD version for IBM POWER8 of function rgb64ToY_c_template
> > +// in file libswscale/input.c
> > +static av_always_inline void
> > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
> > +enum AVPixelFormat origin, int32_t *rgb2yuv)
> > +{
> > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > rgb2yuv[BY_IDX];
> > +int i, j;
> > +int num_vec, frag;
> > +
> > +num_vec = width / 8;
> > +frag= width % 8;
> > +
> > +vector int v_ry = vec_splats((int)ry);
> > +vector int v_gy = vec_splats((int)gy);
> > +vector int v_by = vec_splats((int)by);
> > +
> > +int s_opr2;
> > +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> > +
> > +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> > +vector int v_opr2 = vec_splats((int)s_opr2);
> > +
> > +vector int v_r, v_g, v_b, v_tmp;
> > +vector short v_tmpi, v_dst;
> > +
> > +for (i = 0; i < num_vec; i++) {
> > +for (j = 7; j >= 0  ; j--) {
> > +int r_b = input_pixel(&src[(i*8+j)*4+0]);
> > +int g   = input_pixel(&src[(i*8+j)*4+1]);
> > +int b_r = input_pixel(&src[(i*8+j)*4+2]);
> > +
> > +v_r[j % 4] = r;
> > +v_g[j % 4] = g;
> > +v_b[j % 4] = b;
> > +
> > +if (!(j % 4)) {
>^
> 
> > +v_tmp = v_ry * v_r;
> > +v_tmp = v_tmp + v_gy * v_g;
> > +v_tmp = v_tmp + v_by * v_b;
> > +v_tmp = v_tmp + v_opr2;
> > +v_tmp = vec_sr(v_tmp, (vector unsigned int)v_opr1);
> > +
> > +v_tmpi  = (vector short)v_tmp;
> > +v_dst[(j / 4) * 4 + 3]  = v_tmpi[6];
> ^
> what is the speed of a division and modulo on PPC compared to a
>

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> > On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > > First commit addressing Trac ticket #5570. Functions defined in 
> > > libswscale/input.c
> > > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > > ---
> > >  libswscale/ppc/Makefile   |1 +
> > >  libswscale/ppc/input_vsx.c| 1070 
> > > +
> > >  libswscale/swscale.c  |3 +
> > >  libswscale/swscale_internal.h |1 +
> > >  4 files changed, 1075 insertions(+)
> > >  create mode 100644 libswscale/ppc/input_vsx.c
> > > 
> > > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > > index d1b596e..2482893 100644
> > > --- a/libswscale/ppc/Makefile
> > > +++ b/libswscale/ppc/Makefile
> > > @@ -1,3 +1,4 @@
> > >  OBJS += ppc/swscale_altivec.o   \
> > > +ppc/input_vsx.o \
> > >  ppc/yuv2rgb_altivec.o   \
> > >  ppc/yuv2yuv_altivec.o   \
> > > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > > new file mode 100644
> > > index 000..adb0e38
> > > --- /dev/null
> > > +++ b/libswscale/ppc/input_vsx.c
> > > @@ -0,0 +1,1070 @@
> > > +/*
> > > + * Copyright (C) 2016 Dan Parrot 
> > > + *
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > 02110-1301 USA
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include "libavutil/avutil.h"
> > > +#include "libavutil/bswap.h"
> > > +#include "libavutil/cpu.h"
> > > +#include "libavutil/intreadwrite.h"
> > > +#include "libavutil/mathematics.h"
> > > +#include "libavutil/pixdesc.h"
> > > +#include "libavutil/avassert.h"
> > > +#include "config.h"
> > > +#include "libswscale/rgb2rgb.h"
> > > +#include "libswscale/swscale.h"
> > > +#include "libswscale/swscale_internal.h"
> > > +
> > > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> > > +
> > > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r 
> > > : r_b)
> > > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b 
> > > : b_r)
> > > +
> > > +#if HAVE_VSX
> > > +
> > > +// This is a SIMD version for IBM POWER8 of function rgb64ToY_c_template
> > > +// in file libswscale/input.c
> > > +static av_always_inline void
> > > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
> > > +enum AVPixelFormat origin, int32_t *rgb2yuv)
> > > +{
> > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > > rgb2yuv[BY_IDX];
> > > +int i, j;
> > > +int num_vec, frag;
> > > +
> > > +num_vec = width / 8;
> > > +frag= width % 8;
> > > +
> > > +vector int v_ry = vec_splats((int)ry);
> > > +vector int v_gy = vec_splats((int)gy);
> > > +vector int v_by = vec_splats((int)by);
> > > +
> > > +int s_opr2;
> > > +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> > > +
> > > +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> > > +vector int v_opr2 = vec_splats((int)s_opr2);
> > > +
> > > +vector int v_r, v_g, v_b, v_tmp;
> > > +vector short v_tmpi, v_dst;
> > > +
> > > +for (i = 0; i < num_vec; i++) {
> > > +for (j = 7; j >= 0  ; j--) {
> > > +int r_b = input_pixel(&src[(i*8+j)*4+0]);
> > > +int g   = input_pixel(&src[(i*8+j)*4+1]);
> > > +int b_r = input_pixel(&src[(i*8+j)*4+2]);
> > > +
> > > +v_r[j % 4] = r;
> > > +v_g[j % 4] = g;
> > > +v_b[j % 4] = b;
> > > +
> > > +if (!(j % 4)) {
> >^
> > 
> > > +v_tmp = v_ry * v_r;
> > > +v_tmp = v_tmp + v_gy * v_g;
> > > +v_tmp = v_tmp + v_by * v_b;
> > > +v_tmp =

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Dan Parrot

On Tue, 2016-06-21 at 01:06 +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> > On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> > > On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > > > First commit addressing Trac ticket #5570. Functions defined in 
> > > > libswscale/input.c
> > > > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > > > ---
> > > >  libswscale/ppc/Makefile   |1 +
> > > >  libswscale/ppc/input_vsx.c| 1070 
> > > > +
> > > >  libswscale/swscale.c  |3 +
> > > >  libswscale/swscale_internal.h |1 +
> > > >  4 files changed, 1075 insertions(+)
> > > >  create mode 100644 libswscale/ppc/input_vsx.c
> > > > 
> > > > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > > > index d1b596e..2482893 100644
> > > > --- a/libswscale/ppc/Makefile
> > > > +++ b/libswscale/ppc/Makefile
> > > > @@ -1,3 +1,4 @@
> > > >  OBJS += ppc/swscale_altivec.o  
> > > >  \
> > > > +ppc/input_vsx.o
> > > >  \
> > > >  ppc/yuv2rgb_altivec.o  
> > > >  \
> > > >  ppc/yuv2yuv_altivec.o  
> > > >  \
> > > > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > > > new file mode 100644
> > > > index 000..adb0e38
> > > > --- /dev/null
> > > > +++ b/libswscale/ppc/input_vsx.c
> > > > @@ -0,0 +1,1070 @@
> > > > +/*
> > > > + * Copyright (C) 2016 Dan Parrot 
> > > > + *
> > > > + * This file is part of FFmpeg.
> > > > + *
> > > > + * FFmpeg is free software; you can redistribute it and/or
> > > > + * modify it under the terms of the GNU Lesser General Public
> > > > + * License as published by the Free Software Foundation; either
> > > > + * version 2.1 of the License, or (at your option) any later version.
> > > > + *
> > > > + * FFmpeg is distributed in the hope that it will be useful,
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > > + * Lesser General Public License for more details.
> > > > + *
> > > > + * You should have received a copy of the GNU Lesser General Public
> > > > + * License along with FFmpeg; if not, write to the Free Software
> > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > > 02110-1301 USA
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include "libavutil/avutil.h"
> > > > +#include "libavutil/bswap.h"
> > > > +#include "libavutil/cpu.h"
> > > > +#include "libavutil/intreadwrite.h"
> > > > +#include "libavutil/mathematics.h"
> > > > +#include "libavutil/pixdesc.h"
> > > > +#include "libavutil/avassert.h"
> > > > +#include "config.h"
> > > > +#include "libswscale/rgb2rgb.h"
> > > > +#include "libswscale/swscale.h"
> > > > +#include "libswscale/swscale_internal.h"
> > > > +
> > > > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> > > > +
> > > > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> > > > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> > > > +
> > > > +#if HAVE_VSX
> > > > +
> > > > +// This is a SIMD version for IBM POWER8 of function 
> > > > rgb64ToY_c_template
> > > > +// in file libswscale/input.c
> > > > +static av_always_inline void
> > > > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
> > > > +enum AVPixelFormat origin, int32_t *rgb2yuv)
> > > > +{
> > > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > > > rgb2yuv[BY_IDX];
> > > > +int i, j;
> > > > +int num_vec, frag;
> > > > +
> > > > +num_vec = width / 8;
> > > > +frag= width % 8;
> > > > +
> > > > +vector int v_ry = vec_splats((int)ry);
> > > > +vector int v_gy = vec_splats((int)gy);
> > > > +vector int v_by = vec_splats((int)by);
> > > > +
> > > > +int s_opr2;
> > > > +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> > > > +
> > > > +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> > > > +vector int v_opr2 = vec_splats((int)s_opr2);
> > > > +
> > > > +vector int v_r, v_g, v_b, v_tmp;
> > > > +vector short v_tmpi, v_dst;
> > > > +
> > > > +for (i = 0; i < num_vec; i++) {
> > > > +for (j = 7; j >= 0  ; j--) {
> > > > +int r_b = input_pixel(&src[(i*8+j)*4+0]);
> > > > +int g   = input_pixel(&src[(i*8+j)*4+1]);
> > > > +int b_r = input_pixel(&src[(i*8+j)*4+2]);
> > > > +
> > > > +v_r[j

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Michael Niedermayer

On Mon, Jun 20, 2016 at 06:38:18PM -0500, Dan Parrot wrote:
> On Tue, 2016-06-21 at 01:06 +0200, Michael Niedermayer wrote:
> > On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> > > On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> > > > On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > > > > First commit addressing Trac ticket #5570. Functions defined in 
> > > > > libswscale/input.c
> > > > > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > > > > ---
> > > > >  libswscale/ppc/Makefile   |1 +
> > > > >  libswscale/ppc/input_vsx.c| 1070 
> > > > > +
> > > > >  libswscale/swscale.c  |3 +
> > > > >  libswscale/swscale_internal.h |1 +
> > > > >  4 files changed, 1075 insertions(+)
> > > > >  create mode 100644 libswscale/ppc/input_vsx.c
> > > > > 
> > > > > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > > > > index d1b596e..2482893 100644
> > > > > --- a/libswscale/ppc/Makefile
> > > > > +++ b/libswscale/ppc/Makefile
> > > > > @@ -1,3 +1,4 @@
> > > > >  OBJS += ppc/swscale_altivec.o
> > > > >\
> > > > > +ppc/input_vsx.o  
> > > > >\
> > > > >  ppc/yuv2rgb_altivec.o
> > > > >\
> > > > >  ppc/yuv2yuv_altivec.o
> > > > >\
> > > > > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > > > > new file mode 100644
> > > > > index 000..adb0e38
> > > > > --- /dev/null
> > > > > +++ b/libswscale/ppc/input_vsx.c
> > > > > @@ -0,0 +1,1070 @@
> > > > > +/*
> > > > > + * Copyright (C) 2016 Dan Parrot 
> > > > > + *
> > > > > + * This file is part of FFmpeg.
> > > > > + *
> > > > > + * FFmpeg is free software; you can redistribute it and/or
> > > > > + * modify it under the terms of the GNU Lesser General Public
> > > > > + * License as published by the Free Software Foundation; either
> > > > > + * version 2.1 of the License, or (at your option) any later version.
> > > > > + *
> > > > > + * FFmpeg is distributed in the hope that it will be useful,
> > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > > > + * Lesser General Public License for more details.
> > > > > + *
> > > > > + * You should have received a copy of the GNU Lesser General Public
> > > > > + * License along with FFmpeg; if not, write to the Free Software
> > > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > > > 02110-1301 USA
> > > > > + */
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +#include "libavutil/avutil.h"
> > > > > +#include "libavutil/bswap.h"
> > > > > +#include "libavutil/cpu.h"
> > > > > +#include "libavutil/intreadwrite.h"
> > > > > +#include "libavutil/mathematics.h"
> > > > > +#include "libavutil/pixdesc.h"
> > > > > +#include "libavutil/avassert.h"
> > > > > +#include "config.h"
> > > > > +#include "libswscale/rgb2rgb.h"
> > > > > +#include "libswscale/swscale.h"
> > > > > +#include "libswscale/swscale_internal.h"
> > > > > +
> > > > > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
> > > > > +
> > > > > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> > > > > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> > > > > +
> > > > > +#if HAVE_VSX
> > > > > +
> > > > > +// This is a SIMD version for IBM POWER8 of function 
> > > > > rgb64ToY_c_template
> > > > > +// in file libswscale/input.c
> > > > > +static av_always_inline void
> > > > > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int 
> > > > > width,
> > > > > +enum AVPixelFormat origin, int32_t *rgb2yuv)
> > > > > +{
> > > > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > > > > rgb2yuv[BY_IDX];
> > > > > +int i, j;
> > > > > +int num_vec, frag;
> > > > > +
> > > > > +num_vec = width / 8;
> > > > > +frag= width % 8;
> > > > > +
> > > > > +vector int v_ry = vec_splats((int)ry);
> > > > > +vector int v_gy = vec_splats((int)gy);
> > > > > +vector int v_by = vec_splats((int)by);
> > > > > +
> > > > > +int s_opr2;
> > > > > +s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
> > > > > +
> > > > > +vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
> > > > > +vector int v_opr2 = vec_splats((int)s_opr2);
> > > > > +
> > > > > +vector int v_r, v_g, v_b, v_tmp;
> > > > > +vector short v_tmpi, v_dst;
> > > > > +
> > > > > +for (i

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Dan Parrot

On Tue, 2016-06-21 at 02:22 +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 06:38:18PM -0500, Dan Parrot wrote:
> > On Tue, 2016-06-21 at 01:06 +0200, Michael Niedermayer wrote:
> > > On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> > > > On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> > > > > On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > > > > > First commit addressing Trac ticket #5570. Functions defined in 
> > > > > > libswscale/input.c
> > > > > > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > > > > > ---
> > > > > >  libswscale/ppc/Makefile   |1 +
> > > > > >  libswscale/ppc/input_vsx.c| 1070 
> > > > > > +
> > > > > >  libswscale/swscale.c  |3 +
> > > > > >  libswscale/swscale_internal.h |1 +
> > > > > >  4 files changed, 1075 insertions(+)
> > > > > >  create mode 100644 libswscale/ppc/input_vsx.c
> > > > > > 
> > > > > > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > > > > > index d1b596e..2482893 100644
> > > > > > --- a/libswscale/ppc/Makefile
> > > > > > +++ b/libswscale/ppc/Makefile
> > > > > > @@ -1,3 +1,4 @@
> > > > > >  OBJS += ppc/swscale_altivec.o  
> > > > > >  \
> > > > > > +ppc/input_vsx.o
> > > > > >  \
> > > > > >  ppc/yuv2rgb_altivec.o  
> > > > > >  \
> > > > > >  ppc/yuv2yuv_altivec.o  
> > > > > >  \
> > > > > > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > > > > > new file mode 100644
> > > > > > index 000..adb0e38
> > > > > > --- /dev/null
> > > > > > +++ b/libswscale/ppc/input_vsx.c
> > > > > > @@ -0,0 +1,1070 @@
> > > > > > +/*
> > > > > > + * Copyright (C) 2016 Dan Parrot 
> > > > > > + *
> > > > > > + * This file is part of FFmpeg.
> > > > > > + *
> > > > > > + * FFmpeg is free software; you can redistribute it and/or
> > > > > > + * modify it under the terms of the GNU Lesser General Public
> > > > > > + * License as published by the Free Software Foundation; either
> > > > > > + * version 2.1 of the License, or (at your option) any later 
> > > > > > version.
> > > > > > + *
> > > > > > + * FFmpeg is distributed in the hope that it will be useful,
> > > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
> > > > > > GNU
> > > > > > + * Lesser General Public License for more details.
> > > > > > + *
> > > > > > + * You should have received a copy of the GNU Lesser General Public
> > > > > > + * License along with FFmpeg; if not, write to the Free Software
> > > > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > > > > 02110-1301 USA
> > > > > > + */
> > > > > > +
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +#include "libavutil/avutil.h"
> > > > > > +#include "libavutil/bswap.h"
> > > > > > +#include "libavutil/cpu.h"
> > > > > > +#include "libavutil/intreadwrite.h"
> > > > > > +#include "libavutil/mathematics.h"
> > > > > > +#include "libavutil/pixdesc.h"
> > > > > > +#include "libavutil/avassert.h"
> > > > > > +#include "config.h"
> > > > > > +#include "libswscale/rgb2rgb.h"
> > > > > > +#include "libswscale/swscale.h"
> > > > > > +#include "libswscale/swscale_internal.h"
> > > > > > +
> > > > > > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : 
> > > > > > AV_RL16(pos))
> > > > > > +
> > > > > > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > > AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> > > > > > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > > AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> > > > > > +
> > > > > > +#if HAVE_VSX
> > > > > > +
> > > > > > +// This is a SIMD version for IBM POWER8 of function 
> > > > > > rgb64ToY_c_template
> > > > > > +// in file libswscale/input.c
> > > > > > +static av_always_inline void
> > > > > > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int 
> > > > > > width,
> > > > > > +enum AVPixelFormat origin, int32_t 
> > > > > > *rgb2yuv)
> > > > > > +{
> > > > > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > > > > > rgb2yuv[BY_IDX];
> > > > > > +int i, j;
> > > > > > +int num_vec, frag;
> > > > > > +
> > > > > > +num_vec = width / 8;
> > > > > > +frag= width % 8;
> > > > > > +
> > > > > > +vector int v_ry = vec_splats((int)ry);
> > > > > > +vector int v_gy = vec_splats((int)gy);
> > > > > > +vector int v_by = vec_splats((int)by);
> > > > > > +
> > > > > > +int s_opr2;
> > > > >

Re: [FFmpeg-devel] [PATCH 1/2] avformat/oggparsevorbis: use the base64 decode size macro

2016-06-20 Thread James Almer

On 6/16/2016 7:30 PM, James Almer wrote:
> Allocate the memory needed for the decoded data rather than the
> encoded data.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/oggparsevorbis.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Patchset pushed.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm

2016-06-20 Thread Michael Bradshaw

Hi,

Attached patch removes SegmentUID element from WebM files, as it's
unsupported in WebM[1].

Please review/apply.

Thanks,

Michael

[1]: https://www.webmproject.org/docs/container/#SegmentUID


0001-libavformat-matroskaenc-omit-segment-UID-for-webm.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix videotoolbox compile error on OS X 10.8.

2016-06-20 Thread Dan Dennedy

On Sun, Jun 19, 2016 at 9:25 PM Richard Kern  wrote:

>
> > On Jun 19, 2016, at 6:11 PM, Dan Dennedy  wrote:
> >
> > Fixes error:
> > libavcodec/videotoolbox.c:511:18: error: implicit declaration of
> > function 'CMVideoFormatDescriptionCreateFromH264ParameterSets' is
> > invalid in C99
> >
> > This was added in 10.9:
> >
> https://developer.apple.com/reference/coremedia/1489818-cmvideoformatdescriptioncreatefr?language=objc
>
> Thanks for catching this - applied.
>
> If you have access to OS X 10.8, can you test using this hwaccel?
>
>
My nightly build agent for my app is a hackintosh running 10.8, but I do
not believe it has the hardware or driver to support vda or videotoolbox to
test this on that machine. When I use ffmpeg -hwaccel with vda or
videotoolbox, it fails to initialize. I can, however, successfully use a
build made on it on another, real mac running a very recent OS X - probably
not what you are interested in. I wanted to fix the compile error instead
of disabling videotoolbox altogether in the build script.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

2016-06-20 Thread Dan Parrot

On Tue, 2016-06-21 at 02:22 +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 06:38:18PM -0500, Dan Parrot wrote:
> > On Tue, 2016-06-21 at 01:06 +0200, Michael Niedermayer wrote:
> > > On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> > > > On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> > > > > On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > > > > > First commit addressing Trac ticket #5570. Functions defined in 
> > > > > > libswscale/input.c
> > > > > > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > > > > > ---
> > > > > >  libswscale/ppc/Makefile   |1 +
> > > > > >  libswscale/ppc/input_vsx.c| 1070 
> > > > > > +
> > > > > >  libswscale/swscale.c  |3 +
> > > > > >  libswscale/swscale_internal.h |1 +
> > > > > >  4 files changed, 1075 insertions(+)
> > > > > >  create mode 100644 libswscale/ppc/input_vsx.c
> > > > > > 
> > > > > > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > > > > > index d1b596e..2482893 100644
> > > > > > --- a/libswscale/ppc/Makefile
> > > > > > +++ b/libswscale/ppc/Makefile
> > > > > > @@ -1,3 +1,4 @@
> > > > > >  OBJS += ppc/swscale_altivec.o  
> > > > > >  \
> > > > > > +ppc/input_vsx.o
> > > > > >  \
> > > > > >  ppc/yuv2rgb_altivec.o  
> > > > > >  \
> > > > > >  ppc/yuv2yuv_altivec.o  
> > > > > >  \
> > > > > > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > > > > > new file mode 100644
> > > > > > index 000..adb0e38
> > > > > > --- /dev/null
> > > > > > +++ b/libswscale/ppc/input_vsx.c
> > > > > > @@ -0,0 +1,1070 @@
> > > > > > +/*
> > > > > > + * Copyright (C) 2016 Dan Parrot 
> > > > > > + *
> > > > > > + * This file is part of FFmpeg.
> > > > > > + *
> > > > > > + * FFmpeg is free software; you can redistribute it and/or
> > > > > > + * modify it under the terms of the GNU Lesser General Public
> > > > > > + * License as published by the Free Software Foundation; either
> > > > > > + * version 2.1 of the License, or (at your option) any later 
> > > > > > version.
> > > > > > + *
> > > > > > + * FFmpeg is distributed in the hope that it will be useful,
> > > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
> > > > > > GNU
> > > > > > + * Lesser General Public License for more details.
> > > > > > + *
> > > > > > + * You should have received a copy of the GNU Lesser General Public
> > > > > > + * License along with FFmpeg; if not, write to the Free Software
> > > > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > > > > 02110-1301 USA
> > > > > > + */
> > > > > > +
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +#include "libavutil/avutil.h"
> > > > > > +#include "libavutil/bswap.h"
> > > > > > +#include "libavutil/cpu.h"
> > > > > > +#include "libavutil/intreadwrite.h"
> > > > > > +#include "libavutil/mathematics.h"
> > > > > > +#include "libavutil/pixdesc.h"
> > > > > > +#include "libavutil/avassert.h"
> > > > > > +#include "config.h"
> > > > > > +#include "libswscale/rgb2rgb.h"
> > > > > > +#include "libswscale/swscale.h"
> > > > > > +#include "libswscale/swscale_internal.h"
> > > > > > +
> > > > > > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : 
> > > > > > AV_RL16(pos))
> > > > > > +
> > > > > > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > > AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> > > > > > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin == 
> > > > > > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin == 
> > > > > > AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> > > > > > +
> > > > > > +#if HAVE_VSX
> > > > > > +
> > > > > > +// This is a SIMD version for IBM POWER8 of function 
> > > > > > rgb64ToY_c_template
> > > > > > +// in file libswscale/input.c
> > > > > > +static av_always_inline void
> > > > > > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int 
> > > > > > width,
> > > > > > +enum AVPixelFormat origin, int32_t 
> > > > > > *rgb2yuv)
> > > > > > +{
> > > > > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = 
> > > > > > rgb2yuv[BY_IDX];
> > > > > > +int i, j;
> > > > > > +int num_vec, frag;
> > > > > > +
> > > > > > +num_vec = width / 8;
> > > > > > +frag= width % 8;
> > > > > > +
> > > > > > +vector int v_ry = vec_splats((int)ry);
> > > > > > +vector int v_gy = vec_splats((int)gy);
> > > > > > +vector int v_by = vec_splats((int)by);
> > > > > > +
> > > > > > +int s_opr2;
> > > > >

Re: [FFmpeg-devel] [PATCH] Fix videotoolbox compile error on OS X 10.8.

2016-06-20 Thread Dan Dennedy

On Mon, Jun 20, 2016 at 9:45 PM Dan Dennedy  wrote:

> On Sun, Jun 19, 2016 at 9:25 PM Richard Kern  wrote:
>
>>
>> > On Jun 19, 2016, at 6:11 PM, Dan Dennedy  wrote:
>> >
>> > Fixes error:
>> > libavcodec/videotoolbox.c:511:18: error: implicit declaration of
>> > function 'CMVideoFormatDescriptionCreateFromH264ParameterSets' is
>> > invalid in C99
>> >
>> > This was added in 10.9:
>> >
>> https://developer.apple.com/reference/coremedia/1489818-cmvideoformatdescriptioncreatefr?language=objc
>>
>> Thanks for catching this - applied.
>>
>> If you have access to OS X 10.8, can you test using this hwaccel?
>>
>>
> My nightly build agent for my app is a hackintosh running 10.8, but I do
> not believe it has the hardware or driver to support vda or videotoolbox to
> test this on that machine. When I use ffmpeg -hwaccel with vda or
> videotoolbox, it fails to initialize. I can, however, successfully use a
> build made on it on another, real mac running a very recent OS X - probably
> not what you are interested in.
>

Actually, I have to retract this claim of a build made on 10.8 working on
my MacBook Pro with OS X (10.11). It works using FFmpeg v3.0.2, which the
app uses for releases. However, upon making a build using FFmpeg git
master, -hwaccel videotoolbox is not working with the same AVCHD clip:
/Applications/Shotcut.app/Contents/MacOS/ffmpeg -v verbose -hwaccel
videotoolbox -threads 1 -i ~/Movies/00108.MTS -t 30 -y test.mp4
...
[NULL @ 0x7f9659026200] Ignoring NAL type 9 in extradata
Error creating Videotoolbox decoder.
videotoolbox hwaccel requested for input stream #0:0, but cannot be
initialized.

My app is not using hwaccel at this time; so, not a big deal for me. But, I
thought you might want to know.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

47 matches

Mail list logo