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" },
/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> #define LIBAVFORMAT_VERSION_MINOR 18
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>
> #define LIBAVFORMAT_VE
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
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
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
> 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
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
Hi,
> On Oct 31, 2020, at 5:15 PM, Marton Balint <mailto:c...@passwd.hu>> wrote:
> On Sat, 31 Oct 2020, Dave Rice wrote:
>>> On Oct 31, 2020, at 3:47 PM, Marton Balint >> <mailto:c...@passwd.hu>> wrote:
>>> On Sat, 31 Oct 2020, Dave Rice wrote:
&g
> On Feb 23, 2021, at 2:42 PM, Marton Balint wrote:
>
>
>
> On Sat, 20 Feb 2021, Dave Rice wrote:
>
>> Hi,
>>
>>> On Oct 31, 2020, at 5:15 PM, Marton Balint >> <mailto:c...@passwd.hu>> wrote:
>>> On Sat, 31 Oct 2020, Da
Hi Andreas,
> On Jun 27, 2020, at 5:09 PM, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> Remove the check on dv_demux since dv_fctx will leak if allocate
>> dv_demux failed.
>> ---
>> libavformat/mov.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavform
> On Dec 27, 2019, at 10:49 AM, Paul B Mahol wrote:
>
> That is because signalstats is doing more stuff.
signalstats includes options to disable some of the calculations, possibly this
could be extended to enable or disable the ones you want. It would be
interesting to merge these ideas rathe
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
> 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, Ja
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
> 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
_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];
> +
> 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 ver
> 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
> 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
>>&
162/_index.html>.
From 47def189b270ac93245e002580463b254daf8484 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410
Per
https://developer.apple.com/library/content/technotes/tn2162/_inde
> On Nov 16, 2017, at 11:30 AM, Dave Rice wrote:
>
>> On Jul 9, 2017, at 7:26 PM, Dave Rice wrote:
>>
>>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis
>>> wrote:
>>>
>>> On 7/7/2017 10:13 PM, James Almer wrote:
>>>> I
> 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 (
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
26d9ca470f104d8448000b13c2cc97b8fc5c15ba Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH 1/4] avformat/movenc: correct ImageDescription for
uncompressed ycbcr
Per
https://developer.apple.com/library/content/technotes/tn2162/_index.html
.
---
libavformat/movenc.c | 20
From 41da5e48f8788b85dd7a382030bb2866c506cc03 Mon Sep 17 00:00:00 2001
From: Dave Rice
Date: Sat, 18 Nov 2017 20:31:27 -0500
Subject: [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in
mov
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From 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
8:overlap=7:queue=1' filmstrip.mkv
@end example
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> On Nov 20, 2017, at 9:01 AM, Carl Eugen Hoyos wrote:
>
> 2017-11-20 2:24 GMT+01:00 James Almer <mailto:jamr...@gmail.com>>:
>> On 11/18/2017 11:19 PM, Dave Rice wrote:
>>> From 41da5e48f8788b85dd7a382030bb2866c506cc03 Mon Sep 17 00:00:00 2001
>>> F
> On Nov 20, 2017, at 9:55 AM, Derek Buitenhuis
> wrote:
>
> On 11/20/2017 2:50 PM, Dave Rice wrote:
>> I am hesitant to see write_colr option removed since the guesswork used here
>> https://github.com/FFmpeg/FFmpeg/blob/8f4702a93f87f9f76563e80f1ae2141a40029d9d/li
> On Nov 20, 2017, at 11:22 AM, Derek Buitenhuis
> wrote:
>
> On 11/20/2017 3:19 PM, Dave Rice wrote:
>> TN2162 requires a colr atom for uncompressed yuv (including v210, v308,
>> v408, etc) in mov, so I'd prefer to write it in this case. Note that the
>&g
; 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
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
Subje
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 ab
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 cons
> 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; how
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
___
> 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..
>
>
> 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
tps://twitter.com/ajaprez/status/910100436224499713>. I’m glad to hear that
handling other VANC data is in the works, I’m particularly interested in VITC
and EIA-608 with inputs.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
t; 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
t;
> 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
> 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? Pr
> 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
tom"
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
: 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
lid 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
8
- 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 welc
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
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
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
rks 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
> 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
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
//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
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 f
appened 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 t
aenc.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 l
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-b
...@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/ce
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
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?
D
> 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 shoul
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.
>>
&
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
___
f
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
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
t 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 beginnin
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
her 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/mo
> 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”;
>>
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
> 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 23d80d0d4
mit.
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
id/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
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/
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 l
tware.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
-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.x
cklink 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:
>>>>
_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.
Tha
tion 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 extend
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
_
> 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:
>>>>
> On Mar 27, 2018, at 5:16 PM, wm4 wrote:
>
> On Tue, 27 Mar 2018 16:45:23 -0400
> Dave Rice mailto:d...@dericed.com>> wrote:
>
>>> On Mar 27, 2018, at 4:33 PM, wm4 wrote:
>>>
>>> On Tue, 27 Mar 2018 16:11:11 -0400
>>> Dave R
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
gt; SIGPIPE.
This patch has been working for me and ffmpeg terminates cleanly with SIGPIPE
with a valid output (moov atom written with mov or cues/seekhead written with
mkv). Not sure if I understand well the disadvantage of this patch.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
> 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
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
> 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’
> On Oct 31, 2020, at 5:15 PM, Marton Balint wrote:
> On Sat, 31 Oct 2020, Dave Rice wrote:
>>> On Oct 31, 2020, at 3:47 PM, Marton Balint wrote:
>>> On Sat, 31 Oct 2020, Dave Rice wrote:
>>>> Hi Marton,
>>>>> On Oct 31, 2020, at 12:5
de | 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 32000 | 0.3125
0.3929636797 is the max divergence, at least according to the spec’s limit of
the allowable
e
> 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 i
> 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 timestam
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 seque
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
>F
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
> 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 dat
ivatives/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-Octob
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 negat
1 - 100 of 156 matches
Mail list logo
