Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vdpau_hevc: Remove experimental flag

[wm4]

On Mon,  3 Aug 2015 21:04:57 -0700
Philip Langdale  wrote:

> The latest nvidia 355.06 drivers fixes the interleaving bug when
> video surfaces are rendered. It still seems to be broken for
> read-back with getBits but that's sufficiently uninteresting that
> I don't think we need to wait for it to remove the flag.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavcodec/vdpau_hevc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/vdpau_hevc.c b/libavcodec/vdpau_hevc.c
> index 736d66a..4ac3249 100644
> --- a/libavcodec/vdpau_hevc.c
> +++ b/libavcodec/vdpau_hevc.c
> @@ -427,7 +427,6 @@ AVHWAccel ff_hevc_vdpau_hwaccel = {
>  .type   = AVMEDIA_TYPE_VIDEO,
>  .id = AV_CODEC_ID_HEVC,
>  .pix_fmt= AV_PIX_FMT_VDPAU,
> -.capabilities   = HWACCEL_CODEC_CAP_EXPERIMENTAL,
>  .start_frame= vdpau_hevc_start_frame,
>  .end_frame  = vdpau_hevc_end_frame,
>  .decode_slice   = vdpau_hevc_decode_slice,

Seems ok, as the buggy driver didn't get a chance to spread all that
much.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/6] aacenc: Improve Intensity Stereo phase detection

[Claudio Freire]

On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
 wrote:
> +if (cpe->ms_mode)
> +phase = 1 - 2 * cpe->ms_mask[w*16+g];


Shouldn't it be ?

phase *= 1 - ... ;

phase is an argument, the original code would step on it, with a value
that doesn't depend on phase, so it would fail to evaluate both
phases. Using phase *= would make sure to test both phases.

Well, that's the general idea, except it breaks the phase assigned to
the struct. Something like the following does work though:

ephase = phase;
if (cpe->ms_mode)
ephase *= 1 - 2 * cpe->ms_mask[w*16+g];

and then change all uses of phase into ephase, except the last that remains:

is_error.phase = phase; // original phase
is_error.pass  = dist2 <= dist1;


On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
 wrote:
