On Sun, Nov 5, 2017 at 10:40 PM, Timo Rothenpieler
wrote:
> For once, there should be a good reason to do so.
>
Agreed.
> In case of nvidia the headers in this form is otherwise unobtainable, and
> it's also partially modified specifically for use in ffmpeg.
> Getting the original headers is als
On Sun, Nov 19, 2017 at 4:01 PM, James Darnley wrote:
> ---
> configure | 2 ++
> 1 file changed, 2 insertions(+)
>
LGTM, fixes shared linkage reported on IRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
On Nov 24, 2017 03:01, "Jan Ekström" wrote:
Makes the uninit function re-entrable, which can be a common case
when an API user first tries to initialize its context, fails, and
then finally unrefs the AVHWDevice.
Fixes a crash reported by sm2345 on IRC
Relevant backtrace I received from the us
On Tue, Nov 14, 2017 at 4:05 PM, Mark Thompson wrote:
> This is helpful to know what device has actually been used.
> ---
Change looks alright, and especially in multi-GPU contexts like
laptops this can be quite useful - as you would learn which device you
have just tried to utilize.
Jan
___
Hi,
On Wed, Aug 30, 2017 at 3:08 PM, Clément Bœsch wrote:
> ...
> Thanks to people who review the previous patchset and tested it. If
> someone wants to test without messing with patches, the changes are
> available on github/ubitux/FFmpeg#autodetect.
>
Just got to testing this patch set, and it
Hi,
On Fri, Sep 15, 2017 at 11:04 AM, Tatsuyuki Ishi
wrote:
> Subject: [PATCH] GnuTLS: eat PREMATURE_TERMINATION error
>
> GnuTLS is too strict on the SSL shutdown alert, and it's neither
> mandatory in the spec or critical. As it's ignored in OpenSSL, we
> should also suppress it in GnuTLS as we
On Tue, Sep 26, 2017 at 4:52 AM, Rodger Combs wrote:
> ---
> libavformat/dashenc.c | 13 +
> 1 file changed, 13 insertions(+)
LGTM.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Oct 16, 2017 at 7:31 PM, James Almer wrote:
> On 10/14/2017 12:59 PM, James Almer wrote:
>> It's used by every library, and by making it global we simplify a lot
>> of checks.
>>
LGTM.
I dislike the fact that we have to fix issues caused by 3rd party
libraries' pkg-config files but at th
On Tue, Oct 17, 2017 at 12:38 AM, Hendrik Leppkes wrote:
> Perhaps such libraries shouldn't hardcode -lstdc++ in there, but
> dynamically put whichever C++ library they built against in there
> instead?
> Its not like you can actually use a static library build with another
> C++ library, that *ma
On Mon, Oct 16, 2017 at 11:01 PM, Jan Ekström wrote:
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index b9a3a9bc1f..5aa642a9bb 100755
> --- a/configure
> +++ b/configure
> @@ -6254,7 +6254,8 @@ EOF
> fi
> check_header sound
> Please apply.
Got my key registered onto the system and pushed along with an update
to the commit message noting the static linking use case.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, Oct 19, 2017 at 10:39 AM, Rodger Combs wrote:
> ---
Seems like a valid change to enable the following change of enabling
probing in movdec for mp2/3 in ISOBMFF.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Thu, Oct 19, 2017 at 10:39 AM, Rodger Combs wrote:
> ---
> libavformat/isom.c | 2 ++
> 1 file changed, 2 insertions(+)
This change makes sense due to the ambiguousness of the container mapping. LGTM.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@
Hi,
On Fri, Oct 20, 2017 at 10:39 AM, Shengbin Meng wrote:
> Hi,
>
> I’d like to know if anyone is dong or interested in ARM optimization for the
> native HEVC decoder in FFmpeg?
>
Of course we are interested in optimizations. An example of how they
can be integrated is available @
http://git.v
On Fri, Oct 20, 2017 at 10:26 AM, Mateusz wrote:
> W dniu 2017-10-06 o 17:33, Mateusz pisze:
>> Fixed DITHER_COPY macro (only C code), updated FATE tests.
>>
>> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is
>> there.
>
> Ping.
Hi,
The updated PSNR values look really
On Tue, Oct 17, 2017 at 11:29 AM, Daniel Kucera wrote:
> transfer_func variable passed to retry_transfer_wrapper
> are h->prot->url_read and h->prot->url_write functions.
> These need to return EOF or other error properly.
> In case of returning >= 0, url_read/url_write is retried
> until error is
On Tue, Oct 24, 2017 at 8:57 PM, Nicolas George wrote:
> Le duodi 2 brumaire, an CCXXVI, James Almer a écrit :
>> https://trac.ffmpeg.org/ticket/6767
>
> I do not see in this ticket anything that allows to reproduce the issue
> without a huge amount of foreign code.
>
> Regards,
Hi,
The base ide
On Tue, Oct 24, 2017 at 9:18 PM, Jan Ekstrom wrote:
> This is a public API change, and I'm not sure if we were planning on
> this. I am not against the fact that zero is no longer implictly EOF,
> but this might have been worth a bit more notice as this does indeed
> break quite
On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George wrote:
> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> I do not consider this a public API change because 0 was never
> documented as a valid return value for a read_packet callback, while
> AVERROR_EOF has been around for
On Tue, Oct 24, 2017 at 10:43 PM, James Almer wrote:
> Maybe first ask what the workaround Nicolas mentioned is about?
This was not meant to push anything on anyone. Just wanted to let him
know what had been come up with elsewhere.
> And preferably don't quote me on this subject. This is not my
On Wed, Oct 25, 2017 at 11:22 AM, Nicolas George wrote:
> Print a warning to let applicatios fix their use.
> After a deprecation period, check with a low-level assert.
> Also make the constraint explicit in the doxygen comment.
>
> Signed-off-by: Nicolas George
Thanks for the patch.
> ---
> l
On Wed, Oct 25, 2017 at 11:22 AM, Nicolas George wrote:
> +static int read_packet_wrapper(AVIOContext *s, uint8_t *buf, int size)
> +{
> +int ret;
> +
> +if (!s->read_packet)
> +return AVERROR_EOF;
> +ret = s->read_packet(s->opaque, buf, size);
> +#if FF_API_OLD_AVIO_EOF_0
> +
On Fri, Oct 27, 2017 at 9:33 PM, Nicolas George wrote:
> It is standard parlance in networking: stream protocols produce a stream
> of octets, without any additional structure, while packet protocols
> produce packets, which are delimited at protocol level and visible by
> the application, and can
On Fri, Oct 27, 2017 at 9:46 PM, Nicolas George wrote:
> Print a warning to let applicatios fix their use.
> After a deprecation period, check with a low-level assert.
> Also make the constraint explicit in the doxygen comment.
Difference to the previous version:
> -av_log(s, AV_LOG_WARNI
On Fri, Oct 27, 2017 at 9:46 PM, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
LGTM
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Oct 27, 2017 at 9:46 PM, Nicolas George wrote:
> Signed-off-by: Nicolas George
LGTM
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Oct 27, 2017 at 9:56 PM, Jan Ekstrom wrote:
> On Fri, Oct 27, 2017 at 9:46 PM, Nicolas George wrote:
>> Print a warning to let applicatios fix their use.
>> After a deprecation period, check with a low-level assert.
>> Also make the constraint explicit i
On Mon, Oct 30, 2017 at 9:51 PM, Mark Thompson wrote:
> PPS:
>
> The position stated above would imply removing the avisynth headers. Can
> anyone who uses it comment on what would be required for that?
Avisynth headers are available from the Avisynth SDK that comes with
each installer of Avisy
On Mon, Oct 31, 2016 at 5:30 PM, Nicolas George wrote:
> Le nonidi 9 brumaire, an CCXXV, Steven Liu a écrit :
>> I saw ffmpeg have no HDS and DASH demuxer, and all of them's format is
>> use xml, maybe this parser is a very useful parser, what about the basic
>> xml :-D
>
> The Timed Text Mar
On Sun, Nov 13, 2016 at 9:48 AM, Carlos Fernandez Sanz
wrote:
> One of the reasons apparently for not merging the SCTE-35 patch;
> better never include that in ffmpeg and have the professional use and
> pay for other products even though an implementation that doesn't
> break anything at that has
On Fri, Oct 21, 2016 at 6:32 PM, Derek Buitenhuis
wrote:
> The design one fist: This approach is fundamentally wrong. Edit lists are
> meant to be applied at presentation level, not packet level. The current
> implementation will cause problems in a number of cases:
>
> * Audio packets. Especi
On Sep 26, 2016 09:29, "Carl Eugen Hoyos" wrote:
>
> 2016-09-26 1:52 GMT+02:00 Jan Ekström :
>
> If this fixes anything (I am not sure I understand: Are you changing a
> type which introduces a possible undefined behaviour, so you add an
> additional check at the same time?) it should be part of a
On Sep 26, 2016 04:05, "Marton Balint" wrote:
>
> Overriding width/height with display width/height does not seem right, check
> what happens with a PAL IMX50 MXF file for example. If you want to signal
> this, then a stream side data with some AVPanScan values might make more
> sense.
>
Such
On Sun, Mar 20, 2016 at 3:28 PM, Michael Niedermayer
wrote:
> On Sat, Mar 19, 2016 at 07:39:07PM +0200, Jan Ekström wrote:
>> As far as can be seen, this value is supposed to be the DTS of a
>> fragment in smooth streaming. Thus, don't take b-picture delay and
>> such into mention when calculating
Hi,
On Sun, Apr 10, 2016 at 10:13 PM, Michael Niedermayer
wrote:
> This is not about changing a bad encoder to a good encoder, this patch
> is about removing choices.
> Before this patch users can force libfaac and have twice as long
> battery life at lower quality after the patch the users do no
On Sun, Apr 17, 2016 at 6:25 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4637 for me.
>
> Please comment, Carl Eugen
Hi,
Can you please explain the difference between these two YCbCr-to-RGB
conversion functions?
The result, if it is now black, seems to match what MPC-HC's
On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
wrote:
> In particular, I have an uncomfortable suspicion that
> PGS might be designed to match the movie's colour space,
> in which case neither variant would give correct results
> but instead it would have to depend on what format the
> correspo
On Sun, Apr 17, 2016 at 9:44 PM, wm4 wrote:
>
> Ah that's funny. This indeed ruins everything. It looks like subtitle
> decoders should simply output YUV, and until we can fix it, a private
> option could change between the colorspaces?
Well, the colorimetry is at least specified as per the resol
On Sun, Apr 17, 2016 at 9:55 PM, Reimar Döffinger
wrote:
> ?!???
> These two kind of contradict each other, at least if the HDMV video
> stream uses a full range color matrix (or is that not allowed?).
Just poked at this and it seems indeed that the following values are
set for the resolution pro
On Sun, Apr 17, 2016 at 10:08 PM, Carl Eugen Hoyos wrote:
>
> Does attached make it better?
So the difference between the two conversion functions is that one is
Rec.601 in limited range, and the other is Rec.709 in limited range?
If so, that seems correct. The actual coded width/height of "625/5
On Tue, Apr 19, 2016 at 3:15 PM, Carl Eugen Hoyos wrote:
> Could you explain how I can reproduce the incompleteness?
> Visibly if possible...
It seems right now that we have a function (macro) to convert
(seemingly limited range?) YCbCr to limited range or full range RGB,
both (seemingly) followi
On Sat, Apr 23, 2016 at 2:53 PM, Hendrik Leppkes wrote:
> Otherwise, I think Carl's suggestion might help, PGS subtitles are
> generally from Blu-rays, which means most of it is HD, so swapping the
> flag to detect SD conditions might make it act more "appropriate" in
> absence of w/h.
The defaul
On Sat, Apr 23, 2016 at 11:09 AM, Carl Eugen Hoyos wrote:
> Please mention the relevant ticket in the commit message.
OK, will do.
>
>> +int hdtv;
>
> Please rename to sdtv so you can remove the assignment from
> init_decoder().
>
What would that make of the default value? The current desig
On Sat, Apr 23, 2016 at 3:21 PM, wm4 wrote:
> In that case the hdtv field should be completely removed, and the test
> put in the palette conversion code.
>
If avctx->height is by default 0, then it would have to be something a la:
if (!avctx->height || avctx->height > 576) {
YUV_TO_RGB1_CCI
On Wed, May 18, 2016 at 9:40 PM, Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi | 29 +
> 1 file changed, 29 insertions(+)
>
I agree to this addition. I think having this is a good initial
stepping stone for any future im
On Sat, Feb 11, 2017 at 1:21 AM, Jan Ekström wrote:
> ...
>
Poked Martin about this last night, and his comment was:
`<@wbs> JEEB: doesn't look harmful to me, so no objection`
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/
On Fri, Mar 3, 2017 at 4:38 AM, Ben Chang wrote:
>
> In short, is there any way to transfer meta data between a decode and encode
> context in transcode scenario? If not, would it be supported in foreseeable
> future?
>
Hi,
AVFrames do contain fields for:
* color_primaries
* color_trc
* colors
On Tue, Mar 7, 2017 at 12:44 AM, Marton Balint wrote:
> I guess you meant to convert this to -x264-params as well, no?
>
> Thanks,
> Marton
Yup, welcome to doing things after midnight.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On Tue, Mar 7, 2017 at 5:24 AM, Michael Niedermayer
wrote:
> On Tue, Mar 07, 2017 at 12:20:20AM +0200, Jan Ekström wrote:
>> x264-params does the same thing and this leaves us with a single
>> option that is name-matched with x265-params available in the
>> libx265 wrapper.
>> ---
>> libavcodec/l
On Wed, Mar 8, 2017 at 1:01 AM, Michael Niedermayer
wrote:
> the fast pskip i mentioned yesterday
>
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params
> fast-pskip -vframes 15 -an ref-p.nut
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params
> n
On Wed, Mar 8, 2017 at 10:23 PM, Toepfer, Randall wrote:
> Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not
> does FFMPEG support this?
>
> http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression
>
From the document "Call for Proposals for Point Cloud
On Mon, Jun 26, 2017 at 5:09 PM, Paul B Mahol wrote:
> Rationale:
> prores_ks have more features and is faster for qscale > 0
> and gives better quality output.
>
You probably meant s/avfilter/avcodec/ :) All those filters you've
made have put a template in your mind ;) .
Generally LGTM for me.
On Mon, Jun 26, 2017 at 5:09 PM, Paul B Mahol wrote:
> Rationale:
> - Slower then other encoder
> - Less configurable
> - Does not support alpha profile
> - Does not set interlaced flag
> - Worse output quality
> - No need for 2 encoders
>
I agree with this clean-up. Probably needs an API/ABI bum
Hi,
On Mon, Jun 26, 2017 at 2:12 PM, Paul B Mahol wrote:
>
> Yes it is.
As the output is verified to be bit-exact, this is LGTM for me (as
someone who has poked this format's dec/enc in the past).
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Tue, Jul 18, 2017 at 10:33 PM, Vittorio Giovara
wrote:
> Based off mpv automatic tonemapping capabilities.
Cool stuff, will have to test this soon. Thanks for putting an example
in the docs.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hi,
On Tue, Aug 1, 2017 at 3:22 PM, David Griffiths
wrote:
> Given an MPEG1/2 stream, this bitstream filter can be used to modify
> the sequence headers. The most common use would be to change the
> aspect ration without the need for re-encoding. Some MOD files have
> the aspect ratio incorrectly
Hi,
On Wed, Nov 18, 2015 at 9:28 PM, Zach Swena wrote:
> Are you referring to this seperate applciation?
>
> https://github.com/mmalecki/multicat/blob/master/trunk/README
>
Probably what was meant was
http://www.videolan.org/projects/multicat.html , but that might be a
git svn clone of it.
>
>
On Mon, Dec 14, 2015 at 10:48 PM, compn wrote:
> dumb question
>
> are these encrypted mp4 files some kind of standard encryption?
>
> rephrased... will encrypted files created by ffmpeg be able to be
> decrypted/decoded and played by quicktime? or any other player?
> (assuming other player ha
Hi,
In general looks good, although it might look a bit weird for someone
as usually libraries have initialization functions called like that.
That said, this is what
https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
recommends.
My only comment would be that we might wa
59 matches
Mail list logo
