On Tue, May 21, 2024 at 9:52 PM Lynne via ffmpeg-devel
wrote:
>
>
> It should be the case here, we shouldn't need reordering as NATIVE just
> lets you specify what order the elements appear in the bitstream.
NATIVE means "the FFmpeg native ordering", not "bitstream order".
CUSTOM lets you specify
On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
>
> segmentation.update_map is never reset to 0 on a new frame, and retains
> the value from the previous frame. This bugs out a bunch of hwaccel
> drivers when segmentation.enabled is 0 but update_map isn't because
> they don't ignore values behind swi
On Wed, May 22, 2024 at 7:16 PM Lynne via ffmpeg-devel
wrote:
>
> On 22/05/2024 18:17, Philip Langdale via ffmpeg-devel wrote:
> > On Wed, 22 May 2024 11:10:31 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, May 22
On Thu, May 23, 2024 at 10:38 AM wrote:
>
> From: llyyr
>
> Fields under the segmentation switch are never reset on a new frame, and
> retain the value from the previous frame. This bugs out a bunch of
> hwaccel drivers when segmentation is disabled but update_map isn't
> reset because they don't
On Thu, May 30, 2024 at 11:50 AM Tomas Härdin wrote:
>
> tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont:
> > Can't we just use the compiler built-ins here? AFAIK, they (GCC,
> > LLVM) use the same algorithm if the CPU doesn't support native CTZ.
> > And they will pick the right instr
On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
>
> instead of just resyncing and skipping a bunch of TS packets, leading to
> a loss of frames.
>
> Before this, a stray byte with the value of 0x47 in TP_extra_header
> would throw off the detection of where TS packets start.
>
> A typical file that c
On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes wrote:
>
> On Mon, May 27, 2024 at 3:47 PM llyyr wrote:
> >
> > instead of just resyncing and skipping a bunch of TS packets, leading to
> > a loss of frames.
> >
> > Before this, a stray byte with the value
On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili wrote:
>
>
>
> > On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2024-06-17 07:19:26)
> >> From: Zhao Zhili
> >>
> >> When thread_count be zero, it will be run on current thread like
> >> !HAVE_THREADS.
> >
> > Other APIs tr
On Sat, Mar 23, 2024 at 12:14 PM Marton Balint wrote:
> +char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
> +{
> +if (ts == AV_NOPTS_VALUE) {
> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> +} else {
> +double val = av_q2d(tb) * ts;
> +double
On Mon, Jun 24, 2024 at 8:32 AM wrote:
>
> From: Fei Wang
>
> Otherwise, slice index will never update for hwaccel decode, and slice
> RPL will be always overlap into first one which use slice index to construct.
>
> Fixes hwaccel decoding after 47d34ba7fbb81
>
> Signed-off-by: Fei Wang
> ---
>
On Sat, Sep 25, 2021 at 5:00 AM Soft Works wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Soft Works
> > Sent: Friday, 24 September 2021 19:03
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8
On Wed, Oct 6, 2021 at 8:45 AM Soft Works wrote:
> diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
> index 10cf79dff1..42ed8deb13 100644
> --- a/libavcodec/codec_par.h
> +++ b/libavcodec/codec_par.h
> @@ -198,6 +198,10 @@ typedef struct AVCodecParameters {
> * Audio only. Number
On Sat, Oct 9, 2021 at 5:14 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/internal.h | 7 +++
> libavformat/mux.c | 11 ++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal
On Sat, Nov 6, 2021 at 6:26 AM wrote:
>
> On Fri, Nov 05, 2021 at 10:00:41PM +0100, Michael Niedermayer wrote:
> > On Fri, Nov 05, 2021 at 08:32:16PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavutil/slicethread.c | 2 +-
On Sun, Nov 7, 2021 at 3:33 PM Marton Balint wrote:
>
>
>
> On Tue, 2 Nov 2021, Eran Kornblau wrote:
>
> > Hi all,
> >
> > The attached patch makes the default behavior of caching HTTP redirects
> > optional.
>
> Is caching a redirected URL allowed per the HTTP spec? If not, then no
> caching sho
On Fri, Nov 12, 2021 at 2:35 PM Anton Khirnov wrote:
>
> There is no reason to wrap them in #ifndef guards, they should only be
> defined here and nowhere else. The define guards just add the
> possibility to accidentally use the same FF_API name in different
> libraries.
Wasn't the idea here tha
On Fri, Nov 12, 2021 at 5:47 PM Anton Khirnov wrote:
>
> Quoting James Almer (2021-11-12 17:36:58)
> > On 11/12/2021 1:32 PM, Anton Khirnov wrote:
> > > Also add a function to retrieve that class, analogously to
> > > avformat_get_class().
> > >
> > > This will be useful for adding an AVOption for
On Sun, Nov 14, 2021 at 3:40 AM Ridley Combs wrote:
>
>
>
> > On Nov 13, 2021, at 18:38, Marvin Scholz wrote:
> >
> > On 13 Nov 2021, at 22:09, rcombs wrote:
> >
> >> This is required for VP9 to work.
> >> ---
> >> libavcodec/videotoolbox.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
>
On Tue, Nov 23, 2021 at 6:19 AM Gyan Doshi wrote:
>
>
>
> On 2021-11-23 01:50 am, Michael Niedermayer wrote:
> > On Mon, Nov 22, 2021 at 10:23:35PM +0530, Gyan Doshi wrote:
> >>
> >> On 2021-11-22 09:49 pm, Michael Niedermayer wrote:
> >>> On Mon, Nov 22, 2021 at 08:36:30PM +0530, Gyan Doshi wrote
On Tue, Nov 23, 2021 at 11:31 AM Anton Khirnov wrote:
>
> This flag allows distinguishing between filters that actually modify the
> data and those that only modify metadata or gather some stream
> information.
A "meta" filter has me associate it with other concepts, maybe
spelling out "metadata"
On Thu, Nov 25, 2021 at 1:12 PM Soft Works wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of James
> > Almer
> > Sent: Thursday, November 25, 2021 11:52 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v15 00/16] *** SUBJ
On Fri, Nov 26, 2021 at 4:09 PM Andreas Rheinhardt
wrote:
>
> Soft Works:
> > Also introduce deferred loading of ass headers for all cases where it can't
> > be taken from the context of a decoder.
>
> This should be a commit of its own.
>
> >
> > Signed-off-by: softworkz
> > ---
> > libavcodec
On Thu, Dec 2, 2021 at 2:20 PM wrote:
>
> From: Limin Wang
>
> Old system is:
> OSX version: 10.11.6
> Apple LLVM version 8.0.0 (clang-800.0.42.1)
> Target: x86_64-apple-darwin15.6.0
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/videotoolbox.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 d
On Thu, Dec 2, 2021 at 7:13 PM Andreas Rheinhardt
wrote:
>
> Lynne:
> > The issue is that if ffmpeg is compiled without Vulkan, and an API
> > user includes and uses the functions exposed in hwcontext_vulkan.h,
> > then a linking error will happen, as the hwcontext_vulkan.c file has
> > not been c
On Thu, Dec 2, 2021 at 7:13 PM Andreas Rheinhardt
wrote:
> 2. And even if not: Actually compiling the whole implementation is
> unnecessary; in such cases we typically #if everything away (e.g. in
> your case: it will always return NULL).
> 3. The hwcontext_vulkan.h header requires vulkan system h
On Sat, Dec 4, 2021 at 9:00 PM Marton Balint wrote:
>
> Otherwise there is no way to detect any error during avio_close().
>
Returning errors is nice and all, but whats the expected reaction to
an error here, since we're already trying to close? Can't exactly
close and go home (since thats what y
On Sun, Dec 5, 2021 at 5:40 PM Lynne wrote:
> > +/**
> > + * Usually the same as packet pts, in AV_TIME_BASE.
> > + *
> > + * @deprecated This is kept for compatibility reasons and corresponds
> > to
> > + * AVSubtitle->pts. Might be removed in the future.
> > + */
> > +
On Sat, Oct 14, 2023 at 6:02 AM xyz1001 wrote:
>
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
> ---
> libavcodec/dxva2.c | 3 ++-
> 1 file changed, 2 in
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
>
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount o
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
>
> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >
> > This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> > "Channel
> > Configuration 14", and it being t
On Tue, Oct 24, 2023 at 1:57 AM James Almer wrote:
>
> On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
> >>
> >> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >>>
> >>> This lay
On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer
wrote:
>
> On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote:
> > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit :
> > > > That's not a credible solution for a library. All reverse dependency
> > > > d
On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote:
>
> Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> > that said, i checked ML subscribers and found
> > 16 of the people above to be currently subscribed with email addresses
> > that i found by greping their
(vf_tonemap_opencl maintainer, added SIMD code to
> >> various bits of code, last active in git in 2020)
> >> John Stebbins (over 100 commits in FFmpeg, last active in git in
> >> 2020, 1 copyright match)
> >> Tobias Rapp(vf_readvitc mainatiner, last
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4
> 4 files changed, 24 inser
On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
wrote:
>
> Gurd against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd
On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
wrote:
>
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65df
On Tue, Mar 26, 2019 at 11:32 AM Carl Eugen Hoyos wrote:
>
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/get_bits.h | 82 +
> > libavcodec/utvideodec.c | 4 +-
> > 2 files changed, 60 insertions(+),
On Sat, Mar 30, 2019 at 2:52 PM Gyan wrote:
>
>
>
> On 30-03-2019 06:09 PM, Moritz Barsnick wrote:
> > On Sat, Mar 30, 2019 at 16:50:52 +0530, Gyan wrote:
> >> And what are the semantics of the user setting row_mt or enable-intrabc
> >> as -1?
> > The user doesn't set -1, they set 0 or 1 as bool.
On Mon, Apr 1, 2019 at 7:21 PM Yufei He wrote:
>
> Hi
>
> There may be a bug for .mp4 reader.
>
> On decoding some ntsc mp4 files with my h.264 codec, from actvx I received,
>
> avctx->framerate.den is 100
>
> avctx->framerate.num is 2997
>
> avctx->pkt_timebase.num is 1
> avctx->pkt_timebase.den
On Tue, Apr 2, 2019 at 1:27 PM Gyan wrote:
>
> I ran full fate and some tests failed as the ffmpeg binary wasn't found.
> Suffixes weren't respected. Fixed.
>
> I can run fate only occasionally. Maybe one of the regular FATE
> submitters could set a suffix (and extension) to keep a check on this.
On Mon, Apr 1, 2019 at 4:59 PM James Almer wrote:
>
> On 4/1/2019 9:13 AM, Lynne wrote:
> > Mar 31, 2019, 11:49 PM by jamr...@gmail.com:
> >
> >> A float ret value needs to be in xmm0, and you swapped m0 with m2 on
> >> Win64. This is the source of the fate failure.
> >>
> > Attached a patch to fi
On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> Up until now, the writing process for level 1 elements (those elements
> for which CRC-32 elements are written by default) was this in case the
> output was seekable: Write the EBML ID, write an "unkown length" EBML
> nu
On Tue, Apr 2, 2019 at 5:55 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> Hello,
>
> thanks for taking a look at this.
>
> Hendrik Leppkes:
> > On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> > wrote:
> >>
> >> Up unt
On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
> @@ -383,8 +388,8 @@ static void end_ebml_master_crc32_preliminary(AVIOContext
> *pb, AVIOContext **dyn
> uint8_t *buf;
> int size = avio_get_dyn_buf(*dyn_cp, &buf);
>
> +put_ebml_num(pb, size, master
On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
wrote:
>
> ---
> libavcodec/cbs_h2645.c | 28 ++--
> libavcodec/extract_extradata_bsf.c | 4 ++--
> libavcodec/h2645_parse.c | 6 +++---
> libavcodec/h2645_parse.h | 6 +++---
> libavcode
On Wed, Apr 3, 2019 at 2:28 PM Carl Eugen Hoyos wrote:
>
> 2019-04-03 11:37 GMT+02:00, Hendrik Leppkes :
>
> > We prefer not to expose huge modules like this as avpriv,
> > as it makes it part of the ABI
>
> (I am sure there are cases that are difficult to avoid,
> w
On Wed, Apr 3, 2019 at 10:42 PM Marton Balint wrote:
>
> Signed-off-by: Marton Balint
> ---
> doc/protocols.texi | 9 +
> libavformat/file.c | 5 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index e1caa049a5..34967ff5e2 100644
> ---
The transcode() helper function will already prepend the TARGET_PATH to
the sample path, if its a relative path. This avoids an issue on
Windows, where the relative path check could fail.
---
tests/fate/ffmpeg.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/ffmpe
On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavform
On Thu, Apr 4, 2019 at 3:05 PM Andreas Rheinhardt via ffmpeg-devel
wrote:
>
> And I think that this memleak in mkv_write_trailer() has a twin in
> mkv_write_packet(): Audio frames are not written directly, but rather
> put into storage in cur_audio_pkt via av_packet_ref(). But if the
> preceding a
On Mon, Apr 8, 2019 at 10:54 AM Zachary Zhou wrote:
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/li
On Sat, Apr 6, 2019 at 6:42 PM Balint Marton wrote:
>
> Hi All
>
> Here is a call for the people in the voting committee [1] on the decision
> of extending it.
>
> Using the same guidelines as in the second extension [2], the following
> candidates were found:
>
> git log libav/master..master --no
On Wed, Apr 10, 2019 at 12:21 AM Baptiste Coudurier
wrote:
> +return 0;
> +}
> +init_get_bits(&gb, tmp, tmp_size*8);
> +ret = avpriv_h264_decode_seq_parameter_set(&gb,
> (AVCodecContext*)s, &ps, 0);
The AVCodecContext cast looks like a recipe f
On Wed, Apr 10, 2019 at 12:44 AM Mark Thompson wrote:
>
> On 09/04/2019 23:14, Baptiste Coudurier wrote:
> > ---
> > libavcodec/h264_parse.c | 2 +-
> > libavcodec/h264_parser.c | 2 +-
> > libavcodec/h264_ps.c | 4 ++--
> > libavcodec/h264_ps.h | 4 ++--
> > libavcodec/h264dec.c | 6
On Wed, Apr 10, 2019 at 2:21 AM Aman Gupta wrote:
>
> From: Aman Gupta
>
> Previously, the initial seek position was recorded into
> old_offset at the beginning of avformat_find_stream_info(),
> and passed into estimate_timings(). In the case of mpegts
> with a known filesize, it was further pass
On Wed, Apr 10, 2019 at 3:28 AM James Almer wrote:
> >
> >> Two thirds of SPS is not hard to implement, so i really don't understand
> >> why you're so adamantly against it.
> >
> > I’m adamant about re-using code between libavcodec and libavformat.
> > Re-using code is _good_
>
> So lets do what
On Wed, Apr 10, 2019 at 9:55 AM Aman Gupta wrote:
>
> On Tue, Apr 9, 2019 at 9:49 PM Hendrik Leppkes wrote:
>
> > On Wed, Apr 10, 2019 at 2:21 AM Aman Gupta wrote:
> > >
> > > From: Aman Gupta
> > >
> > > Previously, the initial seek position
On Thu, Apr 11, 2019 at 12:39 AM Lukas Rusak wrote:
>
> This will allow applications to properly init the decoder in
> cases where a hardware decoder is tried first and and software
> decoder is tried after by calling the get_format callback.
>
> Even though there is no hardware pixel formats avai
On Thu, Apr 11, 2019 at 4:51 AM Li, Zhong wrote:
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Linjie Fu
> > Sent: Wednesday, April 10, 2019 7:56 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH, v2] lavu/hwcontext_qsv:
On Thu, Apr 11, 2019 at 7:47 PM Peter F wrote:
>
> Hi,
>
> Am Do., 11. Apr. 2019 um 00:50 Uhr schrieb Hendrik Leppkes
> :
> >
> > On Thu, Apr 11, 2019 at 12:39 AM Lukas Rusak wrote:
> > >
> > > This will allow applications to properly init the decod
On Sat, Apr 13, 2019 at 1:17 AM Lukas Rusak wrote:
>
> On Thu, 2019-04-11 at 21:03 +0200, Hendrik Leppkes wrote:
> > On Thu, Apr 11, 2019 at 7:47 PM Peter F
> > wrote:
> > > Hi,
> > >
> > > Am Do., 11. Apr. 2019 um 00:50 Uhr schrieb Hendrik Leppkes
On Sun, Apr 14, 2019 at 6:50 PM Gyan wrote:
>
> Implemented this patch
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241733.html
>
>
> in libavcodec as suggested by Michael
>
This sure adds a lot of additional fields to the main struct for a
rather specialized feature, that I person
On Mon, Apr 15, 2019 at 8:17 AM Gyan wrote:
>
>
>
> On 15-04-2019 12:17 AM, James Almer wrote:
> > On 4/14/2019 3:29 PM, Hendrik Leppkes wrote:
> >> On Sun, Apr 14, 2019 at 6:50 PM Gyan wrote:
> >>> Implemented this patch
> >>> http://www.ffmpe
On Mon, Apr 15, 2019 at 12:46 PM Carl Eugen Hoyos wrote:
>
> 2019-04-15 9:42 GMT+02:00, Liu Steven :
> >
> >
> >> 在 2019年4月11日，下午12:03，Liu Steven 写道：
> >>
> >>
> >>
> >>> 在 2019年4月11日，上午11:55，Jun Li 写道：
> >>> ...
> >>>
> >>> Ping.
> >> LGTM
> >
> > Pushed
>
> Who wrote the patch that you pushed?
On Tue, Apr 16, 2019 at 7:57 AM Jun Zhao wrote:
>
> From: Jun Zhao
>
> commit abfeba9 "lavf/hls: Cleanup the applehttp" missed
> the version bump and Changelog entry.
>
> Signed-off-by: Jun Zhao
> ---
> Changelog |1 +
> libavformat/version.h |2 +-
> 2 files changed, 2 inse
On Tue, Apr 16, 2019 at 10:58 AM Carl Eugen Hoyos wrote:
>
> 2019-04-16 10:52 GMT+02:00, myp...@gmail.com :
> > On Tue, Apr 16, 2019 at 4:42 PM Hendrik Leppkes wrote:
> >>
> >> On Tue, Apr 16, 2019 at 7:57 AM Jun Zhao wrote:
> >> >
> >> >
On Thu, Apr 18, 2019 at 12:41 PM Gyan wrote:
>
>
>
> On 18-04-2019 03:25 PM, Timo Rothenpieler wrote:
> > On 18/04/2019 09:49, Gyan wrote:
> >>
> >> Patchwork can incorrectly assign ownership. See
> >> https://patchwork.ffmpeg.org/patch/12680/
> >>
> >> The author is Sam John as identified by Mess
On Thu, Apr 18, 2019 at 2:54 PM Lauri Kasanen wrote:
>
> On Thu, 18 Apr 2019 13:53:37 +0200
> Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > Attached patch silences a warning that is shown with some gcc versions.
>
> It pokes my style sense to have different things in the sizeof() and
> the var. How a
On Thu, Apr 18, 2019 at 3:31 PM Gyan wrote:
>
>
>
> On 18-04-2019 06:13 PM, Hendrik Leppkes wrote:
> > On Thu, Apr 18, 2019 at 12:41 PM Gyan wrote:
> >> Ok. Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author?
> >> It did do tha
On Thu, Apr 18, 2019 at 9:04 PM Lou Logan wrote:
>
> On Thu, Apr 18, 2019, at 4:51 AM, Hendrik Leppkes wrote:
> >
> > Whoever setup this ML sender rewriting thing should probably look into
> > options to also re-write the patch content and add a "From:" line i
On Fri, Apr 5, 2019 at 12:06 AM James Almer wrote:
>
> On 4/3/2019 7:17 PM, Hendrik Leppkes wrote:
> > The transcode() helper function will already prepend the TARGET_PATH to
> > the sample path, if its a relative path. This avoids an issue on
> > Windows, where the relati
On Fri, Apr 19, 2019 at 8:23 PM Lou Logan wrote:
>
> On Thu, 18 Apr 2019 18:01:27 -0400
> "Lou Logan" wrote:
> >
> > But we can certainly give it a try if you like. I'm not sure how patchwork
> > will handle it.
>
> (Didn't realize my webmail client wasn't actually wrapping my text
> although it
On Thu, Apr 25, 2019 at 7:25 PM Nicolas George wrote:
>
> Paul B Mahol (12019-04-25):
> > I did reacted. It plays well with negotiation.
>
> I missed that part, sorry. But it did not address my concern.
>
> > Can you be more specific what exactly you mean by "plays well with
> > sample rate negoti
On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
wrote:
>
> On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
> >
> >
> > On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> > >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> > >> mux.c |9 -
> > >> 1 file changed, 8 i
On Mon, Apr 29, 2019 at 2:39 PM Menno de Gier wrote:
>
> Some ADTS files have a first frame that's shorter than the 10 bytes that
> are being read while checking for ID3 tags.
>
> Fixes #7271
>
James already send another patch for this issue -
https://patchwork.ffmpeg.org/patch/12913/ - which see
On Mon, Apr 29, 2019 at 8:35 PM Marton Balint wrote:
> We can't really change this for the better unless there is a somewhat
> "recognized" authority which has the power to make decisions, rules, and
> enforce them.
>
> I hoped that this can be the voting comitte.
The voting commitee is pretty mu
On Thu, May 2, 2019 at 7:42 PM Sasi Inguva
wrote:
>
> Looks good to me. We were already doing PTS based seeking in MOV demuxer
> (although it's not perfect).
>
There are several problems with the MOV approach however. You cannot
look at AVStream->index_entries, take a timestamp of such an index,
On Sat, May 4, 2019 at 10:52 AM Shivam Goyal wrote:
>
> The improved patch is for ticket #5154.
>
> Support for Raw h264 stream from Arecont Camera.
>
> Suggest any changes required.
>
The format-name based check in ff_raw_read_partial_packet is really
iffy. You can setup a specific read function
On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos wrote:
>
> Hi!
>
> Attached patch fixes ticket #7871 without re-introducing #7816.
>
There is no patch here. However, please note that its perfectly valid
to have a username without a password (ie. an @ without a ":") - while
it is not valid to have
On Sun, May 5, 2019 at 8:51 PM Marton Balint wrote:
>
> This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
>
> I don't think it is a good idea to drop frames from CFR input just because
> they
> are duplicated, that can cause issues for API users expecting CFR input. Also
> it can caus
On Sun, May 5, 2019 at 9:47 PM Carl Eugen Hoyos wrote:
>
> Am So., 5. Mai 2019 um 21:18 Uhr schrieb Hendrik Leppkes
> :
> >
> > On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos wrote:
> > >
> > > Hi!
> > >
> > > Attached patch fixes ticke
On Tue, May 7, 2019 at 12:34 AM Michael Niedermayer
wrote:
>
> On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote:
> > This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
> >
> > I don't think it is a good idea to drop frames from CFR input just because
> > they
> > are dupli
On Tue, May 7, 2019 at 1:39 AM Hendrik Leppkes wrote:
>
> On Tue, May 7, 2019 at 12:34 AM Michael Niedermayer
> wrote:
> >
> > On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote:
> > > This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
> >
On Sun, May 12, 2019 at 10:38 PM Carl Eugen Hoyos wrote:
>
> Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> >
> > On 5/12/19, Carl Eugen Hoyos wrote:
> > > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> > >>
> > >> Patch updated again.
> > >> Made some more cleanups to the transf
On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos wrote:
>
> But seriously: We are of course not allowed to remove copyright
> statements, no matter if we consider them relevant or not.
>
Please provide a source for such claims.
- Hendrik
___
ffmpeg-de
On Mon, May 13, 2019 at 8:57 AM Reimar Döffinger
wrote:
>
> On 13.05.2019, at 04:54, Pedro Arthur wrote:
>
> > Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
> > escreveu:
> >>
> >> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos
> >> wr
On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote:
>
> Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
> >
> > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
> > >>
> > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > >
On Mon, May 13, 2019 at 10:53 PM Carl Eugen Hoyos wrote:
>
> > Release branches provide a guarantee of API, ABI and feature
> > stability.
>
> And we sadly did not always hold that guarantee=-(
Mistakes have been made. We shall strive to be better in the future,
and not use them as an excuse to p
On Tue, May 14, 2019 at 10:34 PM Marton Balint wrote:
>
>
>
> On Sun, 5 May 2019, Carl Eugen Hoyos wrote:
>
> > Am So., 5. Mai 2019 um 20:51 Uhr schrieb Marton Balint :
> >>
> >> This reverts commit dd06f022b07438d650c82255dff16908ba04244a.
> >>
> >> Fixes ticket #7871 and reopens ticket #7816.
>
On Tue, May 14, 2019 at 11:25 PM Adam Richter wrote:
>
> Consider, for example, if you agree that columnization makes this range check
> more recognizable in a glance and makes it easier to spot what the bounds are
> (the sixteen space indentation is taken from the code in which it appeared):
>
>
On Wed, May 15, 2019 at 6:15 PM Damien Levin
wrote:
>
> ---
> libavformat/mpegts.c | 9 +++--
> tests/ref/fate/concat-demuxer-simple2-lavf-ts | 4 ++--
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> in
On Wed, May 15, 2019 at 8:41 PM Michael Niedermayer
wrote:
>
> Fixes: Ticket7880
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/qtrle.c| 27 +--
> tests/ref/fate/qtrle-8bit | 1 +
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/lib
On Wed, May 15, 2019 at 9:21 PM Adam Richter wrote:
>
> On Tue, May 14, 2019 at 6:48 PM myp...@gmail.com wrote:
> >
> > On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes wrote:
> > >
> > > On Tue, May 14, 2019 at 11:25 PM Adam Richter
> > > wrote:
On Thu, May 16, 2019 at 6:12 PM Damien Lévin
wrote:
>
> Thanks Hendrik,
>
> The documentation from the AVCodecParameters codec_tag changed here (and
> not AVCodecContext which you are referring to) seems pretty explicit about
> being an AVI fourcc. So I'm not sure I understand why setting the PES
On Mon, May 20, 2019 at 9:44 AM Reimar Döffinger
wrote:
>
>
>
> On 20.05.2019, at 09:23, Mathieu Duponchelle wrote:
>
> > Thanks :)
> >
> > On 5/19/19 7:00 PM, Devin Heitmueller wrote:
> >> Hello Paul,
> >>
> >> On Fri, May 17, 2019 at 4:44 AM Paul B Mahol wrote:
> >>> On 5/17/19, Mathieu Duponc
On Wed, May 22, 2019 at 10:53 AM Gyan wrote:
>
>
>
> On 22-05-2019 01:41 PM, Liu Steven wrote:
> >
> >> 在 2019年5月22日，下午3:10，Gyan 写道：
> >>
> >>
> >> Helps users to identify temp files for a given instance.
> >>
> >> In the longer term, we should aim to clean up all temp files.
> >>
> >> Gyan
> >>
On Wed, May 22, 2019 at 11:51 AM Gyan wrote:
>
>
>
> On 22-05-2019 02:29 PM, Hendrik Leppkes wrote:
> > On Wed, May 22, 2019 at 10:53 AM Gyan wrote:
> >>
> >>
> >> On 22-05-2019 01:41 PM, Liu Steven wrote:
> >>>> 在 2019年5月22日，下午3:10
On Wed, May 22, 2019 at 12:14 PM Gyan wrote:
>
>
>
> On 22-05-2019 03:29 PM, Hendrik Leppkes wrote:
> > On Wed, May 22, 2019 at 11:51 AM Gyan wrote:
> >>
> >>
> >> On 22-05-2019 02:29 PM, Hendrik Leppkes wrote:
> >>> On Wed, May 22, 2019 a
On Thu, May 23, 2019 at 9:55 PM Gyan wrote:
>
>
>
> On 24-05-2019 12:58 AM, Nicolas George wrote:
> > Gyan (12019-05-24):
> >> avpriv_io_delete will call the file protocol's delete which is guarded
> >> with a header check, not done here.
> > Do you have report of a build failure caused by unlink(
1 - 100 of 2231 matches
Mail list logo
