In offline transcoding mode, max latency is controllable.
But in video streaming usages, we can not expect to know the max latency in
advance, even decoder cannot know.
Like RTSP/RTMP/DASH, the latency is variable according to network bandwidth.
Let video sink or renderer in the of pipeline to
On Wed, 11 Mar 2020 at 02:59, Dai, Jianhui J
wrote:
> It does not break FFmpeg output frames management logic (e.g.
> h264_select_output_frame), just enter that phase earlier.
>
> Perhaps my understanding is not correct.
> In my opinions, render should be the one considering variable latency
>
As reply in another thread, the sequence of output frames still follows
standard, like display order POC in H264.
Big enough frame cache can guarantee deterministic delay in some extent, but
not always (decoding time > caching time).
E.g. in FF_THREAD_FRAME 4320x2160 30fps video streaming, 4
It does not break FFmpeg output frames management logic (e.g.
h264_select_output_frame), just enter that phase earlier.
Perhaps my understanding is not correct.
In my opinions, render should be the one considering variable latency issue,
instead of decoder.
The decoder should try best
On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J
wrote:
> Thanks, I will update the commit message.
>
> I test it with FFmpeg native sw H264 decoder.
> In previous FF_THREAD_FRAME, the latency is constant as N ( =
> thread_count - 1) frames.
> It won't sync thread state until no idle threads
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 8b17134944..2d2e4d8817 100755
--- a/configure
+++ b/configure
@@ -2790,7 +2790,7 @@ msmpeg4v3_decoder_select="h263_decoder"
msmpeg4v3_encoder_select="h263_encoder"
Thanks, I will update the commit message.
I test it with FFmpeg native sw H264 decoder.
In previous FF_THREAD_FRAME, the latency is constant as N ( = thread_count -
1) frames.
It won't sync thread state until no idle threads available, therefore N frames
are cached internal, even some frames
Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan :
>
> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote:
> > The Chemnitzer Linuxtage were canceled yesterday because of the Coronavirus.
> > I request reimbursement of €138,86 for the flight to Germany I had
> > booked last month.
>
>
On Tue, Mar 10, 2020 at 06:45:57PM +0100, Anton Khirnov wrote:
> ---
> libavcodec/mpegvideodata.c | 5 -
> 1 file changed, 5 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. --
> 2020年3月7日 上午11:26，Steven Liu 写道：
>
>
>
>> 2020年3月6日 上午11:58，Hongcheng Zhong 写道：
>>
>> This patch fixes Bug #8469
>> If x264 baseline profile is used with other profiles,
>> start_pts will be initialized to audio stream's first pts,
>> while the duration is calculated based on video
> 2020年3月11日 上午2:02，Lou Logan 写道：
>
> On Tue, Mar 10, 2020, at 4:40 AM, Steven Liu wrote:
>>
>> Some travel ticket site can buy the cheapest ticket but cannot
>> cancel it.
>
> In an off-list discussion he indicated that the process would be more
> time consuming than I expected compared to
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Artem Galin
> Sent: Tuesday, March 10, 2020 5:10 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support
>
> Any comments on updated patch by
tis 2020-03-10 klockan 13:40 +0100 skrev Michael Niedermayer:
> Hi all
> [...]
> About reimbursements, my personal oppinion is that anyone who has previously
> paid for travel fully believing that a conference would occur, and cannot get
> their money back should be reimbursed by our funds.
>
On 3/10/2020 4:08 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-10 19:14:47)
>> On 3/10/2020 3:03 PM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-02-27 19:01:59)
It's not a decoding exclusive function.
>>>
>>> How come? The doxy for it says
>>> 'Reset the internal decoder
Mar 10, 2020, 17:45 by an...@khirnov.net:
> Hi,
> sending a proposed new API for exporting QP tables (and possibly other
> things in the future). It is based on a patch from Juan De León
> (cf. <20190819233655.171637-1-jua...@google.com>).
>
> The set is intended for dicussion, not merging at
Quoting James Almer (2020-03-10 19:14:47)
> On 3/10/2020 3:03 PM, Anton Khirnov wrote:
> > Quoting James Almer (2020-02-27 19:01:59)
> >> It's not a decoding exclusive function.
> >
> > How come? The doxy for it says
> > 'Reset the internal decoder state / flush internal buffers.'
>
> It touches
On 3/10/2020 3:11 PM, Andriy Gelman wrote:
> On Tue, 10. Mar 06:37, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Up until now, v4l2_m2m would write via snprintf() into an intermediate
>>> buffer and then copy from there (via strncpy()) to the end buffer. This
>>> commit changes this by
On 3/10/2020 3:03 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-02-27 19:01:59)
>> It's not a decoding exclusive function.
>
> How come? The doxy for it says
> 'Reset the internal decoder state / flush internal buffers.'
It touches some fields used by encode.c, like draining and
On Tue, 10. Mar 06:37, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > Up until now, v4l2_m2m would write via snprintf() into an intermediate
> > buffer and then copy from there (via strncpy()) to the end buffer. This
> > commit changes this by removing the intermediate buffer.
> >
> > The
Quoting James Almer (2020-02-27 19:01:59)
> It's not a decoding exclusive function.
How come? The doxy for it says
'Reset the internal decoder state / flush internal buffers.'
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, Mar 10, 2020, at 4:40 AM, Steven Liu wrote:
>
> Some travel ticket site can buy the cheapest ticket but cannot
> cancel it.
In an off-list discussion he indicated that the process would be more
time consuming than I expected compared to my usual airline.
Just to be clear I'm not blocking
---
libavcodec/h264_picture.c| 8 +-
libavcodec/h264_slice.c | 9 +++
libavcodec/h264dec.c | 47
libavcodec/h264dec.h | 6 +
libavutil/video_enc_params.h | 1 +
5 files changed, 70 insertions(+), 1 deletion(-)
diff
Hi,
sending a proposed new API for exporting QP tables (and possibly other
things in the future). It is based on a patch from Juan De León
(cf. <20190819233655.171637-1-jua...@google.com>).
The set is intended for dicussion, not merging at this point. It does
not adapt the filters and thus breaks
Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS
flag.
Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE*
API.
---
libavcodec/h263dec.c | 6 --
libavcodec/mpeg12dec.c | 5 +++--
libavcodec/mpegpicture.c | 1 +
---
libavcodec/mpegvideodata.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/mpegvideodata.c b/libavcodec/mpegvideodata.c
index 5f1d8f7c00..da0638e052 100644
--- a/libavcodec/mpegvideodata.c
+++ b/libavcodec/mpegvideodata.c
@@ -19,7 +19,6 @@
#include
const uint8_t
---
libavcodec/avcodec.h | 5 +
libavcodec/options_table.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5a0fc3405c..7b3b59dc1e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1116,6 +1116,11 @@ typedef struct
From: Juan De León
This is intended to replace the deprecated the AV_FRAME_DATA_QP_TABLE*
API and extend it to a wider range of codecs.
In the future, it may also be extended to support other encoding
parameters such as motion vectors.
Signed-off-by: Juan De León
Signed-off-by: Michael
It is always 0.
---
libavcodec/mpegvideo.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index dbb6ab9b39..0be5364422 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -347,9 +347,9 @@ av_cold void
lgtm
On 3/10/20, James Almer wrote:
> Also remove the ancient reference to libmpcodecs while at it.
>
> Signed-off-by: James Almer
> ---
> libavfilter/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index
Any comments on updated patch by link below:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.8938-1-artem.ga...@gmail.com/
Thanks,
Artem.
On Sat, 1 Feb 2020 at 14:55, Mark Thompson wrote:
> On 24/01/2020 19:37, Artem Galin wrote:
> > On Fri, 24 Jan 2020 at 00:46, Mark
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 42f21eae8b..cf436f9e3e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2630,7 +2630,7 @@ static int
Also remove the ancient reference to libmpcodecs while at it.
Signed-off-by: James Almer
---
libavfilter/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e6cfcd9487..750412da6b 100644
--- a/libavfilter/Makefile
+++
Signed-off-by: James Almer
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index b7ecea855d..ddfca178f5 100644
--- a/Makefile
+++ b/Makefile
@@ -151,7 +151,9 @@ distclean:: clean
version.h libavutil/ffversion.h
On Tue, Mar 10, 2020 at 15:10:39 +, Zane van Iperen wrote:
> "Moritz Barsnick" wrote:
> > Does it actually build? Nothing seems to depend on adpcm_data.o.
> As for dependencies, seems there's 48 references to adpcm_data.o, all in
> libavcodec/Makefile:
Sorry, I actually missed that you
On Tue, 10 Mar 2020 15:47:08 +0100
"Moritz Barsnick" wrote:
> On Tue, Mar 10, 2020 at 14:15:26 +, Zane van Iperen wrote:
> > It was just to clean things up a bit by keeping them together.
> > Otherwise, 'tis no matter.
>
> Does it actually build? Nothing seems to depend on adpcm_data.o.
>
On Tue, Mar 10, 2020 at 14:15:26 +, Zane van Iperen wrote:
> It was just to clean things up a bit by keeping them together.
> Otherwise, 'tis no matter.
Does it actually build? Nothing seems to depend on adpcm_data.o.
Moritz
___
ffmpeg-devel
On 10/03/2020 09:36, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> ---
> libavcodec/pthread_frame.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
In addition to the points already raised (and which I agree
On 10/03/2020 11:33, Hendrik Leppkes wrote:
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changing delay.
I second this. A lot of software an usecases benefits (or requires) this.
Not to mention non-determinism...
- Derek
I fail to see how useful this is.
Unless you plan to write encoder it is not useful.
On 3/10/20, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> libavcodec/adpcm.c | 67 +++--
> libavcodec/adpcm_data.c | 29 ++
>
On Tue, 10 Mar 2020 14:52:25 +0100
"Paul B Mahol" wrote:
> I fail to see how useful this is.
> Unless you plan to write encoder it is not useful.
>
It was just to clean things up a bit by keeping them together.
Otherwise, 'tis no matter.
Zane
___
On Tue, 10 Mar 2020 at 12:07, Hendrik Leppkes wrote:
> On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai
> wrote:
> >
> > Avoid constant N frames latency in video streaming.
> >
>
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, March 10, 2020 19:34
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame
> to reduce latency
>
> On Tue, Mar 10, 2020 at 10:37 AM Jianhui
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 67 +++--
libavcodec/adpcm_data.c | 29 ++
libavcodec/adpcm_data.h | 4 +++
3 files changed, 51 insertions(+), 49 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> 2020年3月10日 上午9:59，Lou Logan 写道：
>
> On Mon, Mar 9, 2020, at 5:49 PM, Carl Eugen Hoyos wrote:
>>
>> Given that travel to Germany is in no way restricted, I don't see how.
>
> There is no travel restriction in the US either, but here's what the main
> airline in my region offers:
>
> * No
Hi all
I do not know if there are any upcomming real life meetings or conferences
besides the one which was canceled in germany
But i would suggest that Developers avoid all real life meetings/conferences
due to the worldwide increasing risk of COVID-19 until the situation changes
to the better.
On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai wrote:
>
> Avoid constant N frames latency in video streaming.
>
Personally, I'm off the opinion that a predictable constant delay in
this case is better then a variable ever-changing delay.
- Hendrik
___
Hi,
> FFmpeg has been accepted again for CLT 2020 in Chemnitz, Germany!
> This "Chemnitzer Linux Tage" will take place on 14th and 15th of March.
> You can find more details on their homepage:
>
> https://chemnitzer.linux-tage.de/2020/en/
>
> We will man a booth with our staff and are happily
> De : Nicolas Gaullier
> Envoyé : jeudi 5 mars 2020 09:17
> À : ffmpeg-devel@ffmpeg.org
> Cc : Gaullier Nicolas
> Objet : [PATCH v8 0/4] Fix mpeg1/2 stream copy
>
> I have not received any feedback yet.
> I repost here with all 4 patches, maybe it is easier for the review
> - 1/4: fix mpeg12
Am Di., 10. März 2020 um 10:37 Uhr schrieb Jianhui Dai
:
>
> Avoid constant N frames latency in video streaming.
Please add some numbers to the commit message,
if possible without using hardware acceleration.
Carl Eugen
___
ffmpeg-devel mailing list
Avoid constant N frames latency in video streaming.
Signed-off-by: Jianhui Dai
---
libavcodec/pthread_frame.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index b5bd494474..aeb42800ef 100644
---
Moritz Barsnick:
> On Mon, Mar 02, 2020 at 05:44:36 +0100, Andreas Rheinhardt wrote:
>> -{ "header", "filename of the header where the initialization data will
>> be written", OFFSET(header_filename), AV_OPT_TYPE_STRING, { 0 }, 0, 0,
>> AV_OPT_FLAG_ENCODING_PARAM },
>> +{ "header",
51 matches
Mail list logo