>  for (w = 0; w < 128; w++)
>  if (sce1->band_type[w] >= INTENSITY_BT2)
>  sce1->band_type[w] = 0;
>
> -if (!cpe->common_window)
> -return;
> -for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
> -start = 0;
> -for (g = 0;  g < sce0->ics.num_swb; g++) {
> -if (start*freq_mult > INT_STEREO_LOW_LIMIT*(lambda/170.0f) &&
> -cpe->ch[0].band_type[w*16+g] != NOISE_BT && 
> !cpe->ch[0].zeroes[w*16+g] &&
> -cpe->ch[1].band_type[w*16+g] != NOISE_BT && 
> !cpe->ch[1].zeroes[w*16+g]) {
> -int phase = 0;
> -float ener0 = 0.0f, ener1 = 0.0f, ener01 = 0.0f;
> -float dist1 = 0.0f, dist2 = 0.0f;
> +if (!cpe->common_window)
> +return;
> +for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
> +start = 0;
> +for (g = 0;  g < sce0->ics.num_swb; g++) {
> +if (start*freq_mult > 
> INT_STEREO_LOW_LIMIT*(s->lambda/170.0f) &&

This looks strange. As it is that patch, it ends up with code like:

>for (w = 0; w < 128; w++)
>if (sce1->band_type[w] >= INTENSITY_BT2)
>sce1->band_type[w] = 0;
>
>if (!cpe->common_window)
>return;
>for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
>start = 0;
>for (g = 0;  g < sce0->ics.num_swb; g++) {

Which looks wrong. Bad indentation right?

I think you meant:

for (w = 0; w < 128; w++)
if (sce1->band_type[w] >= INTENSITY_BT2)
sce1->band_type[w] = 0;

if (!cpe->common_window)
return;
for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
start = 0;
for (g = 0;  g < sce0->ics.num_swb; g++) {

A big part of the diff in that hunk is reindent, so I believe if you
fix that indentation snafu the patch will shrink.

On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
 wrote:
>  for (w2 = 0; w2 < sce0->ics.group_len[w]; w2++) {
> +abs_pow34_v(L34, sce0->coeffs+start+(w+w2)*128, 
> sce0->ics.swb_sizes[g]);
> +abs_pow34_v(R34, sce1->coeffs+start+(w+w2)*128, 
> sce0->ics.swb_sizes[g]);
>  for (i = 0; i < sce0->ics.swb_sizes[g]; i++) {
>  float coef0 = sce0->pcoeffs[start+(w+w2)*128+i];
>  float coef1 = sce1->pcoeffs[start+(w+w2)*128+i];
> -phase += coef0*coef1 >= 0.0f ? 1 : -1;
>  ener0 += coef0*coef0;
>  ener1 += coef1*coef1;
>  ener01 += (coef0 + coef1)*(coef0 + coef1);
>  }
>  }

Careful, you're stepping on L34 and R34 on eight_short_window, and
passing the last results only to calc_encoding_err_is.

In fact, I'm thinking I may have induced you to make that mistake when
I suggested not to compute R34 / L34 twice (once for each phase),
since L34 and R34 only have room for one window, and
calc_encoding_err_is needs to process a whole window group.

I think you'll have to move it back to inside calc_encoing_err_is and
just compute it twice. Redundant, but at least it's correct.

Also, you should use pcoeffs (coeffs will have M/S applied to it when ms_mask).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Matroska and PCM variants, error in encoding?

[Peter B.]

On 08/03/2015 01:50 PM, Ronald S. Bultje wrote:
> Just different offsets and ranges. Unsigned, n bits (e.g. u8) is in the
> range [0,2^^n> (e.g. for u8, the range is [0,255] or [0,256>), where
> silence is 2^^n-1, e.g. 0x80 (128) for u8. Signed is in the range
> [-2^^n-1,2^^n-1> (e.g. s16, the most typical variant, is [-32768,32767].
> Float is in the range [-1.0, 1.0]. In both cases, 0, is silence.
>
> We have various formats so we can represent exactly what's in a file or
> output by any one particular decoder without having to convert the internal
> representation into some intermediate format.

Thanks for that detailed explanation.

I've never used DPCM with FFmpeg, but after Andreas' question I looked
it up, and found some documentation, and wanted to clear things up.

Am I correct with the following conclusion:

- acodec "pcm_*" is always linear PCM [1]
- DPCM would be prefixed with "adpcm_*" (and some exceptions, like
"interplay_dpcm", etc [2])


Thanks in advance,
Pb


== References:
[1] https://trac.ffmpeg.org/wiki/audio%20types
[2] http://ffmpeg.org/doxygen/trunk/dpcm_8c.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV Decoding - Issues and Regressions

[Ivan Uskov]

Hello Ronald,

Tuesday, August 4, 2015, 5:24:45 AM, you wrote:

RSB> Hi Ivan,

RSB> On Mon, Aug 3, 2015 at 4:50 PM, Ivan Uskov  wrote:

>> Hello Ronald,
>>
>> Monday, August 3, 2015, 11:37:22 PM, you wrote:
>>
>> RSB> On Mon, Aug 3, 2015 at 3:25 PM, Ivan Uskov 
>> wrote:
>>
>> >> By the way, about old implementation which "worked fine".
>> >> It just did drop all buffered frames at decoder re-init on new
>> >> sequence header, there is nice comment inside old qsvdec_h264.c:
>> >> /* TODO: flush delayed frames on reinit */
>>
>>
>> RSB> Each AVCodec has a flush function which should do this. So as you
>> RSB> suggested, you need a flushing state which means you will output "old"
>> RSB> frames while consuming new frames and caching them internally in some
>> way.
>> RSB> Then, when the decoder is flushed (either because flush was called, or
>> RSB> because all old cached frames have been returned), you can use all
>> queued
>> RSB> packets to reinit the hw and start outputing frames right away.
>> Thank you for suggestion but unfortunately AVCodec::flush is useless
>> for this issue. The AVCodec::flush intended to *drop* decoded frames
>> and reset decoder before seeking and it calls by module outside of decoder.
>> My task is keep all frames without losing and decoder initiates
>> "flushing" by itself. So it is different kind of "flush".


RSB> That's exactly what I said, I think you misunderstood.

RSB> Libav's decoder handles AVCodec.flush inside the size-change function.
But not qsv decoder ;-)
RSB> What I'm saying is to make it a state machine and move that code to
RSB> AVCodec.flush (if it's not there already), and otherwise (as part of your
RSB> state machine) buffer incoming patches after a size change until all
RSB> previous-sized packets have been processed.
I agree all about state machine. But still not sure that AVCodec.flush
(which is really a dummy yet) can be used during handling a frame size changing.
For the qsv decoder case the AVCodec.flush (called before seek)
should:
1. call MFXVideoDECODE_Reset() to reset decoder.
2. discard any buffered frames.
At the same time during handling a frame size changing it is
necessary:
1. defer re-init
2. deliver buffered output (no any discards) buffering input
3. when no frames at #2 destroy (not just reset) decoder, init new
instance.
For this sequence I do not see anything appropriate which can be taken
from AVCodec.flush, sorry.

RSB> Then, N new-sized frames later, you'll have N packets buffered, you can
RSB> input them into the decoder all at once and immediately start outputing
RSB> frames of the new size without additional delay except for the hw reinit.
Yes, it is exactly what will be implemented.
Thank you very much for suggestions.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] FFmpegs future and resigning as leader

[tim nicholson]

On 03/08/15 20:43, Michael Niedermayer wrote:
> On Mon, Aug 03, 2015 at 08:51:10AM +0100, tim nicholson wrote:
>> On 31/07/15 17:19, Michael Niedermayer wrote:
>>> On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
>>> [...]
 So in order for the community to continue this, I'd say we probably need
 to have some help for:

 - guidelines on the merge strategies
 - step-by-step on the release process
>>>
 - some overview on the sysadmin state (like, what happens with the recent
   server offers?)
>>>
>>> i accepted the 2 offers which noone objected against (on the ML),
>>> so FFmpeg should
>>> get 2 boxes that things can be moved to and which should be dependable
>>> it does need volunteers doing the work.
>>> Maybe lou, beastd, tim nich, roberto and you would be willing to help
>>> move things to them
>>
>> I am up for assisting where I can, but August is going to be mainly
>> holiday for me ;)
>>
>>
>>> it was discussed to move things into virtual machines (qemu) for
>>> higher security, isolation and ease of future moving.
>>
> 
>> If we go kvm etc, prebuilding a base image beforehand that can then be
>> forked for postfix/Apache/trak etc would be useful.
> 
> yes
> 
> 
>>
>> In fact there are some pre-built images already for some things, e.g
>>
> 
>> https://www.turnkeylinux.org/issue-tracking?page=1
> 
> has these been build by someone who knows about security ?
> or would it require a security audit to ensure no auth stuff /session
> keys / host keys / prng state / whatever is carried over from the
> public image ?
> 

From a quick look they seem to know what they are doing. On first run it
behaves somewhat like the end of an install process first boot, so each
instance is different with regenerated keys. When I tried 2 separate
instances from scrach I confirmed they had different host keys. I didn't
go deeper than that at the time. Obviously prng integrity is important
and would need checking.

> [...]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Failed attempts to simplify packet allocation

[Michael Niedermayer]

Ive tried to get rid of min_size by using just one of the 2 allocation
strategies unconditional, but for both variants there is significant speedloss
This patchset is for documentation and should not be applied (unless theres
some flaw in the testing which indicates that its better ...)

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

[FFmpeg-devel] [PATCH 1/3] avcodec/mpegvideo_enc: Avoid using ->internal->byte_buffer*

[Michael Niedermayer]

From: Michael Niedermayer 

This causes a speedloss from 8.837 to 8.864 sec when encoding matrixbench to 
mpeg4
similar speedloss occurs for high and low bitrate encoding
This should not be applied unless more elaborate benchmarking indicates that 
above
is the exception

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpegvideo.h |3 +++
 libavcodec/mpegvideo_enc.c |   34 +++---
 2 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 8492045..62ee505 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -162,6 +162,9 @@ typedef struct MpegEncContext {
 struct MpegEncContext *thread_context[MAX_THREADS];
 int slice_context_count;   ///< number of used thread_contexts
 
+int growable_size;
+AVPacket *growable_pkt;
+
 /**
  * copy of the previous picture structure.
  * note, linesize & data, might not match the previous picture (for field 
pictures)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 488ec51..80b1a45 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1749,6 +1749,8 @@ int ff_mpv_encode_picture(AVCodecContext *avctx, AVPacket 
*pkt,
 int i, stuffing_count, ret;
 int context_count = s->slice_context_count;
 
+s->growable_pkt = NULL;
+
 s->vbv_ignore_qmax = 0;
 
 s->picture_in_gop_number++;
@@ -1763,11 +1765,13 @@ int ff_mpv_encode_picture(AVCodecContext *avctx, 
AVPacket *pkt,
 /* output? */
 if (s->new_picture.f->data[0]) {
 int growing_buffer = context_count == 1 && !pkt->data && 
!s->data_partitioning;
-int pkt_size = growing_buffer ? 
FFMAX(s->mb_width*s->mb_height*64+1, avctx->internal->byte_buffer_size) - 
AV_INPUT_BUFFER_PADDING_SIZE
+int pkt_size = growing_buffer ? 
FFMAX(s->mb_width*s->mb_height*64+1, s->growable_size) - 
AV_INPUT_BUFFER_PADDING_SIZE
   :
   
s->mb_width*s->mb_height*(MAX_MB_BYTES+100)+1;
-if ((ret = ff_alloc_packet2(avctx, pkt, pkt_size, 0)) < 0)
+if ((ret = ff_alloc_packet2(avctx, pkt, pkt_size, pkt_size)) < 0)
 return ret;
+s->growable_pkt  = pkt;
+s->growable_size = pkt->size;
 if (s->mb_info) {
 s->mb_info_ptr = av_packet_new_side_data(pkt,
  AV_PKT_DATA_H263_MB_INFO,
@@ -1793,9 +1797,8 @@ int ff_mpv_encode_picture(AVCodecContext *avctx, AVPacket 
*pkt,
 vbv_retry:
 ret = encode_picture(s, s->picture_number);
 if (growing_buffer) {
-av_assert0(s->pb.buf == avctx->internal->byte_buffer);
-pkt->data = s->pb.buf;
-pkt->size = avctx->internal->byte_buffer_size;
+av_assert0(s->pb.buf == pkt->data);
+av_assert0(pkt->size == s->growable_size);
 }
 if (ret < 0)
 return -1;
@@ -2773,25 +2776,18 @@ int ff_mpv_reallocate_putbitbuffer(MpegEncContext *s, 
size_t threshold, size_t s
 {
 if (   s->pb.buf_end - s->pb.buf - (put_bits_count(&s->pb)>>3) < threshold
 && s->slice_context_count == 1
-&& s->pb.buf == s->avctx->internal->byte_buffer) {
+&& s->pb.buf == s->growable_pkt->data) {
 int lastgob_pos = s->ptr_lastgob - s->pb.buf;
 int vbv_pos = s->vbv_delay_ptr - s->pb.buf;
 
-uint8_t *new_buffer = NULL;
-int new_buffer_size = 0;
-
-av_fast_padded_malloc(&new_buffer, &new_buffer_size,
-  s->avctx->internal->byte_buffer_size + 
size_increase);
-if (!new_buffer)
-return AVERROR(ENOMEM);
+int ret = av_grow_packet(s->growable_pkt, size_increase);
+if (ret < 0)
+return ret;
 
-memcpy(new_buffer, s->avctx->internal->byte_buffer, 
s->avctx->internal->byte_buffer_size);
-av_free(s->avctx->internal->byte_buffer);
-s->avctx->internal->byte_buffer  = new_buffer;
-s->avctx->internal->byte_buffer_size = new_buffer_size;
-rebase_put_bits(&s->pb, new_buffer, new_buffer_size);
+rebase_put_bits(&s->pb, s->growable_pkt->data, s->growable_pkt->size);
 s->ptr_lastgob   = s->pb.buf + lastgob_pos;
 s->vbv_delay_ptr = s->pb.buf + vbv_pos;
+s->growable_size = s->growable_pkt->size;
 }
 if (s->pb.buf_end - s->pb.buf - (put_bits_count(&s->pb)>>3) < threshold)
 return AVERROR(EINVAL);
@@ -2874,7 +2870,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
 //int d;
 int dmin= INT_MAX;
 int dir;
-int size_increase =  s->avctx->internal->byte_buffer_size/4
+int size_increase =  s->growable_pkt->size/4
+ s->mb_width*MAX_MB_BYTES;
 
 ff_mpv_reallocate_putbitbuffer(s, MAX_MB_BYTES, size_increase);
-- 
1.7.9.5

___

[FFmpeg-devel] [PATCH 3/3] avcodec/utils: Favor using the internal->byte_buffer in ff_alloc_packet2()

[Michael Niedermayer]

From: Michael Niedermayer 

This would allow dropping min_size

This causes matrixbench encoding to rawvideo to drop in speed from
4.204 to 4.210sec
The effect has been previously seen to be much larger at higher
resolutions

Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 8f3bffd..c98a840 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1789,7 +1789,7 @@ int ff_alloc_packet2(AVCodecContext *avctx, AVPacket 
*avpkt, int64_t size, int64
 return AVERROR(EINVAL);
 }
 
-if (avctx && avpkt->data && avpkt->size < size) {
+if (avctx) {
 av_assert0(!avpkt->data || avpkt->data != 
avctx->internal->byte_buffer);
 if (!avpkt->data || avpkt->size < size) {
 av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/3] avcodec/utils: Favor allocating a new packet in ff_alloc_packet2()

[Michael Niedermayer]

From: Michael Niedermayer 

This removes min_size usage by always using the same allocation
strategy (simply allocating new packet)

This causes huffyuv encoding of matrixbench to drop in speed from
16.321 to 16.708sec

Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5dbd0cf..8f3bffd 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1789,7 +1789,7 @@ int ff_alloc_packet2(AVCodecContext *avctx, AVPacket 
*avpkt, int64_t size, int64
 return AVERROR(EINVAL);
 }
 
-if (avctx && 2*min_size < size) { // FIXME The factor needs to be finetuned
+if (avctx && avpkt->data && avpkt->size < size) {
 av_assert0(!avpkt->data || avpkt->data != 
avctx->internal->byte_buffer);
 if (!avpkt->data || avpkt->size < size) {
 av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
-- 
1.7.9.5

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

Re: [FFmpeg-devel] How to get width/height of an H264 stream using its SPS ?

[PROMONET Michel]

Hi,

But  h264.h not seems to be a public include.
Thanks, I will looking in this direction.

Best Regards,

Michel.

[@@ THALES GROUP INTERNAL @@]


-Message d'origine-
De : ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] De la part de Ronald 
S. Bultje
Envoyé : jeudi 30 juillet 2015 18:50
À : FFmpeg development discussions and patches
Objet : Re: [FFmpeg-devel] How to get width/height of an H264 stream using its 
SPS ?

Hi,

On Thu, Jul 30, 2015 at 10:58 AM, PROMONET Michel < 
michel.promo...@thalesgroup.com> wrote:

> Hi Ronald,
>
> Thanks for the quick answer, following the code this was also my guess.
>
> From my side I feel that it could be nice to use ffmpeg to decode SPS 
> without any stream, I would like to avoid an other processing of the SPS.
>
> Is there a particular reason for hiding width/height before decoding ? 
> and could it be a potential evolution of ffmpeg ?


I think you're looking at this from the wrong angle. If you want to get the w/h 
from a sps, just write a function that does so. You could even re-use functions 
from h264_ps.c or reuse the binary exported abi (using h264.h as api).

But expecting any sort of relationship between AVCodecContext and sps is not 
realistic.

Ronald
___
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] [PATCH 3/3] avcodec/utils: Favor using the internal->byte_buffer in ff_alloc_packet2()

[Paul B Mahol]

Dana 4. 8. 2015. 10:48 osoba "Michael Niedermayer" 
napisala je:
>
> From: Michael Niedermayer 
>
> This would allow dropping min_size
>
> This causes matrixbench encoding to rawvideo to drop in speed from
> 4.204 to 4.210sec
> The effect has been previously seen to be much larger at higher
> resolutions

Why then posting this patch at all?
It makes things slow.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 8f3bffd..c98a840 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1789,7 +1789,7 @@ int ff_alloc_packet2(AVCodecContext *avctx,
AVPacket *avpkt, int64_t size, int64
>  return AVERROR(EINVAL);
>  }
>
> -if (avctx && avpkt->data && avpkt->size < size) {
> +if (avctx) {
>  av_assert0(!avpkt->data || avpkt->data !=
avctx->internal->byte_buffer);
>  if (!avpkt->data || avpkt->size < size) {
>  av_fast_padded_malloc(&avctx->internal->byte_buffer,
&avctx->internal->byte_buffer_size, size);
> --
> 1.7.9.5
>
> ___
> 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] [PATCH 2/3] avcodec/utils: Favor allocating a new packet in ff_alloc_packet2()

[Paul B Mahol]

Dana 4. 8. 2015. 10:48 osoba "Michael Niedermayer" 
napisala je:
>
> From: Michael Niedermayer 
>
> This removes min_size usage by always using the same allocation
> strategy (simply allocating new packet)
>
> This causes huffyuv encoding of matrixbench to drop in speed from
> 16.321 to 16.708sec

Again I see no point in this, there is other stuf to do

>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 5dbd0cf..8f3bffd 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1789,7 +1789,7 @@ int ff_alloc_packet2(AVCodecContext *avctx,
AVPacket *avpkt, int64_t size, int64
>  return AVERROR(EINVAL);
>  }
>
> -if (avctx && 2*min_size < size) { // FIXME The factor needs to be
finetuned
> +if (avctx && avpkt->data && avpkt->size < size) {
>  av_assert0(!avpkt->data || avpkt->data !=
avctx->internal->byte_buffer);
>  if (!avpkt->data || avpkt->size < size) {
>  av_fast_padded_malloc(&avctx->internal->byte_buffer,
&avctx->internal->byte_buffer_size, size);
> --
> 1.7.9.5
>
> ___
> 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] [PATCH] configure: Silence error messages when probing compiler.

[Michael Niedermayer]

On Mon, Aug 03, 2015 at 10:25:47AM +, Carl Eugen Hoyos wrote:
> Shiz  shiz.me> writes:
> 
> > On Xcode's clang on OS X, $cc --version will output a 'Configured with:'
> > line to stderr, which clobbers the configure script output. As this line
> > serves no further purpose, it should be silenced.
> 
> I cannot test atm, but the patch looks like a 
> very good idea to me.

applied

thanks

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 3/3] MAINTAINERS: Add myself to vdpau maintainers

[Michael Niedermayer]

On Mon, Aug 03, 2015 at 09:04:59PM -0700, Philip Langdale wrote:
> Signed-off-by: Philip Langdale 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index da02165..b0d0dc7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -304,7 +304,7 @@ Hardware acceleration:
>libstagefright.cppMohamed Naufal
>vaapi*Gwenole Beauchesne
>vda*  Sebastien Zwickert
> -  vdpau*Carl Eugen Hoyos
> +  vdpau*Philip Langdale, Carl Eugen Hoyos
>videotoolbox* Sebastien Zwickert

no objections from me
carl ?

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features

[wm4]

On Tue, 4 Aug 2015 07:57:34 +0200
Reimar Döffinger  wrote:

> On 31.07.2015, at 17:47, Nicolas George  wrote:
> > I can propose the following middle term:
> 
> I do have on more proposal, but the problem is it needs someone to do the 
> work.
> For each removed feature, prepare documentation "a monkey could follow" on 
> how to replace it (you could call it a transition guide).

Yes, that's a good idea. We should probably require something like this
from every patch that deprecates API for other APIs.

There should probably be a migration guide in doc or so. Libav also
tried something like it: https://wiki.libav.org/Migration/11

> Even better, a script that automates it where reasonable.

Would probably work for simple renames, like the AV_ prefix additions.

> In some cases it is just a matter of copy-pasting some existing wrapper code, 
> particularly if we remove that wrapper code it is useful if people still have 
> it available in the new release.

Well, often the problem is that such deprecated features are terribly
entangled with the rest of the code. Consider AVPacket.destruct.

> If it's just a few hours of someone's time who even doesn't need to 
> understand the code, I think we can very confidently say "not really our 
> problem" if some applications still use it.
> If we that way find out that there are non-trivial cases or cases where the 
> code gets a lot more complicated it might be a hint the new API is still crap 
> and we maybe should come up with something better first.
> Btw. the magic option to enable compatibility is still somewhat useful as it 
> lists and allows testing the specific changes that are coming up. But I agree 
> it's only a minor help.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 2:45 AM, Shivraj Patil 
wrote:

>
>
> Hi,
>
>
>
> On Mon, Jul 27, 2015 at 6:01 AM,  wrote:
>
> +++ b/libavcodec/mips/vp8dsp_init_mips.c
>
>
>
> Is there a reason the init code lives in a different file than the
> implementations? It seems to me all symbols could be static if the init
> code lived in the same file as the implementation. This isn't a big deal,
> just wondering.
>
>
>
> Shivraj:- Yes, the files can be merged, we just followed the tradition as
> done by other platforms.
>

Well, so, I have to explain this for it to make sense. On most platforms,
like x86 and arm, we use raw assembly (in .asm files), where the init code
(for function pointer assignment) is C, so they can't logically live in
same files. On platforms where we use C-ish languages for platform-specific
optimizations (e.g. intrinsics for altivec, or gcc-style inline assembly
for x86), I believe the preference would be to use static functions and
merge init/code in the same file.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 2:49 AM,  wrote:

> From: Shivraj Patil 
>
> Signed-off-by: Shivraj Patil 
> ---
>  libavcodec/mips/Makefile   |4 +
>  libavcodec/mips/vp8_idct_msa.c |  160 +++
>  libavcodec/mips/vp8_lpf_msa.c  |  690 +++
>  libavcodec/mips/vp8_mc_msa.c   | 2332
> 
>  libavcodec/mips/vp8dsp_init_mips.c |  113 ++
>  libavcodec/mips/vp8dsp_mips.h  |  172 +++
>  libavcodec/vp8dsp.c|2 +
>  libavcodec/vp8dsp.h|1 +
>  8 files changed, 3474 insertions(+)
>  create mode 100644 libavcodec/mips/vp8_idct_msa.c
>  create mode 100644 libavcodec/mips/vp8_lpf_msa.c
>  create mode 100644 libavcodec/mips/vp8_mc_msa.c
>  create mode 100644 libavcodec/mips/vp8dsp_init_mips.c
>  create mode 100644 libavcodec/mips/vp8dsp_mips.h
>

lgtm.

(I'll try to apply this one later today myself, have to get a push tree
running.)

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

Re: [FFmpeg-devel] How to get width/height of an H264 stream using its SPS ?

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 4:49 AM, PROMONET Michel <
michel.promo...@thalesgroup.com> wrote:

> Hi,
>
> But  h264.h not seems to be a public include.
> Thanks, I will looking in this direction.


It isn't, we never expose much of codec internals. But I'm pretty sure
you'll need codec internals for this kind of stuff, so I'd just compile
against a local/static version of ffmpeg and go this route. The public API
won't get you far for such highly codec-specific stuff...

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

Re: [FFmpeg-devel] How to get width/height of an H264 stream using its SPS ?

[Hendrik Leppkes]

On Tue, Aug 4, 2015 at 12:36 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, Aug 4, 2015 at 4:49 AM, PROMONET Michel <
> michel.promo...@thalesgroup.com> wrote:
>
>> Hi,
>>
>> But  h264.h not seems to be a public include.
>> Thanks, I will looking in this direction.
>
>
> It isn't, we never expose much of codec internals. But I'm pretty sure
> you'll need codec internals for this kind of stuff, so I'd just compile
> against a local/static version of ffmpeg and go this route. The public API
> won't get you far for such highly codec-specific stuff...
>

Parsing the SPS up to the point to get the width/height isn't that
hard, grab the H264 specs from the web and implement it - its pretty
trivial.
Or reference the avcodec h264 code to see how its parsed.

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

[FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: correct handling of dynamic frame size changing has been implemented

[Ivan Uskov]

Hello All,

This patch for libavcodec/qsvdec.c does implement a correct handling
of a case when frame dimensions were changed somewhere in middle of stream.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-correct-handling-of-dynamic-fram.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] MAINTAINERS: Add myself to vdpau maintainers

[Carl Eugen Hoyos]

Philip Langdale  overt.org> writes:

> -  vdpau*Carl Eugen Hoyos
> +  vdpau*Philip Langdale, Carl Eugen Hoyos

This is of course ok, as are the other two patches.

Did you test the sample sample as Hendrik?

Carl Eugen

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

[FFmpeg-devel] Stems file format

[Alex Beregszaszi]

"Hi,

Have you seen the announcement for Stems? (
http://www.stems-music.com/index.html )

"As an open multi-track audio format, Stems enhances creative
possibilities for DJs, producers, and live performers. A Stem file
contains a track split into four musical elements: A drums stem, a
bassline stem, a melody stem, and a vocal stem for example."

On the developer section (
http://www.stems-music.com/stems-is-for-developers/index.html ) there
is a bit more information:

"Stem files use the .mp4 container format to store the four individual
stems of a track within a single file. Using the file extension
.stem.mp4, this single file can be managed just like an mp3 file. A
standard master version of the track is also included in the file and
can even be played in stereo with any compatible audio player
following standard mp4 specs, like iTunes for example. To play with a
track’s individual stems, Stem-compatible software or hardware is
required."

Seems like a good move they didn't create a brand new container. Yet
to see some files out in the wild. According to this article (
http://thenextweb.com/insider/2015/08/03/stems-a-new-open-file-format-for-djs-makes-mixing-easier-than-ever/
) they are already sold on Beatport & Traxsource.

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

Re: [FFmpeg-devel] [PATCH 1/6] lavf/mxfdec: support segmented frame layout as separate fields layout

[Michael Niedermayer]

On Wed, Jul 22, 2015 at 03:29:42PM +0200, Matthieu Bouron wrote:
> According to S377M, segmented frame layout is identical to separate
> field layout except that the two fields are taken from a single scan
> of the incoming image, ie: they are coincident in time. Thus the
> resulting frame is progressive.
> ---
>  libavformat/mxfdec.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

applied

thanks

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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/6] lavf/mxfdec: support segmented frame layout as separate fields layout

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 01:12:19PM +0200, Michael Niedermayer wrote:
> On Wed, Jul 22, 2015 at 03:29:42PM +0200, Matthieu Bouron wrote:
> > According to S377M, segmented frame layout is identical to separate
> > field layout except that the two fields are taken from a single scan
> > of the incoming image, ie: they are coincident in time. Thus the
> > resulting frame is progressive.
> > ---
> >  libavformat/mxfdec.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> applied

btw, almost forgot
send me your public ssh key (for git push access)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: avoid scanf in keyboard command parsing

[Michael Niedermayer]

On Mon, Aug 03, 2015 at 10:02:17PM +0200, Hendrik Leppkes wrote:
> Mixing stdio and low-level IO on stdin is not safe.
> ---
>  ffmpeg.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

LGTM too

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH] ffplay: do not block audio thread on WIN32

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 01:00:52AM +0200, Marton Balint wrote:
> The windows SDL audio driver plays the old data in the buffer in a loop if it
> is not updated in time. So instead of waiting for data and blocking the the
> audio thread, return silence if no data is available.
> 
> Should fix ticket #2289.

ive no means to test but if it works then should be ok

also send me your public SSH key for git push access

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

[FFmpeg-devel] [PATCH 2/2] avcodec/mips: h264qpel init add missing mc00 msa optimization

[周晓勇]

From 734eabc92df1b6ca26a943f9723e47a838d859f7 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Tue, 4 Aug 2015 19:39:51 +0800
Subject: [PATCH 2/2] avcodec/mips: h264qpel init add missing mc00 msa
 optimization


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/h264qpel_init_mips.c | 1 +
 1 file changed, 1 insertion(+)


diff --git a/libavcodec/mips/h264qpel_init_mips.c 
b/libavcodec/mips/h264qpel_init_mips.c
index cfa5854..72797f1 100644
--- a/libavcodec/mips/h264qpel_init_mips.c
+++ b/libavcodec/mips/h264qpel_init_mips.c
@@ -59,6 +59,7 @@ static av_cold void h264qpel_init_msa(H264QpelContext *c, int 
bit_depth)
 c->put_h264_qpel_pixels_tab[1][14] = ff_put_h264_qpel8_mc23_msa;
 c->put_h264_qpel_pixels_tab[1][15] = ff_put_h264_qpel8_mc33_msa;
 
+c->put_h264_qpel_pixels_tab[2][0] = ff_put_h264_qpel4_mc00_msa;
 c->put_h264_qpel_pixels_tab[2][1] = ff_put_h264_qpel4_mc10_msa;
 c->put_h264_qpel_pixels_tab[2][2] = ff_put_h264_qpel4_mc20_msa;
 c->put_h264_qpel_pixels_tab[2][3] = ff_put_h264_qpel4_mc30_msa;
-- 
2.1.0

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

[FFmpeg-devel] [PATCH 1/2] avcodec: loongson optimized h264pred with mmi v2

[周晓勇]

From 71478e642fac00b12b313723ee83acdfef732fd1 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Tue, 4 Aug 2015 16:28:02 +0800
Subject: [PATCH 1/2] avcodec: loongson optimized h264pred with mmi v2


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/h264pred_init_mips.c |   1 -
 libavcodec/mips/h264pred_mips.h  |   7 +-
 libavcodec/mips/h264pred_mmi.c   | 459 +--
 3 files changed, 226 insertions(+), 241 deletions(-)


diff --git a/libavcodec/mips/h264pred_init_mips.c 
b/libavcodec/mips/h264pred_init_mips.c
index a2124ec..93a2409 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -114,7 +114,6 @@ static av_cold void h264_pred_init_mmi(H264PredContext *h, 
int codec_id,
 h->pred16x16[HOR_PRED8x8] = ff_pred16x16_horizontal_8_mmi;
 h->pred8x8l [TOP_DC_PRED] = ff_pred8x8l_top_dc_8_mmi;
 h->pred8x8l [DC_PRED] = ff_pred8x8l_dc_8_mmi;
-h->pred8x8l [HOR_PRED   ] = ff_pred8x8l_horizontal_8_mmi;
 
 switch (codec_id) {
 case AV_CODEC_ID_SVQ3:
diff --git a/libavcodec/mips/h264pred_mips.h b/libavcodec/mips/h264pred_mips.h
index 16bf6fc..d7d12c5 100644
--- a/libavcodec/mips/h264pred_mips.h
+++ b/libavcodec/mips/h264pred_mips.h
@@ -21,11 +21,8 @@
 #ifndef H264_PRED_MIPS_H
 #define H264_PRED_MIPS_H
 
-#include "libavutil/attributes.h"
-#include "libavutil/avassert.h"
-#include "libavcodec/avcodec.h"
+#include "constants.h"
 #include "libavcodec/h264pred.h"
-#include "libavcodec/bit_depth_template.c"
 
 void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t stride);
 void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t stride);
@@ -34,8 +31,6 @@ void ff_pred8x8l_top_dc_8_mmi(uint8_t *src, int has_topleft, 
int has_topright,
 ptrdiff_t stride);
 void ff_pred8x8l_dc_8_mmi(uint8_t *src, int has_topleft, int has_topright,
 ptrdiff_t stride);
-void ff_pred8x8l_horizontal_8_mmi(uint8_t *src, int has_topleft,
-int has_topright, ptrdiff_t stride);
 void ff_pred8x8l_vertical_8_mmi(uint8_t *src, int has_topleft,
 int has_topright, ptrdiff_t stride);
 void ff_pred4x4_dc_8_mmi(uint8_t *src, const uint8_t *topright,
diff --git a/libavcodec/mips/h264pred_mmi.c b/libavcodec/mips/h264pred_mmi.c
index c5ae796..e949d11 100644
--- a/libavcodec/mips/h264pred_mmi.c
+++ b/libavcodec/mips/h264pred_mmi.c
@@ -23,68 +23,66 @@
  */
 
 #include "h264pred_mips.h"
-#include "constants.h"
 
 void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t stride)
 {
 __asm__ volatile (
-"dsubu $2, %0, %1   \r\n"
-"daddu $3, %0, $0   \r\n"
-"ldl $4, 7($2)  \r\n"
-"ldr $4, 0($2)  \r\n"
-"ldl $5, 15($2) \r\n"
-"ldr $5, 8($2)  \r\n"
-"dli $6, 0x10   \r\n"
+"dli $8, 16 \r\n"
+"gsldlc1 $f2, 7(%[srcA])\r\n"
+"gsldrc1 $f2, 0(%[srcA])\r\n"
+"gsldlc1 $f4, 15(%[srcA])   \r\n"
+"gsldrc1 $f4, 8(%[srcA])\r\n"
 "1: \r\n"
-"sdl $4, 7($3)  \r\n"
-"sdr $4, 0($3)  \r\n"
-"sdl $5, 15($3) \r\n"
-"sdr $5, 8($3)  \r\n"
-"daddu $3, %1   \r\n"
-"daddiu $6, -1  \r\n"
-"bnez $6, 1b\r\n"
-::"r"(src),"r"(stride)
-: "$2","$3","$4","$5","$6","memory"
+"gssdlc1 $f2, 7(%[src]) \r\n"
+"gssdrc1 $f2, 0(%[src]) \r\n"
+"gssdlc1 $f4, 15(%[src])\r\n"
+"gssdrc1 $f4, 8(%[src]) \r\n"
+"daddu %[src], %[src], %[stride]\r\n"
+"daddi $8, $8, -1   \r\n"
+"bnez $8, 1b\r\n"
+: [src]"+&r"(src)
+: [stride]"r"(stride),[srcA]"r"(src-stride)
+: "$8","$f2","$f4"
 );
 }
 
 void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t stride)
 {
 __asm__ volatile (
-"daddiu $2, %0, -1  \r\n"
-"daddu $3, %0, $0   \r\n"
+"daddiu $2, %[src], -1  \r\n"
+"daddu $3, %[src], $0   \r\n"
 "dli $6, 0x10   \r\n"
 "1: \r\n"
 "lbu $4, 0($2)  \r\n"
-"dmul $5, $4, %2\r\n"
+"dmul $5, $4, %[ff_pb_1]\r\n"
 "sdl $5, 7($3)  \r\n"
 "sdr $5, 0($3)  \r\n"
 "sdl $5, 15($3) \r\n"
 "sdr $5, 8($3)  \r\n"
-"daddu $2, %1   \r\n"
-"dadd

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions

[Shivraj Patil]

Hi,
+++ b/libavcodec/mips/vp8dsp_init_mips.c

Is there a reason the init code lives in a different file than the 
implementations? It seems to me all symbols could be static if the init code 
lived in the same file as the implementation. This isn't a big deal, just 
wondering.

Shivraj:- Yes, the files can be merged, we just followed the tradition as done 
by other platforms.

Well, so, I have to explain this for it to make sense. On most platforms, like 
x86 and arm, we use raw assembly (in .asm files), where the init code (for 
function pointer assignment) is C, so they can't logically live in same files. 
On platforms where we use C-ish languages for platform-specific optimizations 
(e.g. intrinsics for altivec, or gcc-style inline assembly for x86), I believe 
the preference would be to use static functions and merge init/code in the same 
file.

Shivraj:- "*_init_mips.c" file will contain pointer initialization of all mips 
extensions, right now only one extension present that is MIPS SIMD Arch(MSA). 
"*_msa.c" file contain optimized code for MSA extension.
In future for other mips extension (like dsp-ase r2 etc), pointer 
initialization will still happen in file "*_init_mips.c" but sources will be in 
different file "*_dspaser2.c"

Thanks,
Shivraj

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

Re: [FFmpeg-devel] [PATCH] avcodec/internal: improve min_size documentation for ff_alloc_packet2()

[wm4]

On Tue, 4 Aug 2015 01:46:24 +0200
Michael Niedermayer  wrote:

> On Tue, Aug 04, 2015 at 12:57:38AM +0200, wm4 wrote:
> > On Tue, 4 Aug 2015 00:51:17 +0200
> > Michael Niedermayer  wrote:
> > 
> > > On Tue, Aug 04, 2015 at 12:12:24AM +0200, wm4 wrote:
> > 
> > > > > As well as benchmark results in some commits like
> > > > > 4302a92835313000d4bf8030baae32c2b130d8a1
> > > > 
> > > > avcodec/pcm: Better min_size for ff_alloc_packet2()
> > > > 
> > > > 33318 -> 30601 decicycles
> > > > 
> > > > That doesn't look convincing at all. So you save ~3000 decicycles for
> > > > a task that isn't CPU bound, but which might blocks entire milliseconds
> > > > on I/O.
> > > 
> > > There was a bug report of a overall (aka time ffmpeg) speedloss
> > > in the % values with high res rawvideo
> > 
> > Was it fixed?
> 
> for rawideo and for several others too yes

I see no proof though. The numbers you posted so far are not really
convincing. They're micro-benchmarks too, and might not even matter in
real world work loads.

> iam pretty sure there are other encoders that suffer from speedloss
> due to this too though

What is "this"?

> 
> > 
> > > > > i do intend to fine tune this for more codecs but i spend more time
> > > > > in such disussions than working on the code and having people tell me
> > > > > to do it differently each time i take a step kind of slows it down
> > > > > and turns it into a mess
> > > > 
> > > > We also must take care of not turning the codebase into a mess.
> > > 
> > > I want to fix the mess
> > 
> > I don't mind, but...
> > 
> > > and i would suggest that we first test if any / which encoders benefit
> > > from the static buffer.
> > > It where quite a few long ago but it seems from a few quick tests that
> > > this is not so anymore.
> > > Can someone confirm ?
> > > if it has become useless then I could drop quite a bit of code
> > 
> > Do you have to do your experiments on the live codebase? If you just
> > want to try something, you could do that in a branch. If it gives good
> > results, merge, if not, it's a failed experiment.
> 
> noone did "experiments on the live codebase"

Then what's that "FIXME" in the heuristic, and the new API parameter
that by now uses only 2 possible values, which make this "heuristic"
completely pointless? What bugs me is that you insist on this (IMHO)
bogus min_size parameter, and all complaints are supposed to be
silenced with the holy "speedloss" justification. Except that so far it
seems to be rather minor, and I bet shows up only in non-realistic
benchmarks. But it serves as justification anyway, because if it's just
a slightly bit faster, it wins, no discussion.

Now I don't claim I can do better (actually I do, so feel free to call
me an idiot), but here are my own (untested) conclusions.

From what I see there are 2 cases:
- Fixed allocations, usually the case with raw encoders. Currently,
  the packet is always a full malloc (probably ends up as a mmap
  syscall if the size is big), but an additional copy of the packet at
  a later point is avoided when ref-ing or dup-ing the packet.
- Variable allocations, where the encoder has a (usually rather high)
  worst case estimation and wants a buffer of this size. Later the
  buffer is trimmed to avoid wasting memory. Currently, this is done
  by encoding to a "static" buffer, and then copying it to a new
  correctly sized buffer when the packet is referenced or dup-ed.

I suppose the min_size parameter is supposed to select between these
cases dynamically and use the "best" method. I suggest doing the
following instead:

- have a buffer pool in the codec context
- if a packet is allocated with a size larger then the current pool
  size, realloc the buffer pool to that larger size
- likewise, if the requested packet is much smaller than the current
  pool size, you could either resize the pool, or just allocate the
  packet normally (apply clever heuristic 1 here)
- the encoder gets a refcounted packet from the buffer pool
- after encoding, check how much memory is "wasted"
- if too much is wasted (apply clever heuristic 2 here), create a new
  copy (this could even use another buffer pool which might help if the
  encoded packet sizes are usually similar, but maybe it's not worth
  the trouble)

This actually has some potential to be faster (like when the encoder
does fixed allocations, e.g. raw video or audio, no large allocations
are done after a while), and is simpler at least from the encoders
point of view. There can be a single ff_alloc_packet function which
takes a size only.

(But I'd just avoid the need for too many heuristics, and have a
separate function for raw encoders. It would allocate from a buffer
pool.)

Also, why is this all not applied to demuxing? In fact, even when
encoding, a lot of data is copied in avpacket.c, and these were packets
from the demuxer. Doesn't matter?

> also i strongly suggest that this discussion ends now and that we
> return to do usefull work.

I don't

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mips: h264qpel init add missing mc00 msa optimization

[Shivraj Patil]

Hi,
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of ???
Sent: 04 August 2015 17:35
To: ffmpeg-devel
Subject: [FFmpeg-devel] [PATCH 2/2] avcodec/mips: h264qpel init add missing 
mc00 msa optimization

From 734eabc92df1b6ca26a943f9723e47a838d859f7 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong 
Date: Tue, 4 Aug 2015 19:39:51 +0800
Subject: [PATCH 2/2] avcodec/mips: h264qpel init add missing mc00 msa  
optimization


Signed-off-by: ZhouXiaoyong 
---
 libavcodec/mips/h264qpel_init_mips.c | 1 +
 1 file changed, 1 insertion(+)


diff --git a/libavcodec/mips/h264qpel_init_mips.c 
b/libavcodec/mips/h264qpel_init_mips.c
index cfa5854..72797f1 100644
--- a/libavcodec/mips/h264qpel_init_mips.c
+++ b/libavcodec/mips/h264qpel_init_mips.c
@@ -59,6 +59,7 @@ static av_cold void h264qpel_init_msa(H264QpelContext *c, int 
bit_depth)
 c->put_h264_qpel_pixels_tab[1][14] = ff_put_h264_qpel8_mc23_msa;
 c->put_h264_qpel_pixels_tab[1][15] = ff_put_h264_qpel8_mc33_msa;
 
+c->put_h264_qpel_pixels_tab[2][0] = ff_put_h264_qpel4_mc00_msa;
 c->put_h264_qpel_pixels_tab[2][1] = ff_put_h264_qpel4_mc10_msa;
 c->put_h264_qpel_pixels_tab[2][2] = ff_put_h264_qpel4_mc20_msa;
 c->put_h264_qpel_pixels_tab[2][3] = ff_put_h264_qpel4_mc30_msa;
--
2.1.0


Shivraj:- "c->put_h264_qpel_pixels_tab[2][0] = ff_put_h264_qpel4_mc00_msa" 
initialization is not missing. "ff_put_h264_qpel4_mc00_msa" is not implemented 
as it does not give any optimization than C counterpart.

___
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] [PATCH] avcodec/dvbsubdec: Allow selecting the substream, or all substreams

[Michael Niedermayer]

On Mon, Jul 27, 2015 at 04:48:15PM +0200, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c |   19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)

applied

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

[FFmpeg-devel] [PATCH]lavc/dvbsub: Do not fail on clut depth 0

[Carl Eugen Hoyos]

Hi!

Attached patch fixes the regression reported in ticket #4752, the subtitles 
look very bad before and after but I guess this should be a different ticket.

Please comment, Carl Eugen
diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index ce03e12..23f24f1 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -1168,7 +1168,7 @@ static int dvbsub_parse_clut_segment(AVCodecContext 
*avctx,
 
 if (depth == 0) {
 av_log(avctx, AV_LOG_ERROR, "Invalid clut depth 0x%x!\n", *buf);
-return AVERROR_INVALIDDATA;
+return 0;
 }
 
 full_range = (*buf++) & 1;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Do not fail on clut depth 0

[Hendrik Leppkes]

On Tue, Aug 4, 2015 at 1:31 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes the regression reported in ticket #4752, the subtitles
> look very bad before and after but I guess this should be a different ticket.
>

Makes sense, I guess, it specifically didn't return an error code
before, and the functional change may not have been intended.

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

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Do not fail on clut depth 0

[wm4]

On Tue, 4 Aug 2015 13:31:10 +0200
Carl Eugen Hoyos  wrote:

> Hi!
> 
> Attached patch fixes the regression reported in ticket #4752, the subtitles 
> look very bad before and after but I guess this should be a different ticket.
> 
> Please comment, Carl Eugen

Seems like a case for AV_EF_EXPLODE.

Also, why can't you send proper git patches?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.

[wm4]

On Mon, 3 Aug 2015 17:50:54 -0700
Sasi Inguva  wrote:

> Ok. i'll drop this patch . Does outputting stream DURATION values in
> matroskaenc.c  as string tag's , (same as mkvmerge does ) seem ok?  Atleast
> then, I can parse those string metadata in our own video pipeline  which
> will solve my use case.

Personally I wouldn't mind, as long as the output is exactly the same
as mkvmerge's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/swf: Fix detection of compressed files

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a regression since b7e506b3.

Please comment, Carl Eugen
diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
index 31c26f8..ce1ad8f 100644
--- a/libavformat/swfdec.c
+++ b/libavformat/swfdec.c
@@ -67,6 +67,10 @@ static int swf_probe(AVProbeData *p)
 && AV_RB24(p->buf) != AV_RB24("FWS"))
 return 0;
 
+if (   AV_RB24(p->buf) == AV_RB24("CWS")
+&& p->buf[3] <= 20)
+return AVPROBE_SCORE_MAX / 4 + 1;
+
 init_get_bits8(&gb, p->buf + 3, p->buf_size - 3);
 
 skip_bits(&gb, 40);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/internal: improve min_size documentation for ff_alloc_packet2()

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 02:06:03PM +0200, wm4 wrote:
> On Tue, 4 Aug 2015 01:46:24 +0200
> Michael Niedermayer  wrote:
> 
> > On Tue, Aug 04, 2015 at 12:57:38AM +0200, wm4 wrote:
> > > On Tue, 4 Aug 2015 00:51:17 +0200
> > > Michael Niedermayer  wrote:
> > > 
> > > > On Tue, Aug 04, 2015 at 12:12:24AM +0200, wm4 wrote:
> > > 
> > > > > > As well as benchmark results in some commits like
> > > > > > 4302a92835313000d4bf8030baae32c2b130d8a1
> > > > > 
> > > > > avcodec/pcm: Better min_size for ff_alloc_packet2()
> > > > > 
> > > > > 33318 -> 30601 decicycles
> > > > > 
> > > > > That doesn't look convincing at all. So you save ~3000 decicycles for
> > > > > a task that isn't CPU bound, but which might blocks entire 
> > > > > milliseconds
> > > > > on I/O.
> > > > 
> > > > There was a bug report of a overall (aka time ffmpeg) speedloss
> > > > in the % values with high res rawvideo
> > > 
> > > Was it fixed?
> > 
> > for rawideo and for several others too yes
> 
> I see no proof though. The numbers you posted so far are not really
> convincing. They're micro-benchmarks too, and might not even matter in
> real world work loads.

try some high res rawvideo like 4k
it should be very noticable IIRC

and there was a real bug report about
this so it did occur in a real world use case


> 
> > iam pretty sure there are other encoders that suffer from speedloss
> > due to this too though
> 
> What is "this"?
> 
> > 
> > > 
> > > > > > i do intend to fine tune this for more codecs but i spend more time
> > > > > > in such disussions than working on the code and having people tell 
> > > > > > me
> > > > > > to do it differently each time i take a step kind of slows it down
> > > > > > and turns it into a mess
> > > > > 
> > > > > We also must take care of not turning the codebase into a mess.
> > > > 
> > > > I want to fix the mess
> > > 
> > > I don't mind, but...
> > > 
> > > > and i would suggest that we first test if any / which encoders benefit
> > > > from the static buffer.
> > > > It where quite a few long ago but it seems from a few quick tests that
> > > > this is not so anymore.
> > > > Can someone confirm ?
> > > > if it has become useless then I could drop quite a bit of code
> > > 
> > > Do you have to do your experiments on the live codebase? If you just
> > > want to try something, you could do that in a branch. If it gives good
> > > results, merge, if not, it's a failed experiment.
> > 
> > noone did "experiments on the live codebase"
> 
> Then what's that "FIXME" in the heuristic, and the new API parameter
> that by now uses only 2 possible values, which make this "heuristic"
> completely pointless?

> What bugs me is that you insist on this (IMHO)

i wrote very clearly that i picked this option after waiting for 20
days and asking people what they prefer. And noone cared or suggested
anything that people liked
I have not the slightest preferrance for min_size over other solutions.


[...]

> Now I don't claim I can do better (actually I do, so feel free to call
> me an idiot), but here are my own (untested) conclusions.

you are certainly not an idiot. You are a very talented developer
and you have good ideas about designs.
But discussing with you withiout the discussion becoming a battlefield
of trolls and strawman is something i clearly fail at.


[...]
> I suppose the min_size parameter is supposed to select between these
> cases dynamically and use the "best" method. I suggest doing the
> following instead:
> 
> - have a buffer pool in the codec context
> - if a packet is allocated with a size larger then the current pool
>   size, realloc the buffer pool to that larger size
> - likewise, if the requested packet is much smaller than the current
>   pool size, you could either resize the pool, or just allocate the
>   packet normally (apply clever heuristic 1 here)
> - the encoder gets a refcounted packet from the buffer pool
> - after encoding, check how much memory is "wasted"
> - if too much is wasted (apply clever heuristic 2 here), create a new
>   copy (this could even use another buffer pool which might help if the
>   encoded packet sizes are usually similar, but maybe it's not worth
>   the trouble)

this is a good idea but more complex than what i have time to
implement in the near future.


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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use AVSTREAM_PARSE_FULL_ONCE for h264

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> > >  else if (codec_id == AV_CODEC_ID_H264) {
> > > -st->need_parsing = AVSTREAM_PARSE_HEADERS;
> > > +st->need_parsing = AVSTREAM_PARSE_FULL_ONCE;
> > 
> > Ping, the OP has updated the ticket.
> 
> patch should be ok then

Pushed and closed the ticket.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Do not fail on clut depth 0

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> Seems like a case for AV_EF_EXPLODE.

I wonder if this isn't a bug in our decoder given 
that the output looks very ugly and not an issue 
with the given stream but somebody will have to 
check.
I opened ticket #4754 for the visual issue.

> Also, why can't you send proper git patches?

I find it very uncomfortable and since you don't 
have to commit them, I hope it does not bother 
you too much.

Patch applied, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/swf: Fix detection of compressed files

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 8:58 AM, Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch fixes a regression since b7e506b3.
>
> Please comment, Carl Eugen


OK. (Link to file on samples in commit message would be helpful.)

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

Re: [FFmpeg-devel] [PATCH]lavc/dvbsub: Do not fail on clut depth 0

[wm4]

On Tue, 4 Aug 2015 13:18:54 + (UTC)
Carl Eugen Hoyos  wrote:

> wm4  googlemail.com> writes:
> 
> > Seems like a case for AV_EF_EXPLODE.
> 
> I wonder if this isn't a bug in our decoder given 
> that the output looks very ugly and not an issue 
> with the given stream but somebody will have to 
> check.
> I opened ticket #4754 for the visual issue.
> 
> > Also, why can't you send proper git patches?
> 
> I find it very uncomfortable and since you don't 
> have to commit them, I hope it does not bother 
> you too much.

They lack the commit message, so this bothers me very much. It's
important to ensure that commit messages provide enough information, so
they are definitely part of a patch review. Plus not sending complete
patches sets a bad example.

Setting up git-send-email is not that hard, and it will be much more
comfortable than creating a diff, opening your mail client, attaching
the patch, and somehow imperfectly replicating the commit message in
your email.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use AVSTREAM_PARSE_FULL_ONCE for h264

[Dewangan, Hitesh Kumar]

Remove me from this group please
On Jul 30, 2015 6:06 AM, "Carl Eugen Hoyos"  wrote:

> Carl Eugen Hoyos  ag.or.at> writes:
>
> > Attached patch suggested and tested by noah fixes ticket #4644.
>
> > diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> > index 64ac09c..5683731 100644
> > --- a/libavdevice/v4l2.c
> > +++ b/libavdevice/v4l2.c
>
> >  else if (codec_id == AV_CODEC_ID_H264) {
> > -st->need_parsing = AVSTREAM_PARSE_HEADERS;
> > +st->need_parsing = AVSTREAM_PARSE_FULL_ONCE;
>
> Ping, the OP has updated the ticket.
>
> Carl Eugen
>
> ___
> 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] Remove me from the list

[Dewangan, Hitesh Kumar]

Remove me from this group please

My mail id - hitesh.ku...@globalenglish.com
hitesh.dewan...@pearson.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for font names

[Niklesh Lalwani]

Updated patch.

Thanks,
Niklesh

On Tue, Aug 4, 2015 at 8:58 AM, Philip Langdale  wrote:

> On Fri, 31 Jul 2015 19:25:58 +0530
> Niklesh Lalwani  wrote:
>
> > From: Niklesh 
> >
> > The font names are extracted from the font table, present in text
> > sample entry. More than one fonts can be present, which is taken care
> > of in the patch.
> >
> > Signed-off-by: Niklesh 
> > ---
> >  libavcodec/movtextdec.c | 86
> > +++-- 1 file changed, 83
> > insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> > index 869358c..7d4dead 100644
> > --- a/libavcodec/movtextdec.c
> > +++ b/libavcodec/movtextdec.c
> > @@ -36,10 +36,17 @@
> >  #define HCLR_BOX   (1<<2)
> >
> >  typedef struct {
> > +uint16_t fontID;
> > +uint8_t font_name_length;
> > +uint8_t font[20];
> > +} FontRecord;
> > +
> > +typedef struct {
> >  uint16_t style_start;
> >  uint16_t style_end;
> >  uint8_t style_flag;
> >  uint8_t fontsize;
> > +uint16_t style_fontID;
> >  } StyleBox;
> >
> >  typedef struct {
> > @@ -56,11 +63,13 @@ typedef struct {
> >  StyleBox *s_temp;
> >  HighlightBox h;
> >  HilightcolorBox c;
> > +FontRecord **ftab;
> > +FontRecord *ftab_temp;
> >  uint8_t box_flags;
> > -uint16_t style_entries;
> > +uint16_t style_entries, ftab_entries;
> >  uint64_t tracksize;
> >  int size_var;
> > -int count_s;
> > +int count_s, count_f;
> >  } MovTextContext;
> >
> >  typedef struct {
> > @@ -80,6 +89,56 @@ static void mov_text_cleanup(MovTextContext *m)
> >  }
> >  }
> >
> > +static void mov_text_cleanup_ftab(MovTextContext *m)
> > +{
> > +int i;
> > +for(i = 0; i < m->count_f; i++) {
> > +av_freep(&m->ftab[i]);
> > +}
> > +av_freep(&m->ftab);
> > +}
> > +
> > +static int mov_text_t3xg(AVCodecContext *avctx, MovTextContext *m)
> > +{
> > +char *t3xg_ptr = avctx->extradata;
> > +int i;
> > +// Display Flags
> > +t3xg_ptr += 4;
> > +// Alignment
> > +t3xg_ptr += 2;
> > +// Background Color
> > +t3xg_ptr += 4;
> > +// BoxRecord
> > +t3xg_ptr += 8;
> > +// StyleRecord
> > +t3xg_ptr += 12;
> > +// FontRecord
> > +// FontRecord Size
> > +t3xg_ptr += 4;
> > +// ftab
> > +t3xg_ptr += 4;
> > +m->ftab_entries = AV_RB16(t3xg_ptr);
> > +t3xg_ptr += 2;
> > +for (i = 0; i < m->ftab_entries; i++) {
>
> Need to validate that ftab_entries is a sane value.
>
> > +m->ftab_temp = av_malloc(sizeof(*m->ftab_temp));
> > +if (!m->ftab_temp) {
> > +mov_text_cleanup_ftab(m);
> > +return AVERROR(ENOMEM);
> > +}
> > +m->ftab_temp->fontID = AV_RB16(t3xg_ptr);
> > +t3xg_ptr += 2;
> > +m->ftab_temp->font_name_length = *t3xg_ptr++;
>
> Need to validate font_name_length is a sane value
>
> > +memcpy(m->ftab_temp->font, t3xg_ptr,
> > m->ftab_temp->font_name_length);
> > +av_dynarray_add(&m->ftab, &m->count_f, m->ftab_temp);
> > +if (!m->ftab) {
> > +mov_text_cleanup_ftab(m);
> > +return AVERROR(ENOMEM);
> > +}
> > +t3xg_ptr += 10;
> > +}
> > +return 0;
> > +}
> > +
> >  static int decode_hlit(const uint8_t *tsmb, MovTextContext *m,
> > AVPacket *avpkt) {
> >  m->box_flags |= HLIT_BOX;
> > @@ -118,7 +177,7 @@ static int decode_styl(const uint8_t *tsmb,
> > MovTextContext *m, AVPacket *avpkt) tsmb += 2;
> >  m->s_temp->style_end = AV_RB16(tsmb);
> >  tsmb += 2;
> > -// fontID = AV_RB16(tsmb);
> > +m->s_temp->style_fontID = AV_RB16(tsmb);
> >  tsmb += 2;
> >  m->s_temp->style_flag = AV_RB8(tsmb);
> >  tsmb++;
> > @@ -147,6 +206,8 @@ static int text_to_ass(AVBPrint *buf, const char
> > *text, const char *text_end, MovTextContext *m)
> >  {
> >  int i = 0;
> > +int j = 0;
> > +int k = 0;
> >  int text_pos = 0;
> >  while (text < text_end) {
> >  if (m->box_flags & STYL_BOX) {
> > @@ -164,6 +225,14 @@ static int text_to_ass(AVBPrint *buf, const char
> > *text, const char *text_end, if (m->s[i]->style_flag &
> > STYLE_FLAG_UNDERLINE) av_bprintf(buf, "{\\u1}");
> >  av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
> > +av_bprintf(buf, "{\\fn");
> > +for (j = 0; j < m->ftab_entries; j++) {
> > +if (m->s[i]->style_fontID ==
> > m->ftab[j]->fontID) {
> > +for (k = 0; k <
> > m->ftab[0]->font_name_length; k++)
> > +av_bprintf(buf, "%c",
> > m->ftab[j]->font[k]);
>
> Use av_bprint_append_data.
>
> > +}
> > +}
> > +av_bprintf(buf, "}");
> >  }
> >  }
> >  }
> > @@ -215,6 +284,8 @@ static int mov_text_init(AVCodecContext *avctx) {
> >   * it

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 6:34 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Tue, Aug 4, 2015 at 2:49 AM,  wrote:
>
>> From: Shivraj Patil 
>>
>> Signed-off-by: Shivraj Patil 
>> ---
>>  libavcodec/mips/Makefile   |4 +
>>  libavcodec/mips/vp8_idct_msa.c |  160 +++
>>  libavcodec/mips/vp8_lpf_msa.c  |  690 +++
>>  libavcodec/mips/vp8_mc_msa.c   | 2332
>> 
>>  libavcodec/mips/vp8dsp_init_mips.c |  113 ++
>>  libavcodec/mips/vp8dsp_mips.h  |  172 +++
>>  libavcodec/vp8dsp.c|2 +
>>  libavcodec/vp8dsp.h|1 +
>>  8 files changed, 3474 insertions(+)
>>  create mode 100644 libavcodec/mips/vp8_idct_msa.c
>>  create mode 100644 libavcodec/mips/vp8_lpf_msa.c
>>  create mode 100644 libavcodec/mips/vp8_mc_msa.c
>>  create mode 100644 libavcodec/mips/vp8dsp_init_mips.c
>>  create mode 100644 libavcodec/mips/vp8dsp_mips.h
>>
>
> lgtm.
>
> (I'll try to apply this one later today myself, have to get a push tree
> running.)
>

And ... applied (I think).

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

Re: [FFmpeg-devel] [PATCH 3/3] MAINTAINERS: Add myself to vdpau maintainers

[Philip Langdale]

On Tue, 4 Aug 2015 11:02:40 + (UTC)
Carl Eugen Hoyos  wrote:

> Philip Langdale  overt.org> writes:
> 
> > -  vdpau*Carl Eugen Hoyos
> > +  vdpau*Philip Langdale, Carl
> > Eugen Hoyos
> 
> This is of course ok, as are the other two patches.
> 
> Did you test the sample sample as Hendrik?

Yes, but I couldn't see any difference before or after. Maybe I didn't
know what to look for, but the change seems logical and he's testing on
nvidia hardware as well, so I assume the fundamental behaviour is the
same.

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

Re: [FFmpeg-devel] [PATCH][RFC] ffmpeg: remove access to private FILE struct members on Windows

[Hendrik Leppkes]

On Mon, Aug 3, 2015 at 9:54 PM, Hendrik Leppkes  wrote:
> On Mon, Aug 3, 2015 at 9:30 PM, Nicolas George  wrote:
>> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>>> i also found this comment in a patch in my inbox:
>>>
>>> +  /* When using Standard C input functions, also check if there
>>> +   is anything in the buffer. After a call to such functions,
>>> +   the input waiting in the pipe will be copied to the buffer,
>>> +   and the call to PeekNamedPipe can indicate no input available.
>>> +   Setting stdin to unbuffered was not enough, IIRC */
>>> +  if (stdin->_cnt > 0)
>>> +  {
>>> +char ch;
>>> +//Read it
>>> +read(0, &ch, 1);
>>> +return ch;
>>> +  }
>>>
>>> This seems to explain what the code was intended to do
>>
>> That was my guess.
>>
>> This is ugly, and should be removed anyways. It is not possible to mix stdio
>> and low-level reading like that, period.
>>
>> Fortunately, ffmpeg.c only uses stdin at one single place, a few lines below
>> the corresponding code:
>>
>> }else
>> if(scanf("%d", &debug)!=1)
>> fprintf(stderr,"error parsing debug value\n");
>>
>> It needs to be changed to read a line with the low-level function
>> (read_key()), exactly like 40 above for the 'c' case. I can not brew a patch
>> right now, sorry.
>>
>> I suspect this would not work:
>>
>> printf 'd42\nC ... fontfile ...\n' | ffmpeg ...
>>
>> because the C will end up in the stdio buffer.
>>
>>
>
> Good catch. This command doesn't work with or without the hunk this
> patch removes however.
> A simpler command without drawtext would be:
>
> printf 'd0\n?' | ffmpeg -i ...
>
> If you see help output, it works. Using another command instead of d0
> works fine, like a C command followed by a \n?
> It also doesn't work on Linux, so thats a more fundamental problem.
>
> Since this fixes a build failure, unless we can find a use-case where
> this hunk actually does make a difference, I would still rather remove
> it.
> If it causes any regression in the future, which we didn't think of
> now, I'll be here to work on a fix.
>

Any further thoughts on this?

I would love start setting up a VS2015 FATE box etc, once compilation
actually works.

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

Re: [FFmpeg-devel] [PATCH][RFC] ffmpeg: remove access to private FILE struct members on Windows

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 12:42 PM, Hendrik Leppkes 
wrote:

> On Mon, Aug 3, 2015 at 9:54 PM, Hendrik Leppkes 
> wrote:
> > On Mon, Aug 3, 2015 at 9:30 PM, Nicolas George  wrote:
> >> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> >>> i also found this comment in a patch in my inbox:
> >>>
> >>> +  /* When using Standard C input functions, also check if there
> >>> +   is anything in the buffer. After a call to such functions,
> >>> +   the input waiting in the pipe will be copied to the buffer,
> >>> +   and the call to PeekNamedPipe can indicate no input available.
> >>> +   Setting stdin to unbuffered was not enough, IIRC */
> >>> +  if (stdin->_cnt > 0)
> >>> +  {
> >>> +char ch;
> >>> +//Read it
> >>> +read(0, &ch, 1);
> >>> +return ch;
> >>> +  }
> >>>
> >>> This seems to explain what the code was intended to do
> >>
> >> That was my guess.
> >>
> >> This is ugly, and should be removed anyways. It is not possible to mix
> stdio
> >> and low-level reading like that, period.
> >>
> >> Fortunately, ffmpeg.c only uses stdin at one single place, a few lines
> below
> >> the corresponding code:
> >>
> >> }else
> >> if(scanf("%d", &debug)!=1)
> >> fprintf(stderr,"error parsing debug value\n");
> >>
> >> It needs to be changed to read a line with the low-level function
> >> (read_key()), exactly like 40 above for the 'c' case. I can not brew a
> patch
> >> right now, sorry.
> >>
> >> I suspect this would not work:
> >>
> >> printf 'd42\nC ... fontfile ...\n' | ffmpeg ...
> >>
> >> because the C will end up in the stdio buffer.
> >>
> >>
> >
> > Good catch. This command doesn't work with or without the hunk this
> > patch removes however.
> > A simpler command without drawtext would be:
> >
> > printf 'd0\n?' | ffmpeg -i ...
> >
> > If you see help output, it works. Using another command instead of d0
> > works fine, like a C command followed by a \n?
> > It also doesn't work on Linux, so thats a more fundamental problem.
> >
> > Since this fixes a build failure, unless we can find a use-case where
> > this hunk actually does make a difference, I would still rather remove
> > it.
> > If it causes any regression in the future, which we didn't think of
> > now, I'll be here to work on a fix.
> >
>
> Any further thoughts on this?
>
> I would love start setting up a VS2015 FATE box etc, once compilation
> actually works.


I thought the conclusion was to apply it? I certainly support that.

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

Re: [FFmpeg-devel] [PATCH][RFC] ffmpeg: remove access to private FILE struct members on Windows

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 01:04:34PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Aug 4, 2015 at 12:42 PM, Hendrik Leppkes 
> wrote:
> 
> > On Mon, Aug 3, 2015 at 9:54 PM, Hendrik Leppkes 
> > wrote:
> > > On Mon, Aug 3, 2015 at 9:30 PM, Nicolas George  wrote:
> > >> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> > >>> i also found this comment in a patch in my inbox:
> > >>>
> > >>> +  /* When using Standard C input functions, also check if there
> > >>> +   is anything in the buffer. After a call to such functions,
> > >>> +   the input waiting in the pipe will be copied to the buffer,
> > >>> +   and the call to PeekNamedPipe can indicate no input available.
> > >>> +   Setting stdin to unbuffered was not enough, IIRC */
> > >>> +  if (stdin->_cnt > 0)
> > >>> +  {
> > >>> +char ch;
> > >>> +//Read it
> > >>> +read(0, &ch, 1);
> > >>> +return ch;
> > >>> +  }
> > >>>
> > >>> This seems to explain what the code was intended to do
> > >>
> > >> That was my guess.
> > >>
> > >> This is ugly, and should be removed anyways. It is not possible to mix
> > stdio
> > >> and low-level reading like that, period.
> > >>
> > >> Fortunately, ffmpeg.c only uses stdin at one single place, a few lines
> > below
> > >> the corresponding code:
> > >>
> > >> }else
> > >> if(scanf("%d", &debug)!=1)
> > >> fprintf(stderr,"error parsing debug value\n");
> > >>
> > >> It needs to be changed to read a line with the low-level function
> > >> (read_key()), exactly like 40 above for the 'c' case. I can not brew a
> > patch
> > >> right now, sorry.
> > >>
> > >> I suspect this would not work:
> > >>
> > >> printf 'd42\nC ... fontfile ...\n' | ffmpeg ...
> > >>
> > >> because the C will end up in the stdio buffer.
> > >>
> > >>
> > >
> > > Good catch. This command doesn't work with or without the hunk this
> > > patch removes however.
> > > A simpler command without drawtext would be:
> > >
> > > printf 'd0\n?' | ffmpeg -i ...
> > >
> > > If you see help output, it works. Using another command instead of d0
> > > works fine, like a C command followed by a \n?
> > > It also doesn't work on Linux, so thats a more fundamental problem.
> > >
> > > Since this fixes a build failure, unless we can find a use-case where
> > > this hunk actually does make a difference, I would still rather remove
> > > it.
> > > If it causes any regression in the future, which we didn't think of
> > > now, I'll be here to work on a fix.
> > >
> >
> > Any further thoughts on this?
> >
> > I would love start setting up a VS2015 FATE box etc, once compilation
> > actually works.
> 
> 
> I thought the conclusion was to apply it? I certainly support that.

+1

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers

[Carl Eugen Hoyos]

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

> - We should probably keep our bug tracker since it 
> reflects bugs on the FFmpeg code base. Processing 
> every bugs from the Libav tracker and importing 
> them might require some work, 

> but I think Carl has done most of that already.

I do not have access to all samples, so there may 
be a handful of bugzilla entries that are 
reproducible with FFmpeg but missing in trac.

> Lowest:
> 
> - I think keeping the FFmpeg name is important

I also think that this is "important" and therefore 
not "lowest" priority.
=-)

I agree with what you have written at least to a 
large degree. The reason it feels difficult to be 
more specific for me is that most things sound 
quite hypothetical here.

Thank you for the effort, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] ffmpeg: remove access to private FILE struct members on Windows

[Hendrik Leppkes]

On Tue, Aug 4, 2015 at 7:33 PM, Michael Niedermayer
 wrote:
> On Tue, Aug 04, 2015 at 01:04:34PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Tue, Aug 4, 2015 at 12:42 PM, Hendrik Leppkes 
>> wrote:
>>
>> > On Mon, Aug 3, 2015 at 9:54 PM, Hendrik Leppkes 
>> > wrote:
>> > > On Mon, Aug 3, 2015 at 9:30 PM, Nicolas George  wrote:
>> > >> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>> > >>> i also found this comment in a patch in my inbox:
>> > >>>
>> > >>> +  /* When using Standard C input functions, also check if there
>> > >>> +   is anything in the buffer. After a call to such functions,
>> > >>> +   the input waiting in the pipe will be copied to the buffer,
>> > >>> +   and the call to PeekNamedPipe can indicate no input available.
>> > >>> +   Setting stdin to unbuffered was not enough, IIRC */
>> > >>> +  if (stdin->_cnt > 0)
>> > >>> +  {
>> > >>> +char ch;
>> > >>> +//Read it
>> > >>> +read(0, &ch, 1);
>> > >>> +return ch;
>> > >>> +  }
>> > >>>
>> > >>> This seems to explain what the code was intended to do
>> > >>
>> > >> That was my guess.
>> > >>
>> > >> This is ugly, and should be removed anyways. It is not possible to mix
>> > stdio
>> > >> and low-level reading like that, period.
>> > >>
>> > >> Fortunately, ffmpeg.c only uses stdin at one single place, a few lines
>> > below
>> > >> the corresponding code:
>> > >>
>> > >> }else
>> > >> if(scanf("%d", &debug)!=1)
>> > >> fprintf(stderr,"error parsing debug value\n");
>> > >>
>> > >> It needs to be changed to read a line with the low-level function
>> > >> (read_key()), exactly like 40 above for the 'c' case. I can not brew a
>> > patch
>> > >> right now, sorry.
>> > >>
>> > >> I suspect this would not work:
>> > >>
>> > >> printf 'd42\nC ... fontfile ...\n' | ffmpeg ...
>> > >>
>> > >> because the C will end up in the stdio buffer.
>> > >>
>> > >>
>> > >
>> > > Good catch. This command doesn't work with or without the hunk this
>> > > patch removes however.
>> > > A simpler command without drawtext would be:
>> > >
>> > > printf 'd0\n?' | ffmpeg -i ...
>> > >
>> > > If you see help output, it works. Using another command instead of d0
>> > > works fine, like a C command followed by a \n?
>> > > It also doesn't work on Linux, so thats a more fundamental problem.
>> > >
>> > > Since this fixes a build failure, unless we can find a use-case where
>> > > this hunk actually does make a difference, I would still rather remove
>> > > it.
>> > > If it causes any regression in the future, which we didn't think of
>> > > now, I'll be here to work on a fix.
>> > >
>> >
>> > Any further thoughts on this?
>> >
>> > I would love start setting up a VS2015 FATE box etc, once compilation
>> > actually works.
>>
>>
>> I thought the conclusion was to apply it? I certainly support that.
>
> +1
>

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: avoid scanf in keyboard command parsing

[Hendrik Leppkes]

On Tue, Aug 4, 2015 at 1:35 PM, Michael Niedermayer
 wrote:
> On Mon, Aug 03, 2015 at 10:02:17PM +0200, Hendrik Leppkes wrote:
>> Mixing stdio and low-level IO on stdin is not safe.
>> ---
>>  ffmpeg.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> LGTM too
>

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

Re: [FFmpeg-devel] [PATCH 1/4] x86inc: Support arbitrary stack alignments

[Henrik Gramner]

On Mon, Aug 3, 2015 at 8:12 PM, Hendrik Leppkes  wrote:
> On Mon, Aug 3, 2015 at 5:26 PM, James Almer  wrote:
>> On 03/08/15 9:50 AM, Hendrik Leppkes wrote:
>>> Otherwise, I tested the patch with msvc 2013 32-bit, and fate passed fine.
>>> If there is something else I should specifically test which may not be
>>> covered by fate, let me know.
>>
>> Just to be sure try to convert an 8ch audio stream from float/s24 to 
>> floatp/s24p.
>> See if it crashes or gives wrong output.
>>
>
> Since I wasn't sure in which direction of packed/planar the problem
> usually happened, I tried 8ch s32 -> 8ch s32p, 8ch s32 -> 2ch s32p,
> 8ch s32p -> 8ch s32 and 8ch s32p -> 2ch s32, and all work fine.
>
> - Hendrik

Thanks for testing. Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86inc: warn if XOP integer FMA instruction emulation is impossible

[Henrik Gramner]

From: Anton Mitrofanov 

Signed-off-by: Henrik Gramner 
---
 libavutil/x86/x86inc.asm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 76fcec4..6ad9785 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1437,9 +1437,11 @@ AVX_INSTR pfmul, 3dnow, 1, 0, 1
 %macro %1 4-7 %1, %2, %3
 %if cpuflag(xop)
 v%5 %1, %2, %3, %4
-%else
+%elifnidn %1, %4
 %6 %1, %2, %3
 %7 %1, %4
+%else
+%error non-xop emulation of ``%5 %1, %2, %3, %4'' is not supported
 %endif
 %endmacro
 %endmacro
-- 
1.8.3.2

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

Re: [FFmpeg-devel] [PATCH] x86inc: warn if XOP integer FMA instruction emulation is impossible

[Ronald S. Bultje]

Hi,

On Tue, Aug 4, 2015 at 2:48 PM, Henrik Gramner  wrote:

> From: Anton Mitrofanov 
>
> Signed-off-by: Henrik Gramner 
> ---
>  libavutil/x86/x86inc.asm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
> index 76fcec4..6ad9785 100644
> --- a/libavutil/x86/x86inc.asm
> +++ b/libavutil/x86/x86inc.asm
> @@ -1437,9 +1437,11 @@ AVX_INSTR pfmul, 3dnow, 1, 0, 1
>  %macro %1 4-7 %1, %2, %3
>  %if cpuflag(xop)
>  v%5 %1, %2, %3, %4
> -%else
> +%elifnidn %1, %4
>  %6 %1, %2, %3
>  %7 %1, %4
> +%else
> +%error non-xop emulation of ``%5 %1, %2, %3, %4'' is not
> supported
>  %endif
>  %endmacro
>  %endmacro
>

lgtm.

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

Re: [FFmpeg-devel] Remove me from the list

[Lou Logan]

On Tue, 4 Aug 2015 19:52:35 +0530, Dewangan, Hitesh Kumar wrote:

> Remove me from this group please
> 
> My mail id - hitesh.ku...@globalenglish.com
> hitesh.dewan...@pearson.com

I did it for you, although it is encouraged for you to unsubscribe
yourself instead of making others do it for you. Afterall, you
subscribed yourself. Why would you be unable to unsubscribe?

For others who also can't figure it out, or who are too lazy to do so,
you can:

* Send a message to ffmpeg-devel-requ...@ffmpeg.org with subject
  "unsubscribe". The mailing list will then immediately email you asking
  for confirmation.

* Or go to the ffmpeg-devel info page, scroll to the very bottom, then
  enter your email address in the box with the button labeled,
  "Unsubscribe or edit options". On the next page, go to
  "Unsubscribing from ffmpeg-devel", click the checkbox, and press the
  button. Unsubscription is immediate.
  
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] x86inc: Drop SECTION_TEXT macro

[Henrik Gramner]

On Mon, Aug 3, 2015 at 1:37 AM, Ronald S. Bultje  wrote:
> Does silencing these warnings still work after this patch?
>
> If so: ok.
>
> Ronald

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

Re: [FFmpeg-devel] [PATCH]lavf/swf: Fix detection of compressed files

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> > Attached patch fixes a regression since b7e506b3.

> OK. (Link to file on samples in commit message would be helpful.)

Committed with a link to http://samples.ffmpeg.org/SWF/compressed-swf/

Thank you, Carl Eugen

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

[FFmpeg-devel] [PATCH] avfilter: add showfreqs filter

[Paul B Mahol]

---

Is this correct?

---
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/avf_showfreqs.c | 333 
 3 files changed, 335 insertions(+)
 create mode 100644 libavfilter/avf_showfreqs.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1865e49..049bbe8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -256,6 +256,7 @@ OBJS-$(CONFIG_ADRAWGRAPH_FILTER) += 
f_drawgraph.o
 OBJS-$(CONFIG_AVECTORSCOPE_FILTER)   += avf_avectorscope.o
 OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
 OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o
+OBJS-$(CONFIG_SHOWFREQS_FILTER)  += avf_showfreqs.o
 OBJS-$(CONFIG_SHOWSPECTRUM_FILTER)   += avf_showspectrum.o
 OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
 OBJS-$(CONFIG_SHOWWAVES_FILTER)  += avf_showwaves.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f8e97bc..63a274a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -271,6 +271,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(AVECTORSCOPE,   avectorscope,   avf);
 REGISTER_FILTER(CONCAT, concat, avf);
 REGISTER_FILTER(SHOWCQT,showcqt,avf);
+REGISTER_FILTER(SHOWFREQS,  showfreqs,  avf);
 REGISTER_FILTER(SHOWSPECTRUM,   showspectrum,   avf);
 REGISTER_FILTER(SHOWVOLUME, showvolume, avf);
 REGISTER_FILTER(SHOWWAVES,  showwaves,  avf);
diff --git a/libavfilter/avf_showfreqs.c b/libavfilter/avf_showfreqs.c
new file mode 100644
index 000..54902b9
--- /dev/null
+++ b/libavfilter/avf_showfreqs.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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 "libavcodec/avfft.h"
+#include "libavutil/avassert.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+
+enum DisplayMode  { LINE, BAR, DOT, NB_MODES };
+enum DisplayScale { LINEAR, SQRT, CBRT, LOG, NB_SCALES };
+enum WindowFunc   { WFUNC_NONE, WFUNC_HANN, WFUNC_HAMMING, WFUNC_BLACKMAN, 
NB_WFUNC };
+
+typedef struct ShowFreqsContext {
+const AVClass *class;
+int w, h;
+RDFTContext *rdft;  ///< Real Discrete Fourier Transform context
+int rdft_bits;  ///< number of bits (RDFT window size = 
1outputs[0];
+static const enum AVSampleFormat sample_fmts[] = { AV_SAMPLE_FMT_S16P, 
AV_SAMPLE_FMT_NONE };
+static const enum AVPixelFormat pix_fmts[] = { AV_PIX_FMT_RGBA, 
AV_PIX_FMT_NONE };
+
+/* set input audio formats */
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &inlink->out_formats);
+
+layouts = ff_all_channel_layouts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ff_channel_layouts_ref(layouts, &inlink->out_channel_layouts);
+
+formats = ff_all_samplerates();
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &inlink->out_samplerates);
+
+/* set output video format */
+formats = ff_make_format_list(pix_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ff_formats_ref(formats, &outlink->in_formats);
+
+return 0;
+}
+
+static int config_output(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+AVFilterLink *inlink = ctx->inputs[0];
+ShowFreqsContext *s = ctx->priv;
+unsigned win_size;
+int i, rdft_bits;
+
+outlink->w = s->w;
+outlink->h = s->h;
+
+/* RDFT window size (precision) according to the requested output frame 
height */
+for (rdft_bits = 1; 1 << rdft_bits < 2 * outlink->w; rdft_bits++);
+win_size = 1 << rdft_bits;
+
+/* (re-)configuration if the video output changed (or first init) */
+if (rdft_bits != s->rdft_bits) {
+size_t rdft_size, rdft_listsize;
+
+av_rdft_end(s->rdft);
+s->rdft = av_rdft_init(rdft_bits, DFT_R2C);
+if (!s->rdft) {
+av_log(ctx, AV_LOG_ERROR, "Unable to create RDFT context. "
+ 

Re: [FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers

[Alex Beregszaszi]

On Sat, Aug 1, 2015 at 10:18 AM, Clément Bœsch  wrote:
> Hi folks,
>
> Since Michael decided to step down as a leader, the question of
> reunification with Libav came up once more naturally. Before negotiations
> start again, I think it's important if we can all individually start
> thinking about what are our conditions or expectations from a potential
> reunification, and what we are willing to concede in the process.

I haven't been active on FFmpeg for many years now, yet I still follow
the discussions as my time allows.

I would question the whole merge:
1) To me it seems that libav has a smaller contributor and code base.

2) My gut feeling is that many of the new contributors come to libav
because they have found it in their distribution. As of now Debian and
Gentoo has switched back to FFmpeg. I would believe this source of
contributors would see a decline in libav.

3) Given Michael is stepping down, that should be an incentive for
those who are not contributing to FFmpeg directly because of him (if
such contributors exist) to reconsider their choice.

4) Do you want to have the same rules in FFmpeg as in libav? If not,
my gut feeling is that the original libav authors won't switch back,
i.e. libav would continue to be developed separately.

Long story short: my point is that it might not be needed to do an
official freeze and merge. Invite and welcome developers from the
other side.

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

[FFmpeg-devel] [PATCH] libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge.

[Sasi Inguva]

Compute individual stream durations in matroska muxer.
Write them as string tags in the same format as mkvmerge tool does.

Signed-off-by: Sasi Inguva 
---
 libavformat/matroskaenc.c| 75 +---
 tests/fate/wavpack.mak   |  4 +--
 tests/ref/acodec/tta |  4 +--
 tests/ref/fate/binsub-mksenc |  2 +-
 tests/ref/lavf/mkv   |  8 ++---
 tests/ref/seek/lavf-mkv  | 44 +-
 6 files changed, 101 insertions(+), 36 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 2d0d5f6..0d3ae37 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -44,6 +44,7 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
 #include "libavutil/random_seed.h"
+#include "libavutil/rational.h"
 #include "libavutil/samplefmt.h"
 #include "libavutil/sha.h"
 #include "libavutil/stereo3d.h"
@@ -131,6 +132,9 @@ typedef struct MatroskaMuxContext {
 
 int64_t last_track_timestamp[MAX_TRACKS];
 
+int64_t* stream_durations;
+int64_t* stream_duration_offsets;
+
 int allow_raw_vfw;
 } MatroskaMuxContext;
 
@@ -1151,12 +1155,12 @@ static int mkv_write_simpletag(AVIOContext *pb, 
AVDictionaryEntry *t)
 return 0;
 }
 
-static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
elementid,
- unsigned int uid, ebml_master *tags)
+static int mkv_write_tag_targets(AVFormatContext *s,
+ unsigned int elementid, unsigned int uid,
+ ebml_master *tags, ebml_master* tag)
 {
 MatroskaMuxContext *mkv = s->priv_data;
-ebml_master tag, targets;
-AVDictionaryEntry *t = NULL;
+ebml_master targets;
 int ret;
 
 if (!tags->pos) {
@@ -1166,11 +1170,24 @@ static int mkv_write_tag(AVFormatContext *s, 
AVDictionary *m, unsigned int eleme
 *tags = start_ebml_master(s->pb, MATROSKA_ID_TAGS, 0);
 }
 
-tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
+*tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
 targets = start_ebml_master(s->pb, MATROSKA_ID_TAGTARGETS, 0);
 if (elementid)
 put_ebml_uint(s->pb, elementid, uid);
 end_ebml_master(s->pb, targets);
+return 0;
+}
+
+static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
elementid,
+ unsigned int uid, ebml_master *tags)
+{
+ebml_master tag;
+int ret;
+AVDictionaryEntry *t = NULL;
+
+ret = mkv_write_tag_targets(s, elementid, uid, tags, &tag);
+if (ret < 0)
+return ret;
 
 while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
 if (av_strcasecmp(t->key, "title") &&
@@ -1220,6 +1237,29 @@ static int mkv_write_tags(AVFormatContext *s)
 if (ret < 0) return ret;
 }
 
+
+mkv->stream_durations = av_mallocz(s->nb_streams * sizeof(int64_t));
+mkv->stream_duration_offsets = av_mallocz(s->nb_streams * sizeof(int64_t));
+
+if (!mkv->is_live) {
+  for (i = 0; i < s->nb_streams; i++) {
+ebml_master tag_target;
+ebml_master tag;
+
+mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, 
&tags, &tag_target);
+
+tag = start_ebml_master(s->pb, MATROSKA_ID_SIMPLETAG, 0);
+put_ebml_string(s->pb, MATROSKA_ID_TAGNAME, "DURATION");
+mkv->stream_duration_offsets[i] = avio_tell(s->pb);
+
+// Reserve space to write duration as a 20-byte string.
+// 2 (ebml id) + 1 (data size) + 20 (data)
+put_ebml_void(s->pb, 23);
+end_ebml_master(s->pb, tag);
+end_ebml_master(s->pb, tag_target);
+  }
+}
+
 for (i = 0; i < s->nb_chapters; i++) {
 AVChapter *ch = s->chapters[i];
 
@@ -1801,6 +1841,9 @@ static int mkv_write_packet_internal(AVFormatContext *s, 
AVPacket *pkt, int add_
 }
 
 mkv->duration = FFMAX(mkv->duration, ts + duration);
+mkv->stream_durations[pkt->stream_index] =
+FFMAX(mkv->stream_durations[pkt->stream_index], ts + duration);
+
 return 0;
 }
 
@@ -1978,6 +2021,26 @@ static int mkv_write_trailer(AVFormatContext *s)
 avio_seek(pb, mkv->duration_offset, SEEK_SET);
 put_ebml_float(pb, MATROSKA_ID_DURATION, mkv->duration);
 
+// update stream durations
+for (int i = 0; i < s->nb_streams; ++i) {
+  AVStream *st = s->streams[i];
+  double duration_sec = mkv->stream_durations[i] * 
av_q2d(st->time_base);
+  char duration_string[20] = "";
+
+  av_log(s, AV_LOG_DEBUG, "stream %d end duration = %" PRIu64 "\n", i,
+ mkv->stream_durations[i]);
+
+  if (!mkv->is_live) {
+avio_seek(pb, mkv->stream_duration_offsets[i], SEEK_SET);
+
+snprintf(duration_string, 20, "%02d:%02d:%012.9f",
+ (int) duration_sec / 3600, ((int) duration_sec / 60) % 60,
+ fmod(duration_sec, 60));
+
+put_ebml_bina

Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected

[Ganesh Ajjanagadde]

On Mon, Aug 3, 2015 at 10:47 AM, Nicolas George  wrote:
> Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
>> Trashing the state even more often just because there is one example
>> where this can already happen is not a valid reasoning.
>
> The changes should be applied because they are the RIGHT behaviour, as I
> explained in this mail:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176480.html
>
> The second patch gives a 10-second solutions that will fix ALL trashed ttys,
> for FFmpeg and every other program on the system.
>
> Furthermore, the third patch ensures that the particular case that this
> absurd heuristic fixed does not happen anyway.

Above explanation gives good justification for this patch.
Is there anything I can do to get the patch series applied?

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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] [PATCH 2/6] aacenc: Improve Intensity Stereo phase detection

[Rostislav Pehlivanov]

>L34/R34
Calculating the 3/4 power of the coefficients isn't really that expensive
to do twice, so I'll just scrap the whole idea.

>identation
How'd I miss that? Fixed.

>phase
Copied that from an older revision, missed that '*' sign and didn't notice,
fixed.

Will wait a while to see whether the other commits look good before sending
the fixed one.

On 4 August 2015 at 08:31, Claudio Freire  wrote:

> On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
>  wrote:
> > +if (cpe->ms_mode)
> > +phase = 1 - 2 * cpe->ms_mask[w*16+g];
>
>
> Shouldn't it be ?
>
> phase *= 1 - ... ;
>
> phase is an argument, the original code would step on it, with a value
> that doesn't depend on phase, so it would fail to evaluate both
> phases. Using phase *= would make sure to test both phases.
>
> Well, that's the general idea, except it breaks the phase assigned to
> the struct. Something like the following does work though:
>
> ephase = phase;
> if (cpe->ms_mode)
> ephase *= 1 - 2 * cpe->ms_mask[w*16+g];
>
> and then change all uses of phase into ephase, except the last that
> remains:
>
> is_error.phase = phase; // original phase
> is_error.pass  = dist2 <= dist1;
>
>
> On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
>  wrote:
> >  for (w = 0; w < 128; w++)
> >  if (sce1->band_type[w] >= INTENSITY_BT2)
> >  sce1->band_type[w] = 0;
> >
> > -if (!cpe->common_window)
> > -return;
> > -for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w])
> {
> > -start = 0;
> > -for (g = 0;  g < sce0->ics.num_swb; g++) {
> > -if (start*freq_mult > INT_STEREO_LOW_LIMIT*(lambda/170.0f)
> &&
> > -cpe->ch[0].band_type[w*16+g] != NOISE_BT &&
> !cpe->ch[0].zeroes[w*16+g] &&
> > -cpe->ch[1].band_type[w*16+g] != NOISE_BT &&
> !cpe->ch[1].zeroes[w*16+g]) {
> > -int phase = 0;
> > -float ener0 = 0.0f, ener1 = 0.0f, ener01 = 0.0f;
> > -float dist1 = 0.0f, dist2 = 0.0f;
> > +if (!cpe->common_window)
> > +return;
> > +for (w = 0; w < sce0->ics.num_windows; w +=
> sce0->ics.group_len[w]) {
> > +start = 0;
> > +for (g = 0;  g < sce0->ics.num_swb; g++) {
> > +if (start*freq_mult >
> INT_STEREO_LOW_LIMIT*(s->lambda/170.0f) &&
>
> This looks strange. As it is that patch, it ends up with code like:
>
> >for (w = 0; w < 128; w++)
> >if (sce1->band_type[w] >= INTENSITY_BT2)
> >sce1->band_type[w] = 0;
> >
> >if (!cpe->common_window)
> >return;
> >for (w = 0; w < sce0->ics.num_windows; w +=
> sce0->ics.group_len[w]) {
> >start = 0;
> >for (g = 0;  g < sce0->ics.num_swb; g++) {
>
> Which looks wrong. Bad indentation right?
>
> I think you meant:
>
> for (w = 0; w < 128; w++)
> if (sce1->band_type[w] >= INTENSITY_BT2)
> sce1->band_type[w] = 0;
>
> if (!cpe->common_window)
> return;
> for (w = 0; w < sce0->ics.num_windows; w += sce0->ics.group_len[w]) {
> start = 0;
> for (g = 0;  g < sce0->ics.num_swb; g++) {
>
> A big part of the diff in that hunk is reindent, so I believe if you
> fix that indentation snafu the patch will shrink.
>
> On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov
>  wrote:
> >  for (w2 = 0; w2 < sce0->ics.group_len[w]; w2++) {
> > +abs_pow34_v(L34, sce0->coeffs+start+(w+w2)*128,
> sce0->ics.swb_sizes[g]);
> > +abs_pow34_v(R34, sce1->coeffs+start+(w+w2)*128,
> sce0->ics.swb_sizes[g]);
> >  for (i = 0; i < sce0->ics.swb_sizes[g]; i++) {
> >  float coef0 = sce0->pcoeffs[start+(w+w2)*128+i];
> >  float coef1 = sce1->pcoeffs[start+(w+w2)*128+i];
> > -phase += coef0*coef1 >= 0.0f ? 1 : -1;
> >  ener0 += coef0*coef0;
> >  ener1 += coef1*coef1;
> >  ener01 += (coef0 + coef1)*(coef0 + coef1);
> >  }
> >  }
>
> Careful, you're stepping on L34 and R34 on eight_short_window, and
> passing the last results only to calc_encoding_err_is.
>
> In fact, I'm thinking I may have induced you to make that mistake when
> I suggested not to compute R34 / L34 twice (once for each phase),
> since L34 and R34 only have room for one window, and
> calc_encoding_err_is needs to process a whole window group.
>
> I think you'll have to move it back to inside calc_encoing_err_is and
> just compute it twice. Redundant, but at least it's correct.
>
> Also, you should use pcoeffs (coeffs will have M/S applied to it when
> ms_mask).
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for font names

[Philip Langdale]

On Tue, 4 Aug 2015 20:15:58 +0530
Niklesh Lalwani  wrote:

> From f901f48320140b8f011ec089e6d950e25c90beec Mon Sep 17 00:00:00 2001
> From: Niklesh 
> Date: Tue, 4 Aug 2015 20:10:28 +0530
> Subject: [PATCH] movtextdec.c: Add support for font names
> 
> Signed-off-by: Niklesh 
> ---
>  libavcodec/movtextdec.c | 94
> +++-- 1 file changed, 91
> insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 869358c..3bea93e 100644
> --- a/libavcodec/movtextdec.c
> +++ b/libavcodec/movtextdec.c
> @@ -36,10 +36,17 @@
>  #define HCLR_BOX   (1<<2)
>  
>  typedef struct {
> +uint16_t fontID;
> +uint8_t font_name_length;
> +uint8_t font[20];
> +} FontRecord;
> +
> +typedef struct {
>  uint16_t style_start;
>  uint16_t style_end;
>  uint8_t style_flag;
>  uint8_t fontsize;
> +uint16_t style_fontID;
>  } StyleBox;
>  
>  typedef struct {
> @@ -56,11 +63,13 @@ typedef struct {
>  StyleBox *s_temp;
>  HighlightBox h;
>  HilightcolorBox c;
> +FontRecord **ftab;
> +FontRecord *ftab_temp;
>  uint8_t box_flags;
> -uint16_t style_entries;
> +uint16_t style_entries, ftab_entries;
>  uint64_t tracksize;
>  int size_var;
> -int count_s;
> +int count_s, count_f;
>  } MovTextContext;
>  
>  typedef struct {
> @@ -80,6 +89,63 @@ static void mov_text_cleanup(MovTextContext *m)
>  }
>  }
>  
> +static void mov_text_cleanup_ftab(MovTextContext *m)
> +{
> +int i;
> +for(i = 0; i < m->count_f; i++) {
> +av_freep(&m->ftab[i]);
> +}
> +av_freep(&m->ftab);
> +}
> +
> +static int mov_text_t3xg(AVCodecContext *avctx, MovTextContext *m)
> +{
> +char *t3xg_ptr = avctx->extradata;
> +int i;
> +// Display Flags
> +t3xg_ptr += 4;
> +// Alignment
> +t3xg_ptr += 2;
> +// Background Color
> +t3xg_ptr += 4;
> +// BoxRecord
> +t3xg_ptr += 8;
> +// StyleRecord
> +t3xg_ptr += 12;
> +// FontRecord
> +// FontRecord Size
> +t3xg_ptr += 4;
> +// ftab
> +t3xg_ptr += 4;
> +m->ftab_entries = AV_RB16(t3xg_ptr);
> +if (!ftab_entries) {
> +return -1;
> +}

I didn't mean this - it's ok for the value to be 0, but it's
not ok for it to be some huge number that will cause you to
read beyond the end of the buffer. So like you did for the other
variable length fields, you need to sanity check this against the total
packet size.

> +t3xg_ptr += 2;
> +for (i = 0; i < m->ftab_entries; i++) {
> +m->ftab_temp = av_malloc(sizeof(*m->ftab_temp));
> +if (!m->ftab_temp) {
> +mov_text_cleanup_ftab(m);
> +return AVERROR(ENOMEM);
> +}
> +m->ftab_temp->fontID = AV_RB16(t3xg_ptr);
> +t3xg_ptr += 2;
> +m->ftab_temp->font_name_length = *t3xg_ptr++;
> +if (!m->ftab_temp->font_name_length) {
> +m->ftab_entries = 0;
> +return -1;
> +}

Similarly here. The fontname length could be too long. We know it is
not allowed to be more than 20, but you also need to verify against
total packet size.

> +memcpy(m->ftab_temp->font, t3xg_ptr,
> m->ftab_temp->font_name_length);
> +av_dynarray_add(&m->ftab, &m->count_f, m->ftab_temp);
> +if (!m->ftab) {
> +mov_text_cleanup_ftab(m);
> +return AVERROR(ENOMEM);
> +}
> +t3xg_ptr += 10;
> +}
> +return 0;
> +}
> +
>  static int decode_hlit(const uint8_t *tsmb, MovTextContext *m,
> AVPacket *avpkt) {
>  m->box_flags |= HLIT_BOX;
> @@ -118,7 +184,7 @@ static int decode_styl(const uint8_t *tsmb,
> MovTextContext *m, AVPacket *avpkt) tsmb += 2;
>  m->s_temp->style_end = AV_RB16(tsmb);
>  tsmb += 2;
> -// fontID = AV_RB16(tsmb);
> +m->s_temp->style_fontID = AV_RB16(tsmb);
>  tsmb += 2;
>  m->s_temp->style_flag = AV_RB8(tsmb);
>  tsmb++;
> @@ -147,6 +213,8 @@ static int text_to_ass(AVBPrint *buf, const char
> *text, const char *text_end, MovTextContext *m)
>  {
>  int i = 0;
> +int j = 0;
> +int k = 0;
>  int text_pos = 0;
>  while (text < text_end) {
>  if (m->box_flags & STYL_BOX) {
> @@ -164,6 +232,14 @@ static int text_to_ass(AVBPrint *buf, const char
> *text, const char *text_end, if (m->s[i]->style_flag &
> STYLE_FLAG_UNDERLINE) av_bprintf(buf, "{\\u1}");
>  av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
> +av_bprintf(buf, "{\\fn");
> +for (j = 0; j < m->ftab_entries; j++) {
> +if (m->s[i]->style_fontID ==
> m->ftab[j]->fontID) {
> +av_bprint_append_data(buf,
> m->ftab[j]->font,
> +
> m->ftab[j]->font_name_length);
> +}
> +}
> +av_bprintf(buf, "}");
>  }
>  }
>  }
> @@ -215,6 +291,8 @@ static int 

Re: [FFmpeg-devel] [PATCH] libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge.

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 05:32:51PM -0700, Sasi Inguva wrote:
> Compute individual stream durations in matroska muxer.
> Write them as string tags in the same format as mkvmerge tool does.
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/matroskaenc.c| 75 
> +---
>  tests/fate/wavpack.mak   |  4 +--
>  tests/ref/acodec/tta |  4 +--
>  tests/ref/fate/binsub-mksenc |  2 +-
>  tests/ref/lavf/mkv   |  8 ++---
>  tests/ref/seek/lavf-mkv  | 44 +-
>  6 files changed, 101 insertions(+), 36 deletions(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 2d0d5f6..0d3ae37 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -44,6 +44,7 @@
>  #include "libavutil/mathematics.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/random_seed.h"
> +#include "libavutil/rational.h"
>  #include "libavutil/samplefmt.h"
>  #include "libavutil/sha.h"
>  #include "libavutil/stereo3d.h"
> @@ -131,6 +132,9 @@ typedef struct MatroskaMuxContext {
>  
>  int64_t last_track_timestamp[MAX_TRACKS];
>  
> +int64_t* stream_durations;
> +int64_t* stream_duration_offsets;
> +
>  int allow_raw_vfw;
>  } MatroskaMuxContext;
>  
> @@ -1151,12 +1155,12 @@ static int mkv_write_simpletag(AVIOContext *pb, 
> AVDictionaryEntry *t)
>  return 0;
>  }
>  
> -static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
> elementid,
> - unsigned int uid, ebml_master *tags)
> +static int mkv_write_tag_targets(AVFormatContext *s,
> + unsigned int elementid, unsigned int uid,
> + ebml_master *tags, ebml_master* tag)
>  {
>  MatroskaMuxContext *mkv = s->priv_data;
> -ebml_master tag, targets;
> -AVDictionaryEntry *t = NULL;
> +ebml_master targets;
>  int ret;
>  
>  if (!tags->pos) {
> @@ -1166,11 +1170,24 @@ static int mkv_write_tag(AVFormatContext *s, 
> AVDictionary *m, unsigned int eleme
>  *tags = start_ebml_master(s->pb, MATROSKA_ID_TAGS, 0);
>  }
>  
> -tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
> +*tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
>  targets = start_ebml_master(s->pb, MATROSKA_ID_TAGTARGETS, 0);
>  if (elementid)
>  put_ebml_uint(s->pb, elementid, uid);
>  end_ebml_master(s->pb, targets);
> +return 0;
> +}
> +
> +static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
> elementid,
> + unsigned int uid, ebml_master *tags)
> +{
> +ebml_master tag;
> +int ret;
> +AVDictionaryEntry *t = NULL;
> +
> +ret = mkv_write_tag_targets(s, elementid, uid, tags, &tag);
> +if (ret < 0)
> +return ret;
>  
>  while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
>  if (av_strcasecmp(t->key, "title") &&
> @@ -1220,6 +1237,29 @@ static int mkv_write_tags(AVFormatContext *s)
>  if (ret < 0) return ret;
>  }
>  
> +
> +mkv->stream_durations = av_mallocz(s->nb_streams * sizeof(int64_t));
> +mkv->stream_duration_offsets = av_mallocz(s->nb_streams * 
> sizeof(int64_t));

this is not called in all cases, for example its not called for
webm


> +
> +if (!mkv->is_live) {
> +  for (i = 0; i < s->nb_streams; i++) {
> +ebml_master tag_target;
> +ebml_master tag;
> +
> +mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, 
> &tags, &tag_target);
> +
> +tag = start_ebml_master(s->pb, MATROSKA_ID_SIMPLETAG, 0);
> +put_ebml_string(s->pb, MATROSKA_ID_TAGNAME, "DURATION");
> +mkv->stream_duration_offsets[i] = avio_tell(s->pb);
> +
> +// Reserve space to write duration as a 20-byte string.
> +// 2 (ebml id) + 1 (data size) + 20 (data)
> +put_ebml_void(s->pb, 23);
> +end_ebml_master(s->pb, tag);
> +end_ebml_master(s->pb, tag_target);
> +  }
> +}
> +
>  for (i = 0; i < s->nb_chapters; i++) {
>  AVChapter *ch = s->chapters[i];
>  
> @@ -1801,6 +1841,9 @@ static int mkv_write_packet_internal(AVFormatContext 
> *s, AVPacket *pkt, int add_
>  }
>  
>  mkv->duration = FFMAX(mkv->duration, ts + duration);
> +mkv->stream_durations[pkt->stream_index] =
> +FFMAX(mkv->stream_durations[pkt->stream_index], ts + duration);
> +

this is called for webm too though

[...]
-- 
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/mailm

[FFmpeg-devel] [PATCH] libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge.

[Sasi Inguva]

Compute individual stream durations in matroska muxer.
Write them as string tags in the same format as mkvmerge tool does.

Signed-off-by: Sasi Inguva 
---
 libavformat/matroskaenc.c| 79 +---
 tests/fate/wavpack.mak   |  4 +--
 tests/ref/acodec/tta |  4 +--
 tests/ref/fate/binsub-mksenc |  2 +-
 tests/ref/lavf/mkv   |  8 ++---
 tests/ref/seek/lavf-mkv  | 44 
 6 files changed, 105 insertions(+), 36 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 2d0d5f6..703abc3 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -44,6 +44,7 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
 #include "libavutil/random_seed.h"
+#include "libavutil/rational.h"
 #include "libavutil/samplefmt.h"
 #include "libavutil/sha.h"
 #include "libavutil/stereo3d.h"
@@ -131,6 +132,9 @@ typedef struct MatroskaMuxContext {
 
 int64_t last_track_timestamp[MAX_TRACKS];
 
+int64_t* stream_durations;
+int64_t* stream_duration_offsets;
+
 int allow_raw_vfw;
 } MatroskaMuxContext;
 
@@ -1151,12 +1155,12 @@ static int mkv_write_simpletag(AVIOContext *pb, 
AVDictionaryEntry *t)
 return 0;
 }
 
-static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
elementid,
- unsigned int uid, ebml_master *tags)
+static int mkv_write_tag_targets(AVFormatContext *s,
+ unsigned int elementid, unsigned int uid,
+ ebml_master *tags, ebml_master* tag)
 {
 MatroskaMuxContext *mkv = s->priv_data;
-ebml_master tag, targets;
-AVDictionaryEntry *t = NULL;
+ebml_master targets;
 int ret;
 
 if (!tags->pos) {
@@ -1166,11 +1170,24 @@ static int mkv_write_tag(AVFormatContext *s, 
AVDictionary *m, unsigned int eleme
 *tags = start_ebml_master(s->pb, MATROSKA_ID_TAGS, 0);
 }
 
-tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
+*tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
 targets = start_ebml_master(s->pb, MATROSKA_ID_TAGTARGETS, 0);
 if (elementid)
 put_ebml_uint(s->pb, elementid, uid);
 end_ebml_master(s->pb, targets);
+return 0;
+}
+
+static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int 
elementid,
+ unsigned int uid, ebml_master *tags)
+{
+ebml_master tag;
+int ret;
+AVDictionaryEntry *t = NULL;
+
+ret = mkv_write_tag_targets(s, elementid, uid, tags, &tag);
+if (ret < 0)
+return ret;
 
 while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
 if (av_strcasecmp(t->key, "title") &&
@@ -1220,6 +1237,25 @@ static int mkv_write_tags(AVFormatContext *s)
 if (ret < 0) return ret;
 }
 
+if (!mkv->is_live) {
+for (i = 0; i < s->nb_streams; i++) {
+ebml_master tag_target;
+ebml_master tag;
+
+mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, 
&tags, &tag_target);
+
+tag = start_ebml_master(s->pb, MATROSKA_ID_SIMPLETAG, 0);
+put_ebml_string(s->pb, MATROSKA_ID_TAGNAME, "DURATION");
+mkv->stream_duration_offsets[i] = avio_tell(s->pb);
+
+// Reserve space to write duration as a 20-byte string.
+// 2 (ebml id) + 1 (data size) + 20 (data)
+put_ebml_void(s->pb, 23);
+end_ebml_master(s->pb, tag);
+end_ebml_master(s->pb, tag_target);
+}
+}
+
 for (i = 0; i < s->nb_chapters; i++) {
 AVChapter *ch = s->chapters[i];
 
@@ -1430,6 +1466,10 @@ static int mkv_write_header(AVFormatContext *s)
 }
 end_ebml_master(pb, segment_info);
 
+// initialize stream_duration fields
+mkv->stream_durations = av_mallocz(s->nb_streams * sizeof(int64_t));
+mkv->stream_duration_offsets = av_mallocz(s->nb_streams * sizeof(int64_t));
+
 ret = mkv_write_tracks(s);
 if (ret < 0)
 return ret;
@@ -1801,6 +1841,11 @@ static int mkv_write_packet_internal(AVFormatContext *s, 
AVPacket *pkt, int add_
 }
 
 mkv->duration = FFMAX(mkv->duration, ts + duration);
+
+if (mkv->stream_durations)
+mkv->stream_durations[pkt->stream_index] =
+FFMAX(mkv->stream_durations[pkt->stream_index], ts + duration);
+
 return 0;
 }
 
@@ -1978,6 +2023,28 @@ static int mkv_write_trailer(AVFormatContext *s)
 avio_seek(pb, mkv->duration_offset, SEEK_SET);
 put_ebml_float(pb, MATROSKA_ID_DURATION, mkv->duration);
 
+// update stream durations
+if (mkv->stream_durations) {
+for (int i = 0; i < s->nb_streams; ++i) {
+AVStream *st = s->streams[i];
+double duration_sec = mkv->stream_durations[i] * 
av_q2d(st->time_base);
+char duration_string[20] = "";
+
+av_log(s, AV_LOG_DEBUG, "stream %d end duration = %" PR

Re: [FFmpeg-devel] [PATCH] libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge.

[Sasi Inguva]

Changed the patch to initialize those variables in mkv_write_header. Also
checking if stream_duration_offset > 0 before writing them as tags in
write_trailer, so it won't be written for webm.

On Tue, Aug 4, 2015 at 6:54 PM, Michael Niedermayer 
wrote:

> On Tue, Aug 04, 2015 at 05:32:51PM -0700, Sasi Inguva wrote:
> > Compute individual stream durations in matroska muxer.
> > Write them as string tags in the same format as mkvmerge tool does.
> >
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/matroskaenc.c| 75
> +---
> >  tests/fate/wavpack.mak   |  4 +--
> >  tests/ref/acodec/tta |  4 +--
> >  tests/ref/fate/binsub-mksenc |  2 +-
> >  tests/ref/lavf/mkv   |  8 ++---
> >  tests/ref/seek/lavf-mkv  | 44 +-
> >  6 files changed, 101 insertions(+), 36 deletions(-)
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index 2d0d5f6..0d3ae37 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -44,6 +44,7 @@
> >  #include "libavutil/mathematics.h"
> >  #include "libavutil/opt.h"
> >  #include "libavutil/random_seed.h"
> > +#include "libavutil/rational.h"
> >  #include "libavutil/samplefmt.h"
> >  #include "libavutil/sha.h"
> >  #include "libavutil/stereo3d.h"
> > @@ -131,6 +132,9 @@ typedef struct MatroskaMuxContext {
> >
> >  int64_t last_track_timestamp[MAX_TRACKS];
> >
> > +int64_t* stream_durations;
> > +int64_t* stream_duration_offsets;
> > +
> >  int allow_raw_vfw;
> >  } MatroskaMuxContext;
> >
> > @@ -1151,12 +1155,12 @@ static int mkv_write_simpletag(AVIOContext *pb,
> AVDictionaryEntry *t)
> >  return 0;
> >  }
> >
> > -static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned
> int elementid,
> > - unsigned int uid, ebml_master *tags)
> > +static int mkv_write_tag_targets(AVFormatContext *s,
> > + unsigned int elementid, unsigned int
> uid,
> > + ebml_master *tags, ebml_master* tag)
> >  {
> >  MatroskaMuxContext *mkv = s->priv_data;
> > -ebml_master tag, targets;
> > -AVDictionaryEntry *t = NULL;
> > +ebml_master targets;
> >  int ret;
> >
> >  if (!tags->pos) {
> > @@ -1166,11 +1170,24 @@ static int mkv_write_tag(AVFormatContext *s,
> AVDictionary *m, unsigned int eleme
> >  *tags = start_ebml_master(s->pb, MATROSKA_ID_TAGS, 0);
> >  }
> >
> > -tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
> > +*tag = start_ebml_master(s->pb, MATROSKA_ID_TAG,0);
> >  targets = start_ebml_master(s->pb, MATROSKA_ID_TAGTARGETS, 0);
> >  if (elementid)
> >  put_ebml_uint(s->pb, elementid, uid);
> >  end_ebml_master(s->pb, targets);
> > +return 0;
> > +}
> > +
> > +static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned
> int elementid,
> > + unsigned int uid, ebml_master *tags)
> > +{
> > +ebml_master tag;
> > +int ret;
> > +AVDictionaryEntry *t = NULL;
> > +
> > +ret = mkv_write_tag_targets(s, elementid, uid, tags, &tag);
> > +if (ret < 0)
> > +return ret;
> >
> >  while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
> >  if (av_strcasecmp(t->key, "title") &&
> > @@ -1220,6 +1237,29 @@ static int mkv_write_tags(AVFormatContext *s)
> >  if (ret < 0) return ret;
> >  }
> >
> > +
> > +mkv->stream_durations = av_mallocz(s->nb_streams * sizeof(int64_t));
> > +mkv->stream_duration_offsets = av_mallocz(s->nb_streams *
> sizeof(int64_t));
>
> this is not called in all cases, for example its not called for
> webm
>
>
> > +
> > +if (!mkv->is_live) {
> > +  for (i = 0; i < s->nb_streams; i++) {
> > +ebml_master tag_target;
> > +ebml_master tag;
> > +
> > +mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID, i +
> 1, &tags, &tag_target);
> > +
> > +tag = start_ebml_master(s->pb, MATROSKA_ID_SIMPLETAG, 0);
> > +put_ebml_string(s->pb, MATROSKA_ID_TAGNAME, "DURATION");
> > +mkv->stream_duration_offsets[i] = avio_tell(s->pb);
> > +
> > +// Reserve space to write duration as a 20-byte string.
> > +// 2 (ebml id) + 1 (data size) + 20 (data)
> > +put_ebml_void(s->pb, 23);
> > +end_ebml_master(s->pb, tag);
> > +end_ebml_master(s->pb, tag_target);
> > +  }
> > +}
> > +
> >  for (i = 0; i < s->nb_chapters; i++) {
> >  AVChapter *ch = s->chapters[i];
> >
> > @@ -1801,6 +1841,9 @@ static int
> mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt, int add_
> >  }
> >
> >  mkv->duration = FFMAX(mkv->duration, ts + duration);
> > +mkv->stream_durations[pkt->stream_index] =
> > +FFMAX(mkv->stream_durations[pkt->stream_index], ts + duration);
> > +
>
> this is called for webm too though
>
> [...]
> --
> Michael GnuPG fing

[FFmpeg-devel] (no subject)

[Sasi Inguva]

Nice catch. Changed the patch to initialize variables in mkv_write_header.
Also checking for duration_offset > 0 before writing them as tags in the end,
to ensure it won't be written for webm.

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