Re: [FFmpeg-devel] [PATCH] avformat/movenc: always write a colr atom
Hi James,
> On Jul 16, 2019, at 9:47 AM, James Almer wrote:
>
> -{ "write_colr", "Write colr atom (Experimental, may be renamed or
> changed, do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
> "movflags" },
The comment said specifically not to use this option in scripts; however, there
were ffmpeg users (I admit myself as one) who wanted both to use scripts and
write valid QuickTime files with colr data. I’d suggest permitting the option
to remain but 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-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".
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add reserve free space option
> On Sep 12, 2018, at 11:56 AM, Sigríður Regína Sigurþórsdóttir
> wrote:
>
> On Thu, Sep 6, 2018 at 3:31 PM James Almer <mailto:jamr...@gmail.com>> wrote:
>>
>> On 9/6/2018 4:18 PM, James Darnley wrote:
>>> On 2018-09-06 19:39, Sigríður Regína Sigurþórsdóttir wrote:
>>>> +if (s->metadata_header_padding) {
>>>> +if (s->metadata_header_padding == 1)
>>>> +s->metadata_header_padding++;
>>>> +put_ebml_void(pb, s->metadata_header_padding);
>>>> +}
>>>
>>> Unfortunately I was forced to make the default -1 so you want to check
>>> that the value is greater than 0 rather than just true.
>>>
>>> Furthermore I think you will still want to add to Changelog making a
>>> note that the matroska muxer will now listen to metadata_header_padding.
>>
>> No, this kind of change doesn't justify a Changelog entry as mentioned
>> before.
>>
>>> That may also want a micro version bump so that library users can check.
>>
>> Micro version bump is ok.
>
>
> Thank you.
>
> Here is an updated patch with a bump and a change to make sure the value is >
> 0.
>
>
>
> From 08e140fa0b23274a4db18ce0b201e45fe7c1ac97 Mon Sep 17 00:00:00 2001
> From: Sigga Regina mailto:siggareg...@gmail.com>>
> Date: Wed, 12 Sep 2018 11:47:47 -0400
> Subject: [PATCH] avformat/matroskaenc: add reserve free space option
>
> ---
> libavformat/matroskaenc.c | 5 +
> libavformat/version.h | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 09a62e1..3f5febf 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2005,6 +2005,11 @@ static int mkv_write_header(AVFormatContext *s)
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> +if (s->metadata_header_padding > 0) {
> + if (s->metadata_header_padding == 1)
> +s->metadata_header_padding++;
> + put_ebml_void(pb, s->metadata_header_padding);
> +}
> if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && mkv->reserve_cues_space) {
> mkv->cues_pos = avio_tell(pb);
> if (mkv->reserve_cues_space == 1)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 4d21583..d7a1a35 100644
> --- a/libavformat/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_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>LIBAVFORMAT_VERSION_MINOR, \
> --
> 2.10.1 (Apple Git-78)
> <0001-avformat-matroskaenc-add-reserve-free-space-option
> (1).patch>___
ping on this, as reserving such space in Matroska headers for later edits to
the Tracks element would be helpful.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffplay: options to specify window position
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/ffplay.c b/fftools/ffplay.c
index e375a32ec2..e1ec2e9df2 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -314,6 +314,8 @@ static int default_width = 640;
static int default_height = 480;
static int screen_width = 0;
static int screen_height = 0;
+static int window_x;
+static int window_y;
static int audio_disable;
static int video_disable;
static int subtitle_disable;
@@ -1346,7 +1348,11 @@ static int video_open(VideoState *is)
SDL_SetWindowTitle(window, window_title);
SDL_SetWindowSize(window, w, h);
-SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED,
SDL_WINDOWPOS_CENTERED);
+if (!window_x)
+window_x = SDL_WINDOWPOS_CENTERED;
+if (!window_y)
+window_y = SDL_WINDOWPOS_CENTERED;
+SDL_SetWindowPosition(window, window_x, window_y);
if (is_full_screen)
SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP);
SDL_ShowWindow(window);
@@ -3602,6 +3608,8 @@ static const OptionDef options[] = {
{ "framedrop", OPT_BOOL | OPT_EXPERT, { &framedrop }, "drop frames when
cpu is too slow", "" },
{ "infbuf", OPT_BOOL | OPT_EXPERT, { &infinite_buffer }, "don't limit the
input buffer size (useful with realtime streams)", "" },
{ "window_title", OPT_STRING | HAS_ARG, { &window_title }, "set window
title", "window title" },
+{ "window_x", OPT_INT | HAS_ARG | OPT_EXPERT, { &window_x }, "set the x
position of the window", "x pos" },
+{ "window_y", OPT_INT | HAS_ARG | OPT_EXPERT, { &window_y }, "set the y
position of the window", "y pos" },
#if CONFIG_AVFILTER
{ "vf", OPT_EXPERT | HAS_ARG, { .func_arg = opt_add_vfilter }, "set video
filters", "filter_graph" },
{ "af", OPT_STRING | HAS_ARG, { &afilters }, "set audio filters",
"filter_graph" },
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avdevice/sdl2 : add option to set window position
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 sdl -window_x 641 -window_y 1 waveform -vf
vectorscope,format=yuv420p -f sdl -window_x 1 -window_y 481 vectorscop
From 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
index da5143078e..69c541da23 100644
--- a/libavdevice/sdl2.c
+++ b/libavdevice/sdl2.c
@@ -40,6 +40,7 @@ typedef struct {
SDL_Renderer *renderer;
char *window_title;
int window_width, window_height; /**< size of the window */
+int window_x, window_y; /**< position of the window */
int window_fullscreen;
int window_borderless;
int enable_quit_action;
@@ -217,6 +218,12 @@ static int sdl2_write_header(AVFormatContext *s)
SDL_SetWindowTitle(sdl->window, sdl->window_title);
+if (!sdl->window_x)
+sdl->window_x = SDL_WINDOWPOS_CENTERED;
+if (!sdl->window_y)
+sdl->window_y = SDL_WINDOWPOS_CENTERED;
+SDL_SetWindowPosition(sdl->window, sdl->window_x, sdl->window_y);
+
sdl->texture = SDL_CreateTexture(sdl->renderer, sdl->texture_fmt,
SDL_TEXTUREACCESS_STREAMING,
codecpar->width, codecpar->height);
@@ -337,6 +344,8 @@ static int sdl2_write_packet(AVFormatContext *s, AVPacket
*pkt)
static const AVOption options[] = {
{ "window_title", "set SDL window title", OFFSET(window_title),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, AV_OPT_FLAG_ENCODING_PARAM },
{ "window_size", "set SDL window forced size", OFFSET(window_width),
AV_OPT_TYPE_IMAGE_SIZE, { .str = NULL }, 0, 0, AV_OPT_FLAG_ENCODING_PARAM },
+{ "window_x", "set SDL window x position", OFFSET(window_x),
AV_OPT_TYPE_INT,{ .i64 = 0 },0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM
},
+{ "window_y", "set SDL window y position", OFFSET(window_y),
AV_OPT_TYPE_INT,{ .i64 = 0 },0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM
},
{ "window_fullscreen", "set SDL window fullscreen",
OFFSET(window_fullscreen), AV_OPT_TYPE_BOOL, { .i64 = 0 },0, 1,
AV_OPT_FLAG_ENCODING_PARAM },
{ "window_borderless", "set SDL window border off",
OFFSET(window_borderless), AV_OPT_TYPE_BOOL, { .i64 = 0 },0, 1,
AV_OPT_FLAG_ENCODING_PARAM },
{ "window_enable_quit", "set if quit action is available",
OFFSET(enable_quit_action), AV_OPT_TYPE_INT, {.i64=1}, 0, 1,
AV_OPT_FLAG_ENCODING_PARAM },
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 1/2] ffplay: options to specify window position
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
fftools/ffplay.c | 6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index dcb86ce13c..a3da2cd570 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -74,6 +74,10 @@ as 100.
Force format.
@item -window_title @var{title}
Set window title (default is the input filename).
+@item -screen_left @var{title}
+Set the x position for the left of the window (default is a centered window).
+@item -screen_top @var{title}
+Set the y position for the top of the window (default is a centered window).
@item -loop @var{number}
Loops movie playback times. 0 means forever.
@item -showmode @var{mode}
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index e375a32ec2..6cc59b4d33 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -314,6 +314,8 @@ static int default_width = 640;
static int default_height = 480;
static int screen_width = 0;
static int screen_height = 0;
+static int left = SDL_WINDOWPOS_CENTERED;
+static int top = SDL_WINDOWPOS_CENTERED;
static int audio_disable;
static int video_disable;
static int subtitle_disable;
@@ -1346,7 +1348,7 @@ static int video_open(VideoState *is)
SDL_SetWindowTitle(window, window_title);
SDL_SetWindowSize(window, w, h);
-SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED,
SDL_WINDOWPOS_CENTERED);
+SDL_SetWindowPosition(window, left, top);
if (is_full_screen)
SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP);
SDL_ShowWindow(window);
@@ -3602,6 +3604,8 @@ static const OptionDef options[] = {
{ "framedrop", OPT_BOOL | OPT_EXPERT, { &framedrop }, "drop frames when
cpu is too slow", "" },
{ "infbuf", OPT_BOOL | OPT_EXPERT, { &infinite_buffer }, "don't limit the
input buffer size (useful with realtime streams)", "" },
{ "window_title", OPT_STRING | HAS_ARG, { &window_title }, "set window
title", "window title" },
+{ "left", OPT_INT | HAS_ARG | OPT_EXPERT, { &left }, "set the x position
for the left of the window", "x pos" },
+{ "top", OPT_INT | HAS_ARG | OPT_EXPERT, { &top }, "set the y position for
the top of the window", "y pos" },
#if CONFIG_AVFILTER
{ "vf", OPT_EXPERT | HAS_ARG, { .func_arg = opt_add_vfilter }, "set video
filters", "filter_graph" },
{ "af", OPT_STRING | HAS_ARG, { &afilters }, "set audio filters",
"filter_graph" },
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avdevice/sdl2 : add option to set window position
> 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 sdl -window_x 641 -window_y 1 >> waveform -vf vectorscope,format=yuv420p -f sdl -window_x 1 -window_y 481 >> vectorscop >> >> From 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 >> >> +if (!sdl->window_x) >> +sdl->window_x = SDL_WINDOWPOS_CENTERED; >> +if (!sdl->window_y) >> +sdl->window_y = SDL_WINDOWPOS_CENTERED; >> +SDL_SetWindowPosition(sdl->window, sdl->window_x, sdl->window_y); >> > > What happens if the user value implies fully or partially out-of-canvas > rendering? I attempted to add an error message but am uncertain how to access the width and height of the canvas used. Any advice? > For the former case, we may want to print a warning and reposition the > window. > If a partial window is drawable, then negative values can be valid and the > lower range bound should be INT_MIN > Also, the user can't position a window at top-left (0,0), so the default > should probably be INT_MAX. > > Gyan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 1/2] ffplay: options to specify window position
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(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index dcb86ce13c..99e1d7468a 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -74,6 +74,10 @@ as 100.
Force format.
@item -window_title @var{title}
Set window title (default is the input filename).
+@item -left @var{title}
+Set the x position for the left of the window (default is a centered window).
+@item -top @var{title}
+Set the y position for the top of the window (default is a centered window).
@item -loop @var{number}
Loops movie playback times. 0 means forever.
@item -showmode @var{mode}
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index e375a32ec2..ab1f9faccf 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -314,6 +314,8 @@ static int default_width = 640;
static int default_height = 480;
static int screen_width = 0;
static int screen_height = 0;
+static int screen_left = SDL_WINDOWPOS_CENTERED;
+static int screen_top = SDL_WINDOWPOS_CENTERED;
static int audio_disable;
static int video_disable;
static int subtitle_disable;
@@ -1346,7 +1348,7 @@ static int video_open(VideoState *is)
SDL_SetWindowTitle(window, window_title);
SDL_SetWindowSize(window, w, h);
-SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED,
SDL_WINDOWPOS_CENTERED);
+SDL_SetWindowPosition(window, screen_left, screen_top);
if (is_full_screen)
SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP);
SDL_ShowWindow(window);
@@ -3602,6 +3604,8 @@ static const OptionDef options[] = {
{ "framedrop", OPT_BOOL | OPT_EXPERT, { &framedrop }, "drop frames when
cpu is too slow", "" },
{ "infbuf", OPT_BOOL | OPT_EXPERT, { &infinite_buffer }, "don't limit the
input buffer size (useful with realtime streams)", "" },
{ "window_title", OPT_STRING | HAS_ARG, { &window_title }, "set window
title", "window title" },
+{ "left", OPT_INT | HAS_ARG | OPT_EXPERT, { &screen_left }, "set the x
position for the left of the window", "x pos" },
+{ "top", OPT_INT | HAS_ARG | OPT_EXPERT, { &screen_top }, "set the y
position for the top of the window", "y pos" },
#if CONFIG_AVFILTER
{ "vf", OPT_EXPERT | HAS_ARG, { .func_arg = opt_add_vfilter }, "set video
filters", "filter_graph" },
{ "af", OPT_STRING | HAS_ARG, { &afilters }, "set audio filters",
"filter_graph" },
--
2.19.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
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: >>>> Hi Marton, >>>>> On Oct 31, 2020, at 12:56 PM, Marton Balint >>>> <mailto:c...@passwd.hu>> wrote: >>>>> Fixes out of sync timestamps in ticket #8762. >>>> Although Michael’s recent patch does address the issue documented in 8762, >>>> I haven’t found this patch to fix the issue. I tried with -c:a copy and >>>> with -c:a pcm_s16le with some sample files that exhibit this issue but >>>> each output was out of sync. I put an output at >>>> https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795 >>>> <https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795>. That >>>> output notes that 3597 packages of video are read and 3586 packets of >>>> audio. In the resulting file, at the end of the timeline the audio is 9 >>>> frames out of sync and my output video stream is 00:02:00.020 and output >>>> audio stream is 00:01:59.653. >>>> Beyond copying or encoding the audio, are there other options I should use >>>> to test this? >>> Well, it depends on what you want. After this patch you should get a file >>> which has audio packets synced to video, but the audio stream is sparse, >>> not every video packet has a corresponding audio packet. (It looks like our >>> MOV muxer does not support muxing of sparse audio therefore does not >>> produce proper timestamps. But MKV does, please try that.) >>> You can also make ffmpeg generate the missing audio based on packet >>> timestamps. Swresample has an async=1 option, so something like this should >>> get you synced audio with continous audio packets: >>> ffmpeg -y -i 167052_12.dv -c:v copy \ >>> -af aresample=async=1:min_hard_comp=0.01 -c:a pcm_s16le 167052_12.mov >> >> Thank you for this. With the patch and async, the result is synced and the >> resulting audio was the same as Michael’s patch. >> >> Could you explain why you used min_hard_comp here? IIUC min_hard_comp is a >> set a threshold between the strategies of trim/fill or stretch/squeeze to >> align the audio to time; however, the async documentation says "Setting this >> to 1 will enable filling and trimming, larger values represent the maximum >> amount in samples that the data may be stretched or squeezed” so I thought >> that async=1 would not permit stretch/squeeze anyway. > > It is documented poorly, but if you check the source code you will see that > async=1 implicitly sets min_comp to 0.001 enabling trimming/dropping. > min_hard_comp decides the threshold when silence injection actually happens, > and the default for that is 0.1, which is more than a frame, therefore not > acceptable if we want to maintain <1 frame accuracy. Or at least that is how > I think it should work. I’ve found that aresample=async=1:min_hard_comp=0.01, as discussed here, works well to add audio samples to maintain timestamp accuracy when muxing into a format like mov. However, this approach doesn’t work if the sparseness of the audio stream is at the end of the stream. Is there a way to use min_hard_comp to consider differences between a timestamp and audio data when one of the ends of that range is the end of the file? Best Regards, Dave Rice ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> 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, 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: >>>>>> Hi Marton, >>>>>>> On Oct 31, 2020, at 12:56 PM, Marton Balint >>>>>> <mailto:c...@passwd.hu>> wrote: >>>>>>> Fixes out of sync timestamps in ticket #8762. >>>>>> Although Michael’s recent patch does address the issue documented in >>>>>> 8762, I haven’t found this patch to fix the issue. I tried with -c:a >>>>>> copy and with -c:a pcm_s16le with some sample files that exhibit this >>>>>> issue but each output was out of sync. I put an output at >>>>>> https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795 >>>>>> <https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795>. That >>>>>> output notes that 3597 packages of video are read and 3586 packets of >>>>>> audio. In the resulting file, at the end of the timeline the audio is 9 >>>>>> frames out of sync and my output video stream is 00:02:00.020 and output >>>>>> audio stream is 00:01:59.653. >>>>>> Beyond copying or encoding the audio, are there other options I should >>>>>> use to test this? >>>>> Well, it depends on what you want. After this patch you should get a file >>>>> which has audio packets synced to video, but the audio stream is sparse, >>>>> not every video packet has a corresponding audio packet. (It looks like >>>>> our MOV muxer does not support muxing of sparse audio therefore does not >>>>> produce proper timestamps. But MKV does, please try that.) >>>>> You can also make ffmpeg generate the missing audio based on packet >>>>> timestamps. Swresample has an async=1 option, so something like this >>>>> should get you synced audio with continous audio packets: >>>>> ffmpeg -y -i 167052_12.dv -c:v copy \ >>>>> -af aresample=async=1:min_hard_comp=0.01 -c:a pcm_s16le 167052_12.mov >>>> Thank you for this. With the patch and async, the result is synced and the >>>> resulting audio was the same as Michael’s patch. >>>> Could you explain why you used min_hard_comp here? IIUC min_hard_comp is a >>>> set a threshold between the strategies of trim/fill or stretch/squeeze to >>>> align the audio to time; however, the async documentation says "Setting >>>> this to 1 will enable filling and trimming, larger values represent the >>>> maximum amount in samples that the data may be stretched or squeezed” so I >>>> thought that async=1 would not permit stretch/squeeze anyway. >>> It is documented poorly, but if you check the source code you will see that >>> async=1 implicitly sets min_comp to 0.001 enabling trimming/dropping. >>> min_hard_comp decides the threshold when silence injection actually >>> happens, and the default for that is 0.1, which is more than a frame, >>> therefore not acceptable if we want to maintain <1 frame accuracy. Or at >>> least that is how I think it should work. >> > >> I’ve found that aresample=async=1:min_hard_comp=0.01, as discussed here, >> works well to add audio samples to maintain timestamp accuracy when muxing >> into a format like mov. However, this approach doesn’t work if the >> sparseness of the audio stream is at the end of the stream. Is there a way >> to use min_hard_comp to consider differences between a timestamp and audio >> data when one of the ends of that range is the end of the file? > > I am not aware of a smart method to generate missing audio in the end until > the end of video. > > As a possible workaround you may query the video length using > ffprobe or mediainfo, and then use a second filter, apad to pad audio: > > -af aresample=async=1:min_hard_comp=0.01,apad=whole_dur= > > Tnis might do what you want, but requires an additional step to query the > video length… […] Perfect, thanks for sharing this idea. 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".
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix memleak
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/libavformat/mov.c b/libavformat/mov.c
>> index adc52de947..f179b6efdd 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -7357,10 +7357,9 @@ static int mov_read_close(AVFormatContext *s)
>> av_freep(&sc->coll);
>> }
>>
>> -if (mov->dv_demux) {
>> -avformat_free_context(mov->dv_fctx);
>> -mov->dv_fctx = NULL;
>> -}
>> +av_freep(&mov->dv_demux);
>> +avformat_free_context(mov->dv_fctx);
>> +mov->dv_fctx = NULL;
>>
>> if (mov->meta_keys) {
>> for (i = 1; i < mov->meta_keys_count; i++) {
>>
> Do you have a sample for this? I am asking because there are more
> memleaks related to dv audio and I have a patch [1] for them, but I
> never found any sample for dv in mov/mp4, so it was never applied.
I’m working with a lot of DV lately. Could you clarify what type of sample that
you are looking for?
> If I am not mistaken, then you are not only fixing a leak of dv_fctx in
> case allocation of dv_demux failed; you are also fixing a leak of
> dv_demux itself in the ordinary case where it could be successfully
> allocated. This should be reflected in the commit message.
>
> - Andreas
>
> [1]:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190916155502.17579-3-andreas.rheinha...@gmail.com/
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH v1] avfilter: add colorstats, colorrgbstats, coloryuvstats video filter
> 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 rather than have two filters with such a
substantial overlap.
> On 12/27/19, Limin Wang wrote:
>> On Fri, Dec 27, 2019 at 03:20:19PM +0100, Paul B Mahol wrote:
>>> On 12/27/19, Limin Wang wrote:
On Fri, Dec 27, 2019 at 12:35:25PM +0100, Paul B Mahol wrote:
> You are duplicating some functionality of signalstats filter.
>
Yes, I have other function need to use the mean and stdev which is
support in showinfo filter(only 8bit and don't support packed format,
no multi-thread), and signalstats don't support rgb format and don't
have stdev, also it have too many other function and difficult to change
it, so I think it's more simple to create a new filter to do it.
>>>
>>> No, unacceptable. use signalstats filter.
>>
>> The performance is one major reason also, below is the profiling result for
>> performance:
>>
>> ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
>> bench=start,signalstats,bench=stop -f null -
>> [bench @ 0x3fb9080] t:0.161589 avg:0.165756 max:0.169923 min:0.161589
>> [bench @ 0x3fb9080] t:0.160334 avg:0.163948 max:0.169923 min:0.160334
>> [bench @ 0x3fb9080] t:0.160345 avg:0.163047 max:0.169923 min:0.160334
>> [bench @ 0x3fb9080] t:0.160924 avg:0.162623 max:0.169923 min:0.160334
>> [bench @ 0x3fb9080] t:0.160318 avg:0.162238 max:0.169923 min:0.160318
>>
>> ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
>> bench=start,colorstats,bench=stop -f null -
>> [bench @ 0x26f6100] t:0.012596 avg:0.012612 max:0.012628 min:0.012596
>> [bench @ 0x26f6100] t:0.012542 avg:0.012588 max:0.012628 min:0.012542
>> [bench @ 0x26f6100] t:0.012529 avg:0.012573 max:0.012628 min:0.012529
>> [bench @ 0x26f6100] t:0.012532 avg:0.012565 max:0.012628 min:0.012529
>> [bench @ 0x26f6100] t:0.012527 avg:0.012559 max:0.012628 min:0.012527
>> [bench @ 0x26f6100] t:0.012525 avg:0.012554 max:0.012628 min:0.012525
>> [bench @ 0x26f6100] t:0.012522 avg:0.012550 max:0.012628 min:0.012522
>> [bench @ 0x26f6100] t:0.012552 avg:0.012550 max:0.012628 min:0.012522
>>
>>
>>>
> On 12/27/19, lance.lmw...@gmail.com wrote:
>> From: Limin Wang
>>
>> Signed-off-by: Limin Wang
>> ---
>> doc/filters.texi| 74 ++
>> libavfilter/Makefile| 1 +
>> libavfilter/allfilters.c| 3 +
>> libavfilter/vf_colorstats.c | 461
>>
>> 4 files changed, 539 insertions(+)
>> create mode 100644 libavfilter/vf_colorstats.c
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 8c5d3a5760..81968b2c17 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -7695,6 +7695,80 @@ For example to convert the input to
>> SMPTE-240M,
>> use
>> the command:
>> colorspace=smpte240m
>> @end example
>>
>> +@section colorstats, colorrgbstats, coloryuvstats
>> +The filter provides statistical video measurements such as mean,
>> minimum,
>> maximum and
>> +standard deviation for each frame. The user can check for
>> unexpected/accidental errors
>> +very quickly with them.
>> +
>> +@var{colorrgbstats} report the color stats for RGB input video,
>> @var{coloryuvstats}
>> +to an YUV input video.
>> +
>> +These filters accept the following parameters:
>> +@table @option
>> +@item planes
>> +Set which planes to filter. Default is only the first plane.
>> +@end table
>> +
>> +By default the filter will report these metadata values if the
>> planes
>> +are processed:
>> +
>> +@table @option
>> +@item min.y, min.u, min.v, min.r, min.g, min.b, min.a
>> +Display the minimal Y/U/V/R/G/B/A plane value contained within the
>> input
>> frame.
>> +Expressed in range of [0, 1<> +
>> +@item pmin.y, pmin.u, pmin.v, pmin.r, pmin.g, pmin.b, min.a
>> +Display the minimal Y/U/V/R/G/B/A plane percentage of maximum
>> contained
>> within
>> +the input frame. Expressed in range of [0, 1]
>> +
>> +@item max.y, max.u, max.v, max.r, max.g, max.b, max.a
>> +Display the maximum Y/U/V/R/G/B/A plane value contained within the
>> input
>> frame.
>> +Expressed in range of [0, 1<> +
>> +@item pmax.y, pmax.u, pmax.v, pmax.r, pmax.g, pmax.b, pmax.a
>> +Display the maximum Y/U/V/R/G/B/A plane percentage of maximum
>> contained
>> within
>> +the input frame. Expressed in range of [0, 1]
>> +
>> +@item mean.y, mean.u, mean.v, mean.r, mean.g, mean.b, mean.a
>> +Display the Y/U/V/R/G/B/A plane mean value contained within the
>> input
>> frame.
>> +Expressed in range of [0, 1<> +
>>>
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
On Jan 6, 2017, at 1:34 PM, Gerion Entrup wrote:
>
> On Donnerstag, 5. Januar 2017 02:26:23 CET Michael Niedermayer wrote:
>> On Wed, Jan 04, 2017 at 05:05:41PM +0100, Gerion Entrup wrote:
>>> On Dienstag, 3. Januar 2017 16:58:32 CET Moritz Barsnick wrote:
>>>>>> The English opposite of "fine" is "coarse", not "course". :)
>>>>> Oops.
>>>>
>>>> You still have a few "courses". (The actual variables, not the types. I
>>>> don't care *too* much, but might be better for consistency.)
>>> You're right. Fixed version attached.
>>>
>>>
>>>> From my side - mostly style and docs - it looks fine. Technically, I
>>>> can't judge too much. You went through a long review cycle already, so
>>>> I assume it's fine for those previous reviewers. They have the last
>>>> call anyway.
>>>
>>> What about FATE? I'm willing to write a test, but don't know the best way.
>>> There are official conditions, whether the signature is standard compliant.
>>> I've
>>> written a python script to proof that (see previous emails). Nevertheless
>>> the
>>> checks take relatively long and need 3GB inputvideo, so I assume this is
>>> not
>>> usable for FATE.
>>
>> yes, a 3gb reference is not ok for fate
>>
>>
>>>
>>> One way would be, to take a short input video, take the calculated
>>> signature
>>> and use this as reference, but the standard allow some bitflips and my code
>>> has some of them in comparison to the reference signatures.
>>
>> then the fate test could/should compare and pass if its within what
>> we expect of our code. (which may be stricter than the reference
>> allowance)
>> there are already tests that do similar for comparing PCM/RAW
> Ok, will try to create a test the next days.
>
>
>>> +#define OFFSET(x) offsetof(SignatureContext, x)
>>
>>> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM
>>
>> should contin also AV_OPT_FLAG_FILTERING_PARAM
> Done.
>
>
>>> +static int export(AVFilterContext *ctx, StreamContext *sc, int input)
>>> +{
>>> +SignatureContext* sic = ctx->priv;
>>> +char filename[1024];
>>> +
>>> +if (sic->nb_inputs > 1) {
>>
>>> +/* error already handled */
>>> +av_get_frame_filename(filename, sizeof(filename), sic->filename,
>>> input);
>>
>> its more robust to use a av_assert*() on the return code if its assumed
>> to be never failing than just a comment as a comment cannot be
>> automatcially checked for validity currently.
> I chose av_assert0 because the check is done only nb_inputs times.
>
> The attached patch also fixes the file writing for every frame the one input
> is
> longer than the other.
Just bumping this thread. I've been using the patch and find it very helpful
and would like to see it in libavfilter.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
> On Mar 20, 2017, at 10:13 AM, Paul B Mahol wrote:
>
> On 3/20/17, Dave Rice wrote:
>> On Jan 6, 2017, at 1:34 PM, Gerion Entrup
>> wrote:
>>>
>>> On Donnerstag, 5. Januar 2017 02:26:23 CET Michael Niedermayer wrote:
>>>> On Wed, Jan 04, 2017 at 05:05:41PM +0100, Gerion Entrup wrote:
>>>>> On Dienstag, 3. Januar 2017 16:58:32 CET Moritz Barsnick wrote:
>>>>>>>> The English opposite of "fine" is "coarse", not "course". :)
>>>>>>> Oops.
>>>>>>
>>>>>> You still have a few "courses". (The actual variables, not the types. I
>>>>>> don't care *too* much, but might be better for consistency.)
>>>>> You're right. Fixed version attached.
>>>>>
>>>>>
>>>>>> From my side - mostly style and docs - it looks fine. Technically, I
>>>>>> can't judge too much. You went through a long review cycle already, so
>>>>>> I assume it's fine for those previous reviewers. They have the last
>>>>>> call anyway.
>>>>>
>>>>> What about FATE? I'm willing to write a test, but don't know the best
>>>>> way.
>>>>> There are official conditions, whether the signature is standard
>>>>> compliant. I've
>>>>> written a python script to proof that (see previous emails).
>>>>> Nevertheless the
>>>>> checks take relatively long and need 3GB inputvideo, so I assume this is
>>>>> not
>>>>> usable for FATE.
>>>>
>>>> yes, a 3gb reference is not ok for fate
>>>>
>>>>
>>>>>
>>>>> One way would be, to take a short input video, take the calculated
>>>>> signature
>>>>> and use this as reference, but the standard allow some bitflips and my
>>>>> code
>>>>> has some of them in comparison to the reference signatures.
>>>>
>>>> then the fate test could/should compare and pass if its within what
>>>> we expect of our code. (which may be stricter than the reference
>>>> allowance)
>>>> there are already tests that do similar for comparing PCM/RAW
>>> Ok, will try to create a test the next days.
>>>
>>>
>>>>> +#define OFFSET(x) offsetof(SignatureContext, x)
>>>>
>>>>> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM
>>>>
>>>> should contin also AV_OPT_FLAG_FILTERING_PARAM
>>> Done.
>>>
>>>
>>>>> +static int export(AVFilterContext *ctx, StreamContext *sc, int input)
>>>>> +{
>>>>> +SignatureContext* sic = ctx->priv;
>>>>> +char filename[1024];
>>>>> +
>>>>> +if (sic->nb_inputs > 1) {
>>>>
>>>>> +/* error already handled */
>>>>> +av_get_frame_filename(filename, sizeof(filename),
>>>>> sic->filename, input);
>>>>
>>>> its more robust to use a av_assert*() on the return code if its assumed
>>>> to be never failing than just a comment as a comment cannot be
>>>> automatcially checked for validity currently.
>>> I chose av_assert0 because the check is done only nb_inputs times.
>>>
>>> The attached patch also fixes the file writing for every frame the one
>>> input is
>>> longer than the other.
>>
>> Just bumping this thread. I've been using the patch and find it very helpful
>> and would like to see it in libavfilter.
>
> I do not care as long its GPL.
Gerion's last post on this thread appears to resolve all review comments but
indicated that he would create a FATE test for the filter. Since the patch has
been reviewed, I suggest that the missing FATE test could be a later patch and
not block consideration of merging the signature filter. As noted, it is
written with GPL.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter
> +char text[128];
> +
> +w = 200 / s->w;
> +h = 200 / s->h;
> +
> +if (s->x <= 210 && s->y <= 300) {
> +X = in->width - 210;
> +Y = in->height - 300;
> +} else {
> +X = 0;
> +Y = 0;
> +}
> +
> +ff_blend_rectangle(&s->draw, &s->dark, in->data, in->linesize,
> + in->width, in->height,
> + X,
> + Y,
> + 210,
> + 300);
> +
> +ff_blend_rectangle(&s->draw, &s->black, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 2, s->y - 2, s->w + 4, 1);
> +
> +ff_blend_rectangle(&s->draw, &s->white, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 1, s->y - 1, s->w + 2, 1);
> +
> +ff_blend_rectangle(&s->draw, &s->white, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 1, s->y - 1, 1, s->h + 2);
> +
> +ff_blend_rectangle(&s->draw, &s->black, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 2, s->y - 2, 1, s->h + 4);
> +
> +ff_blend_rectangle(&s->draw, &s->white, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 1, s->y + 1 + s->h, s->w + 3, 1);
> +
> +ff_blend_rectangle(&s->draw, &s->black, in->data, in->linesize,
> + in->width, in->height,
> + s->x - 2, s->y + 2 + s->h, s->w + 4, 1);
> +
> +ff_blend_rectangle(&s->draw, &s->white, in->data, in->linesize,
> + in->width, in->height,
> + s->x + 1 + s->w, s->y - 1, 1, s->h + 2);
> +
> +ff_blend_rectangle(&s->draw, &s->black, in->data, in->linesize,
> + in->width, in->height,
> + s->x + 2 + s->w, s->y - 2, 1, s->h + 5);
> +
> +for (y = 0; y < s->h; y++) {
> +for (x = 0; x < s->w; x++) {
> +FFDrawColor color = { { 0 } };
> +int value[4] = { 0 };
> +
> +s->pick_color(&s->draw, &color, in, x + s->x, y + s->y, value);
> +ff_fill_rectangle(&s->draw, &color, in->data, in->linesize,
> + x * w + (210 - (s->w * w)) / 2 + X, y * h + 2
> + Y, w, h);
> +for (i = 0; i < 4; i++) {
> +average[i] += value[i];
> +min[i] = FFMIN(min[i], value[i]);
> +max[i] = FFMAX(max[i], value[i]);
> +}
> +}
> +}
> +
> +for (i = 0; i < 4; i++) {
> +average[i] /= s->w * s->h;
> +}
> +
> +snprintf(text, sizeof(text), "CH AVG MINMAX\n");
> +draw_text(&s->draw, in, &s->white, X + 18, Y +
> 30 + 200 + 2, text, 0);
> +snprintf(text, sizeof(text), "%c %07.1f %05d %05d\n", s->is_rgb ?
> rgba[0] : yuva[0], average[s->rgba_map[0]], min[s->rgba_map[0]],
> max[s->rgba_map[0]]);
> +draw_text(&s->draw, in, s->is_rgb ? &s->red : &s->white, X + 18, Y +
> 30 + 200 + 15, text, 0);
> +snprintf(text, sizeof(text), "%c %07.1f %05d %05d\n", s->is_rgb ?
> rgba[1] : yuva[1], average[s->rgba_map[1]], min[s->rgba_map[1]],
> max[s->rgba_map[1]]);
> +draw_text(&s->draw, in, s->is_rgb ? &s->green : &s->blue, X + 18, Y +
> 30 + 200 + 30, text, 0);
> +snprintf(text, sizeof(text), "%c %07.1f %05d %05d\n", s->is_rgb ?
> rgba[2] : yuva[2], average[s->rgba_map[2]], min[s->rgba_map[2]],
> max[s->rgba_map[2]]);
> +draw_text(&s->draw, in, s->is_rgb ? &s->blue : &s->red, X + 18, Y +
> 30 + 200 + 45, text, 0);
> +
> +return ff_filter_frame(outlink, in);
> +}
> +
> +static const AVFilterPad pixscope_inputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.filter_frame = pixscope_filter_frame,
> +.config_props = pixscope_config_input,
> +.needs_writable = 1,
> +},
> +{ NULL }
> +};
> +
> +static const AVFilterPad pixscope_outputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +},
> +{ NULL }
> +};
> +
> +AVFilter ff_vf_pixscope = {
> +.name = "pixscope",
> +.description = NULL_IF_CONFIG_SMALL("Pixel data analysis."),
> +.priv_size = sizeof(PixscopeContext),
> +.priv_class= &pixscope_class,
> +.query_formats = query_formats,
> +.inputs= pixscope_inputs,
> +.outputs = pixscope_outputs,
> +};
> --
> 2.9.3
I tested this filter and find it very useful, but could it be adjusted to
handle full range video. Currently when I test with a sample such as:
./ffplay -f lavfi -i
color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
The outputs list Y=235, U=240, V=16.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter
> On Apr 24, 2017, at 4:47 PM, Paul B Mahol wrote: > > On 4/24/17, Dave Rice wrote: >> >> I tested this filter and find it very useful, but could it be adjusted to >> handle full range video. Currently when I test with a sample such as: >> >> ./ffplay -f lavfi -i >> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope >> >> The outputs list Y=235, U=240, V=16. > > Hmm, I cannot reproduce this with my old ffplay build or latest mpv or > latest ffmpeg. > > So it must be ffplay issue. Can you recreate it with: ./ffmpeg -f lavfi -i color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope -f nut - | mpv - Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] avfilter: add video oscilloscope filter
for (i = 0; i < 4; i++) {
> +out->data[0][y0 * out->linesize[0] + x0 *
> draw->pixelstep[0] + i] = color->comp[0].u8[i];
> +}
> +} else {
> +out->data[p][out->linesize[p] * (y0 >> draw->vsub[p]) + (x0
> >> draw->hsub[p])] = color->comp[p].u8[0];
> +}
> +}
> +
> +if (x0 == x1 && y0 == y1)
> +break;
> +
> +e2 = err;
> +
> +if (e2 >-dx) {
> +err -= dy;
> +x0 += sx;
> +}
> +
> +if (e2 < dy) {
> +err += dx;
> +y0 += sy;
> +}
> +}
> +}
> +
> +static int oscilloscope_filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +OscilloscopeContext *s = ctx->priv;
> +AVFilterLink *outlink = ctx->outputs[0];
> +float average[4] = { 0 };
> +int max[4] = { 0 };
> +int min[4] = { INT_MAX, INT_MAX, INT_MAX, INT_MAX };
> +int i, c;
> +
> +s->nb_values = 0;
> +draw_scope(s, s->x1, s->y1, s->x2, s->y2, frame, s->values);
> +ff_blend_rectangle(&s->draw, &s->dark, frame->data, frame->linesize,
> + frame->width, frame->height,
> + s->ox, s->oy, s->width, 300);
It appears that the plotted scope is padded to 300, though the trace usually is
256 (2^8) lines tall. Are the other 44 lines intended to store something?
> +if (s->grid) {
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox, s->oy, s->width - 1, 1);
> +
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox, s->oy + 64, s->width, 1);
> +
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox, s->oy + 128, s->width, 1);
> +
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox, s->oy + 192, s->width, 1);
> +
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox, s->oy + 256, s->width, 1);
> +
> +for (i = 0; i < 10; i++) {
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data,
> frame->linesize,
> + s->ox + i * (s->width - 1) / 10, s->oy, 1,
> 256);
> +}
> +
> +ff_fill_rectangle(&s->draw, &s->gray, frame->data, frame->linesize,
> + s->ox + s->width - 1, s->oy, 1, 256);
> +}
> +
> +for (i = 1; i < s->nb_values; i++) {
> +for (c = 0; c < s->nb_comps; c++) {
> +if ((1 << c) & s->components) {
> +int x = i * s->width / s->nb_values;
> +int px = (i - 1) * s->width / s->nb_values;
> +int py = 255 - s->values[i-1].p[c];
> + int y = 255 - s->values[i].p[c];
> +
> +draw_line(&s->draw, s->ox + x, s->oy + y, s->ox + px, s->oy
> + py, frame, s->colors[c]);
> +}
> +}
> +}
> +
> +return ff_filter_frame(outlink, frame);
> +}
> +
> +static const AVFilterPad oscilloscope_inputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.filter_frame = oscilloscope_filter_frame,
> +.config_props = oscilloscope_config_input,
> +.needs_writable = 1,
> +},
> +{ NULL }
> +};
> +
> +static const AVFilterPad oscilloscope_outputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +},
> +{ NULL }
> +};
> +
> +AVFilter ff_vf_oscilloscope = {
> +.name = "oscilloscope",
> +.description = NULL_IF_CONFIG_SMALL("2D Video Oscilloscope."),
> +.priv_size = sizeof(OscilloscopeContext),
> +.priv_class= &oscilloscope_class,
> +.query_formats = query_formats,
> +.uninit= oscilloscope_uninit,
> +.inputs= oscilloscope_inputs,
> +.outputs = oscilloscope_outputs,
> +};
> --
> 2.9.3
A crash on >8 bit:
./ffplay -f lavfi -i mandelbrot -vf format=yuv422p10le,oscilloscope
ffplay version N-85657-gd2e300a0a0 Copyright (c) 2003-2017 the FFmpeg developers
built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
configuration: --disable-dwt
libavutil 55. 61.100 / 55. 61.100
libavcodec 57. 93.100 / 57. 93.100
libavformat57. 72.101 / 57. 72.101
libavdevice57. 7.100 / 57. 7.100
libavfilter 6. 87.100 / 6. 87.100
libswscale 4. 7.101 / 4. 7.101
libswresample 2. 8.100 / 2. 8.100
Input #0, lavfi, from 'mandelbrot':0KB vq=0KB sq=0B f=0/0
Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[0] / 0x424752), rgb0, 640x480 [SAR 1:1
DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Segmentation fault: 11
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter
> On Apr 24, 2017, at 5:03 PM, Paul B Mahol wrote: > > On 4/24/17, Dave Rice wrote: >> >>> On Apr 24, 2017, at 4:47 PM, Paul B Mahol wrote: >>> >>> On 4/24/17, Dave Rice wrote: >>>> >>>> I tested this filter and find it very useful, but could it be adjusted to >>>> handle full range video. Currently when I test with a sample such as: >>>> >>>> ./ffplay -f lavfi -i >>>> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope >>>> >>>> The outputs list Y=235, U=240, V=16. >>> >>> Hmm, I cannot reproduce this with my old ffplay build or latest mpv or >>> latest ffmpeg. >>> >>> So it must be ffplay issue. >> >> Can you recreate it with: >> >> ./ffmpeg -f lavfi -i >> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope -f >> nut - | mpv - > > No. > > Neither with: > > ./ffmpeg -f lavfi -i > color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope > -f nut -c:v rawvideo - | mpv - > > or: > > mpv > avdevice://lavfi:color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope > > I hard reset my copy of the repo, re-applied the patch, and now it works as expected. Thanks. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] avfilter: add video oscilloscope filter
> On Apr 26, 2017, at 2:37 AM, Paul B Mahol wrote: > > On 4/26/17, Dave Rice wrote: >> >> >> I'm curious why floats are used for x,y coordinates within a frame rather >> than integers. > > So it the position be set relatively. And for similar results for > different resolutions. Having been used to other filters with integers as x,y, this seems a bit unintuitive to me. In other filters relative positions are set by variables, such as ih/2 as opposed to 0.5. If staying with floats, I'd suggest that the documentation include examples for the use of calling specific lines by integer by including math in the options. Perhaps the statistical area could also state the x,y coords of the two ends of the scope as ints so that a viewer of the image would be clear to what line(s) are included in the analysis. >> It appears that the plotted scope is padded to 300, though the trace usually >> is 256 (2^8) lines tall. Are the other 44 lines intended to store something? >> > > Yes, some statistics numbers. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: write clap tag
> 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
>>> would be written on any mov file with a video stream.
>>
>> This was addressed a previous email:
>>
>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html
>>
>> I guess the spec is up for interpretation.
>
> The quicktime spec says "This is a mandatory extension for all uncompressed
> Y´CbCr data formats”. It doesn’t clarify if the clap atom is recommended or
> not in mov files that are not “uncompressed Y´CbCr”, though it would make
> sense if the video container needs to store cropping data. I think
> constraining the change for only “uncompressed Y´CbCr” would be more
> cautious though. I’ll revise my patch to include the condition and resubmit.
>
> If the patch only impacts “uncompressed Y´CbCr” would any fate updates be
> needed?
> Dave Rice
Here’s an update to only write the clap atom for the specific uncompressed
encodings listed in TN2162.
From 37457c1ee135f39452b91b047af4adf1ec43464b Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:29:06 -0500
Subject: [PATCH] avformat/movenc: write clap atom for uncompressed yuv in mov
fixes 6145
---
libavformat/movenc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..18232e8ba3 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1686,6 +1686,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
{
AVRational sar;
@@ -1970,6 +1985,16 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
mov_write_pasp_tag(pb, track);
}
+int uncompressed_ycbcr = ((track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_UYVY422)
+ || (track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_YUYV422)
+ || track->par->codec_id == AV_CODEC_ID_V308
+ || track->par->codec_id == AV_CODEC_ID_V408
+ || track->par->codec_id == AV_CODEC_ID_V410
+ || track->par->codec_id == AV_CODEC_ID_V210);
+if (uncompressed_ycbcr){
+mov_write_clap_tag(pb, track);
+}
+
if (mov->encryption_scheme != MOV_ENC_NONE) {
ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
}
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410
This corrects a few values in the Image Description for v210 and v410 in mov. Apple defines what the depth value for these uncompressed formats should be in https://developer.apple.com/library/content/technotes/tn2162/_index.html <https://developer.apple.com/library/content/technotes/tn2162/_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/_index.html . --- libavformat/movenc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 18232e8ba3..f7b08e2885 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1885,7 +1885,11 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr avio_w8(pb, strlen(compressor_name)); avio_write(pb, compressor_name, 31); -if (track->mode == MODE_MOV && track->par->bits_per_coded_sample) +if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V410) +avio_wb16(pb, 0x18); +else if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V210) +avio_wb16(pb, 0x18); +else if (track->mode == MODE_MOV && track->par->bits_per_coded_sample) avio_wb16(pb, track->par->bits_per_coded_sample | (track->par->format == AV_PIX_FMT_GRAY8 ? 0x20 : 0)); else -- 2.15.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: write clap tag
> 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:
>>>> Isn't this necessary only for files with raw video? As is, this box
>>>> would be written on any mov file with a video stream.
>>>
>>> This was addressed a previous email:
>>>
>>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html
>>>
>>> I guess the spec is up for interpretation.
>>
>> The quicktime spec says "This is a mandatory extension for all uncompressed
>> Y´CbCr data formats”. It doesn’t clarify if the clap atom is recommended or
>> not in mov files that are not “uncompressed Y´CbCr”, though it would make
>> sense if the video container needs to store cropping data. I think
>> constraining the change for only “uncompressed Y´CbCr” would be more
>> cautious though. I’ll revise my patch to include the condition and resubmit.
>>
>> If the patch only impacts “uncompressed Y´CbCr” would any fate updates be
>> needed?
>> Dave Rice
>
> Here’s an update to only write the clap atom for the specific uncompressed
> encodings listed in TN2162.
>
> From 37457c1ee135f39452b91b047af4adf1ec43464b Mon Sep 17 00:00:00 2001
> From: Dave Rice
> Date: Thu, 16 Nov 2017 11:29:06 -0500
> Subject: [PATCH] avformat/movenc: write clap atom for uncompressed yuv in mov
Sorry, this patch should supersede the prior email's patch. I realized that
Apple requires new uncompressed ycbcr files to use version 2 in the Image
Description, so I reused the uncompressed_ycbcr variable to add that in as well.
From 3ea99e7d22f67b8a556152acbcbc8bf2eeec8a39 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:29:06 -0500
Subject: [PATCH 1/2] avformat/movenc: write clap atom for uncompressed yuv in
mov
fixes 6145
---
libavformat/movenc.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..98fcc7a44b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1686,6 +1686,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
{
AVRational sar;
@@ -1832,6 +1847,13 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
char compressor_name[32] = { 0 };
int avid = 0;
+int uncompressed_ycbcr = ((track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_UYVY422)
+ || (track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_YUYV422)
+ || track->par->codec_id == AV_CODEC_ID_V308
+ || track->par->codec_id == AV_CODEC_ID_V408
+ || track->par->codec_id == AV_CODEC_ID_V410
+ || track->par->codec_id == AV_CODEC_ID_V210);
+
avio_wb32(pb, 0); /* size */
if (mov->encryption_scheme != MOV_ENC_NONE) {
ffio_wfourcc(pb, "encv");
@@ -1842,7 +1864,11 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
avio_wb16(pb, 0); /* Reserved */
avio_wb16(pb, 1); /* Data-reference index */
-avio_wb16(pb, 0); /* Codec stream version */
+if (uncompressed_ycbcr) {
+avio_wb16(pb, 2); /* Codec stream version */
+} else {
+avio_wb16(pb, 0); /* Codec stream version */
+}
avio_wb16(pb, 0); /* Codec stream revision (=0) */
if (track->mode == MODE_MOV) {
ffio_wfourcc(pb, "FFMP"); /* Vendor */
@@ -1969,6 +1995,10 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
if (track->par->sample_aspect_ratio.den &&
track->par->sample_aspect_ratio.num) {
mov_write_pasp_tag(pb, track);
}
+
+if (uncompressed_ycbcr){
+mov_write_clap_tag(pb, track);
+}
if (mov->encryption_scheme != MOV_ENC_NONE) {
ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410
> 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 (track->mode == MODE_MOV && track->par->codec_id == >> AV_CODEC_ID_V210) >> +avio_wb16(pb, 0x18); > > It appears you can merge the two cases. The patch is updated with merged cases below. > Or maybe patch bits_per_coded_sample in the encoder… With Apple’s TN2162 there doesn’t appear to be a reliable relationship between the bits_per_coded_sample and what the ImageDescription depth value should be for the uncompressed yuv formats. TN2162 simply lists what the depth value should be and this patch corrects the few instances, where ffmpeg’s behavior doesn’t correlate to what TN2162 defines. From cfa5b2cd959154f2896a9557d9ca2ed2d2d3834e Mon Sep 17 00:00:00 2001 From: Dave Rice Date: Thu, 16 Nov 2017 11:53:32 -0500 Subject: [PATCH 2/2] avformat/movenc: correct ImageDescription depth for v210 v410 Per https://developer.apple.com/library/content/technotes/tn2162/_index.html . --- libavformat/movenc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 98fcc7a44b..d9d3c2bf1e 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1896,7 +1896,10 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr avio_w8(pb, strlen(compressor_name)); avio_write(pb, compressor_name, 31); -if (track->mode == MODE_MOV && track->par->bits_per_coded_sample) +if (track->mode == MODE_MOV && + (track->par->codec_id == AV_CODEC_ID_V410 || track->par->codec_id == AV_CODEC_ID_V210)) +avio_wb16(pb, 0x18); +else if (track->mode == MODE_MOV && track->par->bits_per_coded_sample) avio_wb16(pb, track->par->bits_per_coded_sample | (track->par->format == AV_PIX_FMT_GRAY8 ? 0x20 : 0)); else -- 2.15.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avformat/movenc: write clap atom for uncompressed yuv in mov
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 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ce51c4b3d2..aaa1dedfd7 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1686,6 +1686,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
{
AVRational sar;
@@ -1984,6 +1999,10 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
mov_write_pasp_tag(pb, track);
}
+if (uncompressed_ycbcr){
+mov_write_clap_tag(pb, track);
+}
+
if (mov->encryption_scheme != MOV_ENC_NONE) {
ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
}
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avformat/movenc: correct ImageDescription for uncompressed ycbcr
This patch set updates movenc to write uncompressed ycbcr in mov following
requirements in Apple’s TN2162,
https://developer.apple.com/library/content/technotes/tn2162/_index.html.
Thanks to Carl and Michael for comments on an earlier version of this patchset.
From 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 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..ce51c4b3d2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1832,6 +1832,13 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
char compressor_name[32] = { 0 };
int avid = 0;
+int uncompressed_ycbcr = ((track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_UYVY422)
+ || (track->par->codec_id == AV_CODEC_ID_RAWVIDEO &&
track->par->format == AV_PIX_FMT_YUYV422)
+ || track->par->codec_id == AV_CODEC_ID_V308
+ || track->par->codec_id == AV_CODEC_ID_V408
+ || track->par->codec_id == AV_CODEC_ID_V410
+ || track->par->codec_id == AV_CODEC_ID_V210);
+
avio_wb32(pb, 0); /* size */
if (mov->encryption_scheme != MOV_ENC_NONE) {
ffio_wfourcc(pb, "encv");
@@ -1842,11 +1849,15 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
avio_wb16(pb, 0); /* Reserved */
avio_wb16(pb, 1); /* Data-reference index */
-avio_wb16(pb, 0); /* Codec stream version */
+if (uncompressed_ycbcr) {
+avio_wb16(pb, 2); /* Codec stream version */
+} else {
+avio_wb16(pb, 0); /* Codec stream version */
+}
avio_wb16(pb, 0); /* Codec stream revision (=0) */
if (track->mode == MODE_MOV) {
ffio_wfourcc(pb, "FFMP"); /* Vendor */
-if (track->par->codec_id == AV_CODEC_ID_RAWVIDEO) {
+if (track->par->codec_id == AV_CODEC_ID_RAWVIDEO ||
uncompressed_ycbcr) {
avio_wb32(pb, 0); /* Temporal Quality */
avio_wb32(pb, 0x400); /* Spatial Quality = lossless*/
} else {
@@ -1870,7 +1881,10 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
avio_w8(pb, strlen(compressor_name));
avio_write(pb, compressor_name, 31);
-if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
+if (track->mode == MODE_MOV &&
+ (track->par->codec_id == AV_CODEC_ID_V410 || track->par->codec_id ==
AV_CODEC_ID_V210))
+avio_wb16(pb, 0x18);
+else if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
avio_wb16(pb, track->par->bits_per_coded_sample |
(track->par->format == AV_PIX_FMT_GRAY8 ? 0x20 : 0));
else
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov
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
As required by Apple’s TN2162.
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index aaa1dedfd7..86960b19c1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1978,7 +1978,7 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
else
av_log(mov->fc, AV_LOG_WARNING, "Not writing 'gama' atom. Format
is not MOV.\n");
}
-if (mov->flags & FF_MOV_FLAG_WRITE_COLR) {
+if (mov->flags & FF_MOV_FLAG_WRITE_COLR || uncompressed_ycbcr) {
if (track->mode == MODE_MOV || track->mode == MODE_MP4)
mov_write_colr_tag(pb, track);
else
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] fate: add v210 mov test
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(+) create mode 100644 tests/ref/vsynth/vsynth1-mov-v210 diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index bbcf25d72a..0206312a53 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -360,6 +360,10 @@ fate-vsynth%-mov-bpp16: CODEC = rawvideo fate-vsynth%-mov-bpp16: ENCOPTS = -pix_fmt rgb565le fate-vsynth%-mov-bpp16: FMT = mov +FATE_VCODEC-$(call ENCDEC, V210, MOV) += mov-v210 +fate-vsynth%-mov-v210: CODEC = v210 +fate-vsynth%-mov-v210: FMT = mov + FATE_VCODEC-$(call ENCDEC, ROQ, ROQ)+= roqvideo fate-vsynth%-roqvideo: CODEC = roqvideo fate-vsynth%-roqvideo: ENCOPTS = -frames 5 diff --git a/tests/ref/vsynth/vsynth1-mov-v210 b/tests/ref/vsynth/vsynth1-mov-v210 new file mode 100644 index 00..035f8df6ff --- /dev/null +++ b/tests/ref/vsynth/vsynth1-mov-v210 @@ -0,0 +1,4 @@ +a96ffa7a9ccb8242cb462dd698b3e222 *tests/data/fate/vsynth1-mov-v210.mov +14746427 tests/data/fate/vsynth1-mov-v210.mov +2ba7f4ca302f3c4147860b9dfb12b6e4 *tests/data/fate/vsynth1-mov-v210.out.rawvideo +stddev:1.84 PSNR: 42.81 MAXDIFF: 29 bytes: 7603200/ 7603200 -- 2.15.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add queue option
> On Nov 19, 2017, at 2:19 PM, Nicolas George wrote:
>
> Paul B Mahol (2017-11-19):
>> So what you propose?
>
> I do not know. It is your patch, and I am not even sure I understood
> your explanation correctly.
IMHO, ‘queue' is a good name for what it does. Perhaps an additional example
would help demonstrate the option better. For example `ffplay -f lavfi -i
testsrc=r=1 -vf tile=1x8:overlap=7:queue=1` will display 8 adjoining frames of
the testsrc. Without `queue=1` in this example, the output will be stalled for
8 seconds before displaying, whereas with `queue=1` there will be an output
frame for each input frame (the first frame of the output simply showing the
first frame of the input plus seven empty spaces).
Suggestion:
@item
Produce a filmstrip animation from frame @code{n-7} to @code{n}:
@example
ffmpeg -i file.avi -vf 'tile=1x8: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
Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov
> 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
>>> 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
>>>
>>> As required by Apple’s TN2162.
>>> ---
>>> libavformat/movenc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index aaa1dedfd7..86960b19c1 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -1978,7 +1978,7 @@ static int mov_write_video_tag(AVIOContext *pb,
>>> MOVMuxContext *mov, MOVTrack *tr
>>> else
>>> av_log(mov->fc, AV_LOG_WARNING, "Not writing 'gama' atom.
>>> Format is not MOV.\n");
>>> }
>>> -if (mov->flags & FF_MOV_FLAG_WRITE_COLR) {
>>> +if (mov->flags & FF_MOV_FLAG_WRITE_COLR || uncompressed_ycbcr) {
>>> if (track->mode == MODE_MOV || track->mode == MODE_MP4)
>>> mov_write_colr_tag(pb, track);
>>> else
>>>
>>
>> The write_colr option says "Write colr atom (Experimental, may be
>> renamed or changed, do not use from scripts)". Does that still apply? Is
>> the feature/spec still experimental?
>>
>> If not, then the option and flag could be removed as well as part of
>> this patch.
>
> I believe it should be removed in a follow-up patch.
I am hesitant to see write_colr option removed since the guesswork used here
https://github.com/FFmpeg/FFmpeg/blob/8f4702a93f87f9f76563e80f1ae2141a40029d9d/libavformat/movenc.c#L1747-L1775
would then be applied to all movs of standard HD and SD size and cause many
ffmpeg outputs to appear differently after the change.
Could the guesswork here be removed? Or could write_colr be enabled with the
option removed while the guesswork itself has its own option?
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov
> 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/libavformat/movenc.c#L1747-L1775 >> would then be applied to all movs of standard HD and SD size and cause many >> ffmpeg outputs to appear differently after the change. > > 100% agree with this. We *should not* write guessed color information based > off of resolution by default. > > Further, if no color information is present, no colr atom should be written > at all, unless it is forced by the user (aka the write_colr option right > now). 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 colr atom provides an option for unspecified for each of the color values, so there's a method to write a colr atom which basically says ¯\_(ツ)_/¯. >> Could the guesswork here be removed? Or could write_colr be enabled with the >> option removed while the guesswork itself has its own option? > > If the quesswork is removed or put under an option, I still maintain no > colr atom should be written if no color information is known. Doing > so is just asking for trouble, in my opinion. I disagree. I'd prefer to follow the specification and write a colr atom (in the case of uncompressed yuv in mov) that say the colr is unspecified rather than to write no colr atom at all and create an invalid file. See https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9. I do agree that guesswork should be avoided or provided under an option that users could opt into. I suppose my preference order from support to oppose for writing uncompressed yuv in mov would be: 1: write a colr atom in all cases (if unknown, use unspecified values in colr atom) 2: write a colr atom if color data the known (no colr atom if unknown) 3: write a colr atom in all cases (if unknown, just make stuff up, #yolo) Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov
> 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
>> colr atom provides an option for unspecified for each of the color values,
>> so there's a method to write a colr atom which basically says ¯\_(ツ)_/¯.
>
> [...]
>
>> I disagree. I'd prefer to follow the specification and write a colr atom (in
>> the case of uncompressed yuv in mov) that say the colr is unspecified rather
>> than to write no colr atom at all and create an invalid file. See
>> https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9.
>>
>> I do agree that guesswork should be avoided or provided under an option that
>> users could opt into. I suppose my preference order from support to oppose
>> for writing uncompressed yuv in mov would be:
>>
>> 1: write a colr atom in all cases (if unknown, use unspecified values in
>> colr atom)
>> 2: write a colr atom if color data the known (no colr atom if unknown)
>> 3: write a colr atom in all cases (if unknown, just make stuff up, #yolo)
>
> My opinion falls somewhere in between, to something like this (in
> pseudo-code):
>
>if (colors_known) {
>write_colr(vals);
>} else if (uncompressed_yuv) {
>if (guesswork_user_option) {
>write_colr(guessed_hacky_crap);
>} else {
>write_colr(unspecified);
>}
>} else if (guesswork_user_option) {
>write_colr(guessed_hacky_crap);
>} else {
>// Don't write a colr atom because it adds no value, to write
> unspecified in it
>// and no spec requires it for compressed streams.
>}
What do you propose as the default for guessed_hacky_crap? Also are there
supporters for the need of a guessed_hacky_crap optio? Is there precedence in
ffmpeg to enable/disable guesswork via a user option?
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showwaves: add draw grid support
> On Nov 21, 2017, at 7:36 AM, Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi| 6 ++
> libavfilter/avf_showwaves.c | 28
> 2 files changed, 34 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 62f633c6f8..9c98f1684b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19178,6 +19178,12 @@ Cubic root.
> @end table
>
> Default is linear.
> +
> +@item grid
> +Draw grid, default is disabled.
> +
> +@item grid_color
> +Set grid color.
> @end table
>
> @subsection Examples
> diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
> index 0866967984..74d4886cd4 100644
> --- a/libavfilter/avf_showwaves.c
> +++ b/libavfilter/avf_showwaves.c
> @@ -69,6 +69,8 @@ typedef struct ShowWavesContext {
> int mode; ///< ShowWavesMode
> int scale; ///< ShowWavesScale
> int split_channels;
> +int grid;
> +uint8_t grid_rgba[4];
> uint8_t *fg;
>
> int (*get_h)(int16_t sample, int height);
> @@ -104,6 +106,8 @@ static const AVOption showwaves_options[] = {
> { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG},
> .flags=FLAGS, .unit="scale"},
> { "sqrt", "square root", 0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT},
> .flags=FLAGS, .unit="scale"},
> { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT},
> .flags=FLAGS, .unit="scale"},
> +{ "grid", "draw grid", OFFSET(grid), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
> FLAGS },
> +{ "grid_color", "set grid color", OFFSET(grid_rgba), AV_OPT_TYPE_COLOR,
> {.str="0x00"}, 0, 0, FLAGS },
> { NULL }
> };
>
> @@ -562,6 +566,30 @@ static int alloc_out_frame(ShowWavesContext *showwaves,
> const int16_t *p,
> outlink->time_base);
> for (j = 0; j < outlink->h; j++)
> memset(out->data[0] + j*out->linesize[0], 0, outlink->w *
> showwaves->pixstep);
> +
> +if (showwaves->grid) {
> +const int pixstep = showwaves->pixstep;
> +int ystep = showwaves->split_channels ? outlink->h /
> inlink->channels / 4 : outlink->h / 4;
> +int channels = showwaves->split_channels ? inlink->channels : 1;
> +int x, s, c, yskip = 0;
> +
> +for (c = 0; c < channels; c++) {
> +for (j = 0; j < 4; j++) {
> +for (x = 0; x < outlink->w; x+=3) {
> +for (s = 0; s < pixstep; s++) {
> +out->data[0][(yskip + j * ystep) *
> out->linesize[0] + x * pixstep + s] = showwaves->grid_rgba[s];
> +}
> +}
> +}
> +for (x = 0; x < outlink->w; x+=3) {
> +for (s = 0; s < 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
[FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
Hi,
I tested this with my Ultrastudio Express and confirmed that I'm getting higher
bit depth recordings with the abitscope filter. This patch adds an option to
get 32 bit audio as an input with the decklink device (beforehand only 16 bit
audio was supported). This resolves http://trac.ffmpeg.org/ticket/6708 and is
partly based upon Georg Lippitisch's earlier draft at
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 12 Oct 2017 13:40:59 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support
Partially based upon Georg Lippitsch's patch at
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
---
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 17 ++---
libavdevice/decklink_dec_c.c| 1 +
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..b6acb01bb9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -97,6 +97,7 @@ struct decklink_ctx {
int frames_buffer_available_spots;
int channels;
+int audio_depth;
};
typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 5616ab32f9..368ac259e4 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -42,6 +42,7 @@ struct decklink_cctx {
double preroll;
int v210;
int audio_channels;
+int audio_depth;
int duplex_mode;
DecklinkPtsSource audio_pts_source;
DecklinkPtsSource video_pts_source;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index d9ac01ac91..7e97d5f064 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -771,7 +771,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
av_init_packet(&pkt);
//hack among hacks
-pkt.size = audioFrame->GetSampleFrameCount() *
ctx->audio_st->codecpar->channels * (16 / 8);
+pkt.size = audioFrame->GetSampleFrameCount() *
ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
audioFrame->GetBytes(&audioFrameBytes);
audioFrame->GetPacketTime(&audio_pts, ctx->audio_st->time_base.den);
pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock,
ctx->audio_pts_source, ctx->audio_st->time_base, &initial_audio_pts);
@@ -854,6 +854,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
ctx->audio_pts_source = cctx->audio_pts_source;
ctx->video_pts_source = cctx->video_pts_source;
ctx->draw_bars = cctx->draw_bars;
+ctx->audio_depth = cctx->audio_depth;
cctx->ctx = ctx;
/* Check audio channel option for valid values: 2, 8 or 16 */
@@ -866,6 +867,16 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Value of channels option must be one
of 2, 8 or 16\n");
return AVERROR(EINVAL);
}
+
+/* Check audio bit depth option for valid values: 16 or 32 */
+switch (cctx->audio_depth) {
+case 16:
+case 32:
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Value for audio bit depth option must
be either 16 or 32\n");
+return AVERROR(EINVAL);
+}
/* List available devices. */
if (ctx->list_devices) {
@@ -930,7 +941,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
goto error;
}
st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id= AV_CODEC_ID_PCM_S16LE;
+st->codecpar->codec_id= cctx->audio_depth == 32 ?
AV_CODEC_ID_PCM_S32LE : AV_CODEC_ID_PCM_S16LE;
st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
st->codecpar->channels= cctx->audio_channels;
avpriv_set_pts_info(st, 64, 1, 100); /* 64 bits pts in us */
@@ -1021,7 +1032,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
*avctx)
}
av_log(avctx, AV_LOG_VERBOSE, "Using %d input audio channels\n",
ctx->audio_st->codecpar->channels);
-result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz,
bmdAudioSampleType16bitInteger, ctx->audio_st->codecpar->channels);
+result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz,
cctx->audio_depth == 32 ? bmdAudioSampleType32bitInteger :
bmdAudioSampleType16bitInteger, ctx->audio_st->codecpar->channels);
if (result != S_OK) {
av_log(avctx, AV_LOG_ERROR, "Cannot enable audio input\n");
diff --git a/libavdevice/deckli
Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
Hi Paul,
> On Oct 16, 2017, at 3:56 PM, Paul B Mahol wrote:
>
> On 10/16/17, Dave Rice mailto:d...@dericed.com>> 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 adds an
>> option to get 32 bit audio as an input with the decklink device (beforehand
>> only 16 bit audio was supported). This resolves
>> http://trac.ffmpeg.org/ticket/6708 and is partly based upon Georg
>> Lippitisch's earlier draft at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>>
>>
>> From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
>> From: Dave Rice
>> Date: Thu, 12 Oct 2017 13:40:59 -0400
>> Subject: [PATCH] libavdevice/decklink: 32 bit audio support
>>
>> Partially based upon Georg Lippitsch's patch at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> ---
>> libavdevice/decklink_common.h | 1 +
>> libavdevice/decklink_common_c.h | 1 +
>> libavdevice/decklink_dec.cpp| 17 ++---
>> libavdevice/decklink_dec_c.c| 1 +
>> 4 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
>> index 6b2525fb53..b6acb01bb9 100644
>> --- a/libavdevice/decklink_common.h
>> +++ b/libavdevice/decklink_common.h
>> @@ -97,6 +97,7 @@ struct decklink_ctx {
>> int frames_buffer_available_spots;
>>
>> int channels;
>> +int audio_depth;
>> };
>>
>> typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
>> diff --git a/libavdevice/decklink_common_c.h
>> b/libavdevice/decklink_common_c.h
>> index 5616ab32f9..368ac259e4 100644
>> --- a/libavdevice/decklink_common_c.h
>> +++ b/libavdevice/decklink_common_c.h
>> @@ -42,6 +42,7 @@ struct decklink_cctx {
>> double preroll;
>> int v210;
>> int audio_channels;
>> +int audio_depth;
>> int duplex_mode;
>> DecklinkPtsSource audio_pts_source;
>> DecklinkPtsSource video_pts_source;
>> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
>> index d9ac01ac91..7e97d5f064 100644
>> --- a/libavdevice/decklink_dec.cpp
>> +++ b/libavdevice/decklink_dec.cpp
>> @@ -771,7 +771,7 @@ HRESULT
>> decklink_input_callback::VideoInputFrameArrived(
>> av_init_packet(&pkt);
>>
>> //hack among hacks
>> -pkt.size = audioFrame->GetSampleFrameCount() *
>> ctx->audio_st->codecpar->channels * (16 / 8);
>> +pkt.size = audioFrame->GetSampleFrameCount() *
>> ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
>> audioFrame->GetBytes(&audioFrameBytes);
>> audioFrame->GetPacketTime(&audio_pts,
>> ctx->audio_st->time_base.den);
>> pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock,
>> ctx->audio_pts_source, ctx->audio_st->time_base, &initial_audio_pts);
>> @@ -854,6 +854,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> ctx->audio_pts_source = cctx->audio_pts_source;
>> ctx->video_pts_source = cctx->video_pts_source;
>> ctx->draw_bars = cctx->draw_bars;
>> +ctx->audio_depth = cctx->audio_depth;
>> cctx->ctx = ctx;
>>
>> /* Check audio channel option for valid values: 2, 8 or 16 */
>> @@ -866,6 +867,16 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> av_log(avctx, AV_LOG_ERROR, "Value of channels option must be
>> one of 2, 8 or 16\n");
>> return AVERROR(EINVAL);
>> }
>> +
>> +/* Check audio bit depth option for valid values: 16 or 32 */
>> +switch (cctx->audio_depth) {
>> +case 16:
>> +case 32:
>> +break;
>> +default:
>> +av_log(avctx, AV_LOG_ERROR, "Value for audio bit depth option
>> must be either 16 or 32\n");
>> +return AVERROR(EINVAL);
>
> This message is redundant with AVOptions, User should be able to
> select only 16 or 32,
> see bellow.
>
>> +}
>>
>> /* List available devices. */
>> if (ctx->list_devices) {
>> @@ -930,7 +941,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> goto error;
>> }
>> st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
Hi Moritz,
> On Oct 17, 2017, at 10:40 AM, Moritz Barsnick wrote:
>
> On Tue, Oct 17, 2017 at 09:22:27 -0400, Dave Rice wrote:
>>>> --- a/libavdevice/decklink_dec_c.c
>>>> +++ b/libavdevice/decklink_dec_c.c
>>>> @@ -72,6 +72,7 @@ static const AVOption options[] = {
>>>>{ "wallclock", NULL, 0,
>>>> AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_WALLCLOCK}, 0, 0, DEC, "pts_source"},
>>>>{ "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
>>>> AV_OPT_TYPE_BOOL, { .i64 = 1}, 0, 1, DEC },
>>>>{ "queue_size","input queue buffer size", OFFSET(queue_size),
>>>> AV_OPT_TYPE_INT64, { .i64 = (1024 * 1024 * 1024)}, 0, INT64_MAX, DEC },
>>>> +{ "audio_depth", "audio bitdepth (16 or 32)", OFFSET(audio_depth),
>>>> AV_OPT_TYPE_INT, { .i64 = 16}, 16, 32, DEC },
>>>
>>> Use AV_OPT_ ENUM instead.
>>
>> I don't see there to be an AV_OPT_TYPE_ENUM. Could you point out how this
>> works from an example? Alternatively since the decklink sdk only supports 2
>> bit depths (16 and 32), I could use a boolean here if that makes more sense.
>
> I would guess Paul means:
>
> enum audio_bitdepths {
>AUDIO_BITDEPTH_16,
>AUDIO_BITDEPTH_32,
>AUDIO_BITDEPTH_NB
> };
>
>{ "audio_depth","audio bitdepth", OFFSET(audio_depth),
> AV_OPT_TYPE_INT, { .i64 = AUDIO_BITDEPTH_16 }, 0, AUDIO_BITDEPTH_NB-1, DEC,
> "audio_depth" },
>{ "16", "16 bits", 0,
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0, DEC,
> "audio_depth" },
>{ "32", "32 bits", 0,
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0, DEC,
> "audio_depth" },
>
> I'm not sure pure digits are accepted as an option strin ("16", "32"), but,
> why shouldn't they.
>
> It may seem like a bit of overkill for two values, but take into
> consideration that you can skip the check "Check audio bit depth option
> for valid values: 16 or 32", but need to map the enums to values
> instead. Or you pre-assign the enums values (AUDIO_BITDEPTH_16 = 16,
> ...), but use some other trick to define the lowest possible value.[*]
> And you can easily add 8 bit or 24 bit support. ;-)
>
> Cheers,
> Moritz
>
> [*]
> enum audio_bitdepths {
>AUDIO_BITDEPTH_LOWEST = 16,
>AUDIO_BITDEPTH_16 = 16,
>AUDIO_BITDEPTH_32 = 32,
>AUDIO_BITDEPTH_NB
> };
>
>{ "audio_depth","audio bitdepth", OFFSET(audio_depth),
> AV_OPT_TYPE_INT, { .i64 = AUDIO_BITDEPTH_16 }, AUDIO_BITDEPTH_LOWEST,
> AUDIO_BITDEPTH_NB-1, DEC, "audio_depth" },
>{ "16", "16 bits", 0,
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0, DEC, "audio_depth" },
>{ "32", "32 bits", 0,
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0, DEC, "audio_depth" },
> _______
Thanks for pointing me in the right direction. I am attaching an updated patch
below; however, after removing my 16/32 and using the enumeration method (with
the patch below), it accepts any value between AUDIO_BITDEPTH_LOWEST and
AUDIO_BITDEPTH_NB-1 (16 and 32). When I enter any value from 17 through 31 then
the output is still in pcm_s16le, however the resulting audio is slow and
choppy (I'm guessing from the pkt.size line). Am I missing some method to say
that the enumeration list is restrictive?
From 10f3003e8b690bba1a722b615481d80644cdb2c1 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Tue, 17 Oct 2017 10:52:10 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support
---
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 8
libavdevice/decklink_dec.cpp| 7 ---
libavdevice/decklink_dec_c.c| 3 +++
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..b6acb01bb9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -97,6 +97,7 @@ struct decklink_ctx {
int frames_buffer_available_spots;
int channels;
+int audio_depth;
};
typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_c
Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
> On Oct 17, 2017, at 11:48 AM, Paul B Mahol wrote: > > On 10/17/17, Moritz Barsnick wrote: >> On Tue, Oct 17, 2017 at 11:12:46 -0400, Dave Rice wrote: >> >>> Thanks for pointing me in the right direction. I am attaching an >>> updated patch below; however, after removing my 16/32 and using the >>> enumeration method (with the patch below), it accepts any value >>> between AUDIO_BITDEPTH_LOWEST and AUDIO_BITDEPTH_NB-1 (16 and 32). >>> When I enter any value from 17 through 31 then the output is still in >>> pcm_s16le, however the resulting audio is slow and choppy (I'm >>> guessing from the pkt.size line). Am I missing some method to say >>> that the enumeration list is restrictive? >> >> Yes, that was exactly the oversight I had. The const'ified option now >> takes those strings, but also numbers within the range. So the option >> value "16" will be either "16" (string) or 16 (or integer), "17" will >> be interpreted as integer 17 (and still valid thanks to the range), and >> so on. My bad. >> >> So I guess it's stupid to use a string enum to represent a number >> value. You could properly restrict its use to the enumerated values if >> they were subsequent (i.e. 0, 1), and perhaps strings with letters for >> the enumerated options. But that's totally unintuitive. It would result >> in (auto doc): >> >> -audio_depth .D.. audio bitdepth (from 0 to 1) >> (default 16bits) >> 16bits .D.. >> 32bits .D.. >> >> and you could use it with either >> -audio_depth 0 # 16 bits >> -audio_depth 1 # 32 bits >> -audio_depth 16bits # 16 bits >> -audio_depth 32bits # 16 bits >> but not >> -audio_depth 16 >> >> Horrible! >> >> Your original version was most intuitive, IMHO. Sorry for explaining >> the concept. ;-) It fits well for anything representable by strings, >> not numbers. > > Hmm, first patch might be enough. Sounds good to me. Unless anyone prefers "-audio_depth thirtytwo" :-D Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] decklink 24/32 bit question
> On Oct 17, 2017, at 2:59 PM, Moritz Barsnick wrote: > > Hi Doug, > > On Tue, Oct 03, 2017 at 20:39:49 -0700, Douglas Marsh wrote: >> After digging around in places, made the following changes: > [...] >> It doesn't work (the audio capture is close but wrong), but believe it >> is a step in the correct direction. Anybody have a clue? Saw several >> names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti >> Fliegl, Rafaël Carré and Akamai Technologies Inc. > > Did you check out Dave Rice's recent patch (on this list)? It touches > code in a few more places, and adds an option to select 16 vs. 32 bits. > Please test, if you can. > > Is your subject indicating that 24 bits depth could also be supported? > If so, Dave perhaps should expand his patch to cover that. The decklink sdk only defines two BMDAudioSampleType values: bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't think there's an easy way to support a 24 bit input here. Generally in this case I've used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
> 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.. > >>> Hmm, first patch might be enough. >> Sounds good to me. Unless anyone prefers "-audio_depth thirtytwo" :-D >> Dave Rice > > Yeah that works.. so if they have any other depths, can go 0, 1 or 2 (2=some > new bit depth yet to be created) > > And for clarification: yes 32-bits (PCM_S32LE) -- I was just pointing out the > ADC/DAC's are 24-bit (8-bits padded). I was suggesting `-audio_depth thirtytwo` in jest. IMHO assigning enumerated index numbers to purely numerical values will be confusing. For instance if in the future 12 bit is added then 24 bit, we'll have -audio_depth .D.. audio bitdepth (from 0 to 3) (default 16bits) 16bits [0] 32bits [1] 12bits [2] 24bits [3] The alternative patch in the "decklink 24/32 bit question" thread, changes the default behavior of the decklink input which I think should be avoided. I agree with Moritz that the first patch of this thread (https://patchwork.ffmpeg.org/patch/5588/) is the best option. Also the method used in the patch to validate a limited non-consecutive range of values is already in used elsewhere in the device for the channel count at https://github.com/FFmpeg/FFmpeg/blob/278588cd0bf788df0194f74e62745f68559616f9/libavdevice/decklink_dec.cpp#L859-L868. Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support
> 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 adds an
>> option to get 32 bit audio as an input with the decklink device (beforehand
>> only 16 bit audio was supported). This resolves
>> http://trac.ffmpeg.org/ticket/6708 and is partly based upon Georg
>> Lippitisch's earlier draft at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>>
>>
>> From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
>> From: Dave Rice
>> Date: Thu, 12 Oct 2017 13:40:59 -0400
>> Subject: [PATCH] libavdevice/decklink: 32 bit audio support
>>
>> Partially based upon Georg Lippitsch's patch at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> ---
>> libavdevice/decklink_common.h | 1 +
>> libavdevice/decklink_common_c.h | 1 +
>> libavdevice/decklink_dec.cpp| 17 ++---
>> libavdevice/decklink_dec_c.c| 1 +
>> 4 files changed, 17 insertions(+), 3 deletions(-)
>
> Missing docs/indevs.texi update and libavdevice micro bump.
Updated.
From 1e5ff78fec9b13eccac9a96acc358bbfd6a7015d Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Wed, 18 Oct 2017 15:21:46 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support
---
doc/indevs.texi | 4
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 17 ++---
libavdevice/decklink_dec_c.c| 1 +
libavdevice/version.h | 2 +-
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 55a4084bb2..d308bbf7de 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -311,6 +311,10 @@ Sets maximum input buffer size in bytes. If the buffering
reaches this value,
incoming frames will be dropped.
Defaults to @samp{1073741824}.
+@item audio_depth
+Sets the audio sample bit depth. Must be @samp{16} or @samp{32}.
+Defaults to @samp{16}.
+
@end table
@subsection Examples
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..b6acb01bb9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -97,6 +97,7 @@ struct decklink_ctx {
int frames_buffer_available_spots;
int channels;
+int audio_depth;
};
typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 5616ab32f9..368ac259e4 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -42,6 +42,7 @@ struct decklink_cctx {
double preroll;
int v210;
int audio_channels;
+int audio_depth;
int duplex_mode;
DecklinkPtsSource audio_pts_source;
DecklinkPtsSource video_pts_source;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index d9ac01ac91..7e97d5f064 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -771,7 +771,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
av_init_packet(&pkt);
//hack among hacks
-pkt.size = audioFrame->GetSampleFrameCount() *
ctx->audio_st->codecpar->channels * (16 / 8);
+pkt.size = audioFrame->GetSampleFrameCount() *
ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
audioFrame->GetBytes(&audioFrameBytes);
audioFrame->GetPacketTime(&audio_pts, ctx->audio_st->time_base.den);
pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock,
ctx->audio_pts_source, ctx->audio_st->time_base, &initial_audio_pts);
@@ -854,6 +854,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
ctx->audio_pts_source = cctx->audio_pts_source;
ctx->video_pts_source = cctx->video_pts_source;
ctx->draw_bars = cctx->draw_bars;
+ctx->audio_depth = cctx->audio_depth;
cctx->ctx = ctx;
/* Check audio channel option for valid values: 2, 8 or 16 */
@@ -866,6 +867,16 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Value of channels option must be one
of 2, 8 or 16\n");
return AVERROR(EINVAL);
}
+
+/* Check audio bit depth option for valid values: 16 or 32 */
+switch (cctx->audio_depth) {
+case 16:
+case 32:
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Value for audio bit depth option must
be either 16 or 32\n");
+return AVERROR(EINVAL);
+}
/* List avail
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
> On Oct 6, 2017, at 5:31 PM, Devin Heitmueller > wrote: > >> Sorry, what I meant was: >> Nothing inside FFmpeg except the decklink device could use >> VANC? > > Ah, I understand now. > > Yes, the decklink device is currently the only SDI device which is supported > by libavdevice. I’ve got a whole pile of patches coming which add support > for a variety of protocols for both capture and output (e.g. EIA-708, > SCTE-104, AFD, SMPTE 2038, etc). But today the decklink module is the only > device supported. > > Would love to see more SDI devices supported and potentially interested in > adding such support myself if we can find good candidates. The DVEO/linsys > cards are largely obsolete and the AJA boards are significantly more > expensive than any of BlackMagic’s cards. If anyone has good experiences > with other vendors I would like to hear about it (and there may be an > opportunity to extend libavdevice to support another SDI vendor). The President of AJA has publicly stated an intent to add an open license to their SDK, https://twitter.com/ajaprez/status/910100436224499713 <https://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
Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskaenc: fix Tags master on seekable output if there are tags after the last stream duration
> On Oct 7, 2016, at 10:30 AM, James Almer wrote:
>
> On 10/7/2016 3:05 AM, James Almer wrote:
>> The dynamic AVIOContext would get closed pointing to the wrong position
>> in the buffer.
>> This is a regression since 650e17d88b63b5aca6e0a43483e89e64b0f7d2dd.
>>
>> Signed-off-by: James Almer
>> ---
>> Example:
>> ./ffmpeg -i fate-samples/vorbis/vorbis_chapter_extension_demo.ogg -c:a copy
>> -metadata:c key=value out.mka
>>
>> The output is corrupt before this patch.
>>
>> The refactoring isn't necessary per se, but it comes in handy for the next
>> patch,
>> where attachments will not be treated as tracks anymore when writting tags.
>>
>> libavformat/matroskaenc.c | 15 +--
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index 0878cb5..286b8b4 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -2264,17 +2264,19 @@ static int mkv_write_trailer(AVFormatContext *s)
>> end_ebml_master_crc32(pb, &mkv->info_bc, mkv, mkv->info);
>>
>> // update stream durations
>> -if (mkv->stream_durations) {
>> +if (!mkv->is_live && mkv->stream_durations) {
>> int i;
>> +int64_t curr = avio_tell(mkv->tags_bc);
>> for (i = 0; i < s->nb_streams; ++i) {
>> AVStream *st = s->streams[i];
>> -double duration_sec = mkv->stream_durations[i] *
>> av_q2d(st->time_base);
>> -char duration_string[20] = "";
>>
>> -av_log(s, AV_LOG_DEBUG, "stream %d end duration = %" PRIu64
>> "\n", i,
>> - mkv->stream_durations[i]);
>> +if (mkv->stream_duration_offsets[i] > 0) {
>> +double duration_sec = mkv->stream_durations[i] *
>> av_q2d(st->time_base);
>> +char duration_string[20] = "";
>> +
>> +av_log(s, AV_LOG_DEBUG, "stream %d end duration = %"
>> PRIu64 "\n", i,
>> + mkv->stream_durations[i]);
>>
>> -if (!mkv->is_live && mkv->stream_duration_offsets[i] > 0) {
>> avio_seek(mkv->tags_bc, mkv->stream_duration_offsets[i],
>> SEEK_SET);
>>
>> snprintf(duration_string, 20, "%02d:%02d:%012.9f",
>> @@ -2284,6 +2286,7 @@ static int mkv_write_trailer(AVFormatContext *s)
>> put_ebml_binary(mkv->tags_bc, MATROSKA_ID_TAGSTRING,
>> duration_string, 20);
>> }
>> }
>> +avio_seek(mkv->tags_bc, curr, SEEK_SET);
>> }
>> if (mkv->tags.pos && !mkv->is_live) {
>> avio_seek(pb, mkv->tags.pos, SEEK_SET);
>
>
> Ping. It's a recent regression on a muxer, so I'd like to solve it asap.
> I'll push it later today if nobody comments.
I tested this and it does fix the issue so that the added "key" tag is properly
formed, whereas the tag is only null bytes without the patch. Thanks!
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroska: fix MatroskaVideoFieldOrder enum values
> On Oct 12, 2016, at 3:54 PM, James Almer wrote:
>
> The spec says
>
> 9: Interlaced with bottom field displayed first and top field stored first
> 14: Interlaced with top field displayed first and bottom field stored first
>
> And avcodec.h states
>
> AV_FIELD_TB, //< Top coded first, bottom displayed first
> AV_FIELD_BT, //< Bottom coded first, top displayed first
>
> Signed-off-by: James Almer
> ---
> libavformat/matroska.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/matroska.h b/libavformat/matroska.h
> index 1ff76e6..15e401c 100644
> --- a/libavformat/matroska.h
> +++ b/libavformat/matroska.h
> @@ -286,8 +286,8 @@ typedef enum {
> MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
> MATROSKA_VIDEO_FIELDORDER_TT = 1,
> MATROSKA_VIDEO_FIELDORDER_BB = 6,
> -MATROSKA_VIDEO_FIELDORDER_BT = 9,
> -MATROSKA_VIDEO_FIELDORDER_TB = 14,
> +MATROSKA_VIDEO_FIELDORDER_TB = 9,
> +MATROSKA_VIDEO_FIELDORDER_BT = 14,
> } MatroskaVideoFieldOrder;
>
> typedef enum {
> --
> 2.9.1
LGTM. Thanks for fixing this. It now aligns to the same list in QuickTime as
was intended in the spec.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: add option to ignore moov atoms which are detected in free atoms.
> On Oct 13, 2016, at 1:56 PM, Hendrik Leppkes wrote: > > Am 13.10.2016 19:03 schrieb "liangsi" : >> >> --- >> libavformat/isom.h | 1 + >> libavformat/mov.c | 5 - >> 2 files changed, 5 insertions(+), 1 deletion(-) >> > > Can you elaborate on the reasons of why someone would want this? Preferably > in the commit message for future consideration. Shouldn't using the moov atom that is not detected within a free atom be the default? Can you elaborate on the reasons of why someone wouldn't want this? Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: write a DisplayUnit element when aspect ratio is unknown
> On Oct 15, 2016, at 7:54 PM, Kieran O Leary wrote: > > Hi, > > On Sat, Oct 15, 2016 at 11:09 PM, James Almer wrote: > >> >> -#sar 0: 1/1 >> +#sar 0: 0/1 >> > > This commit looks very useful. A few archivists (including myself) > encountered this issue, so this is a wonderful contribution! Thanks James! +1. Sometimes it makes sense to preserve uncertainty. Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: write DisplayWidth and DisplayHeight elements only if they differ from PixelWidth and PixelHeight
Hi James,
> On Oct 18, 2016, at 11:20 PM, James Almer wrote:
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskaenc.c | 6 --
> tests/fate/matroska.mak | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 6f2957c..03d5326 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1192,8 +1192,10 @@ static int mkv_write_track(AVFormatContext *s,
> MatroskaMuxContext *mkv,
> av_log(s, AV_LOG_ERROR, "Overflow in display width\n");
> return AVERROR(EINVAL);
> }
> -put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYWIDTH , d_width /
> display_width_div);
> -put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYHEIGHT, par->height /
> display_height_div);
> +if (d_width != par->width || display_width_div != 1 ||
> display_height_div != 1) {
> +put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYWIDTH , d_width /
> display_width_div);
> +put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYHEIGHT,
> par->height / display_height_div);
> +}
> } else if (display_width_div != 1 || display_height_div != 1) {
> put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYWIDTH , par->width /
> display_width_div);
> put_ebml_uint(pb, MATROSKA_ID_VIDEODISPLAYHEIGHT, par->height /
> display_height_div);
You could also make the storage simpler by considering whether or not to write
DisplayWidth and DisplayHeight independently. For instance:
PixelWidth=720
PixelHeight=480
DisplayWidth=640
DisplayHeight=480
could be simplified to this (as DisplayHeight if unstored, defaults to
PixelHeight)
PixelWidth=720
PixelHeight=480
DisplayWidth=640
However I'm worried that this may break things when #4489 and/or #5301 are
resolved. As the DisplayWidth/Height are intended to be used after cropping. In
the attached example on #5301 it has:
PixelWidth=320
PixelHeight=240
PixelCropBottom=40
PixelCropTop=0
PixelCropLeft=240
PixelCropRight=40
DisplayWidth=320
DisplayHeight=240
If this was remuxed with your patch AND a potential patch to pass PixelCrop
elements from source mkv to output mkv, then the result would be:
PixelWidth=320
PixelHeight=240
PixelCropBottom=40
PixelCropTop=0
PixelCropLeft=240
PixelCropRight=40
and since the Display Elements are not stored, they would be evaluated as
DisplayWidth as "PixelWidth - PixelCropLeft - PixelCropRight"
DisplayHeight = "PixelHeight - PixelCropTop - PixelCropBottom"
which is
DisplayWidth=40
DisplayHeight=200
which is wrong, since the original file intended to show the cropped 40x200
image in a 320x240 display.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] ffprobe: report field order for video streams
> On Oct 20, 2016, at 3:28 AM, Tobias Rapp wrote: > > On 19.10.2016 23:15, Michael Niedermayer wrote: >> On Wed, Oct 19, 2016 at 02:35:21PM +0200, Tobias Rapp wrote: >>> From: Rodger Combs >>> >>> Reviewed-by: Tobias Rapp >>> --- >>> doc/ffprobe.xsd | 1 + >>> ffprobe.c | 13 + >>> tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +- >>> tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +- >>> tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 2 +- >>> tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 | 2 +- >>> tests/ref/fate/concat-demuxer-simple2-lavf-ts | 2 +- >>> tests/ref/fate/ffprobe_compact | 4 ++-- >>> tests/ref/fate/ffprobe_csv | 4 ++-- >>> tests/ref/fate/ffprobe_default | 2 ++ >>> tests/ref/fate/ffprobe_flat | 2 ++ >>> tests/ref/fate/ffprobe_ini | 2 ++ >>> 12 files changed, 29 insertions(+), 9 deletions(-) >> >> This too doesnt apply: >> >> Applying: ffprobe: report field order for video streams >> Using index info to reconstruct a base tree... >> error: patch failed: tests/ref/fate/ffprobe_compact:27 >> error: tests/ref/fate/ffprobe_compact: patch does not apply >> error: Did you hand edit your patch? >> It does not apply to blobs recorded in its index. >> > > Could be due to encoding problems or long lines. Have rebased the patch onto > current git HEAD and attached it as a file. I tested this and the new version applied for me. The output of xml=q=1 validated against the revision. LGTM. Having this data in ffprobe is really helpful. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: add -show_headers_first option
> On Sep 4, 2016, at 1:09 PM, Nicolas George wrote: > > Le nonidi 19 fructidor, an CCXXIV, Stefano Sabatini a écrit : >> This is meant to be used for generating output suitable for the >> ffprobe_default demuxer. >> --- >> ffprobe.c | 30 ++ >> 1 file changed, 26 insertions(+), 4 deletions(-) > > I find the naming a bit clumsy. It says what it says, but what it the next > step? -show_format_after_frames_but_before_streams? > > I would like to suggest another avenue, a little more work but not by much: > deprecate all the -show_ options, and replace them by a single > -show option that takes the sections name in order: > > ffprobe -show packets,streams,format > > would be equivalent to the current "ffprobe -show_frames -show_streams > -show_format", but: > > ffprobe -show format,streams,packets > > would yield the same result as with -show_headers_first. > > The syntax could later be updated for various extra features: > > ffprobe -show format,streams,packets,rewind,packets+frames=silent=1,streams > > I do not know how it interacts with the -show_entries feature, but I must > say I never understood how the -show_entries feature works. I’m not clear as to the reasoning for this, as the ordering of the elements doesn’t effect any of the meaing of the xml. However I wanted to note that such reordering would create invalid ffprobe xml. ffprobe.xsd defines the elements in a `sequence`, so if the order of elements is really arbitrary it should be changed to a `choice`. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VDD2016] Technical Discussion Results
Hi, > On Sep 12, 2016, at 5:58 AM, Thilo Borgmann wrote: > > Hi, > > these are the resulting notes we've taken during the FFmpeg technical > discussion > during VDD 2016. We've ended up with two slides on the board and compn took > pictures of them. You can find them here: > > https://drive.google.com/drive/folders/0B53tgCAS2uUnVUpZN0U1WDE0MzQ?usp=sharing > > Additional info: > > - There were two more job offers compn forgotto write down. One from Alex at > Comcast to implement a perceptional video filter in lavfi for 4K, along with > mcdeint and denoise filters. Contact compn to get more information about this. > Also Kodi is looking for python plugin developers. Compn also thinks that they > are looking for Android devs, too. > > - The group working on ffv1 specification said they've also opportunities for > work. However you've to contact the commission members at archivist > conferences. > I think we haven't got a list of these conferences, though. I'm in the CELLAR working group (working on Matorka, FFV1, FLAC) and am also an archivist and can speak to this. The MediaConch project via PREFORMA has some funds to sponsor FFV1 and Matroska development during this year. - Option to add CRCs to Top Level Elements in Matroska when muxing. http://trac.ffmpeg.org/ticket/4347 - Support for selecting an Ordered Edition in mkv: http://trac.ffmpeg.org/ticket/5698 - Bayer pixel format support in FFV1 - Support for additional color information in FFV1 to better handle lossless DPX->FFV1->DPX transfer while preserving characteristics such as if the sampling is logarithmic or linear. Probably others. Feel welcome to suggest a bounty or send questions to myself or Jerome Martinez . [...] Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] calculation of probe score
Hi Carl, > On Sep 13, 2016, at 2:57 PM, Carl Eugen Hoyos wrote: > > 2016-09-12 19:47 GMT+02:00 Monique Lassere : >> Trying to dig as deeply as possible into ffprobe's probe score >> and how it is calculated. > > Is there a use case that could be interesting to us? I think the use case if for when an archive accepts a large diverse collection for preservation to access probe_score per file. A lower probe_score may indicate that the file is broken, misnamed, mis-categorized, which could mean that creation of derivatives or long-term handling may need closer review. In a related conversation about probe score I tested 2000+ random files and made this histogram: rate of occurrence, format name and probe_score. 149 "matroska,webm",100 672 "mov,mp4,m4a,3gp,3g2,mj2",100 1 aac,1 1 aac,25 1 adp,25 15 aiff,100 4 asf,100 8 avi,100 919 caf,100 45 dv,75 2 ea,100 1 flac,1 1 flac,13 4 flac,50 8 flv,100 3 mp3,25 90 mp3,51 9 mpeg,26 8 mpeg,52 1 mpegts,50 1 mpegvideo,12 13 mpegvideo,51 11 mxf,100 1 ogg,100 2 rm,100 1 swf,100 5 swf,26 92 wav,99 So for instance perhaps worth a closer look at the mpegvideo with score of 12 or the flac file with score of 1(!), before moving the file into long term storage. > Or a bug you want to tell us about? > > [...] > >> 2. Secondly, does the probe score relate to the container format only? > > As Michael said, yes. > Note that some containers (like H.264 Annex B or ADTS) correspond > to a codec, so for containers that "allow" random codecs (like mpeg > streams) the same probe functions that allow detecting formats can > be used to detect codecs. [...] Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/movenc: Allow to disable writing the timecode track
> On Sep 25, 2016, at 1:49 PM, Michael Niedermayer > wrote: > > On Sat, Sep 24, 2016 at 10:40:35PM +0200, Carl Eugen Hoyos wrote: >> Hi! >> >> Not everybody is happy about a timecode track in mp4, >> see ticket #5492. >> >> Please comment, Carl Eugen > >> doc/muxers.texi |3 +++ >> libavformat/movenc.c |6 -- >> libavformat/movenc.h |1 + >> 3 files changed, 8 insertions(+), 2 deletions(-) >> 1ff491854d9a8c694b38153561d873b55688bb13 >> 0001-lavf-movenc-Allow-to-disable-writing-the-timecode-tr.patch >> From 47a813709643106b0d0a2eceff822107c395d15c Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Sat, 24 Sep 2016 22:38:14 +0200 >> Subject: [PATCH] lavf/movenc: Allow to disable writing the timecode track. >> >> Fixes ticket #5492. >> --- >> doc/muxers.texi |3 +++ >> libavformat/movenc.c |6 -- >> libavformat/movenc.h |1 + >> 3 files changed, 8 insertions(+), 2 deletions(-) > > should be ok, but please wait a day with applying so others can > comment too +1 Tested this and it works well and solves an issue that I occasionally find. Thanks Carl. [...] Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroska: write FlagInterlaced element in WebM
Hi, > On Oct 2, 2016, at 7:14 PM, James Almer wrote: > > On 9/27/2016 3:03 PM, James Almer wrote: >> It's listed as supported in both https://www.webmproject.org/docs/container/ >> and https://matroska.org/technical/specs/index.html >> >> Signed-off-by: James Almer >> --- >> libavformat/matroskaenc.c | 41 + >> 1 file changed, 21 insertions(+), 20 deletions(-) > > Ping. Untested but from a read through, the patch looks good. FlagInterlaced is supported in both Matroska and webM, whereas FieldOrder (a new field from the CELLAR work on Matroska) is only supported in Matroska. IMHO though I think that FlagInterlaced without information on FieldOrder is not so useful and that the webM project should consider adopting FieldOrder as well. I'd prefer to see a patch to webM to consider adding FieldOrder to the format rather than see FieldOrder removed from the webM muxer in FFmpeg. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer
Hi, > On Oct 3, 2016, at 7:36 PM, James Almer wrote: > > This patchsets implements the feature requested on ticket #4347. > The first three patches are preparation work. The first one isn't > strictly related to the implementation, but comes in handy > nonetheless. > > Patches 4 to 11 can be squashed into a single commit before pushing > if that's prefered, but for review purposes i split things as one > patch per Level 1 element being adapted to write a CRC32 element. > > Fate tests are updated as needed. I tested the patches and it works well and resolves ticket #4347. The CRC-32 Elements are in the right positions according to the latest CELLAR drafts on Matroska and the resulting files pass mkvalidator. Thanks much for this. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer
> On Oct 6, 2016, at 4:33 PM, James Almer wrote: > > On 10/6/2016 3:28 PM, Michael Niedermayer wrote: >> On Thu, Oct 06, 2016 at 11:27:08AM -0300, James Almer wrote: >>> On 10/6/2016 7:29 AM, Michael Niedermayer wrote: On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote: > This patchsets implements the feature requested on ticket #4347. > The first three patches are preparation work. The first one isn't > strictly related to the implementation, but comes in handy > nonetheless. > > Patches 4 to 11 can be squashed into a single commit before pushing > if that's prefered, but for review purposes i split things as one > patch per Level 1 element being adapted to write a CRC32 element. > > Fate tests are updated as needed. some questions Does this reduce writing speed ? for example when remuxing high bitrate data like rawvideo ? >>> >>> The bulk of the CRC calculation is done once per level 1 element, so it >>> shouldn't affect remuxing speed in a considerable way. But if preferred, >>> i could see about adding an option to disable it. >> >> i guess such a option cant hurt > > Will add it. Worth adding to the Changelog as well. >> thanks >> >> no furter comments from me about this patchset > > Pushed without squashing, so if problems arise bisect can more accurately > point where things went wrong. > > Thanks. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/filters: add example of pipe protocol use in movie filter
Hi, Based on Paul’s advice on https://trac.ffmpeg.org/ticket/5229#comment:1. This adds an example of the pipe protocol in the movie filter with necessary escaping. Dave Rice 0001-doc-filters-add-example-of-pipe-protocol-use-in-movi.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Cellar] [Matroska-devel] Colour Format proposal
Hi all, Working with the IETF Cellar Working Group, https://datatracker.ietf.org/wg/cellar/charter/, Frank Galligan has drafted a proposal for the management of metadata in Matroska to accommodate information on color, full/broadcast range, HDR metadata, chroma subsampling patterns and other information. I'm forwarding it to ffmpeg-devel and libav-devel to encourage any additional comments. The background discussion thus far is visible at https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal <https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal>. For context, the structure for Matroska element definitions is currently in draft here: https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes>. > Begin forwarded message: > > From: Frank Galligan > Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal > Date: February 18, 2016 at 2:50:27 PM EST > To: Dave Rice > Cc: Jerome Martinez , Discussion about the current and > future development of Matroska , > cel...@ietf.org > > Here is the current proposal, minus the reference to the 265 doc. > > The parent element would be Video [E0]. > > > Element Name: Colour > Level:4 > ID: [55][B0] > Mandatory:- > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. > > > Element Name: MatrixCoefficients > Level:5 > ID: [55][B1] > Mandatory:- > Multiple: - > Default: 2 > Type: u > Description: The Matrix Coefficients of the video used to derive luma and > chroma values from reg, green, and blue color primaries. For > clarity, the value and meanings for MatrixCoefficients are > adopted > from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > 10: BT2020 Constant Luminance) > > > Element Name: BitsPerChannel > Level:5 > ID: [55][B2] > Mandatory:- > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. A value of 0 indicates that > the BitsPerChannel is unspecified. > > > Element Name: ChromaSubsamplingHorz > Level:5 > ID: [55][B3] > Mandatory:- > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cr and Cb channels for > every > pixel not removed horizontally. Example: For video with 4:2:0 > chroma subsampling, the ChromaSubsamplingHorz should be set to > 1. > > > Element Name: ChromaSubsamplingVert > Level:5 > ID: [55][B4] > Mandatory:- > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cr and Cb channels for > every > pixel not removed vertically. Example: For video with 4:2:0 > chroma > subsampling, the ChromaSubsamplingVert should be set to 1. > > Element Name: CbSubsamplingHorz > Level:5 > ID: [55][B5] > Mandatory:- > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cb channel for every pixel > not removed horizontally. This is additive with > ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma > subsampling, the ChromaSubsamplingHorz should be set to 1 and > CbSubsamplingHorz should be set to 1. > > > Element Name: CbSubsamplingVert > Level:5 > ID: [55][B6] > Mandatory:- > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cb channel for every pixel > not removed vertically. This is additive with > ChromaSubsamplingVert. > > > Element Name: ChromaSitingHorz > Level:5 > ID: [55][B7] > Mandatory:- > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: Left > collocated , 2: Half) > > Element Name: ChromaSitingVert > Level:5 > ID: [55][B8] > Mandatory:- > Multiple: - > Default:
Re: [FFmpeg-devel] movenc: Enable timecode tracks in MP4
> On Feb 27, 2016, at 10:24 PM, Michael Niedermayer > wrote: > > On Thu, Feb 04, 2016 at 04:45:09PM +, Carl Eugen Hoyos wrote: >> Syed Andaleeb Roomy gmail.com> writes: >> >>> I worked on the attached patch to enable timecode tracks in MP4 files >>> written by ffmpeg. Could someone please take a look to see if it is >>> acceptable? >> >> Ping, see ticket #4704. > > applied > > thanks [...] I noticed that this patch affects some workflows so wanted to send a note. I can produce an NTSC file with timecode via: ffmpeg -f lavfi -i testsrc=r=3/1001:d=1 -metadata "timecode=01:12:23;04" -y test.mov If I try to transcode the file in a way that changes the frame rate, then the output fails with "[mp4 @ 0x7fcf13000c00] Drop frame is only allowed with 3/1001 or 6/1001 FPS". drice:avsurgery drice$ ffmpeg -i test.mov -r 28 -y test.mp4 ffmpeg version N-43081-g7725210 Copyright (c) 2000-2016 the FFmpeg developers built with Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-ffplay --enable-libopenjpeg --disable-decoder=jpeg2000 --extra-cflags=-I/usr/local/Cellar/openjpeg/1.5.2_1/include/openjpeg-1.5 --enable-vda libavutil 55. 19.100 / 55. 19.100 libavcodec 57. 28.103 / 57. 28.103 libavformat57. 28.102 / 57. 28.102 libavdevice57. 0.101 / 57. 0.101 libavfilter 6. 39.102 / 6. 39.102 libavresample 3. 0. 0 / 3. 0. 0 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc54. 0.100 / 54. 0.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf57.28.102 Duration: 00:00:01.00, start: 0.00, bitrate: 73 kb/s Stream #0:0(eng): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv444p, 320x240 [SAR 1:1 DAR 4:3], 59 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default) Metadata: handler_name: DataHandler encoder : Lavc57.28.103 libx264 timecode: 01:12:23;04 Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s Metadata: handler_name: DataHandler timecode: 01:12:23;04 No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. [libx264 @ 0x7fcf12005c00] using SAR=1/1 [libx264 @ 0x7fcf12005c00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 0x7fcf12005c00] profile High 4:4:4 Predictive, level 1.3, 4:4:4 8-bit [libx264 @ 0x7fcf12005c00] 264 - core 148 r2601 a0cd7d3 - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 [mp4 @ 0x7fcf13000c00] Drop frame is only allowed with 3/1001 or 6/1001 FPS Output #0, mp4, to 'test.mp4': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf57.28.102 Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 320x240 [SAR 1:1 DAR 4:3], q=-1--1, 28 fps, 14336 tbn, 28 tbc (default) Metadata: handler_name: DataHandler timecode: 01:12:23;04 encoder : Lavc57.28.103 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument I suggest if the source file has timecode and the frame rate is changed that FFmpeg provide a warning, but that the encoding still occurs. Dave Rice signature.asc Description: Message signed with OpenPGP using GPGMail ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Demux the PixelCrop* values
Hi, > On Mar 29, 2016, at 4:23 AM, wm4 wrote: > > On Sat, 26 Mar 2016 16:56:55 -0600 > Nic Wolfe wrote: > >> The Matroska spec defines PixelCropTop, PixelCropBottom, PixelCropLeft, >> and PixelCropRight elements: >> https://www.matroska.org/technical/specs/index.html >> >> This commit adds support for demuxing these values so that >> applications using libav* >> are able to use them when playing the stream. They're added to the AVStream's >> metadata if they are set to something non-zero. >> >> >> My official patch is base64 encoded and attached but I will also >> include the diff below for (hopefully) convenience. >> > > To elaborate on why this change is bad (in its current state): > > - It's not clearly defined what the pixelcrop fields mean. Do they > operate before or after aspect rasto is applied? Do they affect > aspect ratio calculation? What if aspect ratio or video size change > later? Does it get applied after h264 bitstream cropping, does it > override it? AFAIK these issues were also discussed on the cellar > mailing list, but I didn't follow it. It was discussed on CELLAR but not patched yet. At the moment, the best clarification is from Steve Lhomme in this post https://mailarchive.ietf.org/arch/search/?email_list=cellar&q=display+area+question: "Yes, the cropping happens on the pixels, the display size are just how to display those remaining pixels.” So the pixelcrop is applied before the aspect ratio. AFAIK there is no determination as to how h264 bitstream cropping and Matroska cropping should be prioritized (cc’ing CELLAR on this). I think the PixelCrop documentation also needs to consider handling in video stereo modes. > - There should generally be a concept at least in libavformat's API how > to handle cropping. For example, it could be some sort of well-defined > AVStream side data. (Personally I'd be a fan of adding it to AVFrame > too. There's no way around if it should work for hw decoding.) > - Worst of all: it's exported as generic metadata. This means that: > - API users could start interpreting the same metadata fields for >other formats than Matroska too > - Transcoders like ffmpeg CLI will copy the crop metadata to other >containers (as normal metadata). > - Non-Matroska files might be created that contain the "made >up" libavformat Matroska demuxer metadata, and the creator of the >file expects that programs respect it. > (Something like this almost happened with the "old" libavformat > rotation metadata, which is also exported as normal metadata.) > > While just adding a "hack" to export metadata for essentially 1 API > user might be acceptable if adding "proper" API is too hard for now, at > least the last point needs to be fixed. I also support a demuxer option to allow pixelcrop to be ignored. Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskaenc.c: use metadata key/value to set mastering metadata
> On Apr 3, 2016, at 6:38 PM, Neil Birkbeck wrote: > > Use "master_display" key/value pair to specify mastering metadata in a > similar formatting as accepted by libx265 (unless there is some other > generic way to add side data to a stream from command line). > Currently, the packet side data propagates from an input file to > output file if it is transmuxed (mkv -> mkv). Perhaps we want to also > use this same metadata key in matroskadec to also allow for the > metadata to propagate during transcoding. > <0001-lavf-matroskaenc.c-use-metadata-key-value-to-set-mas.patch>___ Wouldn’t it reduce confusion if the proposed MasteringMetadata elements[1] were used rather than rather than storing the same data as Matroska tags? Dave Rice [1] as discussed on the CELLAR list https://mailarchive.ietf.org/arch/msg/cellar/hIKLhMdgTMTEwUTeA4ct38h0tmE ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames
> On May 31, 2016, at 3:23 PM, Michael Niedermayer
> wrote:
>
> adding demuxer and other logs should be easy
> This forces single threaded decoding for simplicity
> It also requires pthreads, this could be avoided either with
> some lockless tricks or simply by assuming av_log would never be called from
> another thread.
>
> doc/ffprobe.xsd update missing (TODO & help welcome)
I'll volunteer to do the ffprobe.xsd output. Thanks much.
Dave Rice
> Fixes Ticket5521
>
> Signed-off-by: Michael Niedermayer
> ---
> ffprobe.c | 154 -
> 1 file changed, 153 insertions(+), 1 deletion(-)
>
> diff --git a/ffprobe.c b/ffprobe.c
> index a7e329c..07b61ec 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -49,6 +49,19 @@
> #include "libpostproc/postprocess.h"
> #include "cmdutils.h"
>
> +#if HAVE_PTHREADS
> +# include
> +#else
> +# ifdef pthread_mutex_lock
> +#undef pthread_mutex_lock
> +# endif
> +# define pthread_mutex_lock(a)
> +# ifdef pthread_mutex_unlock
> +#undef pthread_mutex_unlock
> +# endif
> +# define pthread_mutex_unlock(a)
> +#endif
> +
> typedef struct InputStream {
> AVStream *st;
>
> @@ -84,6 +97,7 @@ static int do_show_library_versions = 0;
> static int do_show_pixel_formats = 0;
> static int do_show_pixel_format_flags = 0;
> static int do_show_pixel_format_components = 0;
> +static int do_show_log = 0;
>
> static int do_show_chapter_tags = 0;
> static int do_show_format_tags = 0;
> @@ -92,6 +106,7 @@ static int do_show_program_tags = 0;
> static int do_show_stream_tags = 0;
> static int do_show_packet_tags = 0;
>
> +
> static int show_value_unit = 0;
> static int use_value_prefix = 0;
> static int use_byte_value_binary_prefix = 0;
> @@ -146,6 +161,8 @@ typedef enum {
> SECTION_ID_FRAME_TAGS,
> SECTION_ID_FRAME_SIDE_DATA_LIST,
> SECTION_ID_FRAME_SIDE_DATA,
> +SECTION_ID_FRAME_LOG,
> +SECTION_ID_FRAME_LOGS,
> SECTION_ID_LIBRARY_VERSION,
> SECTION_ID_LIBRARY_VERSIONS,
> SECTION_ID_PACKET,
> @@ -185,10 +202,12 @@ static struct section sections[] = {
> [SECTION_ID_FORMAT] = { SECTION_ID_FORMAT, "format", 0, {
> SECTION_ID_FORMAT_TAGS, -1 } },
> [SECTION_ID_FORMAT_TAGS] ={ SECTION_ID_FORMAT_TAGS, "tags",
> SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name
> = "format_tags" },
> [SECTION_ID_FRAMES] = { SECTION_ID_FRAMES, "frames",
> SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME, SECTION_ID_SUBTITLE, -1 } },
> -[SECTION_ID_FRAME] = { SECTION_ID_FRAME, "frame", 0, {
> SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, -1 } },
> +[SECTION_ID_FRAME] = { SECTION_ID_FRAME, "frame", 0, {
> SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST,
> SECTION_ID_FRAME_LOGS, -1 } },
> [SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS, "tags",
> SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name
> = "frame_tags" },
> [SECTION_ID_FRAME_SIDE_DATA_LIST] ={ SECTION_ID_FRAME_SIDE_DATA_LIST,
> "side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 } },
> [SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
> "side_data", 0, { -1 } },
> +[SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs",
> SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
> +[SECTION_ID_FRAME_LOG] = { SECTION_ID_FRAME_LOG, "log",
> SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 } },
> [SECTION_ID_LIBRARY_VERSIONS] = { SECTION_ID_LIBRARY_VERSIONS,
> "library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 }
> },
> [SECTION_ID_LIBRARY_VERSION] ={ SECTION_ID_LIBRARY_VERSION,
> "library_version", 0, { -1 } },
> [SECTION_ID_PACKETS] ={ SECTION_ID_PACKETS, "packets",
> SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} },
> @@ -255,11 +274,73 @@ static uint64_t *nb_streams_packets;
> static uint64_t *nb_streams_frames;
> static int *selected_streams;
>
> +#if HAVE_PTHREADS
> +pthread_mutex_t log_mutex;
> +#endif
> +typedef struct LogBuffer {
> +char *context_name;
> +int log_level;
> +char *log_message;
> +AVClassCategory category;
> +char *parent_name;
> +AVClassCategory parent_category;
> +}LogBuffer;
> +
> +static LogBuffer *log_buffer;
> +static int log_buffer_size;
> +
> +st
[FFmpeg-devel] Matroska / FFV1 Symposium in Berlin
Hi all, I wanted to share news and an invite for a free symposium to be held in Berlin on July 18-20, 2016 hosted by Deutsche Kinemathek and Zuse Institute Berlin which has a specific focus on the development, standardization, and implementation of Matroska and FFV1. Developers, users, and onlookers are invited to attend. This conference should build upon the work of the IETF Cellar working group [1] which is tasked with standardizing these formats. We are still arranging the schedule but if you would like to propose a presentation or event, or have any questions, please contact i...@mediaarea.net <mailto:i...@mediaarea.net>. More information and a link to the registration form are available at https://mediaarea.net/MediaConch/notimetowait.html <https://mediaarea.net/MediaConch/notimetowait.html>. Best Regards, Dave Rice [1] https://datatracker.ietf.org/wg/cellar/charter/ <https://datatracker.ietf.org/wg/cellar/charter/> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffprobe.xsd: add missing timecode attribute to frameSideDataType
A timecode attribute was added to the ffprobe output of side_data. This patch updates the XSD to include the attribute as well. Dave Rice 0001-ffprobe.xsd-add-missing-timecode-attribute-to-frameS.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames
> On May 31, 2016, at 3:23 PM, Michael Niedermayer
> wrote:
>
> adding demuxer and other logs should be easy
> This forces single threaded decoding for simplicity
> It also requires pthreads, this could be avoided either with
> some lockless tricks or simply by assuming av_log would never be called from
> another thread.
I’ve been testing this patch, but currently the logging does not appear within
the log node. For instance with a fuzzed mpeg2video in QuickTime when I run:
./ffprobe -i /Users/davidrice/fuzzed_mpeg2video.mov -show_log 1 -show_frames
-of xml
Then the output is like:
ffprobe version N-80154-g9c023a7 Copyright (c) 2007-2016 the FFmpeg developers
built with Apple LLVM version 7.3.0 (clang-703.0.31)
configuration: --disable-dwt
libavutil 55. 24.100 / 55. 24.100
libavcodec 57. 44.100 / 57. 44.100
libavformat57. 37.101 / 57. 37.101
libavdevice57. 0.101 / 57. 0.101
libavfilter 6. 46.100 / 6. 46.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 0.101 / 2. 0.101
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/Users/davidrice/fuzzed_mpeg2video.mov':
Metadata:
major_brand : qt
minor_version : 512
compatible_brands: qt
encoder : Lavf57.34.103
Duration: 00:00:04.00, start: 0.00, bitrate: 2668 kb/s
Stream #0:0(eng): Video: mpeg2video (Main) (m2v1 / 0x3176326D),
yuv420p(tv), 640x480 [SAR 1:1 DAR 4:3], 2666 kb/s, 25 fps, 25 tbr, 12800 tbn
(default)
Metadata:
handler_name: DataHandler
encoder : Lavc57.38.100 mpeg2video
[mpeg2video @ 0x7fcfda817600] skipped MB in I frame at 3 18
[mpeg2video @ 0x7fcfda817600] Warning MVs not available
[mpeg2video @ 0x7fcfda817600] concealing 40 DC, 40 AC, 40 MV errors in I frame
[mpeg2video @ 0x7fcfda817600] skipped MB in I frame at 27 6
[mpeg2video @ 0x7fcfda817600] Warning MVs not available
[mpeg2video @ 0x7fcfda817600] concealing 40 DC, 40 AC, 40 MV errors in I frame
[mpeg2video @ 0x7fcfda817600] skipped MB in I frame at 16 13
[mpeg2video @ 0x7fcfda817600] skipped MB in I frame at 29 25
[mpeg2video @ 0x7fcfda817600] Warning MVs not available
[mpeg2video @ 0x7fcfda817600] concealing 80 DC, 80 AC, 80 MV errors in I frame
When the mpeg2video decoding log appears in sdterr, then the node is
written but empty. During a frame when there is no logged message, there is no
node.
Also I’m uncertain what the value to use with -show_log means. I’m using
-show_log 1 for now. Is this for verbosity?
Dave Rice
> doc/ffprobe.xsd update missing (TODO & help welcome)
>
> Fixes Ticket5521
>
> Signed-off-by: Michael Niedermayer
> ---
> ffprobe.c | 154 -
> 1 file changed, 153 insertions(+), 1 deletion(-)
>
> diff --git a/ffprobe.c b/ffprobe.c
> index a7e329c..07b61ec 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -49,6 +49,19 @@
> #include "libpostproc/postprocess.h"
> #include "cmdutils.h"
>
> +#if HAVE_PTHREADS
> +# include
> +#else
> +# ifdef pthread_mutex_lock
> +#undef pthread_mutex_lock
> +# endif
> +# define pthread_mutex_lock(a)
> +# ifdef pthread_mutex_unlock
> +#undef pthread_mutex_unlock
> +# endif
> +# define pthread_mutex_unlock(a)
> +#endif
> +
> typedef struct InputStream {
> AVStream *st;
>
> @@ -84,6 +97,7 @@ static int do_show_library_versions = 0;
> static int do_show_pixel_formats = 0;
> static int do_show_pixel_format_flags = 0;
> static int do_show_pixel_format_components = 0;
> +static int do_show_log = 0;
>
> static int do_show_chapter_tags = 0;
> static int do_show_format_tags = 0;
> @@ -92,6 +106,7 @@ static int do_show_program_tags = 0;
> static int do_show_stream_tags = 0;
> static int do_show_packet_tags = 0;
>
> +
> static int show_value_unit = 0;
> static int use_value_prefix = 0;
> static int use_byte_value_binary_prefix = 0;
> @@ -146,6 +161,8 @@ typedef enum {
> SECTION_ID_FRAME_TAGS,
> SECTION_ID_FRAME_SIDE_DATA_LIST,
> SECTION_ID_FRAME_SIDE_DATA,
> +SECTION_ID_FRAME_LOG,
> +SECTION_ID_FRAME_LOGS,
> SECTION_ID_LIBRARY_VERSION,
> SECTION_ID_LIBRARY_VERSIONS,
> SECTION_ID_PACKET,
> @@ -185,10 +202,12 @@ static struct section sections[] = {
> [SECTION_ID_FORMAT] = { SEC
Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames
> On Jun 8, 2016, at 12:30 PM, Michael Niedermayer > wrote: > > On Tue, Jun 07, 2016 at 08:06:35PM -0400, Dave Rice wrote: >> >>> On May 31, 2016, at 3:23 PM, Michael Niedermayer >>> wrote: >>> >>> adding demuxer and other logs should be easy >>> This forces single threaded decoding for simplicity >>> It also requires pthreads, this could be avoided either with >>> some lockless tricks or simply by assuming av_log would never be called from >>> another thread. >> >> I’ve been testing this patch, but currently the logging does not appear >> within the log node. For instance with a fuzzed mpeg2video in QuickTime when >> I run: >> >> ./ffprobe -i /Users/davidrice/fuzzed_mpeg2video.mov -show_log 1 -show_frames >> -of xml > [...] >> >> When the mpeg2video decoding log appears in sdterr, then the node is >> written but empty. During a frame when there is no logged message, there is >> no node. >> >> Also I’m uncertain what the value to use with -show_log means. I’m using >> -show_log 1 for now. Is this for verbosity? > > you need to set the log level in -show_log high enough so the messages > that you are interrested in are included OK, the value just needs to be higher than I expected. I created a test file with: ffmpeg -f lavfi -i testsrc -bsf noise -t 1 -c:v mpeg2video fuzzed_mpeg2video.mov I don't actually get log info until the -show_log value is up to 16. Then this works: ffprobe fuzzed_mpeg2video.mov -show_log 16 -show_frames -of xml But it outputs invalid xml: <(null) key="context" value="mpeg2video"/> level="16" category="6"<(null) key="message" value="[mpeg2video @ 0x7fa4a380] skipped MB in I frame at 3 0 "/> <(null) key="context" value="mpeg2video"/> level="16" category="6"<(null) key="message" value="[mpeg2video @ 0x7fa4a380] ac-tex damaged at 16 9 "/> <(null) key="context" value="mpeg2video"/> level="16" category="6"<(null) key="message" value="[mpeg2video @ 0x7fa4a380] ac-tex damaged at 11 11 "/> <(null) key="context" value="mpeg2video"/> level="16" category="6"<(null) key="message" value="[mpeg2video @ 0x7fa4a3800000] invalid mb type in I Frame at 9 13 "/> <(null) key="context" value="mpeg2video"/> level="16" category="6"<(null) key="message" value="[mpeg2video @ 0x7fa4a380] Warning MVs not available "/> The 'log' node is called '(null)' and the level and category attributes are outside of a node. > all messages are still printed to stderr too, maybe that is confusing > but feels consistent behavior I agree. [...] Dave Rice signature.asc Description: Message signed with OpenPGP using GPGMail ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskaenc.c: use metadata key/value to set mastering metadata
> On Jun 8, 2016, at 11:03 PM, Neil Birkbeck wrote: > > The most recent patch should still apply cleanly (unless we have a > better way to set these elements). Thanks There are specific mastering metadata elements as recently defined in the Matroska specification [1]. It would be better to use these defined elements from the specification rather than somehow fit this data into tags. Dave Rice [1] https://matroska.org/technical/specs/index.html#MasteringMetadata > On Tue, Apr 19, 2016 at 8:12 AM, Neil Birkbeck > wrote: >> Updated patch attached. >> >> On Sat, Apr 16, 2016 at 7:08 PM, Michael Niedermayer >> wrote: >>> On Sun, Apr 03, 2016 at 03:38:33PM -0700, Neil Birkbeck wrote: >>>> Use "master_display" key/value pair to specify mastering metadata in a >>>> similar formatting as accepted by libx265 (unless there is some other >>>> generic way to add side data to a stream from command line). >>>> Currently, the packet side data propagates from an input file to >>>> output file if it is transmuxed (mkv -> mkv). Perhaps we want to also >>>> use this same metadata key in matroskadec to also allow for the >>>> metadata to propagate during transcoding. >>> >>>> matroskaenc.c | 51 +++ >>>> 1 file changed, 47 insertions(+), 4 deletions(-) >>>> d92564f3ec6cf08430a79b64f4d1ec304637afe1 >>>> 0001-lavf-matroskaenc.c-use-metadata-key-value-to-set-mas.patch >>>> From b30d80f6ba4b09811039f64af3e7f709d86df5fe Mon Sep 17 00:00:00 2001 >>>> From: Neil Birkbeck >>>> Date: Fri, 1 Apr 2016 17:02:42 -0700 >>>> Subject: [PATCH] lavf/matroskaenc.c: use metadata key/value to set >>>> mastering >>>> metadata >>>> >>>> Add key/value metadata interface to allow command line setting of >>>> AVMasteringDisplayMetadata. The formatting is the same as the option in >>>> libx265. >>>> >>>> Signed-off-by: Neil Birkbeck >>> >>> this does not apply cleanly anymore after codecpar >>> >>> Applying: lavf/matroskaenc.c: use metadata key/value to set mastering >>> metadata >>> Using index info to reconstruct a base tree... >>> Falling back to patching base and 3-way merge... >>> Auto-merging libavformat/matroskaenc.c >>> CONFLICT (content): Merge conflict in libavformat/matroskaenc.c >>> Failed to merge in the changes. >>> Patch failed at 0001 lavf/matroskaenc.c: use metadata key/value to set >>> mastering metadata >>> When you have resolved this problem run "git am --resolved". >>> If you would prefer to skip this patch, instead run "git am --skip". >>> To restore the original branch and stop patching run "git am --abort". >>> >>> >>> [...] >>> >>> -- >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >>> >>> Democracy is the form of government in which you can choose your dictator >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_histogram: shortcuts for histogram options
This patch adds some shortcuts for the histogram filter's options in a way that is consistent with the waveform and vectorscope filter. Dave Rice 0001-avfilter-vf_histogram-shortcuts-for-histogram-option.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_histogram: indent histogram options
Some indentation after the previous patch. Dave Rice 0002-avfilter-vf_histogram-indent-histogram-options.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm
> On Jun 21, 2016, at 3:22 PM, Michael Niedermayer > wrote: > > On Mon, Jun 20, 2016 at 08:20:47PM -0700, Michael Bradshaw wrote: >> Hi, >> >> Attached patch removes SegmentUID element from WebM files, as it's >> unsupported in WebM[1]. >> >> Please review/apply. >> >> Thanks, >> >> Michael >> >> [1]: https://www.webmproject.org/docs/container/#SegmentUID > > what does "supported" / "unsupported" mean, is this defined somewhere ? > > In a format something can be > Forbidden, aka >you write it you are buggy, you see it you can bail out > > Required, aka >you dont write it you are buggy, you dont see it you can bail out > > Optional-Ignore, aka >you may write it if you like, you may ignore it if you like, you must not > bail out > > Optional-Fail, aka >you may write it if you like, you may bail out if you see it > > Undefined-Ignore >you write it you are buggy, you may ignore it if you like, you must not > bail out > > > The reason why this question matters is because > If its forbidden to be written then the patch is correct and the > only option, OTOH > if its allowed to be written but the demuxer can ignore it there may > or may not be arguments to write it anyway [...] From my reading of the current EBML specification this is "Undefined-Ignore", but is also something that should not be done. The closest sentence on this from the EBML specification seems to be: "Element Data stored within Master-elements SHOULD only consist of EBML Elements and SHOULD NOT contain any data that is not part of an EBML Element." I think "EBML Element" in this case should be considered to mean "EBML Elements as defined by the EBML DocType". The webm EBML Schema does not define a SegmentUID Element as Matroska does, so the Element is meaningless in webm. It may happen to follow the EBML Header pattern but in the context of webm it is junk data. Best Regards, Dave Rice signature.asc Description: Message signed with OpenPGP using GPGMail ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm
> On Jun 22, 2016, at 10:16 AM, Michael Bradshaw wrote: > > On Tue, Jun 21, 2016 at 12:22 PM, Michael Niedermayer > wrote: >> what does "supported" / "unsupported" mean, is this defined somewhere ? > > As far as WebM is concerned, SegmentUID doesn't exist. > > In this situation, writing SegmentUID is Undefined-Ignore or > Optional-Fail/Forbidden, depending on the file. I concur with Dave's > analysis, but parsing may fail if SegmentUID is written and the master > element has an unknown size (which will be the case if ffmpeg is > writing to an unseakable output, like pipes). This is because master > elements with unknown size are terminated by the first unrecognized > would-be-child element[1], which would cause the parser to terminate > the Info element. I don’t quite think that the EBML specification agrees with this explanation. See: "When EBML is used in transmission or streaming, data that is not part of an EBML Element is permitted to be present within a Master-element if `unknownsizeallowed` is enabled within that Master-element's definition. In this case, the reader should skip data until a valid Element ID of the same level or the next greater level of the Master-element is found. What Element IDs are considered valid within a Master-element is identified by the EBML Schema for that version of the EBML Document Type. Any data contained with a Master-element that is not part of an Element SHOULD be ignored." In this case a SegmentUID Element (undefined in webm) should be skipped be the reader rather than cause the termination of the reader. The end of an unknown-sized Element is determined by the beginning of the next known Element that is not a valid sub-element rather than the first unknown Element. > This would continue to screw up parsing, because now > there could be other children of Info (like DateUTC) after the > SegmentUID, and since the Info element has terminated and those aren't > valid children of Segment, it would cause the Segment element to > terminate. At that point, the file is pretty broken because now there > is no Segment element containing the Clusters and other elements. > > [1]: "The end of a Master-element with unknown size is determined by > the beginning of the next element that is not a valid sub-element of > that Master-element" (from the current EBML spec) Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.
> On Mar 2, 2017, at 9:59 AM, James Almer wrote: > > On 3/2/2017 11:47 AM, Tobias Rapp wrote: >> On 02.03.2017 15:22, James Almer wrote: >>> On 3/2/2017 6:28 AM, Nicolas George wrote: >>>> Le primidi 11 ventôse, an CCXXV, James Almer a écrit : >>>>> Ah, i see there's generic code to read and write CodecPrivate elements >>>>> to and from raw extradata for native codecids where no special handling >>>>> is required. >>>>> >>>>> In any case, the spec says >>>>> >>>>> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written." >>>>> >>>>> The ffv1 encoder creates extradata for v2 and newer, so the muxer >>>>> should have a custom case for ffv1 in order to detect v2 streams and >>>>> avoid writing said extradata. >>>> >>>> I have not looked myself at the situation, I only read what you wrote >>>> her. According to it, it seems here the FFV1 encoder is violating the >>>> specification and needs to be fixed. >>> >>> I can't say if the encoder exporting extradata for version 2 is right or >>> wrong, as muxers or bsfs could still use it for whatever reason, but at >>> least according to the draft ffv1 spec by Michael, it's to be stored at >>> the container level *only* on versions 3 and above. >>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1 >> >> The IETF draft explicitly excludes to specify FFV1 version 2: >> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1 >> >> IIRC there have been some edits to remove references to version 2 in the >> IETF draft. In the older document at >> http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the section >> contains "version >= 2". >> >> Regards, >> Tobias > > Well, that makes things a bit more complex. > Maybe the Matroska spec should follow and also avoid mentioning v2? > That way we could just pretend those files don't exist and not bother > trying to drop their extradata during muxing. I agree. In the FFV1 spec, it is careful to say that it intentionally does not describe FFV1 version 2. I will submit a patch to the Matroska specification to avoid using relative language based on version 2. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC][PATCH] movenc: write clap tag
Hi all,
I’m looking for some assistance on this patch which is intended to resolve
https://trac.ffmpeg.org/ticket/6145 <https://trac.ffmpeg.org/ticket/6145>.
In
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
<https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html>,
regarding the clap atom, it states "This is a mandatory extension for all
uncompressed Y´CbCr data formats”. This patch is intended to write the clap
atom in those cases as a coincident with the stored image (not supported a
cropped aperature yet), but I’m having trouble associating it with the correct
conditional formats.
Currently this patch writes the clap atom under this condition
"track->par->codec_id == AV_CODEC_ID_RAWVIDEO & track->mode == MODE_MOV”;
however, AV_CODEC_ID_RAWVIDEO isn’t quite what the spec asks for. Any advice on
how to write this condition for “uncompressed Y´CbCr data formats”; for
instance v210 is considered uncompress Y´CbCr in QuickTime but is not a
AV_CODEC_ID_RAWVIDEO. I haven’t found a concise way to add a condition for
uncompressed YUV.
Other comments welcome. Thanks.
From a5e399c6eeaa64aef52dc498cc62114428f42941 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 6 Jul 2017 21:12:38 -0400
Subject: [PATCH] movenc: write clap tag
---
libavformat/movenc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 88f2f2c819..033e8550b2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1669,6 +1669,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 64);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* aperatureWidth numerator */
+avio_wb32(pb, 1); /* aperatureWidth denominator (= 1) */
+avio_wb32(pb, track->height); /* aperatureHeight numerator */
+avio_wb32(pb, 1); /* aperatureHeight denominator (= 1) */
+avio_wb32(pb, 0); /* horizontal offset numerator (= 0) */
+avio_wb32(pb, 1); /* horizontal offset denominator (= 1) */
+avio_wb32(pb, 0); /* vertical offset numerator (= 0) */
+avio_wb32(pb, 1); /* vertical offset denominator (= 1) */
+return 64;
+}
+
static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
{
AVRational sar;
@@ -1939,6 +1954,10 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
av_log(mov->fc, AV_LOG_WARNING, "Not writing 'colr' atom. Format
is not MOV or MP4.\n");
}
+if (track->par->codec_id == AV_CODEC_ID_RAWVIDEO & track->mode ==
MODE_MOV) {
+mov_write_clap_tag(pb, track);
+}
+
if (track->mode == MODE_MP4 && mov->fc->strict_std_compliance <=
FF_COMPLIANCE_UNOFFICIAL) {
AVStereo3D* stereo_3d = (AVStereo3D*)
av_stream_get_side_data(track->st, AV_PKT_DATA_STEREO3D, NULL);
AVSphericalMapping* spherical_mapping =
(AVSphericalMapping*)av_stream_get_side_data(track->st, AV_PKT_DATA_SPHERICAL,
NULL);
--
2.13.0
Best Regards,
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] movenc: write clap tag
> On Jul 6, 2017, at 9:39 PM, Derek Buitenhuis > wrote: > > On 7/7/2017 2:20 AM, Dave Rice wrote: >> Currently this patch writes the clap atom under this condition >> "track->par->codec_id == AV_CODEC_ID_RAWVIDEO & track->mode == MODE_MOV”; >> however, AV_CODEC_ID_RAWVIDEO isn’t quite what the spec asks for. Any advice >> on how to write this condition for “uncompressed Y´CbCr data formats”; for >> instance v210 is considered uncompress Y´CbCr in QuickTime but is not a >> AV_CODEC_ID_RAWVIDEO. I haven’t found a concise way to add a condition for >> uncompressed YUV. > > First, it should be '&&', I assume. Thanks. > I don't think there's any concise way of checking such conditions... you'll > probably have to do something like a list of "codes" (v410, v210, raw) and > some sort of sanity check for track->par->format to confirm is is YCbCr. > Maybe someone knows better than myself. I see that although it’s mandatory for uncompressed YUV, there’s no constraint to not use it otherwise, so I think I’ll proceed with just a check for MODE_MOV. I just checked ffmbc’s movenc.c and it also only checks for MODE_MOV. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movenc: write clap tag
Resolves https://trac.ffmpeg.org/ticket/6145 and writes a clap atom that is
coincident with the frames width and height.
From 23d80d0d47829fed61e817b1e7c3f6d420c9ab5c Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 6 Jul 2017 21:12:38 -0400
Subject: [PATCH] movenc: write clap tag
---
libavformat/movenc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 88f2f2c819..31a5de8d5c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1669,6 +1669,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
{
AVRational sar;
@@ -1939,6 +1954,10 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
av_log(mov->fc, AV_LOG_WARNING, "Not writing 'colr' atom. Format
is not MOV or MP4.\n");
}
+if (track->mode == MODE_MOV) {
+mov_write_clap_tag(pb, track);
+}
+
if (track->mode == MODE_MP4 && mov->fc->strict_std_compliance <=
FF_COMPLIANCE_UNOFFICIAL) {
AVStereo3D* stereo_3d = (AVStereo3D*)
av_stream_get_side_data(track->st, AV_PKT_DATA_STEREO3D, NULL);
AVSphericalMapping* spherical_mapping =
(AVSphericalMapping*)av_stream_get_side_data(track->st, AV_PKT_DATA_SPHERICAL,
NULL);
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: write clap tag
> On Jul 7, 2017, at 11:32 AM, Derek Buitenhuis > wrote: > > On 7/7/2017 3:20 AM, Dave Rice wrote: >> Resolves https://trac.ffmpeg.org/ticket/6145 and writes a clap atom that is >> coincident with the frames width and height. >> >> >> From 23d80d0d47829fed61e817b1e7c3f6d420c9ab5c Mon Sep 17 00:00:00 2001 >> From: Dave Rice >> Date: Thu, 6 Jul 2017 21:12:38 -0400 >> Subject: [PATCH] movenc: write clap tag >> >> --- >> libavformat/movenc.c | 19 +++ >> 1 file changed, 19 insertions(+) > > Whoever pushes, add the ticket number into the commit message. > > [...] > >> +avio_wb32(pb, 0); /* horizOff_N (= 0) */ >> +avio_wb32(pb, 1); /* horizOff_D (= 1) */ >> +avio_wb32(pb, 0); /* vertOff_N (= 0) */ >> +avio_wb32(pb, 1); /* vertOff_D (= 1) */ > > Near as I can tell, these related the active image area? Is it useful to ever > set > this to anything but 0 (aka the whole image is active)? Usually not a good idea to set a denominator to zero. The clap atom documentation at https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP4939-CH205-125850 <https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP4939-CH205-125850> specifies zero for numerators and one for denominators as default when the ratio of an actual aperture is not used. > Was thinking of stuff like > analogue video, a la http://chromashift.org/aspectratio/. I assume the answer > is > probably 'no’. The atom is analogous to the PixelCrop* elements of Matroska. For instance a standard definition NTSC video may typically be digitized to a frame size of 720x486 but the active image might only be 704x480, so the aperture atom could express the difference. > Patch itself LGTM. […] Thanks, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: write clap tag
> 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 >> would be written on any mov file with a video stream. > > This was addressed a previous email: > >http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html > > I guess the spec is up for interpretation. The quicktime spec says "This is a mandatory extension for all uncompressed Y´CbCr data formats”. It doesn’t clarify if the clap atom is recommended or not in mov files that are not “uncompressed Y´CbCr”, though it would make sense if the video container needs to store cropping data. I think constraining the change for only “uncompressed Y´CbCr” would be more cautious though. I’ll revise my patch to include the condition and resubmit. If the patch only impacts “uncompressed Y´CbCr” would any fate updates be needed? Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: fix setting field_order during muxing
> On Aug 10, 2017, at 5:18 PM, Jerome Martinez wrote: > > Le 10/08/2017 à 04:43, James Almer a écrit : >> AVFrame.top_field_first doxy states >> >> "If the content is interlaced, is top field displayed first." >> >> And AVFieldOrder doxy defines: >> AV_FIELD_TB, //< Top coded first, bottom displayed first >> AV_FIELD_BT, //< Bottom coded first, top displayed first >> >> Fixes ticket #6577 > > IMHO the subject is complex, and everyone should be in sync with the purpose > of each mux_par->field_order value and understand impact on other players > (sometimes the MOV metadata is the only one available as the codec has no > info e.g. uncompressed or jp2k) before changing current behavior in a so > general manner. > What I understood is that it is based on QuickTime specs (the mapping is 1 to > 1 from fiel atom) and TN2162 and that they are not easy to understand and > maybe misleading : the feedback I got in the last years about the meaning of > this atom are not really in sync with specs having stored vs displayed, and > such change may have an impact on how other players handle fiel atom or other > metadata in the way it is currently implemented by FFmpeg. I filed ticket #6577 but not feel cautious about this patch and consider that my initial report may have been based on some misunderstanding. As Jerome notes the MKV field order flag is derived from mov's fiel atom and there are two definitions for that: https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html (Table 4-2) https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION (Figure 4) From testing we have found that ffmpeg's behavior here is matching some Apple mov muxers in the assignment of a field order value, so the patch may be unneeded or the reason may need more testing. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling
Hello all,
This issue originated in this thread
https://github.com/amiaopensource/vrecord/issues/170. On Field Order, in the
QuickTime specification at
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
(and similarly in the Matroska specification which adopted similar language)
it states the following meanings for field order values:
> 9 – B is displayed earliest, T is stored first in the file. 14 – T is
> displayed earliest, B is stored first in the file.
This definition is contradicted by other Apple documentation such as
https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION.
An Apple engineer confirmed that the QuickTime specification’s definitions for
those Field Order values is wrong and does not match Apple’s (of FFmpeg’s)
practice, see
https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668.
However I think that some of the commenting in ffmpeg is based upon the
inaccurate definitions from Apple. For instance, in that thread David Singer
confirms:
> Ah, not quite. 1 and 6 are indeed 'planar' (all of one field before all of
> the other). They don't concern us. Both 9 and 14 are stored in spatial order
> (i.e. you could do terrible de-interlacing by simply displaying the buffer as
> a frame), and the 9 or 14 value tells you which field is to be displayed
> first.
>
> 9 – T is earlier than B. 14 – B is earlier than T
mov.c associates AV_FIELD_TB with 9 and AV_FIELD_BT with 14 (similar
associations in matroska.h), but avcodec.h states:
> AV_FIELD_TB, //< Top coded first, bottom displayed first
> AV_FIELD_BT, //< Bottom coded first, bottom displayed first
IMHO in both cases of AV_FIELD_TB and AV_FIELD_BT the coding should be referred
as interleaved rather than ‘bottom coded first’ or ‘top coded first’. In the
case of AV_FIELD_TT and AV_FIELD_BB the fields are stored as planar images
where storage order is notable, but with TB and BT the fields are interleaved.
Also utils.c associates these field order values with the following labels:
> AV_FIELD_TB -> "top coded first (swapped)";
> AV_FIELD_BT -> "bottom coded first (swapped)";
From my reading, I infer that "top coded first (swapped)” means "top coded
first, bottom displayed first”; however in practice from files generated by
QuickTime and FFmpeg files with a value of TB have the top field displayed
first, so I think the labels are swapped. In the patch below I suggest using
“top first (interleaved)” for TB and “bottom first (interleaved)” for BT.
Comments?
From de871b3fa891fa0ae6856461c1f8305cc889cde7 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Sat, 12 Aug 2017 12:30:43 -0400
Subject: [PATCH] libavcodec: fix field_order labelling
---
libavcodec/avcodec.h | 4 ++--
libavcodec/utils.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993766..37c39072b3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1726,8 +1726,8 @@ enum AVFieldOrder {
AV_FIELD_PROGRESSIVE,
AV_FIELD_TT, //< Top coded_first, top displayed first
AV_FIELD_BB, //< Bottom coded first, bottom displayed first
-AV_FIELD_TB, //< Top coded first, bottom displayed first
-AV_FIELD_BT, //< Bottom coded first, top displayed first
+AV_FIELD_TB, //< Interleaved coding, top displayed first
+AV_FIELD_BT, //< Interleaved coding, bottom displayed first
};
/**
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1336e921c9..926c964846 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1406,9 +1406,9 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
else if (enc->field_order == AV_FIELD_BB)
field_order = "bottom first";
else if (enc->field_order == AV_FIELD_TB)
-field_order = "top coded first (swapped)";
+field_order = "top first (interleaved)";
else if (enc->field_order == AV_FIELD_BT)
-field_order = "bottom coded first (swapped)";
+ field_order = "bottom first (interleaved)";
av_strlcatf(detail, sizeof(detail), "%s, ", field_order);
}
--
2.13.1
Thanks much,
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: Add bits_per_component to stream output
On Sep 4, 2014, at 8:39 AM, Tobias Rapp wrote: > Attached patch adds bits_per_component (bit depth) output for video streams. Adding an element to the ffprobe output requires a change to ffprobe.xsd as well. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On Sep 4, 2014, at 10:44 AM, Deron wrote: > On 9/4/14 8:06 AM, Roger Pack wrote: >> Do you have some instructions on how to get the headers to make this >> download work? Any links to some device to exercise the code, like on >> amazon [cheaper better LOL]. >> > The DeckLink headers/sdk/libraries can be found at blackmagicdesign.com. The > last copy I downloaded was > http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.1.tar.gz. > A more recent version may be available. Yes http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.4.tar.gz is available. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] ffprobe: add -show_pixel_descriptions option
On Sep 8, 2014, at 10:08 AM, Tobias Rapp wrote: > As a follow-up to the "ffprobe: Add bits_per_component to stream output" > discussion thread here comes my current state of adding pixel format detail > output to ffprobe. > > I'm still unsure if/how to output pixel format flags. Maybe as a simple > white-space separated string "rgb alpha be"? > > Any feedback or suggestions are welcome. > > BTW: How can one test the ffprobe XML output against the XSD? I tried it with > "xmllint --noout --schema doc/ffprobe.xsd ffprobe-output.xml" without > success. What tools do other developers use? That's the command that I use; however when generating the xml use the fully qualified option, ie: ffprobe -f lavfi mandelbrot -show_streams -show_format -of xml=q=1 > test.xml xmllint --noout --schema ffprobe.xsd test.xml test.xml validates dave rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On Sep 14, 2014, at 7:07 AM, Deti Fliegl wrote: > I really would like to bring things forward, but currently nobody wants to > review this patch. It's primarily something that is used under Linux and not > Windows. So please would anyone have a look at my patch. I have a few decklink devices and would be happy to review this on Mac. Does it work on Mac? Dave Rice > Deti > > On 30.08.14 01:22, Michael Niedermayer wrote: >> On Sat, Aug 23, 2014 at 10:50:37PM +0200, Deti Fliegl wrote: >>> On 19.08.14 15:43, Carl Eugen Hoyos wrote: >>>> Deti Fliegl fliegl.de> writes: >>>> >>>>> Minor update to propagate field dominance. >>>> >>>> At least a Changelog entry and a libavdevice version >>>> bump are still missing, but consider waiting for a >>>> real review. >>> Well in the meantime I updated my patch once again to add proper >>> frame sizes and frame rates to the video codec. Maybe somebody wants >>> to review the patch. >>> >>> Deti >>> >> >>> configure |4 >>> doc/indevs.texi | 54 >>> libavdevice/Makefile|5 >>> libavdevice/alldevices.c|2 >>> libavdevice/decklink_common.cpp | 229 + >>> libavdevice/decklink_common.h | 98 +++ >>> libavdevice/decklink_common_c.h | 32 ++ >>> libavdevice/decklink_dec.cpp| 531 >>> >>> libavdevice/decklink_dec.h | 32 ++ >>> libavdevice/decklink_dec_c.c| 54 >>> libavdevice/decklink_enc.cpp| 196 +- >> >> moving code from (like from decklink_enc.cpp to decklink_common.cpp) >> should be in a seperate patch >> >> >>> libavdevice/decklink_enc.h | 11 >>> libavdevice/decklink_enc_c.c|1 >>> 13 files changed, 1055 insertions(+), 194 deletions(-) >> >> If you want to maintain this code, please add yourself to the >> MAINTAINERs file >> >> >> [...] >> >>> +#ifdef _WIN32 >>> +char *dup_wchar_to_utf8(wchar_t *w) >> >> non static functions should have a ff_ prefix (or av if they are >> public but that isnt) >> >> also i dont really know windows & decklink stuff, so iam not the >> ideal one to review ... >> >> [...] >> >> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/signalstats: add more pixel formats
On Sep 25, 2014, at 1:26 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_signalstats.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
> index 53f7401..47545aa 100644
> --- a/libavfilter/vf_signalstats.c
> +++ b/libavfilter/vf_signalstats.c
> @@ -96,6 +96,9 @@ static int query_formats(AVFilterContext *ctx)
> // TODO: add more
> static const enum AVPixelFormat pix_fmts[] = {
> AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P,
> AV_PIX_FMT_YUV411P,
> +AV_PIX_FMT_YUV440P,
> +AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ420P,
> AV_PIX_FMT_YUVJ411P,
> +AV_PIX_FMT_YUVJ440P,
> AV_PIX_FMT_NONE
> };
>
> --
> 1.7.11.2
Tested and works for me.
Thanks,
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Oct 23, 2014, at 4:05 AM, Clément Bœsch wrote:
> On Tue, Oct 21, 2014 at 09:32:39AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> It appears to me that we all know that fieldmatch needs cfr input,
>> but it isn't mentioned in the documentation.
>> Related to ticket #3968.
>>
>> Please comment, Carl Eugen
>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index c70ddf3..bc77623 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -4447,6 +4447,9 @@ and VIVTC/VFM (VapourSynth project). The later is a
>> light clone of TFM from
>> which @code{fieldmatch} is based on. While the semantic and usage are very
>> close, some behaviour and options names can differ.
>>
>> +The filter only works for strictly constant frame rate input. If your input
>> +has variable frame rate, try the @ref{pullup} filter.
>> +
>
> Well... isn't telecined content supposed to be CFR anyway? I would say
> it's supposed to be undefined behaviour in any ivtc filter but well. No
> opinion really.
This would be ideal, but some common production applications use VFR. For
instance when digitizing with the Log and Capture interface of Final Cut Pro
the first and last frame usually have custom durations although most of the
rest of the file is 2997/100. There’s another setting in the Final Cut to
compensate for dropped frames by extending the duration of the last good
captured frame.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data
> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis > wrote: > > On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote: >> I think we should drop the internal crap if the tools and the API support >> it. Would also solve a lot of issues like ffmpeg.c not trimming the start >> frame (so people complain all the time about longer files). > > I personally agree, but I thought I'd be diplomatic about it, since it would > technically be losing a 'feature', since it would no longer Just Work(ish) > and require user applications to apply timelines 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data
> 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: >>>> I think we should drop the internal crap if the tools and the API support >>>> it. Would also solve a lot of issues like ffmpeg.c not trimming the start >>>> frame (so people complain all the time about longer files). >>> >>> I personally agree, but I thought I'd be diplomatic about it, since it would >>> technically be losing a 'feature', since it would no longer Just Work(ish) >>> and require user applications to apply timelines 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 > > Some explanations how this interacts with editions would be good. I put an example with two editions at https://archive.org/download/chapters_test/chapters_test.mkv which mimics a digitized video tape. One edition depicts the stored video encoding in its entire presentation and the other default edition plays from the video encoding selectively. When the file is played in VLC, the default edition is used to show a shortened presentation, but the other editions may be selected within the Program menu option. In the proposal there should be an option to mimic the current behavior and ignore the editions (equivalent of -ignore_editlist in mov), to use the first default edition, or to select a specific edition. > Or documenting ordered chapters and segment linking in the mkv "spec" > at all. This document, http://mod16.org/hurfdurf/?p=8 <http://mod16.org/hurfdurf/?p=8>, is unofficially a good resource on that. More officially the Cellar working group has this section on Linked Segments: https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-23 <https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-23>, and this one on Ordered Editions: https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-10.1.2.3 <https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-10.1.2.3>. This documentation is a work in progress so comments/reviews/suggestions are welcome (issues can be filed at https://github.com/Matroska-Org/matroska-specification <https://github.com/Matroska-Org/matroska-specification> or via https://www.ietf.org/mailman/listinfo/cellar <https://www.ietf.org/mailman/listinfo/cellar>). Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data
> 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 Rice wrote: >>> >>>>> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis >>>>> wrote: >>>>> >>>>> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote: >>>>>> I think we should drop the internal crap if the tools and the API support >>>>>> it. Would also solve a lot of issues like ffmpeg.c not trimming the start >>>>>> frame (so people complain all the time about longer files). >>>>> >>>>> I personally agree, but I thought I'd be diplomatic about it, since it >>>>> would >>>>> technically be losing a 'feature', since it would no longer Just Work(ish) >>>>> and require user applications to apply timelines 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 >>> >>> Some explanations how this interacts with editions would be good. >> >> I put an example with two editions at >> https://archive.org/download/chapters_test/chapters_test.mkv which mimics a >> digitized video > > Also this file lacks a chapter end time in the second edition. How is > that valid? You’re right. I moved this discussion to cellar, but when the Edition is Ordered then ChapterTimeEnd is required. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg.c: use sigterm_handler with sigpipe
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 <http://ffmpeg.org/pipermail/ffmpeg-user/2018-January/038549.html> --- fftools/ffmpeg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 0c16e75ab0..dfcc865dcf 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -406,6 +406,7 @@ void term_init(void) signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/ signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */ +signal(SIGPIPE, sigterm_handler); /* Termination (pipe closed). */ #ifdef SIGXCPU signal(SIGXCPU, sigterm_handler); #endif -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: use sigterm_handler with sigpipe
Thread bump. > On Jan 11, 2018, at 5:51 PM, Nicolas George wrote: > > Moritz Barsnick (2018-01-11): >> This patch doesn't change the handling of SIGTERM > > You should have read SIGPIPE, obviously. > >> Is SIGPIPE an interactive signal? > > Of course not. > >> Anything on the other side of output >> file(name) "-" or "pipe:N" may terminate for some reason. > > Yes, that is exactly what SIGPIPE is for. > >> This patch does NOT try to ignore anything. ffmpeg won't keep running >> due to ignoring of SIGPIPE, it will terminate more cleanly due to >> handling it. The former is not desired. (But yes, shall handing to >> enforce ignoring it would allow that.) > > It will terminate less cleanly than if you do the right thing with > 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
Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
> On Feb 5, 2018, at 4:20 PM, Jerome Martinez wrote: > > On 03/02/2018 14:48, Michael Niedermayer wrote: >> >> I hope this will not reduce interrest in working on a improved >> 9-16bit mode in v4. > > I don't like to put politics in technical stuff, but here this is politics, > and I think that blocking an easy improvement of FFV1 v3 encoding/decoding in > FFmpeg (actually just using the current FFV1 v3, and also v1 actually, > specification without having artificial limitations about bit depths for a > specific color space, i.e. 16-bit support was already there for YUV before I > work on FFV1) just for forcing people to do a completely different work (e.g. > working on FFV1 v4) is not fair and IMO is not in the idea behind open source. > IMO if interest for 9-16bit (side note: I don't see why 8-bit should not be > in the range, some ideas I have for v4 are useful also for 8-bit) mode in v4 > is reduced, that would only mean that v3 is already so great and/or just that > people have no better idea right now, it is not bad, and both works (using v3 > at the maximum of its possibilities and working on v4) are separate works. > FYI criticism I saw about FFV1 is not compression ratio but speed (playing a > 4K stream is just impossible on a "normal" machine, you need a very expensive > CPU for that) so my plan is to focus on speed improvement in priority. It > could be v4 stuff (incompatible changes), or v3 (encoder/decoder > optimization), depending of what I find. IMHO, improved higher bit depths in version 4 is very interesting. We already have a few noted exceptions where version 4 is intended to fix and optimize a few things of version 3 (signed 16 bit handling, RGB plane order for 9-15 bits), so a change in optimization of high bit depth handling seems already appropriate for consideration. >> [...] >> >>> Last but not least, since almost two years now it's impossible >>> to work on the development of FFV1 v4. It's always the wrong >>> time and/or the wrong place every time I am doing something for >>> this cause. Why? This is extremely frustrating. >> I want to understand this too. IMO v4 development should be more >> important than or at least equally to the v3 draft polishing and neither >> should block the other. > > Also politics, but I don't understand who is blocking v4 from your point of > view. "impossible to work on v4"? Where? As far as I see 1 person (me) said > his priority is having FFV1 v3 becoming a standard (so IETF related work) and > widely used (so any bit depth for any supported color space in v3 because it > is an easy demonstration that FFV1 is versatile without having to wait for v4 > R&D, especially because v3 bitstream design is already pretty good and > versatile) because this is what I need, and my personal case is not blocking > anyone else for sending patches for either FFV1 specifications or FFmpeg code > about v4. Eager to see patch proposals for v4 (and v3 if it does not break > support of files in the wild), whoever feeling blocked with his patches > should send patch proposals to either FFmpeg (code) or CELLAR mailing list > (bitstream format). > > That said, I plan to add more pix_fmt support for FFV1 v3 (which is already a > good format!) support in FFmpeg and some optimization ideas beside my work > for IETF spec, with the hope we could speak about technical issues (e.g. more > optimization hints or info about wrong code or warning about that it breaks > the bitstream specs as currently written), leaving aside politics. In the cellar charter and timeline, the effort to produce a informational specification for FFV1 video codec versions 0, 1 and 3 precedes the effort to produce a specification for FFV1 video codec version 4. Initially I anticipated that the version 4 specification would be a fork from the completed version 0,1,3 draft; however, I think the current approach (one doc that ‘makes’ both outputs) works well to allow version 4 work to proceed without blocking any remaining version 0,1,3 work. Still I suggest that we resolve https://github.com/FFmpeg/FFV1/pull/87 and https://github.com/FFmpeg/FFV1/pull/71 soon as IMHO the version 0,1,3 informational specification is 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
Re: [FFmpeg-devel] [PATCH 1/2] avformat/dv: allow returning damaged audio
> 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 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 Niedermayer >>>>>>> --- >>>>>>> libavformat/dv.c | 49 +--- >>>>>>> 1 file changed, 42 insertions(+), 7 deletions(-) >>>>>> >>>>>> If "dv remux loses sync", then the timestamps should be fixed, not >>>>>> additional packets should be generated based on previously read packet >>>>>> data >>>>>> (which is a fragile approach to begin with, e.g. what if the first frame >>>>>> is >>>>>> the corrupt one?). >>>>> >>>>> Ticket8762 is about stream copy, so if no packets are returned for audio >>>>> but are for video and just timestamps are updated this would at least on >>>>> its own probably not work that well. >>>> >>>> If the timestamps are good, a good player should be able to play it >>>> correctly, even if audio stream is sparse. >>>> >>>> None of the demuxers generate packets because the timestamps are not >>>> continous, I just don't think it would be consistent if DV suddenly >>>> started to do this. E.g. what if the user wants to drop video with >>>> no audio? >>> >>> In practice, when dv frames with video and no audio are interleaved >>> within a dv stream that otherwise has both, it is because the playback >>> videotape player of the dv tape is in pause mode or the tape is damaged. >>> These frames most common are filled with only video dif blocks that note >>> concealment (so the image is a copy of a prior image) and the audio >>> source pack metadata is missing, but the paylock of the audio dif blocks >>> are filled with error code so they would decode as silence. >> >> But if the audio source pack metadata is missing, then how can you determine >> the audio settings? I tested with QuickTime Player 7 and when frames are read with the audio source pack metadata missing, the first audio source pack is used. So these frames provide silent output as an earlier audio source pack is used. The disadvantage here is that a mid stream change such as 32kHz to 48kHz causes QuickTime Player 7 to mangle the audio by applying the wrong characteristics. >> Or the number of samples the errornous frame contains >> (e.g. 1600 v.s 1602)? > > some testcase would be useful here where this is done clearly wrong currently I put two additional samples at https://archive.org/download/001.dv.audiogap/001.dv.audiogap.dv <https://archive.org/download/001.dv.audiogap/001.dv.audiogap.dv> and https://archive.org/download/001.dv.audiogap/DVC00036_001.dv.audiogap.dv <https://archive.org/download/001.dv.audiogap/DVC00036_001.dv.audiogap.dv>. Each contains a series of frames in the middle that have all video blocks as concealed and all audio blocks are simply error code with no audio source pack. For each example, both "ffmpeg -i file -c copy out” and “ffmpeg -i file out” has a loss of sync in the result and an audio track shorter than the video. But true, a frame with no audio source pack does not communicate if it should be 1600 or 1602 samples. In the SMPTE specification for DV at http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf <http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf>, it says on page 18 that for NTSC systems, the five-frame pattern should be: 1600, 1602, 1602, 1602, 1602. So if a frame has no audio source pack, the pattern of prior frames could be used or simply use this pattern upon finding a sequence of such frames starting at 1600. Or possibly the relationship between the starting time of the audio data and the starting time for the video data could be used to guess if 1600 or 1602 maintains the alignment more closely. >> Also maybe setting the CORRUPT packet flag should be done in this case? > > yes was thinking that too, that should be in the next revision In the reference specification, table 26 shows how the STA value is interpreted to note if the frame contains concealed video DIF blocks or not. This doesn’t necessarily mean that the frame is corrupt, but that it is the product of data concealment caused by a misreading of the DV videotape. […] 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".
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > -ret: 0 st: 1 flags:0 ts:-0.058333 > +ret: 0 st: 1 flags:0 ts:-0.04 > ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0 > size:144000 > -ret: 0 st: 1 flags:1 ts: 2.835833 > +ret: 0 st: 1 flags:1 ts: 2.84 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > ret: 0 st:-1 flags:0 ts: 1.730004 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > @@ -31,10 +31,10 @@ ret: 0 st: 0 flags:0 ts:-0.48 > ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0 > size:144000 > ret: 0 st: 0 flags:1 ts: 2.40 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > -ret: 0 st: 1 flags:0 ts: 1.306667 > -ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > -ret: 0 st: 1 flags:1 ts: 0.200833 > +ret: 0 st: 1 flags:0 ts: 1.32 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > +ret: 0 st: 1 flags:1 ts: 0.20 > +ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos: 72 > size:144000 > ret: 0 st:-1 flags:0 ts:-0.904994 > ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 0 > size:144000 > ret: 0 st:-1 flags:1 ts: 1.989173 > @@ -43,9 +43,9 @@ ret: 0 st: 0 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.671667 > +ret: 0 st: 1 flags:0 ts: 2.68 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > -ret: 0 st: 1 flags:1 ts: 1.565833 > +ret: 0 st: 1 flags:1 ts: 1.56 > ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos:3456000 > size:144000 > ret: 0 st:-1 flags:0 ts: 0.460008 > ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos:1728000 > size:144000 > — > 2.26.2 Best Regards, Dave Rice ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> 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’s recent patch does address the issue documented in 8762, I
>> haven’t found this patch to fix the issue. I tried with -c:a copy and with
>> -c:a pcm_s16le with some sample files that exhibit this issue but each
>> output was out of sync. I put an output at
>> https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795. That
>> output notes that 3597 packages of video are read and 3586 packets of audio.
>> In the resulting file, at the end of the timeline the audio is 9 frames out
>> of sync and my output video stream is 00:02:00.020 and output audio stream
>> is 00:01:59.653.
>>
>> Beyond copying or encoding the audio, are there other options I should use
>> to test this?
>
> Well, it depends on what you want. After this patch you should get a file
> which has audio packets synced to video, but the audio stream is sparse, not
> every video packet has a corresponding audio packet. (It looks like our MOV
> muxer does not support muxing of sparse audio therefore does not produce
> proper timestamps. But MKV does, please try that.)
>
> You can also make ffmpeg generate the missing audio based on packet
> timestamps. Swresample has an async=1 option, so something like this should
> get you synced audio with continous audio packets:
> ffmpeg -y -i 167052_12.dv -c:v copy \
> -af aresample=async=1:min_hard_comp=0.01 -c:a pcm_s16le 167052_12.mov
Thank you for this. With the patch and async, the result is synced and the
resulting audio was the same as Michael’s patch.
Could you explain why you used min_hard_comp here? IIUC min_hard_comp is a set
a threshold between the strategies of trim/fill or stretch/squeeze to align the
audio to time; however, the async documentation says "Setting this to 1 will
enable filling and trimming, larger values represent the maximum amount in
samples that the data may be stretched or squeezed” so I thought that async=1
would not permit stretch/squeeze anyway.
> Regards,
> Marton
>
>
>>
>>> Signed-off-by: Marton Balint
>>> ---
>>> libavformat/dv.c | 16 ++--
>>> tests/ref/seek/lavf-dv | 18 +-
>>> 2 files changed, 11 insertions(+), 23 deletions(-)
>>> diff --git a/libavformat/dv.c b/libavformat/dv.c
>>> index 3e0d12c0e3..26a78139f5 100644
>>> --- a/libavformat/dv.c
>>> +++ b/libavformat/dv.c
>>> @@ -49,7 +49,6 @@ struct DVDemuxContext {
>>>uint8_t audio_buf[4][8192];
>>>int ach;
>>>int frames;
>>> -uint64_t abytes;
>>> };
>>> static inline uint16_t dv_audio_12to16(uint16_t sample)
>>> @@ -258,7 +257,7 @@ static int dv_extract_audio_info(DVDemuxContext *c,
>>> const uint8_t *frame)
>>>c->ast[i] = avformat_new_stream(c->fctx, NULL);
>>>if (!c->ast[i])
>>>break;
>>> -avpriv_set_pts_info(c->ast[i], 64, 1, 3);
>>> +avpriv_set_pts_info(c->ast[i], 64, c->sys->time_base.num,
>>> c->sys->time_base.den);
>>>c->ast[i]->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>>>c->ast[i]->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
>>> @@ -387,8 +386,7 @@ int avpriv_dv_produce_packet(DVDemuxContext *c,
>>> AVPacket *pkt,
>>>for (i = 0; i < c->ach; i++) {
>>>c->audio_pkt[i].pos = pos;
>>>c->audio_pkt[i].size = size;
>>> -c->audio_pkt[i].pts = c->abytes * 3 * 8 /
>>> - c->ast[i]->codecpar->bit_rate;
>>> +c->audio_pkt[i].pts = (c->sys->height == 720) ? (c->frames & ~1)
>>> : c->frames;
>>>ppcm[i] = c->audio_buf[i];
>>>}
>>>if (c->ach)
>>> @@ -401,10 +399,7 @@ int avpriv_dv_produce_packet(DVDemuxContext *c,
>>> AVPacket *pkt,
>>>c->audio_pkt[2].size = c->audio_pkt[3].size = 0;
>>>} else {
>>>c->audio_pkt[0].size = c->audio_pkt[1].size = 0;
>>> -c->abytes += size;
>>>}
>>> -} else {
>>> -c->abytes += size;
>>>}
>>>
>>>/* Now it's time to
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> 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:56 PM, Marton Balint wrote:
>>>>> Fixes out of sync timestamps in ticket #8762.
>>>> Although Michael’s recent patch does address the issue documented in 8762,
>>>> I haven’t found this patch to fix the issue. I tried with -c:a copy and
>>>> with -c:a pcm_s16le with some sample files that exhibit this issue but
>>>> each output was out of sync. I put an output at
>>>> https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795. That
>>>> output notes that 3597 packages of video are read and 3586 packets of
>>>> audio. In the resulting file, at the end of the timeline the audio is 9
>>>> frames out of sync and my output video stream is 00:02:00.020 and output
>>>> audio stream is 00:01:59.653.
>>>> Beyond copying or encoding the audio, are there other options I should use
>>>> to test this?
>>> Well, it depends on what you want. After this patch you should get a file
>>> which has audio packets synced to video, but the audio stream is sparse,
>>> not every video packet has a corresponding audio packet. (It looks like our
>>> MOV muxer does not support muxing of sparse audio therefore does not
>>> produce proper timestamps. But MKV does, please try that.)
>>> You can also make ffmpeg generate the missing audio based on packet
>>> timestamps. Swresample has an async=1 option, so something like this should
>>> get you synced audio with continous audio packets:
>>> ffmpeg -y -i 167052_12.dv -c:v copy \
>>> -af aresample=async=1:min_hard_comp=0.01 -c:a pcm_s16le 167052_12.mov
>>
>> Thank you for this. With the patch and async, the result is synced and the
>> resulting audio was the same as Michael’s patch.
>>
>> Could you explain why you used min_hard_comp here? IIUC min_hard_comp is a
>> set a threshold between the strategies of trim/fill or stretch/squeeze to
>> align the audio to time; however, the async documentation says "Setting this
>> to 1 will enable filling and trimming, larger values represent the maximum
>> amount in samples that the data may be stretched or squeezed” so I thought
>> that async=1 would not permit stretch/squeeze anyway.
>
> It is documented poorly, but if you check the source code you will see that
> async=1 implicitly sets min_comp to 0.001 enabling trimming/dropping.
> min_hard_comp decides the threshold when silence injection actually happens,
> and the default for that is 0.1, which is more than a frame, therefore not
> acceptable if we want to maintain <1 frame accuracy. Or at least that is how
> I think it should work.
Thanks for the explanation.
I’ve tested this patch with larger sample sets and really appreciate that the
audio timestamps are now properly ordered. For instance with
https://archive.org/download/dvr-007/DVR_007.dv, before the patch the
timestamps for audio around 20 - 30 seconds get severely jumbled which makes it
difficult to use astats metadata. While the documentation could be better, as
I’ve seen many forums entries of ffmpeg users struggling to keep dv from tape
transfers in sync, I don’t think that’s blocking. I’d really like to see this
merged.
Although this patch resolves the issue, I think Michael’s patch is interesting
too as it would allow access to the audio dif blocks of dv frames with no audio
source pack metadata. I’d have to test more to find an instance where the
'dvaudio_concealment pass’ option of Michael’s patch provides a different
result than the added silence from async.
Thanks so much.
Dave
> Regards,
> Marton
>
>>>>> Signed-off-by: Marton Balint
>>>>> ---
>>>>> libavformat/dv.c | 16 ++--
>>>>> tests/ref/seek/lavf-dv | 18 +-
>>>>> 2 files changed, 11 insertions(+), 23 deletions(-)
>>>>> diff --git a/libavformat/dv.c b/libavformat/dv.c
>>>>> index 3e0d12c0e3..26a78139f5 100644
>>>>> --- a/libavformat/dv.c
>>>>> +++ b/libavformat/dv.c
>>>>> @@ -49,7 +49,6 @@ struct DVDemuxContext {
>>>>> uint8_t audio_buf[4][8192];
>>>>> int ach;
>>>>> int frames;
>>>>> -uint64_t abytes;
>>>>> };
>>>>> static inline uint16_t dv_audio_12to16(uint
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> On Nov 1, 2020, at 3:58 PM, Marton Balint wrote:
>
>
>
> On Sun, 1 Nov 2020, Michael Niedermayer wrote:
>
>> On Sat, Oct 31, 2020 at 05:56:24PM +0100, Marton Balint wrote:
>>> Fixes out of sync timestamps in ticket #8762.
>>>
>>> Signed-off-by: Marton Balint
>>> ---
>>> libavformat/dv.c | 16 ++--
>>> tests/ref/seek/lavf-dv | 18 +-
>>> 2 files changed, 11 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/libavformat/dv.c b/libavformat/dv.c
>>> index 3e0d12c0e3..26a78139f5 100644
>>> --- a/libavformat/dv.c
>>> +++ b/libavformat/dv.c
>>> @@ -49,7 +49,6 @@ struct DVDemuxContext {
>>> uint8_t audio_buf[4][8192];
>>> int ach;
>>> int frames;
>>> -uint64_t abytes;
>>> };
>>>
>>> static inline uint16_t dv_audio_12to16(uint16_t sample)
>>> @@ -258,7 +257,7 @@ static int dv_extract_audio_info(DVDemuxContext *c,
>>> const uint8_t *frame)
>>> c->ast[i] = avformat_new_stream(c->fctx, NULL);
>>> if (!c->ast[i])
>>> break;
>>> -avpriv_set_pts_info(c->ast[i], 64, 1, 3);
>>> +avpriv_set_pts_info(c->ast[i], 64, c->sys->time_base.num,
>>> c->sys->time_base.den);
>>> c->ast[i]->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>>> c->ast[i]->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
>>>
>>> @@ -387,8 +386,7 @@ int avpriv_dv_produce_packet(DVDemuxContext *c,
>>> AVPacket *pkt,
>>> for (i = 0; i < c->ach; i++) {
>>> c->audio_pkt[i].pos = pos;
>>> c->audio_pkt[i].size = size;
>>> -c->audio_pkt[i].pts = c->abytes * 3 * 8 /
>>> - c->ast[i]->codecpar->bit_rate;
>>> +c->audio_pkt[i].pts = (c->sys->height == 720) ? (c->frames & ~1)
>>> : c->frames;
>>> ppcm[i] = c->audio_buf[i];
>>> }
>>> if (c->ach)
>>> @@ -401,10 +399,7 @@ int avpriv_dv_produce_packet(DVDemuxContext *c,
>>> AVPacket *pkt,
>>> c->audio_pkt[2].size = c->audio_pkt[3].size = 0;
>>> } else {
>>> c->audio_pkt[0].size = c->audio_pkt[1].size = 0;
>>> -c->abytes += size;
>>> }
>>> -} else {
>>> -c->abytes += size;
>>> }
>>>
>>> /* Now it's time to return video packet */
>>
>> Please correct me if iam 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 worth of audio samples between them.
>
> This is true, by using the frame counter (and the video time base) for audio,
> we lose some audio packet timestamp precision inherently. However I don't
> consider this a problem, audio timestamps do not have to be sample accurate,
> for most formats they are not. Also it is not practical to keep track of how
> many samples are there in the packets, for example when you do seeking,
> obviously you can't read all the audio data before the seek point to get a
> precise sample accurate timestamp.
Good point.
> What matters is that based on what I understand about the DV format (but
> maybe Dave can confirm or deny this) the divergence between the audio
> timestamp and the video timestamp in a DV frame must be less than 1/3 frame
> duration even for unlocked mode:
>
> http://www.adamwilt.com/DV-FAQ-tech.html#LockedAudio
The divergence could be a little larger than 1/3 frame in unlocked mode.
IEC61384-2 defines the allowable range of minimum to maximum samples per frame
and the maximum allowable divergence of accumulated samples per frame.
Mode | Min-Max | Allowance of accumulated difference
NTSC 48000 | 1580-1620 | 20
NTSC 44100 | 1452-1489 | 19
NTSC 32000 | 1053-1080 | 14
PAL 48000 | 1896-1944 | 24
PAL 44100 | 1742-1786 | 22
PAL 32000 | 1264-1296 | 16
The divergence between the audio timestamp and video timestamp is conditional
on the mode, so that would be
Mode | Max divergence as percentage of frame duration
NTSC 48000 | 0.3742511235
NTSC 44100 | 0.3869807536
NTSC 32000 | 0.3929636797
PAL 48000 | 0.3125
PAL 44100 | 0.3117913832
PAL 3200
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> On Nov 6, 2020, at 4:03 PM, Michael Niedermayer > wrote: > > On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote: >> >> On Wed, 4 Nov 2020, Michael Niedermayer wrote: >> >>> we have "millisecond" based formats, rounded timestamps >>> we have "exact" cases, maybe the timebase being 1 packet/frame per tick >>> we have "high precission" where the timebase is so precisse it doesnt matter >>> >>> This here though is a bit an oddball, the size if 1 PCM frame is 1 sample >>> The timebase is not a millisecond based one, its not 1 frame either nor is >>> it exact nor high precission. >>> Its 1 video frame, and whatever 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 frame. >> >> The difference between the audio timestamp and the video timestamp for >> packets from the same DV frame is at most 0.3929636797*frame_duration as the >> specification says, as Dave quoted, so I don't see how the error can be >> bigger than this. >> >> It looks to me you are mixing timestamps coming from a demuxer, and >> timestamps you calculate by counting the number of demuxed/decoded audio >> samples or video frames. Synchronization is done using the former. >> > >>> >>> But if for example some hardware was using internally a 16 sample buffer >>> and only put multiplies of 16 samples in frames this would introduce a >>> considerable amount of jitter in the timestamps in relation to the actual >>> duration. And using async to fix this without introducing more problems >>> might require some care. >> >> I still don't see why timestamp or duration jitter is a problem > >> as long as >> the error is below frame_duration/2. You can safely use async with >> min_hard_comp set to frame_duration/2. > > Thats exactly what i meant. an async like filter which behaves differently > or async with a different value there can mess this up. > IMHO such mess up is ok when the input is corrupted or invalid. OTOH > here it is valid and correct data. > >> In general, don't you find it problematic that the dv demuxer can return >> different timestamps if you read packets sequentially and if you seek to the >> end of a file? It looks like a huge bug > > yes, this is not great > but even with your patch you still have this effect > when seeking to some point in time a player has to output video and > audio to the user at an exact time and that will differ even with async > from linear playbacks presentation When trying to workaround the loss of audio sync, I use -skip_initial_bytes on the dv input to jump to the frame after a missing audio pack to read from that point to keep audio and video in sync from that offset in the bytestream (at least until the next missing audio source pack). >> which is not fixable if you insist >> on sample counting... > > I think you misunderstood me, or maybe i didnt state my opinion well, > iam not saying that i consider what dv in git does good. Rather that there > is a problem beyond what these patches fix. > Some concept of timestamp accuracy independant of the distance of > representable > values would be usefull. > if you take teh 1/25 or whatever they are based on dv timestamps and convert > that > to teh mpeg 90khz based ones thats not making it that accurate. > OTOH if you take 1/25 based audio where each packet is 1/25sec worth of > samples > that very well might be sample accurate or even beyond. > knowing this accuracy is usefull for configuring a async like filter or also > in > knowing how to deal with inconsistencies, is that timestamp jtter ? or the > sample > rate jittering / some droped samples ? > Its important to know as in one instance its the timestamps that need > adjustment > while in the other the samples need adjustment > ATM its down to the user to figure out on a file by file base how to deal or > ignore this. Instead it should be possible for an automated system to > compensate such issues ... As mentioned elsewhere, some automation (or at least a logged hint) would be helpful to add or suggest aresample=async=1 to fill the gaps when using containers that don’t support sparse audio. With Marton’s patch, the user has the opportunity to use that filter to keep the audio in sync. […] Dave Rice ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
> On Nov 14, 2020, at 7:14 PM, Marton Balint wrote: > > On Fri, 6 Nov 2020, Michael Niedermayer wrote: > >> On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote: >>> >>> >>> On Wed, 4 Nov 2020, Michael Niedermayer wrote: >>> we have "millisecond" based formats, rounded timestamps we have "exact" cases, maybe the timebase being 1 packet/frame per tick we have "high precission" where the timebase is so precisse it doesnt matter This here though is a bit an oddball, the size if 1 PCM frame is 1 sample The timebase is not a millisecond based one, its not 1 frame either nor is it exact nor high precission. Its 1 video frame, and whatever 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 frame. >>> >>> The difference between the audio timestamp and the video timestamp for >>> packets from the same DV frame is at most 0.3929636797*frame_duration as the >>> specification says, as Dave quoted, so I don't see how the error can be >>> bigger than this. >>> >>> It looks to me you are mixing timestamps coming from a demuxer, and >>> timestamps you calculate by counting the number of demuxed/decoded audio >>> samples or video frames. Synchronization is done using the former. >>> >> But if for example some hardware was using internally a 16 sample buffer and only put multiplies of 16 samples in frames this would introduce a considerable amount of jitter in the timestamps in relation to the actual duration. And using async to fix this without introducing more problems might require some care. >>> >>> I still don't see why timestamp or duration jitter is a problem >> >>> as long as >>> the error is below frame_duration/2. You can safely use async with >>> min_hard_comp set to frame_duration/2. >> >> Thats exactly what i meant. an async like filter which behaves differently >> or async with a different value there can mess this up. >> IMHO such mess up is ok when the input is corrupted or invalid. OTOH >> here it is valid and correct data. >> >> >>> >>> In general, don't you find it problematic that the dv demuxer can return >>> different timestamps if you read packets sequentially and if you seek to the >>> end of a file? It looks like a huge bug >> >> yes, this is not great >> but even with your patch you still have this effect >> when seeking to some point in time a player has to output video and >> audio to the user at an exact time and that will differ even with async >> from linear playbacks presentation >> >> >>> which is not fixable if you insist >>> on sample counting... >> >> I think you misunderstood me, or maybe i didnt state my opinion well, >> iam not saying that i consider what dv in git does good. Rather that there >> is a problem beyond what these patches fix. >> Some concept of timestamp accuracy independant of the distance of >> representable >> values would be usefull. >> if you take teh 1/25 or whatever they are based on dv timestamps and convert >> that >> to teh mpeg 90khz based ones thats not making it that accurate. >> OTOH if you take 1/25 based audio where each packet is 1/25sec worth of >> samples >> that very well might be sample accurate or even beyond. >> knowing this accuracy is usefull for configuring a async like filter or also >> in >> knowing how to deal with inconsistencies, is that timestamp jtter ? or the >> sample >> rate jittering / some droped samples ? >> Its important to know as in one instance its the timestamps that need >> adjustment >> while in the other the samples need adjustment >> ATM its down to the user to figure out on a file by file base how to deal or >> ignore this. Instead it should be possible for an automated system to >> compensate such issues ... > > OK, but the automated solution is far from trivial, e.g. it should start with > a analysis of the file to check if the sample rate is accurate or not... And > if it is not, is the difference constant througout the file? Then there are > several methods to fix it and the user might have a preference. E.g consider > audio clock "master" and duplicate/drop video frames. Or keep all video > frames, but stretch audio (with or without pitch correction - and which > filter you want for pitch correction? atempo? rubberband?). So making it > automated is not trivial at all. > > Anyhow, is it OK to apply this patch then? Nudging on this, as this patch has been very helpful to avoid tedious workarounds. I’d love to see it merged. If any further test results would be useful, let me know. 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 wit
[FFmpeg-devel] [PATCH] doc/ffprobe.xsd: remove extra sequence from streamType
I found that ffprobe.xsd could no longer validate records, this patch makes the xsd valid once again. Best Regards, Dave Rice >From f55d5dfd3a4980f6f86efee76d18453c7b534b2a Mon Sep 17 00:00:00 2001 From: Dave Rice Date: Tue, 12 May 2015 16:44:52 -0400 Subject: [PATCH] remove extra sequence from streamType This makes the XSD valid again. Fixes a regression from a72b61a. --- doc/ffprobe.xsd | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd index d473c9b..dab55ee 100644 --- a/doc/ffprobe.xsd +++ b/doc/ffprobe.xsd @@ -170,9 +170,6 @@ - - - -- 2.3.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/ffprobe.xsd: add build_date and build_time as optional attributes
This patch puts back two attributes that were removed in 7b35a01. If I understand correctly the intent of patch 7b35a01 was to no longer use build_date and build_time as attributes of programVersion, but the patch also had the effect of making all records generated with an earlier ffprobe build with build_date and build_time as invalid. This patch puts the two attributes back but without mandating their use, thus older ffprobe records as backwards compatible with the current schema and their use is no longer required. Best Regards, Dave Rice >From 7321e45ff04e5b97908c6525c929bb24363ed135 Mon Sep 17 00:00:00 2001 From: Dave Rice Date: Tue, 12 May 2015 16:52:55 -0400 Subject: [PATCH] doc/ffprobe.xsd: add build_date and build_time as optional attributes This partly undoes 7b35a01. --- doc/ffprobe.xsd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd index d473c9b..ab65bd4 100644 --- a/doc/ffprobe.xsd +++ b/doc/ffprobe.xsd @@ -275,6 +275,8 @@ + + -- 2.3.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffprobe: add stream_index to frame data
This patch adds the stream_index to frame data so that a frame may be associated back to the parent stream, otherwise it is difficult to associate them clearly. Dave Rice 0001-ffprobe-print-stream_index-with-frame-data.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: add stream_index to frame data
> On May 14, 2015, at 3:53 AM, Stefano Sabatini wrote:
>
> [...]
>> From c655acffb8d9acc97e19553c2e464c0d78586063 Mon Sep 17 00:00:00 2001
>> From: Dave Rice
>> Date: Wed, 13 May 2015 13:38:29 -0400
>> Subject: [PATCH] ffprobe: print stream_index with frame data
>>
>> otherwise the frame data can't be associated back to its stream. This
>> makes it easier to work with data from multi-track outputs such as:
>> ffprobe -f lavfi
>> movie=1video_3audio.mov:s=v+a+a+a[out0][out1][out2][out3] -show_streams
>> -show_frames
>> ---
>> doc/ffprobe.xsd | 1 +
>> ffprobe.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
>> index d473c9b..5e0f9a9 100644
>> --- a/doc/ffprobe.xsd
>> +++ b/doc/ffprobe.xsd
>> @@ -86,6 +86,7 @@
>> > type="ffprobe:frameSideDataListType" minOccurs="0" maxOccurs="1" />
>>
>>
>> +
>>
>>
>>
>> diff --git a/ffprobe.c b/ffprobe.c
>> index fadcd93..8ee97f5 100644
>> --- a/ffprobe.c
>> +++ b/ffprobe.c
>> @@ -1822,6 +1822,7 @@ static void show_frame(WriterContext *w, AVFrame
>> *frame, AVStream *stream,
>> writer_print_section_header(w, SECTION_ID_FRAME);
>>
>> s = av_get_media_type_string(stream->codec->codec_type);
>> +print_int ("stream_index", stream->index);
>> if (s) print_str("media_type", s);
>> else print_str_opt("media_type", "unknown");
>
> Nit: maybe you should print this after the media_type, as in the case
> of packet.
Fixed.
> Note: you also need to update the fate ffprobe references, see the
> script in attachment (which I should probably commit).
Fixed. New patch is attached.
Dave Rice
0001-print-stream_index-with-frame-data.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC][WIP] Conversion of FFV1 specification to Markdown
Hi all, As there is ongoing work on the FFV1 specification in support of a standardization process via the IETF, Ashley Blewer and I (as part of the PreForma project [1]) have drafted a translation of the current FFV1 specification which is formatted in lyx [2] to markdown. Such a transition was discussed on the listserv before [3] (and recently offlist with Michael Niedermayer) in order in order to make contributions and participation with the development of the specification more accessible. The conversion to markdown is not yet complete but we would appreciate feedback, advice, or contributions to the translation. I propose that the intent of the conversion focus on changing from a lyx basis to a markdown one (with exact semantic meaning) and that discussion on semantic changes to the specification be in a separate or following discussion. We've found that the challenges of converting from lyx to markdown include management of internal-linking, handling header-less tables, and the inclusion of math, but have draft solutions to these issues in place in the current markdown draft. Since a patch would simply be the replacement of nearly every line from the lyx to markdown conversion, I'm attaching the markdown itself for review. This file comes from from a branch of MediaArea's fork of the FFV1 specification, which can be found here: https://github.com/MediaArea/FFV1/tree/markdown <https://github.com/MediaArea/FFV1/tree/markdown>. HTML [4] and PDF renderings of the markdown may be reviewed here: https://github.com/MediaArea/FFV1/tree/markdown/derivatives <https://github.com/MediaArea/FFV1/tree/markdown/derivatives>. Please note that while the HTML [4] presents the math properly in Safari and Firefox, in present form the HTML version is not presenting correctly in Chrome (lack of MathML support). The conversion process from markdown to html and pdf is specified here: https://github.com/MediaArea/FFV1/blob/markdown/derivatives/create_derivatives.sh <https://github.com/MediaArea/FFV1/blob/markdown/derivatives/create_derivatives.sh>. Best Regards, Dave Rice [1] http://preforma-project.eu/ <http://preforma-project.eu/> [2] https://github.com/FFmpeg/FFV1/blob/master/ffv1.lyx <https://github.com/FFmpeg/FFV1/blob/master/ffv1.lyx> [3] https://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/133125.html <https://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/133125.html> [4] https://htmlpreview.github.io/?https://github.com/MediaArea/FFV1/blob/markdown/derivatives/ffv1.html <https://htmlpreview.github.io/?https://github.com/MediaArea/FFV1/blob/markdown/derivatives/ffv1.html> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add drawgraph filter
Hi, > On Jun 26, 2015, at 11:27 AM, Paul B Mahol wrote: > > Signed-off-by: Paul B Mahol > --- > Waiting for comments and flames. Here are some comments and flames: I noticed that when I set min to a value greater than max. I get a crash with "Bus error: 10". There may be an issue with negative values for min/max. When I run: ffplay -f lavfi -i color=gray -vf signalstats,drawgraph=lavfi.signalstats.YAVG:min=0:max=255 I see a line scroll across the center of the window. When I change min to -255 I see a line at ~3/4 down the frame, where I would expect -128 to be. Does the min and max expect non-negative numbers. It could be helpful to include equations within foreground, such as: ffplay -i movie.mkv -vf "signalstats,drawgraph=lavfi.signalstats.YAVG:min=0:max=255:foreground=if(gt(lavfi.signalstats.YAVG\,128)\,green\,red)" or actually I could probably subsequently use geq to accomplish that. Can you alias 's' for 'size' as many of the other filters do. This is very helpful, thanks! Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
