Ping.
> On Apr 27, 2021, at 1:09 PM, Zhao Zhili wrote:
>
> From: zhilizhao
>
> Simple test results:
>
> Command:
> ./ffmpeg -y -hwaccel videotoolbox -hwaccel_output_format videotoolbox_vld \
> -i test.mp4 -an -c:v h264_videotoolbox -benchmark out.mp4
>
> Before:
> frame= 1221 fps= 66 q=-0.0
Ping for review, thanks!
> On May 19, 2021, at 12:03 AM, Zhao Zhili wrote:
>
> ---
> There is no good use case yet. Patch 2/2 is only used for test.
>
> libavformat/libsrt.c | 35 +++
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat
It's useful for test client which pass streamid to ffmpeg/ffplay.
For example, use ffmpeg to test streamid support in VLC:
./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
srt://127.0.0.1:9000
./vlc srt://127.0.0.1:9000?streamid=foobar
---
v3:
Don't zero out streamid.
Fix streamid
> On Jun 9, 2021, at 6:04 AM, Marton Balint wrote:
>
>
> On Tue, 1 Jun 2021, Zhao Zhili wrote:
>
>> It's useful for test client which pass streamid to ffmpeg/ffplay.
>> For example, use ffmpeg to test streamid support in VLC:
>> ./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
> Jun 8, 2021, 07:38 by wenbin.c...@intel.com:
>
> >> Apr 29, 2021, 03:52 by d...@lynne.ee:
> >>
> >> > This patch allows for alternative loader implementations.
> >> >
> >> > Patch attached.
> >> >
> >>
> >> Forgot to fix a flag, v2 attached.
> >>
> >
> > Hi Lynne:
> > I tried the following com
On Wed, 2021-06-09 at 16:03 +, Rogozhkin, Dmitry V wrote:
> On Wed, 2021-06-09 at 12:18 +0800, Haihao Xiang wrote:
> > Since commit 89ffcd1, the pts on output pad is in the time base of
> > the
> > input link, not the time base of the output link when EOF is reached,
> > so
> > a filter after v
On 6/7/2021 9:17 AM, James Almer wrote:
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 04ddc9e60b..e97d879cb3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2962,7 +2962,9 @@ static int
Quoting Diederick C. Niehorster (2021-06-09 21:49:28)
> On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
> >
> > Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > > Sorry to rain on your parade, but I don't think we should go
path1 and sanitized_path are both MAX_URL_SIZE bytes long, yet the latter is
copied from the former with the addition of one extra character.
Should fix a -Wformat-truncation warning.
Signed-off-by: James Almer
---
libavformat/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
>
> Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > Sorry to rain on your parade, but I don't think we should go ahead with
> > > this before deciding what is to be done with li
On Wed, Jun 9, 2021 at 1:20 PM Nicolas George wrote:
> Thanks for explaining. Then "data: int (device-specific)" should be
> enough, if you also document the device-specific value in the user
> documentation of each device.
>
> That means in patch 14, "Documentation of dialog variable:" should be
Check for sys/auxv.h because not all toolchains contain this header.
Fixes https://trac.ffmpeg.org/ticket/9138
Signed-off-by: Bernd Kuhls
---
v2: defined(HAVE_SYS_AUXV_H) -> HAVE_SYS_AUXV_H
configure| 2 ++
libavutil/mips/cpu.c | 6 +++---
2 files changed, 5 insertions(+), 3 deleti
Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > Sorry to rain on your parade, but I don't think we should go ahead with
> > this before deciding what is to be done with libavdevice. The last
> > discussion about it died without being
They are internal and have no reason to exist in a public header, so
rename and move them to internal.h
Signed-off-by: James Almer
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 11 +--
libavformat/internal.h | 9 -
libavformat/utils.c| 14 +++---
liba
On Wed, Jun 9, 2021 at 1:15 PM Nicolas George wrote:
>
> What matters is not what you see in the console but what data is really
> written on the stream. Programs that read from the ffmpeg process and
> use the output to build a command line, all in a binary-clean way,
> should succeed.
>
> You ca
It can be useful to library users, and is currently being used by ffmpeg.c
Suggested-by: Hendrik Leppkes
Signed-off-by: James Almer
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 17 +++--
libavformat/version.h | 4 ++--
3 files changed, 12 insertions(+), 12 deletio
Patch 2/2 (patchwork seemt not handle both at the same time)
Kind regards,
Dennis Fleurbaaij
+31 (0) 6 54 21 5365
From 4f2b6a74863ff50906ba0fa1239914ab5618c304 Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Wed, 9 Jun 2021 19:21:14 +0200
Subject: [PATCH 2/2] libavformat: r12b decoder fou
By request of Carl Eugen here is the r12b decoder and the fourcc proposal
in 2 different patches so you can pick which ones are acceptable.
Kind regards,
Dennis Fleurbaaij
From 0d2243a6b566b17e7f669efb65f5398971964146 Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Wed, 9 Jun 2021 19:20:29
On Wed, 2021-06-09 at 12:18 +0800, Haihao Xiang wrote:
> Since commit 89ffcd1, the pts on output pad is in the time base of
> the
> input link, not the time base of the output link when EOF is reached,
> so
> a filter after vpp_qsv might output some unexpected frames. In order
> to
> avoid this iss
On 6/7/2021 6:24 AM, Valerii Zapodovnikov wrote:
Do you know what command to use with
http://fate-suite.ffmpeg.org/dolby_e/16-11.pcm? I used -ac 6, but I dunno
everything else I used was not giving perfect sound (-f s16le -ac 6 was
most important to at least get something playable). Sigh. Also
On 6/5/2021 12:01 PM, James Almer wrote:
libavdevice needs it.
Signed-off-by: James Almer
---
libavformat/aadec.c | 4 ++--
libavformat/brstm.c | 2 +-
libavformat/idcin.c | 2 +-
libavformat/internal.h| 2 +-
libavformat/matroskadec.c | 2 +-
libavformat/mca.c
Diederick C. Niehorster (12021-06-08):
> The guts of this function is unchanged from av_opt_get, just moved
> here, should i address this in this patch, or is it a separate issue?
> Happy to do either.
The critical part is the API of the new public function, because this we
cannot fix later.
Unfo
Diederick C. Niehorster (12021-06-08):
> Do i understand correctly that you would like it documented what this
> int means? It would be avdevice-specific. If a device has multiple
> dialogs, the int allows indicating which is to be shown. Would adding
> "data: int: indicates which dialog to show. M
Diederick C. Niehorster (12021-06-08):
> Done. Only problem is that now a device of mine that should be called
> "Microphone Array (Intel® Smart Sound Technology (Intel® SST))" is
> instead printed as "Intel® Smart Sound Technology (Intel® SST)".
> Since devices are selected by name for some avde
Nicolas George (12021-06-09):
> Interesting thanks. I wonder why they did it like this, requiring two
> extra system calls for each flush; a flag on send would have served
> without extra system calls.
Ah, I see they have MSG_MORE, introduced at the same time, that does
just that. If it was portab
Steinar H. Gunderson (12021-06-09):
> If you want explicit flush, you can enable TCP_CORK (but it's Linux-only).
> Disable for the flush.
Interesting thanks. I wonder why they did it like this, requiring two
extra system calls for each flush; a flag on send would have served
without extra system c
Am 09.06.21 um 12:45 schrieb Steinar H. Gunderson:
> On Wed, Jun 09, 2021 at 12:41:17PM +0200, Nicolas George wrote:
>> (TCP_NODELAY is a terrible hack for a terrible API design. An explicit
>> flush system call would have been a much better choice.)
>
> If you want explicit flush, you can enable
On Wed, Jun 09, 2021 at 12:41:17PM +0200, Nicolas George wrote:
> (TCP_NODELAY is a terrible hack for a terrible API design. An explicit
> flush system call would have been a much better choice.)
If you want explicit flush, you can enable TCP_CORK (but it's Linux-only).
Disable for the flush.
/*
Thilo Borgman (12021-06-09):
> $subject seems to be useful depending on the network.
It looks premature. TCP_NODELAY should only ever used when the network
code already takes care of writing data in a single system call. This is
not what happens in ff_rtmp_packet_write() (libavformat/rtmppkt.c): t
Hi,
$subject seems to be useful depending on the network.
-Thilo
From 936826eec00ac2ceaa4579e8a6030a85191320a5 Mon Sep 17 00:00:00 2001
From: Nick Ruff
Date: Wed, 9 Jun 2021 12:26:03 +0200
Subject: [PATCH] lavf/rtmp: Add option to set TCP_NODELAY for rtmp
Suggested-By: ffm...@fb.com
---
doc/p
Jun 8, 2021, 07:38 by wenbin.c...@intel.com:
>> Apr 29, 2021, 03:52 by d...@lynne.ee:
>>
>> > This patch allows for alternative loader implementations.
>> >
>> > Patch attached.
>> >
>>
>> Forgot to fix a flag, v2 attached.
>>
>
> Hi Lynne:
> I tried the following command:
> "ffmpeg -init_hw_devic
Include hstack_qsv, vstack_qsv and xstack_qsv, some code is copy and
pasted from other filters
Example:
$> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -filter_complex
"[0:v][0:v]hstack_qsv" -f null -
---
configure | 6 +
libavfilter/Makefile | 3 +
libavfilter/allfi
32 matches
Mail list logo