[FFmpeg-devel] Calculating audio frame rate
Hi all, First, I apologize for asking a question not directly related to ffmpeg development, but hope you can still help me... I'm looking for some code to calculate the frame rate of audio, based on parameters such as the codec id, sampling rate, channels, codec private data etc. For example, if the codec is AAC and the sampling rate is 44.1KHz, the frame rate would be 44100/1024= ~43 fps (assuming each frame has 1024 samples, not 960) Has anyone ever written/bumped into something that implements this across multiple codecs? Thank you! Eran ___ 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] [PATCH 2/2] avformat/hls: Don't strdup non-null-terminated string
If an URI indicated that the data protocol was in use, it would be
copied into a temporary buffer via strncpy(dst, src, strlen(src)),
thereby ensuring that the trailing \0 would not be copied, despite dst
being uninitialized. dst would then be av_strdup'ed, leading to
potential segfaults.
The solution to this is simple: Don't copy the URI in the temporary
buffer at all, instead av_strdup it directly.
This fixes a -Wstringop-truncation warning emitted by GCC 9.2.
Signed-off-by: Andreas Rheinhardt
---
This is honestly untested, as this is not covered by FATE.
libavformat/hls.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745a7..fc45719d1c 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -403,8 +403,7 @@ static struct segment *new_init_section(struct playlist
*pls,
const char *url_base)
{
struct segment *sec;
-char *ptr;
-char tmp_str[MAX_URL_SIZE];
+char tmp_str[MAX_URL_SIZE], *ptr = tmp_str;
if (!info->uri[0])
return NULL;
@@ -414,11 +413,11 @@ static struct segment *new_init_section(struct playlist
*pls,
return NULL;
if (!av_strncasecmp(info->uri, "data:", 5)) {
-strncpy(tmp_str, info->uri, strlen(info->uri));
+ptr = info->uri;
} else {
ff_make_absolute_url(tmp_str, sizeof(tmp_str), url_base, info->uri);
}
-sec->url = av_strdup(tmp_str);
+sec->url = av_strdup(ptr);
if (!sec->url) {
av_free(sec);
return NULL;
--
2.20.1
___
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] [PATCH 1/2] avcodec/v4l2_m2m: Avoid using intermediate buffer
Up until now, v4l2_m2m would write via snprintf() into an intermediate
buffer and then copy from there (via strncpy()) to the end buffer. This
commit changes this by removing the intermediate buffer.
The call to strncpy() was actually of the form strncpy(dst, src,
strlen(src) + 1) which is unsafe in general, but safe in this instance
because dst and src were both of the same size and src was a proper
zero-terminated string. But this nevertheless led to a compiler warning
"‘strncpy’ specified bound depends on the length of the source argument
[-Wstringop-overflow=]" in GCC 9.2. strlen() was unnecessary anyway.
Reviewed-by: Andriy Gelman
Signed-off-by: Andreas Rheinhardt
---
Thanks to Andriy for testing and reviewing.
libavcodec/v4l2_m2m.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 2d21f910bc..e48b3a8ccf 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -358,7 +358,6 @@ int ff_v4l2_m2m_codec_init(V4L2m2mPriv *priv)
{
int ret = AVERROR(EINVAL);
struct dirent *entry;
-char node[PATH_MAX];
DIR *dirp;
V4L2m2mContext *s = priv->context;
@@ -372,9 +371,8 @@ int ff_v4l2_m2m_codec_init(V4L2m2mPriv *priv)
if (strncmp(entry->d_name, "video", 5))
continue;
-snprintf(node, sizeof(node), "/dev/%s", entry->d_name);
-av_log(s->avctx, AV_LOG_DEBUG, "probing device %s\n", node);
-strncpy(s->devname, node, strlen(node) + 1);
+snprintf(s->devname, sizeof(s->devname), "/dev/%s", entry->d_name);
+av_log(s->avctx, AV_LOG_DEBUG, "probing device %s\n", s->devname);
ret = v4l2_probe_driver(s);
if (!ret)
break;
@@ -389,7 +387,7 @@ int ff_v4l2_m2m_codec_init(V4L2m2mPriv *priv)
return ret;
}
-av_log(s->avctx, AV_LOG_INFO, "Using device %s\n", node);
+av_log(s->avctx, AV_LOG_INFO, "Using device %s\n", s->devname);
return v4l2_configure_contexts(s);
}
--
2.20.1
___
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] libavformat/avisynth: AvxSynth deprecation and switch to AviSynth+
With the release of version 3.5 earlier this evening, AviSynth+ can now be built and used natively on the same platforms AvxSynth could, making AvxSynth completely obsolete. Due to that, is there a preference for how we should handle this? I have two different patchsets ready to send. The first simply adds a warning message that AvxSynth is deprecated and urges the user to upgrade to AviSynth+ 3.5 or higher. The actual switch would then probably occur after the message has been visible for one or two releases of FFmpeg. The second just up and removes the AvxSynth-specific branching and streamlines the demuxer so that it assumes only AviSynth(+) is being used at all times, with the USING_AVISYNTH checks reverted back to simple _WIN32 at the spots it's still necessary to compensate for platform differences. On the one hand, it would be kind of rude to apply the second patchset with no advance warning to users that AvxSynth will suddenly cease to work. But on the other hand, AvxSynth itself is such a dead project at this point that the demuxer was always lopsided in favor of Windows and the vast majority of users probably aren't/weren't even aware AvxSynth existed, let alone that FFmpeg could use it (I still see people calling the ability to open AviSynth scripts a Windows-only feature, even though it's been possible on Linux, et al., with AvxSynth for the last 7-7.5 years, with FFmpeg and x264 both gaining the ability to use it in February/March 2013). ___ 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] Splitting or merging libraries (was: Status and Plans for Subtitle Filters)
On Sun, Mar 1, 2020 at 6:54 AM Nicolas George wrote: > Vittorio Giovara (12020-02-28): > > err a monsterlibrary is a monsterlibrary regardless of how it is linked, > > and it's good that you mention static linking since that would be one of > > the best reason to keep library separated > > You seem to have some basic misconceptions about how linking works, > which result in completely incorrect conclusions. Let me elaborate. > I'd appreciate if we could keep the conversation cordial, rather than throwing assumptions on people. This is a pretty hard start, and I will not continue on this thread if this is the tone going forward. First, if you take a monsterlibrary and configure it with > --disable-everything --enable-what-you-need, you get a tiny library. > Therefore, the maximum size of the library is not an issue for the > people who ship their own. > First of all the "size" of any code is pretty much the least important aspect of development, unless we're talking the embedded world or assembly optimizations. That does not mean one should be allowed to make the code purposely larger for no gain: so far I haven't heard any good motive for merging the libraries together, while the ones for splitting them even more are pretty evident. > For static linking, it's even simpler. Static linking does not copy the > whole library, the linker only picks the object files it needs based on > the symbols the application uses. You can have a monsterlibrary; you can > have ten extra useless monsterlibraries, it will change nothing: the > resulting binary will contain exactly the code it needs. > In a perfect world, sure, but that is not the case. To my knowledge most compilers do not perform such pervasive code elimination, unless when configured with extremely obscure parameters. This presentation seems to illustrate the problem well https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf > > There are plenty of example in which imposing constraints on the code or > > language forces developers to write better code. > > And there are plenty of examples where arbitrary constraints lead to > worse code. > I feel like we're starting to go in the agree to disagree section :) > > For example splitting the libraries would make sure that a private header > > does not "leak" to a dependent library, like in a patch that was > published > > a few days ago. > > But the "leak" is only a problem because the libraries are separate. > No, it was a problem from a design point of view, there are different libraries dedicated to different things, merging everything together serves no purpose, while separating them a bit more, would introduce new functionality and features in the project. > The fact is, we develop these libraries as a whole. Codecs, muxers and > filters are often written by the same person and use the same tables and > small utility functions. These are functions that are too specific and > anecdotal to be public functions. We can update them easily, including > their prototype, because they are used only at two or three places in > code we know. > This is very very anecdotal. Besides, you don't know how a library will be used by the application, I believe you'd be surprised. > If we stopped caring about separate libraries, we would just name them > ff_someobscurecodec_get_random_info() and call them whenever necessary. > But because people insist on split libraries, we have to jump hoops and > waste effort. > Well by that reasoning, why isn't everything compiled in-kernel? After all we're just wasting precious user memory when everything could run from kernel space right? Maybe encoding and decoding could go 1% faster!!! Whether you like it or not, there is value in designing separate tools and implementing separate tools and libraries for different use cases: even though the ffmpeg suite of library is closed together because they pertain the same subject (multimedia) it makes a lot of sense to keep them separate and try to identify portions of code that could work well enough in a library separated from the rest. -- Vittorio ___ 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 4/4] avformat/mxfenc: add some missing content package rates
On Mon, 2 Mar 2020, Baptiste Coudurier wrote:
Hey guys,
On Mar 2, 2020, at 12:57 PM, Marton Balint wrote:
On Mon, 2 Mar 2020, Tomas Härdin wrote:
fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
> Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint :
> > Fixes ticket #8523.
> > > > Signed-off-by: Marton Balint
> > ---
> > libavformat/mxf.c | 13 +
> > 1 file changed, 13 insertions(+)
> > > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > index 14056647c5..987410258a 100644
> > --- a/libavformat/mxf.c
> > +++ b/libavformat/mxf.c
> > @@ -135,10 +135,23 @@ static const MXFContentPackageRate
mxf_content_package_rates[] = {
> > { 2, { 1,24} },
> > { 3, { 1001, 24000 } },
> > { 4, { 1,25} },
> > +{ 6, { 1,30} },
> > { 7, { 1001, 3 } },
> > +{ 8, { 1 , 48} },
> > +{ 9, { 1001, 48000 } },
> > { 10, { 1,50} },
> > { 12, { 1,60} },
> > { 13, { 1001, 6 } },
> > +{ 14, { 1,72} },
> > +{ 15, { 1001, 72000 } },
> > +{ 16, { 1,75} },
> > +{ 18, { 1,90} },
> > +{ 19, { 1001, 9 } },
> > +{ 20, { 1,96} },
> > +{ 21, { 1001, 96000 } },
> > +{ 22, { 1,100 } },
> > +{ 24, { 1,120 } },
> > +{ 25, { 1001, 12} },
> > Are these still the only supported frame rates?
These are the *package* rates that SMPTE 326M defines (technically it defines
the /1.001 version of 25, 50, 75 and 100 fps, but those are not used).
For the record, this is section 7.2 Content package rate in SMPTE 326M-
2000. What is not initially obvious is that mxf_content_package_rates-
rate is bits b5..b0. A comment about this would be nice, I don't like
magical tables in the MXF codebase not being justified by references :)
You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
too. But it's probably wise not to do that.
I am not sure, maybe we should add all possible values, even if they are
uncommon. After all I found out that for example 50/1.001 is actually supported
for mkvmerge:
It seems like if we were to do that, we would open the door to allowing
essences that don’t support the package rate and we should definitely NOT do
that.
I am not sure I understand, there are two different things to consider:
1) support every frame rate which can be exactly represented by a package
rate as defined in SMPTE 326M, even uncommon ones like 50/1.001.
2) support all frame rates and write 0 (undefined) as the package rate
for frame rates which cannot be exactly represented
You are voting against 2), right? 1) should not cause any "compatibility"
issues as far as I see.
Thanks,
Marton
___
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 4/4] avformat/mxfenc: add some missing content package rates
Hey guys,
> On Mar 2, 2020, at 12:57 PM, Marton Balint wrote:
>
>
>
> On Mon, 2 Mar 2020, Tomas Härdin wrote:
>
>> fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
>>> On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
>>> > Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint :
>>> > > Fixes ticket #8523.
>>> > > > > Signed-off-by: Marton Balint
>>> > > ---
>>> > > libavformat/mxf.c | 13 +
>>> > > 1 file changed, 13 insertions(+)
>>> > > > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
>>> > > index 14056647c5..987410258a 100644
>>> > > --- a/libavformat/mxf.c
>>> > > +++ b/libavformat/mxf.c
>>> > > @@ -135,10 +135,23 @@ static const MXFContentPackageRate
>>> > > mxf_content_package_rates[] = {
>>> > > { 2, { 1,24} },
>>> > > { 3, { 1001, 24000 } },
>>> > > { 4, { 1,25} },
>>> > > +{ 6, { 1,30} },
>>> > > { 7, { 1001, 3 } },
>>> > > +{ 8, { 1 , 48} },
>>> > > +{ 9, { 1001, 48000 } },
>>> > > { 10, { 1,50} },
>>> > > { 12, { 1,60} },
>>> > > { 13, { 1001, 6 } },
>>> > > +{ 14, { 1,72} },
>>> > > +{ 15, { 1001, 72000 } },
>>> > > +{ 16, { 1,75} },
>>> > > +{ 18, { 1,90} },
>>> > > +{ 19, { 1001, 9 } },
>>> > > +{ 20, { 1,96} },
>>> > > +{ 21, { 1001, 96000 } },
>>> > > +{ 22, { 1,100 } },
>>> > > +{ 24, { 1,120 } },
>>> > > +{ 25, { 1001, 12} },
>>> > > Are these still the only supported frame rates?
>>> These are the *package* rates that SMPTE 326M defines (technically it
>>> defines the /1.001 version of 25, 50, 75 and 100 fps, but those are not
>>> used).
>>
>> For the record, this is section 7.2 Content package rate in SMPTE 326M-
>> 2000. What is not initially obvious is that mxf_content_package_rates-
>>> rate is bits b5..b0. A comment about this would be nice, I don't like
>> magical tables in the MXF codebase not being justified by references :)
>>
>> You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
>> too. But it's probably wise not to do that.
>
> I am not sure, maybe we should add all possible values, even if they are
> uncommon. After all I found out that for example 50/1.001 is actually
> supported for mkvmerge:
It seems like if we were to do that, we would open the door to allowing
essences that don’t support the package rate and we should definitely NOT do
that.
—
Baptiste
___
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 4/17] avformat/segment: Don't set extradata size twice
On Mon, Mar 02, 2020 at 10:47:29AM +0530, Gyan Doshi wrote: > > > On 02-03-2020 10:05 am, Andreas Rheinhardt wrote: > >ff_alloc_extradata() already sets the size of the extradata so doing it > >again is unnecessary. > > > >Signed-off-by: Andreas Rheinhardt > >--- > > libavformat/segment.c | 1 - > > 1 file changed, 1 deletion(-) > > > >diff --git a/libavformat/segment.c b/libavformat/segment.c > >index 5f7fe76600..d565183349 100644 > >--- a/libavformat/segment.c > >+++ b/libavformat/segment.c > >@@ -882,7 +882,6 @@ static int seg_write_packet(AVFormatContext *s, AVPacket > >*pkt) > > goto calc_times; > > } > > memcpy(st->codecpar->extradata, pkt_extradata, > > pkt_extradata_size); > >-st->codecpar->extradata_size = pkt_extradata_size; > > } > > } > > LGTM. will apply thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ 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 1/2] avcodec/adpcm: Clip step index for ADPCM_IMA_APM
On Mon, Mar 02, 2020 at 09:40:52AM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ 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/mxfenc: Never set codec_ul UID to NULL
Hi Andreas, > On Mar 2, 2020, at 10:14 AM, Tomas Härdin wrote: > > fre 2020-02-28 klockan 05:14 +0100 skrev Andreas Rheinhardt: >> mxf distinguishes codec profiles by different UIDs and therefore needs >> to check that the input is actually compatible with mxf (i.e. if there >> is a defined UID for it). If not, then sometimes the UID would be set to >> NULL and writing the (video) packet would fail. Yet the following audio >> packet would trigger writing the header (which has been postponed because >> the UID is not known at the start) and if the UID is NULL, this can lead >> to segfaults. This commit therefore stops setting the UID to NULL if the >> input is incompatible with mxf (it has initially been set to a generic >> value in mxf_write_header()). >> >> Fixes #7993. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> a) #7993 is actually a segfault even if its description suggests >> otherwise. >> b) My actually preferred way to fix this was to error out if an audio >> packet is encountered and the header has not been written yet, thereby >> ensuring that only a video packet can trigger writing the header and >> said code is only reached when the video is actually compatible with mxf >> (or with this muxer?). Yet I was surprised to find out that the >> FATE-test mxf-d10-user-comments would fail with this, because right now >> writing the header in this test is triggered by an audio packet (the >> video packets aren't written because they are not of the right size) and >> if these aren't written either, there will be zero bytes of output. Yes, we need the video track before writing the header. It’s an issue and that’s what should be implemented IMHO. — Baptiste ___ 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 1/1] Patch for adding Documentation of ff_http_match_no_proxy
On Mon, Mar 02, 2020 at 08:32:10PM +0530, Sourabh Sharma wrote:
> Patch for adding Documentation of ff_http_match_no_proxy
> Function ff_http_match_no_proxy check for host of proxy address matches with
> the hostname or not.
>
> ---
> libavformat/network.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/network.h b/libavformat/network.h
> index 71347e815b..7c93375ae5 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -303,6 +303,13 @@ int ff_listen_connect(int fd, const struct sockaddr
> *addr,
>socklen_t addrlen, int timeout,
>URLContext *h, int will_try_next);
>
> +/**
> + * It Checks for a host of proxy address matches with the hostname or not.
> + *
> + * @param no_proxy Server address of proxy server e.g. example.domain.com
> + * @param hostname Server address of hostname e.g. domain.com
> + * @return 0 if don't match, 1 for exactly match
> +*/
> int ff_http_match_no_proxy(const char *no_proxy, const char *hostname);
maybe looking at how this function is used makes it clearer what it does
for example
libavformat/http.c:use_proxy = !ff_http_match_no_proxy(getenv("no_proxy"),
hostname) &&
libavformat/http.c- proxy_path && av_strstart(proxy_path,
"http://";, NULL);
but basically
no_proxy, is a list of addresses for which not to use the proxy server,
these may be local addresses
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: PGP signature
___
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 7/30] avformat/matroskaenc: Avoid allocations for SeekHead
On Fri, Feb 28, 2020 at 6:10 AM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt < > andreas.rheinha...@gmail.com> wrote: > >> Andreas Rheinhardt: >> > Andreas Rheinhardt: >> >> Andreas Rheinhardt: >> >>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the >> >>> beginning referencing the main level 1 elements (i.e. not the >> Clusters) >> >>> and one at the end, referencing the Clusters. This second SeekHead was >> >>> useless and has therefore been removed. Yet the SeekHead-related >> >>> functions and structures are still geared towards this usecase: They >> >>> are built around an allocated array of variable size that gets >> >>> reallocated every time an element is added to it although the maximum >> >>> number of Seek entries is a small compile-time constant, so that one >> should >> >>> rather include the array in the SeekHead structure itself; and said >> >>> structure should be contained in the MatroskaMuxContext instead of >> being >> >>> allocated separately. >> >>> >> >>> The earlier code reserved space for a SeekHead with 10 entries, >> although >> >>> we currently write at most 6. Reducing said number implied that every >> >>> Matroska/Webm file will be 84 bytes smaller and required to adapt >> >>> several FATE tests; furthermore, the reserved amount overestimated the >> >>> amount needed for for the SeekHead's length field and how many bytes >> >>> need to be reserved to write a EBML Void element, bringing the total >> >>> reduction to 89 bytes. >> >>> >> >>> Signed-off-by: Andreas Rheinhardt >> >>> --- >> >> >> >> Ping. >> >> >> >> - Andreas >> >> >> > Ping (the actual patch (which has been omitted for brevity) is here: >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html). >> > >> > - Andreas >> > >> Another ping. >> >> - Andreas >> > > Ping. > > - Andreas > Ping. - Andreas ___ 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/udp: support w32pthreads compat
phunkyfish in the history is fine thanks ;)
> On 2 Mar 2020, at 21:00, Marton Balint wrote:
>
>
>
>> On Mon, 2 Mar 2020, Ross Nicholson wrote:
>>
>> Updated to correct header.
>
> Can you resend the patch with the proper author (e.g. Ross Nicholson instead
> of phunkyfish?) Or you want to appear as phunkyfish in the history?
>
> Thanks,
> Marton
>
>>
>>> On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
>>>
>>>
>>>
On Mon, 2 Mar 2020, phunkyfish wrote:
>>>
>>> > ---
>>> > compat/w32pthreads.h | 8
>>> > libavformat/udp.c| 6 +-
>>> > 2 files changed, 13 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
>>> > index 7df33b7da4..6405e72b64 100644
>>> > --- a/compat/w32pthreads.h
>>> > +++ b/compat/w32pthreads.h
>>> > @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
>>> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
>>> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>>> >
>>> > +#define PTHREAD_CANCEL_ENABLE 1
>>> > +#define PTHREAD_CANCEL_DISABLE 0
>>> > +
>>> > static av_unused unsigned __stdcall attribute_align_arg
>>> win32thread_worker(void *arg)
>>> > {
>>> > pthread_t *h = (pthread_t*)arg;
>>> > @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
>>> *cond)
>>> > return 0;
>>> > }
>>> >
>>> > +static inline int pthread_setcancelstate(int state, int *oldstate)
>>> > +{
>>> > +return 0;
>>> > +}
>>> > +
>>> > #endif /* COMPAT_W32PTHREADS_H */
>>> > diff --git a/libavformat/udp.c b/libavformat/udp.c
>>> > index 23c3773c64..692ff07cec 100644
>>> > --- a/libavformat/udp.c
>>> > +++ b/libavformat/udp.c
>>> > @@ -61,7 +61,11 @@
>>> > #define IPPROTO_UDPLITE 136
>>> > #endif
>>> >
>>> > -#if HAVE_PTHREAD_CANCEL
>>> > +#if HAVE_W32THREADS
>>> > +#include "compat/w32pthreads.h"
>>>
>>> This should be #include "libavutil/thread.h" instead, the compat layer
>>> should not be included directly.
>>>
>>> Regards,
>>> Marton
>>>
>>> > +#undef HAVE_PTHREAD_CANCEL
>>> > +#define HAVE_PTHREAD_CANCEL 1
>>> > +#elif HAVE_PTHREAD_CANCEL
>>> > #include
>>> > #endif
>>> >
>>> > --
>>> > 2.20.1 (Apple Git-117)
>>> >
>>> > ___
>>> > 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".
>> ___
>> 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".
___
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 v2] avformat/mxfenc: use a zero based continuity counter
On Mon, 2 Mar 2020, Tomas Härdin wrote: lör 2020-02-29 klockan 21:06 +0100 skrev Marton Balint: The standard does not seem to require the counter to be zero based, but some checker tools (MyriadBits MXFInspect, Interra Baton) have validations against 0 start... Fixes ticket #6781. Signed-off-by: Marton Balint --- libavformat/mxfenc.c | 2 +- tests/ref/fate/mxf-user-comments | 2 +- tests/ref/lavf/mxf | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c index 7ea47d7311..5e0dc0e889 100644 --- a/libavformat/mxfenc.c +++ b/libavformat/mxfenc.c @@ -2686,7 +2686,7 @@ static void mxf_write_system_item(AVFormatContext *s) avio_w8(pb, mxf->content_package_rate); // content package rate avio_w8(pb, 0x00); // content package type avio_wb16(pb, 0x00); // channel handle -avio_wb16(pb, (mxf->tc.start + frame) & 0x); // continuity count, supposed to overflow +avio_wb16(pb, frame & 0x); // continuity count, supposed to overflow OK I suppose Thanks, applied. Regards, Marton ___ 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/udp: support w32pthreads compat
On Mon, 2 Mar 2020, Ross Nicholson wrote:
Updated to correct header.
Can you resend the patch with the proper author (e.g. Ross
Nicholson instead of phunkyfish?) Or you want to appear as phunkyfish in
the history?
Thanks,
Marton
On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
On Mon, 2 Mar 2020, phunkyfish wrote:
> ---
> compat/w32pthreads.h | 8
> libavformat/udp.c| 6 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 7df33b7da4..6405e72b64 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>
> +#define PTHREAD_CANCEL_ENABLE 1
> +#define PTHREAD_CANCEL_DISABLE 0
> +
> static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
> {
> pthread_t *h = (pthread_t*)arg;
> @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
*cond)
> return 0;
> }
>
> +static inline int pthread_setcancelstate(int state, int *oldstate)
> +{
> +return 0;
> +}
> +
> #endif /* COMPAT_W32PTHREADS_H */
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 23c3773c64..692ff07cec 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -61,7 +61,11 @@
> #define IPPROTO_UDPLITE 136
> #endif
>
> -#if HAVE_PTHREAD_CANCEL
> +#if HAVE_W32THREADS
> +#include "compat/w32pthreads.h"
This should be #include "libavutil/thread.h" instead, the compat layer
should not be included directly.
Regards,
Marton
> +#undef HAVE_PTHREAD_CANCEL
> +#define HAVE_PTHREAD_CANCEL 1
> +#elif HAVE_PTHREAD_CANCEL
> #include
> #endif
>
> --
> 2.20.1 (Apple Git-117)
>
> ___
> 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".
___
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 4/4] avformat/mxfenc: add some missing content package rates
On Mon, 2 Mar 2020, Tomas Härdin wrote:
fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
> Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint :
> > Fixes ticket #8523.
> >
> > Signed-off-by: Marton Balint
> > ---
> > libavformat/mxf.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > index 14056647c5..987410258a 100644
> > --- a/libavformat/mxf.c
> > +++ b/libavformat/mxf.c
> > @@ -135,10 +135,23 @@ static const MXFContentPackageRate
mxf_content_package_rates[] = {
> > { 2, { 1,24} },
> > { 3, { 1001, 24000 } },
> > { 4, { 1,25} },
> > +{ 6, { 1,30} },
> > { 7, { 1001, 3 } },
> > +{ 8, { 1 , 48} },
> > +{ 9, { 1001, 48000 } },
> > { 10, { 1,50} },
> > { 12, { 1,60} },
> > { 13, { 1001, 6 } },
> > +{ 14, { 1,72} },
> > +{ 15, { 1001, 72000 } },
> > +{ 16, { 1,75} },
> > +{ 18, { 1,90} },
> > +{ 19, { 1001, 9 } },
> > +{ 20, { 1,96} },
> > +{ 21, { 1001, 96000 } },
> > +{ 22, { 1,100 } },
> > +{ 24, { 1,120 } },
> > +{ 25, { 1001, 12} },
>
> Are these still the only supported frame rates?
These are the *package* rates that SMPTE 326M defines (technically it
defines the /1.001 version of 25, 50, 75 and 100 fps, but those are not
used).
For the record, this is section 7.2 Content package rate in SMPTE 326M-
2000. What is not initially obvious is that mxf_content_package_rates-
rate is bits b5..b0. A comment about this would be nice, I don't like
magical tables in the MXF codebase not being justified by references :)
You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
too. But it's probably wise not to do that.
I am not sure, maybe we should add all possible values, even if they are
uncommon. After all I found out that for example 50/1.001 is actually
supported for mkvmerge:
https://gitlab.com/mbunkus/mkvtoolnix/-/commit/1a350a9573e4f895223e7ab10f7d491440abaf62
Regards,
Marton
> How do archivists store low-fps film in mxf?
I don't know. One can write an undefined package rate into the file, or
the frame rate can may be different from package rate. You can put almost
anything into MXF, the only problem is that it will not be widely
supported or readable.
Like Marton says, MXF allows anything. In practice everyone uses a
small set of profiles of MXF. No one attempts to support all of MXF,
that way lies madness.
/Tomas
___
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] avformat/udp: support w32pthreads compat
Updated to correct header.
On Mon, 2 Mar 2020 at 19:53, Marton Balint wrote:
>
>
> On Mon, 2 Mar 2020, phunkyfish wrote:
>
> > ---
> > compat/w32pthreads.h | 8
> > libavformat/udp.c| 6 +-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > index 7df33b7da4..6405e72b64 100644
> > --- a/compat/w32pthreads.h
> > +++ b/compat/w32pthreads.h
> > @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
> >
> > +#define PTHREAD_CANCEL_ENABLE 1
> > +#define PTHREAD_CANCEL_DISABLE 0
> > +
> > static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> > {
> > pthread_t *h = (pthread_t*)arg;
> > @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> > return 0;
> > }
> >
> > +static inline int pthread_setcancelstate(int state, int *oldstate)
> > +{
> > +return 0;
> > +}
> > +
> > #endif /* COMPAT_W32PTHREADS_H */
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index 23c3773c64..692ff07cec 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -61,7 +61,11 @@
> > #define IPPROTO_UDPLITE 136
> > #endif
> >
> > -#if HAVE_PTHREAD_CANCEL
> > +#if HAVE_W32THREADS
> > +#include "compat/w32pthreads.h"
>
> This should be #include "libavutil/thread.h" instead, the compat layer
> should not be included directly.
>
> Regards,
> Marton
>
> > +#undef HAVE_PTHREAD_CANCEL
> > +#define HAVE_PTHREAD_CANCEL 1
> > +#elif HAVE_PTHREAD_CANCEL
> > #include
> > #endif
> >
> > --
> > 2.20.1 (Apple Git-117)
> >
> > ___
> > 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".
___
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] [PATCH] avformat/udp: support w32pthreads compat
---
compat/w32pthreads.h | 8
libavformat/udp.c| 7 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 7df33b7da4..6405e72b64 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
+#define PTHREAD_CANCEL_ENABLE 1
+#define PTHREAD_CANCEL_DISABLE 0
+
static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
{
pthread_t *h = (pthread_t*)arg;
@@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
return 0;
}
+static inline int pthread_setcancelstate(int state, int *oldstate)
+{
+return 0;
+}
+
#endif /* COMPAT_W32PTHREADS_H */
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 23c3773c64..3af6b09ca7 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,8 +61,13 @@
#define IPPROTO_UDPLITE 136
#endif
+#if HAVE_W32THREADS
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
#if HAVE_PTHREAD_CANCEL
-#include
+#include "libavutil/thread.h"
#endif
#ifndef IPV6_ADD_MEMBERSHIP
--
2.20.1 (Apple Git-117)
___
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 2/4] avformat/mxf: get rid of samples per frame array usage
On Mon, 2 Mar 2020, Tomas Härdin wrote:
fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
Signed-off-by: Marton Balint
---
libavformat/mxf.c| 44
libavformat/mxf.h| 6 --
libavformat/mxfdec.c | 23 +++
libavformat/mxfenc.c | 24 ++--
4 files changed, 13 insertions(+), 84 deletions(-)
int ff_mxf_get_content_package_rate(AVRational time_base)
{
-int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
-AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
-
-diff.num = FFABS(diff.num);
-
-if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
-return -1;
-
-return mxf_content_package_rates[idx];
+for (int i = 0; mxf_time_base[i].num; i++)
+if (!av_cmp_q(time_base, mxf_time_base[i]))
I see this gets rid of the inexact check for an exact one. Approve!
@@ -3307,20 +3307,17 @@ static int mxf_get_next_track_edit_unit(MXFContext
*mxf, MXFTrack *track, int64_
static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
int64_t edit_unit)
{
-int i, total = 0, size = 0;
MXFTrack *track = st->priv_data;
AVRational time_base = av_inv_q(track->edit_rate);
AVRational sample_rate = av_inv_q(st->time_base);
-const MXFSamplesPerFrame *spf = NULL;
-int64_t sample_count;
// For non-audio sample_count equals current edit unit
if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
return edit_unit;
-if ((sample_rate.num / sample_rate.den) == 48000)
-spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
-if (!spf) {
+if ((sample_rate.num / sample_rate.den) == 48000) {
+return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
Should be OK, per previous rounding argument
}
sc->index = INDEX_D10_AUDIO;
sc->container_ul =
((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
-sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 4;
+sc->frame_size = 4 + 8 * av_rescale_rnd(st->codecpar->sample_rate,
mxf->time_base.num, mxf->time_base.den, AV_ROUND_UP) * 4;
I was going to say this is only used for CBR video, but closer
inspection reveals it's used to prevent 1/1.001 rate audio packets from
making their way into CBR files. This is a bit surprising to me, since
D-10 supports NTSC (without audio?)
I thought D10 can only be CBR and and it can only use a constant edit unit
size, 1/1.001 audio packet size difference is handled using KLV
padding. So what we compute here is a _maximum_ frame size.
Regards,
Marton
sc->index = INDEX_WAV;
} else {
mxf->slice_count = 1;
-sc->frame_size = (st->codecpar->channels *
spf[0].samples_per_frame[0] *
-
av_get_bits_per_sample(st->codecpar->codec_id)) / 8;
+sc->frame_size = st->codecpar->channels *
+ av_rescale_rnd(st->codecpar->sample_rate,
mxf->time_base.num, mxf->time_base.den, AV_ROUND_UP) *
+
av_get_bits_per_sample(st->codecpar->codec_id) / 8;
Looks similarly OK
/Tomas
___
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 V2] [RFC] GSoC: FLIF16 Image format parser
Anamitra Ghorui (12020-03-02):
> According to the specification of the file format, there is no mention of an
> upper bound for the integer: https://flif.info/spec.html#_part_1_main_header
But they are mapped to FFmpeg values: width and height are ints, frame
counts are uint64_t at best. Therefore, I think you should drop the
varint_t structure entirely, and just read varints into uint64_t,
returning an error (INVALIDDATA) if it exceeds.
> >> + * magnitude of the varint, similar to UTF-8 encoding.
> > This is not how UTF-8 works.
> I was talking about it in the context of the 'prefix coding' it uses. UTF-8
> uses the MSB bits to indicate how many successive bits aside from the starting
> bit are included in a character. The varint does a similar thing in the manner
> that it also uses an MSB bit to indicate that a successive bit is included in
> the number. Hovever aside from this superficial similarity there is not much
> in common.
I'd prefer if there is no mention of UTF-8 rather than a misleading one.
Actually, this particular coding of integers seems quite common, it must
have a name.
> AVPacket *pkt = av_mallocz(sizeof(AVPacket));
> if (!pkt)
> return pkt;
>
> Is there a special reason for this?
I don't think so.
> I see. the stucture should therefore be defined with buf after buf_size
> (hence putting pad + 1 bytes in contiguous storage but there may be a problem
> with the byte padding of the struct), or should buf point to v + sizeof(*v)?
> (* See follow-up content below)
See below.
> I have tested it separately. In the given code, the function will set the
> value
> to { 128, 0, 0 }, which is an incorrect representation. But for the puropses
> of
> the parser and the decoder where we are only concerned with bound checking
> with
> an existing number, such a situation will never occur. However I can see that
> there will be issues when the encoder will be written since then we will have
> to make the varint and write the varint to a file.
Either fix the function to make it work correctly, or document that it
has an unusual behavior.
> >An assert cannot be used to check for a memory allocation failure.
> I think I have to use av_log then.
No, not av_log() either, because it does not prevent the code from
continuing and dereferencing NULL (the asserts do, unless they are
disabled at build time). You need to add an error return, and return
AVERROR(ENOMEM).
> Should I double the size everytime v->buf_size becomes
> equal to the actual number of byte-segments of the varint?
Double the size every time you need to increase it, every time what you
need to put in the buffer does not fit.
> If I add it to the end of the struct, the compiler will likely add padding
> bits to it, but I don't think its a problem since the padding bits will be set
> to zero anyway and therefore can be used in the buffer.
Exactly. You could even make a sizeof() expression to avoid allocating
bytes if there is already room enough in the padding. It is quite a
common pattern. Modern C even allows 0-sized arrays at the end of
structs to make it more elegant, but we don't use it in FFmpeg.
Note: all these considerations about allocation, incrementation, etc.,
would be moot if you decide, as I think you should, to just drop
varint_t and use a large enough integer instead.
> FLIF16Varint should be fine then?
I think so; as Anton points, the FF prefix is not mandatory for
structures, only the ff_ prefix for functions.
> >> +typedef enum FLIF16ParseStates {
> >> +FLIF16_HEADER = 1,
> >> +FLIF16_METADATA,
> >> +FLIF16_BITSTREAM,
> >> +// FLIF16_TRANSFORM,
> >> +FLIF16_PIXELDATA,
> >> +FLIF16_CHECKSUM,
> >> +FLIF16_VARINT
> >> +} flif16_states;
> > We usually name the enum and the corresponding types the same way.
> I had modelled most of the code after the GIF parser, and it names the enum
> values in the same manner:
> https://ffmpeg.org/doxygen/trunk/gif__parser_8c_source.html
> I will probably prefix them with 'FLIF16_STATE_' then.
The name of the values are fine. I meant the name of the enum itself,
FLIF16ParseStates compared to the name of the type, flif16_states.
By the way, the name of enums is usually singular.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
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/udp: support w32pthreads compat
On Mon, 2 Mar 2020, phunkyfish wrote:
---
compat/w32pthreads.h | 8
libavformat/udp.c| 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 7df33b7da4..6405e72b64 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
+#define PTHREAD_CANCEL_ENABLE 1
+#define PTHREAD_CANCEL_DISABLE 0
+
static av_unused unsigned __stdcall attribute_align_arg win32thread_worker(void
*arg)
{
pthread_t *h = (pthread_t*)arg;
@@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
return 0;
}
+static inline int pthread_setcancelstate(int state, int *oldstate)
+{
+return 0;
+}
+
#endif /* COMPAT_W32PTHREADS_H */
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 23c3773c64..692ff07cec 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,7 +61,11 @@
#define IPPROTO_UDPLITE 136
#endif
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_W32THREADS
+#include "compat/w32pthreads.h"
This should be #include "libavutil/thread.h" instead, the compat layer
should not be included directly.
Regards,
Marton
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#elif HAVE_PTHREAD_CANCEL
#include
#endif
--
2.20.1 (Apple Git-117)
___
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".
[FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
---
libavformat/rtsp.c | 49 ++
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cd6fc32a29..d23ec5723e 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
static int rtp_read_header(AVFormatContext *s)
{
uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
-char host[500], sdp[500];
-int ret, port;
+char host[500], sdp[1000], filters_buf[1000];
+int ret, port, sdp_length, nc;
URLContext* in = NULL;
int payload_type;
AVCodecParameters *par = NULL;
@@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
AVIOContext pb;
socklen_t addrlen = sizeof(addr);
RTSPState *rt = s->priv_data;
+const char *p;
if (!ff_network_init())
return AVERROR(EIO);
@@ -2513,12 +2514,41 @@ static int rtp_read_header(AVFormatContext *s)
av_url_split(NULL, 0, NULL, 0, host, sizeof(host), &port,
NULL, 0, s->url);
-snprintf(sdp, sizeof(sdp),
- "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
- addr.ss_family == AF_INET ? 4 : 6, host,
- par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
- par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
- port, payload_type);
+sdp_length = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "v=0\r\nc=IN IP%d %s\r\n",
+ addr.ss_family == AF_INET ? 4 : 6, host);
+
+p = strchr(s->url, '?');
+if (p) {
+static const char *filters[][2] = {{"sources", "incl"}, {"block",
"excl"}, {NULL, NULL}};
+int i;
+char *q;
+for (i = 0; filters[i][0]; i++) {
+if (av_find_info_tag(filters_buf, sizeof(filters_buf),
filters[i][0], p)) {
+/* av_log(s, AV_LOG_VERBOSE, "rtp_read_header() found %s
%s\n", filters[i][0], filters_buf); */
+q = filters_buf;
+while ((q = strchr(q, ',')) != NULL)
+*q = ' ';
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "a=source-filter:%s IN IP%d %s %s\r\n",
+ filters[i][1],
+ addr.ss_family == AF_INET ? 4 : 6, host,
+ filters_buf);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
+sdp_length += nc;
+}
+}
+}
+
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "m=%s %d RTP/AVP %d\r\n",
+ par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
+ par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
+ port, payload_type);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
+sdp_length += nc;
av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
avcodec_parameters_free(&par);
@@ -2534,6 +2564,9 @@ static int rtp_read_header(AVFormatContext *s)
s->pb = NULL;
return ret;
+fail_nobuf:
+ret = AVERROR(ENOBUFS);
+av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for
sdp-headers\n");
fail:
avcodec_parameters_free(&par);
if (in)
--
2.20.1 (Apple Git-117)
___
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] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp
---
libavformat/rtsp.c | 49 ++
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cd6fc32a29..c744e403c6 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
static int rtp_read_header(AVFormatContext *s)
{
uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
-char host[500], sdp[500];
-int ret, port;
+char host[500], sdp[1000], filters_buf[1000];
+int ret, port, sdp_length, nc;
URLContext* in = NULL;
int payload_type;
AVCodecParameters *par = NULL;
@@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
AVIOContext pb;
socklen_t addrlen = sizeof(addr);
RTSPState *rt = s->priv_data;
+const char *p
if (!ff_network_init())
return AVERROR(EIO);
@@ -2513,12 +2514,41 @@ static int rtp_read_header(AVFormatContext *s)
av_url_split(NULL, 0, NULL, 0, host, sizeof(host), &port,
NULL, 0, s->url);
-snprintf(sdp, sizeof(sdp),
- "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
- addr.ss_family == AF_INET ? 4 : 6, host,
- par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
- par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
- port, payload_type);
+sdp_length = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "v=0\r\nc=IN IP%d %s\r\n",
+ addr.ss_family == AF_INET ? 4 : 6, host);
+
+p = strchr(s->url, '?');
+if (p) {
+static const char *filters[][2] = {{"sources", "incl"}, {"block",
"excl"}, {NULL, NULL}};
+int i;
+char *q;
+for (i = 0; filters[i][0]; i++) {
+if (av_find_info_tag(filters_buf, sizeof(filters_buf),
filters[i][0], p)) {
+/* av_log(s, AV_LOG_VERBOSE, "rtp_read_header() found %s
%s\n", filters[i][0], filters_buf); */
+q = filters_buf;
+while ((q = strchr(q, ',')) != NULL)
+*q = ' ';
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "a=source-filter:%s IN IP%d %s %s\r\n",
+ filters[i][1],
+ addr.ss_family == AF_INET ? 4 : 6, host,
+ filters_buf);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
+sdp_length += nc;
+}
+}
+}
+
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+ "m=%s %d RTP/AVP %d\r\n",
+ par->codec_type == AVMEDIA_TYPE_DATA ? "application" :
+ par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
+ port, payload_type);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
+sdp_length += nc;
av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
avcodec_parameters_free(&par);
@@ -2534,6 +2564,9 @@ static int rtp_read_header(AVFormatContext *s)
s->pb = NULL;
return ret;
+fail_nobuf:
+ret = AVERROR(ENOBUFS);
+av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for
sdp-headers\n");
fail:
avcodec_parameters_free(&par);
if (in)
--
2.20.1 (Apple Git-117)
___
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/mxfenc: Never set codec_ul UID to NULL
fre 2020-02-28 klockan 05:14 +0100 skrev Andreas Rheinhardt: > mxf distinguishes codec profiles by different UIDs and therefore needs > to check that the input is actually compatible with mxf (i.e. if there > is a defined UID for it). If not, then sometimes the UID would be set to > NULL and writing the (video) packet would fail. Yet the following audio > packet would trigger writing the header (which has been postponed because > the UID is not known at the start) and if the UID is NULL, this can lead > to segfaults. This commit therefore stops setting the UID to NULL if the > input is incompatible with mxf (it has initially been set to a generic > value in mxf_write_header()). > > Fixes #7993. > > Signed-off-by: Andreas Rheinhardt > --- > a) #7993 is actually a segfault even if its description suggests > otherwise. > b) My actually preferred way to fix this was to error out if an audio > packet is encountered and the header has not been written yet, thereby > ensuring that only a video packet can trigger writing the header and > said code is only reached when the video is actually compatible with mxf > (or with this muxer?). Yet I was surprised to find out that the > FATE-test mxf-d10-user-comments would fail with this, because right now > writing the header in this test is triggered by an audio packet (the > video packets aren't written because they are not of the right size) and > if these aren't written either, there will be zero bytes of output. > c) It seems that mxf_write_header() doesn't actually write anything and > could be converted into an init function. > > libavformat/mxfenc.c | 25 ++--- > 1 file changed, 14 insertions(+), 11 deletions(-) Looks OK. Maybe we should have some av_asserts in the remaining places where sc->codec_ul is used? /Tomas ___ 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 v2] avformat/mxfenc: use a zero based continuity counter
lör 2020-02-29 klockan 21:06 +0100 skrev Marton Balint: > The standard does not seem to require the counter to be zero based, but some > checker tools (MyriadBits MXFInspect, Interra Baton) have validations against > 0 > start... > > Fixes ticket #6781. > > Signed-off-by: Marton Balint > --- > libavformat/mxfenc.c | 2 +- > tests/ref/fate/mxf-user-comments | 2 +- > tests/ref/lavf/mxf | 4 ++-- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c > index 7ea47d7311..5e0dc0e889 100644 > --- a/libavformat/mxfenc.c > +++ b/libavformat/mxfenc.c > @@ -2686,7 +2686,7 @@ static void mxf_write_system_item(AVFormatContext *s) > avio_w8(pb, mxf->content_package_rate); // content package rate > avio_w8(pb, 0x00); // content package type > avio_wb16(pb, 0x00); // channel handle > -avio_wb16(pb, (mxf->tc.start + frame) & 0x); // continuity count, > supposed to overflow > +avio_wb16(pb, frame & 0x); // continuity count, supposed to overflow OK I suppose /Tomas ___ 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 3/4] avformat/mxfenc: move content package rates and timebase combinations to a separate struct
fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint: > Signed-off-by: Marton Balint > --- > libavformat/mxf.c | 28 > libavformat/mxf.h | 5 + > 2 files changed, 17 insertions(+), 16 deletions(-) > Reasonable enough. /Tomas ___ 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 2/4] avformat/mxf: get rid of samples per frame array usage
fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
> Signed-off-by: Marton Balint
> ---
> libavformat/mxf.c| 44
> libavformat/mxf.h| 6 --
> libavformat/mxfdec.c | 23 +++
> libavformat/mxfenc.c | 24 ++--
> 4 files changed, 13 insertions(+), 84 deletions(-)
> int ff_mxf_get_content_package_rate(AVRational time_base)
> {
> -int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
> -AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
> -
> -diff.num = FFABS(diff.num);
> -
> -if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
> -return -1;
> -
> -return mxf_content_package_rates[idx];
> +for (int i = 0; mxf_time_base[i].num; i++)
> +if (!av_cmp_q(time_base, mxf_time_base[i]))
I see this gets rid of the inexact check for an exact one. Approve!
> @@ -3307,20 +3307,17 @@ static int mxf_get_next_track_edit_unit(MXFContext
> *mxf, MXFTrack *track, int64_
> static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
> int64_t edit_unit)
> {
> -int i, total = 0, size = 0;
> MXFTrack *track = st->priv_data;
> AVRational time_base = av_inv_q(track->edit_rate);
> AVRational sample_rate = av_inv_q(st->time_base);
> -const MXFSamplesPerFrame *spf = NULL;
> -int64_t sample_count;
>
> // For non-audio sample_count equals current edit unit
> if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
> return edit_unit;
>
> -if ((sample_rate.num / sample_rate.den) == 48000)
> -spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
> -if (!spf) {
> +if ((sample_rate.num / sample_rate.den) == 48000) {
> +return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
Should be OK, per previous rounding argument
> }
> sc->index = INDEX_D10_AUDIO;
> sc->container_ul =
> ((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
> -sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 4;
> +sc->frame_size = 4 + 8 *
> av_rescale_rnd(st->codecpar->sample_rate, mxf->time_base.num,
> mxf->time_base.den, AV_ROUND_UP) * 4;
I was going to say this is only used for CBR video, but closer
inspection reveals it's used to prevent 1/1.001 rate audio packets from
making their way into CBR files. This is a bit surprising to me, since
D-10 supports NTSC (without audio?)
> sc->index = INDEX_WAV;
> } else {
> mxf->slice_count = 1;
> -sc->frame_size = (st->codecpar->channels *
> spf[0].samples_per_frame[0] *
> -
> av_get_bits_per_sample(st->codecpar->codec_id)) / 8;
> +sc->frame_size = st->codecpar->channels *
> + av_rescale_rnd(st->codecpar->sample_rate,
> mxf->time_base.num, mxf->time_base.den, AV_ROUND_UP) *
> +
> av_get_bits_per_sample(st->codecpar->codec_id) / 8;
Looks similarly OK
/Tomas
___
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 4/4] avformat/mxfenc: add some missing content package rates
fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
>
> On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
>
> > Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint :
> > > Fixes ticket #8523.
> > >
> > > Signed-off-by: Marton Balint
> > > ---
> > > libavformat/mxf.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > > index 14056647c5..987410258a 100644
> > > --- a/libavformat/mxf.c
> > > +++ b/libavformat/mxf.c
> > > @@ -135,10 +135,23 @@ static const MXFContentPackageRate
> > > mxf_content_package_rates[] = {
> > > { 2, { 1,24} },
> > > { 3, { 1001, 24000 } },
> > > { 4, { 1,25} },
> > > +{ 6, { 1,30} },
> > > { 7, { 1001, 3 } },
> > > +{ 8, { 1 , 48} },
> > > +{ 9, { 1001, 48000 } },
> > > { 10, { 1,50} },
> > > { 12, { 1,60} },
> > > { 13, { 1001, 6 } },
> > > +{ 14, { 1,72} },
> > > +{ 15, { 1001, 72000 } },
> > > +{ 16, { 1,75} },
> > > +{ 18, { 1,90} },
> > > +{ 19, { 1001, 9 } },
> > > +{ 20, { 1,96} },
> > > +{ 21, { 1001, 96000 } },
> > > +{ 22, { 1,100 } },
> > > +{ 24, { 1,120 } },
> > > +{ 25, { 1001, 12} },
> >
> > Are these still the only supported frame rates?
>
> These are the *package* rates that SMPTE 326M defines (technically it
> defines the /1.001 version of 25, 50, 75 and 100 fps, but those are not
> used).
For the record, this is section 7.2 Content package rate in SMPTE 326M-
2000. What is not initially obvious is that mxf_content_package_rates-
>rate is bits b5..b0. A comment about this would be nice, I don't like
magical tables in the MXF codebase not being justified by references :)
You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
too. But it's probably wise not to do that.
> > How do archivists store low-fps film in mxf?
>
> I don't know. One can write an undefined package rate into the file, or
> the frame rate can may be different from package rate. You can put almost
> anything into MXF, the only problem is that it will not be widely
> supported or readable.
Like Marton says, MXF allows anything. In practice everyone uses a
small set of profiles of MXF. No one attempts to support all of MXF,
that way lies madness.
/Tomas
___
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 1/4] avformat/audiointerleave: disallow using a samples_per_frame array
On Fri, Feb 28, 2020 at 1:38 AM Marton Balint wrote:
> Only MXF used an actual sample array, and that is unneeded there because
> simple
> rounding rules can be used instead.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/audiointerleave.c | 24 ++--
> libavformat/audiointerleave.h | 7 ---
> libavformat/gxfenc.c | 2 +- libavformat/mxfenc.c | 7
> ++-
>
> libavformat/mxfenc.c | 7 ++-
> 4 files changed, 17 insertions(+), 23 deletions(-)
>
> diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
> index 6797546a44..f9887c1f4a 100644
> --- a/libavformat/audiointerleave.c
> +++ b/libavformat/audiointerleave.c
> @@ -39,14 +39,11 @@ void ff_audio_interleave_close(AVFormatContext *s)
> }
>
> int ff_audio_interleave_init(AVFormatContext *s,
> - const int *samples_per_frame,
> + const int samples_per_frame,
> AVRational time_base)
> {
> int i;
>
> -if (!samples_per_frame)
> -return AVERROR(EINVAL);
> -
> if (!time_base.num) {
> av_log(s, AV_LOG_ERROR, "timebase not set for audio
> interleave\n");
> return AVERROR(EINVAL);
> @@ -56,18 +53,18 @@ int ff_audio_interleave_init(AVFormatContext *s,
> AudioInterleaveContext *aic = st->priv_data;
>
> if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
> +int max_samples = samples_per_frame ? samples_per_frame :
> av_rescale_rnd(st->codecpar->sample_rate, time_base.num, time_base.den,
> AV_ROUND_UP);
>
This line and a few others are overly long. Why don't you split them?
> aic->sample_size = (st->codecpar->channels *
>
> av_get_bits_per_sample(st->codecpar->codec_id)) / 8;
> if (!aic->sample_size) {
> av_log(s, AV_LOG_ERROR, "could not compute sample
> size\n");
> return AVERROR(EINVAL);
> }
> -aic->samples_per_frame = samples_per_frame;
> -aic->samples = aic->samples_per_frame;
> aic->time_base = time_base;
> +aic->samples_per_frame = samples_per_frame;
>
I don't see a reason to move this line and not moving it would lead to a
smaller diff.
>
> -aic->fifo_size = 100* *aic->samples;
> -if (!(aic->fifo= av_fifo_alloc_array(100, *aic->samples)))
> +aic->fifo_size = 100 * max_samples;
>
It doesn't matter here, but I think it is generally better to only set the
size after you know the allocation succeeded.
> +if (!(aic->fifo = av_fifo_alloc_array(100, max_samples)))
> return AVERROR(ENOMEM);
> }
> }
> @@ -81,7 +78,8 @@ static int interleave_new_audio_packet(AVFormatContext
> *s, AVPacket *pkt,
> AVStream *st = s->streams[stream_index];
> AudioInterleaveContext *aic = st->priv_data;
> int ret;
> -int frame_size = *aic->samples * aic->sample_size;
> +int nb_samples = aic->samples_per_frame ? aic->samples_per_frame :
> (av_rescale_q(aic->n + 1, av_make_q(st->codecpar->sample_rate, 1),
> av_inv_q(aic->time_base)) - aic->nb_samples);
> +int frame_size = nb_samples * aic->sample_size;
> int size = FFMIN(av_fifo_size(aic->fifo), frame_size);
> if (!size || (!flush && size == av_fifo_size(aic->fifo)))
> return 0;
> @@ -95,13 +93,11 @@ static int interleave_new_audio_packet(AVFormatContext
> *s, AVPacket *pkt,
> memset(pkt->data + size, 0, pkt->size - size);
>
> pkt->dts = pkt->pts = aic->dts;
> -pkt->duration = av_rescale_q(*aic->samples, st->time_base,
> aic->time_base);
> +pkt->duration = av_rescale_q(nb_samples, st->time_base,
> aic->time_base);
> pkt->stream_index = stream_index;
> aic->dts += pkt->duration;
> -
> -aic->samples++;
> -if (!*aic->samples)
> -aic->samples = aic->samples_per_frame;
> +aic->nb_samples += nb_samples;
> +aic->n++;
>
> return pkt->size;
> }
> diff --git a/libavformat/audiointerleave.h b/libavformat/audiointerleave.h
> index f28d5fefcc..0933310f4c 100644
> --- a/libavformat/audiointerleave.h
> +++ b/libavformat/audiointerleave.h
> @@ -29,14 +29,15 @@
> typedef struct AudioInterleaveContext {
> AVFifoBuffer *fifo;
> unsigned fifo_size; ///< size of currently allocated FIFO
> +int64_t n;///< number of generated packets
> +int64_t nb_samples; ///< number of generated samples
> uint64_t dts; ///< current dts
> int sample_size; ///< size of one sample all channels
> included
> -const int *samples_per_frame; ///< must be 0-terminated
> -const int *samples; ///< current samples per frame, pointer
> to samples_per_frame
> +int samples_per_frame;///< samples per frame if fixed, 0
> otherwise
> AVRational time_base; ///< time base of output audio packets
> } AudioIn
Re: [FFmpeg-devel] [PATCH 1/4] avformat/audiointerleave: disallow using a samples_per_frame array
Sorry for replying a bit late, I've been sick
fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
> Only MXF used an actual sample array, and that is unneeded there
> because simple
> rounding rules can be used instead.
Does this produce the exact same rounding? Like 1602, 1601,
1602, 1601, 1602, 1062 ... for 30/1.001 fps? If so then this is a nice
solution
> Signed-off-by: Marton Balint
> ---
> libavformat/audiointerleave.c | 24 ++--
> libavformat/audiointerleave.h | 7 ---
> libavformat/gxfenc.c | 2 +-
> libavformat/mxfenc.c | 7 ++-
> 4 files changed, 17 insertions(+), 23 deletions(-)
>
> diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
> index 6797546a44..f9887c1f4a 100644
> --- a/libavformat/audiointerleave.c
> +++ b/libavformat/audiointerleave.c
> @@ -39,14 +39,11 @@ void ff_audio_interleave_close(AVFormatContext *s)
> }
>
> int ff_audio_interleave_init(AVFormatContext *s,
> - const int *samples_per_frame,
> + const int samples_per_frame,
> AVRational time_base)
> {
> int i;
>
> -if (!samples_per_frame)
> -return AVERROR(EINVAL);
> -
> if (!time_base.num) {
> av_log(s, AV_LOG_ERROR, "timebase not set for audio interleave\n");
> return AVERROR(EINVAL);
> @@ -56,18 +53,18 @@ int ff_audio_interleave_init(AVFormatContext *s,
> AudioInterleaveContext *aic = st->priv_data;
>
> if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
> +int max_samples = samples_per_frame ? samples_per_frame :
> av_rescale_rnd(st->codecpar->sample_rate, time_base.num, time_base.den,
> AV_ROUND_UP);
Looks correct
> aic->sample_size = (st->codecpar->channels *
>
> av_get_bits_per_sample(st->codecpar->codec_id)) / 8;
> if (!aic->sample_size) {
> av_log(s, AV_LOG_ERROR, "could not compute sample size\n");
> return AVERROR(EINVAL);
> }
> -aic->samples_per_frame = samples_per_frame;
> -aic->samples = aic->samples_per_frame;
> aic->time_base = time_base;
> +aic->samples_per_frame = samples_per_frame;
>
> -aic->fifo_size = 100* *aic->samples;
> -if (!(aic->fifo= av_fifo_alloc_array(100, *aic->samples)))
> +aic->fifo_size = 100 * max_samples;
> +if (!(aic->fifo = av_fifo_alloc_array(100, max_samples)))
> return AVERROR(ENOMEM);
> }
> }
> @@ -81,7 +78,8 @@ static int interleave_new_audio_packet(AVFormatContext *s,
> AVPacket *pkt,
> AVStream *st = s->streams[stream_index];
> AudioInterleaveContext *aic = st->priv_data;
> int ret;
> -int frame_size = *aic->samples * aic->sample_size;
> +int nb_samples = aic->samples_per_frame ? aic->samples_per_frame :
> (av_rescale_q(aic->n + 1, av_make_q(st->codecpar->sample_rate, 1),
> av_inv_q(aic->time_base)) - aic->nb_samples);
Here's where the meat is. av_rescale_q() means AV_ROUND_NEAR_INF. So
basically round(). Fiddling around a bit in Octave to replicate the
logic:
octave:13> round(48000*1001/3)
ans = 1602
octave:14> round(48000*1001/3*2)-1602
ans = 1601
octave:15> round(48000*1001/3*3)-(1602+1601)
ans = 1602
octave:16> round(48000*1001/3*4)-(1602+1601+1602)
ans = 1601
octave:17> 48000*1001/3*5-(1602+1601+1602+1601)
ans = 1602
Seems kosher. The rest of the patch looks OK.
mxfdec.c could also make use of this. Then we could remove
ff_mxf_get_samples_per_frame() and related code. Replacing
mxf_content_package_rates with a simple formula would also be nice.
/Tomas
___
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 v2 1/2] avformat: Add AMQP version 0-9-1 protocol support
On Mon, 02. Mar 11:41, Anton Khirnov wrote: > Quoting Marton Balint (2020-02-29 17:09:58) > > > > > > On Sat, 29 Feb 2020, Paul B Mahol wrote: > > > > > I think this was already rejected? > > > > jb questioned if this belongs to libavformat, and timo asked how well the > > message brokers handle high bitrates/big message sizes, no hard rejects > > were made as far as I remember. > > > > Andriy provided numbers for scaling, I have not answered the concerns > > regarding libavformat integration, because I am not sure I understand the > > concern. AMQP is a general purpose protocol for message transfer, it even > > has an official URL scheme, so when we integrate it into libavformat as a > > *protocol* I don't really see why it would not fit into the framework or > > what can be gained if it is implemented separately. > > > > If people still have hard feelings against merging this, please speak up, > > but I honestly don't see a problem with it. > > I would say the question is what is it for? Is anyone using (or > intending to use) this for multimedia transfer? What are the advantages > of doing that over other existing protocols? "why not" does not seem > like a sufficient argument to me. We have 5-10 nodes that are already talking to each other via a RabbitMQ broker. A few of these nodes may be publishing low bitrate multimedia content, and new ones may join the network. The idea is to re-use the RabbitMQ broker instead of using a separate video server, where we can view all the logs (queue sizes, etc.) on the same webui. Also Marton mentioned a use case here: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256976.html -- Andriy ___ 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] avcodec/cuviddec: use AVCodec.bsfs to filter packets
On 3/2/2020 7:35 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-01 04:00:25)
> [...]
>> +if (avctx->codec->bsfs) {
>> +const AVBSFContext *bsf =
>> avctx->internal->filter.bsfs[avctx->internal->filter.nb_bsfs - 1];
>
> yuck
>
> I guess it's acceptable for now, but we'll want to get rid of that in
> the future. Might be tricky though...
>
> Patch looks good otherwise.
I tried in f631c328e6. Long story short, it was a disaster, since
AVCodecContext.extradata is supposedly owned by the caller in decoding
scenarios, and some projects started crashing because of it. Had to be
reverted in 87588caf8c. So any solution will have to be internal but
less ugly, or an API change.
___
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 1/1] Patch for adding Documentation of ff_http_match_no_proxy
Patch for adding Documentation of ff_http_match_no_proxy Function ff_http_match_no_proxy check for host of proxy address matches with the hostname or not. --- libavformat/network.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavformat/network.h b/libavformat/network.h index 71347e815b..7c93375ae5 100644 --- a/libavformat/network.h +++ b/libavformat/network.h @@ -303,6 +303,13 @@ int ff_listen_connect(int fd, const struct sockaddr *addr, socklen_t addrlen, int timeout, URLContext *h, int will_try_next); +/** + * It Checks for a host of proxy address matches with the hostname or not. + * + * @param no_proxy Server address of proxy server e.g. example.domain.com + * @param hostname Server address of hostname e.g. domain.com + * @return 0 if don't match, 1 for exactly match +*/ int ff_http_match_no_proxy(const char *no_proxy, const char *hostname); int ff_socket(int domain, int type, int protocol); -- 2.11.0 On Sun, Mar 1, 2020 at 2:49 AM Michael Niedermayer wrote: > On Sat, Feb 29, 2020 at 05:07:30PM +0530, Sourabh Sharma wrote: > > Patch for adding Documentation of ff_http_match_no_proxy > > > > Function ff_http_match_no_proxy check for host of proxy address > > matches with hostname or not. > > --- > > libavformat/network.h | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/libavformat/network.h b/libavformat/network.h > > index 71347e815b..cd533a7cbc 100644 > > --- a/libavformat/network.h > > +++ b/libavformat/network.h > > @@ -302,7 +302,13 @@ int ff_accept(int fd, int timeout, URLContext *h); > > int ff_listen_connect(int fd, const struct sockaddr *addr, > >socklen_t addrlen, int timeout, > >URLContext *h, int will_try_next); > > - > > > +/** > > + * It Check for host of proxy address matches with hostname or not. > > This has some english grammer issues. > Also look at how other similar function doxy is worded > > > > + * > > + * @param no_proxy URL of proxy address > > + * @param hostname URL of hostname > > I dont think the function would be understood from just this > > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Does the universe only have a finite lifespan? No, its going to go on > forever, its just that you wont like living in it. -- Hiranya Peiri > ___ > 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".
[FFmpeg-devel] [PATCH] avformat/udp: support w32pthreads compat
---
compat/w32pthreads.h | 8
libavformat/udp.c| 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 7df33b7da4..6405e72b64 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
+#define PTHREAD_CANCEL_ENABLE 1
+#define PTHREAD_CANCEL_DISABLE 0
+
static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
{
pthread_t *h = (pthread_t*)arg;
@@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
return 0;
}
+static inline int pthread_setcancelstate(int state, int *oldstate)
+{
+return 0;
+}
+
#endif /* COMPAT_W32PTHREADS_H */
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 23c3773c64..692ff07cec 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,7 +61,11 @@
#define IPPROTO_UDPLITE 136
#endif
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_W32THREADS
+#include "compat/w32pthreads.h"
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#elif HAVE_PTHREAD_CANCEL
#include
#endif
--
2.20.1 (Apple Git-117)
___
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/udp: support w32pthreads compat
Thanks!
On Mon, 2 Mar 2020 at 14:16, Andriy Gelman wrote:
> On Mon, 02. Mar 13:38, phunkyfish wrote:
> > ---
> > compat/w32pthreads.h | 10 ++
> > libavformat/udp.c| 8 +++-
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > index 7df33b7da4..64cd40cda4 100644
> > --- a/compat/w32pthreads.h
> > +++ b/compat/w32pthreads.h
> > @@ -63,6 +63,11 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> > #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0,
> 0)
> > #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
> >
> > +#undef PTHREAD_CANCEL_ENABLE
> > +#undef PTHREAD_CANCEL_DISABLE
> > +#define PTHREAD_CANCEL_ENABLE 1
> > +#define PTHREAD_CANCEL_DISABLE 0
> > +
> > static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> > {
> > pthread_t *h = (pthread_t*)arg;
> > @@ -180,4 +185,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> > return 0;
> > }
> >
> > +static inline int pthread_setcancelstate(int state, int *oldstate)
> > +{
> > +return 0;
> > +}
> > +
> > #endif /* COMPAT_W32PTHREADS_H */
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index 23c3773c64..4f42b026cd 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -61,10 +61,16 @@
> > #define IPPROTO_UDPLITE 136
> > #endif
> >
> > -#if HAVE_PTHREAD_CANCEL
>
> > +#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
> > #include
> > #endif
>
> In my config.h HAVE_W32THREADS is defined, but it's set to 0
> so it ends up not including the pthread.h header
>
> >
> > +#if HAVE_W32THREADS
> > +#include "compat/w32pthreads.h"
> > +#undef HAVE_PTHREAD_CANCEL
> > +#define HAVE_PTHREAD_CANCEL 1
> > +#endif
> > +
> > #ifndef IPV6_ADD_MEMBERSHIP
> > #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
> > #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
>
> --
> Andriy
>
___
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/udp: support w32pthreads compat
On Mon, 02. Mar 13:38, phunkyfish wrote:
> ---
> compat/w32pthreads.h | 10 ++
> libavformat/udp.c| 8 +++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 7df33b7da4..64cd40cda4 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -63,6 +63,11 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>
> +#undef PTHREAD_CANCEL_ENABLE
> +#undef PTHREAD_CANCEL_DISABLE
> +#define PTHREAD_CANCEL_ENABLE 1
> +#define PTHREAD_CANCEL_DISABLE 0
> +
> static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> {
> pthread_t *h = (pthread_t*)arg;
> @@ -180,4 +185,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> return 0;
> }
>
> +static inline int pthread_setcancelstate(int state, int *oldstate)
> +{
> +return 0;
> +}
> +
> #endif /* COMPAT_W32PTHREADS_H */
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 23c3773c64..4f42b026cd 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -61,10 +61,16 @@
> #define IPPROTO_UDPLITE 136
> #endif
>
> -#if HAVE_PTHREAD_CANCEL
> +#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
> #include
> #endif
In my config.h HAVE_W32THREADS is defined, but it's set to 0
so it ends up not including the pthread.h header
>
> +#if HAVE_W32THREADS
> +#include "compat/w32pthreads.h"
> +#undef HAVE_PTHREAD_CANCEL
> +#define HAVE_PTHREAD_CANCEL 1
> +#endif
> +
> #ifndef IPV6_ADD_MEMBERSHIP
> #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
> #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
--
Andriy
___
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] [PATCH] avformat/udp: support w32pthreads compat
---
compat/w32pthreads.h | 10 ++
libavformat/udp.c| 8 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 7df33b7da4..64cd40cda4 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -63,6 +63,11 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
+#undef PTHREAD_CANCEL_ENABLE
+#undef PTHREAD_CANCEL_DISABLE
+#define PTHREAD_CANCEL_ENABLE 1
+#define PTHREAD_CANCEL_DISABLE 0
+
static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
{
pthread_t *h = (pthread_t*)arg;
@@ -180,4 +185,9 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
return 0;
}
+static inline int pthread_setcancelstate(int state, int *oldstate)
+{
+return 0;
+}
+
#endif /* COMPAT_W32PTHREADS_H */
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 23c3773c64..4f42b026cd 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,10 +61,16 @@
#define IPPROTO_UDPLITE 136
#endif
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
#include
#endif
+#if HAVE_W32THREADS
+#include "compat/w32pthreads.h"
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
#ifndef IPV6_ADD_MEMBERSHIP
#define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
#define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
--
2.20.1 (Apple Git-117)
___
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/udp: support w32pthreads compat
This should allow the use of w32pthreads compat layer to be used for UDP.
For windows this would mean not needing to change the underlying
threading impl.
On Mon, 2 Mar 2020 at 12:53, phunkyfish wrote:
> ---
> compat/w32pthreads.h | 8
> libavformat/udp.c| 8 +++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 7df33b7da4..6405e72b64 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
>
> +#define PTHREAD_CANCEL_ENABLE 1
> +#define PTHREAD_CANCEL_DISABLE 0
> +
> static av_unused unsigned __stdcall attribute_align_arg
> win32thread_worker(void *arg)
> {
> pthread_t *h = (pthread_t*)arg;
> @@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t
> *cond)
> return 0;
> }
>
> +static inline int pthread_setcancelstate(int state, int *oldstate)
> +{
> +return 0;
> +}
> +
> #endif /* COMPAT_W32PTHREADS_H */
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 23c3773c64..4f42b026cd 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -61,10 +61,16 @@
> #define IPPROTO_UDPLITE 136
> #endif
>
> -#if HAVE_PTHREAD_CANCEL
> +#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
> #include
> #endif
>
> +#if HAVE_W32THREADS
> +#include "compat/w32pthreads.h"
> +#undef HAVE_PTHREAD_CANCEL
> +#define HAVE_PTHREAD_CANCEL 1
> +#endif
> +
> #ifndef IPV6_ADD_MEMBERSHIP
> #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
> #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
> --
> 2.20.1 (Apple Git-117)
>
>
___
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] [PATCH] avformat/udp: support w32pthreads compat
---
compat/w32pthreads.h | 8
libavformat/udp.c| 8 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 7df33b7da4..6405e72b64 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -63,6 +63,9 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
+#define PTHREAD_CANCEL_ENABLE 1
+#define PTHREAD_CANCEL_DISABLE 0
+
static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
{
pthread_t *h = (pthread_t*)arg;
@@ -180,4 +183,9 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
return 0;
}
+static inline int pthread_setcancelstate(int state, int *oldstate)
+{
+return 0;
+}
+
#endif /* COMPAT_W32PTHREADS_H */
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 23c3773c64..4f42b026cd 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,10 +61,16 @@
#define IPPROTO_UDPLITE 136
#endif
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_PTHREAD_CANCEL && !defined(HAVE_W32THREADS)
#include
#endif
+#if HAVE_W32THREADS
+#include "compat/w32pthreads.h"
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
#ifndef IPV6_ADD_MEMBERSHIP
#define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
#define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
--
2.20.1 (Apple Git-117)
___
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 V2] [RFC] GSoC: FLIF16 Image format parser
Hello,
> Is there an upper bound for the size of these integers? In my
> experience, varints in multimedia code are used to save a few bits in
> the file than to allow very large integers. You could make the code much
> simpler if you had an upper bound.
>
> Also, there is probably already similar code, because it is a common
> feature.
According to the specification of the file format, there is no mention of an
upper bound for the integer: https://flif.info/spec.html#_part_1_main_header
>> + * magnitude of the varint, similar to UTF-8 encoding.
>
> This is not how UTF-8 works.
I was talking about it in the context of the 'prefix coding' it uses. UTF-8
uses the MSB bits to indicate how many successive bits aside from the starting
bit are included in a character. The varint does a similar thing in the manner
that it also uses an MSB bit to indicate that a successive bit is included in
the number. Hovever aside from this superficial similarity there is not much
in common.
>> +varint_t *flif16_varint_alloc(unsigned int pad, uint8_t lsbval)
>> +{
>> +varint_t *v = av_mallocz(sizeof(varint_t));
>
>When possible, prefer sizeof(*var) to sizeof(type).
Okay
>> + if(!v)
>
> Our coding style mandates spaces after if, for, etc.
Yes. There are several other non-uniformities in the code.
>> + return v;
>
> return NULL is more idiomatic.
True. I was looking through the AVpacket functions and in the av_packet_alloc
function: https://ffmpeg.org/doxygen/trunk/avpacket_8c_source.html#l00051 (line
51)
there's a similar pattern followed:
AVPacket *pkt = av_mallocz(sizeof(AVPacket));
if (!pkt)
return pkt;
Is there a special reason for this?
>> +v->buf = av_mallocz(sizeof(uint8_t) * (pad + 1));
>
>sizeof(uint8_t) is guaranteed to be 1 on supported platforms.
>
>Missing malloc check. Better make it:
>
> v = av_mallocz(sizeof(*v) + pad);
>
>to allocate both at the same time: more efficient.
I see. the stucture should therefore be defined with buf after buf_size
(hence putting pad + 1 bytes in contiguous storage but there may be a problem
with the byte padding of the struct), or should buf point to v + sizeof(*v)?
(* See follow-up content below)
>> +v->buf[pad] = lsbval & 127;
>> +v->buf_size = pad + 1;
>> +return v;
>> +}
>> +
>> +void flif16_varint_free(varint_t *v)
>> +{
>> +av_free(v->buf);
>> +av_free(v);
>> +}
>> +
>> +// May be made faster by providing MSByte as a parameter.
>> +unsigned int flif16_varint_inc(varint_t *v)
>> +{
>> +unsigned int msb;
>
>> +av_assert0(v->buf_size);
>
>If speed is a concern, use av_assert1().
Okay
>> +msb = v->buf_size - 1;
>> +
>> +for(; msb > 0; --msb) {
>
>> +if(v->buf[msb] == 127) {
>> +v->buf[msb] = 0;
>> +} else {
>> +++v->buf[msb];
>> +return msb;
>> +}
>
>Did you test this code for varint { 127, 127, 127 }?
I have tested it separately. In the given code, the function will set the value
to { 128, 0, 0 }, which is an incorrect representation. But for the puropses of
the parser and the decoder where we are only concerned with bound checking with
an existing number, such a situation will never occur. However I can see that
there will be issues when the encoder will be written since then we will have
to make the varint and write the varint to a file.
>> +}
>> +
>> +++v->buf[msb];
>> +return msb;
>> +}
>> +
>>
>> +void flif16_varint_append(varint_t *v, uint8_t vs)
>> +{
>> +av_fast_realloc(v->buf, &v->buf_size, v->buf_size + 1);
>
>> +av_assert0(v->buf);
>
>An assert cannot be used to check for a memory allocation failure.
I think I have to use av_log then.
>> + v->buf[v->buf_size - 1] = vs & 127;
>> +}
>
> Increasing a buffer one by one is inefficient. Please consider doubling
> the size.
Should I double the size everytime v->buf_size becomes
equal to the actual number of byte-segments of the varint?
>> +typedef struct varint_t {
>> + uint8_t *buf;
>
> To avoid the indirection and extra malloc, you can make it
> uint8_t buf[1] at the end of the structure.
If I add it to the end of the struct, the compiler will likely add padding
bits to it, but I don't think its a problem since the padding bits will be set
to zero anyway and therefore can be used in the buffer.
>> + unsigned int buf_size; // Assuming that no one will try to make an image of
>> + // dimensions greater than 2^32x2^32
>
> unsigned is enough. Same everywhere.
>
> I suppose size_t would be way overkill for this case.
Ok
>> +} varint_t;
>
> Names ending in _t are reserved by the C standard. FFmpeg uses types
> with capitals and FF prefix for private APIs.
FLIF16Varint should be fine then?
>> +
>> +/**
>> + * Allocates an empty varint.
>> + * Note the 'pad' parameter here. This can be used to pad the number with
>> + * preceeding bytes if we already know the number of bytes in the number.
>> + * @param pad The number of
Re: [FFmpeg-devel] [PATCH V1 1/3] lavf/dashenc: add 3GPP TS26.247 probe in dash demuxer
On Mon, Mar 2, 2020 at 5:10 PM Carl Eugen Hoyos wrote:
>
> Am So., 1. März 2020 um 13:39 Uhr schrieb Jun Zhao :
> >
> > From: Jun Zhao
> >
> > Enabled the 3GP-DASH Release-10/Relase-11(3GPP TS26.247) profile
> > to dash demuxer probe.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/dashdec.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index 15e79fd..7be3276 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -2361,7 +2361,9 @@ static int dash_probe(const AVProbeData *p)
> > if (av_stristr(p->buf, "dash:profile:isoff-on-demand:2011") ||
> > av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> > av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> > -av_stristr(p->buf, "dash:profile:isoff-main:2011")) {
> > +av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
>
> > +av_stristr(p->buf, "3GPP:PSS:profile:DASH10") ||
> > +av_stristr(p->buf, "3GPP:PSS:profile:DASH11")) {
>
> Is there a reason why you don't compare with "3GPP:PSS:profile:DASH1"?
>
No particular reason , in fact :)
___
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 v2 1/2] avformat: Add AMQP version 0-9-1 protocol support
Am Mo., 2. März 2020 um 11:41 Uhr schrieb Anton Khirnov : > > Quoting Marton Balint (2020-02-29 17:09:58) > > > > > > On Sat, 29 Feb 2020, Paul B Mahol wrote: > > > > > I think this was already rejected? > > > > jb questioned if this belongs to libavformat, and timo asked how well the > > message brokers handle high bitrates/big message sizes, no hard rejects > > were made as far as I remember. > > > > Andriy provided numbers for scaling, I have not answered the concerns > > regarding libavformat integration, because I am not sure I understand the > > concern. AMQP is a general purpose protocol for message transfer, it even > > has an official URL scheme, so when we integrate it into libavformat as a > > *protocol* I don't really see why it would not fit into the framework or > > what can be gained if it is implemented separately. > > > > If people still have hard feelings against merging this, please speak up, > > but I honestly don't see a problem with it. > > I would say the question is what is it for? Is anyone using (or > intending to use) this for multimedia transfer? What are the advantages > of doing that over other existing protocols? "why not" does not seem > like a sufficient argument to me. I can only say that I (heavily) object to your argumentation, it is basically against everything FFmpeg stands for (imo). Carl Eugen ___ 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 v2 1/2] avformat: Add AMQP version 0-9-1 protocol support
Quoting Marton Balint (2020-02-29 17:09:58) > > > On Sat, 29 Feb 2020, Paul B Mahol wrote: > > > I think this was already rejected? > > jb questioned if this belongs to libavformat, and timo asked how well the > message brokers handle high bitrates/big message sizes, no hard rejects > were made as far as I remember. > > Andriy provided numbers for scaling, I have not answered the concerns > regarding libavformat integration, because I am not sure I understand the > concern. AMQP is a general purpose protocol for message transfer, it even > has an official URL scheme, so when we integrate it into libavformat as a > *protocol* I don't really see why it would not fit into the framework or > what can be gained if it is implemented separately. > > If people still have hard feelings against merging this, please speak up, > but I honestly don't see a problem with it. I would say the question is what is it for? Is anyone using (or intending to use) this for multimedia transfer? What are the advantages of doing that over other existing protocols? "why not" does not seem like a sufficient argument to me. -- Anton Khirnov ___ 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] avcodec/cuviddec: use AVCodec.bsfs to filter packets
Quoting James Almer (2020-03-01 04:00:25)
[...]
> +if (avctx->codec->bsfs) {
> +const AVBSFContext *bsf =
> avctx->internal->filter.bsfs[avctx->internal->filter.nb_bsfs - 1];
yuck
I guess it's acceptable for now, but we'll want to get rid of that in
the future. Might be tricky though...
Patch looks good otherwise.
--
Anton Khirnov
___
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 V2] [RFC] GSoC: FLIF16 Image format parser
Quoting Nicolas George (2020-03-01 19:59:11) > > > +} varint_t; > > Names ending in _t are reserved by the C standard. FFmpeg uses types > with capitals and FF prefix for private APIs. FF prefix is not needed for structs. -- Anton Khirnov ___ 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 3/17] avformat/avformat: Allow const AVOutputFormat where possible
Am Mo., 2. März 2020 um 05:36 Uhr schrieb Andreas Rheinhardt : > -int avformat_alloc_output_context2(AVFormatContext **ctx, ff_const59 > AVOutputFormat *oformat, > +int avformat_alloc_output_context2(AVFormatContext **ctx, const > AVOutputFormat *oformat, > const char *format_name, const char > *filename); I believe this breaks C++ code using libavformat. Carl Eugen ___ 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 1/3] lavf/dashenc: add 3GPP TS26.247 probe in dash demuxer
Am So., 1. März 2020 um 13:39 Uhr schrieb Jun Zhao :
>
> From: Jun Zhao
>
> Enabled the 3GP-DASH Release-10/Relase-11(3GPP TS26.247) profile
> to dash demuxer probe.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/dashdec.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 15e79fd..7be3276 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -2361,7 +2361,9 @@ static int dash_probe(const AVProbeData *p)
> if (av_stristr(p->buf, "dash:profile:isoff-on-demand:2011") ||
> av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> -av_stristr(p->buf, "dash:profile:isoff-main:2011")) {
> +av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
> +av_stristr(p->buf, "3GPP:PSS:profile:DASH10") ||
> +av_stristr(p->buf, "3GPP:PSS:profile:DASH11")) {
Is there a reason why you don't compare with "3GPP:PSS:profile:DASH1"?
Carl Eugen
___
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 1/2] avcodec/adpcm: Clip step index for ADPCM_IMA_APM
lgtm
On 3/1/20, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 20828/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_IMA_APM_fuzzer-5712770106654720
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/adpcm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> index b987e93c5f..5f152ee6ef 100644
> --- a/libavcodec/adpcm.c
> +++ b/libavcodec/adpcm.c
> @@ -154,9 +154,9 @@ static av_cold int adpcm_decode_init(AVCodecContext *
> avctx)
> case AV_CODEC_ID_ADPCM_IMA_APM:
> if (avctx->extradata && avctx->extradata_size >= 16) {
> c->status[0].predictor = AV_RL32(avctx->extradata + 0);
> -c->status[0].step_index = AV_RL32(avctx->extradata + 4);
> +c->status[0].step_index = av_clip(AV_RL32(avctx->extradata +
> 4), 0, 88);
> c->status[1].predictor = AV_RL32(avctx->extradata + 8);
> -c->status[1].step_index = AV_RL32(avctx->extradata + 12);
> +c->status[1].step_index = av_clip(AV_RL32(avctx->extradata +
> 12), 0, 88);
> }
> break;
> case AV_CODEC_ID_ADPCM_IMA_WS:
> --
> 2.17.1
>
> ___
> 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".
