> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Thursday, 15 July 2021 07:43
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> d3d11va support, added mfxhdlpair
>
> On Thu, 2021-07-15 at 03:49 +, Sof
On Thu, 2021-07-15 at 03:49 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > James Almer
> > Sent: Thursday, 15 July 2021 05:21
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> > d3d11va support
---
libavcodec/videotoolboxenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 4eaabed5d8..61eb6e1921 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -990,6 +990,10 @@ static int get_cv_tran
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Thursday, 15 July 2021 05:21
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> d3d11va support, added mfxhdlpair
>
> On 7/15/2021 12:10 AM, Soft Works wrote:
On 7/15/2021 12:10 AM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Xiang, Haihao
Sent: Thursday, 15 July 2021 04:35
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
d3d11va support, added mfxhdlpair
On Tue, 2021-
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Thursday, 15 July 2021 04:35
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> d3d11va support, added mfxhdlpair
>
> On Tue, 2021-07-13 at 11:53 -0300, Jam
On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote:
> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote:
> > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote:
> >
> > > Adding DX11 relevant device type checks and adjusting callbacks with
> > > proper MediaSDK pair type support.
> > >
> > > Extendi
Fixes http://trac.ffmpeg.org/ticket/9219
---
libavformat/isom_tags.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index 1666b9d4a5..e2e589b658 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -312,6 +312,8 @@ const AVC
This adds the Reddit subreddit to the forum section. It has over 7000
participants. Many of the developers on here, like Gyan and Paul,
participate on there already. I also think Gyan is the moderator of that
subreddit as well. And reddit is more popular than superuser.
---
src/contact | 3 +++
On 2021-07-14 14:51, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
htdocs/robots.txt | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index eb05362..4bbc395 100644
--- a/htdocs/robots.txt
+++ b/htdocs/rob
On 2021-07-14 14:55, Nicolas George wrote:
ffmpegandmahanstreamer@lolcow.email (12021-07-14):
I'm not against fixing the mailing list. No, not at all. It need to be
fixed. But Google is big company and trying to figure out how to make
their
mail deliver successfully might be a problem.
I thin
On 15.07.2021 00:02, James Almer wrote:
On 7/14/2021 6:54 PM, Timo Rothenpieler wrote:
On 14.07.2021 23:28, James Almer wrote:
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125
On 7/14/2021 6:54 PM, Timo Rothenpieler wrote:
On 14.07.2021 23:28, James Almer wrote:
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
++
On 14.07.2021 23:28, James Almer wrote:
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
+++ b/configure
@@ -6194,7 +6194,7 @@ check_func_h
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
+++ b/configure
@@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep
check_func_heade
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
+++ b/configure
@@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep
check_func_headers windows.h VirtualAlloc
check_func_headers glob.h
On Mon, Jul 12, 2021 at 11:14:14PM +0200, Michael Niedermayer wrote:
> Thanks to Jan Ekström for details
> ---
> src/security | 1 +
> 1 file changed, 1 insertion(+)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but
On Wed, Jul 14, 2021 at 04:00:53PM -0400, ffmpegandmahanstreamer@lolcow.email
wrote:
> On 2021-07-14 14:51, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > htdocs/robots.txt | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git
On Wed, Jul 14, 2021 at 08:13:24PM +0100, Derek Buitenhuis wrote:
> On 7/14/2021 7:59 PM, Michael Niedermayer wrote:
> > Some spiders where attracted by gitwebs and got entangled in it
> > eventually the OOM killer freed them but in the blaze of holy
> > linux kernel OOM fire grossd and named also
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, 14 July 2021 21:05
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Mailing List Delay
>
> Derek Buitenhuis (12021-07-14):
> > Yeah, I know, but i
On 7/14/2021 8:05 PM, Nicolas George wrote:
> If it happens to you again, you can ask for the logs immediately, it will
> be more likely the admins can find what went wrong.
Who is admin here who I would ask? Michael?
- Derek
___
ffmpeg-devel mailing li
On 7/14/2021 7:59 PM, Michael Niedermayer wrote:
> Some spiders where attracted by gitwebs and got entangled in it
> eventually the OOM killer freed them but in the blaze of holy
> linux kernel OOM fire grossd and named also where burnt
Are services not restarted automatically if they're killed?
It's a write only field.
Signed-off-by: James Almer
---
libavformat/internal.h | 2 --
libavformat/utils.c| 6 --
2 files changed, 8 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 240de9e289..4b7ab082e7 100644
--- a/libavformat/internal.h
+++ b/libavform
Derek Buitenhuis (12021-07-14):
> Yeah, I know, but it seemed to be a good time to bring this up yet again.
> Sorry if that was unclear.
No problem. It is an important discussion, and now we are on the same
page.
> Looking at a set of 3 patches I sent with git-send-email that had this issues,
> t
On Wed, Jul 14, 2021 at 08:51:21PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> htdocs/robots.txt | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/htdocs/robots.txt b/htdocs/robots.txt
> index eb05362..4bbc395 100644
> --- a
On Wed, Jul 14, 2021 at 04:47:49PM +0530, Gyan Doshi wrote:
> Is there an issue with the mailing list over the past couple of days?
> I've just received multiple messages over 12 hours old.
Some spiders where attracted by gitwebs and got entangled in it
eventually the OOM killer freed them but in
Signed-off-by: Michael Niedermayer
---
htdocs/robots.txt | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index eb05362..4bbc395 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -1,2 +1,13 @@
User-agent: *
-Disallow:
ffmpegandmahanstreamer@lolcow.email (12021-07-14):
> I'm not against fixing the mailing list. No, not at all. It need to be
> fixed. But Google is big company and trying to figure out how to make their
> mail deliver successfully might be a problem.
>
> I think this was the reasoning behind alot o
On 2021-07-14 09:43, Derek Buitenhuis wrote:
On 7/14/2021 2:35 PM, ffmpegandmahanstreamer@lolcow.email wrote:
I have been bringing this up consstently for years, and been told
it's
a "non-issue", but it is incredibly annoying.
I am not sure if it's due to Google having issues (trust?) sending
On 2021-07-14 09:17, Derek Buitenhuis wrote:
On 7/14/2021 12:27 PM, Nicolas George wrote:
Looking at the headers, it looks like the delay happens at Google
before
the mail arrives to the mailing-list.
Yours arrived quickly. Mine will too, I guess.
Sending from GMail, I have had anywhere from
On Tue, Jul 13, 2021 at 07:54:18PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-07-12 21:08:55)
> > On Mon, Jul 12, 2021 at 01:07:06PM +0200, Anton Khirnov wrote:
> > [...]
> > > diff --git a/libswscale/swscale.h b/libswscale/swscale.h
> > > index 50d6d46553..41eacd2dea 100644
>
On 2021-07-04 17:58, ffmpegandmahanstreamer@lolcow.email wrote:
These are some cosmetic changes and also priming the decoder for
sprite support (which i plan on adding). This patch was mainly for me
to get used to the git email patch flow, if anything. Of course the
decoder still works as it was
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> In streaming mode when using a segment list, the current segment should
> be listed so that clients can immediately request it even before
> complete. Without this, even though the segment is being written in a
> way th
xmllint (silently) replaces the ' with " when fixing and validating the output
of ffprobe in fate-ffprobe_xsd.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d452c212e..94c73f
Thanks! Yes I saw your comment on v2 and agree that patch can be closed/ignored.
On Jul 14, 2021, 10:47 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 7/14/21, 7:46 PM, "Kevin LaFlamme" wrote:
>
> > Any feedback on this?
> Thanks for the reminder. I have pushed this patch alone from this series.
>
Ah I didn’t realize the SegmentTemplate was actually required in the spec for
streaming mode. This should be closed then, thanks.
On Jul 14, 2021, 10:45 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 6/24/21, 6:28 PM, "Kevin LaFlamme" wrote:
>
> > In streaming mode when using a segment list, the c
On 7/14/21, 7:46 PM, "Kevin LaFlamme" wrote:
>Any feedback on this?
Thanks for the reminder. I have pushed this patch alone from this series.
I had some concerns on v2 of this series, to which I have replied separately.
Thanks and Regards,
Karthick
>On Jun 24, 2021, 8:58 AM -0400, Kevin LaFla
On 6/24/21, 6:28 PM, "Kevin LaFlamme" wrote:
>In streaming mode when using a segment list, the current segment should
>be listed so that clients can immediately request it even before
>complete. Without this, even though the segment is being written in a
>way that it can be requested while sti
Tag only packets containing with IDR pictures as keyframes by default, same as
the decoder.
Fixes MP4 and Matroska muxers marking incorrect samples as Sync Samples in
scenarios where this AVParser is used.
Signed-off-by: James Almer
---
libavcodec/h264_parser.c | 16 ++--
t
It will be used to allow parsers to be more liberal when tagging packets as
keyframes.
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 8b97895aeb..8e3d888266 100644
--- a/libavcodec/avcodec.
Use it to enable keyframe tagging heuristics to mark as many RAPs as possible.
Signed-off-by: James Almer
---
configure | 2 +-
libavformat/mpegtsenc.c | 45 +
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/configure b/confi
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> When streaming mode is enabled, the DASH manifest is written on the
> first packet for the segment so that the segment can be advertised
> immediately to clients. It was also still writing the manifest at the
> end of t
On 7/14/2021 2:41 PM, Derek Buitenhuis wrote:
> These were sent as a single chain all at once, via git-send-email, but the
> received tim are wildly different.
Apologies, ignore the third link - it was a 2 patch set. My mistake.
The first two are enough to demonstrate the issue though.
- Derek
On 7/14/2021 2:35 PM, ffmpegandmahanstreamer@lolcow.email wrote:
>> I have been bringing this up consstently for years, and been told it's
>> a "non-issue", but it is incredibly annoying.
>>
>> I am not sure if it's due to Google having issues (trust?) sending to
>> out host, or the host having tro
On 7/14/2021 2:24 PM, Nicolas George wrote:
> The issue we discussed here only happened since yesterday, and
> apparently stopped happening.
>
> So it's not the same issue.
Yeah, I know, but it seemed to be a good time to bring this up yet again.
Sorry if that was unclear.
>> I am not sure if it
On 7/14/2021 10:17 AM, Derek Buitenhuis wrote:
On 7/14/2021 12:27 PM, Nicolas George wrote:
Looking at the headers, it looks like the delay happens at Google before
the mail arrives to the mailing-list.
Yours arrived quickly. Mine will too, I guess.
Sending from GMail, I have had anywhere fro
Derek Buitenhuis (12021-07-14):
> Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay
> ever since moving to the "new" (Hungarian?) mailing list host. Especially
> when sending via git-send-email.
>
> I have been bringing this up consstently for years, and been told it's
> a
On 7/14/2021 1:32 PM, Martin Storsjö wrote:
> I guess we could - but I see that as a separate thing to do which could be
> applied everywhere where we export metadata.
Yeah, true... we should probably have it in som upper/middle layer that checks
all string-type exports or something.
Patch shoul
On 7/14/2021 12:27 PM, Nicolas George wrote:
> Looking at the headers, it looks like the delay happens at Google before
> the mail arrives to the mailing-list.
>
> Yours arrived quickly. Mine will too, I guess.
Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay
ever since
On 7/12/2021 9:24 AM, Brad Hards wrote:
> MISB ST 0604 and ST 2101 require user data unregistered SEI messages
> (precision timestamps and sensor identifiers) to be included. That
> currently isn't supported for libx265. This patch adds support
> for user data unregistered SEI messages in accordanc
On Tue, 13 Jul 2021, Derek Buitenhuis wrote:
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
+} else if (data_type > 1 && data_type != 4) {
+// data_type can be 0 if not set at all above. data_type 1 means
+// UTF8 and 4 means "UTF8 sort". For any other type (UTF16 o
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
> +} else if (data_type > 1 && data_type != 4) {
> +// data_type can be 0 if not set at all above. data_type 1 means
> +// UTF8 and 4 means "UTF8 sort". For any other type (UTF16 or
> e.g.
> +// a picture), don
On Tue, 13 Jul 2021, Derek Buitenhuis wrote:
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
---
libavformat/mov.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
OK.
Thanks
I would just push in the future after waiting so long.
Sure, although in particular f
On 7/12/2021 11:44 PM, Kieran Kunhya wrote:
On Tue, 13 Jul 2021, 02:45 James Almer, wrote:
On 7/12/2021 10:01 PM, Kieran Kunhya wrote:
Because it isn't something that should be marked as a keyframe as coded
bitstream in any kind of container, like it's the case of mp4 sync
samples.
MPEG
Gyan Doshi (12021-07-14):
> Is there an issue with the mailing list over the past couple of days?
> I've just received multiple messages over 12 hours old.
Looking at the headers, it looks like the delay happens at Google before
the mail arrives to the mailing-list.
Yours arrived quickly. Mine wi
On 11/14/2020 1:49 PM, Max Dmitrichenko wrote:
On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote:
Adding DX11 relevant device type checks and adjusting callbacks with
proper MediaSDK pair type support.
Extending structure for proper MediaSDK pair type support.
Signed-off-by: Artem Galin
Is there an issue with the mailing list over the past couple of days?
I've just received multiple messages over 12 hours old.
And there have been no new messages in ffmpeg-user since the 12th,
although that list is low traffic anyway.
Gyan
___
ffmpeg
On 7/13/2021 1:22 AM, James Almer wrote:
> Because it isn't something that should be marked as a keyframe as coded
> bitstream in any kind of container, like it's the case of mp4 sync samples.
It *is* something that should be specifically marked in MP4, though, which
does vhae proper facilities f
On 7/13/2021 9:28 AM, Anton Khirnov wrote:
> Seems we need a better definition of what "keyframe" means in our APIs.
Not one, but many. That there is a single notion of a "keyframe" is wrong
in itself.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@
---
v2: add doc
It's useful when tlpktdrop=0&maxbw=0 and network bandwidth is smaller
than input stream rate. Without this option, the estimated input rate
can drop to near zero.
https://github.com/Haivision/srt/issues/2057
doc/protocols.texi | 4
libavformat/libsrt.c | 16 ++
On 2021-07-14 00:35, James Almer wrote:
On 7/13/2021 6:12 AM, Gyan Doshi wrote:
On 2021-07-13 13:14, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-07-02 12:03:05)
Allows forcing decoders of different media type.
Needed to decode media data muxed as data streams.
---
doc/ffmpeg.texi
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
> ---
> libavformat/mov.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
OK.
I would just push in the future after waiting so long.
- Derek
___
ffmpeg-devel mailing list
ffm
On 08.04.2021 08:41, Tobias Rapp wrote:
On 07.04.2021 19:25, Paul B Mahol wrote:
Please ask someone else to apply it.
I can technically commit the patches but would prefer if some second
pair of eyes could take a look. So will apply them in a week from now if
nobody objects.
Applied this f
13 Jul 2021, 20:16 by an...@khirnov.net:
> Quoting Lynne (2021-07-09 04:42:07)
>
>>
>> I can change the patch to either initialize it as an invalid value (which
>> would
>> signal the user to instead get the timebase elsewhere) or set its value
>> when the packet passes through the common demuxin
On 7/13/2021 6:12 AM, Gyan Doshi wrote:
On 2021-07-13 13:14, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-07-02 12:03:05)
Allows forcing decoders of different media type.
Needed to decode media data muxed as data streams.
---
doc/ffmpeg.texi | 5 +
fftools/ffmpeg_opt.c | 7 ++
Quoting Thilo Borgmann (2021-06-28 15:12:11)
> Hi,
>
> > when transcoding 608 cc, the cc stream frame pts is set to the same value
> > as its container frame's pts. However, the time_base is always set to
> > 1/9 (default) in the initialization stage. Which causes timing issues
> > when the
On 2021-07-14 13:23, Zhao Zhili wrote:
---
libavformat/libsrt.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 8dee6aa3f3..5113858d97 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -72,6 +72,9 @@ typed
Quoting Lynne (2021-07-09 04:42:07)
>
> I can change the patch to either initialize it as an invalid value (which
> would
> signal the user to instead get the timebase elsewhere) or set its value
> when the packet passes through the common demuxing function.
> Having this field in does not imply
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
inde
Quoting Michael Niedermayer (2021-07-12 21:08:55)
> On Mon, Jul 12, 2021 at 01:07:06PM +0200, Anton Khirnov wrote:
> [...]
> > diff --git a/libswscale/swscale.h b/libswscale/swscale.h
> > index 50d6d46553..41eacd2dea 100644
> > --- a/libswscale/swscale.h
> > +++ b/libswscale/swscale.h
> > @@ -30,6
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
inde
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
inde
---
libavformat/libsrt.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 8dee6aa3f3..5113858d97 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -72,6 +72,9 @@ typedef struct SRTContext {
int ipttl;
in
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
inde
Quoting Gyan Doshi (2021-07-13 11:12:19)
>
>
> On 2021-07-13 13:14, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2021-07-02 12:03:05)
> >> Allows forcing decoders of different media type.
> >> Needed to decode media data muxed as data streams.
> >> ---
> >> doc/ffmpeg.texi | 5 +
> >>
75 matches
Mail list logo
