ld limit
this to maxDpbSlots I suspect, probably still use a uint32_t bitmask
to track it.
Dave.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..3548299770 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -3090,7 +3090,7 @@ static int hls_init(AVFormatContext *s)
---
libavformat/hlsenc.c | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e1714d4eed..1baefe852f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -35,6 +35,7 @@
#include "libavuti
---
libavformat/hlsenc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..76d8094de6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -245,7 +245,7 @@ typedef struct HLSContext {
char *var_
---
libavformat/hlsenc.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..dd1a461cce 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1931,6 +1931,30 @@ fail:
return ret
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..e59a38b497 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1538,7 +1538,7 @@ static int hls_window(AVFormatContext *s,
---
libavformat/hlsenc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f613e35984..e1714d4eed 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1253,9 +1253,11 @@ static int hls_appen
---
libavformat/hlsenc.c | 51 +---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 93c47b631b..f613e35984 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -103,6 +103,7 @@ typed
---
libavformat/hlsenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 24a0304f78..93c47b631b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1013,7 +1013,7 @@ static int sls_flags_filename_process(struct
---
libavformat/hlsenc.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5dfff6b2b6..24a0304f78 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -159,6 +159,7 @@ typedef struc
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 41 +
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f6071484ff..87c19a5cb9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1086,6 +108
---
libavformat/dashenc.c | 3 ++-
libavformat/hlsenc.c | 8 +++-
libavformat/hlsplaylist.c | 5 -
libavformat/hlsplaylist.h | 2 +-
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 96f4a5fbdf..15f700acbc 100644
--
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 41 +
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f6071484ff..87c19a5cb9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1086,6 +108
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f6071484ff..87c19a5cb9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1086,6 +1086,9 @@ seeking. This flag should be use
On Thu, 22 Jun 2023 at 07:36, James Almer wrote:
>
> On 6/21/2023 6:15 PM, Dave Airlie wrote:
> > On Thu, 22 Jun 2023 at 02:36, James Almer wrote:
> >>
> >> On 6/20/2023 8:36 PM, airl...@gmail.com wrote:
> >>> From: Dave Airlie
> >>>
>
On Thu, 22 Jun 2023 at 02:36, James Almer wrote:
>
> On 6/20/2023 8:36 PM, airl...@gmail.com wrote:
> > From: Dave Airlie
> >
> > av1-1-b8-03-sizeup.ivf on vulkan causes gpu hangs as none of the
> > images get resized when dimensions change, this detects th
let 1 open with no change than fixing no issue
>> because we wouldn't be sure for 1 of the 2.
>
> I suspect we are lucky because 720i doesn't really exist in the real
> world, and 576i and 480i are both multiples of 32.
>
> IMO mxfenc shouldn't lie, but looking a
ead_ffv1_sub_descriptor, sizeof(MXFFFV1SubDescriptor),
> FFV1SubDescriptor },
> { {
> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3A,0x00
> }, mxf_read_track, sizeof(MXFTrack), Track }, /* Static Track */
> { {
> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,
> -{ AV_FMT(YUYV422), AV_CODEC(RAWVIDEO),V4L2_FMT(YUYV) },
> -{ AV_FMT(UYVY422), AV_CODEC(RAWVIDEO),V4L2_FMT(UYVY) },
> -{ AV_FMT(YUV422P), AV_CODEC(RAWVIDEO),V4L2_FMT(YUV422P) },
> -{ AV_FMT(YUV411P), AV_CODEC(RAWVIDEO),V4L2_FMT(YUV411P) },
> On Mar 12, 2022, at 1:09 PM, Michael Niedermayer
> wrote:
>
> On Sat, Mar 12, 2022 at 10:11:52AM -0500, Dave Rice wrote:
>>
>>
>>> On Mar 10, 2022, at 4:41 AM, Tobias Rapp wrote:
>>>
>>> On 09/03/2022 19:18, Michael Niederm
...]
> The filter options look nice to me now. Have not actually tested the
> bitstream filter on DV files, though.
I tested this and this works well for me. Here's a few samples that demonstrate
the filter:
./ffmpeg -i
https://samples.ffmpeg.org/archi
Giving this another go. It would be really great to get webvtt with style
and region blocks working correctly in ffmpeg. This patch would solve at
least #9064, probably #8684 and possibly other tickets.
Please let me know if further changes are needed.
Cheers,
Dave
On Tue, Mar 16, 2021 at 9
ourage
one another, offer fair critical reviews, and work collaboratively towards
rough consensus.
Kind Regards,
The CC
James Almer
Thilo Borgmann
Carl Eugen Hoyos
Jean-Baptiste Kempf
Dave Rice
___
ffmpeg-
ted this patch and it does correct some errors. For instance, before
this patch frame 3 of the output only offers half of the needed duration, so
the resulting audio track is (1001/3)/2 shorter than the video. But after
the patch, the video and audio outputs have the same length.
ffmpeg -i
Hi Marton,
> On Feb 23, 2021, at 3:07 PM, Dave Rice wrote:
>
>> On Feb 23, 2021, at 2:42 PM, Marton Balint wrote:
>>
>> On Sat, 20 Feb 2021, Dave Rice wrote:
>>
>>> Hi,
>>>
>>>> On Oct 31, 2020, at 5:15 PM, Marton Balint >&g
t doesn't follow the API, then we fix it so that it does.
Stateful H264 implementation is
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/drivers/staging/vc04_services/bcm2835-codec
Stateless HEVC is
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/drivers/staging/media/rpivid
Dave
> [
stateless-decoder.html
[3] https://docs.nvidia.com/jetson/l4t-multimedia/group__V4L2Dec.html
Dave
> Brad
>
>
> [1]
> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/HEAD:/libavcodec/v4l2_m2m.c
> ___
> ffmpeg-devel mailing
Would it be possible for someone to take a look at this please? Would be
lovely to get it merged at some point. Please let me know if further
changes are needed.
Cheers,
Dave
On Tue, Oct 13, 2020 at 10:25 AM Dave Evans wrote:
> This patch fixes the total failure to parse cues when style
> On Feb 23, 2021, at 2:42 PM, Marton Balint wrote:
>
>
>
> On Sat, 20 Feb 2021, Dave Rice wrote:
>
>> Hi,
>>
>>> On Oct 31, 2020, at 5:15 PM, Marton Balint >> <mailto:c...@passwd.hu>> wrote:
>>> On Sat, 31 Oct 2020, Da
Hi,
> On Oct 31, 2020, at 5:15 PM, Marton Balint <mailto:c...@passwd.hu>> wrote:
> On Sat, 31 Oct 2020, Dave Rice wrote:
>>> On Oct 31, 2020, at 3:47 PM, Marton Balint >> <mailto:c...@passwd.hu>> wrote:
>>> On Sat, 31 Oct 2020, Dave Rice wrote:
&g
Hijacking with related, similar patch from a few months ago:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2538
On Tue, Jan 12, 2021 at 4:56 PM Roderich Schupp
wrote:
> Bug-ID: 9064
>
> The webvtt decoder truncates the file at the first such block.
> Since these blocks typically occu
tever amount of audio there is in the container
>>>>
>>>> which IIUC can differ from 1 video frame even rounded.
>>>> maybe this just doesnt occur and each frame has a count of samples always
>>>> rounded to the closes integer count for the video fra
>>> maybe this just doesnt occur and each frame has a count of samples always
>>> rounded to the closes integer count for the video frame.
>>
>> The difference between the audio timestamp and the video timestamp for
>> packets from the same DV frame is at most 0.3929
am wrong but
>> in cases where no audio is missing or damaged, this would also ignore how
>> much
>> audio is in each packet. So you could have lets say a timestamp difference
>> of excatly 1 second between 2 packets while their is actually not exactly
>> 1 second
> On Oct 31, 2020, at 5:15 PM, Marton Balint wrote:
> On Sat, 31 Oct 2020, Dave Rice wrote:
>>> On Oct 31, 2020, at 3:47 PM, Marton Balint wrote:
>>> On Sat, 31 Oct 2020, Dave Rice wrote:
>>>> Hi Marton,
>>>>> On Oct 31, 2020, at 12:5
> On Oct 31, 2020, at 3:47 PM, Marton Balint wrote:
> On Sat, 31 Oct 2020, Dave Rice wrote:
>
>> Hi Marton,
>>
>>> On Oct 31, 2020, at 12:56 PM, Marton Balint wrote:
>>> Fixes out of sync timestamps in ticket #8762.
>>
>> Although Michael’
flags:0 ts: 0.88
> ret: 0 st: 0 flags:1 dts: 0.88 pts: 0.88 pos:3168000
> size:144000
> ret: 0 st: 0 flags:1 ts:-0.24
> ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0
> size:144000
> -ret: 0 st: 1 flags:0 ts: 2
original issue is fixed.
Same as v1 except the test has been changed as requested in the original review.
Cheers,
Dave
WEBVTT
REGION
id:son
width:40%
lines:3
regionanchor:20%,80%
viewportanchor:20%,80%
scroll:up
REGION
id:father
width:40%
lines:3
regionanchor:80%,80%
viewportanchor:80%,80
On Mon, Oct 12, 2020 at 11:20 PM Jan Ekström wrote:
>
> On Tue, Oct 13, 2020 at 12:07 AM Dave Evans wrote:
> >
> > This patch fixes the total failure to parse cues when style and region
> > definition blocks are contained in the input file, and ensures those blocks
>
original issue is fixed.
First patch so please go easy :-)
Cheers,
Dave
WEBVTT
REGION
id:son
width:40%
lines:3
regionanchor:20%,80%
viewportanchor:20%,80%
scroll:up
REGION
id:father
width:40%
lines:3
regionanchor:80%,80%
viewportanchor:80%,80%
scroll:up
STYLE
::cue(i) {
/* make i tags italic
> On Aug 3, 2020, at 5:16 PM, Michael Niedermayer
> wrote:
>
> On Mon, Aug 03, 2020 at 10:38:21PM +0200, Marton Balint wrote:
>>
>>
>> On Sun, 2 Aug 2020, Dave Rice wrote:
>>
>>>
>>>
>>>> On Aug 1, 2020, at 5:26 PM, Marton
> On Aug 1, 2020, at 5:26 PM, Marton Balint wrote:
>
>
>
> On Sat, 1 Aug 2020, Michael Niedermayer wrote:
>
>> On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
>>>
>>>
>>> On Sat, 1 Aug 2020, Michael Niedermayer wrote:
>>>
Fixes: Ticket8762
Signed-off-by: Michael N
Hi Andreas,
> On Jun 27, 2020, at 5:09 PM, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> Remove the check on dv_demux since dv_fctx will leak if allocate
>> dv_demux failed.
>> ---
>> libavformat/mov.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavform
On 06/13/20 07:03 AM, KO Myung-Hun wrote:
Hi/2.
Dave Yeo wrote:
On 06/11/20 10:26 AM, Michael Niedermayer wrote:
On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote:
On 06/10/20 02:09 PM, Michael Niedermayer wrote:
On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote:
Hi, could I
On 06/11/20 10:26 AM, Michael Niedermayer wrote:
On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote:
On 06/10/20 02:09 PM, Michael Niedermayer wrote:
On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote:
Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break
in
On 06/10/20 02:09 PM, Michael Niedermayer wrote:
On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote:
Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break
in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and
also need the prototype.
Th
Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build
break in libavformat/ip.c (implicit declaration of function
'getaddrinfo') and also need the prototype.
Thanks,
Dave
From f9fbdaaf6cdb6f886cbdf31c1983e452567cd857 Mon Sep 17 00:00:00 2001
From: Dave Yeo
Date:
From 6182a7f6b83905fb2315b416ae714a329ec2d0df Mon Sep 17 00:00:00 2001
From: Dave Yeo
Date: Wed, 12 Feb 2020 20:13:00 -0800
Subject: [PATCH] compat/os2threads:define INCL_DOSERRORS
This is needed to pull in the define for ERROR_TIMEOUT
Signed-off-by: Dave Yeo
---
compat/os2threads.h | 1
> On Dec 27, 2019, at 10:49 AM, Paul B Mahol wrote:
>
> That is because signalstats is doing more stuff.
signalstats includes options to disable some of the calculations, possibly this
could be extended to enable or disable the ones you want. It would be
interesting to merge these ideas rathe
to change the default behavior from disabled to enabled. If I
understand correctly, after this patch, encoding with `-movflags write_colr`
would cause ffmpeg to fail with an error from the mov muxer.
Dave
___
ffmpeg-devel mailing list
ffmpeg-deve
Perhaps, for future proofing
-#if defined(__OS2__)
+#if !defined(SHUT_RD)
#define SHUT_RD 0
#define SHUT_WR 1
#define SHUT_RDWR 2
Works fine here on OS/2 and these macros may be added to the headers at
some point.
Dave
___
ffmpeg-devel mailing list
From caa816d70e69f85d49556ff341addab24ebcd942 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Mon, 1 Oct 2018 17:07:44 -0400
Subject: [PATCH 1/2] ffplay: options to specify window position
---
doc/ffplay.texi | 4
fftools/ffplay.c | 6 +-
2 files changed, 9 insertions(+), 1 deletion
> On Oct 2, 2018, at 1:32 AM, Gyan wrote:
>
> On Tue, Oct 2, 2018 at 2:47 AM Dave Rice wrote:
>
>> Allows arrangement of multiple windows such as:
>> ffmpeg -re -f lavfi -i mandelbrot -f sdl -window_x 1 -window_y 1
>> mandelbrot -vf waveform,format=yuv420p -f
Thanks Marton for comments. Here is a revision to the first patch.
From 3fe6a9e5279a280af9a06843621737ddc44529cc Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Mon, 1 Oct 2018 17:07:44 -0400
Subject: [PATCHv2 1/2] ffplay: options to specify window position
---
doc/ffplay.texi | 4
00438983c96b5db227b9975a2c160fc6aac5219d Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Mon, 1 Oct 2018 17:08:35 -0400
Subject: [PATCH 2/2] avdevice/sdl2 : add option to set window position
---
libavdevice/sdl2.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c
From 14d6833b564bd672613d50ecc4c3ede1768eee37 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Mon, 1 Oct 2018 17:07:44 -0400
Subject: [PATCH 1/2] ffplay: options to specify window position
---
fftools/ffplay.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fftools
/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> #define LIBAVFORMAT_VERSION_MINOR 18
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>
> #define LIBAVFORMAT_VE
r.
Works great on OS/2, from 700 seconds to 144 seconds
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
forked alternative to the work on
FFV1 version 4 by the IETF cellar working group.
https://twitter.com/retokromer/status/884030201050648576?s=21
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 12 August 2018 at 22:25, Jorge Ramirez-Ortiz wrote:
> On 08/06/2018 10:12 PM, Mark Thompson wrote:
>>
>> On 06/08/18 16:44, Jorge Ramirez-Ortiz wrote:
>>>
>>> On 08/04/2018 11:43 PM, Mark Thompson wrote:
>
> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> index
> On Jun 7, 2018, at 5:01 PM, Marton Balint wrote:
>
> On Thu, 7 Jun 2018, Dave Rice wrote:
>
> [...]
>
>>
>> Before I only tested with vitc but now have a serial cable connected as well
>> and found a source tape that has distinct values for LTC and VI
> On Jun 7, 2018, at 12:12 PM, Dave Rice wrote:
>
>
>> On Jun 6, 2018, at 5:32 PM, Marton Balint wrote:
>>
>> On Wed, 6 Jun 2018, Dave Rice wrote:
>>
>>>> On Jun 6, 2018, at 4:50 PM, Marton Balint wrote:
>>>> On Mon, 4 Jun 2018, Dave
> On Jun 6, 2018, at 5:32 PM, Marton Balint wrote:
>
> On Wed, 6 Jun 2018, Dave Rice wrote:
>
>>> On Jun 6, 2018, at 4:50 PM, Marton Balint wrote:
>>> On Mon, 4 Jun 2018, Dave Rice wrote:
>>>>>> In my testing the timecode value set here has
> On Jun 6, 2018, at 4:50 PM, Marton Balint wrote:
>
> On Mon, 4 Jun 2018, Dave Rice wrote:
>
>>
>>>> In my testing the timecode value set here has corrected been associated
>>>> with the first video frame (maintaining the timecode-to-first-frame
> On Jun 5, 2018, at 1:17 PM, Marton Balint wrote:
>
> On Tue, 5 Jun 2018, Dave Rice wrote:
>
>>> On Jun 4, 2018, at 4:21 PM, Marton Balint wrote:
>>>
>>> The default memory allocator is limited in the max number of frames
>>> available,
&g
> On Jun 4, 2018, at 4:21 PM, Marton Balint wrote:
>
> The default memory allocator is limited in the max number of frames available,
> and therefore caused frame drops if the frames were not freed fast enough.
I’ve been testing this patchset today. Yesterday I was occasionally getting
“Deckli
> On Jun 4, 2018, at 12:24 PM, Marton Balint wrote:
>
> On Fri, 1 Jun 2018, Dave Rice wrote:
>
>>> On May 31, 2018, at 5:29 PM, Marton Balint wrote:
>>> On Thu, 31 May 2018, Jonathan Morley wrote:
>>>> Thank you for the clarification, Dave. It migh
> On May 31, 2018, at 5:29 PM, Marton Balint wrote:
>
> On Thu, 31 May 2018, Jonathan Morley wrote:
>
>> Thank you for the clarification, Dave. It might be that the Blackmagic
>> approach to collecting timecode doesn’t work for that one source because it
>> is
avg: 65536.000
> I will add that to the next patch, but it might be a minute before I get to
> it. Thank you again for taking a look.
>
> I guess we got really lucky in our use case.
>
> Thanks,
> Jon
>
>> On May 31, 2018, at 12:39 PM, Dave Rice wrote:
>>
&
Hi Jonathan,
> On May 31, 2018, at 11:41 AM, Jonathan Morley wrote:
>
> Thank you very much, Dave. I am really curious about the df vs ndf since the
> Blackmagic SDK call I am making doesn’t have any arguments for specifying
> that kind of distinction. It simply returns what
l the Media Express
captures are Non-Drop Frame and all the ffmpeg captures are Drop Frame, so one
has to be wrong. I’ll try to find a source that can provide a known df and ndf
signal to determine which is correct.
Thanks for the update,
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> On May 25, 2018, at 17:15, Jonathan Morley wrote:
>
> Thank you for trying it out, Dave.
>
> 1) Can you please tell me more about how you tested?
J30 digibeta deck playing a Betacam SP with SDI to an Ultrastudio 3D with
ffmpeg with your patch and configured with decklink.
{ "unset", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 0}, 0, 0,DEC, "duplex_mode"},
>>> { "half", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 1}, 0, 0,DEC, "duplex_mode"},
>>> { "full", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 2}, 0, 0,DEC, "duplex_mode"},
>>> +{ "timecode_format", "timecode format", OFFSET(tc_format),
>>> AV_OPT_TYPE_INT, { .i64 = 0}, 0, 7,DEC, "tc_format"},
>>> +{ "none", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 0}, 0, 0,DEC, "tc_format"},
>>> +{ "rp188vitc", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 1}, 0, 0,DEC, "tc_format"},
>>> +{ "rp188vitc2",NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 2}, 0, 0,DEC, "tc_format"},
>>> +{ "rp188ltc", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 3}, 0, 0,DEC, "tc_format"},
>>> +{ "rp188any", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 4}, 0, 0,DEC, "tc_format"},
>>> +{ "vitc", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 5}, 0, 0,DEC, "tc_format"},
>>> +{ "vitc2", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 6}, 0, 0,DEC, "tc_format"},
>>> +{ "serial",NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 7}, 0, 0,DEC, "tc_format"},
>>> { "video_input", "video input", OFFSET(video_input),
>>> AV_OPT_TYPE_INT, { .i64 = 0}, 0, 6,DEC, "video_input"},
>>> { "unset", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 0}, 0, 0,DEC, "video_input"},
>>> { "sdi", NULL, 0,
>>> AV_OPT_TYPE_CONST, { .i64 = 1}, 0, 0,DEC, "video_input"},
>>> --
>>
>> Documentation update is missing.
>
> D’oh! Sloppy.
Thanks for this work!
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
consensus to appoint a CoC committee and
as needed the CoC committee finds consensus (as a small group) on how to
respond to concerns from the community and to implement the CoC.
b) the larger ffmpeg community finds consensus on how to implement the CoC
directly each time there’s a concern fro
> Have you considered BearSSL?
Thanks Nicolas; it sounds great but we disregarded it because the web
site declares it to be beta-quality. We will certainly keep an eye on
it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
you will find our method and results. We look forward to your
feedback.
Many thanks,
Dave
--
FFmpeg TLS libraries: disk and memory footprint comparison report
Goal: Compare the memory usage and disk footprint of the new mbedTLS
integration against the three existing platform-agnostic TLS libr
fo[n] - I only know V4L2 in any depth.
>> +break;
>> +
>> +default:
>
> Probably want a more explicit failure in other cases. Is there any 10-bit
> handling here yet (P010, I guess)?
Based on a quick search I don't believe V4L2 has added suppor
lly for information that things haven't
cleaned up in the manner that you might expect. Either you just ignore
it and let V4L2 clean up eventually when the main V4L2 device fd gets
closed, or you need applications to behave in a particular manner.
Ignoring it has potential knockon issues as
> On Mar 27, 2018, at 5:16 PM, wm4 wrote:
>
> On Tue, 27 Mar 2018 16:45:23 -0400
> Dave Rice mailto:d...@dericed.com>> wrote:
>
>>> On Mar 27, 2018, at 4:33 PM, wm4 wrote:
>>>
>>> On Tue, 27 Mar 2018 16:11:11 -0400
>>> Dave R
> On Mar 27, 2018, at 4:33 PM, wm4 wrote:
>
> On Tue, 27 Mar 2018 16:11:11 -0400
> Dave Rice wrote:
>
>>> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis
>>> wrote:
>>>
>>> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
>>>>
themselves - and I figured
> some would argue that point.
+1 I’m willing to contribute what information or samples would be needed to
help with Matroska support with virtual timelines. IMO, this would be a
valuable feature to have in ffmpeg.
Dave Rice
_
very close to a last call and submission to the
IESG (chairs are welcome to offer other opinions ;) ). So while I encourage
resolution to these pull requests, it seems we have a good system to manage
concurrent work on both FFV1 goals of the charter.
Kind Regards,
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
gt; SIGPIPE.
This patch has been working for me and ffmpeg terminates cleanly with SIGPIPE
with a valid output (moov atom written with mov or cues/seekhead written with
mkv). Not sure if I understand well the disadvantage of this patch.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 0faa2954010feb8428542fc33aa81e898a280c88 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 11 Jan 2018 15:52:36 -0500
Subject: [PATCH] ffmpeg.c: use sigterm_handler with sigpipe
Based on a suggestion by Moritz Barsnick at
http://ffmpeg.org/pipermail/ffmpeg-user/2018-January/038549.html
; pixstep; s++) {
> +out->data[0][(yskip + j * ystep - 1) *
> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
> +}
> +}
> +
> +yskip += j * ystep;
> +}
> +}
> }
> return 0;
> }
> --
> 2.11.0
Seems interesting but do the gridlines convey any meaning? Perhaps a flags
value too similar to waveform that should label the lines in dB or as a float.
Also perhaps worth adjustment the placement of the gridlines depending on a
scale (log vs lin).
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> On Nov 20, 2017, at 11:22 AM, Derek Buitenhuis
> wrote:
>
> On 11/20/2017 3:19 PM, Dave Rice wrote:
>> TN2162 requires a colr atom for uncompressed yuv (including v210, v308,
>> v408, etc) in mov, so I'd prefer to write it in this case. Note that the
>&g
> On Nov 20, 2017, at 9:55 AM, Derek Buitenhuis
> wrote:
>
> On 11/20/2017 2:50 PM, Dave Rice wrote:
>> I am hesitant to see write_colr option removed since the guesswork used here
>> https://github.com/FFmpeg/FFmpeg/blob/8f4702a93f87f9f76563e80f1ae2141a40029d9d/li
> On Nov 20, 2017, at 9:01 AM, Carl Eugen Hoyos wrote:
>
> 2017-11-20 2:24 GMT+01:00 James Almer <mailto:jamr...@gmail.com>>:
>> On 11/18/2017 11:19 PM, Dave Rice wrote:
>>> From 41da5e48f8788b85dd7a382030bb2866c506cc03 Mon Sep 17 00:00:00 2001
>>> F
8:overlap=7:queue=1' filmstrip.mkv
@end example
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From fe9e3aa13ecf3b4cb81f279696bcc21602662e7a Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Sat, 18 Nov 2017 20:32:33 -0500
Subject: [PATCH 4/4] fate: add v210 mov test
---
tests/fate/vcodec.mak | 4
tests/ref/vsynth/vsynth1-mov-v210 | 4
2 files changed, 8 insertions
26d9ca470f104d8448000b13c2cc97b8fc5c15ba Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH 1/4] avformat/movenc: correct ImageDescription for
uncompressed ycbcr
Per
https://developer.apple.com/library/content/technotes/tn2162/_index.html
.
---
libavformat/movenc.c | 20
From 41da5e48f8788b85dd7a382030bb2866c506cc03 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Sat, 18 Nov 2017 20:31:27 -0500
Subject: [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in
mov
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From e9079167c199791e652fe9cd3550333b819a8a9a Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:29:06 -0500
Subject: [PATCH 2/4] avformat/movenc: write clap atom for uncompressed yuv in
mov
fixes 6145
---
libavformat/movenc.c | 19 +++
1 file changed, 19
> On Nov 16, 2017, at 6:08 PM, Carl Eugen Hoyos wrote:
>
> 2017-11-16 17:54 GMT+01:00 Dave Rice :
>
>> +if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V410)
>> +avio_wb16(pb, 0x18);
>> +else if (
> On Nov 16, 2017, at 11:30 AM, Dave Rice wrote:
>
>> On Jul 9, 2017, at 7:26 PM, Dave Rice wrote:
>>
>>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis
>>> wrote:
>>>
>>> On 7/7/2017 10:13 PM, James Almer wrote:
>>>> I
162/_index.html>.
From 47def189b270ac93245e002580463b254daf8484 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410
Per
https://developer.apple.com/library/content/technotes/tn2162/_inde
> On Jul 9, 2017, at 7:26 PM, Dave Rice wrote:
>
>
>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis
>> wrote:
>>
>> On 7/7/2017 10:13 PM, James Almer wrote:
>>> Isn't this necessary only for files with raw video? As is, this box
>>&
tps://twitter.com/ajaprez/status/910100436224499713>. I’m glad to hear that
handling other VANC data is in the works, I’m particularly interested in VITC
and EIA-608 with inputs.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> On Oct 18, 2017, at 3:07 PM, Marton Balint wrote:
>
> On Mon, 16 Oct 2017, Dave Rice wrote:
>
>> Hi,
>>
>> I tested this with my Ultrastudio Express and confirmed that I'm getting
>> higher bit depth recordings with the abitscope filter. This patch
> On Oct 17, 2017, at 3:30 PM, Douglas Marsh wrote:
>
> On 2017-10-17 09:10, Dave Rice wrote:
>
>>>> -audio_depth .D.. audio bitdepth (from 0 to 1)
>>>> (default 16bits)
>>>>16bits .D..
>
>
1 - 100 of 223 matches
Mail list logo
