On Thu, Apr 5, 2018 at 2:06 PM, Josh de Kock wrote:
> Thanks, pushed. I also clarified with wm4 on IRC that while he was against
> it he wasn't blocking the muxer if someone else pushes it.
Thank you!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On 4/1/2018 8:26 AM, Paul B Mahol wrote:
> On 3/5/18, Gaullier Nicolas wrote:
>> Hello,
>> I have not received any comment yet on my patchset v3 ("add mono mode" new
>> feature + 4 fixes including a ticket), does it look good to you, could it be
>> committed ?
>>
>> http://ffmpeg.org/pipermail/ffm
On 4/4/2018 8:43 PM, James Almer wrote:
> Data in EbmlBin objects is never changed after being read from the
> input file (save for two specific cases with encoded CodePrivate), so
> using AVBufferRef we can prevent unnecessary copy of data by instead
> creating new references to said constant data
On 4/6/2018 8:30 PM, Michael Niedermayer wrote:
> On Thu, Apr 05, 2018 at 12:32:47PM -0300, James Almer wrote:
>> Newly allocated data buffers (wavpack, prores, compressed buffers)
>> are padded to meet the requirements of AVPacket.
>>
>
>> About 10x speed up in matroska_parse_frame().
>
> thats
On 4/6/2018 8:29 PM, Michael Niedermayer wrote:
> On Thu, Apr 05, 2018 at 12:30:59PM -0300, James Almer wrote:
>> Simplifies code in matroska_parse_frame(). This is in preparation for
>> the following patch.
>>
>> Signed-off-by: James Almer
>> ---
>> Not overloading dst this time...
>>
>> libavfo
On Thu, Apr 05, 2018 at 02:38:03PM +0200, Hendrik Schreiber wrote:
> Hey there,
>
> I have recently switched to using FFmpeg for conversions of 24bit stereo WAV
> to 16bit stereo WAV (with dithering).
>
> For some very large files, I occasionally encountered a segmentation fault in
> _sum2_floa
On Wed, 4 Apr 2018 16:09:35 +0200, Paul B Mahol
wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 8 +
> libavcodec/siren.c | 847
>
On Thu, Apr 05, 2018 at 12:32:47PM -0300, James Almer wrote:
> Newly allocated data buffers (wavpack, prores, compressed buffers)
> are padded to meet the requirements of AVPacket.
>
> About 10x speed up in matroska_parse_frame().
thats a nice speedup
patch seems to work fine
thx
[...]
--
Mic
On Thu, Apr 05, 2018 at 12:30:59PM -0300, James Almer wrote:
> Simplifies code in matroska_parse_frame(). This is in preparation for
> the following patch.
>
> Signed-off-by: James Almer
> ---
> Not overloading dst this time...
>
> libavformat/matroskadec.c | 50
> +
On Wed, 4 Apr 2018 16:09:37 +0200, Paul B Mahol
wrote:
> +} else {
> +ast->codecpar->codec_id = AV_CODEC_ID_SIREN;
> +ast->codecpar->bits_per_coded_sample = 16;
> +ast->codecpar->block_align = 40;
> +ast->codecpar->bit_rate = 6400;
wow great!
now there is o
On Thu, Apr 5, 2018, at 10:17 AM, Lou Logan wrote:
> This seems to confuse Github users into thinking that we may accept pull
> requests. We do not accept pull requests.
>
> Sending patches to the ffmpeg-devel mailing list is our preferred method
> for users to contribute code.
>
> Signed-off-by:
On 6 April 2018 at 17:59, Vittorio Giovara
wrote:
> Yes the order of operations is a problem in a generic matrix, but for a
> display matrix the order is more or less consolidated in a defacto
> standard:
> check for flip first, then rotation. We have the same pattern in h264 and
> hevc decoder f
Yes the order of operations is a problem in a generic matrix, but for a
display matrix the order is more or less consolidated in a defacto standard:
check for flip first, then rotation. We have the same pattern in h264 and
hevc decoder for the rotation side data.
You are right that the description
> >> This breaks the testcase described in
> >> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> >> one you described in this patch.
> >>
> >> I get the following spammed repeatedly:
> >>
> >> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
> >> [m
On 3/28/2018 10:42 AM, James Almer wrote:
> On 3/28/2018 6:59 AM, wm4 wrote:
>> On Tue, 27 Mar 2018 23:11:27 -0300
>> James Almer wrote:
>>
>>> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
>>> index 73b6bd0b14..d06b301fe5 100644
>>> --- a/libavutil/buffer.h
>>> +++ b/libavutil/buffer.h
>>>
On 4/5/2018 12:09 AM, Michael Niedermayer wrote:
This does not work
breaks fate-unknown_layout-ac3
also the tests mayb too strict, there are similar codec_ids like mpeg1/2
or jpeg variants which are all basically the same from a muxers point of view
Revised patch passes FATE. Set looser cond
How to write a ffmpeg-libavfilter filter which outputs a "Hello World
minute:sec" subtitle each second.The filter should produce packets/frames
of subtitles in a AVMEDIA_TYPE_SUBTITLE stream output from the avfilter.The
output from the filter should be passed through the filter chain back into
the
On 4/6/2018 7:25 AM, Alexander Kravchenko wrote:
>>
>> This breaks the testcase described in
>> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
>> one you described in this patch.
>>
>> I get the following spammed repeatedly:
>>
>> [AVHWFramesContext @ 0502d340] Stati
On 6 April 2018 at 12:22, Josh de Kock wrote:
> On 2018/04/05 19:17, Lou Logan wrote:
>
>> This seems to confuse Github users into thinking that we may accept pull
>> requests. We do not accept pull requests.
>>
>> Sending patches to the ffmpeg-devel mailing list is our preferred method
>> for us
On 2018/04/05 19:17, Lou Logan wrote:
This seems to confuse Github users into thinking that we may accept pull
requests. We do not accept pull requests.
Sending patches to the ffmpeg-devel mailing list is our preferred method
for users to contribute code.
Signed-off-by: Lou Logan
---
doc/dev
Dear All,
when var_stream_map option is used, %v must appear either in segment
name template or in the directory path. This latter case currently is
not handled and using delete_segments flag of hls_flags is broken now.
This patch fixes this issue.
The root cause of the bug was that HLSSegment
>
> This breaks the testcase described in
> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> one you described in this patch.
>
> I get the following spammed repeatedly:
>
> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
> [mpeg2video @
On Thu, Apr 5, 2018 at 9:02 PM, James Almer wrote:
> On 4/5/2018 3:25 PM, Lou Logan wrote:
>> On Sun, Mar 25, 2018, at 10:51 PM, Valery Kot wrote:
>>>
>>> Just wondering: is there an active maintainer for avcodec/libopenh264?
>>
>> Doesn't appear to be so.
>>
>>> If yes - can he or she please revi
2018.04.06. 1:34 keltezéssel, wm4 írta:
On Fri, 30 Mar 2018 14:47:25 +0200
Bodecs Bela wrote:
Hi All,
regularly, on different forums and mailing lists a requirement popups
for a feature to automatically failover switching between main input and a
secondary input in case of main input unavai
24 matches
Mail list logo
