Hi Marton,
Very good work with your series of patches on the mpegtsenc!
‐‐‐ Original Message ‐‐‐
On Thursday, 15 de August de 2019 1:51, Marton Balint wrote:
> Also document the algorithm for the default PCR interval.
> [...]
> + if (ts->mux_rate > 1 || ts->pcr_period_ms >= 0) {
> +
Hi Marton,
‐‐‐ Original Message ‐‐‐
On Wednesday, 14 de August de 2019 23:31, Marton Balint wrote:
> I pushed this series, will post the patch which enables setting pcr period
> for VBR.
Great! I'll prepare my updated interleaved patch.
Regards.
A.H.
---
Hi,
‐‐‐ Original Message ‐‐‐
On Saturday, 10 de August de 2019 20:05, Andreas Håkon
wrote:
> Hi Gyan and Nicolas,
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, 10 de August de 2019 17:13, Nicolas George geo...@nsup.org wrote:
>
> > Gyan (12019-08-10):
> >
> > > Since both pts and
On Wed, Aug 14, 2019 at 10:46:19PM +0200, Lynne wrote:
> Aug 14, 2019, 19:29 by mich...@niedermayer.cc:
>
> > On Tue, Aug 13, 2019 at 12:11:30PM +0200, Lynne wrote:
> >
> >> Aug 12, 2019, 20:53 by mich...@niedermayer.cc:
> >>
> >> > On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
fixes #8080
Signed-off-by: Błażej Szczygieł
---
libavformat/tls_gnutls.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index f32bc2821b..f507b7d044 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -184,6 +184,10
On Fri, Aug 16, 2019 at 5:22 AM Andreas Rheinhardt
wrote:
>
> The effective lifetime of the packet does not extend beyond the
> extract_extradata in libavformat/utils.c, so the packet can simply be
> put on the stack there. This allows to remove the allocation and the
> corresponding frees.
>
> Si
Hi all
as some noticed there are missing logs on the ffmpeg-devel-irc archives.
And it seemed some people on IRC think there is no logging.
I just want to confirm that the IRC topic is accurate and the channels
are logged.
The only problem that iam aware of is a problem between the logger and
the
On Fri, Aug 16, 2019 at 3:39 AM Reimar Döffinger
wrote:
>
>
> On 15.08.2019, at 19:38, Paul B Mahol wrote:
>
> > On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger <
> reimar.doeffin...@gmx.de>
> > wrote:
> >
> >> On 15.08.2019, at 13:15, Vittorio Giovara
> >> wrote:
> >>> I think being on the se
On Thu, Aug 15, 2019 at 05:14:38PM -0500, Ian Klassen wrote:
> Hi,
>
> Sorry Moritz, I somehow missed your feedback. Here's an updated patch with
> the fixed formatting. I also set up a server that you can test with. Try:
>
> ffmpeg -i test.mp4 -hls_flags +append_list -hls_time 6 -method PUT
> -h
On Fri, Aug 16, 2019 at 10:35 AM Michael Niedermayer
wrote:
> On Wed, Aug 14, 2019 at 10:46:19PM +0200, Lynne wrote:
> > Aug 14, 2019, 19:29 by mich...@niedermayer.cc:
> >
> > > On Tue, Aug 13, 2019 at 12:11:30PM +0200, Lynne wrote:
> > >
> > >> Aug 12, 2019, 20:53 by mich...@niedermayer.cc:
> >
Hi,
The latest version ready to merge of the bitstream filter "editpts".
Implements all requests.
This supersedes:
https://patchwork.ffmpeg.org/patch/14302/
https://patchwork.ffmpeg.org/patch/14195/
https://patchwork.ffmpeg.org/patch/13743/
https://patchwork.ffmpeg.org/patch/13699/
I hope it
Michael Niedermayer (12019-08-16):
> irc logs off? irc logs off.
> carl not here? carl not here.
> nicolas is an awful person who disagrees with everything and does no
> work like ever, yet hangs around the ml to be obnoxious
> his opinions on asserts should disqualify him from working on any
On Fri, Aug 16, 2019 at 1:03 PM Nicolas George wrote:
> Michael Niedermayer (12019-08-16):
> > irc logs off? irc logs off.
> > carl not here? carl not here.
> > nicolas is an awful person who disagrees with everything and
> does no work like ever, yet hangs around the ml to be obnoxious
> > h
- Forwarded message from Nicolas George -
Date: Fri, 16 Aug 2019 13:55:18 +0200
From: Nicolas George
To: Juan De León
Subject: Re: [FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures
Juan De León (12019-08-15):
> I don't think it's common for size_t to wrap around.
size_t h
> > +{ "duration", "set minimum mono or out-of-phase duration in
> seconds", OFFSET(duration), AV_OPT_TYPE_DOUBLE, {.dbl=2.}, 0, 24*60*60,
> FLAGS },
>
> ffmpeg also provides a AV_OPT_TYPE_DURATION. (This may have been
> discussed before - sorry if so.)
AV_OPT_TYPE_DURATION is used as an integ
On Thu, Aug 15, 2019 at 11:49:13PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (11sec -> 6sec)
> Fixes:
> 16344/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ANM_fuzzer-5673032000995328
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/
Pasting it into an email may not have been a good idea... here it is as an
attachment. Thanks.
On Fri, Aug 16, 2019 at 4:35 AM Michael Niedermayer
wrote:
> On Thu, Aug 15, 2019 at 05:14:38PM -0500, Ian Klassen wrote:
> > Hi,
> >
> > Sorry Moritz, I somehow missed your feedback. Here's an update
fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > Fixes: Timeout (12sec -> 32ms)
> > > >
On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Kieran Kunhya:
> > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Up until now, the H.264 parser has allocated a new buffer for every
> >> frame in order
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Guo, Yejun
> Sent: Wednesday, August 7, 2019 10:44 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [FFmpeg-devel] [PATCH V2] FATE/dnn: let fate/dnn tests depend on
> ffmpeg static libraries
>
> background:
>
Kieran Kunhya:
> On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Kieran Kunhya:
>>> On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
>>> andreas.rheinha...@gmail.com> wrote:
>>>
Up until now, the H.264 parser has allocated a new buffer for ever
ping.
leozhang 于2019年8月14日周三 上午11:07写道：
>
> Reviewed-by: Carl Eugen Hoyos
> Signed-off-by: leozhang
> ---
> libavformat/flvdec.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index b531a39..6bfe624 100644
> --- a/libavf
ff_read_packet had several potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If a packet happens to have an illegal stream index (i.e. one that
does not correspo
1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2. Furthermore,
The documentation of ff_packet_list_get currently didn't match the
actual usage:
1. It said that the destination packet is supposed to be initialized.
But this makes no sense given that it will be overwritten completely and
flacenc, mp3enc and ttaenc ignored this.
2. ff_packet_list_get returns an i
Need anything else Moritz?
> On 14 Aug 2019, at 09:54, Ross Nicholson wrote:
>
> I would imagine that the way Kodi handles the stream, rtsp_hd_out is null as
> per the following:
>
> URLContext * rtsp_hd_out
> Additional output handle, used when input and output are done
> separately,
Hi,
On Thu, Aug 15, 2019 at 1:22 PM elliottk
wrote:
>
> Current default is 256kbps, which produces inconsistent
> results (too high for low-res, too low for hi-res).
> Use CRF instead, which will adapt.
> ---
> libavcodec/libaomenc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf
There's no software i could find that supports this, so mine is the first
implementation out there. It's therefore tested with itself :p
James Almer (3):
avcodec/mlp_parse:
Signed-off-by: James Almer
---
libavformat/movenc.c | 61 +++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a96139077b..adb5cd0e5a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.
Signed-off-by: James Almer
---
libavformat/isom.c | 1 +
libavformat/mov.c | 34 ++
2 files changed, 35 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index c4880878c1..fa2e318099 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -3
It will be needed by the next commit.
Signed-off-by: James Almer
---
libavcodec/mlp_parse.c | 50 --
libavcodec/mlp_parse.h | 49 +
2 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/libavcodec/mlp_pars
On 8/16/2019 6:17 PM, James Almer wrote:
> https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf
>
> There's no software i could find that supports this, so mine is the first
> implementation out there. It's therefore tested with
tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin > :
> > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > Hi Tomas,
> > >
> > > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> > tjop...@acc.umu.se
> > > > :
>
fre 2019-08-16 klockan 14:57 +0200 skrev Tomas Härdin:
> fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> > On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > > mån 2019-08-12 klockan 21:17 +0200 skrev Mich
On 8/16/2019 6:31 PM, Tomas Härdin wrote:
> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin >> :
>>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
Hi Tomas,
Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Här
fre 2019-08-16 klockan 19:26 -0300 skrev James Almer:
> On 8/16/2019 6:31 PM, Tomas Härdin wrote:
> > tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin
> > > > > > :
> > > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
>
On 8/16/2019 7:32 PM, Tomas Härdin wrote:
> fre 2019-08-16 klockan 19:26 -0300 skrev James Almer:
>> On 8/16/2019 6:31 PM, Tomas Härdin wrote:
>>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin :
> ons 2019-08-14 klockan
On Thu, Aug 15, 2019 at 07:59:28AM +0200, Stanislav Ionascu wrote:
> Hi,
>
> On Wed, Aug 14, 2019 at 11:50 PM Michael Niedermayer
> wrote:
> >
> > On Wed, Aug 14, 2019 at 08:44:11PM +0200, Stanislav Ionascu wrote:
> > > On Tue, Aug 13, 2019 at 10:22 PM Andreas Rheinhardt
> > > wrote:
> > > >
> >
Hi,
This patch is trying to fix #6869.
The ticket has a h264 stream NOT starting with IDR, and all frames are I
frames.
And the mp4toannexb filter insert SPS/PPS before IDR, so leads to the
result that the output has no SPS/PPS.
The fix is just simply insert SPS/PPS before first picture, no matter
Fix #6869, write sps/pps before the first picture nal, no matter what type
of picture it is.
---
libavcodec/h264_mp4toannexb_bsf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index fb3f2
matroska_reset_status (a function that is used during seeking (among
other things)) used an int for the return value of avio_seek which
returns an int64_t. Checking the return value then indicated an error
even though the seek was successfull for targets in the range of
2GB-4GB, 6GB-8GB, ... This e
On 8/16/2019 9:27 PM, Andreas Rheinhardt wrote:
> matroska_reset_status (a function that is used during seeking (among
> other things)) used an int for the return value of avio_seek which
> returns an int64_t. Checking the return value then indicated an error
> even though the seek was successfull
Hendrik Leppkes:
> On Fri, Aug 16, 2019 at 5:22 AM Andreas Rheinhardt
> wrote:
>>
>> The effective lifetime of the packet does not extend beyond the
>> extract_extradata in libavformat/utils.c, so the packet can simply be
>> put on the stack there. This allows to remove the allocation and the
>> c
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet; it is of course nonsense and has
been replaced by an accurate description.
2. The description of av_write_uncoded_fra
45 matches
Mail list logo
